Mechanism extensions and the GSSAPI
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
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.
More information about the krbdev