Mechanism extensions and the GSSAPI

Nicolas Williams Nicolas.Williams at sun.com
Mon May 3 14:19:58 EDT 2004


On Mon, May 03, 2004 at 01:14:25PM -0400, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> 
>     Nicolas> On Fri, Apr 30, 2004 at 10:21:20AM +0200, Love wrote:
>     Love> I though about this some time ago. I think you are missing
>     Love> two things if this api should go forward; ability list all
>     Love> options, options are specified oid.
> 
>     Nicolas> Agreed.
> 
> I think I disagree.  I'd rather the extension be specified at the shim
> layer not at the ioctl layer.  So the operation code is an internal
> matter for the implementation.  Thus I see no reason for it to be an
> oid.

An OID gets us a number of things:

 - reuse of OID set type and set operations, which would be useful for
   querying the set of extension types associated with an object,
   supported by a mech, etc...

 - some extensions may be generic, some may be mechanism-specific, some
   may be platform-specific, some may be implementation-specific, so we
   have a lot of namespaces to manage -- OIDs are good for this.

 - probably more that I can't think of atm.

Cheers,

Nico
-- 


More information about the krbdev mailing list