<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Lucida Sans Unicode";
panose-1:2 11 6 2 3 5 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>No, that’s not what my email implies: read more carefully ;-).
There are no evident benefits of B over A, and detrimental effects of changing
A to B. So, seems to make sense to stick with A.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Phillips, Addison
[mailto:addison@amazon.com] <br>
<b>Sent:</b> Saturday, February 28, 2009 8:55 AM<br>
<b>To:</b> Peter Constable; Mark Davis; Tex Texin<br>
<b>Cc:</b> ietf-languages@iana.org; Doug Ewell<br>
<b>Subject:</b> RE: Proposal to remove Preferred-Value field for region YU in
LTRU<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Did you mean “the sensible choice is to remove the PV field”?
That’s what your email implies, but not what your last sentence says.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Addison<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<p class=MsoNormal><span style='font-size:9.0pt;font-family:"Lucida Sans Unicode","sans-serif";
color:#1F497D'>Addison Phillips<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:9.0pt;font-family:"Lucida Sans Unicode","sans-serif";
color:#1F497D'>Globalization Architect -- Lab126<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:9.0pt;font-family:"Lucida Sans Unicode","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:9.0pt;font-family:"Lucida Sans Unicode","sans-serif";
color:#1F497D'>Internationalization is not a feature.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:9.0pt;font-family:"Lucida Sans Unicode","sans-serif";
color:#1F497D'>It is an architecture.<o:p></o:p></span></p>
</div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
ietf-languages-bounces@alvestrand.no
[mailto:ietf-languages-bounces@alvestrand.no] <b>On Behalf Of </b>Peter
Constable<br>
<b>Sent:</b> Saturday, February 28, 2009 8:50 AM<br>
<b>To:</b> Mark Davis; Tex Texin<br>
<b>Cc:</b> ietf-languages@iana.org; Doug Ewell<br>
<b>Subject:</b> RE: Proposal to remove Preferred-Value field for region YU in
LTRU<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There are two options involving the two records<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A)
YU -> CS<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>
CS<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Or<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>B)
YU<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>
CS<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Some observations:<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>(i) We all agree that both options result in paths that are dead
ends. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>(ii) We all agree that the regions have split into multiple
regions, that PV cannot be used to indicate multiple regions, and that LTRU
should not change the 4646bis draft to accommodate data indicating a multi-way
split.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>(iii) We all agree that users wondering how something tagged
with YU or CS might be tagged under today’s recommendations, and that
(optional) comments might be useful additions to the records for this purpose.
And given (ii), comments are the only way to accomplish this.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In light of those observations, option A is not any better than
option B for users wondering how Balkan nations have changed and what the
implications are for tagging: only comments or user research can answer that,
and either can be applied to either option.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>However, the change from A to B does have an impact on
canonicalization that can change the behaviour of implementations using it.
There is no benefit to that behaviour change; it is likely detrimental.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hence, it seems the sensible choice is not to remove the PV
field for YU, but to add comments (not in LTRU process) to the CS and YU
records.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Peter<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
ietf-languages-bounces@alvestrand.no
[mailto:ietf-languages-bounces@alvestrand.no] <b>On Behalf Of </b>Mark Davis<br>
<b>Sent:</b> Friday, February 27, 2009 1:12 PM<br>
<b>To:</b> Tex Texin<br>
<b>Cc:</b> ietf-languages@iana.org; Doug Ewell<br>
<b>Subject:</b> Re: Proposal to remove Preferred-Value field for region YU in
LTRU<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>Ah, I am now finally
understanding what you are concerned about. The main problem is that the
Preferred value really should be a set, in the case of regions. Then we would
have<br>
<br>
Before:<br>
YU -> CS<br>
<br>
After<br>
YU -> {RS ME}<br>
CS -> {RS ME}<br>
<br>
and the connection is maintained. But we -- unfortunately -- don't have that
ability, and I'm not suggesting addition at this late date (although perhaps
for a future version - in CLDR we maintain that information because it is
important for implemenations)!<br>
<br>
So removing CS breaks the equivalence class relation between YU and CS.<br>
<br>
I'm starting to change my mind about the wisdom of removing the Preferred
value. After all the purpose is for canonicalization, and xx-YU and xx-CS
should have the same canonical form. We lose that if we drop the value.<br>
<br clear=all>
Mark<o:p></o:p></p>
<div>
<p class=MsoNormal>On Fri, Feb 27, 2009 at 12:55, Tex Texin <<a
href="mailto:textexin@xencraft.com">textexin@xencraft.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>1) I used YU/CS as a shorthand for identifying a subtag that
could be either.<br>
2) I understand the inaccuracy between YU and CS. That was not offered as the
reason for the change however, at least in the mails I saw. Perhaps it was an
implicit motive.<br>
<br>
3) I understand that there isn't a requirement to change tags. I'll make the
case another way-<br>
At some point in time a user attempts to find documents tagged for Yugoslavia.<br>
The search engine, using the then current registry data noting the preferred
value relationship, matches either YU and CS.<br>
<br>
Another user searches for documents for Serbia.<br>
The search engine, using the then current registry data noting the preferred
value relationship, matches either YU and CS.<br>
<br>
The results are in some sense accurate and complete given the history of the
subtag.<br>
<br>
After the change in the preferred value relationship, the search engine does
not search for both, since the registry does not indicate a relationship. Only
one or the other subtag is used for each query. However, the query results are
now incomplete since documents for YU may have been tagged with the one-time
preferred tag of CS.<br>
<br>
4) Comments are a good thing for recording rationale and tangential history.
However, implementers are not going to go thru and read the comments on any or
all tags in order to make a correct implementation. They are going to implement
based on the schema and operate with the data values.<br>
<br>
5) I think the registry should stay as it is with respect to YU and CS.<br>
As CS is now being used, deprecated or not, I don't see a compelling motivation
to change the value back to YU. Doing so would just compound the confusion over
the two subtags.<br>
<br>
6) I don't expect users to be walking the registry in any event but to use a
software package that recommends the optimal value. If that software executes a
few extra machine cycles to get to CS, so be it. (And that is only if the
results aren't put into a precompiled form.)<br>
<br>
7) I would not argue that preferred value relationships should never change.
But the motivation to make a change should be compelling enough to outweigh the
impact of making ambiguous the existing tagged data.<br>
<br>
8) Separate topic- The number of countries in the world seems to grow. This
suggests to me that regions being subdivided is not going to be a rare event.
Perhaps there should be a mechanism to indicate subtags that have later been
split, so instead of one preferred value, there is a way to indicate that a tag
has been deprecated in favor of two or more possible values.<br>
<span style='color:#888888'><br>
tex</span><o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:ietf-languages-bounces@alvestrand.no">ietf-languages-bounces@alvestrand.no</a>
[mailto:<a href="mailto:ietf-languages-bounces@alvestrand.no">ietf-languages-bounces@alvestrand.no</a>]
On Behalf Of Doug Ewell<br>
Sent: Friday, February 27, 2009 5:21 AM<br>
To: <a href="mailto:ietf-languages@iana.org">ietf-languages@iana.org</a><br>
Subject: Re: Proposal to remove Preferred-Value field for region YU in LTRU<o:p></o:p></p>
</div>
<div>
<div>
<p class=MsoNormal>Tex Texin <textexin at xencraft dot com> wrote:<br>
<br>
> Historically, it was a concern that codes might change.<br>
> If I use the registry to choose the preferred value for a region, and<br>
> that preferred value can change, then isn't it tantamount to the code<br>
> changing?<br>
<br>
This would have been a good question for the LTRU group back when the<br>
decision was made to allow Preferred-Value to change. I'm guessing this<br>
was about a year ago, but I would have to look it up.<br>
<br>
> If I had data that would be represented by YU/CS and after the<br>
> preferred value is removed it should instead be YU, that seems like a<br>
> problem.<br>
<br>
I guess I'm not sure what you mean by "YU/CS" in this context.
A<br>
language tag contains at most one region subtag, of course.<br>
<br>
> Especially since the relationship between CS and YU becomes lost.<br>
<br>
Speaking to this particular case and not to the general principle of<br>
allowing P-V to change...<br>
<br>
It has been argued frequently on LTRU that the relationship between CS<br>
and YU is not what it appears, because the country identified as YU<br>
changed its nature dramatically between 1991 and 2003, in a way that was<br>
pertinent to language identification, by shrinking from the original<br>
"Yugoslavia" to just Serbia and Montenegro. This viewpoint
holds that<br>
data tagged as "something-YU" is already ambiguous as to "which
YU" is<br>
intended. This is really just a special case of the problem that<br>
country codes as language modifiers are less than perfectly precise.<br>
<br>
> Also, it may not be clear which CS records should be restored to YU.<br>
<br>
There is never any presumption that someone will go through and retag<br>
data. Section 3.1 says, "In particular, the 'Preferred-Value' field<br>
does not imply retagging content that uses the affected subtag." To
me<br>
this implies that a change or deletion of P-V doesn't imply retagging<br>
either.<br>
<br>
> I don't see that the fact that the target preferred value of YU is<br>
> also deprecated is a good reason to break the relationship at this<br>
> point. We still end up with deprecated codes with no preferred value<br>
> to go to, so why introduce an unnecessary change?<br>
<br>
So that users will not have to follow a chain of arbitrary length to<br>
determine the best subtag -- or in this case, to reach a dead end.<br>
<br>
--<br>
Doug Ewell * Thornton, Colorado, USA * RFC 4645 *
UTN #14<br>
<a href="http://www.ewellic.org" target="_blank">http://www.ewellic.org</a><br>
<a href="http://www1.ietf.org/html.charters/ltru-charter.html" target="_blank">http://www1.ietf.org/html.charters/ltru-charter.html</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages"
target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a>
ˆ<br>
<br>
_______________________________________________<br>
Ietf-languages mailing list<br>
<a href="mailto:Ietf-languages@alvestrand.no">Ietf-languages@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages"
target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br>
<br>
_______________________________________________<br>
Ietf-languages mailing list<br>
<a href="mailto:Ietf-languages@alvestrand.no">Ietf-languages@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages"
target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><o:p></o:p></p>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>