On Thursday, September 07, 2006 07:07:51 PM -0400 John C Klensin <john-ietf@xxxxxxx> wrote:
However, 2195 is not, itself, a SASL method and there is nothing in the procedural rules as I understand them that permits the SASL WG to de-standardize it (you could write any of several styles of document that would designate it as "not recommended" or even "historic" but such documents had best be in your Charter and Last Called as doing that).
To the extent that SASL is the successor to the original extensible authentication framework contained in IMAPv4, yes, CRAM-MD5 is a SASL mechanism. The cross-references don't explicitly point out that RFC2222 obsoletes RFC1731, but it seems clear that was the intent.
Now, suppose someone comes along who _likes_ the non-SASL incarnation of CRAM-MD5 in 2195. Let's call this hypothetical person "nobody" to avoid casting aspersions on Frank. Nothing in our current procedures prevents him, at any time, from preparing an interoperability report on 2195-specified CRAM-MD5, pointing out that there are many deployed interoperable implementations, and asking that 2195 be reclassified (or a 2195bis be published) as a Draft Standard.
Well, he could ask that 2195 be advanced as-is, but I would expect such an effort to fail, as that version has turned out to be somewhat underspecified. Multiple interoperable implementations is not the _old_ criteria for advancement; it is necessary but not sufficient(*).
Given that the SASL WG has an explicit charter item to produce a revised TS for CRAM-MD5, with RFC 2195 as a starting point, I would expect any effort to do so outside of that WG to meet with very strong resistance. As Kurt has noted, the WG is nearly finished its work on that item, and the resulting draft will be in Last Call soon.
The working group decided, due to a variety of considerations, not to pursue publication of the new document on the standards track, and instead to ask that it be published as Informational. However, the decision as to whether to publish that document and what status to assign it belongs to the IESG, not the working group. IMHO, an argument that it should be assigned a status other than that requested by the working group would be an appropriate subject for a Last Call comment.
If "nobody" were so
inclined, I would expect him to protest any effort on the part of the SASL WG to deprecate 2195 itself
Why? That working group's charter clearly includes an item to produce an updated specification for CRAM-MD5, and it seems obvious that the intent is that such a new specification obsolete RFC 2195 (if it's not obvious, that's a bug in the charter; certainly everyone participating in the work has understood that to be the intent).
(*) I think this is perhaps the crux of the matter. I do not believe that every old specification should be advanced along the standards track simply because it has been around a while and has multiple implementations. Advancing a specification to Draft Standard sends the signal that the IETF thinks the specification is a good idea and that people should deploy it. Protocols for which that is not the case have no business advancing toward the status of Internet Standard, *even if we thought they were good ideas when they were written*.
-- Jeff _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf