Re: [Rswg] Archive format

["Martin J. Dürst" <[e-mail]>]

On 2022-07-29 12:51, Mark Nottingham wrote:
> I think it depends on what properties we're assuming 'archival' and 'canonical' documents have.
> 
> In my mind, the closest thing to stable has always been the textual representation. The HTML representation changes with e.g., stylesheet changes; the PDF representations sometimes need updating; and as we see, even the XML vocabulary needs to change over time. All of them seem to evolve in such as way as to not change the textual representation in any meaningful way (for some definition of meaningful that probably features whitespace pretty prominently).
> 
> Just food for thought...

Yes indeed. As network engineers, we tend to care a lot about the bits 
on the wire, and so we care a lot about the bits in an RFC. But an RFC 
isn't really bits, it's text. And I don't mean text in the sense of 
ASCII (or UTF-8) text here, but text in the sense of words and sentences.

White space features prominently in there if it's relevant for layout 
that affects meaning, but otherwise it's pretty irrelevant. So is most 
of the CSS styling for the HTML.

Of course, when you start to be sloppy with the bits and bytes, this may 
eventually lead to sloppiness with the textual content, and so we 
shouldn't be sloppy with bits/bytes/markup/... But we shouldn't deal 
with it as if it were the holy grail.

On 2022-07-29 06:48, Brian E Carpenter wrote:
 > On 29-Jul-22 01:56, John C Klensin wrote:

 >> Not speaking for Brian, but there might be at least two reasons:
 >>
 >> (1) The very fact that the vocabulary / schema seems to be
 >> evolving rapidly to accommodate problem fixes and additional
 >> features is problematic from the standpoint of an archival
 >> format that was expected to be completely stable.
 >
 > Exactly. As I understand it (and I have not looked at the details),
 > RFC 8651 and RFC 9286 use different xml grammars. This makes any
 > claim of a stable archive format dubious. Imagine trying to explain
 > that to a jury under hostile cross-examination as an expert witness.

[IANAL] First, we have to distinguish between a stable (e.g. bit-by-bit, 
or at whatever other level, see above) archival version of a single RFC 
or a range of RFCs and a single stable archive format. Of course having 
the later is desirable, but lawyers will only be interested in the former.

Second, even for the former, if there are versions that differ 
bit-by-bit but have the same textual contents, lawyers (and the court, 
and the jury) will be interested in the textual contents and not in the 
bits, unless the difference in the bits somehow is potentially affecting 
the meaning of the text. (*) So again, we should be very careful about 
what we do, but bringing up hostile cross-examination when discussing a 
stable archival format is a red herring.

Regards,   Martin.

(*) I was involved in a (court, although it didn't make it to court 
because the parties settled early) case where white space was actually 
relevant. I was deposed as the author of 
https://www.ietf.org/archive/id/draft-duerst-dns-i18n-00.txt and its 
updates, because a company had managed to get a patent on it, and that 
patent had ended up in the hands of some patent troll company which was 
then suing a company that used i18n domain names.

The defendant's lawyer showed my page 6 of 
https://www.ietf.org/archive/id/draft-duerst-dns-i18n-02.txt, 
in particular the table on that page, where the data columns are off 
from the column headings. (The -01 version doesn't have the problem.) I 
don't remember exactly, but I guess I apologized for my sloppiness.

The lawyers also showed me the patent itself, which had the same column 
shift. I expressed surprise at that, because for everybody who had an 
idea about what was discussed in the draft, it should have been obvious 
that the columns were off; that this wasn't corrected in the patent 
seemed to indicate that the people writing the patent didn't really 
understand what they were talking about.