Re: [idn] URL encoding in html page

["James Seng" <jseng@pobox.org.sg>]

> However user interface design is not part of IETF protocol design.  That
is
> why it is not part of this working group's charter.  Rather, this working
> group has a task of working on a network interchange standard.

Okay, lets look at network interchange then.

Assuming there is an application (A1) that uses IDN it send IDNs around to
another application (A2) maybe through some immediated relay/proxy/cache
(MIM).

For IDNA, there is no change in the infrastructure, ie, MIM remains
unchange.

Case 1: From IDNA A1 thru MIM to IDNA A2

A1 is capable of handling IDN input, display and resolution as defined in
IDNA. It will send out IDN as ACE.

MIM receive ACE, thinking it is some ASCII string, process it as usual.

A2 receive ACE and able to handle IDN input, display and resolution as
defined in IDNA.

Case 2: From IDNA A1 thru MIM to non-IDNA A2

A1 is capable of handling IDN input, display and resolution as defined in
IDNA. It will send out IDN as ACE.

MIM receive ACE, thinking it is some ASCII string, process it as usual.

A2 receive ACE. But it is not able to understand ACE so it display the ACE
as-it-is.

Case 3: From non-IDNA A1 thru MIM to IDNA A2

A1 capability to handle IDN is unknown. It may send out as-is in whatever
encoding the user specify.

This is a failure case unless the user input IDN into A1 as ACE directly.

If so, MIM receive ACE, thinking it is some ASCII string, process it as
usual. A2 receive ACE and able to handle IDN input, display and resolution
as defined in IDNA.

Case 4: From non-IDNA A1 thru MIN to IDNA A2

A1 capability to handle IDN is unknown. It may send out as-is in whatever
encoding the user specify.

This is a failure case unless the user input IDN into A1 as ACE directly.

If so, MIM receive ACE, thinking it is some ASCII string, process it as
usual. A2 receive ACE. But it is not able to understand ACE so it display
the ACE
as-it-is.

Summary for IDNA:

Protocol:
             Resolution        Display
           A1    MIM   A2      A1   A2
Case 1 :  okay  okay  okay    okay  okay   // IDNA A1, IDNA A2
Case 2 :  okay  okay  okay    okay  fail   // IDNA A1, non-IDNA A2
Case 3 :   ?    okay* okay*    ?    okay*  // non-IDNA A1, IDNA A2
Case 4 :   ?    okay* okay*    ?    fail*  // non-IDNA A1, non-IDNA A2

? the processing fail here unless ACE is used to bypass non-IDNA support.
* subjected to the condition that ACE is used to bypass non-IDNA support.

cut & paste:
           Resolution    Display
           A1    A2      A1    A2
Case 1 :  okay  okay    okay  okay         // IDNA A1, IDNA A2
Case 2 :  okay    ?     okay    ?          // IDNA A1, non-IDNA A2
Case 3 :  okay  okay    fail  okay         // non-IDNA A1, IDNA A2
Case 4 :  okay  okay    fail  fail         // non-IDNA A1, non-IDNA A2

? Case 2, A2 is likely to fail in the resolution altho A2 may be or may not
able to display the string correctly. We cannot predict what an non-IDNA
applications going to do to the domain names.

-James Seng