Subject: RE: Lessons of the SPI, re Java bindings

From: Michael Smith <[email-masked]>
Date: Wed, 19 May 1999 14:32:26 -0400

At 10:46 AM 5/19/99 -0700, Jack wrote:

>I think if we hope to be able to progress the Java GSS bindings forward we
>need to be evaluating its scope with respect to RFC 2078 and not attach
>baggage of the SPI approach. I see the following reasons for this:
>
>1) SPI approach is just one of the ways one can implement a GSS-API package.

True. But the SPI issue has come up -- inconclusively, I admit -- 
before now, and in fact I believe Mayank indicated, either on the list
or in an off-line discussion, that he was interested in this approach. 
Anyway, while it is just _one_ approach, as Jack notes, it's potentially 
a very useful one, and if we can define the bindings in such a way as 
to make it easier and/or better-performing, without offsetting disadvantages,
this seems worthwhile. 

>2) I have not yet seen the interest within the group for the SPI approach. I
>would like to ask the group if the interest is any greater then just
>curiosity?

There was some discussion of this in Minneapolis, and as noted the subject 
has come up before. But I second Jack's request for contributions from others. 

>Can you be more specific about what parameters you are missing?

It seems to me that any or all of the parameters defined for 
"init" in abstract GSS may be germane. E.g. some mechanisms 
may support anonymity, others not. Not all will support privacy -- 
both the ones currently implemented under our version, for example,
support authentication only. Ditto for mutual authentication. 

>I appreciate your creativity - Hatchery is a clever name. But I think we
>should stick with de-facto naming conventions that are familiar in the Java
>environment. So I would prefer the old naming convention of factories. This
>is not just because I'm a city folk :-)

Well, I'm a "city folk" too -- indeed, a Manhattanite. Maybe that's
why I'm interested in rural scenery! Anyhow, I'm not wedded to the 
name. 

>I don't see the big performance problem that you describe with approach 2
>and feel this [i.e. a "wrapper" context in the shim] is the most straight 
>forward way to solve this problem. 

The performance problem is not a big one, I agree, but being a grizzled old 
protocol implementer, I try to anticipate sources of delay and remove them 
where possible. It's mostly a matter of whether the fix is more of a headache 
than the original problem, and here again, it would be nice to 
hear from other CATniks. 

--Michael Smith
  [email-masked]

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