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

Brian E Carpenter brian.e.carpenter at gmail.com
Mon Jun 18 00:29:41 PDT 2012

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

The evidence is that acid-free paper and the right kind of ink are
very durable (centuries); whereas all digital storage media that I'm
aware of have a lifetime measured in decades without regular re-copying.
Format details are largely irrelevant to this aspect.

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

I think so, whereas unannotated plain text doesn't, and neither does
a containment-free markup.


More information about the rfc-interest mailing list