How about a Real World Deployment wiki page linked from each RFC, where implementers can insert comments like "Don't do like vendor xxx - don't always set the nonce to zero". Hopefully vendor xxx fixes it in the next release, and changes the page to read "Don't do like vendor xxx did prior to version 6.14 - don't always set the nonce to zero." Sadly, as soon as the marketing and legal departments get wind of this, they will edit this to say "Don't always set the nonce to zero", but that should be good enough. -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Sabahattin Gucukoglu Sent: Thursday, April 22, 2010 8:39 AM To: ietf@xxxxxxxx Subject: Re: another document categorization suggestion On 22 Apr 2010, at 01:55, james woodyatt wrote: > After just now finding the root cause of yet another stupid interoperability problem to be an interaction between a client not choosing a sufficiently unique host/session identifier and a server being overly clever about using said identifiers for purposes other than intended in the protocol specification... > > WHEREAS the IETF has no document category for dealing with material that is unfit for Standards Track, that does not in any way describe Best Current Practice, provides Information of questionable utility, which is neither yet limited to Historical interest nor of merely Experimental nature... > > BE IT HEREBY RESOLVED that IETF should create a new document category for Disinformation, and that RFC 2516 should immediately and with extreme prejudice be reclassified as such without further discussion. I think what we're really looking for in cases like this is a document subset called RWD, or Real World Deployment. This subset comprises of notes stating the necessary information that couldn't possible be included in specifications for any number of good reasons, but which assist those implementing those specifications to avoid the next incoming arrow of misfortune that results from trying to interoperate with the incredible array of brain-dead implementations using the dubious interpretations that exist, perhaps just to the benefit of the IETF, for whom these concerns are perhaps greater than those of the vendor. As a concession to avoiding further bureaucracy, because we get enough of that as it is, and as an aid to IETF sponsorship, special offers should be made concerning vendor recognition in such documents. The hopeful consequence of this is that the subset should be modest in size, if not purpose, and will remain so for the foreseeable future. Cheers, Sabahattin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf