[rfc-i] Towards Consensus
hallam at gmail.com
Sat May 26 08:22:20 PDT 2012
In the unlikely event that presentation is going to affect semantics,
any discussion should use the presentation format least likely to
result in ambiguity or error.
That is HTML or PDF/A, it is not plaintext format which is the least
I agree that we frequently refer to an old RFC to determine what
should happen. I just find the idea that the RFCs are so excellent and
precious that arguing over which one is the authoritative to be rather
The only relevance to the discussion here would be if someone wanted
to insist that the plaintext version had to be the authoritative one.
Which would of course serve no other purpose than to prevent use of
any of the features of HTML that make it more effective.
On Fri, May 25, 2012 at 1:10 PM, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:
> On Fri, May 25, 2012 at 11:46:34AM -0400, Phillip Hallam-Baker wrote:
>> 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.
> I fully disagree with the claim that it is nonsense, and I fully
> disagree with the claims about tradition.
> RFCs form an archival series. That's why they're not allowed to be
> updated. For that reason, there must be one formally-blessed
> publication format that is the one that is to be consulted when there
> is a dispute about the meaning of a passage. Otherwise, it is
> logically possible (unlikely, but logically possible) that a bug in a
> transformation for presentation could introduce a difference in
> meaning. (The most obvious way this could happen is incorrect
> comment-line handling, where the source document includes a comment
> line that mistakenly ends up in the document or processes as a comment
> something that was in fact normative text. But it doesn't matter how
> it happens, as long as it is a possibility.)
> As for tradition: more than once in the past few years in DNSEXT we
> have been faced with disputes over what behaviour ought to be, and
> differences among different deployed software. The way we resolve
> those things is often to compare them with the text (and then
> sometimes, to decide the RFC was wrong, in which case the software in
> question is still strictly speaking non-conforming to that RFC).
> Some of your other propositions I'm not sure I agree with (the xml2rfc
> stuff I have no strong feeling about), but there must be exactly one
> thing to which we can all appeal in the event of a dispute. If we
> want to call that "canonical", "basic", "fundamental", or "BillyBob's
> Favourite Format", I don't care.
> Andrew Sullivan
> ajs at anvilwalrusden.com
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest