On Wed, Mar 10, 2004 at 09:18:11PM +0100, Martin Rex wrote: > Sam Hartman wrote: > > > [Martin, yes I know you would object very strongly to dropping > > gss_export_name. I'm fairly sure there are enough of us who want to > > revisit the issue that it is important to include in the charter. I > > fully realize that we do not yet have any consensus for any specific > > change.] > > Fortunately you cannot change GSS-API v2, and I will do all that I can > to prevent a spec from entering the standards track that calls itself > a revision of GSS-API v2 does not have gss_canonicalize_name() and > gss_export_name() fully backwards compatible with current GSS-API v2.
I myself have no intention whatsoever to change or remove either gss_canonicalize_name() or gss_export_name() or the format of exported names. I'm too busy for now to fully engage in any debate in this area and, frankly, I don't care to get into this at all, as I don't think these functions need any changes -- clarifications at most. I'm not sure what you mean by name games, but I'm guessing that you don't like the desired names (both, of credentials and the requested target name in GSS_Init_sec_context()) to differ from what is returned by GSS_Inquire_context(). > > * The Global Grid Forum has advanced several proposals for extensions > > to GSSAPI. KITTEN will consider these proposals and see if there > > are mechanisms acceptable to the IETF for accomplishing the same > > goals as these proposals. > > Haven't looked at those lately. When I looked at it a few years ago > they looked like dirty hacks due to insufficient abstraction. I agree. > > * Mechanism implementers have complained that GSSAPI is too > > complicated and thus they prefer to write SASL mechanisms rather than > > GSSAPI mechanisms. KITTEN will produce a document describing how to > > write a GSSAPI mechanism specification. > > Well, there is a SASL-scheme to use GSS-API mechanisms for performing > the actual work. I don't see a problem. Sam means that designing GSS-API mechanisms is too hard, so folks are designing SASL mechanisms instead when we'd all really rather they design GSS-API mechanisms. Sam is proposing, and I second this, that a document be written offering guidelines to mechanism designers. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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]
