Java work in the IETF was Re: I-D ACTION:draft-ietf-kitten-gssapi-prf-05.txt

[Jeffrey Altman <jaltman at columbia.edu>]

Sam Hartman wrote:

>>>>>>"Seema" == Seema Malkani <Seema.Malkani at Sun.COM> writes:
> 
> 
>     Seema> Jeffrey, We have not decided on how PRF will be available
>     Seema> in the Java Bindings. Hence, we should not mention any Java
>     Seema> interface/class here.
> 
>     Seema> Currently section 2.2 states:
> 
>     Seema> For Java GSS_Pseudo_random() maps to a method, 'prf', of
>     Seema> the class that implements the GSSContext interface.
> 
>     Seema> This should be modified to: For Java GSS_Pseudo_random()
>     Seema> maps to a method, 'prf'.
> 
> I would rather us remove all references to Java until this can be
> decided.

Later today draft-ietf-kitten-gssapi-prf-07 will be published.
This draft is identical to draft -06 which was published on Friday
except that the Normative reference to RFC2853 will have been
removed.

The primary change in -06/07 is to remove all references to the
Java Bindings.   Recent discussions have brought to light a conflict
between the IETF and Java Community Process (JCP) <http://jcp.org>.

A bit of history.  RFC 2853 was originally a product of the IETF
CAT working group.  Before Sun implemented it in the Java Class
Libraries the content of 2853 was submitted to the JCP and it became
JSR 72 <http://jcp.org/en/jsr/detail?id=72>.   Under the guidelines
of the JCP, all future changes to the Java GSS API must be developed
under JSR 72 and must be approved via the JCP procedures
<http://jcp.org/en/procedures/jcp2>.   In essence, the JCP is a
standards organization with membership requirements and procedures
that conflict with those in the IETF.

At the present time, neither the IETF nor the JCP are willing to
simply accept the work performed by the other.  Therefore, it appears
that those who are interested in the Java work must choose between
one of the two organizations.   I believe there are two choices:

(1) The JCP can be petitioned to allow the work of the IETF to be the
definitive source of specifications for Java GSS under JSR 72.  In this
case all work would be done in this working group.  The Kitten mailing
list traffic could be forwarded to the JSR 72 mailing list provided that
JSR 72 participants are informed that the IETF Note Well applies to JSR
72.  The Java GSS work would continue to be Standards track.

(2) The JCP JSR 72 can be the home to work on Java GSS.  Discussions
related to Java Bindings can take place on the Kitten mailing list but
there will be no Java items on the Kitten charter.  When a new JCP
specification is defined the authors can submit a publication request
to the RFC Editor for Informational publication.   The Java GSS work
would not be Standards track.

Seema is researching the options and will come back to this group with
her selection.   In the meantime, while discussion of Java GSS may
continue, I have requested that Nico remove all references to Java from
the existing documents we are trying to move forward to the IESG.
Once -07 is published, I will issue a WGLC on the document.

Jeffrey Altman

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten