[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Comments on draft-zeilenga-ldapbis-rfc2253-01.txt
Ryan,
see my comments below with <TJH> ... </TJH>
<rm>... See <rm></rm> comments... Ryan </rm>
Greetings,
Section 2.3:
I understand the intent here (ensure that distinguished names in protocol
are unique). However, I believe that this will represent a big
compatibility concern for existing implementations. This also places quite
a bit more burden on LDAP clients to query the subschema entry and build a
OID <-> attribute type name mapping to use when presenting DNs to
applications.
<rm> Well, I can say that Kurt, Rick Huber and I had a lively discussion
about this after the working group meeting on Monday night. In my opinion,
again, we should find a way to list those attribute type names that are
required for interoperability and provide an "escape clause" that
implementations SHOULD support additional attribute type names. If I
put on my "directory customer" hat (which I wear quite a bit these days),
anything without the "escape clause" is DOA. This is because other working
groups and standards bodies are defining schema that use additional
attribute type names for naming already, and anything that "raises the bar"
for implementations is (again IMHO) a BAD thing.</rm>
<TJH>Sounds good to me</TJH>
Section 2.4:
A note indicating that UTF-8 characters may be escaped using the "\nn" form
would be helpful - noting that in this case, multiple escaped bytes will be
required.
<rm>Hmm, I thought there was something in the ABNF already?</rm>
<TJH>I checked the draft again this morning. While the draft indicates
that a value is first transformed to a UTF-8 string (according to RFC
2252), it also indicates that
"Implementations MAY escape other characters."
It then goes on to state that the character to be escaped
"is replaced by a backslash and two hex digits, which form a single byte in
the code of the character."
There is an example in section 4 that contains an escaped UTF-8 character.
It just seems to me that we could describe how to escape multi-byte
characters a bit more than what is in the second quote in this
paragraph.</TJH>
Regards,
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