[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: RFC 2596 questions
Jim,
> -----Original Message-----
> From: Jim Sermersheim [mailto:JIMSE@novell.com]
> Sent: Tuesday, 24 October 2000 5:23
> To: Kurt@OpenLDAP.org; d.w.chadwick@salford.ac.uk
> Cc: ietf-ldapext@netscape.com
> Subject: Re: RFC 2596 questions
>
>
> And this is one of my concerns about specifying any kind of multiple
> attribute subtype inheritance via attribute type options. I imagine that
> X.500 vendors may want to reuse whatever attribute subtyping mechanisms
> they already have when implementing support for attribute type options.
It's not so much a desire as a necessity. I use the existing subtyping
mechanism to deal with LDAP attribute options because I don't currently
have an alternative. As a solution it has its drawbacks.
One drawback is the potentially large number of attribute definitions.
If there are N attribute types that can have M different options then
there must be N x M explicit subtype definitions. I also need to find OIDS
for each of these. There is no imperative from the LDAP side of the fence
that causes these OIDs to be defined and no imperative for the notional
optioned subtypes to be defined as explicit subtypes in a subschema
subentry.
There are also the problems that the X.500 ATTRIBUTE information object
and the AttributeTypeDescription ASN.1 type only allow a single supertype,
and some attribute options, like ";binary", are non-sensical as subtypes
from
the X.500 point of view (because everything there is ";binary").
One solution to align LDAP attribute options with X.500 is for X.500
to revise the attribute descriptions to allow multiple inheritance,
and for LDAP to formally require optioned attribute types to be explicitly
defined in subschema as subtypes of the unoptioned attribute type.
I don't expect the latter to happen. LDAP-only vendors don't get any
benefit to make it worthwhile for them to support such a requirement.
A second solution is for X.500's attribute type to be extended to
carry attribute options. That would require extensive changes
but at least LDAP and X.500 would be brought into perfect alignment with
regard to attribute options (once we've sorted out exactly how attribute
options are supposed to work, of course).
The required changes to search filters, etc, to support attribute options
in the X.500 protocols would be much like the changes already
made to support contexts, so I've recently been revisiting the question
of how contexts could be used to represent attribute options in the
X.500 protocols and data model.
An X.500 context has a type and one or more values. An attribute value can
have zero, one or more contexts. The obvious mapping from attribute options
to contexts is for each kind of option (e.g. language tags) to be
represented
by a context type, and each option of that kind (e.g. lang-en, lang-jp)
to be represented by a value of the context type.
An AttributeValueAssertion may contain one or more context assertions
which, if present, must also be satified for a match to return true for
a particular value. The context assertions can be written as a conjunction
or a disjunction of context types and values. The conjunctions are most
useful here. The context assertions also apply to any attribute subtypes.
What this all means is that there is a straightforward mapping that
gives the apparent LDAP behaviour that a request for name;a;b will match
name;a;b, name;a;b;c, sn;a;b, sn;a;b;c, among other things (i.e. name,
or any of its attribute subtypes, that has at least the attribute
options ;a and ;b). The order of context values is not significant so with
the simplest mapping to contexts, sn;a;b is the same as sn;b;a.
There is a problem though. An attribute value also matches a context
assertion
if it does not have any context values of the context type in the assertion.
So for example, a request for sn;lang-en can also return attribute
values of just sn. The model used seems to be that an attribute value
without
a context value for a specific context type implicitly has all possible
values of that context type. I need it 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.
A much cleaner solution would be the ability to define a context type
where context assertions for that context type evaluate to false for
attribute values not having the context type, instead of evaluating to true.
This leads me to a proposal for sorting out the LDAP attribute options and
their relationship to X.500:
(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 (I prefer 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.
> I also just don't like stating that an attribute type options is a subtype
> and then having a set of (unspecified) exceptions to that statement.
>
> It would be preferable if 2251 stated that AttributeDescriptions with one
> or more options are *sometimes* treated as subtypes of the attribute type
> without any options, and then go on to explain whatever nuances we agree
> they have.
Even better (assuming a mapping to contexts) if the effect of an
AttributeDescription is described without using the word "subtype".
Regards,
Steven
>
> Jim
>
>
> >>> "David Chadwick" <d.w.chadwick@salford.ac.uk> 10/21/00 3:04:00 PM >>>
> Date forwarded: Sat, 21 Oct 2000 12:11:09 -0700 (PDT)
> Date sent: Sat, 21 Oct 2000 12:10:31 -0700
> To: d.w.chadwick@salford.ac.uk
> From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
> Subject: Re: RFC 2596 questions
> Copies to: <ietf-ldapext@netscape.com>
> Forwarded by: ietf-ldapext@netscape.com
>
> > At 07:58 PM 10/21/00 +0100, David Chadwick wrote:
> > >I think this is pretty conclusive evidence that multiple superclasses
> > >are supported (i.e. multiple inheritance)
> >
> > Of object classes, yes.
> > But we're talking about multiple inheritance of attribute types.
> >
> >
> Slight disconnect there !.
> I agree that multiple inheritance of attribute types is not supported
> by X.501
>
> David
>
>
> ***************************************************
>
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351 Fax +44 161 745 8169
> Mobile +44 790 167 0359
> Email D.W.Chadwick@salford.ac.uk
> Home Page http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
>
> ***************************************************