On Wed, 1 May 2013, Simon Wilkinson wrote:
On 1 May 2013, at 16:09, Benjamin Kaduk wrote:
Our control flow does not have a persistent connection, and the
client drives the loop using the GSSNegotiate RPC;
To all intents and purposes, we do have a persistent connection - the
opaques provide one. Also, an implementation can chose to regard all of
the GSSNegotiate RPCs received over a particular RX connection as part
of a single connection establishment. So, I'm not sure that this
argument is correct.
My worry about the description of the control flow isn't that it may
confuse implementors. I'm concerned because it explicitly forbids
behaviour that is required in order to support some multi-round trip
GSSAPI mechanisms. I would prefer that we have no description at all
rather than what is in the document at present.
Is this referring just to the case where gss_init_sec_context returns
GSS_S_COMPLETE but a nonempty output token? I believe this can be
remedied with the insertion of a single sentence, and has already been
pushed to my github repo.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
