We issue errata for RFCs. Most errata address a substantive defect in the text that would affect the protocol. The RFC may be 'authoritative' (whatever that is meant to mean) but the errata is almost certainly what someone would want to actually implement to make the protocol work. I remember a case in the X.25 protocol specs which turned out to be so wrong that the only way to make them work was to look at bits on the wire and work out what real X.25 boxen did. If I had the xml2rfc source, and the errata in appropriate form, I could then write a piece of code that shows the errata in context of the RFC, so that I can then see that there is a correction as I am looking at the page. RFC stands for Request For Comments. The idea of an authoritative request is a little strange. This is not scripture. It is an engineering tool. There are plenty of IETF specs where best practice on the net is to ignore the MUST requirements of RFCs. A case in point is the ludicrous requirement in the FTP spec that the user interface default to ascii mode rather than binary. That may have made sense in the mid 70s, but I somewhat doubt it, EBSIDC was already on its way out. The chance of meeting a system that uses a character set that could be matched through the naive transcoding mechanism in FTP clients is many orders of magnitude less than that of a straight guy getting lucky on chatroulette. On Fri, Mar 19, 2010 at 1:06 PM, Henning Schulzrinne <hgs@xxxxxxxxxxxxxxx> wrote: > Maybe I'm not enough of a amateur lawyer, but has "authoritative" been a practical issue, i.e., has there been confusion or legal action because one rendition (say, PDF) differed in some trivial aspect from another (e.g., ASCII)? > > Pragmatically, one could simply state that one form (say, good-ol ASCII, to avoid endless debates and for historical reasons) was authoritative and that others were "best effort" versions of the same text and that any deviations and omissions were accidental and should be brought to the attention of the appropriate authorities. I'm sure we can come up with more legal boiler plate to phrase this more precisely - we seem to be getting good at this boilerplate thing... > > With that caveat, in the case of a (presumably exceedingly rare) production error, the non-authoritative version could then be updated, in the same manner that the auto-generated pseudo-HTML versions we have today on the IETF site change occasionally as the rendering program is improved. This doesn't seem to have caused a significant protocol interoperability problem. > > Henning > > On Mar 18, 2010, at 12:42 PM, Bob Braden wrote: > >> >> >> John R. Levine wrote: >> >>> between the XML and the final output. If we could agree that the final XML was authoritative, >> >> John, >> >> What, precisely, do you mean here? Do you mean that there would be NO text form of an RFC that was authoritative, or do you mean that BOTH the xml2rfc form and some text-equivalent form (say, .txt or .pdf) would be authoritative? I don't quite understand how either choice would work. >> >> I am asking about RFCs here, not Internet Drafts, BTW. >> >> Thanks, >> >> Bob Braden >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf >> > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf