Use of "CS" for 'Serbia and Montenegro'

JFC (Jefsey) Morfin jefsey at jefsey.com
Wed Jan 12 11:03:01 CET 2005


At 06:35 12/01/2005, Peter Constable wrote:

> > From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> > bounces at alvestrand.no] On Behalf Of Bruce Lilly
>
>
> > 1. the language-tag "sr-CS" fully conforms with the generative
> >    mechanisms in RFC 3066
> > 2. RFC 3066 gives explicit rules regarding interpretation of
> >    both primary and second subtags in such a case
> >
> > what makes you think that an RFC 3066 conforming language-tag
> > parser would even bother looking in the IANA registry for
> > "sr-CS" (which matches the generative mechanisms)?
>
>I don't. I assume that a parser needs to work when it's not connected to
>the net, and I don't assume that parsers need to have a clue what the
>string means.
>
>I do assume, however, that at some point users have a part in assigning
>tags to particular content, that at some point developers will associate
>certain known-valid tags with particular UI strings. And in those
>situations, having this tag registered can and would serve to clarify
>what this particular tag is and is not intended to be used for.

This is the _whole_ issue.

RFC 3066 langtags have most probably been used in the way you describe in 
your first paragraph and I see no problem there. A parser will have one 
option (or no option) for a given tag.

This is no more true when an external reference is necessary, as you 
document it in your second paragraph case, which is the case that 
Draft-Philips-languages-08.txt langtags is intended to support. Either 
because you think of developers (what is a tiny minority of the cases), or 
because you are now in a networked usage: in a web service, OPES, extended 
service. The two dialoging peers have to negotiate the language they use. 
Their "sr-CS" understanding may be different because they operate in 
different cultural context, use different dictionaries or their release 
date from different understandings of what "CS" means, etc.

This is why I say that scripting-language-country is enough information to 
select a language in your own word processor or in a choice of web pages, 
but is _not_ information enough to qualify a language _exchange_ between 
unrelated parties and to permit a language intersection negociation.

This is why we say that the Draft does not scale in an open network 
environment, why it cannot be a _general_ best common practice but why it 
can perfectly be a best common practice 
_for_chosing_in_a_scripting-language-country_table and why in such a case 
it would probably be deprecated soon enough by the default of a generalized 
"five-information-tag", unless the semantic of the "five-information-tag" 
could be made fully backward compatible with it (what call for this list to 
specify its requirements because such a "five-information-tag" will most 
probably result from a different and more generalized intergovernance than 
the RFC 3066 tag governance).

jfc



More information about the Ietf-languages mailing list