Draft: draft-zeilenga-ldap-adlist-10.txt
Reviewer: Black_David@emc.com
Review Date: Tuesday 7/5/2005 12:45 PM
Telechat Date: July 7, 2005

Summary: This draft is on the right track but has open issues.

Review comments: 
----------------
I have one major concern:  Due to the strong association of the
at-sign ('@') with email addresses, I think its usage for this
extension is problematic at best, as that character is liable to
cause confusion.  I suggest selection of another character if
that's possible at this late stage.

A related minor concern is that the draft contains no examples,
which could serve to illustrate the major concern above.  A few
examples should be added regardless of how the major concern
is resolved.

Section 2 contains a reference to an IANA-ASSIGNED-OID, but
Section 4 says that an OID for this mechanism has been allocated
by the OpenLDAP Foundation and is to be registered by IANA.  The
Section 2 reference is probably in error, as the draft does
not request IANA to allocate any OID.

Subsequent email discussion between David and Kurt:
---------------------------------------------------
Kurt,

> I disagree that any association of the COMMERCIAL AT with
> email addresses will lead to any significant confusion
> here (especially given the restrictions on portions
> of the string to the left and right of the COMMERCIAL AT).

I took a look at the restrictions to the right of COMMERCIAL AT,
(there's more flexibility to the left in an email address) and I
see some of your point.  An oid is clearly not an email domain,
and the crucial '.' character is forbidden in the "descr" syntax,
so text to the right can't be confused with an email address that
contains a full internet domain (e.g., foo@example.com).  OTOH,
there has been use of short address forms that could cause confusion
(e.g., if Example, Inc.'s mailer uniformly expands @country in an
email address to @country.example.com - that's plausible, even if
it's also evidence of possible brain damage), and email addresses
are among the entities that are stored in directories.  If one has
a policy of never using such short address forms, then there's very
little possibility for confusion, but I'm not sure about that
initial "If".

> However, that said, I note that this document is specifying
> the protocol extension as currently implemented and, hence,
> such a change would cause this document to fail the authors
> goal to faithful detailing current practice.

I suspected as much.  I think this is Ted's call at this juncture.

> >A related minor concern is that the draft contains no examples,
> >which could serve to illustrate the major concern above.  A few
> >examples should be added regardless of how the major concern
> >is resolved.
> 
> The example provided illustrates that this should not
> be a concern.  "@country" does not look like an email
> address to me.

I was looking for full-query examples (that include elements to
the left of the '@'), as opposed to this query fragment example.
Sorry for not making that clear in the review.