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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 Mar 2001 08:56:14 -0800

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 14 Mar 2001 20:53:08 -0700

I'd like to find a general way in the protocol document to make a distinction between "transfer specifier options" and "subtyping options". Once that is done, I'd like to make the "An AttributeDescription with one or more options is treated as a subtype" statement apply ONLY to "subtyping options".

Are there reasons not to do this?  If so, I'd have to vote that each "transfer specifier option" specify whether or not it is an exception to the subtype rule (more explicitly than is currently being done).

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 3/14/01 9:56:14 AM >>>

That is,

Ugh.

Kurt

---

From: "Timothy Hahn" <[email-masked]>
Date: Thu, 15 Mar 2001 00:44:59 -0500

Jim,

Such a categorization sounds like an interesting idea.

However, we should phrase this is such a way that all future attribute 
descriptions that are created/defined MUST declare whether they are 
"subtyping options" or NOT.  (I don't think it's required that we 
necessarily know that they are "transfer specifier options" - it seems 
sufficient that we would know that they are NOT to be considered for 
"subtyping").

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        [email-masked]
To:     <[email-masked]>, <[email-masked]>
cc: 
Subject:        Re: ;binary and (supertypes of an attribute description)

I'd like to find a general way in the protocol document to make a 
distinction between "transfer specifier options" and "subtyping options". 
Once that is done, I'd like to make the "An AttributeDescription with one 
or more options is treated as a subtype" statement apply ONLY to 
"subtyping options".

Are there reasons not to do this?  If so, I'd have to vote that each 
"transfer specifier option" specify whether or not it is an exception to 
the subtype rule (more explicitly than is currently being done).

Jim

That is,

Ugh.

Kurt

---

From: "Slone, Skip" <[email-masked]>
Date: Thu, 15 Mar 2001 14:07:10 -0500

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:[email-masked]]
Sent: Wednesday, March 14, 2001 11:56 AM
To: [email-masked]
Subject: ;binary and (supertypes of an attribute description)

That is,

Ugh.

Kurt