Subject: RE: Proposed changes to draft-ietf-cat-gssv2-javabind-01.t

From: Dave Arnold <[email-masked]>
Date: Thu, 27 May 1999 10:55:17 -0700

I agree with the IGSS* convention.  In fact, we have been considering using
the IGSS* convention for interfaces and CGSS* convention for concrete
classes.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 26, 1999 6:09 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Proposed changes to draft-ietf-cat-gssv2-javabind-01.t
> 
> 
>      First, I prefer the IGSS* naming convention over 
> GSS*Int.  It seems 
>      more standard, but then I may have lived in C++ (and 
> Microsoft) land 
>      far too long. 
>      
>      I'm worried that we cannot meet both the applet and 
> applications needs 
>      with one method of instantiating classes. We need to draw a line 
>      between "stand alone" GSSAPI implementations and "system" GSSAPI 
>      implementations.  I use "stand alone" to refer to a 
> GSSAPI provider 
>      that provides a complete implementation for a 
> mechanism(s) based on 
>      the interfaces provided (typically done within an 
> applet).  A "system" 
>      provider sits under a system wide GSSAPI implementation 
> that provides 
>      access to multiple mechanisms (typically within in 
> application or 
>      server).   Currently the GSSManager concrete class 
> instantiates both 
>      types.  I am against this for the following reasons.
>      
>      -  An applet may not be able to set the necessary system 
> provider 
>      properties. 
>      -  It requires the applet to have access to a common 
> implementation of 
>      GSSManager.
>      -  It encourages mixing of objects between providers.  Having a 
>      GSSManager class that instantiates multiple providers 
> suggests that 
>      one might be aware of another.
>      -  It adds more weight to the applet code.
>      -  A provider management API is currently not specified 
> for GSSAPI.
>      
>      I propose that the applet writer must know the name of 
> the GSSFactory 
>      class and instantiate it directly for an "stand alone" provider.
>      
>      The "system" and "stand alone" methods differ in how classes are 
>      instantiated and where the GSSManager functionality 
> lies. Reorganizing 
>      the document would help separate the details of 
> implementation from 
>      the GSSAPI interfaces.
>      
>      Separate the document into two sections. The first 
> defines the set of 
>      interfaces and common classes adding an IGSSManager 
> interface (or, if 
>      you like GSSManagerInt  see sample code at the end).    
> The second 
>      specifies two implementation models, the "stand alone" 
> model oriented 
>      towards applets and the "system" model oriented towards 
> applications.  
>      
>      Stand Alone Model
>      -----------------
>      In the stand alone model the  implementation provider 
> provides a class 
>      that implements GSSFactory and IGSSManager.  The 
> application must know 
>      the name of the provider class that implements GSSFactory.  The 
>      application uses the GSSFactory interface to get 
> instances of the 
>      GSSContext, GSSCredential, and GSSName classes as needed.  Using 
>      different implementations requires instantiating 
> different classes, 
>      this reinforces the fact that different implementations 
> probably will 
>      not co-operate to share tokens.  Here the GSSManager 
> functionality is 
>      covered by the same class that implements GSSFactory.
>      
>      
>      System Model
>      -----------------
>      In the "system" model there is a well known GSSManager 
> class that 
>      implements the IGSSManager interface. as well as well known 
>      GSSCredential, GSSName and GSSContext classes that 
> implement their 
>      respective interfaces.  In this model there may be co-operation 
>      between mechanisms so that tokens can be created for and used in 
>      multiple mechanisms.
>      
>      
>      I am pushing for two different models because applets 
> and applications 
>      need different things.  In the applet world the browser 
> restricts 
>      access to system properties and functions.  Browser 
> support limits how 
>      quickly new features are implemented.  Additionally, the 
> smaller the 
>      applet the better.  An application, on the other hand, 
> can demand 
>      better VM support, have huge code size, and access 
> anything in the 
>      system it wants to.  I would probably not be able to use 
> the proposed 
>      changes in an applet.  
>      
>      
>      -Joe
>      
>      
>      Code Samples
>      --------------
>      
>      New interfaces:
>      /**
>       * IGSSManager is a interface to provide information 
> about mechanism   
>       * implemented in the specific provider
>       *
>       */
>       public interface IGSSManager {
>         public Oid[] getMechs();
>              public Oid[] getNamesForMech(Oid mech) throws 
> GSSException;
>              public Oid[] getMechsForName(Oid nameType);
>              public Oid getDefaultMech();
>       }
>      
>      
>      
>      /**
>       * GSSFactory is the main interface that a provider implements. 
>       * The caller must know the name of the class that 
> implements this     
>       * interface
>       */
>      public interface GSSFactory {
>         // Factory methods      
>         public GSSContextInt    getContext();
>         public GSSCredentialInt getCredential();        
>         public GSSNameInt       getName();
>      
>      }
>      
>      /** an stand alone GSSAPI provider would implement both 
> of the above   
>       *  interfaces
>      
>      public class GSSStandAloneProvider implements 
> IGSSManager, GSSFactory{
>      
>      ...
>      
>      }
> 
> 
> ______________________________ Reply Separator 
> _________________________________
> Subject: Proposed changes to draft-ietf-cat-gssv2-javabind-01.txt (
> Author:  mdu ([email-masked]) at internet
> Date:    5/25/99 6:01 PM
> 
> 
> We would like to complete all changes to this draft next week 
> as far as 
> the introduction of interfaces and multiple top level GSS-API 
> providers 
> go. If you wish to review the proposal and send us some 
> feedback you can 
> find the proposal, sample apps, and a class diagram online at: 
>      
http://playground.sun.com/~mdu/
     
We look forward to your response.
     
Regards,
Mayank Upadhyay
Jack Kabat

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