[rfc-i] Towards Consensus

Joe Touch touch at isi.edu
Fri May 25 23:10:25 PDT 2012

On May 25, 2012, at 10:05 AM, Phillip Hallam-Baker wrote:

> ...
> > In 20 years of being involved in IETF, I have never once come across a situation where the presentation format of a document introduced an ambiguity. And in the highly unlikely case that it ever did, a new document would be required in any case. The document that is most likely to be considered 'authoritative' today would be the XML2RFC input.
> It's actually the txt. The XML2RFC input may be retained, but the txt is the ONLY current authoritative version, internal or otherwise.
> Authoritative, shmoratative. 
> We are currently having a discussion in my industry about RFC 5280. The specification clearly states that Name Constraints MUST be marked critical. I think it almost certain that the industry is about to vote to ignore that requirement. And yes, we have votes. This is a parallel process that has sprung up because the IETF did not meet industry or end user needs.
> Now if an industry can decide (almost certain to be unanimous in this case) that an RFC is to be ignored, I am pretty sure that the question of which presentation format is used is completely irrelevant. 

The question of normative document refers to "which document *is* RFC 5280". Whether anyone follows that doc or not is a separate issue.

> The IETF does not make laws. It does not have any plenary authority whatsoever. Describing RFCs as being 'authoritative' is just piffle. 

The RFC Editor *does* publish RFCs, and those RFCs have an ISBN number. It's absolutely relevant to ask what is being published - and what alternate forms (which are not being published, but are being made available as a convenience) exist.

> > Proposition 4: XML2RFC MUST continue to be supported as an input format
> Not any more than nroff, Word, or any other format.
> The reason I say this is that the current production toolchain requires either nroff or XML2RFC. 

The production tool doesn't matter. Authors do NOT verify the correctness of the nroff or xml2rfc versions; they verify the *txt* that the RFC Editor provides (and we don't know - or care - how they manage that).

I.e., there could be many variants of nroff or xml2rfc that generate indistinguishable output. None of those differences are relevant, since the RFC Editor never makes its internal versions available to others. It does make the author's version available upon request for some versions.

> If you want to pick one, then say that txt must be continued to be allowed, even if discouraged.
> Nope, no metadata.

It does have metadata, but not in a way that's necessarily automatically extracted. That doesn't mean the metadata isn't there.


More information about the rfc-interest mailing list