Re: IDNA section 3.1 requirement 3

Paul Hoffman <[email protected]> wrote:

> Question: when faced with an incomprehensible domain name with no
> visual indications, do you think that typical users will know what to
> do, or even what to be cautious of?

No, but they don't need to do anything special or use any more caution
than they would with any domain name that they didn't recognize.  As
long as they don't see "paypal" or whatever, they're at least not being
misled.

> Adam: could you think more about it and see how it would look if
> thought visual assistance was an option?

Suspicious characters could be shown in red, or highlighted, or with
squiggly underlines.  But the risk with any such scheme is that the
misleading text is still visible, so if the user doesn't take the
hint, they might still be misled.  And these approaches would be
less effective or impossible on monochrome displays or in tty-based
applications.

Another option is to show the suspicious characters using the
replacement glyph (hollow rectangle), but then cut-and-paste might
break, unless it's really clever.

I proposed the show-ACE approach because it's simpler to implement and
it's obviously effective regardless of the display technology.

John C Klensin <[email protected]> wrote:

> 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.

I agree.  If enough browsers implement the proposal, no one will have a
motive to use domain labels that would show as ACE, and therefore users
will see ACE very rarely.

> 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.

Same comment.

> 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.

IDNA already makes a recommendation regarding what form to display,
but maybe you'd prefer my proposal to demote the details to cited
suggestions.  For example:

   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).  Implementors are encouraged to
      develop policies that balance the conflicting goals of hiding
      unintelligible ACE strings from users and hiding potentially
      misleading Unicode strings from users.  See appendix A for
      suggestions.  When requirementst 2 and 3 both apply, requirement 2
      takes precedence.

Then the rest of the proposal would go in appendix A, without the
SHOULD/MAY language.

AMC