[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: Feature discovery (Was: RFC 2596 questions)

To: <d.w.chadwick@salford.ac.uk>, <ietf-ldapext@netscape.com>
Subject: RE: Feature discovery (Was: RFC 2596 questions)
From: "Steven Legg" <steven.legg@adacel.com.au>
Date: Mon, 2 Oct 2000 11:21:40 +1100
Cc: <osidirectory@az05.bull.com>
Importance: Normal
In-reply-to: <39CC9E0A.11579.5AAFC3@localhost>
David,

> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk]
> Sent: Saturday, 23 September 2000 22:12
> To: Steven Legg; steven.legg@adacel.com.au; ietf-ldapext@netscape.com
> Cc: osidirectory@az05.bull.com
> Subject: 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)

I wasn't really aiming at dynamic attribute subtyping (though it's
doable) but rather at being able to choose an OID for an attribute
with option that is the same as what everyone else chooses.

> 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.

Would these globally unique strings be things like,

employeeNumber.attributeType.adacel.com.au

and/or,

joint-iso-ccitt.ds.attributeType.commonName

and/or ( :-) ),

2.5.4.3 ?

There are two situations we need to deal with; two different
objects having the same identifier, and an object having multiple
identifiers. The globally unique strings would fix the former
but the latter also has its problems. If server S1 chains a search
request on joint-iso-ccitt.ds.attributeType.commonName to server S2 but
S2 only knows the attribute by the name 2.5.4.3 then it will respond
with an empty result. Either the alternative names must be known
(or discoverable - yuk!) everywhere, or a single specific name of the
object must always be used in protocol. At the moment we have strings
in LDAP and OIDs in DSP, etc. Insisting on dotted decimal OID notation
in LDAP is one solution. However, if globally unique strings are going
to be used to identify attribute types without there necessarily being
a corresponding defined OID then I would suggest extending the attribute
type (in X.500) to be a choice between an OID or a unique string.
Either or both identifiers could be part of the attribute definition,
but this would be set in concrete at the time of definition. 
 
> 
> 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.

No argument there!

> 
> 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.

That helps by reducing the N x M problem to an M problem. We'd still
need to have an OID for each attribute option, which they currently
don't have. The attribute type could be changed to include a sequence
of character string attribute options to allow a direct mapping
from LDAP to DSP, but we'd have the usual problems of
ambiguous identifier strings. Globally unique string names would
solve that, though they could be a bit cumbersome.

Regards,
Steven

> 
> 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
> 
> ***************************************************
> 
>
Prev by Date: Are you worth WAY more than you are paid?
Next by Date: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt
Index(es):
- Chronological
- Thread