[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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.
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
***************************************************