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.