[rfc-i] New proposal for "canonical and others"
paul.hoffman at vpnc.org
Sun Jun 17 11:48:12 PDT 2012
On Jun 17, 2012, at 11:36 AM, Brian E Carpenter wrote:
> 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.
Sorry for being dense, but I'm still not seeing it. How would a text file not be "durable and readable" for several centuries? What other type of file do you see as being more "durable and readable"?
>>> 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.
Ah, OK. We fully agree then. Both XML and HTML allow for explicit metadata in the file, depending on the profile chosen by the RFC Editor.
More information about the rfc-interest