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 Sun, Sep 13, 2009 at 12:41:08PM -0700, Love Hörnquist Åstrand wrote:
> 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.

> 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.)

> same goes for gss_get_name_attribute()

What same?

> Most functions does not talk about memory management, is buffers  
> released or not ?

All buffers must be released.

Nico
-- 

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