Subject: Syntax OIDs, RFC2252

From: "Howard Chu" <[email-masked]>
Date: Sat, 14 Aug 1999 09:20:08 -0700

Hello, I have a question that's been nagging at me for a while... Why is it
that most of the schema elements in RFC2252 can be specified using either a
string-form or numeric OID, but attribute syntaxes are required to use
numeric OID (noidlen) ?  This makes schema reading rather painful, and
writing even more so. In a system where everything is defined by OIDs, why
were attribute syntaxes singled out and treated differently?
  -- Howard

---

From: Mark Wahl <[email-masked]>
Date: Sun, 15 Aug 1999 23:24:47 -0500

Originally in X.500(88-93), attribute and object names names were OIDs, and 
syntaxes were strings.  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.

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.

---

From: "Howard Chu" <[email-masked]>
Date: Sun, 15 Aug 1999 22:42:14 -0700

> syntax strings were not valid or a poor model.

Yes, attribute and object names were OIDs, but everything was represented in
ASN.1, which allows macro-style substitution. So a schema writer could
declare
	foo objectidentifier ::= {1 976 123 4}
and then use "foo" from that point on instead of the numeric OID. Any ASN.1
compiler would find simple mistakes of the kind you mention.

I don't see how the LDAPv3 notation changes anything relevant to this
problem.
> efficient client retrieval and processing.
That is a perfectly good goal.

> determine whether it knew a syntax for the "bar" attribute or not.
I'm not suggesting that string names should be used *instead* of OIDs.
But the fact is that a client already needs to be able to resolve strings
down to their OIDs, when looking up attribute types and objectclasses in a
published schema. The mechanism to handle such a lookup is already going to
be in the client. The problem of name conflicts with syntaxes is no worse
than with attribute types and object classes - the problems are all the
same. It makes no sense to make this a special case. Basically you've said
"everything has an OID. In every case, you can refer to a thing by its
string name instead of its numeric OID. Except this one case." As far as
efficient client retrieval goes - the client still only has to retrieve a
single subentry. For efficient processing - it's more efficient to have a
single, consistently defined behavior, than to have a mostly-consistent
behavior with a special case.

Taking efficiency to the extreme, there shouldn't be any string names at
all, only numeric OIDs. But then LDAP would be human-unfriendly and no
better than straight DAP. In the interest of human-friendliness I think it
best to offer the *choice* - the ability to use string names if desired, the
same way the choice is available for the other protocol elements. I always
thought the fact that LDAP was string-oriented was one of its selling
points...

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 17 Aug 1999 09:18:14 +0200

Howard Chu writes:
> But the fact is that a client already needs to be able to resolve
> strings down to their OIDs, when looking up attribute types and
> objectclasses in a published schema. The mechanism to handle such a
> lookup is already going to be in the client.

Lots of clients don't.  I doubt they will, until the C API provides a
convenient way to handle all this.  Then clients must be updated to take
advantage of it.  That's work.  If you want them to handle syntax names
as well, that's more work.

Incidentally, has someone made a convenient API to handle all this, for
X.500 or for LDAP?

> It makes no sense to make this a special case. Basically you've said
> string name instead of its numeric OID. Except this one case."

It makes sense to me.  Syntaxes are different from object classes and
attribibute types because a program can't apply a syntax unless it has
built-in knowledge about it.  When the program *has* that knowledge of a
syntax, it can translate to/from the syntax name internally.  In
practice, that also makes most syntax handling independent of naming
context.  So named syntaxes doen't add as much value as named object
classes and attribute types.

BTW, this reminded me about a few other points in rfc2251; I'm not sure
what is intended here:

- paragraph 4.1.4: "If the server has a textual name for an attribute
  type, it MUST use a textual name for attributes returned in search
  results."
  There is no similar requirement for object classes?

- There doesn't seem to be any requirement that servers handle
  searches for "2.5.4.0=2.5.20.1"      and "2.5.4.0=*" the same way as
  searches for "objectClass=subschema" and "objectClass=*".
  Nor "OBJECTCLASS=*", for that matter...
  Actually a strict reading of paragraphs 3.2.2 and 3.4 doesn't even
  seem to _allow_ them to be handled the same way:-)

-- 
Hallvard

---

From: "Howard Chu" <[email-masked]>
Date: Tue, 17 Aug 1999 14:35:52 -0700

> From: Hallvard B Furuseth [mailto:[email-masked]]
>
> Howard Chu writes:
I thought the LDAP service provider for JNDI already did some of this work.
But if you're saying most clients don't do this *today* it sounds like
you're saying "the published schema is useless because no existing clients
process published schema." ????

If it's work, big deal, it's work no matter what. But at least make it
worthwhile to do the work.

> classes and attribute types.
A program can't apply matching rules without built-in knowledge either, and
yet they exist with both string names and numeric OIDs. In fact, matching
rules only have implementation relevance on a server, and yet they are
presented to the client as either numeric OIDs or as human-friendly string
names. I think this is an unjustified inconsistency in the specification.

And while we're on this point - true, completely unknown syntaxes don't add
much value. At the very least, the syntaxes attribute ought to have included
an (optional) "human-readable" flag. Essentially, if the information was
interesting enough to have been documented on paper (the table on page 8 of
RFC 2252), it ought to have been worth putting out on the wire. Either the
information is useful, and should be provided, or it's totally unimportant,
and should be completely deleted. I'm not asking for the latter!
  -- Howard

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 18 Aug 1999 16:18:48 +0100

Date forwarded: 	Sun, 15 Aug 1999 21:25:52 -0700 (PDT)
Date sent:      	Sun, 15 Aug 1999 23:24:47 -0500
From:           	Mark Wahl <[email-masked]>
Subject:        	Re: Syntax OIDs, RFC2252
To:             	Howard Chu <[email-masked]>
Copies to:      	[email-masked]
Forwarded by:   	[email-masked]

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

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

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 [email-masked] *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

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 24 Aug 1999 21:30:49 +0200

Howard Chu writes:

>> has someone made a convenient API to handle all this, for
>> X.500 or for LDAP?
>>

Thanks.  Will read.

> process published schema." ????

No, I'm saying that it's wrong to say "client already needs to be able
to resolve strings down to their OIDs", and to enable namespace
collisions on this level gives us an unnecessary problem.

> worthwhile to do the work.

I quite agree:-)

>> built-in knowledge about it.  (...)
> 

Well, since LDAP was supposed to _simplify_ the ideas from X.500, it
does seem to be unnecessary complication to allow matching rule names to
be sent instead of OIDs over the protocol...

> an (optional) "human-readable" flag.

Yes, that would have been nice.  Still, 'human-readable' doesn't mean
'interesting for human users', which would be a lot more interesting -
but on attribute types, not on syntaxes.  Note that OIDs are 'human-
readable' in the table, for example.

> Essentially, if the information was interesting enough to have been
> documented on paper (the table on page 8 of RFC 2252), it ought to
> have been worth putting out on the wire.  Either the information is
> useful, and should be provided, or it's totally unimportant, and
> should be completely deleted. I'm not asking for the latter!

Depends on who is the target audience of that piece of information.
It makes sense the way it is if it's mostly provided for implementors:
Whoever defines a syntax should of course describe it.  When someone
implements some other syntax, they'll put that information elsewhere.

-- 
Hallvard

---

From: "Howard Chu" <[email-masked]>
Date: Tue, 24 Aug 1999 13:43:06 -0700

> implements some other syntax, they'll put that information elsewhere.

The whole motivation for publishing schema in the directory is so that
nobody has to look "elsewhere" before they can do useful work with a piece
of information. I am utterly amazed at your statement.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 24 Aug 1999 22:47:47 +0200

> of information. I am utterly amazed at your statement.

For syntaxes (and matching rules), one has to look "elsewhere" anyway.

-- 
Hallvard