wrt IDNA2003->IDNA2008 transitionn (was: IDN processing-related, security considerations for draft-ietf-websec-strict-transport-sec)

[John C Klensin]

--On Thursday, October 06, 2011 11:06 +0200 Yedidyah Bar-David
<didi at isoc.org.il> wrote:

> Hi all,
> 
> I am a sysadmin in ISOC-IL, the .il ccTLD operator. I've been
> lurking here for several years now, and IIRC this is my first
> post.
>...
> In our registration rules we mention neither IDNA2003 nor
> IDNA2008, but simply write our own rules, which are (intended
> to be) a very small subset of IDNA2008:
> http://isoc.org.il/domains/il-domain-rules.html When people do
> request registration of such IDNA2008-only names, we make them
> aware of the current situation, in which (almost?) no browsers
> allow trivial use of such names. We obviously hope that this
> situation will change with the proliferation of IDNA2008
> browsers.
>...

FWIW, I think this -- with registration rules that permit a
small subset of characters, string checks and warnings about
what labels might not be as useful and people might image, etc.
-- is just exactly the right way to go.   It is what was
intended by the IDNA2008 comments about registry restrictions
(and the IESG note to IDNA2003) -- the issue is not new.

On a different piece of the thread, as far as all of the other
"just mapped" strings that IDNA2008 prohibited, those strings
could not be retained without retaining the confusion about what
is actually in the DNS and that caused by users putting in one
string and getting back another.  Perhaps it makes no difference
in application that simply map in one direction and never try to
recover a user-visible string from a mapped and
Punycoded-encoded one, but experience showed that there were a
lot of applications that did try to recover the user-visible
native character string and thereby created user confusion.

   john