Re: Bidi issues

Clearly we have an open issue that wasn't identified in the draft.  Roy,
thanks for spotting this.

Martin Duerst <[email protected]> wrote:

> there is no need to apply the bidi check to the whole left hand part
> if that's not deemed appropriate.

Okay, so we do indeed need to make a judgement call.

In the current IMAA draft, Nameprep is applied to the entire local
part before the local part is divided into segments.  There is an
important reason for that: the normalization step of Nameprep might
cause the appearance of protected characters that weren't present
before.  Protected characters delimit segments.  If we did segmentation
first, then applied Nameprep to each segment, we might end up with
segments containing protected characters, which defeats the whole point
of segmentation (which is to make every segment contain no protected
characters or to contain only protected characters, so that protected
characters cannot get moved around by Punycode).

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

Existing implementations of Nameprep would need to change their
interfaces to accomodate this.  The alternative is to forbid the mixture
of left-to-right and right-to-left characters in a local part (as the
current draft does).

Roy Badami <[email protected]> wrote:

> if IMA practice were to follow the currently proposed IRI practice (ie
> render by simply applying bidi in an LTR context), then the e-mail
> address (logical order) [email protected] would render as:
>
>       [email protected]

That looks shocking to me, but it's consistent with the IRI draft
section 4.4 example 5:

logical: http://ab.cd.EF/GH/ij/kl.html
 visual: http://ab.cd.HG/FE/ij/kl.html

The domain label and path component are swapped, just as the local part
and domain label are swapped in your example.

> Further, consider the address [email protected] (logical order).

That's a good example, because the current draft prohibits it (because
"owner" is left-to-right and "LIST" is right-to-left).  If we want to
allow this local part to exist at all (regardless of how it should be
displayed), we'll need to change something.

AMC