[rfc-i] issue: canonical formats

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Wed Jun 6 02:36:07 PDT 2012

Hello Brian,

On 2012/06/06 16:06, Brian E Carpenter wrote:
> (off list)

That didn't seem to work as intended.

> On 2012-06-05 12:26, Martin J. Dürst wrote:
> ...
>> We (both the list and Heather with input from IETF legal) have come to
>> the conclusion that exact formatting isn't an issue as long as the
>> content is the same (which is a technical problem and so we should be
>> able to deal with it).
> But that's just the problem. If there's a PDF version and an ASCII
> version (just to refer to today's reality) and there is a technical
> difference between the two (originally caused by human error),
> which one counts, ten years later in court?

In the case I mentioned, there was no technical difference whatsoever. 
There's only one way to interpret the draft that makes sense. It's not 
easy to generalize, but I'd guess that most accidental formatting 
troubles would fall in the same category. (Otherwise, we might be able 
to delegate the writing of RFCs to a bunch of monkeys.)

> I don't see how we can "deal with that" except by stating which one
> is valid.

If we have a canonical version upstream, we should assume that that 
version contains all the necessary information (markup if necessary) to 
make the decision.

> And as Martin's story of two I-Ds and a patent seems to show,
> even formatting differences can be relevant.

[I tried to be pretty polite and careful in my last mail, but I'll be a 
bit more direct here.] The formatting differences were *only* relevant 
in the sense that they created an additional indication showing that the 
guys who wrote up the patent mostly just copied the ID, without much 
care, and that on top of that, the patent examiner probably didn't pay 
much attention either. To everybody who looked at documents, that should 
have been quite obvious anyway.

[I have to admit that the patent also contained some original 
contributions, mainly: 1) translation from "IETF English" to 
"Patentese"; 2) Adding some language about context/machinery in 
accordance with "Patentese", including a diagram; 3) A second example; 
4) The idea to potentially use more than one 'synthetic' root (I got 
shot down by most DNS practitioners just for proposing one of these).]

[The glitch was not on purpose and unknown, but in some ways, it was 
similar to what one often hears about publishers of maps and other 
essentially factual material: They (apparently) include little glitches 
and on-purpose errors to be able to trace copying of their material.]

> So the argument that
> automatic reflowing doesn't matter is unconvincing to me.
> I remain convinced that we need to state which version is canonical.
> That doesn't mean I'm against reflowable formats, etc., for
> convenience. It's just that there needs to be a reference version.

The W3C has been using reflowable formats exclusively for more than 15 
years now. I don't know in how many legal cases some of these documents 
were relevant, but I haven't heard of any case where there was a 
problem. The main point is to identify material that can't be reflowed, 
but that's extremely well established in HTML as already discussed.

Also, at the W3C, there's no problems with authors signing off on 
publications of reflowable material, but that's also because there is 
much less that the publication staff actually does.

Regards,   Martin.

More information about the rfc-interest mailing list