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

John C Klensin john+rfc at jck.com
Sat Sep 27 08:46:50 PDT 2008



--On Saturday, 27 September, 2008 13:30 +0100 Stephen Farrell
<stephen.farrell at cs.tcd.ie> wrote:

> 
> 
> Paul Hoffman wrote:
>> At 12:37 PM -0500 9/25/08, Stephen Nadas wrote:
>>> I have read this draft and I support this (imho) very good
>>> idea. I don't think there were any comments on -00.
>> 
>> There was a great deal of discussion about this last month
>> when the first draft was posted. See (currently)
>> <http://www.ietf.org/mail-archive/web/ietf/current/mail11.htm
>> l>
>> 
>> In particular, please see my comment at
>> <http://www.ietf.org/mail-archive/web/ietf/current/msg53066.h
>> tml>, in which I make a counter-proposal that makes no
>> changes to the current Internet Draft format and gives more
>> flexibility in the output.
> 
> Yes. I (and I recall others) also supported Paul's simpler
> approach. IMO draft-rfc-image-files-00 is over complex.

Paul,

Two issues arise with that suggestion (essentially to have the
RFC Editor maintain an archive of images and permit normative
references to them):

(1)  The community has made a long series of decisions about
intellectual property over the last several years.  Whether one
agrees with those decisions or not, their status wrt RFCs is
reasonably clear (since we continue to see debates on the IETF
list, probably only "reasonably" clear even now).  The
draft-rfc-image-files proposal is carefully designed to make the
images an integral part of the RFC, thereby avoiding any new IPR
issues and, perhaps almost as important, any new rounds of IPR
discussions.  

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.  Who do they belong to?  Who has the right to
reprint or reuse them and do they have the right to publish the
copies in modified form, either intrinsically or after asking
permission?  If permission needs to come from the IETF Trust,
what guidelines do they follow in granting it?  Do the IETF's
patent disclosure requirements apply to such filed and
referenced images?  Is boilerplate required on a per-file basis
and, if so, what should it be and where does it go?

I think some of those questions have easy answers; others are
harder.  But, based on experience with the IPR WG, I would
predict that none of them would be resolved easily and
painlessly.

And, if one considers total complexity of a given proposal --
draft-rfc-image-files more or less as it stands versus your
outline with getting the IPR issues sorted out and incorporated
included-- it is not even clear to me that the former is, on
balance, less complex.  It could certainly be deployed more
quickly if the community were interestd.

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

regards,
     john



More information about the rfc-interest mailing list