Subject: RE: New GSSAPI V2 C-bindings draft

From: "Linn, John" <[email-masked]>
Date: Fri, 21 Nov 1997 13:52:49 -0500

John Wray writes:

>   I didn't change the description of the calling errors to require
> that they be
>   accompanied by GSS_S_FAILURE (or some other non-zero error status).
> I don't
>   have any objection to this, although I'm not sure how much benefit
> it
>   is, since the GSS_ERROR macro already includes the calling error
> fields.
> 
I'm also not too concerned here; I assume that any non-zero calling
error means, in effect, a failure before the GSS functional level can
even be invoked.

>   However, this change is similar to Martin's recommendation (which I
> like)
>   that we mandate the pairing of DUPLICATE_TOKEN/OLD_TOKEN with
> GSS_S_FAILURE 
>   or GSS_S_COMPLETE to distinguish between a fatal or informational
> condition.
> 
I also like Martin's context-independent approach at the result encoding
level. For completeness, it probably also applies to UNSEQ_TOKEN and
GAP_TOKEN, even though these are defined only for the per-message calls,
not for context establishment. Given the explicit statement that
sequencing failures are fatal during context establishment, I don't
think we need to consider complicating changes wrt CONTINUE_NEEDED,
which is also encoded in the C bindings as a supplementary status bit.

I don't believe that any current text in the high-level document makes
reference to the possibility that a GSS call may return more than one
major_status code as its result.  It's arguably reasonable, therefore,
that a caller might check a per-message call's return value for one of
the sequencing-related codes and, finding one, conclude that the result
wasn't also GSS_S_COMPLETE and, therefore, that no message buffer had
been returned and needed to be freed later.  To disambiguate, is it OK
and sufficient to add statements that DUPLICATE_TOKEN, OLD_TOKEN,
UNSEQ_TOKEN, and GAP_TOKEN stati may be reflected along with either
COMPLETE or FAILURE status, and that callers must also check the sense
of COMPLETE vs. FAILURE to decide whether results were successfully
returned?

>   This probably merits a bit more discussion as it's a change in the
> semantics 
>   of the error codes, at least wrt the context set-up calls.
> 
Yes.  For context establishment, we've excluded the prospect of a
success along with a sequencing error, so the effect would be that
COMPLETE && XXX_TOKEN, while syntactically representable, should never
occur.  If the impact is confined to the possibility that a caller might
interpret a FAILURE && XXX_TOKEN case as just a FAILURE, this loses some
information but seems perhaps tolerable. 

--jl

---

From: [email-masked]
Date: Mon, 24 Nov 1997 19:26:27 -0500

From: "Linn, John" <[email-masked]>
   Date: Fri, 21 Nov 1997 13:52:49 -0500

I suspect there's probably some non-trivial amount of existing code
which is currently doing:

	if (retval == GSS_S_COMPLETE)

Granted this is incorrect code; however, I think in order to avoid this,
in the C binding specification we want to use much more explicit
language about using the GSS_ERROR(x) macro.

   occur.

Yes, absolutely.

   If the impact is confined to the possibility that a caller might
   interpret a FAILURE && XXX_TOKEN case as just a FAILURE, this loses some
   information but seems perhaps tolerable. 

If the calling application follows this up with a gss_display_status, we
may not even lose information when it is reported up to the user.

						- Ted