Re: GGF's extensions to GSS in Public Comment

 > Maybe I'm misunderstanding, but wouldn't this mean that the application
 > has to make assumptions about the underlying mechanisms implementation
 > in order to get the variable correctly?

The specification is that the returned variable is feedable to putenv,
so to the extent that is a de facto standard, no.

Von

Wyllys Ingersoll writes (09:59 April 8, 2004):
 > Von Welch wrote:
 > 
 > > But for GSS mechanisms that don't have kernel support for their
 > > creentials stores and use environment variables, this isn't the
 > > case. A process might decide to clean up its environment for a number
 > > of reasons and accidentially effect the GSS mechanism's current
 > > credential store or fail to pass the meaningful env variable to a
 > > child process as in SSHD.
 > > 
 > > This is what led us to have a mechanism that allowed the GSS mechanism
 > > to tell the calling application that a particular env variable was
 > > meaningful to it so that a well behaved application could treat that
 > > variable appropriately.
 > 
 > Maybe I'm misunderstanding, but wouldn't this mean that the application
 > has to make assumptions about the underlying mechanisms implementation
 > in order to get the variable correctly?
 > 
 > > 
 > > You are right in that our use of environment variables was focused on
 > > a couple of specific mechanisms (GSI & Krb5) in which we were
 > > interested. I agree the approach does not generalize well to
 > > mechanisms that use other methods besides env variables.
 > 
 > I think that specifying the use of environment variables as an
 > interface for manipulating the configuration of the mechanisms
 > is a really ulgy solution.   Use of environment variables may
 > be acceptable in a particular implementation of a spec, but they
 > should definitley not be part of any standards document for a
 > generic interface such as this.
 > 
 > -Wyllys Ingersoll
 > 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]