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

From: Michael Smith <[email-masked]>
Date: Wed, 03 Nov 1999 14:12:32 -0500

At 10:11 AM 11/3/99 -0800, Joe Salowey <[email-masked]> wrote:
[responding to my]
>> 
>> 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.  

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]

==========================================================================
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: Mayank Upadhyay <[email-masked]>
Date: Wed, 3 Nov 1999 13:07:48 -0800 (PST)

> achieve this goal (e.g. a class name in a system property). 

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

> I'm troubled by what is, I suppose, an issue of ownership

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