Subject: Java GSS: Major status codes and exceptions

From: Mayank Upadhyay <[email-masked]>
Date: Thu, 12 Aug 1999 15:16:55 -0700 (PDT)

On Thu, 29 Jul 1999, Linn, John wrote:

> ....  A GSS-level question arises here, which John
> Linn plans to investigate: in what (if any) combinations are different major
> status codes conformantly permitted to exist in conjunction with one
> another?

This was a concern about the exception model raised by Mike Eisler at the
Oslo meeting.  Included below is my interpretation of what 2078bis and the
C bindings document imply about this matter.  John Linn asked me to
forward this to the alias to confirm it.  Please reply if you disagree. 

Thanks,
Mayank

----------

We don't have an explicit mechanism to return two major status codes
simultaneously in Java GSS but we dont need it either based on the
requirements in the RFC. 

2078bis only mentions the sequencing related status codes (GAP_TOKEN,
DUPLICATE_TOKEN, etc ) as potentially being returned in conjunction with
one of COMPLETE or FAILURE. Morevoer, it mentions that during context
establishment a sequencing problem is always fatal and must be returned
with FAILURE whereas during the per-message calls the implementation can
return the sequencing status code with either COMPLETE or FAILURE. The
java bindings still allow the same thing to be achieved, although
differently. 

If the implementation wishes to return a sequencing state that is a
fatal error, it throws an exception with this sequencing error code
contained within the exception. 

If the implementation wishes to return a sequencing state that is
not a fatal error, but just informatory, then it does so in the
MessageProp structure associated with the per-message call.

Hence indicating a second COMPLETE/FAILURE code along with the sequencing
code is unnecessary.

Note that the "calling errors" defined in the C bindings are not an issue
in the Java platform. They are optional even within that document and may
be returned in some other platform specific way. Java has stronger type
checking when passing objects around and also has exceptions defined for
invalid parameters.

----

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]