[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ASN.1 definitions in draft-ietf-ldapbis-syntaxes-01.txt
I like this - except for the use of 'native', as I described elsewhere. To
recap, as every syntax requires an ASN.1 definition (for ;binary), the ASN.1
becomes the de facto native encoding. 'String' encoding is not perfect, but
native is counter-intuitive.
Ron.
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Saturday, 2 March 2002 6:44
To: Jim Sermersheim
Cc: IETF-LDAPbis@OpenLDAP.org
Subject: Re: ASN.1 definitions in draft-ietf-ldapbis-syntaxes-01.txt
At 11:15 AM 2002-03-01, Jim Sermersheim wrote:
>For any multipart syntax, could we include the ASN.1 definition, rather
>than including it in prose?
>I'm thinking of examples like Section 3.9 and 3.13.
I think we need to be very clear which ASN.1 data type definition
is associated with the OID. For example
This LDAP syntax associates the OID 1.3.6.1.4.1.1466.115.121.1.14
with the ASN.1 data type DeliveryMethod [REFERENCE]. The
following "native" string representation is defined for this
syntax.
An informative copy of the ASN.1 data definition could be
provided as well.
Then the string representation should be defined in terms
of the referenced ASN.1 data type.
>For example, in 3.9, rather than "A value in this syntax is a set of
>the ASN.1 enumerated INTEGER
> values", we could have:
>
>DeliveryMethod ::= SET OF ENUMERATED {
> any (0),
> mhs (1),
> physical (2),
> telex (3),
> teletex (4),
> g3fax (5),
> g4fax (6),
> ia5 (7),
> videotex (8),
> telephone (9) }
>
>(If that's actually what the statement means.)
>
>Also, there are many multipart syntaxes that lack an ASN.1 definition,
>do we plan to define the ASN.1 for these?
I believe each and every LDAP syntax as an associated ASN.1 definition.
In some cases, it might be implicit or defined in some obscure
document. We need to clarify for each and every syntax what the
ASN.1 definition is.
There may be some syntaxes which are best removed then clarified.
Kurt