Subject: I-D ACTION:draft-ietf-ldapbis-dn-02.txt

From: [email-masked]
Date: Mon, 02 Apr 2001 07:16:34 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP (v3) Revision Working Group of the IETF.

	Title		: Lightweight Directory Access Protocol (v3): UTF-8 
                          String Representation of Distinguished Names
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-ldapbis-dn-02.txt
	Pages		: 10
	Date		: 30-Mar-01
	
The X.500 Directory uses distinguished names as the primary keys to
entries in the directory.  Distinguished Names are encoded in ASN.1 in
the X.500 Directory protocols.  In the Lightweight Directory Access
Protocol, a string representation of distinguished names is
transferred.  This specification defines the string format for
representing names, which is designed to give a clean representation
of commonly used distinguished names, while being able to represent
any distinguished name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapbis-dn-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapbis-dn-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 02 Apr 2001 10:51:47 -0700

This revision incorporates language to codify a "be liberal
in what you accept, be strict in what you produce" requirement
as discussed prior to and at IETF#50.  In particular, the
following paragraph was added to Section 3 of the I-D:

  Implementations MUST recognize AttributeType string type names
  (keywords) listed in the Section 2 table, but MAY recognize other
  names (keywords).  Implementations MAY recognize other DN string
  representations (such as that described in RFC 1779) but SHALL only
  generate DN strings in accordance with Section 2 of this document.

Does the addition of this paragraph, specifically the first
sentence, adequately address concerns resulting from the previous
Section 2 clarification of "a published table" to be the table
published in Section 2?  If no, what sort of change do you believe
is necessary? (specific suggestions welcomed)

Does the addition of this paragraph, specifically the second
sentence, adequately address concerns resulting from the previous
removal of the "Relationship to LDAPv2 and RFC 1779" section?
If no, what sort of change do you believe is necessary? (specific
suggestions welcomed)

I note that at IETF#50, there was agreement to form an engineering
team to produce recommendation(s) on how to resolve the significant
outstanding issues with this I-D.  That's still the plan.  Your
answers to the above questions is meant as input to this engineering
team.

Regards, Kurt

---

From: Kathy Dally <[email-masked]>
Date: Wed, 18 Apr 2001 14:17:21 -0400

Hi Kurt!

By itself the new paragraph expresses the intention at IETF#50. 
However, I'm confused by section 2.4.

Here's an example:

The example attribute type is initials and the value is "KL".

The system recognizes the initials attribute.

Sending
	First paragraph of 2.4 says AttributeTypeAndValue SHOULD be:
		2.5.4.43=#04024B4C

	Second paragraph of 2.4 says representation is:
		2.5.4.43=KL

	WHICH ONE IS SENT?

Receiving
	Plus, the alternative given in the new paragraph of section 3, allows a
keyword, 
	such as, the attribute type name specified in RFC 2256, to be the
AttributeType:
		initials=KL

	WOULD ALL THREE BE ACCEPTED ON RECEPTION?

Thanks,
Kathy Dally

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 18 Apr 2001 11:40:17 -0700

At 11:17 AM 4/18/01, Kathy Dally wrote (in part):
>However, I'm confused by section 2.4.  Here's an example:
>

Note that initials is of directoryString syntax not octetString so
that hex encoding is incorrect.  But that's another matter.
Maybe I'll add a directoryString # example to the I-D.

>        Second paragraph of 2.4 says representation is:

The former SHOULD be sent per last sentence of first paragraph.

>        such as, the attribute type name specified in RFC 2256, to be the

or
        initials=#....

>        WOULD ALL THREE BE ACCEPTED ON RECEPTION?

The "initials=" forms may not be as there is no requirement
to recognizes "initials" as an attribute string name in this
context.  I hope the latest Section 3 text I offered in
response to Jim's concerns.

  Implementations MUST recognize AttributeType string type names
  (keywords) listed in the Section 2.3 table, but MAY recognize other
  names.  Implementations MAY recognize other DN string representations
  (such as that described in RFC 1779). As there is no requirement
  for other names or alternative DN string representations be
  recognized, implementations SHOULD only generate DN strings in
  accordance with Section 2 of this document.

---

From: Kathy Dally <[email-masked]>
Date: Wed, 18 Apr 2001 15:03:32 -0400

Hi Kurt!

There's still a problem because the first sentence of 2.4 says that the
attribute value does not have a string representation, which is not the
case for directoryString.

What am I missing?

Thanks,
Kathy

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 18 Apr 2001 12:05:38 -0700

>case for directoryString.

I think the section sentence needs an "also" after the SHOULD.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 18 Apr 2001 11:40:17 -0700

or
        initials=#....

---

From: Kathy Dally <[email-masked]>
Date: Wed, 18 Apr 2001 16:23:42 -0400

Hi Kurt!

Yes.  That makes sense.

Thanks,
Kathy

---

From: Kathy Dally <[email-masked]>
Date: Wed, 18 Apr 2001 16:23:42 -0400

Hi Kurt!

Yes.  That makes sense.

Thanks,
Kathy