At 1:20 AM +0100 5/17/06, Bill de hÓra wrote:
I'm -0 this becoming a Proposed Standard. I think this is really cool, has room for interop problems, probably has security issues, and thus is arguably premature/innovative and could be considered informational.
These are not reasons to make something an Informational RFC. In the minds of developers, there is no difference between Informational and standards-track RFCs. The IETF's differentiation between types of RFCs has always been confusing, but that is not a reason for us to niggle on a particular document.
This document describes an extension to an existing standards-track document: it should either be on standards track or it should not be an RFC.
If the document has "room for interop problems", and/or security issues, they should be stated so that the sponsoring AD, and the IESG as a whole, can decide whether or not the document is ready to be an RFC, regardless of the type of RFC it will become.
--Paul Hoffman, Director --Internet Mail Consortium
