Updating RFC 5890-5893 (IDNA 2008) to Full Standard

[John C Klensin]

(top post and personal opinion only)

Simon,

Many thanks to you and Kajtan.

FWIW, while not precisely conforming to IDNA2008 (whether it
would meet IETF's requirements for interoperable implementations
is an interesting question), my personal view is that, at least
as part of a transition strategy, what you/ Opera has done is a
perfectly rational implementation.  For the long term, I do
worry a bit about "never prevent DNS lookups" (I've referred to
that elsewhere as "lookup everything"), particularly because
newly-assigned code points in further versions of Unicode may
have properties requiring special treatment.  But your decision
to display those as A-labels ("Punycode") would mitigate almost
all of the possible ill-effects of such a change for an alert
user.

That might sort of generalize: a reasonable API interface might
accept a native character string and return the relevant DNS
records, if any, and a status indication of "conforming but
mapped", "conforming unmapped", "conforming but dubious (e.g.,
mixed script label)", or "non-conforming".  Again, just IMO.

thanks,
    john

p.s. I'm tied up with IETF and other work and on travel and
won't be able to respond further to the other thread until
probably sometime late next week.


--On Friday, 09 November, 2012 10:19 +0100 Simon Pieters
<simonp at opera.com> wrote:

> On Thu, 08 Nov 2012 06:45:11 +0100, Martin J. Dürst
> <duerst at it.aoyama.ac.jp> wrote:
> 
>> On 2012/11/08 13:18, "Martin J. Dürst" wrote:
>> 
>>> Hello John,
>>> 
>>> I think this should happen sooner or later. However, Anne
>>> van Kesteren recently pointed out that the major browsers
>>> haven't yet done too much with respect to implementing UTR
>>> 46, which I'd guess implies that they haven't yet
>>> implemented much of IDNA 2008, either (Anne, can you confirm
>>> or clarify?).
>> 
>> By chance, I found the reference that I was referring to
>> again: http://annevankesteren.nl/2012/09/idna2008
>> 
>> I also found some mentioning that Opera implemented IDNA2008:
>> http://www.opera.com/docs/specs/presto2.12/networking/
>> I haven't tested it, and I don't know what exactly (if
>> anything) Opera   is doing for backwards compatibility. (On
>> the above page, IDNA 2003 is   still mentioned as supported.)
>> Simon, do you know more? Any feedback   from Opera on IDNA
>> 2008?
> 
> I asked our developers who implemented this.
> 
> [[
> Hi Simon!
> 
> First of all what we have is not IDNA2008 + UTS46. In general
> we've implemented IDNA2008 + RFC5895 but with few diversions:
> - we NEVER prevent DNS lookups,
> - all domain names violating IDNA2008 (and some more, listed
> below) are presented in UI in the punnycoded version (rfc3492)
> only. Those are domains that:
> 	- contain characters classified as INVALID (rfc5892),
> 	- contain characters classified as CONTEXTJ or CONTEXTO but
> in wrong context (rfc5892),
> 	- for which BIDI rules are not met (rfc5893),
> 	- are using characters from 2 or more scripts that should not
> be used together (our own heuristic that e.g. blocks
> displaying http://www.gooɡle.com/ - IDNA2008 allows that one).
> 
> 
> /Kajtan
> ]]
> 
> HTH,
> 
>> Regards,   Martin.
>> 
>>> Given that browsers are an important part of IDNA users,
>>> it might be prudent to wait for some more time and see what
>>> issues might come up from that side.
>>> 
>>> (That was also why I asked Marcos about deployment of "ß";
>>> the story was that registries would first deploy these with
>>> the respective bundlings or restrictions, and then browsers
>>> could move ahead and resolve them directly.)
>>> 
>>> Regards, Martin.
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/idna-update
> 
> 
> --Simon Pieters
> Opera Software