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

["Steven Legg" <steven.legg@adacel.com.au>]

Scott,

Scott Seligman wrote:
> "Jim Sermersheim" <JIMSE@novell.com> writes:
> > 
> > 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".
> 
> 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"?

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
> octet string, while respecting our natural tendency to think of
> something like "foo$bar" as a string.
> 
> 
> Scott
>