[rfc-i] issue: canonical formats
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Wed Jun 6 02:36:07 PDT 2012
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.
More information about the rfc-interest