Re: ;binary and *

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

At 07:43 AM 2002-03-04, Michael Ströder wrote:
>Kurt D. Zeilenga wrote:
>>At 04:33 AM 2002-03-04, Michael Ströder wrote:
>>
>>>David Chadwick wrote:
>>>
>>>>>OR not return the attribute.
>>>>Absolutely not. The user has asked for ALL attributes. Unless access
>>>>controls prevent it, all should be returned, even if the user cant
>>>>handle them.
>>>>For example, pictures should be returned, even though today
>>>>some well known windows clients cant display them (whilst others can).
>>>I concur.
>>>
>>>
>>>>This is no different to sending others back using ;binary encoding. The
>>>>server does not know what the client supports, so should assume it can
>>>>support everything since it has not limited what it wants.
>>>Yes.
>>Then clients MUST treat any attribute description which contains
>>an unrecognized option as unrecognized.
>
>Do you think that's a big difference to what LDAP clients are
>already doing today?

Yes.  There are many clients today which implement "An
AttributeDescription with one or more options is treated as a
subtype of the attribute type without any options."

>> Clients cannot simply
>>treat attributes with unrecognized options as an (indirect)
>>subtype of the attribute description with the same attribute
>>type and no options.
>
>So what?

This will break all those clients which do treat attribute
descriptions with one or more options as a subtype of the
attribute type without any options.

>Frankly I wouldn't expect most LDAP applications to treat e.g. cn;lang-de-DE automagically as a sub-type of cn if the application wasn't explicitly designed to handle language sub-types.

An LDAP client can generically support all attribute description
subtyping without specifically implementing language tag options.

>I also can't imagine an exact behaviour a LDAP application should have. I'd consider it rather as opening a can of worms.

The application should behave as if they are subtypes. For example,
a client which is designed to display all attributes of directory
string syntax can simply display all subtypes of attribute types
with that syntax.  However, if one of the options could be
a unrecognized transfer option, then it MUST treat all unrecognized
options as unrecognized transfer options.

>>It is a really bad idea for servers to assume clients support
>>anything which is not REQUIRED.
>
>IMHO it's also a bad idea for servers to assume which attributes a client cannot handle based on what the client requested or did not request when using *.
>I think I'd vote for assuming that client applications would be at least smart enough to move unhandled attribute types to /dev/null.

Then one needs to change:
   A server will treat an AttributeDescription with any options
   it does not implement as an unrecognized attribute type.

   A server or a client will treat an AttributeDescription with
   any options it does not implement as an unrecognized attribute
   type.  Clients and Servers cannot assume that an AttributeDescription
   with any options it does not implement is a subtype of the attribute
   type without any options.