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