[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Formal definition of LDAPOID values
Jim,
Is there some reason why you can't just reference the numericstring
production
in Section 4.1 of RFC 2252 ?
If not, then like RFC 2252, you should say that leading zeroes are not
permitted in a numericstring, or else rewrite the ABNF to disallow them,
e.g.
numericstring = "0" / ( non-zero-digit *digit)
digit = %x30-39 ; "0" to "9"
non-zero-digit = %x31-39 ; "1" to "9"
Regards,
Steven
> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim Sermersheim
> Sent: Wednesday, 24 January 2001 6:45
> To: ietf-ldapbis@OpenLDAP.org; Kurt@OpenLDAP.org
> Subject: Formal definition of LDAPOID values
>
>
> This is the proposal to add a formal ABNF for the value of
> LDAPOID to section 4.1.2 of the protocol specification.
> Currently, there is only an example in this section to be
> used as a reference for the actual string encoding. The
> intent of this ABNF is to clairify, using a formal
> definition, as well as to be a reference for other areas in
> the specification needing to refer to the string
> representation of LDAPOID.
>
> The proposed change is this:
>
> <The LDAPOID is a notational convenience to indicate that the
> permitted value of this string is a (UTF-8 encoded)
> dotted-decimal representation of an OBJECT IDENTIFIER.
> <
> <LDAPOID ::= OCTET STRING
> <
> <For example,
> <
> <1.3.6.1.4.1.1466.1.2.3
>
> >The LDAPOID is a notational convenience to indicate that the
> permitted value of this string is a (UTF-8 encoded)
> dotted-decimal representation of an OBJECT IDENTIFIER.
> >
> >LDAPOID ::= OCTET STRING
> >
> >A value of LDAPOID is based on the following ABNF [RFC2234]
> (lines wrapped for readability):
> >
> > ldapOID = numericstring *( "." numericstring )
> >
> > numericstring = 1*( "0" / "1" / "2" / "3" / "4" /
> > "5" / "6" / "7" / "8" / "9" )
> >
> >For example,
> >
> >1.3.6.1.4.1.1466.1.2.3
>
> Potential issues include the fact that the "oid." prefix is
> not accounted for, and the ABNF does not ensure a valid OID
> (within the existing OID hierarchy). I don't believe either
> of these issues are valid.
>
> Is this reasonable, and will it work?
>
> Jim
>
>