Subject: Re: Feature discovery (Was: RFC 2596 questions)

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 15 Sep 2000 15:28:50 -0600

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):

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

>>> <[email-masked]> 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: [email-masked]
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" <[email-masked]> on 09/15/2000 04:33:17 PM

To:   <[email-masked]>, Timothy Hahn/Endicott/IBM@IBMUS
cc:   <[email-masked]>
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" <[email-masked]> 9/15/00  2:01:22 PM >>>
At 07:18 AM 9/15/00 -0400, [email-masked]  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

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 21 Sep 2000 17:50:41 +0100

Date forwarded: 	Fri, 15 Sep 2000 14:30:17 -0700 (PDT)
Date sent:      	Fri, 15 Sep 2000 15:28:50 -0600
From:           	"Jim Sermersheim" <[email-masked]>
To:             	<[email-masked]>, <[email-masked]>
Subject:        	Re: Feature discovery (Was: RFC 2596 questions)
Forwarded by:   	[email-masked]

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

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

>    "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE") oids) ; list of
>    syntaxes or attributes that this ATO applies to. whsp ")"
> 
> 
> Jim
> 
> 
> 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).
> 
> 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
> 
> 
> 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 [email-masked]
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

***************************************************

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 22 Sep 2000 11:37:14 +1100

David,

> -----Original Message-----
> From: David Chadwick [mailto:[email-masked]]
> Sent: Friday, 22 September 2000 3:51
> To: Jim Sermersheim; [email-masked]; [email-masked]

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 

> > >Should we investigate some additional rootDSE attribute to 
>  indicate
> > >the

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 23 Sep 2000 12:11:54 +0100

Send reply to:  	<[email-masked]>
From:           	"Steven Legg" <[email-masked]>
To:             	<[email-masked]>
Copies to:      	<[email-masked]>
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

> > > attributeTypeOptions, the syntax would look something like this
> > > (ala 2252 nomenclature):
> > 
> > Jim
> > 
> 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
> 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 ?
> 
> 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 .
> 
> 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
> > 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
> > 
> > 
> > > 
> > > 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
> > > 
> > > 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
> > > 
> > > 
> > > set of attribute descriptions that are supported?  Further,  when
> > > a new attribute description is defined, should we be 
> > assigning OIDs and 

David Chadwick