Re: [idn] URL encoding in html page

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

>Case 2: From IDNA A1 thru MIM to non-IDNA A2
> >...
> >A2 receive ACE. But it is not able to understand ACE so it display the
ACE
> >as-it-is.
>
> So that we are clear:  nothing breaks.  The string is ugly, but it is
legal
> and A2 does with that string whatever it usually does with ASCI DNS
strings.

"nothing breaks" is probably too strong. For some, "nothing" => resolution
only, for others, display too.

I think it is reasonable to say A1 works for both resolution and display and
A2 works for resolution but not display.

> >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.
>
> Sorry, no.  If A1 is a non-IDNA DNS mechanism, then it supports non-IDN
> strings.  In other words, it supports the existing set of ASCII DNS
strings.
>
> You are specifying that a mechanism which is not converted to IDNA will
> somehow start issuing new strings that are neither current ASCII nor
> IDNA-encoded ASCII.
>
> Unless you can provide more detail to this example -- so that we can
> understand concretely how it could happen -- then the problem with the
> example is that it will not happen.

We are not disagreeing.

The behavior of non-IDNA A1 is totally unknown. It is likely to fail in
resolution. The display may or may not work, depending on implementation.
But I agree that this is an expected behavior of any application feed with
data it is not able to process anyway.

It is not my intention to specify how non-IDNA is going to behave.

However, if non-IDNA is feed with ACE, then resolution works altho display
will still be in ACE. This is basically what my conclusion.

Can we at least agree on the case example for IDNA? If we can, then we can
draw up similar case examples for other proposal (UDNS, UTF-8 or what we
have) and do a proper comparsion between them.

-James Seng