Message-Id: <6.1.2.0.2.20050112102038.04f18320@mail.jefsey.com>
Date: Wed, 12 Jan 2005 11:03:01 +0100
To: "Peter Constable" <petercon@microsoft.com>,
	<ietf-languages@alvestrand.no>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <F8ACB1B494D9734783AAB114D0CE68FE04BAAF8E@RED-MSG-52.redmon
	d.corp.microsoft.com>
References: <F8ACB1B494D9734783AAB114D0CE68FE04BAAF8E@RED-MSG-52.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-2FE02643
Cc: 
Subject: RE: Use of "CS" for 'Serbia and Montenegro'
Precedence: list
Sender: ietf-languages-bounces@alvestrand.no
Errors-To: ietf-languages-bounces@alvestrand.no

At 06:35 12/01/2005, Peter Constable wrote:

> > From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-
> > bounces@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

_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages