[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: User-defined attribute options (Was: Suggestion: attribute;search)

At 07:59 AM 2002-11-11, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>> I like ;x-user-, but I don't agree that such names should be enforced.
>> 
>> Well, I'm thinking that a descrFamily- (RFC3383) should be
>> registered to handle this.  For example, "e-user-" or "e-u-".
>> Could even be "user-", but likely this would require some
>> form of technical specification to be written.
>>
>> Tag options in this family would be arbitrary (defined by the user
>> without restriction).
>
>If so, I suggest 'e-dist-' or 'dist-' as well - for the _distributor_ of
>precompiled LDAP packages.  Though it might still be a little difficult
>for some people to decide which name space to use.

I'll come back to the prefix issue later on.


>> One could support the concept of range
>> options could also be supports for the tag options.
>
>If you are comparing with language ranges, I don't know what they are or
>how they work, all I know is the code seems to support them.
>(SLAP_DESC_LANG_RANGE.)

Basically, they allow matching against a range of tags.
For example, requesting "cn;lang-de-" matches "cn;lang-de",
"cn;lang-de-ch", etc.  See RFC 3066 and
draft-zeilenga-ldap-rfc2596-xx.txt.  


>> Code wise, they could implemented simply by changing ad.c:
>>         (...)

I'm now thinking that instead of having an extensible array
of option tag/range prefixes.  The default would be "lang-".
This could be extended by a configuration directive to support
other hierarchically tags.  For a (contrived) example,
"e-geopolitical-" could allow:  telephone;e-geopolitical-us-ca-sf
(City and County of San Franscisco, State of California, United
States) vs. telephone;e-geopolitical-us-ca-sm-rwc (Redwood City,
County of San Mateo, State of California, United States).

>> That is, these options are just like language options, they
>> are both "tagging" options.  The code should treat them the
>> same.
>
>I suppose so, but isn't the language code rather slow?

Maybe.  The code may be doing more.