Re: IDNA section 3.1 requirement 3

Adam,

I see where you are going here, but, to some considerable 
extent, I think it is a waste of time or worse.

Please take a step back from looking at coding, disclaimers, and 
this type of recommendation and put yourself into the place of 
the application developer who, other than the registrars and 
registries, is the market for the IDNA technology.  Those 
application developers, at least the ones who intend to survive, 
are quite sensitive to user reactions: users who are unhappy 
with user interfaces tend to have thoughts about going 
elsewhere.  The IETF has, for years, avoided getting involved 
with user interface design for many reasons; being the source of 
that unhappiness is one of the reasons.

You are now proposing to transform an IDNA rule that, given 
contemporary operating system and display designs, was 
essentially meaningless (but harmless) into a fairly complex set 
of rules.  If the current rule contracted the experience 
application designers wanted to deliver to their users, they 
would ignore it... and have been doing so.  If the new rule is 
at variance with the target experience, it, too, will be ignored.

Let's look at a few of the things we know about user behavior 
and reactions:

    * They do not like looking at punycode or similar "no
    obvious meaning" and/or "ugly" constructions.  If too much
    of it is displayed, they will be unhappy.

    * They don't like the unpredictable and unexpected.  If they
    are used to seeing native characters and punycode suddenly
    pops up, there had better be a good, and plausible, and
    immediately accessible explanation.

    * They get really irritated with repeated and intrusive
    warnings that they don't know how to interpret and what to
    do about.  With too many pop-up alerts, the usual response
    is to click "ok" every time and to go looking for a way to
    shut the alerts off.  Given that there are many legitimate
    cases that fall into your "display punycode" categories,
    especially in the vicinity of certain scripts and languages,
    the application would generate a lot of false positives and
    the user would learn to ignore whatever is written there.

Make whatever suggestions and recommendations you think 
appropriate, but wrapping them in conformance language about 
what SHOULD/MUST be done just brings discredit on the protocol/ 
algorithm core of IDNA.

Just my opinion.

     john

--On Wednesday, March 16, 2005 10:13 PM +0000 "Adam M. Costello" 
<[email protected]> wrote:

> Consider a domain name containing a slash-homograph.
>
> As it stands, IDNA section 3.1 requirement 3 tells
> applications that they "SHOULD" display the non-ACE form.  The
> security considerations section, much later, "suggests" that
> applications provide visual indications of various anomalies
> (from which one could extrapolate that the slash-homograph
> would benefit from a visual indication).
>
> I think we've seen that these security concerns need to be
> less buried, that "visual indications" are too burdensome on
> implementations, and that in some cases (like this one) the
> recommendation to display the non-ACE form ought to be
> withdrawn, or even reversed (that is, recommend the ASCII
> form).
>
> There I propose a technical change to IDNA section 3.1
> requirement 3. For reference, here it is as it stands now in
> RFC-3490 (with one typo corrected):
>
>    3) ACE labels obtained from domain name slots SHOULD be
> hidden from       users when it is known that the environment
> can handle the non-ACE       form, except when the ACE form is
> explicitly requested.  When       it is not known whether or
> not the environment can handle the       non-ACE form, the
> application MAY use the non-ACE form (which       might fail,
> such as by not being displayed properly), or it MAY       use
> the ACE form (which will look unintelligible to the user).
> Given an internationalized domain name, an equivalent domain
> name       containing no ACE labels can be obtained by
> applying the ToUnicode       operation (see section 4) to each
> label.  When requirements 2 and       3 both apply,
> requirement 2 takes precedence.
>
> Here is my proposed replacement:
>
> --begin--
>
>    3) When a domain label occupying or obtained from a domain
> name       slot is to be shown to a user, it SHOULD NOT simply
> be shown in       whatever form it was found in; before being
> shown it SHOULD be       forced into either ASCII form (which
> can be obtained by applying       ToASCII) or non-ACE form
> (which can be obtained by applying       ToUnicode, see
> section 4), according to the first applicable of       the
> following rules:
>
>       a) If requirements 2 and 3 both apply, requirement 2
> takes          precedence, and the ASCII form MUST be used.
>
>       b) When the user has explicitly requested to see one
> form or the          other, that form SHOULD be shown.
>
>       c) When it is known that the environment cannot handle
> the non-ACE          form, the ASCII form SHOULD be shown.
>
>       d) If the non-ACE form contains any character outside
> Unicode          categories L (letter), N (number), and M
> (mark), other than          U+002D hyphen-minus, the ACE form
> SHOULD be shown.
>
>       e) If the application determines that showing the
> non-ACE form          would pose too great a risk of
> misleading the user, the ASCII          form MAY be shown.
> Applications MAY use complex heuristics to          estimate
> this risk, but SHOULD try to minimize the negative
> impact on legitimate usage of internationalized domain names.
>
>       f) When it is not known whether the environment can
> handle the          non-ACE form, the application MAY show the
> non-ACE form (which          might fail, such as by not being
> displayed properly), or it MAY          show the ASCII form
> (which will look unintelligible to the user          if it is
> an ACE).
>
>       g) In general, when rules a-f do not apply, the non-ACE
> form          SHOULD be shown.
>
>       Rules c, d, and e above apply tests to "the" non-ACE
> form, but       in fact there can be many non-ACE forms that
> differ only in       capitalization and/or normalization.  If
> a given non-ACE label       fails some test, it MAY be
> converted to an equivalent non-ACE       label by applying the
> map and/or normalize steps of [NAMEPREP] (or       all the
> steps), and then given another chance to pass the test.
>
> --end--
>
> Thoughts?
>
> AMC
>
>