RE: ;binary and (supertypes of an attribute description)

["Slone, Skip" <skip.slone@lmco.com>]

This subtyping issue has hit the X.500 group's radar screen with respect to
LDAP/X.500 alignment.  Our latest working document (should be posted soon)
has an editor's note drawing attention to this issue.  The note, adapted
mostly from the words of Steven Legg, is shown below. The suggested actions
seem to be divided across X.500, LDAPbis, and LDAPext areas of concern.

I will be at IETF#50 and will be interested in getting feedback on this
issue.

 -- Skip Slone

==========================================

Editor's Note 5: There have been electronic mail-based discussions between
X.500 experts and LDAP experts with respect to a misalignment between LDAP
attribute options and X.500 contexts.  The alignment problem has been
described as follows:  
	In X.500, an attribute value matches a context assertion even if it
does not have any context values of the context type in the assertion. For
example, when processed by an X.500 DSA, an LDAP request for "sn;lang-en"
can also return attribute values of just "sn". That is, an attribute value
without a context value for a specific context type implicitly has all
possible values of that context type. In LDAP, it is expected to be treated
as though it has none of the possible context values. To get the desired
behaviour it would be necessary to add something like a "lang-null" context
value (hidden, as an attribute option, from LDAP clients) to *all* attribute
values that don't otherwise have a language context and to translate all
requests for the attribute type without options into requests for attribute
values with the lang-null context value. Apart from being messy, this
workaround requires fore knowledge of all the context types a server is
going to receive in requests, and isn't really backward compatible with an
X.500 server not supporting attribute options through contexts.
To resolve this problem, the following proposal has been made: 

(1)	In X.500: extend the CONTEXT information object to include a new
optional field that specifies whether a context assertion on the context
type returns true (current behaviour) or false for values not having the
context type.

(2) Somewhere (a new RFC ?): define a CONTEXT information object for LDAP
attribute options using the new field, and describe the mapping from
attribute options into this new context type, noting that some options (e.g.
;binary) don't map to context values.

(3) In LDAPbis (RFC 2251): describe the attribute options in a way that is
consistent with the behaviour resulting from (2), and as something clearly
separate from the attribute type hierarchy.

(4) In LDAPbis (RFC 2252): change the ABNF to disallow the use of attribute
options on attribute types in the NAME and SUP fields of an
AttributeTypeDescription, the MUST and MAY fields of an
ObjectClassDescription, and the APPLIES field of a
MatchingRuleUseDescription.

(5) Somewhere (the new RFC): define a schema operational attribute, e.g.
called AttributeOptionUse, to capture any capability anyone thinks is lost
from doing (4), and/or to add an ability to control how attribute options
are used in a subschema administrative area.

National Body comments on this proposal are requested, specifically with
respect to item (1).

==========================================

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, March 14, 2001 11:56 AM
To: ietf-ldapbis@OpenLDAP.org
Subject: ;binary and (supertypes of an attribute description)


The essence of this issue is application of:
   An AttributeDescription with one or more options
   is treated as a subtype of the attribute type
   without any options.

to an AttributeDescription such as userCertificate;binary
and the description that the binary transfer option.

That is,
   userCertificate;binary is treated as a subtype of
   userCertificate.

and section 4.1.5.1 implies that userCertificate;binary
is NOT to be treated as a subtype of userCertificate.

Ugh.

Kurt