RE: multiple values in ldap question

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Will Holcomb

> This question is not exactly openldap specific, but I am using openldap in
> a program where I am facing this issue. =) LDAP has schemas that define
> what value is allowed where and certain values are "multivalued" meaning
> there can be more than one instance, right? As best I can tell the common
> way is to define a new entity type for every possibility.

You mean "Attribute Type" and in the context of your question, defining new
attributeTypes has nothing to do with whether you intend them to be multivalued
or not. "Multivalued" means multiple values for a single attributeType. You
would only utilize this approach when the values all have exactly the same
semantics, and don't need to be further distinguished. E.g., an entry with:
	cn: James Jones
	cn: Jim Jones
	cn: Jimmy Jones

You don't need to put these values into separate attributeTypes because they
are all equivalent as far as you care.

When you actually want to enable a distinction, such as between Home Address
and Work Address, then you need to use a separate attributeType for each.

> I am working on a program for a school. I have students that have a school
> address (campus box), home address (their actual house), parent's address
> (which is sometimes mother's address and father's address.) If I were
> doing this in the way it is usually done I would define a new entity type
> for each of those, right? And then all of the info would be in the entry,
> so I would have no good way to distinguish between someone who lived in
> Joneboro, Tennessee and someone who lived on Jonesboro Road in neighboring
> Bristol, Tennessee. Since a search for homeAddress=*Jonesboro* would
> return both.

This depends on your particular use of the attribute syntaxes. LDAP is a rather
poor example to work from here because most of the commonly used syntaxes in
LDAP are basically unstructured, and they all devolve into "octet string." This
means that while there may be conventional ways to use a particular syntax,
there is nothing in the protocol or the implementations that enforces any
internal structure in a given attribute value. (Again, I'm only talking about
what's in common use. There are plenty of truly structured syntaxes as well,
e.g. userCertificate. In the X.500 world, structure is the norm, not the
exception. LDAP installations tend to flatten or ignore these structures when
they can...)

Anyway, the point is, you can store whatever you want into a homeAddress
attribute. The common use is to just store exactly what you'd write for a
particular address, with some line delimiters thrown in:
	homeAddress: 1221 Circle Lane $ Nowheresville, Shock 98765-4321

But there's nothing that says you can't impose a more artificial, useful
structure on this value:
	homeAddress: number=1221 $ street=Circle Lane $ city=Nowheresville $
state=shock $ zip=98765-4321

You just have to make sure that your application software that drives access to
the directory is written to use the format that you decide upon. With this
approach, you can easily distinguish the two cases you described above:
	(homeaddress=city=Jonesboro)
	(homeaddress=street=*Jonesboro*)

> Why is this preferable (other than incompatabilities with existing
> schemas) to making an address node type in the tree and it having a type
> attribute which has a certain set of allowed values? This would allow
> adding new types without redefining the schema and allow me to search for
> &(type=home, city=Jonesboro).

Breaking up entries into clusters of entries becomes very clumsy. E.g., if you
want to search based on a value stored in a subordinate object, you have to
obtain that object and then perform a second search on the object's parent's DN
in order to obtain the entire cluster. Object deletion, renaming, etc. all gets
that much more unwieldy.
>
> I like ldap and I want to use the technology, and I am just trying to
> understand it to that end.

Good, that's a lot better than most people who just try to use it without
understanding it. LDAP itself is useful for far more than the dry old examples
and "common knowledge" would lead you to believe. You just need a little
creative thinking to make it solve your problems effectively.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support