Subject: registration of LDAP syntax OIDs

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 22 Oct 2004 20:49:04 -0700

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: "Jim Sermersheim" <[email-masked]>
Date: Sat, 23 Oct 2004 22:49:13 -0600

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 24 Oct 2004 12:46:58 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 10/24/04 2:52:57 AM >>>
>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.

I agree

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

Yes, but they could (in the future be given valid 'descr' form
descriptions (like octetString)

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

I don't think harm will be introduced either way. I still favor 2, but
it's not keeping me up at night.

<snip>
 
Jim