Subject: RE: Java GSSAPI: Interfaces vs. Concrete classes

From: Joe Salowey <[email-masked]>
Date: Wed, 3 Nov 1999 10:11:08 -0800

> 
> Frankly, I'm still a little baffled about why folks think it's 
> important to have GSSManager be either concrete or semi-solid
> (i.e. abstract), as opposed to being an interface. 

By providing an abstract class with a static method you enable an
application to easily find the default GSSAPI implementation on a given
platform.  This implementation may be Sun's implementation if the VM was
developed and distributed by Sun, or it may IBM's if the VM is developed and
distributed by IBM, etc.  There are a growing number of OS vendors that
provide an implementation of GSSAPI with the OS as well as a Java VM.  Why
is it important to use the platform provided mechanism if possible?  There
maybe credential stores such as Kerberos caches or certificate stores that
are integral to the OS and are shared among applications (both C and Java
applications).  By using another mechanism you might loose "Single Sign On"
or you might not be able to verify a CA certificate.  If the GSSAPI
implementation does not have a standard name you will not be able to find it
without having to modify code or program parameters for each platform (to
instantiate com.ibm.gss vs com.sun.gss).  However it is also possible that
as an applet the mechanism you need might not be available or you might not
have access to it.  In this case the applet may carry with it an
implementation of the mechanism it needs.

> As has been noted before, if Sun wants to ship a default GSS 
> implementation, with or without a static method, there's no reason 
> why it shouldn't do so, even if org.ietf.GSSmanager is only an 
> interface. 
> 
> In any case, the application programmer must 1) import something
> (Sun's standard implementation, or somebody else's) 
> and 2) get an instance of something. So I see no advantage 
> whatsoever to making GSSmanager anything but an interface. Against 
> this must be weighed the loss of flexibility if we make it 
> a class, either abstract or otherwise: Java provides no multiple
> inheritance of classes, but it does for interfaces. 

True, there is a trade off here.  The ability to find the Platform
implementation is significant and out weighs the benefits of multiple
inheritance.

Joe
 
==========================================================================
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: Michael Smith <[email-masked]>
Date: Wed, 03 Nov 1999 17:01:11 -0500

At 01:07 PM 11/3/99 -0800, Mayank wrote:

>Your proposal of using class names in system properties is bad because: 
>
>(1) it is inconvenient to the programmer
>
>(2) system properties require permissions in the Java sandbox to read or
>write
>
>(3) system properties have the same value for all applets in the browser
>which would create a security hole in your model

The "class name system property" approach was intended simply as an 
illustration; no doubt better ways could be thought of. I note, however, 
that surely point 3) above would also apply to your approach of a 
static method in GSSManager; and I fear I don't see where the 
"security hole" comes from. 

As for point 1), being inconvenient to the programmer, that's easy 
to fix, if Sun wants to be helpful: define some java.mumble.GSSFinder 
class which does precisely what your proposed static method in GSSManager 
does, either by interrogating a system property or by doing something 
more razzle-dazzle. This would also dispose of point 2). 
And it would not require any endorsement by the WG or the IETF;
helpful little Boy Scout classes supplied with the environment 
are certainly Sun's prerogative entirely.  

>One more time, I'll try to put this across as plainly as I can: 
>
>Please download other JVM's from Microsoft, IBM, HP, etc and you will
>realize that you have a choice amongst implementations of the standard
>Java API's. All packages in the java.* namespace have the same API but
>have different implementations depending on the vendor you get your JRE
>from.
>
>And if you haven't yet noticed, these packages are a mix of concrete
>classes, abstract classes and interfaces. 

Mayank, I really don't think I've failed to understand what you have 
in mind; sorry if I've given you that impression. I realize (all too 
well!) that implementations of the standard java APIs can differ. The 
trouble is that if I as an implementer have to extend a class rather 
than implement an interface, then I am to some extent at the mercy of 
the implementer of the parent class, whoever that may have been in a 
particular environment -- yet another source of portability worries, 
incidentally. In effect, the problem is even worse than I originally 
argued: instead of standardizing Sun's implementation, we are being 
asked to wave a standards wand over "whoever"'s implementation, where 
"whoever" is the implementer of the local java.mumble.GSSManager. 

I see no need to open this can of worms, since we have the easy option
of staying on the high ground simply by making GSSManager an interface. 
The only basis that I've heard for making it a class is to provide a 
way to get the "local implementation." But that's a childishly easy 
problem to solve by other means, so making it a class seems very 
inadequately motivated by any considerations raised thus far.  

--Michael Smith
  [email-masked]

---

From: Joe Salowey <[email-masked]>
Date: Wed, 3 Nov 1999 15:48:14 -0800

I don't see what control Sun (or any other vendor) has if the class is
abstract and all the methods aside from getInstance are abstract.  The point
of making the class abstract rather than concrete was to enable it to be
fully defined by the API document. 

If Sun or any other vendor goes against the specification and implements a
concrete GSSManager that is final then there is a problem.   Then again
there are many other areas in which a non-conforming implementation can
inhibit interoperability.

A reference implementation of GSSManager could implement getInstance() as
follows (this gets the name of the GSSManager class from a system property
as Michael suggests). Note the rest of the class is abstract.

	public static GSSManager getInstance()
	{
		try{
			//It might be possible to do something more elegant
here	
			Class gmClass =
Class.forName(java.lang.System.getProperty("gssapi.manager"));
			if (gmClass != null){
				GSSManager gm = (GSSManager)
gmClass.newInstance();
				return gm;
			}
			return null;
		}
		catch (Exception e){
			// The Exception handling could be better
			return null;
		}
		
	}	

-Joe

> -----Original Message-----
> From: Michael Smith [mailto:[email-masked]]
> Sent: Wednesday, November 03, 1999 11:13 AM
> To: Joe Salowey
> Cc: [email-masked]
> Subject: RE: Java GSSAPI: Interfaces vs. Concrete classes
> 
> 
> At 10:11 AM 11/3/99 -0800, Joe Salowey <[email-masked]> wrote:
> [responding to my]
> >> 
> >platform.  
> No doubt; but there are considerably more lightweight ways to 
> achieve this goal (e.g. a class name in a system property). 
> 
> Quite apart from the multiple-inheritance issue, 
> I'm troubled by what is, I suppose, an issue of ownership
> and control. 
> 
> A concrete class (unlike an interface) has an implementation
> behind it. What it seems we (the WG) are being asked to do is to 
> say, in effect, that the Java-GSS binding consists of a 
> class, to be implemented by Sun and to remain under its 
> control. 
> 
> What's wrong with that? Well, suppose the export-control 
> commissars tell Sun that a non-final GSSManager, or a GSSManager
> with non-final management functions, constitutes "crypto 
> with a hole" and can't be exported. What happens then? Sun 
> might take the (relatively) high road and pull the GSS package 
> from the export JDK/JRE, but then where's the portability? Or 
> Sun might decide to be law-abiding and make its GSSManager 
> final, or make management functions final, in ways which 
> impede the ability of non-US users to use whatever crypto 
> they have available, at least through GSS. 
> 
> It gets worse: now suppose some patent holder sues Sun 
> for letting users load mech implementations which the 
> patent holder claims infringe its patents. What will Sun's
> lawyers tell Sun? 
> 
> I'm not attributing to Sun any sinister motivations here, 
> but it seems very extraordinary to me that we are 
> apparently contemplating specifying an implementation
> where our mandate is to specify an API -- and an 
> implementation, at that, which we haven't produced and 
> don't control. 
> 
> 
> --Michael Smith
>   [email-masked]
>

---

From: Jack Kabat <[email-masked]>
Date: Thu, 4 Nov 1999 09:42:51 -0800

This thread is definitely providing spark to the list
we have not seen for some time. But getting back to JGSS,
interestingly the motivation for us to add and argue for
the importance of the GSSManager class as a concrete or
abstract class stems not from any association with Sun
or other entity, but quite the opposite - from us
thinking of the application and applet developers
(ones that should not need to search the properties to
access the JGSS implementation). As an application
developer I want to create a class without worrying
if it will not work if the JGSS implementation is from
vendor x or y. I don't understand why this needs to be
complicated.

Michael, I think if you look from this perspective you
might change your position on the importance of this feature
(well, maybe not :-)). Having a well defined class that
the applications can create is very valuable, much more than
the disadvantage you have pointed out. The flexibility
argument was well founded when talking about the GSSName,
GSSCredential, and GSSContext classes, and hence we revised
our draft to include that change. But I don't buy it
here - it is one class that is important to tie all
the other interfaces together. Interfaces have their
place in the binding, but are not appropriate here.

Thanks,

jack

> Sent: Wednesday, November 03, 1999 2:01 PM
> To: Mayank Upadhyay

---

From: [email-masked]
Date: Fri, 5 Nov 1999 19:23:00 -0600

Since we are also developing an implementation of J-GSS, I
would like to add my vote for the importance of the GSSManager
class as a concrete class. The application developer needs
to create a class without worrying if it will not work if
the J-GSS implementation is from any vendor. This is a base
requirement from all of our ISV's.

I don't buy Michael's, perspective at all and I believe if we go down
that path we will all regret this 100%. Having a well defined
class that the applications can create is very valuable with all
the various vendors that are out there today.

Thanks,
Anthony Nadalin
_______________________________

mailto:[email-masked]