Subject: [Ltru] Process Enhancement

From: Mark Davis <[email-masked]>
Date: Mon, 20 Mar 2006 09:49:13 -0800

I suggest that we discuss with iana an enhancement of the process used 
for registration. I believe that this is consonant with the current 
rules, although it could be formalized in the 3066ter revision eventually.

Problem.
Once a code appears in the registry, we are committed to it. However, 
there are various points of possible failure; either the reviewer or the 
iana staff could make a mistake in transcription.

Proposal.
To help prevent that, I suggest the following:

1. All changes to the language subtag registry are first made in a trial 
version of the registry, located at 
http://www.iana.org/assignments/language-subtag-registry-beta.
2. Any time this beta file is changed, a notice is sent out to the 
[email-masked] list. This starts a 1 week review period for of 
those changes.
3. At the end of the period, if nobody on the list raises an objection, 
the reviewer notifies iana to release the beta: the contents are copied 
to http://www.iana.org/assignments/language-subtag-registry.
4. If an objection is raised, then an additional week will be allowed 
for discussion. At the end of that period, the reviewer will either 
request iana that
4a. the release is to proceed or
4b. the beta file is to be modified, which returns to Step 2.

(these are numbered for reference).

Mark

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Addison Phillips" <[email-masked]>
Date: Mon, 20 Mar 2006 14:28:43 -0800

-1

This proposed process strikes me as overkill. IANA has done a good job, as far as I can tell, historically. I think if we were going to change things it would be to make their job easier and simpler. This we could do as follows:

1. Provide the ability to fix clerical errors explicitly in 3066ter. I note that this is already provided for by allowing for changes to most fields via repeated registration and record replacement anyway, but explicitly calling it out would be good.

2. Changing from the LSR providing records to the LSR providing the updated file (this is much easier for IANA to validate and verify; the "subtag-registry-beta" mentioned below can be hosted on a mirror site such as evertype or inter-locale or alvestrand for easy access and incorporated into the existing review process without having a separate clock and separate approval to muck about with).

3. Ensuring that we provide IANA and LSR with formatting and validation tools (I've already offered the LSR such tools privately, since I have a record-jar processor and tools for creating and validating registration forms). A "langtag-nits" tool would help ensure prompt registrations. Right now IANA has to insert the fields and then check the file--a manual process. The proposed process adds several layers of complexity to what should be as simple as possible.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Mark Davis [mailto:[email-masked]]
> Sent: 2006年3月20日 9:49
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Ltru] Process Enhancement
>

---

From: Mark Davis <[email-masked]>
Date: Mon, 20 Mar 2006 14:50:33 -0800

I think our maintaining the beta file, and then sending the entire file 
to IANA would solve the main issue, AND probably speed up the 
registration process on the IANA side, since it is more work to find the 
place in the file where an entry should go, check that mistakes weren't 
introduced, etc. So if we did the work of maintaining the beta AND 
validating, that would both fix the process issues I am worried about 
and speed things up. So I'm in favor of Addison's revision.

Mark

---

From: Ned Freed <[email-masked]>
Date: Mon, 20 Mar 2006 16:18:54 -0800 (PST)

> and speed things up. So I'm in favor of Addison's revision.

The charsets registory continues to be a huge mess in no small part because
we tried using this approach. I still don't know why it was such a spectacular
failure, but that's where it ended up.

The running code we have therefore indicates this is not the good idea it
appears to be on first inspection.

				Ned