Seema Malkani wrote:
To answer Ken's question :
Adding a new method to a standardized interface will break existing
applications. This means all classes that implement GSSContext interface
will now need to add the new method. All implementations of Java GSS
will NOT compile until the new method is added.
Abstract classes don't have such a problem, since you can provide a
default (possibly empty) implementation, and existing implementations
will not break. It is easier to evolve an abstract class than to evolve
an interface. Since GSSContext was defined to be an interface, we cannot
change it.
Alternatives ?
We can possibly add the new method to GSSManager class, which is an
abstract class. This class serves as a factory for three GSS interfaces:
GSSName, GSSCredential, and GSSContext. The new method will have to be
invoked after the GSSContext has been established.
GSSManager class:
public byte[] prf(GSSContext context, int prf_key, byte[] inBuf, int
outlen)
throws GSSException
GSSManager mgr = GSSManager.getInstance();
GSSName targetName = mgt.createName("service at host", ..);
GSSContext context = mgr.createContext(targetName, ..);
..
if (context.isEstablished()) {
// define PRF key, input..
int prf_key = ..
..
byte[] prf_out = mgr.prf(context, prf_key, inBuf, outlen);
}
Seema
I have given this subject much consideration. I believe that the
issues relating to Java and C# are no different than the issues related
to the C binding. What this document does is specify an
"implementation specific extension" to GSS API version 2 update 1.
As such, it is not going to be possible for a given application to be
able to expect that this functionality exists without some
implementation specific knowledge that it is there. Simply knowing that
we are using GSS API will not be enough.
I do not believe it is appropriate for this document (or any other
document specifying an extension to GSSAPI v2 u1 that Kitten publishes
before GSSAPI v3) to describe the tools necessary for a caller to
determine whether or not the function/method is implemented by a given
implementation. The mistake that the document makes is by specifying
that the method belongs to the "GSSContext" interface. It is perfectly
reasonable for a Java class that implements the GSSContext interface to
provide the prf() method even if it is not part of the GSSContext
interface. An application that expects to use the prf() prior to the
availability of a GSSv3Context interface will need to obtain the
GSSContext reference, use introspection on the resulting class to search
for the method, and if it is found, use a class reference to access the
method.
I believe that adding this method to the GSSManager class would violate
the abstraction model. prf is the first of many extensions this working
group will be proposing. Continuously adding new methods to GSSManager
would result in a class definition that is constantly in a state of flux
without providing any real benefit.
Jeffrey Altman
------------------------------------------------------------------------
_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten
