Subject: Re: Java Bindings do not need to be removed was Re: Proposed PRF changes to address Ken's comments

From: Mayank Upadhyay <[email-masked]>
Date: Mon, 18 Jul 2005 12:06:58 -0700

I agree with Sam's comments. It would be in JGSS's best interest if the 
bindings are defined at the IETF simply because the it would provide the 
widest review with experts in this area.

Having an abstract API at the org.ietf level and an implementation at 
java.* level would just confuse developers. I was at Sun when RFC2853 
was imported into the JDK/J2SE and was actually the JCP lead. I found 
that many folks on the JCP expert committee were already involved in the 
IETF and didn't have any fundamental differences with the RFC. The few 
suggestions they made were very implementation specific and can easily 
co-exist within the bounds of the RFC. For example, two suggestions 
which came out of the JCP were:

   1.  Every standard implementation of JGSS should provide support for
      Kerberos v5. This was the only way a client and server using
      JDK/J2SE could be guaranteed interoperability.
   2. JGSS was to work hand-in-hand with JAAS. this meant that
      credential acquisition was to happen from the current Subject on
      the thread's execution context. This made it simple for developers
      to predict where the credentials were coming from and how they
      could be managed. We did provide a system property that could be
      set which allowed this restriction to be relaxed.

In summary, I think the IETF process and the JCP are both important for 
these bindings, and it would be unfortunate if Sun cannot make this 
process work so that the two standard bodies don't collide on this.

-Mayank

On 7/11/05, *Sam Hartman* <[email-masked]> wrote:>>>>> "Jeffrey" 
== Jeffrey Altman <[email-masked]> writes:

    Jeffrey> Seema Malkani wrote:
    >> Hello... back from JavaOne.
    >>
    >> I would like to clarify few things here:
    >>
    >> 1) JCP Process When RFC 2853 was published, we went through
    >> Sun's JCP process for the Java GSS bindings before providing an
    >> implementation in the JDK.  Any updates to the Java GSS
    >> Bindings would also need to go though the JCP process. Here is
    >> the JSR on the Java GSS bindings:
    >> http://www.jcp.org/en/jsr

    /detail?id=72

        Jeffrey> IETF Standards Track documents are developed within the
        Jeffrey> IETF and IETF processes.

    True.

        Jeffrey> By working with IETF to develop
        Jeffrey> a standards track specification for JGSS, Sun has given
        Jeffrey> up the right to utilize the JCP.

    I don't think that follows at all.  I think that if Sun chooses to
    continue working within the IETF to standardize Java GSS bindings then
    Sun should plan to implement the results of IETF standards.

    If that isn't going to work for Sun, then perhaps it is inappropriate
    for this working group to standardize Java bindings for GSS
    extensions.  Instead, we can standardize the abstract APIs.  Sun can
    go through whatever process they choose to define Java bindings.  I'd
    recommend that if Sun chooses that route they publish informational
    RFCs notifying the IETF community what Java extensions they
    standardize.

    My hope is that Sun will find a way of working within the IETF process
    to standardize Java GSS extensions.  However we need Sun's input on
    this issue rather soon in order to know what to do with the current
    draft.

    Sam Hartman
    Security Area Director

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Jul 2005 17:00:19 -0400

>>>>> "Mayank" == Mayank Upadhyay <[email-masked]> writes:

    Mayank> I agree with Sam's comments. It would be in JGSS's best
    Mayank> interest if the bindings are defined at the IETF simply
    Mayank> because the it would provide the widest review with
    Mayank> experts in this area.

    Mayank> Having an abstract API at the org.ietf level and an
    Mayank> implementation at java.* level would just confuse
    Mayank> developers. 

Er, that's not quite what I meant.  By abstract API I mean the
language-independent API. 

I.E. with the current administritive structures the IETF can either do
the standardization work or Sun can do the work.  The option of IETF
doing the work and having it reviewed after the fact in Sun's process
is not OK.  Joint work might be a possibility.

---

From: Mayank Upadhyay <[email-masked]>
Date: Tue, 19 Jul 2005 15:04:35 -0700

>language-independent API. 
My apologies. My view is tainted by an old contentious discussion in the 
CAT working group about an interfaces-only JGSS API. :)

-Mayank