At 12:39 PM -0500 3/5/07, John C Klensin wrote:
--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> wrote:
At 8:53 AM -0800 3/5/07, Bob Braden wrote:
*> FWIW, I don't think we want to start bouncing specs
because they *> don't pay homage - in this case all the
similarities are probably *> the only obvious ways to add
authorization tokens to a TLS *> handshake. Such downrefs
to dead documents would anyway add yet *> more cruft to the
RFC process, so let's not.
*>
*> S.
*>
s/cruft/integrity/
How does adding a downref to a dead document add more
integrity to the RFC process?
Independent of the merits in this particular case, it provides
history and context.
Fully disagree. A reference to a dead document that the reader cannot
find directly provides no histor nor context. A diligent reader might
use Google et. al., to search for the title, but they are then
possibly confronted with documents with the same name and no way to
know which the author meant. That is neither good history nor good
context.
To be clear: downrefs to living documents that can identified by name
is clearly a good thing, but downrefs to dead documents reduces the
credibility of the RFC process because typical readers will ask "why
can't I find this old Internet Draft" and then get sucked into the
the vortex of the debates about the IETF keeping a public archive of
old documents.
We have learned, or should have learned,
two things over and over again:
(1) Failure to provide context and a track through
rejected and alternative suggestions results in "new"
proposals to try the same things again, usually from
people who had no idea about the prior work.
That is not fixed with a reference to a dead document.
(2) Providing good documentation that recognizes the
origins of an idea and its date, even if there were some
changes from the original version, can be very helpful
in defending our work against patent vultures who try to
make filings on work that the IETF has had under
development for some time.
That can be done much more effectively by other mechanisms that cause
less confusion to someone reading an RFC than a reference to
something that they cannot get their hands on.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf