[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



At 05:06 PM 2002-03-08, 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"?  That clearly distinguishes it from
>octet string, while respecting our natural tendency to think of
>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