[Date Prev][Date Next] [Chronological] [Thread] [Top]

Revised DN TS



I have reissued draft-zeilenga-ldapbis-rfc2253-01.txt as
draft-ietf-ldapbis-dn-00.txt based upon discussions on
this list.  

- Updated 2.3 to clarify which table is the published table of
names which may be appear in DNs.  Remove "as an example"
language.
- Updated 2.4 to allow hex pair escaping of all characters and
clarified escaping for when multiple octet UTF-8 characters are
present.
- Rewrote Section 3 to use ABNF as defined in RFC 2234.
- Rewrote Section 3 ABNF to be consistent with 2.4.

As noted at IETF#49, the following major issues need to be
discussed:

a) what "type string names" may be used to identify attribute
types in the generation names (and, hence, required to be
recognized by protocol peers)?  I will separately post my
comments regarding this issue.

b) what is the "Relationship with RFC1779 and LDAPv2"?
I will separately post my comments regarding this issue.


In addition, there is an additional, I hope, minor issue:

c) normative references
  2.3 refers to 'domainComponent' (dc) and 'userId' (uid)
  X.500 attribute types.  RFC 1274, a Proposed Standard,
  describes 'domainComponent' and 'userid'.  RFC 2247 provides
  an LDAP attribute description for 'domainComponent' using
  the short name 'dc'.

  So that a normative reference to RFC 1274 and/or 2247 is
  not necessary, I suggest that RFC2256bis include LDAP
  attribute descriptions for 'dc' (domainComponent) and
  'uid' (userid) based upon their X.500 counter part
  descriptions in X.520 and elsewhere.


Kurt