Re: supertypes of an attribute description

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

There is an interesting side issue regarding supertypes
of attribute descriptions contain transfer options
(e.g. ;binary).  My initial thoughts here is that the same
rules apply for determining what are the supertypes
of an attribute description containing a transfer
option as any other option.  And that the non-typical
features are just restrictions upon the use of the option.

First, transfer options are mutually exclusive.  That is,
an attribute description can contain only one transfer
option.

Also, when request attributes (in a search), all related
attribute descriptions should call for the same transfer
mode.  That is, they should either all contain no transfer
option or the same transfer option.  For example, say
there was a transfer option ";pem" in addition to ";binary",
and the requested attribute descriptions where:
        cn;lang-en;pem
        cn;binary;lang-de

and there was a value associated with:
        cn;lang-de;lang-en


The server shouldn't return both:
        cn;binary;lang-de;lang-en
        cn;lang-de;lang-en;pem

and:
        cn;binary;lang-de;lang-en;pem

is bogus.  I think the best solution is to just require
transfer modes to be consistent amongst all related
descriptions.  I say "modes" as requesting "cn,cn;binary"
problematic as well.

Also, as transfer options only impact transfer, there
needs to restriction that all values associated with the
same underlying attribute should be transferred in one
mode during the course of an operation.  That is, an
attribute returned by a search entry response or provided
with an add or modify request should be transferred
in whole as one element of the associated sequence.
That is:
        dn: cn=foo
        objectclass: bar
        cn: foo
        cn;binary:: <hex-encoded-BER-value>

(whether representing an Add request or Search entry)
is bogus.

But the problem is that an attribute description
less a transfer option and same attribute description
with a transfer option are NOT subtypes.  This is
clear in that displayName and displayName;binary
are not subtypes.  If they were subtypes, then
Modify/Delete of displayName would not delete
displayName;binary and Modify/Add of displayName;binary
would not add to displayName value and
        dn: cn=foo
        displayName: foo
        displayName;binary:: binary-value

would not violate the attribute's SINGLE-VALUE
constraint.

So, the statement:
   An AttributeDescription with one or more options
   is treated as a subtype of the attribute type without
   any options.

isn't actually consistent with how ;binary is treated.
I prefer not to rewrite the above to:
   An AttributeDescription with one or more options
   is generally treated as a subtype of the attribute
   type without any options.

as this would open the door to other options being
introduced which have any even more inconsistent with
subtyping mechanisms.  However, I don't have a better
solution.... do you?

Kurt

At 09:08 PM 3/11/01 -0800, Kurt D. Zeilenga wrote:
>At various times we (LDAPbis, LDAPext) have discussed
>what are the supertypes of an attribute description
>with multiple options, such as:
>        sn;a;b
>
>In drawing from these discussions, I believe there is
>some agreement that the supertypes should be:
>        sn;a (*)
>        sn;b (*)
>        sn
>        name;a;b (*)
>        name;a
>        name;b
>        name
>
>(* direct supertypes)
>
>This is consistent with:
>        An AttributeDescription with one or more options is
>        treated as a subtype of the attribute type without
>        any options.
>
>(and, I believe, most implementations).  However, this statement
>can easily be misinterpreted as: 
>        An AttributeDescription with one or more options is
>        treated as a direct subtype of the attribute type without
>        any options.
>
>as LDAP/X.500 attribute type subtyping does not support multiple
>inheritance.  I feel a clarification is in order, preferable
>with an example (such as the one above).
>
>Comments?
>
>Kurt