[Date Prev][Date Next]
Revised DN TS
I have reissued draft-zeilenga-ldapbis-rfc2253-01.txt as
draft-ietf-ldapbis-dn-00.txt based upon discussions on
- Updated 2.3 to clarify which table is the published table of
names which may be appear in DNs. Remove "as an example"
- Updated 2.4 to allow hex pair escaping of all characters and
clarified escaping for when multiple octet UTF-8 characters are
- 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
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.