Re: Java Bindings do not need to be removed was Re: Proposed PRF changes to address Ken's comments
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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* <hartmans-ietf at mit.edu> wrote:>>>>> "Jeffrey" == Jeffrey Altman <jaltman at columbia.edu> 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
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.