RE: Compound Attribute Support in LDAP

[Howard Chu <hyc@highlandsun.com>]

It's an interesting proposal. I wish a different example was chosen; it
makes it hard to view this facility in a generally useful context. I kept on
tripping up over silly points like "well, ZIP codes could be 5 or 9 digits"
or "why not use the state-or-province and/or locality attributes" or "this
example is only illustrative in the USA" etc. etc...

You might be able to make a good case for this feature, but I don't think
your chosen example helps your case. I also was somewhat dismayed that I had
to read thru at least 4 pages of text before I even knew for sure what you
meant by the term "Compound Attribute." If you can't define it up-front and
immediately, then you should avoid using the term until you have actually
established enough context and presented the definition.

There are other instances of structured attributes already, such as
NameAndOptionalUUID. I like this compound approach better, because it allows
compounds to be constructed that can be interpreted by any client that knows
how to retrieve schema. (Whereas, with NameAndOptionalUUID, if the client
doesn't recognize this syntax OID, it has no idea what to do with it.) The
ability to use this approach to define new compounds that any compound-aware
client will be able to deal with is a nice advantage.

Something about this proposal keeps reminding me of X.500 named attribute
sets. It strikes me that if you really want to be able to search on various
components of something, that those components ought to be individual
attributes. Especially in an example like the current one - the individual
fields that make up a postal address are interesting enough on their own to
warrant their existence as independent attributes. It would be annoying to
use something like this if it meant duplicating values in two different
attributes - e.g., using the locality attribute in addition to the
snail-mail attribute. Again, the example gets in the way of presenting the
functionality. With the given example, it seems what you really want is to
have individual name, street, city, state, zipcode, and country attributes,
but the ability to use a nickname (e.g., a named attribute set) to grab all
of them at once, occasionally.

Finally, I'm not so sure that security issues are not applicable here. If
you don't propose a mechanism for handling access control on individual
components of a compound, I think you are missing something. (And on the
flip side, not wanting to complicate access control issues even further by
needing to get more granular than attribute-level control, I again conclude
that this compound idea is more trouble than it's worth.)

> -----Original Message-----
> From: Vipul Modi [mailto:MVIPUL@novell.com]

> Please check out the Internet Draft
> http://www.ietf.org/internet-drafts/draft-vmodi-ldapext-compound-a
> ttr-00.txt
>
> Abstract:
>
>    This draft describes the method of providing Compound Attribute
>    Support in LDAP. The draft proposes a modification to
>    AttributeTypeDescription syntax in order to be able to describe any
>    Compound Attribute. The draft describes the syntax definition for
>    any Compound Attribute, and hence the method for encoding its
>    values. The usage of Compound Attribute in LDAP requests and
>    responses is also described.
>
>
> Comments on the same are most welcomed.
>
> Regards,
>
> Vipul Modi.
> Software Consultant,
> Novell Inc.
>
>
>
>