Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd)

[Benjamin Kaduk <[e-mail]>]

On Wed, 20 Nov 2013, Greg Hudson wrote:

> On 11/20/2013 05:45 PM, Benjamin Kaduk wrote:
>
>> The send_token()/receive_token() routines are not very good examples.
>> It is probably better to rewrite them to use sendmsg/recvmsg with
>> socketpair, which also eliminates the need to add framing with the token
>> length.
>
> I think the RFC should only include the do_initiator() and do_acceptor()
> functions.  The sample code does not need to compile and run, only
> demonstrate how the API should be used and be a reasonable starting
> point for cut and paste.  Adding questionable framing code runs the risk
> of people actually using it, and adding solid framing code would be too
> much verbiage.  release_buffer() is needed, of course, unless we get rid
> of it somehow (perhaps by assuming that receive_token will free what's
> already there, and then just calling free() in cleanup).

How would you feel about having stub routines send_token()/receive_token() 
which are just comments indicating what an implementation of them should 
do?  My original intention in including these routines was in fact to have 
sample code that would compile (and maybe run, if the mechanism supports 
nameless initiators), to make it as clear as possible what was necessary 
for an application implementation.  Subsequent discussion has convinced me 
that (as you say) including an actual implementation of those routines is 
unwise, but I would still like to be as explicit as possible what is 
necessary for applications.  A stub routine with comment seems like it 
could be more clear than just a call to an unimplemented routine with an 
argument 'readfd' or 'writefd'.

I will still have an implementation locally, so that I can test the sample 
code -- it wouldn't do to include buggy sample code.

> I would rather see anonymous handled as a runtime parameter than an
> #ifdef, which is distracting.

We had previously discussed having separate sample code for the anonymous 
and non-anonymous case, but as I was writing it seemed like the 
differences were so small that duplicating everything was not worth it. 
However, I still wanted to make clear that if an application did not care 
about supporting anonymous initiators, the code in question could be 
removed; using a preprocessor conditional seemed the clearest way to do 
so.  I don't think the sense of "this code can be entirely removed" is as 
clear with a C-level conditional.

> "if ((ret_flags & GSS_C_ANON_FLAG) != GSS_C_ANON_FLAG)" can be
> simplified to "if (!(ret_flags & GSS_C_ANON_FLAG))", and similarly
> elsewhere.

This is true.  If you think it is more clear to write it that way, I guess 
I can change it for the next revision.

-Ben