Subject: RE: GSS: SPI and API

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Oct 1999 10:11:54 -0700 (PDT)

> I thought we
> came to agreement on this?

indeed. i thought we came to agreement on everything in Minneapolis.

	-mre

==========================================================================
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: Mon, 25 Oct 1999 08:46:27 -0700

Hello,

Below are additional comments to Mayank's reply.

Regards,

Jack

> -----Original Message-----
> From: Mayank Upadhyay [mailto:[email-masked]]
> Sent: Friday, October 22, 1999 6:04 PM
> To: Michael Smith
> Cc: [email-masked]
> Subject: Re: GSS: SPI and API
> 
> 
> Brief comments below...
> 
> -Mayank
> 
> On Fri, 22 Oct 1999, Michael Smith wrote:
> 
> > concrete classes vs. interfaces. If I recall correctly, we 
> > decided (at Minneapolis, was it?) that the binding spec 
> > itself should consist of a repertoire of interfaces 
> > rather than concrete classes. J & M have mostly complied 
> 
> We had decided this for the Name, Credentials and Context 
> classes only. We
> had also decided we had to have a standard way for instantiating
> implementations for these. 
> 

Having interfaces works well, but one needs a well defined
method of instantiating these objects. A standard method
of accomplishing this in Java is through a factory class,
which is what we have followed. In the current draft update
we modified the static methods of the factory class with
instance methods.

> 
> > with this, except for their "factory class", GSSManager, 
> > which they continue to specify as a concrete class.
> 
> org.ietf.jgss.GSSManager will be the standard factory class 
> for these top
> level interfaces. Its easy, logical, and less confusing to developers
> since you are introducing new provider based factories in the SPI.
> 
> 
> > J & M, however, have defined GSSManager as a 
> > concrete class incorporating some mechanism 
> > management functions. I have two problems with 
> > this: 1) these functions make no sense in the 
> > context of monolithic implementations, which is 
> > certainly one class of implementations we want 
> > to support, 
> 
> Applications don't want two separate API's for monolithic and
> non-monolithic implementations. Our GSS-API has the bare 
> minimum addition
> that can *optionally* enable the implementation to be non-monolithic.
> 

Are you referring to the three methods (set/get provider)
in GSSManager? These are used to set any provider
preferences to the JGSS implementation. These methods
need to be specified at the JGSS layer since applications
programs will be insulated from any GSS internals.
Also, these methods are clearly labeled as optional
functions with specific exceptions they will throw
in non-supported implementations. Applications wishing
maximum interoperability would not use these, just
like they would not insist on a specific provider.

> 
> > and 2) J & M's management functions 
> > don't seem to me to be quite adequate for the 
> > purpose.  
> 
> We're willing to argue that the provider management 
> functionality you're
> looking for is already there in the Java language API without 
> us needing
> to duplicate it in the GSS-API. Please remember that provider 
> management
> is not GSS-API. It's Java Crypto Architecture and that's being built
> elsewhere. Unless you have a dire need for something new, its 
> best to not
> bloat the API. 
> 

Michael, as we discussed this topic offline, we feel
that bloating the GSS layer with management functions
is unnecessary. Java provider framework supplies a
rich toolbox of methods which make no sense to be
duplicated here. And, as Mayank had demonstrated to
you in our previous discussion, the existing framework
can accomplish all the tasks you desired. I thought we
came to agreement on this?

> 
> > Rather than haggling with J & M over the 
> > management functions, though, I think we should 
> > do the following:
> 
> Please, let's not haggle! Let's discuss this issue on technical and
> practical merits.