Re: [kitten] RFC2743 errata 4251

[[e-mail] (Martin Rex)]

Nico Williams wrote:
> I wrote this yesterday but neglected to click the submit button.  Just
> submitted:
> 
> http://www.rfc-editor.org/errata_search.php?eid=4151


I hate to do this (to you), but I'm "violently" opposed to this errata.

I believe you have misunderstood the meaning of the original text.

Quoting from your errata:

  Section 2.2.4 says:

   o  GSS_S_FAILURE indicates that the context is recognized, but that
   the GSS_Process_context_token() operation could not be performed for
   reasons unspecified at the GSS-API level.

  It should say:

   o  GSS_S_FAILURE indicates that the peer had an error consuming the
   last context token sent to it (when the local side must have been
   fully established but the peer hadn't yet been).  The minor status
   code provides error information from the input token.


You find similar descriptions for GSS_S_FAILURE semantics all over
the GSS-API specification _on_purpose_, and you _may_not_ remove that
meaning here.

You may at most add a hint that the minor_status(!!) that must
accompany a GSS_S_FAILURE major_status returned from
gss_process_context_token() may not just cover reasons that are
a "local matter" (i.e. implementation issue of the current gssapi
mechanism) but include reasons conveyed through an error token
from the remote side.  It will be impossible to define portable
behaviour to programmatically react to specific such reasons,
because what will be returned is not just a local issue, but
a remote plus local issue combined.


And Ben is right that GSS_S_FAILURE is explicitly supposed to include
situations of local resource shortage (no more memory, no more filehandles,
no more socket handles, whathaveyou).

Btw. any minor_status that conveys an error from a remote peer that
was carried in an error token ought to clearly say that this information
came from the remote peer (and is not a local error) in the textual
translation from gss_display_status().


-Martin