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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:47 AM 2002-11-15, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>> I don't quite follow this.  Do you mean that slapd.conf would
>>> configure a list of prefixes (in this case just "e-geopolitical-")
>>> which would work the same way as "lang-"?
>> 
>> Yes.  Basically, have a directive like:
>> 
>> tagOptionPrefixes "lang-" "e-geopolitical-" "e-user-"
>
>Should it be possible to configure away language support?
>I think I'd prefer to always have "lang-" supported.

While I generally prefer to have language tag/range support
available, others may not.  

>Also, I'd remove the quotes in the option above.

They are not part of the option.. the parser will remove them
automatically (if present).

>> which would all be treated as language/range options are treated
>> today.
>
>Well, chief, should I implement that, or keep my bit-flag user-defined
>options, or both?

I'm thinking both would be generally useful...

>> I note that in implementing either (or both) approaches, be
>> sure that options are generating in ascending order in all
>> attribute descriptions produced.
>
>Why?

RFC 2251:
   Implementations MUST generate the <options> list sorted in
   ascending order

(this requirement may be lifted by LDAPBIS)

> The server must compare them in sorted order internally, so that
>;x;y = ;y;x, but I'd think it would be good enough to send an attribute
>description the same way it was added.

The question is, are there clients which expect ascending order?
Likely not, but...

>> Also, these user-defined options should all be treated as "tagging"
>> options (per draft-ietf-ldapbis-models-xx.txt) in terms of attribute
>> hierarchy and other models aspects.
>
>Heh.  It hadn't even occurred to me that other kinds of options might
>exist, until I read that.

;binary is a classic example of a non-tagging (non-subtyping) option.