Subject: RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions

From: Dave Singer <[email-masked]>
Date: Mon, 3 Jan 2005 10:30:22 -0800

>
>The *meaning* of any given language tag would be no more or less a 
>problem under the proposed revision than it was for RFC 3066 or RFC 
>1766. For instance, there is a concurrent thread that has been 
>discussing when country distinctions are appropriate or recommended 
>("ca" or "ca-ES"?); this discussion pertains to RFC 3066, and part 
>of the issue is that meanings of tags are implied rather than 
>specified -- and always have been even under RFC 1766 (I pointed 
>this out five years ago when we were working on preparing RFC 3066).
>
>So, for instance, when an author uses "de-CH", what does he intend 
>recipients to understand to be the difference between that and 
>"de-DE" or even "de"? Neither RFC 1766 or RFC 3066 shed any light on 
>this, and ultimately only the author knows for sure.
>
>Under RFC 3066, it was the *exceptional* case that a complete tags 
>was registered, allowing some indication of the meaning of the whole 
>(though even in that regard nothing really required that the 
>documentation provide clear indication of the meaning). The 98% 
>cases were those like "de-CH" in which it was assumed that everyone 
>would understand what the intended meaning is.

This whole question of what 'matches' is subtle.  Consider the case 
when I have a document that has variant content by language (e.g. 
different sound tracks), and the user indicates a set of preferred 
languages.  If the content has "de-CH" and "fr-CH" (swiss german and 
french), and a default "en" (english) and the user says he speaks 
"de-DE" and "fr-FR", on the face of it nothing matches, and I fall 
back to the catch-all default, which is almost certainly not the best 
result.
-- 
David Singer
Apple Computer/QuickTime

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Tue, 04 Jan 2005 09:14:51 -0800 (PST)

> back to the catch-all default, which is almost certainly not the best

David, this isn't the half of it. The case you describe is actually one of the
easy ones, in that it can be handled by doing a "preferred" match on the entire
tag, with a "generic" match on the primary tag only having lesser precedence
but higher precedence than a fallback to a default.

I know of two other wrinkles in the RFC 1766 world:

(1) Matching may want to take into account the distinguished nature
    of country subtags in some way.

(2) SGN- requires special handling, in that SGN-FR and SGN-EN are in fact
    sufficiently different languages that a primary tag match should not be
    taken to be a generic match. (Of course this only matters if sign
    languages are relevant to your situation - in many cases they aren't.
    In retrospect I think it was a mistake to register sign languages this
    way.)

This proposed revision, however, opens pandora's box in regards to matching.
Consider:

(a) Extension tags appear as the first subtags, and as such have to
    be taken into account when looking for country subtags.

(b) Script tags change the complexion of the matching problem significantly,
    in that they can interact with external factors like charset information
    in odd ways.

(c) UN country numbers have been added (IMO for no good reason), requiring
    handling similar to country codes.

The bottom line is that while I know how to write reasonable code to do RFC
1766 matching (and have in fact done so for widely deployed software), I
haven't a clue how to handle this new draft competently in regards to matching.
And the immediate consequence of this is that I, and I suspect many other,
implementors are going to adopt a "wait and see" attitude in regards to
implementing any of this.

				Ned

---

From: [email-masked]
Date: Tue, 04 Jan 2005 09:51:59 -0800 (PST)

Small typo: In my previous response I referred to RFC 1766 when I meant
RFC 3066. Too many documents open at once, sorry.

				Ned

---

From: Dave Singer <[email-masked]>
Date: Tue, 4 Jan 2005 09:58:52 -0800

>but higher precedence than a fallback to a default.

Yes, I picked off an easy example for which the 'matching' section of 
the draft didn't seem adequate.  This really is a tar-pit, of course. 
Serbo-croatian used to be a language;  now it's serbian and croatian. 
I assume that they are mutually intelligible.  Serbian is probably a 
better substitute for croatian than some general default (or 
silence), though saying this in some parts of the world might start 
wars.

The whole question of what is a language, a variant or dialect of a 
language, or a suitable substitute for a language, would benefit some 
thought in any tagging scheme, though I agree the problem is not 
generally soluble.

-- 
David Singer
Apple Computer/QuickTime

---

From: John Cowan <[email-masked]>
Date: Tue, 4 Jan 2005 13:04:46 -0500

> I know of two other wrinkles in the RFC 1766 world:

Are you aware that RFC 1766 has been obsolete for four years now?

>    taken to be a generic match. 

The same is true of the various registered zh-* tags.

>    be taken into account when looking for country subtags.

Finding country codes is straightforward: any non-initial subtag of two letters
(not appearing to the right of "x-" or "-x-") is a country code.
This is true in RFC 1766, RFC 3066, and the current draft.

>    in that they can interact with external factors like charset information

Can you clarify this?  Charset information neither specifies nor necessarily
restricts (except in text/plain) the script used to write a document.

>    handling similar to country codes.

They provide for supranational language varieties and for stability in
country codes which is inappropriate for ISO 3166 alphabetic codes (which
are codes for country *names*).

> haven't a clue how to handle this new draft competently in regards to 

The draft describes only the RFC 1766 (3066) algorithm, without excluding
other algorithms to be defined later.

-- 
"Clear?  Huh!  Why a four-year-old child        John Cowan
could understand this report.  Run out          [email-masked]
and find me a four-year-old child.  I           http://www.ccil.org/~cowan
can't make head or tail out of it."             http://www.reutershealth.com
        --Rufus T. Firefly on government reports

---

From: John Cowan <[email-masked]>
Date: Tue, 4 Jan 2005 13:25:15 -0500

> the draft didn't seem adequate.  This really is a tar-pit, of course. 

Indeed it is, which is why the draft provides only one simple algorithm
(described as "the most common implementation", which it is) and explicitly
allows for cleverer techniques for those who want them.

> I assume that they are mutually intelligible.  

Among speakers of good will, yes.

> thought in any tagging scheme, though I agree the problem is not 

See the editor's draft of ISO 639-3 at http://tinyurl.com/6kky2 .  This is
a PDF file about 4 MB in size, so I excerpt the relevant text here (clause
4.2.1, pp. 3-4):

# There is no one definition of "language" that is agreed upon by all and
# appropriate for all purposes. As a result, there can be disagreement,
# even among speakers or linguistic experts, as to whether two varieties
# represent dialects of a single language or two distinct languages. For
# this part of ISO 639, judgments regarding when two varieties are
# considered to be the same or different languages are based on a number
# of factors, including linguistic similarity, intelligibility, a common
# literature, the views of speakers concerning the relationship between
# language and identity, and other factors. The following basic criteria
# are followed:
#
#	Two related varieties are normally considered varieties of the same
#	language if speakers of each variety have inherent understanding
#	of the other variety (that is, can understand based on knowledge of
#	their own variety without needing to learn the other variety) at a
#	functional level.
#
#	Where spoken intelligibility between varieties is marginal, the
#	existence of a common literature or of a common ethnolinguistic
#	identity with a central variety that both understand can be strong
#	indicators that they should nevertheless be considered varieties of
#	the same language.
# 
#	Where there is enough intelligibility between varieties to
#	enable communication, the existence of well-established distinct
#	ethnolinguistic identities can be a strong indicator that they should
#	nevertheless be considered to be different languages.
#
# Some of the distinctions made on this basis may not be considered
# appropriate by some users or for certain applications. These basic
# criteria are thought to best fit the intended range of applications,
# however.

-- 
First known example of political correctness:   John Cowan
"After Nurhachi had united all the other        http://www.reutershealth.com
Jurchen tribes under the leadership of the      http://www.ccil.org/~cowan
Manchus, his successor Abahai (1592-1643)       [email-masked]
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all         The Languages of China
to be called Manchus."

---

From: [email-masked]
Date: Tue, 04 Jan 2005 21:58:41 -0800 (PST)

> Are you aware that RFC 1766 has been obsolete for four years now?

Of course I am.

> The same is true of the various registered zh-* tags.

Yes, forgot to mention that one. It is actually different and more important in
that the use-cases aren't the same as those for sign languages.

> This is true in RFC 1766, RFC 3066, and the current draft.

On the contrary, in RFC 3066 the rule is "any 2 letter value that appears as
the second subtag is a country code". The rule in the new draft is either the
formulation you give above or  "any 2 letter value that appears as a subtag
after the initial subtag and some number of 3 and 4 letter subtags".

These aren't the same.

> restricts (except in text/plain) the script used to write a document.

And what if you're dealing with text/plain, as many applicationss do?

Just because something doesn't necessarily do something doesn't mean it
never does it.

> are codes for country *names*).

I'm aware of what they provide (although I see no explanation of this
in the draft). I'm just not convinced that their addition is warranted.

> other algorithms to be defined later.

Well, maybe I'm missing something obvious, but I see nothing in RFC 3066 that
qualifies as a description of a matching algorithm. The new draft does include
such a description in section 2.4.2 - an improvement - but leaves any number of
details open. And we all know where the devil lives.

Side note: I don't think item 4 really belongs in the list in section 2.4.2.
It is a warning to implementors, not part of the matching mechanism.

				Ned

---

From: John Cowan <[email-masked]>
Date: Wed, 5 Jan 2005 09:01:46 -0500

[email-masked] scripsit:

> > Finding country codes is straightforward: any non-initial subtag of
> > two letters (not appearing to the right of "x-" or "-x-") is a country
> > code.  This is true in RFC 1766, RFC 3066, and the current draft.
> 
> On the contrary, in RFC 3066 the rule is "any 2 letter value that
> appears as the second subtag is a country code". The rule in the new
> draft is either the formulation you give above or  "any 2 letter value
> that appears as a subtag after the initial subtag and some number of
> 3 and 4 letter subtags".

I didn't state it as a rule, but as true.  Every non-initial 2-letter
tag in RFC 3066 is a country code; the same is true in the draft.
(A private correspondent notes that the reference to "-x-" should
in fact be a reference to any singleton, though "-x-" and "i-" are
the only singletons currently usable.)

> Just because something doesn't necessarily do something doesn't mean it

It does mean it can't be counted on in the general case.

> Well, maybe I'm missing something obvious, but I see nothing in RFC
3066 that > qualifies as a description of a matching algorithm.

Section 2.5 (2.4.1 in the draft) states the matching rule in a succinct
fashion.  Everything in 2.4.2 is a non-normative elaboration of this.

-- 
John Cowan  www.reutershealth.com  www.ccil.org/~cowan  [email-masked]
'Tis the Linux rebellion / Let coders take their place,
The Linux-nationale / Shall Microsoft outpace,
We can write better programs / Our CPUs won't stall,
So raise the penguin banner of / The Linux-nationale.  --Greg Baker

---

From: [email-masked]
Date: Wed, 05 Jan 2005 07:33:04 -0800 (PST)

> tag in RFC 3066 is a country code; the same is true in the draft.

Again, that is not what RFC 3066 says. From section 2.2:

 There are no rules apart from the syntactic ones for the third and subsequent
 subtags.

Sure sounds to me like a third two letter subtag is (a) Allowed and (b)
Isn't supposed to be treated as country code.

Now, it may be the case that all _registered_ tags have avoided the use of
non-country code two letter codes in the third and later position. But this is
100% irrelevant. The point is that conformant code implementing RFC 3066 is
broken if it simply assumes any 2 letter code after the first subtag is a
country code. Rather, the rule is simply that a country code, if present,
always appears as a two letter second subtag. The new draft changes this rule,
so applications that pay attention to coutnry codes in language tags have to
change and the new algorithm for finding the country code is trickier.

> the only singletons currently usable.)

I have to say I find it quite interesting that one of the main proponents of
the new draft, while arguing that the new draft doesn't make the matching
problem a lot harder, ended up giving an erroneous rule for extracting country
codes from a language tag. 

> It does mean it can't be counted on in the general case.

Sure, in the general case most if not all of these nasty corner cases you've
created can be blithly assumed away because they only appear in specific
problem domains. Actual applications that operate in those specific domains
aren't so lucky, however. And the metric we're supposed to apply in the IETF is
real world implementability.

As it happens I deal with messaging applications, and in this space text/plain
with all sorts of nasty charset issues is the rule, not the exception.

> > 3066 that qualifies as a description of a matching algorithm.

> fashion.  Everything in 2.4.2 is a non-normative elaboration of this.

??? Which in no way refutes my assertion that no matching rule algorithm
was given in RFC 3066!

				Ned

---

From: John Cowan <[email-masked]>
Date: Wed, 5 Jan 2005 17:26:16 -0500

[email-masked] scripsit:

> 100% irrelevant.

If you say so.

> The point is that conformant code implementing RFC 3066 is
> always appears as a two letter second subtag.

Not quite.  The rule is that a 2-letter second subtag is a country code.
Country codes could have appeared elsewhere, and may still wind up doing so
before RFC 3066 is obsoleted.

> The new draft changes this rule,

But not much.  As an advantage, country codes can always be found in the new
draft, whereas in RFC 3066 they could in principle be anywhere.

> codes from a language tag. 

Like other people, I sometimes post when tired; I don't think this particularly
interesting.

> real world implementability.

I fail to see what this has to do with the merit of marking scripts in language
tags.  The preferred IETF charset, UTF-8, contains no information about script
whatever.

> with all sorts of nasty charset issues is the rule, not the exception.

Extended language tags will neither help nor harm you, then.

-- 
"We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.
Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
fishes, for a poor creature, and they say death.  So wise they are; so just,
so very just."  --Gollum        [email-masked]  www.ccil.org/~cowan

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 5 Jan 2005 17:55:42 -0800

> Rather, the rule is simply that a country code, if present,

Your text above says (a) "if there is a country code in the tag, it is the
second subtag". That is not what text of RFC 3066 actually says, which is:

> The following rules apply to the second subtag:
> All 2-letter subtags are interpreted as ISO 3166 alpha-2 country...

That is, it says (b) "if a second subtag has 2 letters, then it is an ISO
3166 code", which is not the same as (a). (It is almost, but not quite, the
converse.) The current RFC certainly does not forbid the use of country
codes in other positions in language tags. One could absolutely register
en-Latin-US, for example, meaning English as spoken in the US written in
Latin script.

There has been a lot of noise on this issue, and too few concrete examples.
In the so-called 3066bis draft, we have striven very hard to ensure that:

(c) Every single tag that could be generated under RFC 3066bis is a tag that
could have been registered under RFC 3066.

Thus if someone wrote a parser that is future-compatible -- that could parse
all RFC 3066 language tags including those registered after the parser was
deployed -- then that parser can handle all 3066bis language tags. This is a
significant advance over RFC 3066, whose registered (not generated) language
tags are atomic, and cannot be effectively parsed at all. 3066bis adds more
structure so as to allow effective parsing of tags.

If you *can* come up with tags that would show that (c) is invalid, that
would be a concrete case that we would have to make adjustments in the draft
for.

A second issue that has come up is complexity. Admittedly, 3066bis is more
complex than RFC 3066. Part of that is due to adding additional structure,
and part due to necessary clarifications (such as the distinction between
well-formed and valid). But we did not add the additional structure at a
whim. RFC 3066, while a significant advance, is simply not now powerful
enough to meet the current needs for distinctions in language needed by the
industry. The companies and organizations in the Unicode consortium, for
example, are supporting 3066bis for improved software internationalization.
For more information on the reasons behind the enhancements in 3066bis see
http://www.inter-locale.com/ID/why-rfc3066bis.html.

Moreover, all the talk about this being *too* complex is far overblown. All
3066bis language tags can be parsed, including all the grandfathered codes,
with a very short piece of code, or even with a regular expression (such as
in Perl). This is not rocket science.

‎Mark

----- Original Message ----- 
From: <[email-masked]>
To: "John Cowan" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 05, 2005 07:33
Subject: Re: draft-phillips-langtags-08, process, sp
ecifications,"stability", and extensions

> Ietf-languages mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>

---

From: [email-masked]
Date: Thu, 06 Jan 2005 06:35:34 -0800 (PST)

> before RFC 3066 is obsoleted.

But it is wrong for a compliant 3066 implementation to assume that such a two
letter code is a country code!

I really cannot fathom why this issue is so hard for you to understand.

> draft, whereas in RFC 3066 they could in principle be anywhere.

Not really. Anyhing that puts a country code in some other location in the
3066 world isn't going to get the benefit of automatic recognition of the
code as such by a 3066-compliant parser.

> Like other people, I sometimes post when tired; I don't think this particularly

Whereas everyone who writes code when they implement this stuff will be as
fresh as a daisy?

> tags.  The preferred IETF charset, UTF-8, contains no information about script

Sadly, the IETF's preferences haven't managed to catch on in many parts of the
world.

> Extended language tags will neither help nor harm you, then.

This actually may be true, because as I have said before, the likely outcome if
this draft is adopted in its present form will be that it will simply be
ignored in its entirety. But is this what we want?

				Ned

---

From: [email-masked]
Date: Thu, 06 Jan 2005 06:44:38 -0800 (PST)

> converse.)

Fine, whatever.

> The current RFC certainly does not forbid the use of country

Sure, but my point was, is, and always has been that any 3066-compliant
implementation won't see this as a country code (unless it is table driven,
which brings up its own set of issues).

> There has been a lot of noise on this issue, and too few concrete examples.

No, what there has been is a lot of discussion of a real problem with no
apparent recognition of it as such by the draft authors. Your pejorative
characterization of this as "noise" does not make it so.

> could have been registered under RFC 3066.

True but irrelevant.

> would be a concrete case that we would have to make adjustments in the draft

(c) is frankly not an issue I care one whit about. (Perhaps I should, but I
don't.) I don't register tags. I write code that processes, and more to the
point matches, tags. That's why I have issues with this draft.

> Moreover, all the talk about this being *too* complex is far overblown.

Again, your pejorative dismissal of other people's concerns does not
mean your position is valid.

> All
> in Perl).

Of course you can write a short piece of code to parse this stuff. It's what you
do with it after you parse it that's a problem.

> This is not rocket science.

Parsing almost never is. But simply parsing these tag is not, and never has
been, the issue.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jan 2005 10:48:36 -0500

--On Thursday, 06 January, 2005 06:35 -0800
[email-masked] wrote:

>...
> This actually may be true, because as I have said before, the
> likely outcome if this draft is adopted in its present form
> will be that it will simply be ignored in its entirety. But is
> this what we want?

Actually, Ned, my concern goes a little beyond "ignored in its
entirety".   If this thing were adopted as a separate standard,
with some scope of applicability, and it were completely
ignored, that would not really be harmful except on the great
scoreboard of standards issued versus standards used.   But, if,
in the process, it succeeds in identifying 3066 as Obsolete
without replacing it with anything that is usable and
compatible, that could cause a serious reduction in
interoperability in the areas where 3066, today, is good enough
or just about good enough.

That brings me back to what I've tried to suggest several times
but which, as you observe, the authors of this draft seem to
dismiss either as "noise" or as a "no change to 3066 under any
circumstances" position.    If the purpose is to get this model
out there, rather than replacing 3066 because it is generally
offensive, there is a fairly quick way to get this document
unstuck:

(1) Remove the notion and statements about obsoleting 3066.
This would probably require a change of title and some
introductory material, but that shouldn't be a big deal if the
real goal is to get it finished and published.

(2) Create a new section, called "applicability" that contains
at least one example of how and where this system would be used.
I'm not wild about it but, personally, I'd settle for some vague
handwaving like "places where more comprehensive identification
is needed than is provided by 3066".

(3) Ask the IESG to approve publication of the thing as either a
Proposed Standard or an Experimental document, as they believe
best matches the needs and consensus of the community.  The
document is not a good candidate for BCP for three reasons: (i)
as you and I have commented, it contains algorithmic and
protocol specifications, rather than just specifying a
registration procedure.  3066 was, IMO, marginal in that regard;
this is well over the line.  (ii) As Jefsey has pointed out,
this is not yet a "current practice", "best" or otherwise.
(iii) Two BCP documents covering the same space would be certain
to create confusion unless the applicability differences were
much more clearly stated than I think anyone is prepared to do.

Then we let the market sort the situation out.  If the proposers
of this specification are right about how important the
additional detail are, I'd expect to see 
   Content-language: <3066-tag>
   X-Extended-Content-language: <new-tag>
and its equivalents show up all over the email environment and
the web.  The interpretation and matching issues would either
sort themselves out or they wouldn't.   If it became clear, in
practice, that this was the right way to go for a broader range
of applications, writing a short RFC to update the applicability
statement (and to move the thing from Experimental to Proposed
Standard if the IETF went the "experimental" route), would be
pretty trivial.   If that range appeared to the community to be
subsuming all of the applications of 3066, the same document
could provide the "obsoletes 3066" decision.

You've probably got a prediction about how likely the broadest
form of outcome is, and it probably matches mine.  But the IETF
does not, and should not try, to impose technologies by
replacing working standards, and, despite my biases about
experience and processes, our predictions should ultimately be
no more determinative than that of the authors.  Let's separate
this from "replaces 3066", get it out there, see how important
and useful the marketplace thinks it is, and let the marketplace
(and the experimental/ proposed standard models) sort of the
implementability and usability problems.

    john

---

From: John Cowan <[email-masked]>
Date: Thu, 6 Jan 2005 15:28:33 -0500

>    X-Extended-Content-language: <new-tag>

This reflects a fundamental misunderstanding of what the draft does
compared to what RFC 3066 does.  It imposes *more* restraints on language
tags, not fewer.  The RFC 3066 language tag registration process can
register tags with almost unpredictable meaning once one gets past the
first subtag.  The draft *limits* the possible tags to a small subset,
and tightens up the allowable semantics.  It allows no tag to be used
that was not already registerable under RFC 3066.

In RFC 3066, it is only a heuristic (or examination of the IANA registry,
which is not machine-parseable) that tells the meaning of the second
subtag the existing registered tag sr-Latn.  In the draft, its meaning
is unambiguously specified a priori.

-- 
John Cowan  <[email-masked]>  http://www.ccil.org/~cowan
        Raffiniert ist der Herrgott, aber boshaft ist er nicht.
                --Albert Einstein

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 6 Jan 2005 15:47:49 -0800

First, I apologize about the statement "there has been a lot of noise on
this issue". By that, I wasn't really meaning your message in particular. I
was commenting more on the general status of a quite a number of statements
that have been made on the overall topic. And by "noise", I really mean
high-level statements without explicit examples or scenarios, where it is
very hard for people not familiar with the details to be able to judge the
correctness of the statements.

And I will assume that it was that perceived insult that caused you to be
dismissive, with your statement below about "Fine, whatever." I assume that
otherwise you would not so readily conclude that it didn't matter whether
RFC 3066 said "if X then Y" vs. "if Y then X". Those are, after all, very
different statements, and a confusion between them would cause incorrect
conclusions to be drawn.

> > could have been registered under RFC 3066.

Not at all irrelevant. Suppose someone is using a RFC 3066 parser, and is
faced with either:

(a) a registered tag from a future version of the RFC 3066 registry, or
(b) a 3066bis tag (that uses generative features not in RFC 3066).

Their parser will work *exactly* the same way; they would parse both as
being equally well-formed, and they will be unable to determine any of the
structure of either tag, and just treat each as a blob. So they are no
better off, but *no worse off either*. (Had we not followed (c), this would
not have been true.) Of course, if they try parsing a tag that is generated
according to RFC 3066 (eg not in the registry), then they would be able to
parse out the language code and/or country.

If they update to a 3066bis parser, then they can reliably extract much more
information from the tag. And because 3066bis was written to be backwards
compatible, anything RFC 3066 generated language tag parses out exactly the
same as it would with an RFC 3066 parser.

Now you yourself may not care much about the extra information in the
3066bis language tag. But IBM, and many other companies and organizations
do. This is not some theoretically problem; it is a real current issue that
many are faced with. For example, without reliable script information many
languages are severely underspecified. One simply cannot mix content with
different scripts and have happy customers.

And if you don't care about the extra information, you are no worse off than
if you were trying to parse a registered RFC 3066 tag. For matching
purposes, the commonly used truncation mechanism will work just as well with
all 3066bis tags as it does with RFC 3066 tags, for all tags you will
encounter.

‎Mark

----- Original Message ----- 
From: <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, January 06, 2005 06:44
Subject: Re: draft-phillips-langtags-08, process, sp
ecifications,"stability",and extensions

> > > always appears as a two letter second subtag. The new draft changes
this
> > rule,
> > > so applications that pay attention to coutnry codes in language tags
have
> > to

---

From: [email-masked]
Date: Thu, 06 Jan 2005 16:39:08 -0800 (PST)

> dismissive,

I was dismissive because your correction, while accurate, was irrelevant
to the current discussion of the change to country code semantics.

> with your statement below about "Fine, whatever." I assume that

Of course they are, but I fail to see how any of this impacts the country
code issue I have been discussing.

> Not at all irrelevant.

I meant, of course, that it is irrelevant to the issue at hand.

> Suppose someone is using a RFC 3066 parser, and is
> faced with either:

I am well aware of the value of this sort of backwards compatibility. I
am not, I hope, a total fool, which I would have to be to be unaware of this.

> 3066bis language tag.

I never said that. In fact I have repeatedly said exactly the opposite.

> But IBM, and many other companies and organizations

I am well aware of this. You are presenting a strawman argument here.

> if you were trying to parse a registered RFC 3066 tag.

It is somewhat axiomatic that if I don't care about something I don't
care when that something changes.

> For matching

Given that the matching approach I have been talking about is not simple
truncation, I'm afraid this is yet another strawman.

				Ned

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 07 Jan 2005 02:44:33 +0100

Dear John,
thank you to acknowledge that the proposed draft "_impose_" something ! It 
therefore do not report on an existing practice.
thank you to acknowledge that the proposed draft even "_limits_" the 
current practice !
thank you to explain that the decision of the user is replaced by an 
a-priori obligation .. resulting from a decision of a member of this list.

Technically, these remarks are however without incidence on John Klenin's 
remark: a limitation is only a (negative) extension. I support _every_ 
position of John Klensin today (except that the IANA registrations should 
be transfered to IANA now which would set-up a global procedure equal to 
all, to address the possible discrepancies between the RFC 3066 and the 
draft). This would permit an acceptance by the IESG. Otherwise such an 
acceptance is unadvisable.
jfc

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jan 2005 23:20:13 -0500

--On Thursday, 06 January, 2005 15:28 -0500 John Cowan
<[email-masked]> wrote:

> This reflects a fundamental misunderstanding of what the draft
> does compared to what RFC 3066 does.  It imposes *more*
> restraints on language tags, not fewer.

It also very explicitly permits talking about scripts, not just
languages and countries.    That, to me, is an extension,
regardless of the additional constraints.  But I could have used
a different word; this was just an example.

>  The RFC 3066 language
> tag registration process can register tags with almost
> unpredictable meaning once one gets past the first subtag.
> The draft *limits* the possible tags to a small subset, and
> tightens up the allowable semantics.  It allows no tag to be
> used that was not already registerable under RFC 3066.

The "extension" that I see involves more semantics and formal
variations, not more possible registered tags.    And, as Ned as
pointed out repeatedly, there are things that can be done in
3066 parsers/interpreters in practice that have to be done
differently in this new system.  I could, of course, have used
"X-Incompatible-Content-Language" in my example, but that
presumably would have set you off in some other direction.

> In RFC 3066, it is only a heuristic (or examination of the
> IANA registry, which is not machine-parseable) that tells the
> meaning of the second subtag the existing registered tag
> sr-Latn.  In the draft, its meaning is unambiguously specified
> a priori.

So?

    john

---

From: John Cowan <[email-masked]>
Date: Fri, 7 Jan 2005 07:52:53 -0500

JFC (Jefsey) Morfin scripsit:
> Dear John,
> thank you to acknowledge that the proposed draft "_impose_" something ! 
> It therefore do not report on an existing practice.

The practice that is being limited is that of the language tag review
process (the list, the Reviewer, IANA), not of any user.  Users are
free to use language tags or not, of course.

> remark: a limitation is only a (negative) extension. 

And tyranny is only negative liberty, I suppose?  Hogwash.

> (except that the IANA registrations should be transfered to IANA now  [...])

Is this supposed to mean something?

-- 
"How they ever reached any conclusion at all    [email-masked]>
is starkly unknowable to the human mind."       http://www.reutershealth.com
        --"Backstage Lensman", Randall Garrett  http://www.ccil.org/~cowan

---

From: John Cowan <[email-masked]>
Date: Fri, 7 Jan 2005 08:31:07 -0500

> > sr-Latn.  In the draft, its meaning is unambiguously specified

So it is meaningless to talk about "breaking backward compatibility"
when the behavior in question is a heuristic (or to quote Ned,
"it works in most but not all cases").  Registration of new tags
under RFC 3066 can and will break the heuristic all by themselves.
The new draft talks about scripts, but the existing registered tags
talk about scripts too.