The thing proposed by Emmanuel is called Contexts in X.500 and they are only used for language tags in LDAP. (Please correct if I am wrong.) In fact, Contexts can be used for anything and they are subject to X.500 facilities like Access Control. However LDAP only took them as language tags and there is no reason to extend the intent to use them in a generic manner.
BTW, about the Families of Entries, I had noted down some links here: http://cwiki.apache.org/confluence/display/DIRxSRVx11/The+need+for+Families+of+Entries+in+LDAP They can be used for much wider purposes than Contexts. I hope we have time to implement them. On 1/22/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 1/21/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: ... > Well, I don't know to much about famillies, but I think that we might > workaround the problem of first email, second email, etc by using > attribute descriptions options : > > mail;primary: [EMAIL PROTECTED] > mail;office: [EMAIL PROTECTED] Could this technique also be used for multiple attributes that are typically grouped together? As a specific example, would you do this with addresses, say for a shipping address vs. a secondary shipping address? In RFC 2596 the technique is used for language codes: streetAddress: 1 University Street streetAddress;lang-en: 1 University Street streetAddress;lang-fr: 1 rue Universite Would it make sense to handle shipping address vs. secondary shipping address attributes (from RFC 2256: X.500 User Schema) this way? street;home: 5 Main St. street;work: 10 Commercial Way ... similarly for st, l, and c (state, locality, and country). Enrique
-- Ersin
