Reminder: ISO 639-3 changes are coming

Doug Ewell doug at ewellic.org
Sat Nov 14 05:47:39 CET 2009


"Phillips, Addison" <addison at amazon dot com> wrote:

> I agree with your reading of RFC 5646, but note that it does not 
> require this exercise to be done in the least efficient manner 
> imaginable :-).

I think you and Michael are probably right that Michael can send IANA a 
single zip file containing N new or changed records plus N registration 
forms (where N is somewhere in the 100 to 140 range).  Of course we will 
need to check with IANA on this, but I suspect they would also prefer to 
receive one mail with a big attachment instead of 2N separate mails.

However, those records and forms will still have to be posted to this 
list for 2 weeks, which will result in a lot of list traffic, and 
probably more than a few complaints that our rules are too cumbersome 
and rigid.  But many of us are the ones who spent years in LTRU writing 
the rules, and we have an obligation to follow them.

> Certainly each proposed change/addition must have its own proposed 
> record and registration form (note that the form contains the record, 
> so these are effectively the same thing).

Not exactly; the records have to have File-Date and Added fields, not 
present in the reg form.

> It does not say anywhere that the changes must be individually 
> submitted to ietf-languages@ nor that they must all be considered 
> separately. I would suggest that they be batched by the reviewer based 
> upon his evaluation (e.g. separate the additions from the 
> modifications and the records requiring additional scrutiny if such 
> exist from the routine). I would expect most of them to be routine, 
> assuming the proposed records were assembled according to the rules. 
> This will be significant work for you, I dare say, since the 
> Description fields have some requirements that are more difficult to 
> verify.

Good sugggestions.  When I post these, I will try to draw a clear 
distinction between the additions and the modifications.  There may be 
some that go together in complex ways -- for example, there are 
proposals to convert existing individual language code elements into 
macrolanguages -- so I'll try to organize those in a meaningful way too.

Most of these should require about the same amount of scrutiny, 
primarily to make sure I haven't made some type of clerical error in 
adapting 100+ ISO actions to the Registry.  One major exception would be 
if any of the additions or changes resulted in a name collision (Section 
3.1.5), and I'll certainly try to detect those and warn the list.  None 
of the changes should be considered so routine that it's not worth 
verifying them, however.

Yeah, this will be a lot of work for me, but it's worth it to continue 
to have a good standard with a reliable, internally consistent data 
source.  I wish all such standards were maintained by people who paid 
such attention to detail.  (Yeah, I'm talking to you, UNECE 
Secretariat.)

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s ­



More information about the Ietf-languages mailing list