No subject

Tue Nov 18 23:43:20 CET 2008

bundling. However, the "permanent" interopability issues outlined above =
are bound to "taint" labels with an "=C3=9F" for an indefinite period of =
time, with the most sensible option to disallow registration completely =
to avoid those problems.

I think it's not very likely that all vendors agree on a single mapping =
- particularly with the WG scope of not dealing with a mapping as part =
of the protocol. However, i'd like to propose the following:

- add text to Section 5 of idnabis-protocol that says

       "characters that are PVALID MUST NOT be subject to mappings".

Or (more focused)

       "characters that are listed as Exceptions (F) in Section 2.6
        of [tables] MUST NOT be subject to mappings"

I'm not sure whether that contradicts the "local matters" part in =
Section 5.1 (and i'm pretty sure it creates problems elsewhere), but i =
think it solves the "permanent interopability" problem outlined above. =
That means that "=C3=9F" stops working during the transition period, but =
also means that it can be treated as an independent character *after* =
the transition - bundling is not required, Mr Weiss and Mr Wei=C3=9F can =
both have their distinct domain names, etc..

Is that a way forward? Comments appreciated.

Alex

_______________________________________________
Idna-update mailing list
HYPERLINK "mailto:Idna-update at alvestrand.no" \nIdna-update at alvestrand.no
HYPERLINK "http://www.alvestrand.no/mailman/listinfo/idna-update" =
\nhttp://www.alvestrand.no/mailman/listinfo/idna-update

=20

Internal Virus Database is out-of-date.
Checked by AVG.=20
Version: 7.5.560 / Virus Database: 270.12.26/2116 - Release Date: =
15/05/2009 06:16
=20

------=_NextPart_000_054D_01CA741C.93E78390
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dutf-8">

<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:597101261;
	mso-list-template-ids:-33502570;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I think adding a TRANSITIONAL =
status may
go someway towards alleviating this problem.=C2=A0 Although, as Georg =
pointed out,
this would mean that the WG would need to reconvene.=C2=A0 However, if =
you add a
TRANSITION DATE field everyone knows where they are at (and when) and no =
need
to reconvene.=C2=A0 You could also add a =E2=80=9CTransitional =
relationship=E2=80=9D field which
would include ss for </span></font><font size=3D2 color=3Dnavy =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:navy'>=C3=9F =
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>and add text to the document stating that registries should =
bundle transitional
characters until the TRANSITION DATE when </span></font><font size=3D2
color=3Dnavy face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:navy'>=C3=9F et al would become PVALID</span></font><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>.=C2=A0 =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Mark =
wrote:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

&gt;&gt; That will =
cause
currently valid URLs to fail, but that is far better than having them =
have
ambiguous targets. This way we get to the long-term goal of having these =
characters
be PVALID, without having the disruption during the =
interim.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>I don=E2=80=99t like the idea of =
currently valid
URLs failing.=C2=A0 This would be addressed (I think) by bundling until =
2016?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><o:p>&nbsp;</o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Best =
regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><o:p>&nbsp;</o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Debbie</span></font><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

From: =
idna-update-bounces at alvestrand.no
[mailto:idna-update-bounces at alvestrand.no] On
Behalf Of Mark Davis ? 
Sent: 01 December 2009 =
17:49 
To: Alexander =
Mayrhofer 
Cc: Shawn Steele; Patrik
F=C3=A4ltstr=C3=B6m; Harald Alvestrand; idna-update at alvestrand.no; lisa =
Dusseault;
&quot;Martin J. D=C3=BCrst&quot;; Vint Cerf 
Subject: Re: The real =
issue:
interopability, and a proposal (Was: Consensus Call on Latin Sharp S and =
Greek
Final Sigma)<o:p></o:p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

I don't think that anyone at this point would really stand in =
the way
of these characters being PVALID, if it weren't for compatibility =
problems. To
that end, I think the key issue is the transition strategy: how to deal =
with
the 5 or so years where the browser implementations are transitioning to
IDNA2008. If we had an adequate strategy, I don't think anyone would =
really
stand in the way of having the 4 problem characters be valid. 
 
These 4 characters are unlike symbols in two ways: (a) with symbols you =
don't
go to two different places with two different browsers, and (b) symbols =
are far
less frequent than these characters. So even though the prohibition on =
symbols
was based on no particular evidence, the prohibition doesn't cause a =
severe
compatibility issue. 
 
When reading some of the transition proposals, one approach occurred to =
me.
What if we have a new status for the 4 characters: TRANSITIONAL? 
 
We set it up in this way; in IDNA2008, TRANSITIONAL characters are =
invalid for
registration and lookup, AND cannot be mapped. After a period of some =
years,
once the percentage of IDNA2003 browsers and emailers have dropped to a =
small
proportion, the stated plan is to issue a new version of IDNA that =
changes them
to PVALID. 
 
That will cause currently valid URLs to fail, but that is far better =
than
having them have ambiguous targets. This way we get to the long-term =
goal of
having these characters be PVALID, without having the disruption during =
the
interim. 
 
=3D=3D=3D 
 
As far as Harald's back-of-the-envelope calculations go, they present a =
very
inaccurate picture of the scale. Here are some more exact figures for =
that
data.<o:p></o:p>

<ol start=3D1 type=3D1>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>819,600,672&nbsp;&nbsp;&nbsp; =3D sample =
size of
     documents<o:p></o:p></span></font></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>5,000&nbsp;&nbsp;&nbsp; =3D links with =
eszed in the
     sample<o:p></o:p></span></font></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>1,000,000,000,000&nbsp;&nbsp;&nbsp; =3D =
total
     documents in index (2008)<o:p></o:p></span></font></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>1,220&nbsp;&nbsp;&nbsp; =3D scaling =
factor (=3D total
     docs / sample size)<o:p></o:p></span></font></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>6,100,532&nbsp;&nbsp;&nbsp; =3D =
estimated total
     links with eszed (=3D scaling * sample eszed =
links)<o:p></o:p></span></font></li>
</ol>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Even this has =
to be taken
with a certain grain of salt, since (a) it is assuming that the sample =
is
representative (although we have reasonable confidence in that), and (b) =
it
doesn't weight the &quot;importance&quot; of the links (in terms of the =
number
of times they are followed), and (c) this data was collected back in Nov =
2008,
so we've had another year of growth since then.<br>
<br clear=3Dall>
Mark<br>
<br>
<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>On Tue, Dec 1, 2009 at 01:59, Alexander Mayrhofer &lt;<a
href=3D"mailto:alexander.mayrhofer at nic.at" =
target=3D"_blank">alexander.mayrhofer at nic.at</a>&gt;
wrote:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><br>
(I've spent quite some time on re-thinking the issue last night. It's a =
bit
longish, and the promised proposal is at the end).<br>
<br>
I think i didn't make it clear enough in my previous messages that i'm =
not an
opponent of the character Latin Sharp S itself. I'm opposing against =
changes
that have a high risk of introducing interopability, particularly in the =
long
run.<br>
<br>
My *only* major concern is that the introduction of the Latin Sharp S is
exactly such a case, but a particularly nasty one. I understand that the
majority of WG participants think that &quot;=C3=9F&quot; should be =
PVALID (i'm
carefully avoiding the word &quot;concensus&quot; here, because it's =
obviously
up to the WG chair to declare that).<br>
<br>
If i look at the issue in an isolated way, not considering any =
compatibility/interopability
issues, then it makes perfectly sense to declare &quot;=C3=9F&quot; =
PVALID, because
(this is sort of convincing myself here ;) :<br>
<br>
- There seems to be little existing deployment of =C3=9F-labels out =
there, at least
on the web - the client side is a different issue, there's nearly 100%
deployment. We can also err guesstimate that &quot;=C3=9F&quot; has only =
about 1% of
the deployment of other german &quot;umlauts&quot;, according to Erik's =
numbers
(As Eric pointed out, those numbers have no indication of confidence, =
though).
We don't know how many people type &quot;=C3=9F&quot; into their browser =
address
bar, though, which is at least &quot;unsatisfying&quot; from an =
engineering
perspective.<br>
<br>
- The character is undoubtly part of German grammar, at least in two of =
the
three countries where German is an official language - i don't know =
about the
minorities in other countries. The upper case variant as well as the =
Unicode
casing and folding is.. well, extravagant - but the lowercase =
&quot;=C3=9F&quot; is
definitely part of the grammar.<br>
<br>
- Georg's argument that this would be &quot;the last chance&quot; to =
introduce
&quot;=C3=9F&quot;, got me thinking. If the &quot;Exceptions&quot; would =
be
implemented as an IANA registry, it would be much easier to add (and =
probably
remove) characters. But given that changes to the Exceptions now require =
an
update to the base specification, we should probably take this =
opportunity,
rather than waiting for IDNA2015.<br>
<br>
So, as i said multiple times, the problem is changing the semantics of a =
part
of the namespace, definitely from the user's perspective - one could =
argue
whether or not that means the &quot;protocol semantics&quot; change, =
since the
mapping step ist part of the protocol of IDNA2003.<br>
<br>
Regarding interopability, i'm not so much concerned about the transition =
period
between IDNA2003 and IDNAbis. This will be painful, but it will be =
(hopefully
temporary).<br>
<br>
What i am more concerned is that the legacy of the &quot;=C3=9F-ss&quot; =
mapping
would introduce incompatibility for an indefinite period of time, =
*after* all
clients have switched over to IDNAbis. This could happen because some =
vendors
would implement mappings to be fully IDNA2003 backwards compatible, and =
others
would implements the informative idnabis-mappings only.<br>
<br>