Subject: RE: Comments on draft-zeilenga-ldapbis-rfc2253-01.txt

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 13 Dec 2000 08:34:41 -0500

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: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

---

From: "Ryan Moats" <[email-masked]>
Date: Wed, 13 Dec 2000 10:03:59 -0600

<rm2></rm2> this time. I've dropped Section 2.3 since it looks
like Tim and I agree. Ryan

-----Original Message-----
From: Timothy Hahn [mailto:[email-masked]]
Subject: RE: Comments on draft-zeilenga-ldapbis-rfc2253-01.txt

Ryan,

Greetings,

<rm2>[snip]...</rm2>

Section 2.4:

<rm2>Hmmm.  Isn't the multi byte character concern covered under the UTF-8
transformation?  I take the sentence about escape to mean if an
implementation has a reserved character it can escape it.  Maybe I'm
confused [that often happens :-)].</rm2>

Regards,
Tim Hahn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Dec 2000 09:20:35 -0800

>the code of the character."

I'll rewrite this sentence to specify that each octet of the
character is to be replaced with a backslash and two hex
digits as demonstrated in the examples.  I likely can
borrow language from other portions of the LDAP TS.

Kurt