Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt



On Monday 14 September 2009 07.11.24 Nicolas Williams wrote:
> On Sun, Sep 13, 2009 at 12:41:08PM -0700, Love Hörnquist Åstrand wrote:

First of all: thanks for the review which you obviously did!

> > name_is_MN is an output variable, the c-bindings define it as an "int"
> > which provides little chance of "out-ness"
>
> A typo.  Thanks.
>
> > I really dislike the modifying name attributes, why is that interface
> > needed (usecase ?)
>
> It's not about modifying names but about making assertions (or asking
> that an authority vouch for them).  You first import a name, then set
> the name attributes corresponding to the assertions you wish to make,
> then you acquire a credential, then you use the credential.
>
> > The *more trick sucks but I can live with it, it assumes names do no
>
> We can always add more set types.  I'm not fond of the idea of adding
> set types, but now that gss_buffer_set_t seems to be here to stay, I
> think I'd give in.

gss_buffer_set_t it is then unless people scream bloody murder at it
fairly soon

>
> > change and that items are iteratable, it also makes mech glue life hard.
>
> Can you explain the last part?  The *more thing is not thread-safe,
> that's for sure (though it fails in safe ways).
>
> > GSS_Map_name_to_any, the type should be an OID, strings are not used
> > anywhere else and its painful to use, its if really a strings, make it
> > a "const char *" in the c bindings.
>
> I'd be happy with a const char *.  I'd also be happy dropping this API.
> (I'd rather OSes have APIs like our gsscred_name_to_unix_cred, where the
> compiler can check types, than that we defeat type checking.)
>

I've never been comfortable with this API - it feels difficult to specify 
property. I'd be in favor of dropping it.

> > same goes for gss_get_name_attribute()
>
> What same?

+1

>
> > Most functions does not talk about memory management, is buffers
> > released or not ?
>
> All buffers must be released.

I guess it doesn't hurt for us to say so explicitly though.

	Chers Leif



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.