[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: do spaces matter in DNs?
Here is the reference.
RFC 2253 LADPv3 Distinguished Names December 1997
Implementations MUST allow for space (' ' ASCII 32) characters to be
present between name-component and ',', between attributeTypeAndValue
and '+', between attributeType and '=', and between '=' and
attributeValue. These space characters are ignored when parsing.
>From my understanding, if using a version 3 server and client.
This should work just fine.
***********************
Here is the entire context....
3. Parsing a String back to a Distinguished Name
The structure of the string is specified in a BNF grammar, based on
the grammar defined in RFC 822 [5]. Server implementations parsing a
DN string generated by an LDAPv2 client MUST also accept (and ignore)
the variants given in section 4 of this document.
distinguishedName = [name] ; may be empty string
name = name-component *("," name-component)
name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
attributeTypeAndValue = attributeType "=" attributeValue
attributeType = (ALPHA 1*keychar) / oid
keychar = ALPHA / DIGIT / "-"
oid = 1*DIGIT *("." 1*DIGIT)
attributeValue = string
string = *( stringchar / pair )
/ "#" hexstring
/ QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
quotechar = <any character except "\" or QUOTATION >
special = "," / "=" / "+" / "<" / ">" / "#" / ";"
pair = "\" ( special / "\" / QUOTATION / hexpair )
stringchar = <any character except one of special, "\" or QUOTATION >
hexstring = 1*hexpair
hexpair = hexchar hexchar
hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
ALPHA = <any ASCII alphabetic character>
; (decimal 65-90 and 97-122)
DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
Wahl, et. al. Proposed Standard [Page 5]
RFC 2253 LADPv3 Distinguished Names December 1997
4. Relationship with RFC 1779 and LDAPv2
The syntax given in this document is more restrictive than the syntax
in RFC 1779. Implementations parsing a string generated by an LDAPv2
client MUST accept the syntax of RFC 1779. Implementations MUST NOT,
however, generate any of the RFC 1779 encodings which are not
described above in section 2.
Implementations MUST allow a semicolon character to be used instead
of a comma to separate RDNs in a distinguished name, and MUST also
allow whitespace characters to be present on either side of the comma
or semicolon. The whitespace characters are ignored, and the
semicolon replaced with a comma.
Implementations MUST allow an oid in the attribute type to be
prefixed by one of the character strings "oid." or "OID.".
Implementations MUST allow for space (' ' ASCII 32) characters to be
present between name-component and ',', between attributeTypeAndValue
and '+', between attributeType and '=', and between '=' and
attributeValue. These space characters are ignored when parsing.
Implementations MUST allow a value to be surrounded by quote ('"'
ASCII 34) characters, which are not part of the value. Inside the
quoted value, the following characters can occur without any
escaping:
",", "=", "+", "<", ">", "#" and ";"
******************************************
Hope this helps.
-Rajk
William L Anderson wrote:
> Raj Kunjithapadam writes:
> > Both are equivalent.
> > The simple answer is *NO*. Whitespace after each rdn is ignored.
>
> Raj, when then how do you explain the fact that a search starting at
>
> 'dc=xerox,dc=com'
>
> yields a DN for the entry with spaces when a search starting at
>
> 'dc=domain,dc=xerox,dc=com'
>
> does not?
>
> Bill A
begin:vcard
n:Kunjithapadam;Raj
tel;cell:408-504-3254
tel;home:510-651-9978
tel;work:650-569-5733
x-mozilla-html:TRUE
org:@Home Network;Set Top Engineering
adr:;;4023 Budwing Terrace;Fremont;CA;94538;US
version:2.1
email;internet:rajk@home.com
title:Software Engineer
x-mozilla-cpt:;0
fn:Raj Kunjithapadam
end:vcard