[Date Prev][Date Next]
Re: Floating point Syntax & Matching rules (ITS#745)
At 12:00 AM 9/16/00 +0000, june@ISI.EDU wrote:
>I ftped it yesterday. I modified pkg/ldap/servers/slapd/schema_init.c
>and the patch name is june-000914.patch.
Okay. For others: ftp://ftp.openldap.org/pub/incoming/june-000914.patch
>Can you elaborate more about the specification, i.e. what kind of
>format, where I put it, etc...
I assume you intent to define an LDAP syntax for the ASN.1
primitive type REAL. As such a syntax would be generally
useful, the specification should be eventually published as
an RFC. So, I recommend you format your specification as such.
In fact, I encourage you to submit an Internet Draft to the
IETF. Your first draft can be rough. The IETF has guidelines
available for I-D authors at:
You might also scan the archives of the IETF LDAPext WG
for prior work or interest in this area. OpenLDAP maintains
a browsable archive of this IETF list at:
In fact, see:
I wouldn't think such an I-D would take too long to write.
I suggest leveraging an existing textual representation
of real numbers (from IEEE or ISO) and just stating use
of this. In fact, you likely can borrow from:
>I also have a question about the oids. I selected
>188.8.131.52.4.1.14184.108.40.206.59 for the Float syntax.
You can not "select" or otherwise assign an OID which
doesn't belong to you.
>Is it ok or should I select the oid that I have a control on?
In the specification, do not specify one (yet). Just define
the OID as:
( <TBD> DESC 'string syntax for ASN.1 REAL' )
After the specification matures, an appropriate OID can be
selected by the authors as directed by the IETF/IESG. This
may be a privately assigned OID, may end up being one
previously allocated for this purpose, or may come from
various OID arcs used for such things.
For development purposes, I'd be willing to assign an OID
for this (as such is general purpose syntax) out of our
experimental OID arc. We arc allows "evolving
specifications". That is, we don't assign new OIDs upon
each I-D revision... and we ALWAYS replace the OID prior
to "publication" of the reference specification (e.g. RFC).