Subject: 'native' v. 'string' (RE: I-DACTION:draft-ietf-ldapbis-protocol-06.txt)

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 06 Mar 2002 19:43:50 -0700

Yeah, how about "indigenous".

But seriously, here are some possible alternatives (in my preference
order). "common", "natural", "normalized", "ldap", and "native-ldap".
Not sure if I like any of them better than native, but some may
alleviate the concerns being raised. My only issue with native is the
'local' connotation. Meaning, I don't want people to think that native
means "the form in which the value is stored in the server's database".

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 03/04/02 09:26PM >>>
Sorry for replying twice (and now a third time).  My e-mail client
told me I hadn't yet sent it when in fact I did.  Anyways, just
for clarity.

If anyone has an alternative term to use for 'string' which
is clearly better than 'native', they should make their case
to the WG soon so that final determination can be made.

Kurt

At 08:10 PM 2002-03-04, Kurt D. Zeilenga wrote:
>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

---

From: Scott Seligman <[email-masked]>
Date: 08 Mar 2002 17:06:34 -0800

> means "the form in which the value is stored in the server's database".

The term "string" was a problem due to confusion between character
string representations and octet string representations.  The term
"native" is a problem because it suggests something about the server's
internals, as Jim notes above.  Would it work to use "character string"
or "character-based string"?  That clearly distinguishes it from
octet string, while respecting our natural tendency to think of
something like "foo$bar" as a string.

Scott

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 08 Mar 2002 17:49:19 -0800

>something like "foo$bar" as a string.

Since the native string encoding is a octet string encoding,
calling it a character string encoding would be confusing.
And calling it an octet string encoding is also confusing,
consider:

  userPassword attribute are returned in a BER-encoded
  AttributeValue, an OCTET STRING, which contains an
  octet string encoding of the userPassword value,
  an OCTET STRING.

I rather call it a puny encoding.... :-)

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 12 Mar 2002 15:56:24 +1100

Scott,

Scott Seligman wrote:
> or "character-based string"?

No, because the native encoding for some syntaxes is not a human-readable
character string. For example, the native encoding for the Audio and JPEG
syntaxes is arbitrary octet data. The term we use to describe the encoding
that applies in the absence of an explicit transfer option has to allow
for a variety of non-character string encodings.

Of the alternative terms offered I prefer "LDAP-specific encoding".

Regards,
Steven

> That clearly distinguishes it from