Doug Ewell | 2 Feb 05:58

Re: Principles of Operation

Kent Karlsson <kent dot karlsson14 at comhem dot se> replied to John 
Cowan, who already answered these questions but did not cite chapter and 
verse:

>> If ISO 639 decides to merge two languages, we aren't going to follow; 
>> we'll just add the new merged code, and keep the two codes they 
>> retire.
>
> They surely must be kept (if they ever got in to begin with), but I do 
> hope that, by 639-3 RA, codes that become "retired" are 
> "automatically" deprecated in LSR. I'm not sure if any new text in 
> 4646bis is needed to say that more explicitly.

Draft-4646bis-11, section 3.4, item 13 covers this.  I have to admit 
John's response surprised me at first reading: saying we "keep" them 
didn't shout "deprecation" to me.

> If a 639-3 code is "retired" already before 4645bis is submitted in 
> final form, it should not be part of 4645bis. I understand that 
> current drafts are constructed without already retired "new" codes.

Draft-4645bis-03, section 2.1 covers this: the retired code elements are 
not considered to be "in" 639-3.  I probably need to make that clearer.

I hope the default action for all LTRU participants, when questions like 
this come up, will be to check the drafts first.  All basic questions of 
this sort should be in one draft or the other, and if they are not, we 
need to add them.  If we're not reading through the drafts pretty 
thoroughly by now, we aren't even going to make the co-chairs' new, 
improved milestone of March for IETF Last Call (which BTW is still not 
(Continue reading)

Doug Ewell | 2 Feb 06:56

Proposed wording for 639-3 items already retired

I wrote:

> Draft-4645bis-03, section 2.1 covers this: the retired code elements 
> are not considered to be "in" 639-3.  I probably need to make that 
> clearer.

Proposed wording for Section 2.1 of draft-4645bis, immediately following 
the three bullet points:

"Language code elements that were already retired in [ISO639-3] prior to 
IESG approval of this memo were not listed in these files, and 
consequently were not considered in this update."

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
http://www.ietf.org/mailman/listinfo/ltru
Mark Davis | 2 Feb 20:48
Favicon

Re: Proposed wording for 639-3 items already retired

+1

On Feb 1, 2008 9:56 PM, Doug Ewell <dewell <at> roadrunner.com> wrote:
I wrote:

> Draft-4645bis-03, section 2.1 covers this: the retired code elements
> are not considered to be "in" 639-3.  I probably need to make that
> clearer.

Proposed wording for Section 2.1 of draft-4645bis, immediately following
the three bullet points:

"Language code elements that were already retired in [ISO639-3] prior to
IESG approval of this memo were not listed in these files, and
consequently were not considered in this update."

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
http://www.ietf.org/mailman/listinfo/ltru



--
Mark
Randy Presuhn | 6 Feb 19:14
Picon

ltru mailing list test

Hi -

test, please ignore

Randy, as list admin

Internet-Drafts | 8 Feb 21:15
Picon
Favicon

I-D ACTION:draft-ietf-ltru-4645bis-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Language Tag Registry Update Working Group of the IETF.

	Title		: Update to the Language Subtag Registry
	Author(s)	: D. Ewell
	Filename	: draft-ietf-ltru-4645bis-04.txt
	Pages		: 904
	Date		: 2008-2-8
	
This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the
publication of RFC 4646bis [RFC EDITOR NOTE: replace with actual RFC number], for use in forming tags for
identifying languages.  As an Internet-Draft, it also contained a complete replacement of the contents
of the Registry to be used by IANA in updating it.  To prevent confusion, this material was removed before publication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ltru-4645bis-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ltru-4645bis-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 135 bytes
Attachment (draft-ietf-ltru-4645bis-04.txt): message/external-body, 68 bytes
Randy Presuhn | 9 Feb 01:40
Picon

Begin LTRU WG last call on 4646bis and 4645bis

Hi -

After consulting with our document editors, my co-chair, and our
Area Director, as ltru co-chair I'm pleased to announce the start
of working group last call on two documents:
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-04.txt

This will be a two-week WG last call, ending on February 22.
In order to maintain some semblance of sanity PLEASE:
   1) group your *purely* editorial comments into a single message
   2) technical comments should be posted with *ONE* issue per message
   3) the subject line should identify the document (e.g. 4646bis)
   4) the subject line should uniquely identify the issue
   5) if there is an issue which you believe has not been satisfactorily
      resolved, or needs to be reconsidered in light of experience,
      NOW is the time to speak up!
   6) comments of the form "I've read this document and have no problems
      with it" are also helpful.
   7) in discussing comments, if a new issue arises, USE A NEW SUBJECT
      LINE

Please post your comments to to ltru <at> ietf.org

February 25 is the i-d cutoff.  We hope to be able to issue updated
drafts reflecting the working group last call comments before then.
Depending on the nature of the comments and the edits, at that time
we will either issue a second last call, to end March 17 (extended
due to the IETF meeting in Philadelphia), or hand the documents to
our ADs.

Randy
ltru co-chair

Addison Phillips | 9 Feb 02:10
Picon
Favicon

Re: Begin LTRU WG last call on 4646bis and 4645bis

 > After consulting with our document editors,

I don't recall seeing a note from you recently, but I'll go back and 
look for it. Shouldn't I submit draft-12, with its one or two edits first?

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

Randy Presuhn wrote:
> Hi -
> 
> After consulting with our document editors, my co-chair, and our
> Area Director, as ltru co-chair I'm pleased to announce the start
> of working group last call on two documents:
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-11.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-04.txt
> 
> This will be a two-week WG last call, ending on February 22.
> In order to maintain some semblance of sanity PLEASE:
>    1) group your *purely* editorial comments into a single message
>    2) technical comments should be posted with *ONE* issue per message
>    3) the subject line should identify the document (e.g. 4646bis)
>    4) the subject line should uniquely identify the issue
>    5) if there is an issue which you believe has not been satisfactorily
>       resolved, or needs to be reconsidered in light of experience,
>       NOW is the time to speak up!
>    6) comments of the form "I've read this document and have no problems
>       with it" are also helpful.
>    7) in discussing comments, if a new issue arises, USE A NEW SUBJECT
>       LINE
> 
> Please post your comments to to ltru <at> ietf.org
> 
> February 25 is the i-d cutoff.  We hope to be able to issue updated
> drafts reflecting the working group last call comments before then.
> Depending on the nature of the comments and the edits, at that time
> we will either issue a second last call, to end March 17 (extended
> due to the IETF meeting in Philadelphia), or hand the documents to
> our ADs.
> 
> Randy
> ltru co-chair
> 
> _______________________________________________
> Ltru mailing list
> Ltru <at> ietf.org
> http://www.ietf.org/mailman/listinfo/ltru

Randy Presuhn | 9 Feb 02:35
Picon

Re: Begin LTRU WG last call on 4646bis and 4645bis

Hi -

> From: "Addison Phillips" <addison <at> yahoo-inc.com>
> To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>
> Cc: "LTRU Working Group" <ltru <at> ietf.org>
> Sent: Friday, February 08, 2008 5:10 PM
> Subject: Re: [Ltru] Begin LTRU WG last call on 4646bis and 4645bis
>
> > After consulting with our document editors,
> 
> I don't recall seeing a note from you recently, but I'll go back and 
> look for it.

A short while ago I received a NDN for you.  Sorry, I assumed you'd
seen our conversation.

> Shouldn't I submit draft-12, with its one or two edits first?

No.  If it's just one or two (or even a small handful of) edits,
let's treat them individually as WGLC comments.

Randy

Doug Ewell | 9 Feb 04:25

Re: Begin LTRU WG last call on 4646bis and 4645bis

Randy wrote:

> After consulting with our document editors, my co-chair, and our
> Area Director, as ltru co-chair I'm pleased to announce the start
> of working group last call on two documents:
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-11.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-04.txt
>
> This will be a two-week WG last call, ending on February 22.

I think the ietf-languages list should be copied on this as well.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ 

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
http://www.ietf.org/mailman/listinfo/ltru
Doug Ewell | 10 Feb 07:39

WGLC: remove new region subtags from 4646bis/4645bis (long)

This is a technical comment on both draft-4646bis and, by implication, 
draft-4645bis.

Summary:
I propose that the new region subtags based on ISO 3166-1 "exceptionally 
reserved" code elements, and the wording that authorizes them, be 
removed from both drafts.

Discussion:
This topic was discussed at significant length during November 2007. 
Most of what I am writing here is a summary of what has gone before, 
repackaged for Last Call.  An earlier argument, which itself contains 
links to still earlier arguments, is at 
http://www.ietf.org/mail-archive/web/ltru/current/msg08851.html .

Historically, RFC 4646 and its predecessors (including common practice 
in the days before RFC 1766) limited two-letter region subtags to those 
corresponding to code elements formally assigned in ISO 3166-1.  The 
primary reason for adding the exceptionally reserved ("ER") code 
elements was apparently to allow 'EU' to be used with the meaning 
"European Union," not for language tagging per se, but in CLDR and other 
works that are not related to language tagging.  The other ER code 
elements, such as 'DG' for "Diego Garcia" and 'EA' for "Ceuta [and] 
Melilla," were ancillary to this objective; they were added in 
preference to cherry-picking 'EU' out of the list of ER codes (a 
preference I certainly shared).

In justifying this change, Mark Davis wrote, "BCP 47 is not only the 
source of language tags; it is *the* reference for stabilized, 
maintainable codes for languages, scripts, and regions."  While I 
appreciate the desire to have a work such as CLDR derive its code list 
from a stable reference, this does not require the BCP 47 code list to 
include all entities that might be useful to a derivative work. 
Instead, CLDR could be defined as a profile of BCP 47, and add code 
elements beyond those provided in BCP 47 as necessary for its own needs.

There are other region subtags already in the Language Subtag Registry 
that are known, or highly suspected, not to be useful for identification 
of language variations.  Some of the better-known examples are 'AQ' for 
"Antarctica" and 'BV' for "Bouvet Island."  However, those subtags were 
included in the Registry in strict accordance with the philosophy of 
incorporating all of the *formally assigned* ISO 3166-1 code elements, 
without cherry-picking them for perceived relevance.

For RFC 4646, the LTRU WG added the UN M.49 numeric code elements 
corresponding to supra-national regions, to provide additional region 
subtags for demonstrated language tagging needs.  The poster child for 
this particular need was '419' for "Latin American and the Caribbean," 
useful for Spanish as used in certain Spanish-speaking areas of the New 
World but not in Spain.

But the WG explicitly excluded UN codes categorized under "Selected 
economic and other groupings," because those codes represent groups of 
geographically and linguistically unrelated nations and have no 
pertinence to language tagging.  An example is '432' for "Landlocked 
developing countries," a grouping that includes Bolivia, Chad, Laos, and 
Moldova.  The WG correctly decided to consider *relevance to language 
tagging* in deciding which categories of UN code to include and which to 
exclude.

Making an explicit change to RFC 4646bis to add the ISO 3166-1 ER code 
elements presents the impression that they must fulfill a particular 
language tagging need, just as the act of adding the UN codes fulfilled 
such a need.  However, no such need has been demonstrated *for language 
tagging*, only for locale designation and ease of cross-checking between 
standards.  John Cowan mentioned that "English as spoken on Tristan da 
Cunha" is a recognized variety of English, but there is no actual 
evidence of a need to tag this variety.

Claims of a requirement to tag "European Union English" as distinct from 
"English as spoken in {Northern, Southern, Western, Eastern} Europe" 
(all of which could be implemented with numeric UN-based region subtags) 
have been based on the notion of an EU "bureaucratese" which has not 
been shown to exist, at least not in any way beyond ordinary 
bureaucratese, and which in any case would not be truly region-based and 
thus not appropriate for a region subtag.  A variant subtag is the 
normal mechanism for tagging specialized jargon.

In short, to make a change like this in BCP 47, there should be a good 
reason why the change is necessary and the status quo is inadequate for 
language tagging.  No good reason has been demonstrated IMHO, although 
several reasons ranging from marginal to bogus have appeared.

None of my objection to these subtags has anything to do with the 
additional overhead of adding seven new region subtags to the RFC 
4645bis Registry, which already contains 289 region subtags and 8,304 
tags and subtags overall.  Also, none of my objection constitutes a 
judgment of the political or institutional legitimacy of the European 
Union; this is not the purpose of the Registry or of the LTRU effort.

My specific proposal is that all wording in draft-4646bis and 
draft-4645bis related to the addition of these region subtags be 
removed, including the actual subtags in the 4645bis Registry.  I can 
itemize the specific passages to be changed if desired.

I do not intend to oppose the drafts or file an appeal if this comment 
is rejected, but I do ask that the comment be duly considered by the WG 
and ruled upon by the co-chairs.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
Editor, draft-ietf-ltru-4645bis
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ 

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
http://www.ietf.org/mailman/listinfo/ltru

Gmane