Ken Hornstein wrote: > > >> My only comment is that I find it ironic that these two paragraphs > >> appear in the same message: > >[...] > > >Why? > > "If you have to ask, you'd never understand". But I'll try to explain > anyway. > > Your first paragraph says, "I will fight to the death to prevent a > revision of GSS-API v2 that doesn't have gss_canonicalize_name()". > > Your second paragraph says, "If you want something standardized > you must be prepared for changes to the (initial) proposal, and I > hope the IESG still has the balls to enforce that".
Correct. GSS-API v2 has a de-facto maturity level of full standard. The reason why it formally is still at proposed is because no-one put in the effort to advance the documents formally (the majority of implementors never participated the IETF.) However there is plenty of independent implementation practice and code running smoothly for 6 years now. > > If you can't see the irony of these two statements together ... well, > I don't know what else to say. You don't seem to be aware how many work went into the existing standard. GSS-API v2 wasn't rubber stamped, it's one of the most refined and well-discussed analyzed and independently implemented protocol spec of the IETF. > > And I believe you are wrong about not being able to change GSSAPI v2. > Since RFC 2744 is only a Proposed Standard, it is still possible to > change it in a revision. Note that I really don't have an opinion > about gss_canonicalize_name() either way. CAT was never like any other IETF working group, likewise GSS-API v2. It's not opinions and voting that counts, it's about architecture, implementation experience and running code. As I said, the de-facto maturity level of GSS-API v2 is full standard. Formally, features that are not being used or that have proven to cause interoperability problems are candidates for removal. That is definitely not gss_canonicalize_name() -- and if you haven't noticed, the canonicalization is already required for gss_compare_name(). Likely candidates for removal (because hardly implemented, hardly used and proven to cause interoperability problems) are definitely channel bindings and QOP values. However, since these features can not be ripped out of the API spec without creating an entirely different API, they will remain more-or-less as "typed holes". However they will have to get warning signs that they're hardly implemented, have shown to cause interoperability problems, will likely have mechanism-specific side-effects when implemented by a gssapi mechanism and are therefore off limits for portable applications. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to [EMAIL PROTECTED]
