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

RE: draft-ietf-ldapbis-filter-03.txt



Mark C Smith wrote:
> Hallvard B Furuseth wrote:
> > Why was section 6 "String Search Filter Definition" changed to
> > say that "all octets greater than 0x7f" must be escaped?
> > 
> > Shouldn't that at least be "MUST" esacpe them when 
> generating filters,
> > but SHOULD (or MAY) recognize them unescaped, for backwards
> > compatibility?
> 
> That change was the result of working group last call 
> comments made by 
> Steven Legg (but I am the one who wrote the text). But I think I 
> unintentionally made a protocol change. Is there a good reason to 
> require that all octects > 0x7f be escaped? I do not remember 
> all of the 
> details surrounding those older conversations.

The string representation of LDAP search filters is used in LDAP URLs.
The whole area of non-ASCII characters in URLs/URIs is murky, but to
quote from RFC 2396:

   A URI is a sequence of characters from a very limited set,
   i.e. the letters of the basic Latin alphabet, digits, and
   a few special characters.

and

   A URI may be transcribed from a non-network source, and thus
   should consist of characters that are most likely to be able to
   be typed into a computer, within the constraints imposed by
   keyboards (and related input devices) across languages and
   locales.

The escaping of octets > 0x7f in assertion values means that the
LDAP URL is an ASCII string and therefore resilient in the face of
transcription. We should probably go further and escape the
non-printable ASCII characters as well.

An LDAP URL with non-ASCII UTF-8 characters could only be faithfully
entered through an interface that supported UTF-8. We have to allow for
the possibility that it will be entered through an interface that
supports a different charset.

Regards,
Steven