[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Syntax OIDs, RFC2252
Date forwarded: Sun, 15 Aug 1999 21:25:52 -0700 (PDT)
Date sent: Sun, 15 Aug 1999 23:24:47 -0500
From: Mark Wahl <M.Wahl@INNOSOFT.COM>
Subject: Re: Syntax OIDs, RFC2252
To: Howard Chu <hyc@highlandsun.com>
Copies to: ietf-ldapext@netscape.com
Forwarded by: ietf-ldapext@netscape.com
>
> Originally in X.500(88-93), attribute and object names names were OIDs,
> and syntaxes were strings.
Mark
This is incorrect. All schema definitions in 1998 had OIDs. Attribute
syntaxes in 1988 were allocated OIDs under the arc 2.5.5. Further
all schema definitions were allocated reference strings as well, so
that an attribute type could be referenced by its OID or its name (a
string), but it was only carried in protocol by its OID.
Further, in X.500(93) attribute syntaxes no longer existed. They
were split up into their two component parts - matching rules (which
also had an OID and a string reference) and the ASN.1 data type
(that did not have an OID, just a string name)
> This led to problems when schema writers would
> create new attributes through 'cut and paste' and sometimes not realize
> that their syntax strings were not valid or a poor model.
>
I dont follow this. I certainly had no problems creating schemas by
cutting and pasting attribute syntaxes (you obviously had to make an
intelligent choice about the correct one to use for each attribute, of
course).
David
> Note in LDAPv3, unlike object class names, attribute types, and matching
> rule names, syntax names are not transferred over protocol except as
> subschema publication elements. LDAPv3 subschema publication is intended
> for reasonably efficient client retrieval and processing.
>
> A client which is talking to a server for the first time and is going
> through the schema discovery process needs to determine which of the
> client's schema elements are supported by the server. For example, what
> attribute types are the same? Now the client and server may both call an
> attribute "foo", but the client may have a different semantic meaning, so
> it needs to request and parse the attributeTypes element to compare the
> OIDs.
>
> What of the syntaxes? A client may not know what the attribute "bar"
> (1.2.3.4) defined by a server means, but if it knows that it has syntax
> 1.3.6.1.4.1.1466.115.121.1.41 it perhaps could display it to a user, or
> reformat it for another protocol that deals with postal mail addressing.
>
> The use of string names for syntaxes rather than OIDs would raise the
> problem of name conflicts. Since in LDAPv3 as defined in 2251-2256, there
> is no other information about a syntax provided to clients in subschema
> publication, there didn't seem to be any value to the clients of having
> another layer of indirection and require the client to sort through
> ldapSyntaxes values just to determine whether it knew a syntax for the
> "bar" attribute or not.
>
> Mark Wahl, Directory Product Architect
> Innosoft International, Inc.
>
>
***************************************************
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
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
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
***************************************************