Re: [kitten] RFC2743 errata 4251

[Jeffrey Hutzelman <[e-mail]>]

On Fri, 2014-12-19 at 18:16 -0600, Nico Williams wrote:
> On further thought, since context deletion tokens are obsoleted, and
> have been for a long time, we might as well say nothing about
> GSS_S_COMPLETE implying that the peer is done using its side of the
> security context.  The GSS_S_FAILURE case, however, still kinda leads to
> the caller being done.
> 
> OLD PROPOSED TEXT
> |      Though future GSS-API extensions may add new uses of asynchronous
> |      security context tokens and ways to process them, applications
> |      using the GSS-API version 2, update 1, should generally call
> |      GSS_Delete_sec_context() after calling GSS_Process_context_token(),
> |      when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE.
> 
> NEW:
> |      Applications should generally call GSS_Delete_sec_context() when
> |      GSS_Process_context_token() returns GSS_S_FAILURE.

FWIW, I agree with Greg that it's not reasonable to assume, or suggest
that applications assume, that all asynchronous context tokens are
deletion tokens or mean that the context is now dead.  So, the above
change is an improvement.

However, after reading this thread, I'm not convinced we need to give
applications any guidance about calling GSS_Delete_sec_context after
processing a context token.  Nico thinks that saying "generally" makes
it OK, but I disagree.  The word "generally" here isn't an effective
weasel word; it's a particle.  If you describe what the exceptions are,
you don't need it, and if you don't, then it doesn't do you any good.
Implementors are going to read the text as if the word wasn't there.


I think it is worth noting that if we start giving new implementation
guidance to applications in an erratum, people who read it will assume
it must be important and start doing that, because otherwise, why did we
go out of our way to publish an erratum?


The purpose of errata is to fix technical or editorial errors and
omissions in the existing spec.  They are not for changing the spec or
offering new guidance.  We should stick to doing the former, and leave
the latter for a new or updated document, if it's necessary.

-- Jeff