[rfc-i] I-D Action:draft-rfc-image-files-01.txt

Paul Hoffman 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
>painlessly.

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 
seems silly.

>(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.

Fully agree.

>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
>inline.

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
--VPN Consortium


More information about the rfc-interest mailing list