gmane.ietf.idnabis

Re: An implementer's lament

Martin J. Dürst — 2012-11-29T05:48:58

Just for the record, Anne is not an implementer. He used to work for an 
implementer. His blog post is mostly written from the view of a spec writer.

Also, he takes (what I think is) the right conclusion at the bottom: 
Wait a bit.

Regards,   Martin.

On 2012/11/28 12:28, Paul Hoffman wrote:

An implementer's lament

Paul Hoffman — 2012-11-28T03:28:44

http://annevankesteren.nl/2012/11/idna-hell

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

JFC Morfin — 2012-11-18T01:28:24

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

Mark Davis ☕ — 2012-11-17T05:05:55

Let me try again.

   1. Clearly there was consensus in the WG that a certain bundle of
   features was more important than backwards compatibility. No objection to
   that fact.
   2. Just as clearly, some people disagree with those priorities, and
   think that backwards compatibility was more important than that bundle of
   features.



Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**



On Fri, Nov 16, 2012 at 8:54 PM, John C Klensin <klensin< at >jck.com> wrote:

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

John C Klensin — 2012-11-17T04:54:01


--On Friday, November 16, 2012 15:59 -0800 Mark Davis ☕
<mark< at >macchiato.com> wrote:


And retaining mapping as part of the protocol rejects the notion
that having a dual relationship between A-labels and U-labels is
very important (or even just important).  The WG considered it
quite important.  See Vint's note.  Also remember that IDNA is
not just about the web and that other protocols that use domain
names as part of identifiers (sometimes without resolving them)
may have their own guidance about comparison of those
identifiers.

best,
   john


_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

Mark Davis ☕ — 2012-11-16T23:59:59

I specifically did not say it was.

Option 1 is clearly *not* IDNA2008. That is option 2.

If Option 1 is expressed so as to accurately represent an alternative
approach that does maintain compatibility, then it includes mapping.


Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**



On Fri, Nov 16, 2012 at 1:41 PM, Patrik Fältström <paf< at >frobbit.se> wrote:

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

Vint Cerf — 2012-11-16T23:15:19

I am loathe to return to the debates of the 2008-2010 period but the strong
utility of canonical forms that are unambiguous as to identity (ie between
A-Label and U-Label) should not be underestimated. Mapping has the
unfortunate side-effect of making things "equivalent" when they are not in
fact identical. I think many who were in favor of the IDNA2008 formulation
were persuaded that this powerful feature was worth some breakage with
regard to backward compatibility. It is obvious that there is a value
judgment here and people's opinions varied.

vint



On Fri, Nov 16, 2012 at 5:45 PM, Anne van Kesteren <annevk< at >annevk.nl> wrote:

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

Anne van Kesteren — 2012-11-16T22:45:15

Thanks! So apart from Opera no browser has changed their IDNA
approach. And Opera has not exactly aligned with IDNA2008 either. It
seems the pragmatic approach is to stick with IDNA2003+, meaning
IDNA2003 algorithms with an updated version of Unicode.

I'm not at all convinced it's web compatible to change the approach
here, no matter how many warnings have been given to web developers
that non-normalized identifiers might not be portable in the long run.
Web developers expect backwards compatibility. And the approach to
make this work via domain registrars is flawed too, as that does not
account for subdomains, such as the one I mentioned earlier.

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

Patrik Fältström — 2012-11-16T21:41:06

Offline I have been asked to respond after all, so here we go.

On 16 nov 2012, at 12:36, Mark Davis ☕ <mark< at >macchiato.com> wrote:


What is different between what I wrote and what you wrote?


Correct.


Mapping is not part of IDNA2008, and the need for a 1:1 mapping between A- and U-label is a requirement as outlined in various documents.


I very explicitly did write inability to use ß in an A- or U-label.

   Patrik

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

Patrik Fältström — 2012-11-16T21:17:58


I give up.

   Patrik

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

Mark Davis ☕ — 2012-11-16T20:36:06

I really don't want to revisit all this. It was painful enough the first
time, and people are still extraordinarily sensitive. Saying that someone
was not concerned about backwards compatibility is *not* name-calling.
There are times when it is perfectly legitimate to not be concerned, and
there are often areas where I'm not concerned: typically where the usage is
so low, or the effects are so small, or the benefits are so large, that it
is still worth doing.

Speaking of this, Patrik gives two options:

   1. Backward compatibility with IDNA2003, extend the number of exceptions
   to the algorithm to use, and never ever be able to use ß as a character in
   A- or U-labels.
   2. Using an algorithm based on Unicode Codepoint meta data (from Unicode
   Consortium) to calculate whether codepoints where to be allowed or not,
   take the pain of incompatibility via sunrise for very few code points (like
   ß), but finally acknowledge ß as a character on its own (as Unicode has
   defined it), separate from "s

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

Paul Hoffman — 2012-11-16T19:18:11


I am someone who, often vocally, disagreed with the way IDNA2008 went with respect to backward compatibility. Having said that, I think Mark's characterization of the people who were promoting IDNA2008 as "people who did not feel that it was an important concern" is simply wrong. The long discussions about backward compatibility on the mailing list very much showed that the authors were concerned about it and were willing to incorporate changes for backward compatibility that had WG consensus (of which I was often on the wrong side).

We have IDNA2003 and IDNA2008 in deployment, both partially. We knew that this would happen, we talked about it, and we did IDNA2008 anyway. Name-calling at this point is not helpful to developers and end users of the two protocols.

--Paul Hoffman

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

John C Klensin — 2012-11-16T14:09:11


--On Thursday, November 15, 2012 18:22 -0800 Mark Davis ☕
<mark< at >macchiato.com> wrote:


Mark,

I don't want to drag this out, but even that change implies that
we dismissed the "backward compatibility" issues as unimportant.
That wasn't the case.  We (or at least some of us):

(i) Saw some nuances about what you call "backward
compatibility" and put less weight on some of the practices you
roll into that category than others.  Even those we did weight
higher were unimportant, they just didn't win out given other
considerations.

(ii) Saw other issues as important, indeed very important, but
not sufficiently important/ persuasive to overwhelm the other
considerations identified in my earlier note.

In addition, as indirectly mentioned earlier, some of us were
very concerned and skeptical about strategies that were
suggested as "temporarily maintain more backward compatibility"
or "provide better transition" unless there was a clear stopping
model.    I can't speak for others, but I would have supported a

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

Patrik Fältström — 2012-11-16T13:42:16


As I am named, although not by name, by Mark, I feel I must explain my view -- again -- as I do not think Mark explains it correctly:

The choice was between:

- Backward compatibility with IDNA2003, extend the number of exceptions to the algorithm to use, and never ever be able to use ß as a character in A- or U-labels.

- Using an algorithm based on Unicode Codepoint meta data (from Unicode Consortium) to calculate whether codepoints where to be allowed or not, take the pain of incompatibility via sunrise for very few code points (like ß), but finally acknowledge ß as a character on its own (as Unicode has defined it), separate from "ss".

For me, the second of these did win. Without any doubt. Short term pain with long term benefits.

   Patrik

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

Martin J. Dürst — 2012-11-16T11:31:49

Hello Mark,

On 2012/11/16 8:56, Mark Davis ☕ wrote:


For Opera, http://www.amt-golßener-land.de/ goes to a Wordpress blog 
page about "IDNA2008 & ß". This means that with respect to ß, Opera 
implements IDNA2008. For other browsers (I tested IE9, Safari, Firefox 
and Chrome on Windows 7), this page can be reached at 
http://www.xn--amt-golener-land-mlb.de (as indicated above).

As far as I understand the plan behind IDNA2008, the idea was that 
first, the affected registries (and DENIC is the most affected here of 
course) will make sure that their registrees have a chance to catch up 
(with bundling, sunrise, or whatever). In a next step, the browsers 
would adopt.

DENIC did this with sunrise 
(http://www.denic.de/domains/internationalized-domain-names/einfuehrung-eszett.html 
mentions "Vorzugsregistrierung für die Inhaber bestehender Domains mit 
dem Namensbestandteil „ss“").

It looks like the owners of http://www.amt-golssener-land.de didn't use 
the sunrise opportunity. We don't know whethe

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

Mark Davis ☕ — 2012-11-16T02:22:57

point taken:

concerns --> important concerns



Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**



On Thu, Nov 15, 2012 at 5:27 PM, John C Klensin <klensin< at >jck.com> wrote:

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

John C Klensin — 2012-11-16T01:27:23


--On Thursday, November 15, 2012 15:56 -0800 Mark Davis ☕
<mark< at >macchiato.com> wrote:


Mark,

Certainly there was a disagreement in the WG about which
objectively to prioritize.  However, characterizing the people
who disagreed with you as feeling "that backwards compatibility
and migration were not concerns" doesn't seem accurate to me.
Instead, many of us felt that they _were_ concerns, but that we
saw engineering/design tradeoffs between preserving
compatibility with whatever had been done under the IDNA2003
umbrella and other concerns, including:

(1) The higher degree of identifier (including URL) stability
and predictability that would result from a strict one-one
relationship between (in IDNA2008 terms) A-labels and U-labels
was an advantage and that the difficulties that had arisen from
the lack of that relationship in IDNA2003 was a concern.

(2) Some of the incompatible changes made in IDNA2008, including
permitting ZWJ and ZWNJ rather than discarding them and allowing
some characters that IDN

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

Mark Davis ☕ — 2012-11-15T23:56:07

Anne,

The development of IDNA2008 was a long, painful, and frustrating process,
with a split between:

   - people who were concerned with backwards compatibility and what would
   happen during a migration period (such as most representatives to the
   Unicode consortium, and
   - people who did not feel that it was a concern (such as John, the other
   authors, and most participants in the WG).

The rough consensus of the WG was judged to be that backwards compatibility
and migration were not concerns, and that's what went into idna2008.

Yet for companies like mine, compatibility is rather important; we need to
ensure that URLs like http://ÖBB.at <http://xn--bb-eka.at> continue to work
as people expect, and URLs like
http://www.amt-golßener-land.de/<http://www.amt-golssener-land.de/>go
to a single location, rather than (depending on the browsers),
sometimes:

   - sometimes their original pages (http://www.amt-golssener-land.de)
   - sometimes new pages (http://www.xn--amt-golener-land-mlb.de)

Not wan

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

Dave Thaler — 2012-11-15T20:12:31

IE10 resolves http://www.ad--acta.de/ and you get to the page.

And when you put in http://faß.de the page you get to after resolution and
redirects is http://www.bayern-fass.de/cms/website.php 

-Dave
 
_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

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

John C Klensin — 2012-11-15T18:08:00


--On Thursday, November 15, 2012 08:28 -0800 Anne van Kesteren
<annevk< at >annevk.nl> wrote:


Anne,

Statements like "Host names have been case-insensitive from the
start" are precisely where i18n design decisions start wandering
into the swamp.  From the start, host names have been basic,
undecorated, "Latin" characters, coded in [seven bit] ASCII and
transmitted over the Internet with a leading zero on each octet.
Worse, while the DNS (server) case-matching rules provide and
support case-insensitive matching for ASCII, if one were to code
UTF-8 or ISO 8859-1 (or ISO 8859-anything else) into the DNS,
octets whose high bit is one are compared without any adjustment
for case, i.e., case-sensitively.

"A" is just an example, but the problem is that in some
languages and locales, not only does "a" (U+0061) upper-case to
"A" (U+0041), but so does "á" (U+00E1).  In other languages and
locales, á upper-cases to "Á" (U+00C1) -- it just depends.
And that makes it plausible that the lower case form of "A" can
be ei

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

Paul Hoffman — 2012-11-15T16:47:46


Something that Jefsey made up to sound important. Welcome to the less fun part of the world of i18n.


Arguing facts with Jefsey has not proven to be useful in the past, but hope springs eternal.


Exactly.


Further, even when they do enter addresses in address bar, i18n is just one place where the browsers change everything based on what the browser designers think would be best for the users.

--Paul Hoffman
_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update