Subject: New GSSAPI V2 C-bindings draft

From: "John Wray, Digital DPE, 508/486-5210 21-Nov-1997 0859" <[email-masked]>
Date: Fri, 21 Nov 97 09:37:39 EST

I sent a new version of cat-ietf-gssv2-cbind to the ID editor yesterday.
There are only minor changes between this version and the previous one:

  Remove the suggestion that DUPLICATE_TOKEN may be returned by
  gss_unwrap/gss_verify for contexts that don't claim to support replay
  detection.

  Expanded the text around the use of GSS_C_NO_NAME with gss_add_cred, and
  fixed the incorrect references to gss_acquire_cred.

  Added a sentence saying that gss_release_buffer should be able to cope with
  any GSSAPI-generated buffer (including a zero-length one).

  Fixed a handful of typos.

I didn't include any changes for the following points that have been raised
on the list recently:

  I didn't make any changes about mandating the zeroing of pointers or 
  handles by the release calls (If we mandate this for new implementations, 
  we should probably make it clear that a V1 GSSAPI might not necessarily do 
  this, so an App that wants to run atop either version of GSSAPI can't 
  assume they get zeroed).

  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.
  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.
  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.

  Nor did I change any of the text relating to gss_inquire_context relating to 
  incomplete contexts - has this point been resolved?

John