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: m...@petit-huguenin.org
Work: petit...@acm.org
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to