[rfc-i] Towards Consensus

Phillip Hallam-Baker hallam at gmail.com
Fri May 25 10:05:54 PDT 2012

On Fri, May 25, 2012 at 12:24 PM, Joe Touch <touch at isi.edu> wrote:

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

It is generally considered to be shorthand for 'what happens in the real

> > 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 IETF does not make laws. It does not have any plenary authority
whatsoever. Describing RFCs as being 'authoritative' is just piffle.

> > 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. Since nroff does not support metadata and offers a
subset of XML2RFC capabilities, it is clear which one has to be supported
through the transition period.

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

Nope, no metadata.

I see no need to support TXT in any role other than as an output format
offered when this is possible without corrupting the document.

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

We might drop XML2RFC at some future date. But I can't see we could do that

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

OK, what I am satying here is that whatever format we choose has to be
sufficiently like XML2RFC that it is possible to convert from one to the
other so that we don't need to change the production tools

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

I am not 'overlooking' the issue, merely stating that I don't see that as
an issue where there is the same degree of convergence.

My personal opinion is that future support for TXT should be the same as
that which HTML has received over the years. Others have different opinions.

Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120525/1464fc4f/attachment-0001.htm>

More information about the rfc-interest mailing list