[rfc-i] New proposal for "canonical and others"
hallam at gmail.com
Mon Jun 18 09:22:26 PDT 2012
What is so hard about constant copying?
It is going to be an inevitable feature of the cloud. We are going to
have to find ways to archive materials that are far more important
than RFCs which have been in digital format since forever in any case.
I am actually more concerned with the archives of the mailing lists
than the RFCs. They give the why and the when which are rather more
important than the what.
If people have lost the source documents of a spec then it is unlikely
to be of anything more than historic interest. If people have
forgotten how to ship bits about then they have almost certainly lost
interest in IETF like things.
On Mon, Jun 18, 2012 at 3:29 AM, Brian E Carpenter
<brian.e.carpenter at gmail.com> wrote:
> 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.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest