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

Re: Stringprep Considered Harmful


Rici,

Rici Lake wrote: 
On 11-Nov-04, at 11:21 AM, Kurt D. Zeilenga wrote:

In revising the LDAP technical specification, the WG was
charged with resolving known interoperability problems,
including those in character string matching.  I believe
the WG understood (and understands) that fixing the general
character string matching problems requires invalidating
(or "breaking") some specific application uses of LDAP.  I
also believe the WG understands well the limitations of the
Stringprep solution and accepts those limitations as
reasonable given the situation.


I doubt the working group as a whole has the background to give
due consideration to the issues around bidi. I know I don't.
I think prior consensus here probably amounts to a lot of
"I dunno, whatever".

I find that acceptable for most of the little quirks of the
stringprep profile proposed. But I would beg the WG to
reconsider the application of the bidi-prohibition rule.


The situations you have described seem to me to be quite reasonable
uses of the directory. It is unfortunate if LDAPprep + stringprep
is making those things illegal.


To try to make the problem as simple as possible, all of the
following strings would be unmatchable with bidi-prohibition:

1) A URL which contains an Arabic or Hebrew component, whether
a domain component, path component or query component, unless
%-quoted. (This might even be an ldap: url.) These will be
unmatcheable because a URL must start with a scheme name,
all of which currently are left-to-right characters (in fact
[a-z0-9]+)

2) An email address which contains an Arabic or Hebrew
domain name component or Arabic or Hebrew mailbox name,
unless the entire domain name include the TLD is in
Arabic or Hebrew. (I know that there is a proposal to
implement Arabic TLDs, but I feel that <arabicword>.com
is rather more likely in the forseeable future.)

3) A string not identified as having distinguished name
syntax which happens to be a distinguished name which
includes Arabic or Hebrew components

4) An absolute filepath which includes Arabic or Hebrew
components, even if all components are Arabic or Hebrew, since
the initial / will fail the bidi prohibition

5) And a long etc.

So it seems to me that the bidi prohibition is more the exception
than the rule; it should be applied to the syntax for the dc
attribute, but it is hard to think of other attributetypes where
it will not primarily serve block the use of right-to-left scripts.


Seems like a fair assertion to me.


Your comment "this may indicate the need for more MatchingRules
which correspond to those system's matching algorithms" is on
target.  Where the general-purpose matching rules (e.g.,
caseIgnoreMatch, caseExactMatch, etc.) are inappropriate in
some application-specific context, an application-specific
matching rule should be introduced OR the application should
specify that application-specific transformations (e.g., IDN
toASCII/toUnicode) be employed above the directory such that
matching with general purpose matching rules (e.g.,
octetStringMatch) in the directory behaves in a manner
appropriate for the application.



That seems entirely appropriate to me. Consequently, I would humbly
suggest that the default general-purpose matching rule not include
the bidi prohibition rule, and that an application-specific rule
be introduced for attributes whose values will be normalised by
nameprep.


I agree that it is appropriate for the general purpose matching rules to
be able to support arbitrary changes of direction. Though it is not at all
clear to me what the implications would be for the substring matching rules.

Regards,
Steven


Rici