Subject: Why combine the Java and C# bindings?

From: Mayank Upadhyay <[email-masked]>
Date: Mon, 18 Apr 2005 16:35:21 -0700

First, I apologize for joining this discussion late. I'm concerned that 
we are rushing to combining the Java and C# bindings in to one document. 
If we combine the two bindings into one, my feeling is that over time we 
will end up with a large switch statement written in plain English.

The Java bindings in RFC 2853 aim to provide a vast amount of guidance 
that is relevant to the Java platform. Each and every bit of it that is 
not applicable to C# will need to have a case that lists the Java 
behaviour and the C# behaviour separately. Some of the issues that come 
to mind right away are:

1. Does C# have a provider framework, and can all the JGSS provider APIs 
be ported to C#? Does the provider framework have the same level of 
permissions as the Java one? (See the discussion of security providers 
throughout RFC 2853.)

2. In Java all methods are virtual unless declared final. Not so in C# - 
all methods are non-virtual unless the virtual keyword is present in its 
declaration. This means that all RFC2853 classes that have non-final 
methods will have different behaviour when called in Java and when 
called in C#. This affects the mechanism implementor in all classes, and 
it affects the application developer in ChannelBinding, MessageProp, and 
Oid.

3. The ChannelBinding class can accept both IPv4 and IPv6 addresses in 
Java. Will that work in C#?

4. The application developer can make his/her own address class that 
subclasses InetAddress, and pass that to ChannelBindings. Will that work 
in C#?

5. All references to package org.ietf.jgss in Java already have to be 
replaced with references to a namespace in C#.

Looking forward, there are two enhancements that should be added to the 
Java version that may not make sense in the C# version:

1. There is enormous interest in getting a service-provider interface 
published that allows non-default mechanism providers to add their 
mechanism implementations to any compliant JGSS package. Again, this 
relies heavily on the availability of a JCA (Java Crypto Architecture)  
like provider framework. Even if C# adds one at some point in the 
future, there may be multi-threading issues with the API itself that may 
vary between the C# (mono, .NET) and Java platforms.

2. After having implemented JGSS in the Java platform we realized there 
was a need to clarify what credentials cache should be used by default, 
and how it may be populated. This refers to the Subject class that is 
associated with the access control context in the JVM. This class, 
again, is only relevant in Java, and providing guidance on how to 
integrate JGSS with it makes a great deal of sense for Java programmers.

Moreover, there is no guarantee that C# and Java will not diverge 
significantly, even beyond the issues mentioned above. We should not 
compare C# and Java to C and C++. The latter two can make do with one 
set of bindings because one language is (almost) a proper subset of the 
other.

Since the current requirements of the C# draft are very modest and only 
refer to the core API, I would recommend that they publish a separate 
document that references the relevant sections of the Java bindings. As 
the Java bindings evolve, it may not even be necessary to increment the 
C# bindings because the changes are unlikely to affect the core.

Just my 2 cents!

-Mayank

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Apr 2005 13:05:38 -0500

Is it really the case that sub-classing is the intended SPI in Java?
RFC2853 seems to explicitly leave the SPI out of scope.

Nico
--

---

From: Mayank Upadhyay <[email-masked]>
Date: Wed, 20 Apr 2005 11:48:18 -0700

>RFC2853 seems to explicitly leave the SPI out of scope.
The the impact on inheritance is irrespective of the SPI. Say, an 
application developer creates a subclass of ChannelBinding that does 
some special processing of the input parameters and overrides the 
accessor methods. During context establishment this object is passed to 
the underlying mechanism. Now, when the underlying mechanism calls 
/getAcceptorAddress/() or any of the other accessor methods on this 
object, in C# the behavior they see will be the base class 
org.ietf.jgss.ChannelBinding, and not the applications developer's 
intended behavior. This is because the method in the subclass is not 
declared virtual. The same thing can happen to /MessageProp /and /Oid/.

Regarding the SPI, when we started the Java bindings there were export 
control issues and the JCA provider model was still being 'digested'. So 
we decided to simply provide hooks for providers but leave the SPI out 
to be specified in another doc, another time. Ideally, I would like to 
see the SPI be part of the base document in the future because export 
control restrictions have been eased and JCA is better understood now. 
Irrespective of this issue, all of those hooks that refer to provider in 
RFC 2853 would create compile time issues for the C# API.

-Mayank