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@xxxxxxxxxxxxxxxxxx Work: petithug@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf