LANGUAGE SUBTAG REGISTRATION FORM (R3): pinyin

Phillips, Addison addison at amazon.com
Thu Sep 4 21:29:34 CEST 2008


… but only if there were not significant objection to approving that version, mm? I would probably have some objection if (let us suppose) Michael were to cherry-pick a specific registration request from the past that was not previously approved and approve it without discussion. I don’t have a problem with what you propose, since I view the pinyin/wadegile requests as single requests in which multiple form versions have been submitted.

This is increasingly off-topic here, but I want to make sure that the new rules for 4646bis do what is wanted. It sounds like they are about right.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

From: Peter Constable [mailto:petercon at microsoft.com]
Sent: Thursday, September 04, 2008 12:25 PM
To: Phillips, Addison; Michael Everson; ietflang IETF Languages Discussion
Subject: RE: LANGUAGE SUBTAG REGISTRATION FORM (R3): pinyin

Re “two-weeks per specific version of the form”, if there is a substantive, technical change introduced late in the discussion, then there should not be a quick decision to accept a request with that change: IMO, that is effectively a new proposal. If that change gets reverted, then IMO we’re effectively working on the original proposal, and the timing can be dated from when that request was originally submitted.

IOW, if Michael wanted to approve the Aug 2 requests with prefix “zh-Latn” today (with possible editorial changes), then I’d consider the review period complete and that that would not be a problem, IMO.


Peter

From: Phillips, Addison [mailto:addison at amazon.com]
Sent: Thursday, September 04, 2008 10:18 AM
To: Peter Constable; Michael Everson; ietflang IETF Languages Discussion
Subject: RE: LANGUAGE SUBTAG REGISTRATION FORM (R3): pinyin

RFC 4646 supports your timeline. I note that Michael did not explicitly extend the discussion period and he did explicitly approve one request, although that appears to have been retracted (explicit approval, rejection, or extension of the timeline is required by the RFC)

In any event, what I’m concerned with is that the current rules suggest that on 8 September Michael will reject the R3 form (assuming for a moment that we all decide that zh-Latn should be the prefix) and we’ll get Yet Another Two Week Review Period. I am also pointing out that if this is not the record that Mark wants, he should submit that record so that the debate and any LSR actions are appropriately focused. The sooner Mark submits the record he would like to have, the sooner the two weeks expire and Michael can approve/reject/extend.

In the past, we have not adhered to the two-weeks per specific version of the form when modifying the original request, on the theory that the request is still requesting the “same thing” (we’re just editing the form a bit to address comments). By that logic, Michael could approve R3 at any time (the same would apply to an R4 or whatever), since the original two weeks is long past and the revised form has been debated for awhile. Draft-4646bis was modified specifically to allow refreshes of the request to address comments without resetting the two-week clock. Once we are under the new document’s auspices, the timeline below would not apply: the final form requires a one-week appearance on the list before submission and modified requests do not reset the clock. I think that’s actually a good thing. Those rules changes were put into the draft to specifically address the inflexibility of the process in the past when it came to correcting non-material or ancillary changes to the form (to achieve rule compliance, etc.).

On a separate note, I’m trying to ascertain what Michael will approve and what is acceptable to Mark (and the community as well). I would happily support a prefix of ‘zh-Latn’, because that is sensible. I also support a prefix of ‘zh’ because some people will treat the registry prefix information as normative (improperly) and the possibility exists of tagging that uses the transcription subtags without a script. But I would be okay with only having a prefix of ‘zh-Latn’. It makes sense to have that prefix regardless of any other prefixes. But Michael can’t approve what we’re discussing now because it hasn’t been requested (or, more properly, it isn’t the *current* request).

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

From: Peter Constable [mailto:petercon at microsoft.com]
Sent: Thursday, September 04, 2008 9:18 AM
To: Phillips, Addison; Michael Everson; ietflang IETF Languages Discussion
Subject: RE: LANGUAGE SUBTAG REGISTRATION FORM (R3): pinyin

Well, on July 30 and then again on Aug 2, Mark submitted forms that had “zh-Latn”. On Aug 25 Mark submitted forms with “zh” and on Aug 26 Michael said “I approve”. It is not yet two weeks since the submission of forms with “zh” – the mandatory review period extends to Sept 8; so it would be premature for Michael to have already approved the requests submitted on Aug 25. If those are already being processed with IANA, then I think there are valid grounds for objection – and I would object.

Peter


From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Phillips, Addison
Sent: Thursday, September 04, 2008 7:59 AM
To: Michael Everson; ietflang IETF Languages Discussion
Subject: RE: LANGUAGE SUBTAG REGISTRATION FORM (R3): pinyin

I’m confused here.

On August 26th Michael approved both pinyin and wadegile as subtags. I specifically asked if this was formal approval and he replied that it was, in fact, formal approval.

I would assume that he approved the then current registration request, but I gather that the Prefix field subsequently caused him to reconsider. Mark later that day submitted the current “R3” form.

Michael, do you NOT approve of the R3 form—the one we are currently considering, which contains only the prefix ‘zh’? Would you approve of one that includes both Prefix fields? Mark, are you withdrawing the R3 request in favor of a zh-latn request? If so, you should do so now, because Michael can only (as I understand the rules) pronounce on a submitted request… and that is the request currently being considered.

I also note that one course of action is specifically prohibited: the prefix ‘zh’ cannot be *replaced* with the prefix ‘zh-latn’ (a narrowing). It can be supplemented with an additional prefix ‘zh-Latn’ (or ‘cmn-*’), but it can’t be replaced.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Michael Everson
Sent: Thursday, September 04, 2008 1:43 AM
To: ietflang IETF Languages Discussion
Subject: Re: LANGUAGE SUBTAG REGISTRATION FORM (R3): pinyin

On 4 Sep 2008, at 01:21, Peter Constable wrote:

As you say, he may reject something based on a single *compelling* opinion, and that may happen to be his own; but IMO he must use that veto ability very carefully so as to avoid conflict of interest: if indeed he alone voices an objecting opinion against several others on the list, it would need to be compelling indeed! The issue he raises in this case is, IMO, far from compelling.

The issue? Peter, please be clear when you write. Which issue? "The issue" I raised is that "pinyin" and "wadegile" are by default Latin because there are no other possiblities of interpretation. Is that "the issue" to which you refer? Because I don't believe you have demonstrated that what I have said is incorrect. Nor have you demonstrated how your position (that "Latn" must be included) is "compelling".

Michael Everson * http://www.evertype.com<http://www.evertype.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20080904/7c9fed2f/attachment-0001.htm 


More information about the Ietf-languages mailing list