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

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

At 08:00 AM 2002-11-10, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 04:52 AM 2002-11-09, Hallvard B Furuseth wrote:
>> 
>>> Besides, I just finished coding user-defined attribute options:  Since I
>>> thought I'd have to implement a new option anyway, I could just as well
>>> generalize. 
>> 
>> I suggest that each of these user-defined attribute options have
>> a common prefix (e.g, ";x-user").
>
>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).  One could support the concept of range
options could also be supports for the tag options.

Code wise, they could implemented simply by changing ad.c:
        } else if ( optlen >= sizeof("lang-")-1 &&
            strncasecmp( opt, "lang-", sizeof("lang-")-1 ) == 0 )
        {

to:
        } else if (( optlen >= sizeof("lang-")-1 &&
               strncasecmp( opt, "lang-", sizeof("lang-")-1 ) == 0 ) ||
            ( optlen >= sizeof("e-user-")-1 &&
              strncasecmp( opt, "e-user-", sizeof("e-user-")-1 ) == 0 ))
        {

and:
            if( nlang >= MAX_LANG_OPTIONS ) {
                *text = "too many language options";
                return rtn;
            }

to:
            if( nlang >= MAX_LANG_OPTIONS ) {
                *text = "too many tagging options";
                return rtn;
            }

That is, these options are just like language options, they
are both "tagging" options.  The code should treat them the
same.

>I've looked again at RFC2251, and all it says is
>
>   Options beginning with "x-" are reserved for private experiments.
>
>I think OpenLDAP should follow suit: Reserve a namespace for users, but
>don't enforce it.  If the user wants a shorter option name and is
>prepared to risk that OpenLDAP may use that option name in the future,
>that's his decision.

Actually, I think "e-user-" is best prefix for "user defined
tagging (and range) options".

>(The same way, if OpenLDAP wants to define a new option some day, it
>looks like a valid approach to not use the 'x-' prefix: Instead try to
>get out an RFC with the option as soon as possible, while hoping that
>nobody else will grab it first.  I don't know which way I'd prefer.)
>
>> Coding wise, they would be just like language tag/range
>> options... except the option name would have user defined meaning.
>
>Actually I coded them as bit flags.  Each option defined in slapd.conf
>gets its own bit.  That seemed to be quicker and easier.
>
>Here is a preliminary patch, if anyone is interested:
>
>  http://folk.uio.no/hbf/OpenLDAP/attr-options.txt
>
>Yet to do:
>
>- I'd like to handle ";binary" the same way as user-defined options,
>  instead of having a special case for it, and move the binary flag
>  from AttributeDescription.ad_flags to .ad_options.
>
>- I could merge AttributeDescription.ad_flags and .ad_options into
>  one value `ber_uint_t ad_flags'.  16 bits could be reserved for
>  OpenLDAP flags and options, the rest for user-defined options.
>  Flags like SLAP_DESC_LANG_RANGE would be in the most significant bits,
>  predefined options like ;binary in the least significant bits.
>
>- A slapd.conf directive 'access to attr=;options ...' which would apply
>  to all attributes with those options.
>
>- document (and maybe enforce) the ";x-user-" namespace.
>
>-- 
>Hallvard