comments on draft-sermersheim-ldapbis-rfc2251-00.txt

["Timothy Hahn" <hahnt@us.ibm.com>]

Greetings,

I have the following comments on this draft:

Section 2:
There is an editors note that needs to be filled in: "<reference define
doc>"

Last paragraph of Section 3.2.2:
This paragraph indicates that a base object search should be performed to
get the subschema information.  The paragraph should give some indication
as to what distinguished name should be used.  Something like "the base DN
of the search should be the value retrieved from a separate
search/retrieval of the subschemasubentry attribute from an entry in the
DIT."

Section 3.4:
subschemasubentry in the root DSE is clarified here to be multi-valued.
This is different from the schema definition for this operational attribute
which defines this attribute to be single-valued.  This has been discussed
on the list before but I do not recall a concensus on how to handle this.
I would prefer that the root DSE not be allowed to "violate" schema
definitions if at all possible.

Section 4.1.2:
ISO 10646 is refered to here as the character set that is UTF-8 encoded.
Some new government regulations beginning to require not just UCS-2 but
UCS-4 support in products.  UTF-8 encoding can handle up to 31-bit
characters and thus can be used to encode UCS-4 characters.  However, if
the LDAP protocol limits strings to UCS-2, LDAP's use in certain parts of
the world could be stymied.  Should we allow expansion to UCS-4 in strings?

Section 4.1.3:
The ABNF appears to need more information.

Paragraph starting with "If the server has a textual name" seems to
conflict with the proposals in draft-zeilenga-ldapbis-rfc2253-01.txt.

Last paragraph of Section 4.2.1:
If the client does NOT establish a new connection, how should the server
treat any client requests?  I propose that the server treats all subsequent
operations, in this case, as if the client bound as anonymous.

Section 4.4:
I think it would be good to clarify that an unsolicited notification that
follows the setup of encryption and integrity will be sent using the
encryption and integrity that was setup.

Section 4.5.1:
"The extensibleMatch is new in this version of LDAP"  would be better
stated as "The extensibleMatch is new in this specification of LDAPv3"

paragraph on "attributes:".  This paragraph should be updated to discuss
the usage of "+" as defined in the draft-zeilenga-ldapv3bis-opattrs-03.txt
draft.

Should "Furthermore, servers will not return operational attributes" be
"Furthermore, servers MUST NOT return operational attributes"?

Section 4.8(add), 4.9(modify DN), 4.10(compare):
Clarify that aliases are not dereferenced in performing these operations.

Section 4.9:
I think a paragraph should indicate that servers MAY attempt to "re-align"
attributes of distinguishedName syntax in entries not contained within a
re-located sub-tree such that these distinguished names continue to point
to entries that have moved.

Thanks,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681