[Ltru] Process Enhancement

[Addison Phillips]

-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:mark.davis at icu-project.org]
> Sent: 2006年3月20日 9:49
> To: ietf-languages at iana.org
> Cc: iana at iana.org; ltru at ietf.org
> Subject: [Ltru] Process Enhancement
> 
> 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
> ietf-languages at iana.org 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
> Ltru at ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru