Subject: WG last call on the Java API

From: Roland Hedberg <[email-masked]>
Date: Fri, 9 Mar 2001 12:46:09 +0100

LDAPEXTers,

The purpose of this message is to initiate the LDAPEXT
working group last call on "The Java LDAP Application 
Program Interface"

WHAT DOCUMENT?

The document in last call is:
  
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-13.txt.  

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately two
weeks. It will end on March 23, 2001

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
   forward the documents to the IESG for informational
   status.

2) Minor changes agreed to on the list are required, and
   the documents are revised. We then ask our ADs to put
   forward the revised documents to the IESG for
   informational status.

3) Major issues are raised and no consensus is reached on
   the list. In this case, we slink back and discuss
   things until consensus is reached, at which time another
   working group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the documents
is with the IESG. The IESG reads them and may approve the
documents (with or without changes), or send the documents
back to the working group to have major issues addressed.

If the first outcome happens, the documents are put forward
for a two-week last call to the entire IETF, and after
successful completion the documents are published as RFCs
with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the documents forward again when we
believe they're ready.

WHAT SHOULD YOU DO?

You should read the documents, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me or my co-chair Mark Wahl.

Silence means consent.

Read, enjoy, and send your comments in!

regards,
Roland Hedberg and Mark Wahl

---

From: Roland Hedberg <[email-masked]>
Date: Fri, 9 Mar 2001 19:45:35 +0100

> weeks. It will end on March 23, 2001

I have received a request to extend the timeperiod for the
evaluation. The reason being the extra workload that the 
upcoming IETF meeting represents.

I have therefore decided to extend the evaluation period 
such that it will end on March 30, 2001.

-- Roland

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Mar 2001 09:25:38 -0800

As I've noted previously, I believe the "core" API specification
should not address LDAP extensions such as Language Tags for
LDAP (RFC 2596).  APIs for LDAP extensions are best handled as
extensions to a "core" API.

Anyways...

The document needs a normative reference to RFC 2596.

The document uses "subtype" to refer to attribute description
options.  This is confusing.

4.1.7 getLangSubtype
   Returns the language subtype, if any. For example, if the attribute 
   name is cn;lang-ja;phonetic, this method returns the String lang-ja.

but RFC 2596 says:
   Multiple language options may be present on a particular value.

getLangSubtype should return a list of options.

Section 4.3.5 says:
   "cn;lang-ja-JP-kanji" may be a subtype of "cn;lang-ja".

No!  RFC 2596 says:
  Language codes are case insensitive....  Implementations MUST NOT
  otherwise interpret the structure of the code when comparing two codes,
  and MUST treat them as simply strings of characters.

Hence, "cn;lang-ja-JP-kanji" IS NOT a subtype of "cn;lang-ja".

Section 4.3.5 continues:
   getAttribute(attrName, lang) returns the subtype that matches 
   attrName and that best matches lang.

I believe "best matches" is inappropriate.  A lang option either
matches (case insensitively) or it doesn't.

Also, 4.3.7 lists the example description "sn;phonetic;lang-ja".
This is an invalid description.  Options must be presented in
ascending order per RFC 2251.

---

From: Michael Ströder <[email-masked]>
Date: Sat, 10 Mar 2001 21:19:28 +0100

> matches (case insensitively) or it doesn't.

Sorry for jumping in so late without knowing prior discussion.

If lang is simply a string the term "best matches" is inappropriate
indeed. But I think lang should be declared as an ordered list of
language options. In this case "best matches" would make sense to
me.

E.g. web interfaces get a list of preferred languages from the web
browser. Would be handy to simply pass that list directly to
getAttribute(attrName, langList). Otherwise I can imagine myself
coding another wrapper method...

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Mar 2001 12:30:40 -0800

>Sorry for jumping in so late without knowing prior discussion.

I just initiated this discussion, so I don't see how you
could be viewed as late.

>indeed.

In this context, "best matches" refers to a matching
algorithm which requires interpretation of the structure
of the language code.  This is inappropriate as RFC 2596
specifically states:
   Language codes are case insensitive.  Implementations MUST NOT
   otherwise interpret the structure of the code when comparing
   two codes, and MUST treat them as simply strings of characters.

>But I think lang should be declared as an ordered list of
>language options.

That how RFC 2596 describes the use of Language
Tags in LDAP.  An attribute type description can
contain any number of language tag options (which,
per RFC 2251 option requirements, must appear in
ascending order).

>In this case "best matches" would make sense to
>me.

This I don't understand.  They are simply strings, so
the only matching that makes sense is a simple case
insensitive match.

>coding another wrapper method...

Well, I think that would require this API to interpret
the structure of the code.  While this may be appropriate
in other contexts, in the context of an RFC 2596 implementation,
it is not.

There are many different uses of language tags.  Gatewaying
between them is an application level problem.  This API is an
LDAP API, hence it should be consistent with LDAP's use of
language tags.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Mar 2001 17:17:49 -0800

These suggestions are primarily editorial in nature:

The I-D represents a number of simple assertion filters
in the form "sn=Jensen", an invalid form.  The I-D
should use "(sn=Jensen)".

The I-D represents a number of DN in the form:
  cn=Barbara Jensen, o=University of Michigan, c=US

An LDAPv3 generated per RFC 2253, Section 2 would
have the form:
  cn=Barbara Jensen,o=University of Michigan,c=US

That is, the more restrictive RFC 2253 form, as
opposed to the RFC 1779 form, should be used.  (Yes,
I know that some of the core documents contain similar
flaws, these are being fixed).

I also recommend that examples use domains (example.com),
DNs (dc=example,dc=com) and IPv4/IPv6 addresses reserved
for examples. For IPv4, IIRC, 192.0.2.0 can be used
(though that might be TEST numbers).  For IPv6, you can
use the IPv6 over IPv4 address (2002::/16) based on the
example IPv4 addresses you use.

I also note that some examples imports "netscape.ldap", not
"org.ietf.ldap".  BTW, I couldn't find any packaging, name
space requirements for this API, nor any guide as to what
namespaces/packaging extensions to this API should be
placed in...

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Mar 2001 17:18:24 -0800

>The document needs a normative reference to RFC 2596.

I also believe the reference to RFC 1766 (obsolete)
should be replaced with a reference to RFC 2596.  I
note that lang attribute of getAttribute takes a
language tag option ("lang-x-klingon") not a
language code ("x-klingon").

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 13 Mar 2001 16:14:10 -0800

I reiterate my request that a detailed security analysis should
be undertaken before the document is progressed to the IESG.  One
of the areas which concern me is the management of authentication
secrets by the API.  Also, a discussion of considerations
implementing API SASL and TLS features should be detailed.  In
particular, the handling of TLS alerts seems an area needing
some discussion.  There were security trade-off taken (in
referral chasing) which should be discussed in the I-D.  

Kurt