Dot-mapping

[fujiwara at jprs.co.jp]

Dear IDNAbis authors,

I found that RFC 3490 section 3.1 the first requirement is removed in
the new protocol document draft-klensin-idnabis-protocol-02.

|  1) Whenever dots are used as label separators, the following
|     characters MUST be recognized as dots: U+002E (full stop), U+3002
|     (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
|     (halfwidth ideographic full stop). 

And John described this reason.

Is removing the dot-mapping already decided?

The dot-mapping has useful in some language enviromnet.
The dot-mapping is already implemented in many applications.
Removing it causes many problems.

I'm afraid that another languages may have the same problem and the
characters which need to be treated as a dot may increase.

Regards,

--
Kazunori Fujiwara, JPRS

> Subject: IDNAbis discussion style, mappings, and (incidentally) Eszett
> From: John C Klensin <klensin at jck.com>
> To: idna-update at alvestrand.no
> Date: Thu, 29 Nov 2007 18:14:12 -0500
---snip---
> So the draft IDNA200X documents take the dot-mapping provision
> out, turning the parsing of all domain names, including those
> that contain A-labels, back over to the rules of RFC 1034 and
> 1035 and the acceptance of special dots into a UI issue. To me,
> the arguments for that choice are overwhelming.  But it is a
> tradeoff against user-predictable behavior with scripts that
> use non-ASCII dots and compatibility with existing non-protocol
> text that represents IDNs using those dots: if applications
> that map between such text and the IDNA protocol don't do the
> right UI things with dots other than U+002E, bad things will
> happen.  And, if we work the tradeoffs so that types of
> compatibility issues overwhelm the reasons why special dot
> mapping was a bad idea, then we are stuck with the special dots
> forever.