Jeffrey Hutzelman wrote: > A thinly veiled description of an actual situation is not a > hypothetical. 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 or CANCEL. > 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": <http://www.proper.com/lookit/hash-futures-panel-notes.html> [other examples] > 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. [expired cert] > 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@11. > 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 interesting). Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf