Subject: [EAI] Re: design and display of non-ascii mailbox name

From: Shawn Steele <[email-masked]>
Date: Wed, 6 Dec 2006 09:57:56 -0800

Homographs and other issues are addressed somewhat by Unicode TR#36
"Unicode Security Considerations".  http://www.unicode.org/reports/tr36/
IMHO this is a problem with any sort of protocol like this and it should
be left to a different standard or the software designer to address.
Hopefully there'd be a consistent behavior on a machine so that the end
user would have a consistent experience.

- Shawn

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

---

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

> user would have a consistent experience.

<quote from tr36>
2.10.3 User Agent Recommendations

The following recommendations are for user agents in handling domain names. The term 'user agent' is interpreted broadly to mean any program that displays Internationalized Domain Names to a user, including browsers and emailers.

For information on the confusable tests mentioned below, see Section 4. Confusable Detection [UTS39]. If the user can see the case-folded form, use the lowercase-only confusable mappings; otherwise use the broader mappings.

   1. Follow Section 2.10.2 General Programmer Recommendations.
   2. Display
         1. Either always show the domain name in nameprepped form [RFC3491], or make it very easy for the user to see it (see Section 2.8.1 Case-Folded Format). For example, this could be a tooltip interface, or a separate box.
         2. Always display the domain name with a visually highlighted domain name, to prevent syntax spoofs (see Section 2.6 Syntax Spoofing).
         3. Always display IRIs with bidi content according to the IRI specification [RFC3987].
   3. Preferences
         1. In preferences, allow the user to select the desired Restriction Level to apply to domain names. Set the default to Restriction Level 2.
         2. In preferences, allow the user to select among additional scripts that can be used without alerting. The default can be based on the user's locale.
         3. In preferences, allow the user to choose a backwards compatibility setting; see Section 2.9.1 Backwards Compatibility.

</quote>

comment:
  2.1) localparts are not domain names, so they are not (MUST BE) nameprepped,and 
      are put in different location in IRI/URL, 
      but optionally normailzed by something other.

  2.2) we hope to check whether some syntax spoofs/interferences 
      with neighboring @hostname part is possible and problematic.

  2.3) IRI has all %escaped non-ascii chars (both localpart and hostname). 
      I hope we could display only problematic parts in alternative form.

  3.1~2) "restriction level" and "default locale" is a good starding point.
      I think our draft can refer to TR#36 for this matter, as informative
        reference.

Thanks.

Soobok

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 07 Dec 2006 14:39:17 +0100

> I think our draft can refer to TR#36 for this matter, as informative

Just in case, it's not in the general bibxml library:

        <reference
            anchor='UTR36'
            target='http://www.unicode.org/reports/tr36'>
        <front>
            <title>Unicode Security Considerations</title>
            <author initials='M.' surname='Davis'
                    fullname='Mark Davis'>
                    <organization />
            </author>
            <author initials='M.' surname='Suignard'
                    fullname='Michael Suignard'>
                    <organization />
            </author>
            <date month='August' day='11' year='2006' />
        </front>
        <seriesInfo name='Unicode Technical Reports' value='#36' />
        </reference>

Frank