ken rossen is correct here. since we are talking about a multi-valued rdn, the
attributes are all in the same entry. one can only have one occurance of a type
in an entry, therefore multiple values for the same type are stored as a single
occurance of the type with multiple values. and as ken points out only one
value in the set can be distinguished, i.e., can be used in an RDN.
however there is no problem with the order since order is meaningless in an
rdn. that is, (o=DBC,l=Mountain View) is equivalent to (l=Mountain View,
o=DBC). so tom jones's construct could be supported but is specifically
excluded.
i suspect this restriction goes back to the very early days when it was
required that the supplied name be unordered and multiple occurances of the
same type was forbidden (this never made the final 1988 standard). if fact this
view was strongly held by the x.400 guys who participated in the directory work
which is why you see such things as ou1, ou2, etc. in x.400. although the
directory group went to an ordered sequence of name components we never
revisited the distinguished value restriction.
i have never heard a request that this restriction be removed. i suspect this
is because one could satisfy your naming example by having l=santa clara be the
name of the immediately superior entry. suggested structure rules do permit
locality being an immediate subordinate of locality, and since the name is a
sequence of rdns, we don't need to have l1, l2, etc.
it difficult to change things having to do with naming since it can be fraught
with migration and co-existance problems. however, if a requirement arose we
could revisit the issue (but not now while i am trying to get 93 out).
hoyt