Yep I stand corrected.  If it's of any consolation I've been corrupted by JNDI which often refers to an RDN litterally as a relative name, relative to a context which can be of any length. 

Emmanuel is correct here since JNDI is far from being consistent about LDAP. 


On 4/10/07, Emmanuel Lecharny <> wrote:
Alex Karasulu a écrit :

> I did intend what I wrote.

Then you should not have ;)

> An RDN does not necessarily mean one name
> component.

Nope, a RDN is described in the RFC as a cobinaison of atavs, separated
by '+', as stated by RFC 2253 :

"In X.501 [2] the ASN.1 structure of distinguished name is defined as:

       DistinguishedName ::= RDNSequence

       RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF

       AttributeTypeAndValue ::= SEQUENCE {
        type  AttributeType,
        value AttributeValue }

   The following sections define the algorithm for converting from an
   ASN.1 structured representation to a UTF-8 string representation.

2.1. Converting the RDNSequence

   If the RDNSequence is an empty sequence, the result is the empty or
   zero length string.

   Otherwise, the output consists of the string encodings of each
   RelativeDistinguishedName in the RDNSequence (according to 2.2),
   starting with the last element of the sequence and moving backwards
   toward the first.

   The encodings of adjoining RelativeDistinguishedNames are separated
   by a comma character (',' ASCII 44).

2.2.  Converting RelativeDistinguishedName

   When converting from an ASN.1 RelativeDistinguishedName to a string,
   the output consists of the string encodings of each
   AttributeTypeAndValue (according to 2.3), in any order.

   Where there is a multi-valued RDN, the outputs from adjoining
   AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
   character. "

I have spent so much time to write those damn DN decoding to at least be
100% sure of that ;)