[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Feature discovery (Was: RFC 2596 questions)
Send reply to: <steven.legg@adacel.com.au>
From: "Steven Legg" <steven.legg@adacel.com.au>
To: <d.w.chadwick@salford.ac.uk>
Copies to: <ietf-ldapext@netscape.com>
Subject: RE: Feature discovery (Was: RFC 2596 questions)
Date sent: Fri, 22 Sep 2000 11:37:14 +1100
Steven
You raise a number of interesting questions below. I think that there
are two different issues to be addressed, namely
i) whether to have dynamic attribute subtyping with schema
definitions that link subtypes to attributes at runtime, and individual
implementations decide dynamically which ones they can support
(this is similar to the matchingRuleUse system schema definition
currently defined in X.501) or
ii) having static definitions with fixed OIDs (which is what my
previous message was suggesting)
The second issue is how to unambiguously represent an attribute
subtype in protocol. We could use either or both of OIDs and ldap
strings. We currently have neither of these as ldap strings are only
locally defined and there is no current way of automatically
generating an OID representation. YOur message below gave one
suggestion for the latter. The Internet 2 folks were suggesting
globally unique strings for ldap attribute types as a solution to the
former.
Of course if we only have static definitions with fixed OIDs then
both problems are solved, but as you point out there could be an
explosion of new static definitions.
I suggest that this work should be defined in conjunction with the
X.500 group, since they now have an LDAP alignment work item,
and the work seems to me to be of a fundamental basis.
We could for example suggest a change to the ASN.1 of an
attribute type by making it a sequence of OIDs with an optional
subtype qualifier OID after the mandatory attribute type OID.
However we proceed, this is not a particularly easy problem to
solve,
David
>
> David,
>
> > -----Original Message-----
> > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk]
> > Sent: Friday, 22 September 2000 3:51
> > To: Jim Sermersheim; ietf-ldapext@netscape.com; kgdaniec@us.ibm.com
> > Subject: Re: Feature discovery (Was: RFC 2596 questions)
> >
> >
> > Date forwarded: Fri, 15 Sep 2000 14:30:17 -0700 (PDT)
> > Date sent: Fri, 15 Sep 2000 15:28:50 -0600
> > From: "Jim Sermersheim" <JIMSE@novell.com>
> > To: <ietf-ldapext@netscape.com>,
> > <kgdaniec@us.ibm.com>
> > Subject: Re: Feature discovery (Was: RFC 2596 questions)
> > Forwarded by: ietf-ldapext@netscape.com
> >
> > > You mean advertised in the schema, right? I would say yes, I think
> > > there should be another schema element called something like
> > > attributeTypeOptions, the syntax would look something like this
> > > (ala 2252 nomenclature):
> >
> > Jim
> >
> > The only problem with your approach below is that you are
> > effectively defining a whole new set of attribute subtypes, without
> > assigning OIDs to the subtypes. Although it is more longwinded, I
> > would prefer an approach where every subtype was specified in its
> > own right as an attribute type, and had its own OID allocated to it.
>
> I agree with the sentiment since I have to translate LDAP attribute
> descriptions into OIDs to pass around in the DSP and DISP protocols. I
> can define the OIDs for the implied subtypes from an OID arc I have
> authority over but that doesn't help interoperability any. It would be
> very helpful to me to have the OIDs for subtypes predefined, but there
> are some definitional problems in practice.
>
> If we have N attribute types, and M options we want to use with those
> attribute types, then we have to define NxM OIDs. It isn't clear who
> should be responsible for defining those OIDs. If I define a new
> attribute type should I also define the OIDs for the subtypes
> corresponding to the options I know about ? What happens when new
> options are defined by someone else later ? If I define a new option
> am I required to define the OIDs for all the potential attribute types
> the option could applied to ? Then what happens when new attributes
> are defined ?
>
> Two of the possible strategies for a solution are:
>
> 1) Try to get the X.500 standard extended to allow attribute options
> to be conveyed along side the attribute type OIDs in the protocols.
>
> 2) Invent an algorithmic way to derive OIDs for an arbitrary
> attribute type and option combination.
>
> By way of a solution for 2) we could require that each option have an
> OID defined for it. Then the OID for the subtype implied by the option
> <option-oid> applied to the attribute type <attribute-oid> is the
> concatenation <option-oid>.<attribute-oid> . For example, if I define
> a new option "foo" with the OID 1.2.36.79672281.1.30.1 and I want to
> apply it to the commonName attribute I end up with a subtype cn;foo
> having the OID 1.2.36.79672281.1.30.1.2.5.4.3 .
>
> The concatenation <attribute-oid>.<option-oid> would actually make
> more sense but we have no authority to extend the vast majority of
> existing attribute OID arcs. Attribute options don't currently have
> OIDs so we can require that the arcs below the option OID are left
> open for any legitimate OID to be appended. The scheme also works if
> two or more option OIDs are concatenated, with the attribute type OID
> appended to the end.
>
> Regards,
> Steven
>
> >
> > By way of example, taking cn;lang-fr as a subtype of common name
> > we should be able to define
> >
> > ( x.y.z NAME 'frenchname' SUP cn )
> > -- all values to be in French
> >
> > or (x.y.z NAME 'cn;lang-fr' EQUALITY caseIgnoreMatch
> > SUBSTR caseIgnoreSubstringsMatch
> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
> >
> > or even (x.y.z NAME 'cn;lang-fr' SUP cn)
> >
> > These should all be equivalent and allowed. This would necessitate a
> > change to the BNF to allow ;options to be included in attribute
> > types.
> >
> > A user can then request French common names by either asking for the
> > frenchname attribute or the cn;lang-fr attribute values.
> >
> > David
> >
> >
> > >
> > > AttributeTypeOptionDescription = "(
> > > numericoid whsp ; Attribute Type Option Identifier
> > > [ "NAME" qdescrs ]
> > > [ "DESC" qdescrs ]
> > > [ "OBSOLETE" whsp ]
> > > "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE")
> > oids) ; list of
> > > syntaxes or attributes that this ATO applies to. whsp ")"
> > >
> > >
> > > Jim
> > >
> > >
> > > >>> <kgdaniec@us.ibm.com> 9/15/00 2:58:18 PM >>>
> > > Jim wrote:
> > > Whatever the discovery mech is, I'd rather we have it and be
> > > rarely used than not have it at all. Also, some things (like attr
> > > type options) need more than just an OID in a list. We need to
> > > specify where they can be used (which attrs or syntaxes support
> > > them).
> > >
> > > Doesn't this imply then that support of the attribute tags should
> > > be discovered as part of schema discovery?
> > >
> > > Karen
> > >
> > > Internet: kgdaniec@us.ibm.com
> > > Internal: Karen Gdaniec/Endicott/IBM@IBMUS or
> > > IBMUSM10(KGDANIEC)
> > > phone: 607.752.1075 tie-line: 8/852-1075
> > > fax: 607.752.3681
> > > ---------------------- Forwarded by Karen Gdaniec/Endicott/IBM on
> > > 09/15/2000 04:57 PM ---------------------------
> > >
> > > "Jim Sermersheim" <JIMSE@novell.com> on 09/15/2000 04:33:17 PM
> > >
> > > To: <Kurt@OpenLDAP.org>, Timothy Hahn/Endicott/IBM@IBMUS
> > > cc: <ietf-ldapext@netscape.com>
> > > Subject: Re: Feature discovery (Was: RFC 2596 questions)
> > >
> > >
> > >
> > >
> > > Whatever the discovery mech is, I'd rather we have it and be
> > > rarely used than not have it at all. Also, some things (like attr
> > > type options) need more than just an OID in a list. We need to
> > > specify where they can be used (which attrs or syntaxes support
> > > them).
> > >
> > > Jim
> > >
> > >
> > > >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 9/15/00 2:01:22 PM >>>
> > > At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com wrote:
> > > >Should we investigate some additional rootDSE attribute to
> > indicate
> > > >the
> > > set of attribute descriptions that are supported? Further, when
> > > a new attribute description is defined, should we be
> > assigning OIDs and
> > > keeping these as an additional part of the subschemasubentry data?
> > >
> > > I wouldn't mind too much having one attribute type
> > > "supportedFeatures" of syntax OID which listed "supported"
> > features.
> > > This could include MAYs and SHOULDs from the "core"
> > specification as
> > > well as any MAY, SHOULD, MUST of any extension. This
> > would provide a
> > > discovery mechanism for any feature you might want to
> > publish support
> > > for.
> > >
> > > However, I wonder the value of providing additional discovery
> > > mechanisms when the discovery mechanisms we already provide are
> > > rarely used and, in some cases, not needed or
> > inappropriate to use.
> > > [Discovery of StartTLS is not needed, discovery of SASL
> > mechanisms is
> > > inappropriate without appropriate consideration of security
> > > risks].
> > >
> > > Kurt
> > >
> >
> >
> > ***************************************************
> >
> > 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
> >
> > ***************************************************
> >
> >
>
***************************************************
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
***************************************************