[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Feature discovery (Was: RFC 2596 questions)

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