Subject: RE: Java-GSS Manifesto

From: "Linn, John" <[email-masked]>
Date: Tue, 6 Jul 1999 13:05:44 -0400

CAT/Java fanciers:

There's been a lot of commentary exchanged on this thread, but it's not
clear that it's yet converging towards consensus.  I'd encourage others
within the WG who are interested in the progression of GSS Java bindings to
contribute their thoughts into the discussion, to support a decision about
what sort of approach to pursue. 

From a "10,000 foot" level, it seems like most of the divergences between
approaches fall into the following areas:

- means for locating mechanisms and/or implementations
- means for supporting operations within multi-mechanism environments
- issues about name types
- approach for returning results
- address representations

Which of these are most critical, and how should they be resolved?

--jl

==========================================================================
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]

---

From: "Jack Kabat" <[email-masked]>
Date: Wed, 7 Jul 1999 11:43:23 -0700

Hello Everyone,

Here are my thoughts on the current state of the Java bindings.

I feel that as of the latest revision of the draft, Mayank and I have
addressed the major feedback received from the group. We re-architected the
API to add interfaces and make them the core of the API. The concrete
classes have been transformed into mere wrappers for the interfaces. We have
taken the input regarding the lightweight requirements to meet the needs of
applet writers and differentiate in our draft between system and bundled
implementations. What remains now seems to be just a few API details which
Michael Smith does not seem to agree with us on. I feel that some things can
be solved in more then one approach, and this seems to be what we have here.
I think that for most of these items, we can just agree to disagree with
Michael.

Let me now try to address each individual point presented in John's email.

1) means for locating mechanisms and/or implementations
We have chosen the Provider approach for the mechanisms to achieve this.
Note that our specification allows the implementation of a set of GSS-API
interfaces (IGSSFactory, IGSSName, IGSSCredential, IGSSContext) which
comprise a functional Java GSS-API without using the Provider model at all.
We also specify a system wide GSS-API framework which takes full advantage
of Java's Provider architecture. The comments presented by Michael Smith do
not show any technical reasons for his dislike of this approach. Provider
class is lightweight and can be thought of as a set of environment variables
packaged inside a single class. But again, one can implement our
specification without ever using the Provider specification.

2) means for supporting operations within multi-mechanism environments
I think most of the comments from Michael Smith on this subject (don't mean
to pick on you here Michael, but you have been the main person driving these
objections) have been made with certain implementation assumptions about our
specification. When using the interfaces we have defined, one can avoid any
intermediate layer that Michael has referred to when discussing this
problem. Again, I think after reading the current version of the draft you
should be able to see that any intermediate layer can be avoided if one is
really concerned about this (and I question the motivation for this, but
that's irrelevant here).

3) issue about name types
This has been discussed several times on this list and I see this as again a
minor item that we should just agree to disagree about. We have pros for our
method and cons for yours, and vice versa. We have not found any of the
arguments presented by Michael compelling enough to favor his approach, and
have been able to point out some fundamental reason why we don't think this
is a viable option.

4) approach for returning results
Again, subjective comments in which Michael thinks his approach provides
simplicity while we think ours is superior. We have been able to capture the
level of error reporting equal to that of the C-bindings and feel this will
meet the needs of the users and developers. Again, let's agree to disagree
and put our energy into moving this specification forward.

5) address representations
It is true that we only formally define the InetAddress as an argument to
channel bindings. We feel this will satisfy the needs of 95% of the users
and bloating the API does not seem justified. We also allow the usage of a
byte array which could be any date supplied by the caller. Thus, anyone
using an address other the InetAddress could convert it into a byte array
and interface into the channel bindings in that manner. This will
accommodate the other minority of users without having ill effects on the
rest.

Regards,

Jack

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Linn, John
> Sent: Tuesday, July 06, 1999 10:06 AM
> To: [email-masked]
> Subject: RE: Java-GSS Manifesto
>
>
> CAT/Java fanciers:
>