Re: KITTEN BOF at IETF 60?

"Douglas E. Engert" <[email protected]> Wed, 24 Mar 2004 13:19:35 -0600
Newsgroups gmane.ietf.cat
Message-ID <[email protected]>

Greg Hudson wrote:
> 
> On Wed, 2004-03-24 at 09:08, Douglas E. Engert wrote:
> > Some situations which need to be addresed:
> >
> >  o application may wish to use one thread model, but GSSAPI
> >    implementation is using a different model.
> 
> In the long run, this is like saying "an application may wish to use one
> stdio implementation, but the GSSAPI implementation is using a different
> one."  There's just no point in adding complexity for this purpose.

I think we agree. I don't want to get into this situation, I want to 
avoid it, by possibly saying only "native" threading is supported. 
In the past there have been quite a few competing thread implmentaitons.
The DCE threads comes to mind. DCE has Kerberos GSSAPI implementation. 
   

> 
> In the short term, you're also deluding yourself if you think you can
> provide good support for non-standard threading implementations.  libc
> functions, like gethostbyname(), already make use of the native
> threading primitives.  See
> http://www.imc.org/ietf-sasl/mail-archive/msg01009.html
> for more discussion on this point.
> 
> >  o Applicatin may wish to use multiple mechs but the mechs
> >    use differnet thread models.
> 
> ... which is why platforms should provide one standard implementation
> (perhaps with multiple APIs, like on Solaris, but they must
> interoperate), and all libraries should use it.  I believe platforms are
> pretty much all doing their side of the job correctly at this point.

Yes I like the Solaris mechglue, which really requires GSSAPI to be
as Generic as possible, so as an application will never need to 
make mech specific implementation calls to store a delegated credential
for example. 
 

> 
> > Any thoughts on doing something like OpenSSL does with callbacks for threads?
> 
> I think OpenSSL and cyrus-sasl went in the wrong direction here.  What
> they do is really unfriendly to callers who are themselves thread-safe
> libraries.
> 
> If one is dead-set on providing callbacks for non-standard thread
> implementations, a better model is glib's, where specifying alternate
> thread callbacks is optional (and rarely used).

I am not set on it, just bringing up the issue. OpenSSL is used internaly
by may applicaitons and some gssapi implementations.  

-- 

 Douglas E. Engert  <[email protected]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]