RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

I don't follow

I note that ASN.1 provides only the data definition, not an
encoding.

If you specify ;binary, it certainly becomes an encoding (and therefore
always was an encoding).

Also, LDAP usually doesn't have an encoding based on the ASN.1. Unless you
mean loosely based. For example, StreetAddress is a SEQUNCE OF, but the LDAP
version is a collection of strings separated by '$' (is the '$' escaped in
the strings? - don't know, but it would also complicate the transformation).

So let's just say there are two encodings. I am not saying the ASN.1 form is
'native', I am simply saying that, as the ASN.1 form came first, and, as you
say below, the string encoding is based on the ASN.1, one can hardly call
the LDAP form 'native'. I would prefer a different adjective.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, 5 March 2002 15:11
To: Ramsay, Ron
Cc: steven.legg@adacel.com.au; ietf-ldapbis@OpenLDAP.org
Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt


At 04:56 PM 2002-03-04, Ramsay, Ron wrote:
>This use of the term 'native' encoding is not good. I think we have already
>established that every syntax must have an ASN.1 encoding defined, and I
>would think that this is about as native as you can get. I can see
>difficulties with the term 'string' encoding, but I don't think 'native' is
>the way to go.

The WG consensus was use a different term. The only proposal
we have is use the term 'native'.

I note that ASN.1 provides only the data definition, not an
encoding.  LDAP currently has two possible encodings, both
defined in terms of the ASN.1 data definition.  Referring
to the "string" representation as a "native" encoding as
they were born in LDAP technical specifications for use
in LDAP.

Kurt