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.