Chris Weber ch...@lookout.net:
I downloaded Opera 12 pre-alpha and IDNA2008 doesn't seem to be in here
either... correct?
The current Opera 12 build from http://my.opera.com/desktopteam/blog/ does
have IDNA2008 support.
--
\\// Peter Krefting - Core Technology Developer, Opera Software
I downloaded Opera 12 pre-alpha and IDNA2008 doesn't seem to be in here
either... correct?
Another question around bundling and blocking. Is the recommendation
here that all domains containing an ss should be considered for
bundling and blocking? So for all new domain name registrations
, July 08, 2011 10:11 AM
To: unicode@unicode.org
Subject: Re: UTS46 transitional period
I downloaded Opera 12 pre-alpha and IDNA2008 doesn't seem to be in here
either... correct?
Another question around bundling and blocking. Is the recommendation here that
all domains containing an ss should
30, 2011 3:10 PM
To: Neil Harris
Cc: unicode@unicode.org
Subject: Re: UTS46 transitional period
On 6/29/2011 4:12 PM, Neil Harris wrote:
Firefox currently has an open bug for IDNA 2008 implementation:
https://bugzilla.mozilla.org/show_bug.cgi?id=479520
-- Neil
Interesting, thanks
On 6/29/2011 4:12 PM, Neil Harris wrote:
Firefox currently has an open bug for IDNA 2008 implementation:
https://bugzilla.mozilla.org/show_bug.cgi?id=479520
-- Neil
Interesting, thanks for sharing. Nice of DENIC to give a... ahem... 3
week sunrise period. I hope nobody was on vacation!
Den 2011-06-29 04:41:22 skrev Chris Weber ch...@lookout.net:
I was trying to understand the implementation differences in some
browsers and registrars. Using your example from UTS46
http://xn--fa-hia.de/
Opera - error, doesn't resolve
We have recently implemented support for IDNA 2008
On 6/28/2011 11:20 PM, Peter Krefting wrote:
Den 2011-06-29 04:41:22 skrev Chris Weber ch...@lookout.net:
I was trying to understand the implementation differences in some
browsers and registrars. Using your example from UTS46
http://xn--fa-hia.de/
Opera - error, doesn't resolve
We have
For Chrome, we're working on UTS46 support, but I can't comment on schedule.
Mark
*— Il meglio è l’inimico del bene —*
On Wed, Jun 29, 2011 at 15:25, Chris Weber ch...@lookout.net wrote:
On 6/28/2011 11:20 PM, Peter Krefting wrote:
Den 2011-06-29 04:41:22 skrev Chris Weber
On 29/06/11 23:25, Chris Weber wrote:
On 6/28/2011 11:20 PM, Peter Krefting wrote:
Den 2011-06-29 04:41:22 skrev Chris Weber ch...@lookout.net:
I was trying to understand the implementation differences in some
browsers and registrars. Using your example from UTS46
http://xn--fa-hia.de/
On a tangent, under IDNA2003 rules, shouldn't registration and
resolution of the punycode form of "faß.de", which is
"xn--fa-hia.de" be illegal since the nameprep process would mapp the
eszett to "ss"?
On 6/27/2011 4:14 PM, Mark Davis ☕ wrote:
Once the
It depends on what you mean.
Registrars could and did allow users to enter in labels for registration
that would end up getting remapped to other labels before registration. That
is, they could let people enter in faß.de http://fass.de or ÖBB.at, even
though what was actually registered as far as
I was trying to understand the implementation differences in some
browsers and registrars. Using your example from UTS46
http://xn--fa-hia.de/
Opera - error, doesn't resolve
Internet Explorer - error, doesn't resolve
Chrome, FF, and Safari - all resolve with
IDNA2008 doesn't require that validation be done on punycode.
http://tools.ietf.org/html/rfc5891#section-5.3
If the input to this procedure appears to be an A-label (i.e., it
starts in xn--, interpreted case-insensitively), the lookup
application *MAY* attempt to convert it to a U-label
Once the registries (of that support the 4 special characters) have adopted
bundling/blocking policies, then it will be possible for client software to
safely move off of the transitional approach. So it is really dependent on
the registries' behavior. Different clients may have different
14 matches
Mail list logo
