[rfc-i] I-D Action:draft-rfc-image-files-01.txt
paul.hoffman at vpnc.org
Sat Sep 27 10:38:19 PDT 2008
At 11:46 AM -0400 9/27/08, John C Klensin wrote:
>Based in part on the discussions that went into the "image file"
>model, I believe that any system that involves the RFC Editor
>(or someone else) accepting additional files, posting them
>somewhere to which stable URLs could be generated, and then
>permitting normative references to them would open up all of the
>IPR issues again.
You can, of course, open up all of the IPR issues again if you wish.
I would prefer that you didn't because it is mindless hair-splitting.
Person A gives publisher R text T and image file X to publish. R
publishes either a single document that directly includes T and X, or
publishes a document of T that refers to a copy of X that is
published on R's web site. You may think there are substantial
differences in IPR for those two scenarios, but I disagree.
>But, based on experience with the IPR WG, I would
>predict that none of them would be resolved easily and
You have more experience than I do with that, thankfully. However,
from the experience that I have, predicting whether your proposal is
more likely to finish significantly sooner than mine or vice versa
>(2) Even if one ignores the above problems, I suggest that there
>is still a difference between having some image be "part of" a
>document versus having a normative reference to somewhere else.
>That difference becomes greater if the image is really a key
>part of the definition rather than a component of an explanation
>or example. Even normative references (as that term is used in
>the IETF and in the RFC series) usually point to things that a
>reader of a spec should already understand, might need a
>refresher one, or that provide context, not a key and original
>part of the definition.
There are plenty of instances in recent important standards track
RFCs and Internet Drafts that will become RFCs where normative
references are required in order to implement a protocol. For
example, one document might have a set of definitions that are
required for a protocol to be implemented, but the protocol itself is
in a different document. I believe that you would agree with me that
this is a reasonable linkage between RFCs for a protocol. I also
believe that this model can be easily extended to be normative
images, not just normative definitions.
>The figures/images contemplated by the
>image file proposal explicitly are intended to include such
>definitional material. IMO, that doesn't work with external
>reference links of the type you contemplate unless the RFC text
>is in HTML and the renderer automagically produces the images
We disagree. We both know plenty of implementers who can read one RFC
in one window and another one in another window when the second one
is required for the first.
>But, even ignoring the separate debate about
>primary-form RFCs in HTML, at that point one does't have
>references and links anymore but a proposal that is nearly
>identical with the "image files" one.
Indeed. That's why I didn't suggest HTML at all. To prevent similar
strawman proposals from being attributed to me, should I write up a
(very short) Internet Draft as a contrast to draft-rfc-image-files?
--Paul Hoffman, Director
More information about the rfc-interest