[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