Re: Bidi issues

I wrote:

> If we don't want the bidi check to apply to the whole local part, but
> rather to individual segments, then I think we'll need to break Nameprep
> into two halves.  The order of processing would be:
> 
>     Nameprep first half (mapping, normalization, prohibition)
>     Segmentation
>     Nameprep second half (bidi check) applied to each segment

The prohibition step works just as well before or after the
segmentation, and it seems cleaner to put it after:

    Nameprep first half (canonicalization = mapping + normalization)
    Segmentation
    Nameprep second half (restrictions = prohibition + bidi check)

(Optimization: Every other segment contains only protected characters,
which means it's an ASCII string, and an ASCII string cannot violate the
restrictions.)

Paul may recall long ago when I proposed that Nameprep be split into
two black boxes rather than one, because the canonicalization half and
the restriction half are so disparate (one may alter the string and
never fails, while the other may fail and never alters the string).
I suggested that it might be convenient to be able to use the halves
separately.

But the split was unnecessary for IDNA, so Nameprep remained a single
black box.  We now have another situation where it is tempting to make
this split.

In the current draft, owner-ARABICLIST is not an allowed local part.
How much does that bother us?  How much would it bother us to split
Nameprep into two halves?  Does anyone see another way out?

AMC