Subject: [EAI] display of RightToLeft chars in localparts and hostnames

From: Soobok Lee <[email-masked]>
Date: Thu, 7 Dec 2006 09:48:17 +0900

http://www.ietf.org/internet-drafts/draft-alvestrand-idna-bidi-00.txt (page 6)
and http://www.unicode.org/reports/tr36/#Bidirectional_Text_Spoofing

If you read above references, you can understand why this:
(storage order)
  [email-masked]

(display order)
  [email-masked]

( @ and dot are neutral chars wrt RtL and LtR direction)

I remember that there had been some discussion about whether
  we should do "RtoL stopper chars"(this may be not the right tech term, sorry) 
  around  delimiters like @ or dot.

this may not have any definitive right answer, but we may have better choose 
 one anyway.

Soobok

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Soobok Lee <[email-masked]>
Date: Thu, 7 Dec 2006 09:59:07 +0900

> this may not have any definitive right answer, but we may have better choose 

one of my self-answer is "for display preparation, insert RtoL stopper around 
all special chars in IRI/URL".

If we follow this:

  (new display order)
   [email-masked]

  here each  @ and dot have preceding unseen(transparent) RtoL stopper char.

Soobok

---

From: Soobok Lee <[email-masked]>
Date: Thu, 7 Dec 2006 11:04:25 +0900

On Thu, Dec 07, 2006 at 09:59:07AM +0900, Soobok Lee wrote:
> > (old display order)

For RtoL stopper, we can use "LRE  dot PDF" sequence.

But, we still have 3 problems:

1) the above choice would still make input-time display order still look as (old display
order), since we can't expect input method editors for BIDI chars intelligently
determine when to insert such surrounding stoppers on the running input entry form.
So we should provide consistent user experience around all of storage order,
input time order,old display order, and new display order. But, it won't be a trvial
task.

2) Moreover, when we copy and paste (new display order) hostname and localpart strings, 
they may contain hidden LRE and PDF chars which have been *prohibited* in stringprep.
  (http://www.ietf.org/rfc/rfc3454.txt section 5 and section 5.8)

When IDN hostnames contains prohibited chars, they will fail be stringpreped 
and return an error.
To prevent this from happening, bidi LRE /PDF should not be copied  by mouse
operation. 

3) localparts may contain  dots, for example, [OSAMA].[BIN].[LADEN]@free.af
how to display dot-containing bidi localparts would complicate this problem.
I guess localpart dot should follow the way that hostname dot does .

I welcome any criticism/suggestion.

Soobok