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

[brian.e.carpenter at gmail.com (Brian E Carpenter)]

On 2012-06-17 19:27, Paul Hoffman wrote:
> 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?


Archival has to be durable and readable for several centuries. That is
a stronger constraint than I think will apply elsewhere in our world.

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

Yes, maybe - but the point is that we need to define a set of
metadata requirements that can be explicit or implicit in the actual
file; the implicit metadata are only present in the abstraction.

I would prefer all metadata to be explicit, to avoid this problem.

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