Choice of language code for Serbian

Danilo Segan dsegan at
Sun Jan 11 23:43:11 CET 2004

Regards ietf-languages readers,

I don't know if this is the correct list, but this is where I was
directed at.

I'm living in Serbia and Montenegro, and Serbian is my native
language.  What bothers me is the proposed assignement of new 
language code for Serbian in Serbia and Montenegro (or actually, the
was draft is written, since there are only examples of concrete codes,
and they're not normative in the text).

As we all know, this is the point of ISO 3166-1 assignement of "CS"
to another country, and I won't go into that.  The following paragraph
made me curious about usage of "CS1" for examples, in the section on

    The form of the registered variant should be either an ISO3166-2
    alpha3 tag (if that does not itself have ambiguity problems) or be
    a 3-character tag that is not otherwise permitted by the ISO
    registration authority, such as one containing a sequence number
    (e.g. CS1).

This paragraph is all fine by me, because I would expect code "SCG" to
be used for "sr-SCG", and not another one made up based on "CS", as
underlined above.  Are there some ambiguity problems that I am not
aware of in case of "SCG"? ("CS1" is used in examples all over.)

As far as I read, SCG should be used unless there are some
ambiguities.  I've checked the archives of the list, but couldn't
find anything related to strict "CS1" choice (I found a couple
debates on CS assignment itself).

So please let me know of the rationale for choosing CS1 over SCG.

SCG doesn't have a chance of being misinterpreted, because it stands
clearly for "Srbija i Crna Gora" (Serbia and Montenegro), unlike CS
which supposedly stands for "Crna Gora i Srbija". It's clear, and
there's no chance of it changing (even if code in ISO 3166-1 gets
changed sometime) in the near future (unless Serbia and Montenegro
split, which seems unlikely, but one can never know).

As someone from Serbia, I'm not that fond of code CS; unfortunately,
all my preferences [SR, SC, SM] are taken, so I am neither for, nor
against this particular code. I'd only add that each of ISO 3166-1
codes is also related to a time of use, so if you don't have a
timestamp, you generally risk presenting incorrect data, and many are
probably doing it already, because there were changes in ISO 3166-1 
not as wide known as this one. 

Danilo Segan

More information about the Ietf-languages mailing list