[rfc-i] New proposal for "canonical and others"

[paul.hoffman at vpnc.org (Paul Hoffman)]

On Jun 17, 2012, at 2:10 AM, Brian E Carpenter wrote:

> Trying to up-level this discussion yet again, I believe that we
> haven't yet either clearly distinguished the hypothetical "canonical"
> format from the hypothetical "archival" format, or clearly
> established the requirements for each of them.
> 
> If the requirements came out to be identical, that would be
> excellent, but it seems unlikely to be the case.

Why? If the RFC Editor uses one base document as the origin for all versions that they publish, then that document is both canonical and archival. What were you thinking would be different?

> In the end, the canonical format may turn out to be an
> abstraction, and the real-world requirement is something that
> is functionally equivalent to the canonical format.

That seems.... obscure.

> By contrast,
> the archival format MUST [RFC2119] be some kind of physical
> analogue or digital representation that can be filed away in a
> library or museum.

Exactly. So why have it be an abstraction of some sort?

> Down level again, draft-hoffman-rfcformat-canon-others-02 seems
> to assume that XML is a stable format, unlike HTML.

A particular profile of XML is a stable format, yes. So's a particular profile of HTML, for that matter.

> I'm not so sure
> about that; we might have to regress another level and say that
> our format is defined in SGML (even if, in practice, it is based
> on a specific version of some dialect of SGML such as a current
> version of XML or HTML).

I would want to hear some good reasons for that before we went away from a definable profile of something that is well-understood today.

--Paul Hoffman