Ambiguity (Announcing draft-langtags-phillips-davis-00.txt)

[Addison Phillips [wM]]

All,

Mark Davis and I have submitted a new Internet-Draft intended as the
framework for that "update" that has been mentioned on this list for some
months now. We had hoped to announce this on this list shortly, except that
we have just finished preparing a revision (which will be submitted in the
more readable PDF format). That revision I think addresses a number of the
immediately obvious issues, including "6a". We were waiting for that to post
before announcing it.

Mark and I look forward to the feedback and (no doubt vigorous) debate about
this proposal in the coming week. Look for version -01 on the IETF website
in a few days. (Of course you can look at -00 now).

Misha, with regard to your question, the version -01's draft currently
reads:

7. To maintain backwards compatibility, there are two
provisions to account for instabilities in ISO 639,
3166, and 15924 codes.

   a. Ambiguity. In the event that one of these
      standards reassigns a code that was previously
      assigned a different meaning, the new use of
      the code will not be permitted and the IANA
      registry, as soon as practical, will register
      a variant subtag as a surrogate value for the
      new code, based on the year that the new code
      assignment was made.

    For example:
      cs-CS (Czech for Czechoslovakia)
      sr-CS2003 (Serbian for Serbia and Montenegro,
                 using a registered variant)

This example is because of the late unpleasantness regarding ISO3166
assigning the country code 'CS', formerly Czechoslovakia (a defunct country)
to what was formerly Yugoslavia (now officially called "Serbia and
Montenegro"). Since this happened this year, the 'surrogate' value would be
'CS2003'. The new draft makes it clear that this is a 'variant' subtag,
registered in the IANA registry.

The goal is that language tags in use somewhere do not change meaning even
if the Ur-standards on which language tags are based assign a code a
different value.

Hopefully this rule will be seldom or never used. Hope that clarifies.

Again, I appologize for this announcement leaking out and not coming
directly and Mark and I look forward to the comments that you may have.

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 Misha Wolf
> Sent: Friday, November 14, 2003 5:04 AM
> To: IETF Languages
> Subject: Ambiguity
>
>
> A question re:
>    http://xml.coverpages.org/draft-langtags-phillips-davis-00.txt
>
> In section 6a, Ambiguity, I don't understand the derivation of
> "sr-CS2003".
>
> --
> Misha Wolf
> Standards Manager
> Content Architecture and Capabilities Group
> Reuters, 85 Fleet Street, London EC4P 4AJ
>
> Telephone          +44 20 7542 6722
> Mobile             +44 7990 56 6722
> Email              misha.wolf at reuters.com
> Reuters Messaging  misha.wolf.reuters.com at reuters.net
>
>
>
>
> -------------------------------------------------------------- --
>         Visit our Internet site at http://www.reuters.com
>
> Get closer to the financial markets with Reuters Messaging - for more
> information and to register, visit http://www.reuters.com/messaging
>
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages