On 2010-09-09 11:25, Richard L. Barnes wrote: >> Finally, we are an open community encouraging a diversity of views, and >> it's sometimes necessary (and often desirable) to publish material from >> the community that meets none of the above criteria. Hence the >> Independent stream of RFCs. As everyone should know, the independence >> of the Independent stream is now guaranteed by a much more robust >> process than before (RFC 4846 and RFC 5620). Since RFC 4846 gives a >> complete explanation of why the Independent series exists, I won't >> repeat it here. > > Echoing somewhat Eric's original point -- we have the web now. There > are a multitude of fora in which material that doesn't meet the above > criteria can be published. Why does it need to be part of the RFC > series, other than the fact that we've always done it? In one word: archival. In several words: systematic archival rather than the vagueness of transient URLs and search engine caches. Obviously, that presupposes a judgment that the document is worthy of archival, which is why there is an editor and an editorial board. Brian > > I fail to find any of the justifications in RFC 4846 all that > persuasive. Choosing a few examples: > > o Discussion of Internet-related technologies that are not part of > the IETF agenda. > o Critiques and discussions of alternatives to IETF Standards-Track > protocols. The potential for such critiques provides an important > check on the IETF's standards processes and should be seen in that > light. > o Informational discussions of technologies, options, or experience > with protocols. > o Technical contributions (e.g., RFC 1810 [RFC1810]). > > These discussions happen all the time, all over the Internet. My > favorite recent example: > <http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars> > > One venue more or less for these discussions isn't going to make a huge > difference, and using the RFC stream for them simply causes confusion as > to what's a "real" RFC. > > o Informational publication of vendor-specific protocols. > > Nowadays, vendors have web sites that describe their protocols. See, > for example: > <http://code.google.com/apis/gears/geolocation_network_protocol.html> > > --Richard > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf