[rfc-i] Towards Consensus

Joe Touch touch at isi.edu
Fri May 25 09:24:58 PDT 2012

I don't agree with any part of your discussion about XML2RFC.

One other point:

> I find the arguments about 'Canonical' format to be total nonsense. As far as IETF tradition goes, the standard has always been set by bits on the wire rather than the documents.

Protocols are bits on the wire, state at the endpoints, and the relationship between them. I keep hearing this silly reference to wire bits as defining protocols, which really should cease.

> 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.

> Proposition 4: XML2RFC MUST continue to be supported as an input format

Not any more than nroff, Word, or any other format.

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

> I think proposition 4 is self-evident. There is a considerable investment in the XML2RFC format. 

People invested in X.25 too. That's not itself a reason to stay with XML2RFC. 

I agree that it might be useful to ensure that something *like* XML2RFC be allowed, but I see no reason to assume this current format as a *requirement*.

> Even if additional input formats are supported it is going to be necessary to support XML2RFC for legacy.

If legacy input includes anything, it should include txt. I see no reason to include anything beyond that.

If an XML2RFC to new-format translator is possible and developed, it might be useful - but again, that cannot be a requirement. When this format was developed it was not picked as a requirement, so we shouldn't add it based on legacy support.

There can/should be a gradual transition, but that's not the same as a requirement to support a currently optional input format.

> What this proposal does not address is:
> 1) How traditional format would continue to be supported. 

FWIW, I cannot fathom why you would claim XML2RFC support is required and overlook this issue.


More information about the rfc-interest mailing list