Subject: Re: registration of LDAP syntax OIDs

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 24 Oct 2004 00:32:34 -0600

I'm talking about descr's applied to syntaxes (I wasn't very clear)

>>> "Jim Sermersheim" <[email-masked]> 10/23/04 10:49:13 PM >>>
While I understand that these descriptors are not used in the protocol
as we know it today, why the need to actively prevent them from being
used in some future extension (especially if they are registered)?

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/23/04 6:03:55 PM >>>
At 09:54 PM 10/22/2004, Jim Sermersheim wrote:
>I favor #2 for forward compatibility.

I'm thinking of inserting the something like:

Additionally, short descriptive names may be used outside
of the protocol to identity these and other objects. In
particular, short descriptive names (based on the name
of the ASN.1 data type name) may be used to refer to LDAP 
syntax.

as the second paragraph of Section 3.3 of [BCP64bis].
Comments?

Kurt

> 
>There may be future features which either cause the syntax oid to be
stored or transmitted as an oid syntax. These features may wish to allow
(mainly for consistency with other uses of the oid syntax) these oid
values to be transmitted in descr form. Also, a future extension of
SyntaxDescription may specify a "NAME" field.
> 
>In these cases, a table containing oid/descr associations will allow
existing and future syntaxes to be assigned descr's.
> 
>Jim
>
>>>> "Kurt D. Zeilenga" < [email-masked] > 10/22/04 9:49:04 PM >>>
>IANA recently asked me whether LDAP syntaxes should be
>registered and, if so, how.
>
>Given our prior decision to provide a listing of certain
>other OIDs solely for informational purposes (as opposes to
>ensuring value uniqueness), I think we should.
>
>Three options come to mind on how to handling syntax
>registration:
>
>1) Add a new table specifically for Syntaxes. This
>table would look basically like Descriptors table,
>except the syntax name would be some string (like
>the name of the associated ASN.1 data type) instead
>of a descriptor.
>
>2) Use the descriptor table to register syntaxes.
>While that would imply descriptors would be assigned
>to syntaxes, we'd have to be clear that these
>descriptors are not used in the protocol.
>
>3) Use the protocol mechanisms table to register syntaxes.
>
>I prefer option 1 over 2. I dislike option 3.
>
>Comments?
>
>Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 24 Oct 2004 01:52:57 -0700

I don't want to unnecessarily preclude some
future use of a syntax descriptor in the protocol,
but I do think we do need to be clear that these
descriptors are not presently used in the protocol.

I started to experiment with some [Models] edits
here and haven't found any way of saying syntaxes
can have descriptors in a way that is clear that
they are used (presently) in the protocol.  I'm
thinking it best to leave introduction of syntax
descriptors (which seems like a new feature) to
an extension specification.

Another (lessor) problem with using descriptors
here is that many syntaxes are referred to by ASN.1
data type names (e.g., OCTET STRING) which are not
valid descriptors.

So, at this point, I guess I have to say I now
prefer option 1 and dislike both 2 and 3.

I note that Option 1 doesn't preclude a future
extension from introducing 'syntax descriptors',
but it does (and I think properly so) defers the
introduction to a future extension specification.

Kurt

At 11:32 PM 10/23/2004, Jim Sermersheim wrote:
>While I understand that these descriptors are not used in the protocol as we know it today, why the need to actively prevent them from being used in some future extension (especially if they are registered)?
>Jim
>
>>There may be future features which either cause the syntax oid to be stored or transmitted as an oid syntax. These features may wish to allow (mainly for consistency with other uses of the oid syntax) these oid values to be transmitted in descr form. Also, a future extension of SyntaxDescription may specify a "NAME" field.
>> 
>>In these cases, a table containing oid/descr associations will allow existing and future syntaxes to be assigned descr's.
>> 
>>Jim
>>
>>>>> "Kurt D. Zeilenga" < <mailto:[email-masked]>[email-masked] > 10/22/04 9:49:04 PM >>>