[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