Louis,<br>JFC's motto is "nothing is impossible to who does not care
one knows who made it!". But if you read Mark carefully you will find
some oddities.<br><br>2009/4/10 LB <span dir="ltr"><<a href="mailto:lbleriot@gmail.com" target="_blank">lbleriot@gmail.com</a>></span><div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span style="border-collapse: collapse;"></span><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div>We
need to recognize that the people in this working group are a very
small subset of those affected by the changes we make, and are only
partially representative. Someone whose primary editor is emacs, for
example, is hardly a typical user! Of course the WG is open to any and
all comers,</div></div></blockquote></div></blockquote></div><div><br>Except our france@large and the A-FRA Chair. Interesting enough.<br> <br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div> but certainly not all types of people that will be directly
or indirectly affected by these changes will realize that this group
even exists, let alone that it will be making incompatible changes.
(When I mention to ordinary engineers that the changes in IDNA2008 will
result in the same URL going to different IP addresses on different
browsers, they look at me like I'm completely, utterly, crazy.)<br><br>Most
of the people on this list will not be the ones that get the error
reports, where people are really upset because something used to work
and doesn't anymore. We will only find out after the fact just how bad
it is - sadly, we don't have the luxury of a beta phase, where our
users can see what the effects of these changes are, and let us know
where we must make changes.</div></div></blockquote></div></blockquote></div><div><br>The beta phase resulted in banning the user :-) <br>This starts making noise around .... so one becomes more careful.<br>Whatever the story they build, users will have to bite it.<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div>
But before we blithely rush to doing just case+width mapping, we have
to do due diligence: carefully looking over the other instances, and
making sure that exclusion is on balance the right approach. It is
probably ok to remove Arabic presentation forms, but we'd better check
first with the Arabic-script communities to make sure; just as we heard
back from the CJK communities that Width mapping was important.</div></div></blockquote></div></blockquote></div><br>You will note he does not want to quote French scripting problem: it creates a fundamental problem due to the ASCII upper-cases.<br>
JFC says that we do not care as .FRA will not use "xn--", I would suggest we try a little bit longer before saying that.<br><br>Mark speaks French very well. I am sure he can read: <a href="http://fr.wikipedia.org/wiki/Majuscule" target="_blank">http://fr.wikipedia.org/wiki/Majuscule</a>.<br>
<br>In case some people on this list do not read French, they can
easily feel the complexity: in comparing the page size with its English
counter-part: <a href="http://en.wikipedia.org/wiki/Capital_letter" target="_blank">http://en.wikipedia.org/wiki/Capital_letter</a>.<br>
<br>Rémy Renardin<br><br><br><div class="gmail_quote">2009/4/10 LB <span dir="ltr"><<a href="mailto:lbleriot@gmail.com">lbleriot@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span style="border-collapse: collapse;">JFC called me to ask me to send "+1"<div>---</div><div>LB</div><div><br></div></span><div class="gmail_quote">2009/4/10 Mark Davis <span dir="ltr"><<a href="mailto:mark@macchiato.com" target="_blank">mark@macchiato.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">I usually try to err on the side of concision, since otherwise I know
people's eyes quickly glaze over, but I'll take a bit longer to address
the issue you raised (though I will never be any competition for John
;-). So please bear with me this time.<br><br>The reason that I
included the ability to change the mapping filter is just so that
people could try out different choices, and see what an actual
difference it would make. I suspect that we will end up with not using
the IDNA2003 mapping style (NFKC+CF+removing default ignorables), but
we need to examine our choices very carefully. For example, I think
John's suggestion of not having the "removing default ignorables" be
part of the mapping is a reasonable one.<br><br>I may seem pretty
conservative on this account. This is probably due to the experiences
of over 20 years with Unicode, which is such a core technology that
changes ripple quite broadly. There have been times where we made a
change that looked absolutely reasonable, would be clearly the right
thing to do, and would not affect anyone negatively --<i> where all reports from contacts in community X </i><i>(eg BIDI) </i><i>said that they didn't use the characters, and so a change wouldn't matter.</i> Yet once systems start being deployed, low and behold the error reports come rolling in -- it turns out that they <b>are</b>
used by X community, and users are extremely unhappy. Those of us who
have worked in operating systems are also painfully aware of this kind
of problem.<br><br>So even though Unicode could be improved in many
ways with incompatible changes, we have really gotten quite
conservative about them, just because of unintended and unforeseen
consequences.<br><br>Someone on this listed noted that "The registrants
are the main clients of IDN domains, hence they are the main clients of
this WG." That is not true: there are many, many stakeholders involved.
Registrants certainly, but also
registries, and <i>most importantly,</i> users of programs that
accept and display URLs:
browsing, email, chat, IM, and so on. Those users include a very a
pretty signficant portion of the world's population. And we will face a
long transition period where both IDNA2003 and its successor are in
play - we at Google see just how many people are using very old
browsers, and of course the DNS people know just how long it has taken
to deploy IPv6.<br><br>We
need to recognize that the people in this working group are a very
small subset of those affected by the changes we make, and are only
partially representative. Someone whose primary editor is emacs, for
example, is hardly a typical user! Of course the WG is open to any and
all comers, but certainly not all types of people that will be directly
or indirectly affected by these changes will realize that this group
even exists, let alone that it will be making incompatible changes.
(When I mention to ordinary engineers that the changes in IDNA2008 will
result in the same URL going to different IP addresses on different
browsers, they look at me like I'm completely, utterly, crazy.)<br><br>Most
of the people on this list will not be the ones that get the error
reports, where people are really upset because something used to work
and doesn't anymore. We will only find out after the fact just how bad
it is - sadly, we don't have the luxury of a beta phase, where our
users can see what the effects of these changes are, and let us know
where we must make changes.<br><br>That's why we in this group need to
very careful about incompatible changes to an existing, deployed
standard (IDNA2003) except where:<br>
<br>
<div style="margin-left: 40px;">(a) there is clear harm, or <br>
(b) the characters in question occur in demonstrably very low frequency.<br>
</div>
<br>The latter is why the Unicode Consortium is ok, for example, with
the removal of the vast majority of symbols and punctuation, because
the vast majority are used with such low frequency, even though only a
couple of them have actually be shown to be at all harmful. And I think
it is probably ok to remove the circled items from mapping
(<a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B:dt=Enc:%5D" target="_blank">http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:dt=Enc:]</a>),
even though they cause no harm either (removal has little potential
upside, only potential downside).<br>
<br>
But before we blithely rush to doing just case+width mapping, we have
to do due diligence: carefully looking over the other instances, and
making sure that exclusion is on balance the right approach. It is
probably ok to remove Arabic presentation forms, but we'd better check
first with the Arabic-script communities to make sure; just as we heard
back from the CJK communities that Width mapping was important.<br><br>And
people cannot simply depend on the Unicode decomposition type (dt) (See
<a href="http://unicode.org/cldr/utility/properties.jsp#Decomposition_Type" target="_blank">http://unicode.org/cldr/utility/properties.jsp#Decomposition_Type</a>) to
make all the decisions for them; it would not be a good idea to exclude
DZ from mapping, for example, and its dt is Compat. The dt property will
be useful, in the the same way as other property-based rules in the
tables doc are, but the categories defined by that property may not
match exactly to what end-user's needs are, and thus need to be
reviewed.<br><font color="#888888"><br>Mark<br></font><br>PS. And bringing this back to subject of the online tool, if there are changes to the tools at
<a href="http://unicode.org/cldr/utility/index.jsp" target="_blank">http://unicode.org/cldr/utility/index.jsp</a> that would help in such a
review, please let me know.
<br></div></div>_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><font color="#888888">LB<br>
</font><br>_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
<br></blockquote></div><br>