Jeffrey Hutzelman wrote:
A thinly veiled description of an actual situation is not a
Okay, pick a better adjective, I tried to make the point that
there is a pattern in these real examples: A technology where
only experts know how it works, while users get the choice OK
The spec was already quite clear on this.
Yes. Some wrote that the bug was to press the reset button,
others proposed to use another order of the list, but actually
it was a race condition, a communication problem between some
participants. "Did you sell a certificate to [insert bank or
celebrity] ?" - "Yes" - oops.
The change you are referring to in GSS-API v2u1 (RFC2743) is
hardly to an "obscure default"
I'm only a lurker on the SASL list, and from my POV it was an
obscure issue. The implementor tried to get it right, and used
the library as is, updating it when updates where available. I
can understand that he's upset about this issue, he took that
updated library in good faith, checking the relevant RFCs. Not
"your" (collective) fault, but a part of the pattern, even the
implementors are lost if the complete system is too complex.
Sometimes it has a funny side, I liked the "road to nowhere":
I don't think I can help you with any of these.
That's what the CERT folks told me, I should install OpenSSL
and figure it out for myself... ;-) Download and install was
fair enough, but admittedly I didn't manage to read the online
manuals so far.
Maybe your browser was broken before?
Maybe the cert wasn't expired before?
It wasn't (2005). I'd have to check if it is only one the
known bugs in this browser (several running instances, only
one of them can lock the cert.db, all others get defaults)
I don't think this scenario supports your argument that
documenting a protocol is better than not documenting it,
because I doubt that the problem is the result of an
ill-defined or underspecified protocol.
My point was something in the direction of "don't replace
KISS by TLS unless you must". 2195 is fine for its purpose,
nobody proposed to use it as the new ideal way to transmit
credit card numbers.
I'd guess that it is a result of an oversight on the part
of the operator of that server, combined with a complete
lack of anyone bothering to report the problem
Possible. And you guessed correctly that I never tried to
nail that last issue. For the ticket system I've given up
to report it, the complete issue is too ridiculous, one user
ietf password ietf can't get read access anymore, nobody
knows why, film(_at_)11(_dot_)
If we're talking about what happened to newtrk or what
the standards process should be, then we're talking about
how to designate and advance protocol specifications that
_are_ being published.
RFC 2195 was mainly an example, I had to pick something that
I had actually implemented. For the draft I can't claim this,
I haven't implemented SASLprep (maybe I'll try this later, the
part "yes, this is NFKC Unicode 5.0, but not 3.2" could be
Ietf mailing list