Re: Re: modification of Prefix fields

Re: modification of Prefix fields

Mark Davis wrote:

> Prefix: zh-Hant
> Prefix: zh-Hans
> can be replaced by
> Prefix: zh
> Prefix: ru
> This is because addition of zh makes zh-Hant and zh-Hans redundant,
> so they can be removed, and the addition of "ru" only broadens.

For 4646bis we might better stay away from zh-tags in examples (?)
Otherwise your wording is a bit clearer, matter of taste, probably.

In your version s/because addition/because the addition/
In Addison's version s/a prefix a prefix/a prefix/ (?)

Frank

Re: Re: Archival of registration forms

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> <t>Sometimes the requested record needs to be modified as a result of 
> discussion during the review period or due to requirements in this 
> document. The applicant, Language Subtag Reviewer, or others are free 
> to submit a modified version of the request, which will be considered 
> in lieu of the original request with the explicit approval of the 
> applicant. Such changes do not restart the two-week discussion period, 
> although an application containing the final record submitted to IANA 
> MUST appear on the list at least one week prior to the Language Subtag 
> Reviewer forwarding the record to IANA. The applicant is also free to 
> modify a rejected application with additional information and submit 
> it again; this starts a new two-week comment period.</t>

At least one week?  That will have the effect of indirectly restarting 
the review period: every comment that comes in N days before the end of 
the review period (for N < 7) that results in a change to the original 
request will cause the review period to be extended by another (7 - N) 
days.

If that is what the ietf-languages group wants, I won't argue the point, 
but I see a lot more complaints about the group's slow pace and 
indecisiveness than about registering things it shouldn't.

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

Re: Re: Archival of registration forms

At 13:53 07/05/01, Doug Ewell wrote:
>Addison Phillips <addison at yahoo dash inc dot com> wrote:

>At least one week?  That will have the effect of indirectly restarting the review period: every comment
that comes in N days before the end of the review period (for N < 7) that results in a change to the original
request will cause the review period to be extended by another (7 - N) days.

Yes, that's the intention. The issue is that if something new comes
up, even if it looks like everybody agrees on the spot, it's better
to give it a bit of time.

>If that is what the ietf-languages group wants, I won't argue the point, but I see a lot more complaints
about the group's slow pace and indecisiveness than about registering things it shouldn't.

My understanding is that indecisiveness doesn't happen because
there are ongoing little tweaks that don't converge, but mainly
because a) there are strongly opposing opinions, or b) because
peolple don't care too much either way, or c) because nobody has
enough time.

One other way to address issues is to at some point just say
"the one we had already one week ago is good enough, if you want
to change it again, please submit another request". Of course,
that only works for changeable fields.

Anyway, that's the intention behind what Addison wrote (or my
interpretation of it), but I'm not totally attached to it.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst <at> it.aoyama.ac.jp     

Re: Re: Archival of registration forms

Doug Ewell wrote:
> 
>> <t>Sometimes the requested record needs to be modified as a result of 
>> discussion during the review period or due to requirements in this 
>> document. The applicant, Language Subtag Reviewer, or others are free 
>> to submit a modified version of the request, which will be considered 
>> in lieu of the original request with the explicit approval of the 
>> applicant. Such changes do not restart the two-week discussion period, 
>> although an application containing the final record submitted to IANA 
>> MUST appear on the list at least one week prior to the Language Subtag 
>> Reviewer forwarding the record to IANA. The applicant is also free to 
>> modify a rejected application with additional information and submit 
>> it again; this starts a new two-week comment period.</t>
> 
> At least one week?  That will have the effect of indirectly restarting 
> the review period: every comment that comes in N days before the end of 
> the review period (for N < 7) that results in a change to the original 
> request will cause the review period to be extended by another (7 - N) 
> days.

I had to pick a time period. A time period of less than 48 hours doesn't 
permit people time to respond (especially if the 48 hours fall on a 
weekend or national holiday). So I chose a week as a convenient time period.

I note that this does not restart the time period for review and 
approval. The LSR can approve the record at any time (provided two-weeks 
have elapsed), but he cannot forward the record until the 7 days have 
elapsed for the final record.

And note that it is only the FINAL record that matters for the one week 
measure. The applicant is free to send a new record every day for the 
first week of the review period without causing any change in the 
registration schedule at all.

> 
> If that is what the ietf-languages group wants, I won't argue the point, 
> but I see a lot more complaints about the group's slow pace and 
> indecisiveness than about registering things it shouldn't.

The ietf-languages list is rather too efficient at registering subtags, 
in my opinion. The slow pace, indecisiveness, lack of discipline, and 
general opacity of the process is an artifact, in my opinion, of how the 
list and process are managed. Nonetheless, we have to hand quite a list 
of examples of "register quickly" (under a month) followed by "repent 
forever".

Addison

--

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

Re: Re: modification of Prefix fields

Mark Davis wrote:
>  I'd suggest slightly different wording, since saying that it cannot be 
> removed but can be modified is a bit odd. So I'd suggest:

The modifications are limited, though.

> 
> The collection of fields of type 'Prefix' MUST NOT be changed in a way 
> that narrows the meaning of the subtag. If there is no Prefix, then one 
> cannot be added. 

This sentence bothers me. I know you're trying to prevent true generic 
variants from becoming language specific, but the wording, I think, 
would be confusing.

> If there (is) a Prefix, then others can be added. A Prefix 
> can be removed only if it is redundant: there is another Prefix that 
> covers all of the cases that it does. For example:
>   Prefix: zh-Hant
>   Prefix: zh-Hans
> can be replaced by
>   Prefix: zh
>   Prefix: ru
> This is because addition of zh makes zh-Hant and zh-Hans redundant, so 
> they can be removed, and the addition of "ru" only broadens.
> 

I'll work on incorporating this into draft-06 when I get a chance later 
today.

Addison

--

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

I-D ACTION:draft-ietf-ltru-4646bis-05.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		: Tags for Identifying Languages
	Author(s)	: A. Phillips, M. Davis
	Filename	: draft-ietf-ltru-4646bis-05.txt
	Pages		: 68
	Date		: 2007-5-1
	
This document describes the structure, content, construction, and
   semantics of language tags for use in cases where it is desirable to
   indicate the language used in an information object.  It also
   describes how to register values for use in language tags and the
   creation of user-defined extensions for private interchange.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-05.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-4646bis-05.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-4646bis-05.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.

Re: Re: Archival of registration forms

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> The ietf-languages list is rather too efficient at registering 
> subtags, in my opinion. The slow pace, indecisiveness, lack of 
> discipline, and general opacity of the process is an artifact, in my 
> opinion, of how the list and process are managed. Nonetheless, we have 
> to hand quite a list of examples of "register quickly" (under a month) 
> followed by "repent forever".

How many "repent forever" subtags would you say we currently have?

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

RE: Re: Transliteration of reference titles

From: Mark Davis [mailto:mark.davis <at> icu-project.org]

> BTW, I'm not pushing strongly for this, since the current
> situation is workable, though not not optimal. One example
> of why it is not optimal is that Yahoo, Google, etc. don't
> think that the language subtag registry contains words
> like Bokmål. Try a Google or Yahoo search for
>
>  iana language-subtag-registry Bokmål

Interesting -- no hit on the LSTR. Try it in Live Search: LSTR is the very first hit.

Peter

RE: draft-05 changes, etc.

From: Addison Phillips [mailto:addison <at> yahoo-inc.com]

> I just submitted draft-05...

There's a word missing in rule 4 of section 4.1:

Change

   4.  [ISO639-2] has defined several codes included in the subtag
       registry that require additional care when choosing language
       tags.  In most of these cases, where omitting the language tag is
       permitted, such omission preferable to using these codes.

to

   4.  [ISO639-2] has defined several codes included in the subtag
       registry that require additional care when choosing language
       tags.  In most of these cases, where omitting the language tag is
       permitted, such omission is preferable to using these codes.
                                ^^

Peter