Subject: Re: Why combine the Java and C# bindings?

From: "Juan Carlos Luciani" <[email-masked]>
Date: Tue, 19 Apr 2005 10:43:39 -0600

Mayank,

When defining the C# bindings, we at Novell felt that there was no reason to
diverge from the Java bindings. Keeping the C# bindings as close as possible to
the Java bindings meant that developers familiar with the Java bindings would
have an easier time when developing to the C# bindings.

We originally set out to produce a document that only published the C# bindings
and we got feedback that it would be better to extend RFC 2853 since the
document that we were producing was duplicating a lot of the information
present in the RFC.

The concerns that you list are valid. I will consider withdrawing the
current draft and publishing the C# bindings in their own document.

Thanks,

Juan Carlos

>>> Mayank Upadhyay <[email-masked]> 04/18/05 5:35 PM >>>
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

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Apr 2005 11:47:20 -0500

> current draft and publishing the C# bindings in their own document.

WG consensus on the matter hasn't been reached.

I for one would like to hear more about why or why not C# bindings
shouldn't be in the same doc as Java bindings.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Apr 2005 14:10:50 -0500

> shouldn't be in the same doc as Java bindings.

Mayank has made, privately, one technical argument about the lack in C#
of an equivalent for the Java stream classes used in the Java bindings.

I believe that, if accurate, that may yet turn out to be a very good
reason for specifying the bindings for those two languages in separate
documents as the differences between one set of bindings an another
might differ too much to justify specifying in one document, and the two
bindings would probably progress at different rates, thus the
specification of one might hold up the other.

I would like to know, out of curiosity if nothing else, if there really
are any differences between Java and C# that make it impossible to
specify the C# bindings of the GSS-API in terms of lexical
transformations of the Java bindings, as Juan has attempted.

If the C# bindings of the GSS-API cannot be expressed simply and in
terms of the Java bindings then I see no strong reason to specify the
two in one document.

My mind is not entirely made up as I'm still missing information, but
the authors of the existing I-Ds seem willing to pursue separate paths.

Jeff, do you think we need a consensus call, or is there consensus
already?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Apr 2005 14:12:33 -0500

> Mayank has made, privately, one technical argument about the lack in C#
                              ^^^
			      a

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Apr 2005 18:18:41 -0400

> Jeff, do you think we need a consensus call, or is there consensus

I do not believe that we need an explicit consensus call to determine
which path is taken for publication of this work.

Back in October when the working group was forming there was a weak
consensus that the Java and C# bindings should be merged into one
update to 2853 because it was argued that the quantity of work
necessary to be performed was modest for both.  Java required an
update because there were factual errors that needed to be corrected.
The C# definition was considered to be minor.

In the past two weeks there has been significant discussion regarding
the merits of this decision.   The editors of both the current Java
draft and C# draft are in agreement to go separate ways and I do not
see any requirements that only a single document be produced.

Here is what I would like to see in the coming month:

* I would like to see an updated version of
draft-ietf-kitten-rfc2853bis-00.txt published that contains all of the
text of rfc2853 modified as stated by the aforementioned  draft.

* I would like to see a revised version of
draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00 which is based on
rfc2853 but is specific to C#

I believe that rfc2853bis can be sent to the IESG in a very short period
of time.  A revised rfc is justified to correct the factual errors in
2853.   This working group will have a large number of changes published
in the coming year and I do not want to wait for the conclusion of this
working group before an updated Java bindings RFC is published.

A third revision to 2853 can be published as we near the end of the
working group to collect all of the Java bindings which are produced for
forthcoming APIs.  In the meantime, supplementary documents such as the
PRF drafts will contain bindings for at least C and Java when they are
submitted to the IESG.

Jeffrey Altman