[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] stringprep comment 2



Soobok Lee <lsb@postel.co.kr> wrote:

> In many cases, label strings are imported or transmitted from other
> applicationss, not generated by the application itself. that makes it
> difficult to classify them.
>
> ...comparing two "query strings" are inevitable and make troubles.
>
> It seems very subtle question.

I'm starting to agree.

Hmmm, is it even necessary to avoid comparing two query strings?  Even
if you compare two strings prepared with loose stringprep (unassigned
code points allowed), the worst that can happen is still a false
negative (where they don't match when they should), you still can't get
a false positive (where they match when they shouldn't).

So maybe we could simply remove all this talk about stored strings
and query strings.  The Stringprep spec could make this yet another
parameter: the profile would have to specify, along with the mapping
tables etc, a single bit indicating whether unassigned code points are
prohibited or not.  The Stringprep spec would retain the discussion
about what can happen when unassigned code points are not prohibited.

The Nameprep document would define two profiles: strict Nameprep and
loose Nameprep, which differ only in that bit.  The IDNA spec would
require registrars to use strict Nameprep, and would let applications
decide for themselves when/if to allow loose Nameprep.

How's that?

AMC