(iso639.1574) New ISO 639 language identifier - Klingon

[Addison Phillips [wM]]

> Also, "put your money where your mouth is" is a popular IETF game - if
it's
> simple to generate those data files, someone who's interested could hack
up
> the scripts to do it, provide a "contribution" site that has the files,
and
> donate the scripts to IANA if they're willing to run them.

My implementation of rfc3066 (and rfc3066bis) includes code that does that.
I'll happily split that out and donate it. It might take a couple of weeks
(since I'm busy getting ready to go off to Cannes for the W3C TP).

> publish "derived" files to make it easy to correctly verify what tags in
> fact exist and are supposed to be used than a whole-tag registry
> has. Does 3066bis discuss the functioning of the registry at all?

It does discuss the functioning of the registry, but mostly on a par with
what rfc3066 said. More text can be added to deal with this, of course.

The problem here is that the source materials for the various ISO standards
are not always readily available. Rfc3066 puts the burden on implementations
to figure it out. A larger, more formal registry might need to include
authoritative sources for ISO639-x, ISO3166, and ISO15924, since this is the
Ur-data for generating any additional fallback tables.

Note that rfc3066bis includes slightly more text than rfc3066 does related
to obsoleting of codes. See rule 7a (Ambiguity) in section 2.3 (the HTML is
here when my DSL is working:
http://www.inter-locale.com/ID/draft-phillips-langtags-01.html#choice)

Best Regards,

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Harald Tveit
> Alvestrand
> Sent: mercredi 25 février 2004 07:41
> To: Peter Constable; IETF-languages list
> Subject: RE: (iso639.1574) New ISO 639 language identifier - Klingon
>
>
>
>
> --On 24. februar 2004 08:54 -0800 Peter Constable
> <petercon at microsoft.com>
> wrote:
>
> >> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> >> bounces at alvestrand.no] On Behalf Of Addison Phillips [wM]
> >
> >> According to the rules in place in RFC3066 (not bis), as I understand
> > them,
> >> the tag 'i-klingon' will never be *deleted*, only deprected with a
> > reference
> >> to 'tlh'.
> >
> > I think what Mike was suggesting was that the RFC say something explicit
> > about how alisasing in such cases is dealt with. It currently is silent
> > on this, so while I could look in the registration file for i-lux
> > (http://www.iana.org/assignments/lang-tags/i-lux) and find that it "has
> > been deprecated by ISO 639 lb", there's nothing in the RFC to tell me
> > that that will always be done, or that it will always be done the same
> > way.
>
> RFC 3066 does say that a generating application MUST use the ISO code:
>
>    4. When a language has both an IANA-registered tag (i-something) and
>       a tag derived from an ISO registered code, you MUST use the ISO
>       tag.  NOTE: When such a situation is discovered, the IANA-
>       registered tag SHOULD be deprecated as soon as possible.
>
> At the time this was written, we didn't have Håvard to feed us the new
> registrations in real time, so I imagined that we could find out
> about new
> ISO codes months or years after its registration....
>
> > And more could be done to make life easier for application developers,
> > or even to allow for more intelligent apps. For instance, the IANA
> > lang-tags folder could contain a tab- or comma-delimited file alias.txt
> > containing alias mappings; e.g.
> >
> > ;deprecated,best_practice
> > i-lux,lb
> > i-navajo,nv
> > no-bok,nb
> > no-nyn,nn
> >
> > etc.
>
> That seems like a not unreasonable thing to do, even though giving a
> machine-parseable list of all registered tags would be higher on
> my list .-)
>
> I haven't gotten around to critiquing the latest version of 3066bis yet,
> but it seems to me that a subtag registry could have a much
> greater need to
> publish "derived" files to make it easy to correctly verify what tags in
> fact exist and are supposed to be used than a whole-tag registry
> has. Does
> 3066bis discuss the functioning of the registry at all?
>
> Also, "put your money where your mouth is" is a popular IETF game
> - if it's
> simple to generate those data files, someone who's interested
> could hack up
> the scripts to do it, provide a "contribution" site that has the
> files, and
> donate the scripts to IANA if they're willing to run them.
>
> > The fact is that aliases can and do exist. The question is whether we
> > are doing all that we could to deal with that reality.
>
> The answer is definitely "no". The more relevant question is what the
> optimum use of resources is...... IANA's currently extricating
> itself from
> a situation that allowed a multi-month registration backlog to
> build up in
> the IETF registries... NOT the right time to ask for creativity......
>
>                  Harald
>
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages