Henning Schulzrinne wrote:
I admit that I'm no friend of additional I-D sections, as they easily
generate into boilerplate and "make work" projects. If the goal, which
does not seem stated, is to acknowledge the contributions of
implementations in improving a standards document, we already have a
mechanism for that, namely the customary acknowledgements found in most
RFCs. I don't think anybody would object to saying something like
"The authors gratefully recognize the efforts of Joe Programmer, whose
XYZ implementation of early versions of the draft helped to remove
useless crud from the spec."
[well, maybe not quite verbatim like that.]
We can never hope to acknowledge all implementations in any event; for
example, many are done by students in classes, and are never released
(and that's a good thing...). It seems much more useful to capture
implementations on WG-related web pages; after all, the value of
implementations does not step when the I-D hits the RFC editor's desk.
We also certainly don't want to put yet more hurdles into the path of
getting drafts published. Does the RFC editor have to verify the URLs
and that they still exist? Do we worry about advertising pages and
implementations that turn out to be malicious? I'd really rather not
have to deal with an RFC where a domain of a fledgling open-source
project was taken over by a malware distributor.
That's a good point. The reference to the code is needed only until
the publication as RFC, so an URL does not need to be valid after
this - the subsequent need for two implementations for Draft
Standard is a completely different problem that have nothing to do
with my proposal. So I will modify the draft to say that the URLs
have to be removed before publication as an RFC.
--
Marc Petit-Huguenin
Home: marc(_at_)petit-huguenin(_dot_)org
Work: petithug(_at_)acm(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf