ietf
[Top] [All Lists]

Re: Why the normative form of IETF Standards is ASCII

2010-03-21 20:10:38
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(_at_)cs(_dot_)columbia(_dot_)edu> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>