Dave Crocker wrote:
And, indeed, I haven't seen much support for the document under
discussion.
I find statements such as this mind-boggling. Please explain what you
mean by much support. There have been at least as many individuals
writing mails in favour of the document as against it.
On Mon, 10 Jan 2005 11:33:54 GMT, Misha Wolf said:
I find statements such as this mind-boggling. Please explain what you
mean by much support. There have been at least as many individuals
writing mails in favour of the document as against it. Furthermore,
it has been made clear that the
Let me take this opportunity to say that Apple, too, strongly supports
3066bis.
Deborah Goldsmith
Internationalization, Unicode liaison
Apple Computer, Inc.
[EMAIL PROTECTED]
On Jan 10, 2005, at 3:33 AM, Misha Wolf wrote:
I find statements such as this mind-boggling. Please explain what you
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.
thank you to acknowledge that the proposed draft even _limits_ the
current practice !
thank you to explain that the decision of
[EMAIL PROTECTED] scripsit:
What would be really nice is to specify a parameterized matching
algorithm (or more precisely, an algorithm family) along the lines
of the stringprep family of string normalization algorithms. But
I'm unsure if there's sufficient time and interest available to do
John C Klensin scripsit:
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?
So
[EMAIL PROTECTED] scripsit:
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.
If you say so.
The point is that conformant code implementing RFC 3066 is
broken
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.
From: [EMAIL PROTECTED] [mailto:ietf-languages-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Again, your pejorative dismissal of other people's concerns does not
mean your position is valid...
Parsing almost never is. But simply parsing these tag is not, and
never
has
been, the
--On Thursday, 06 January, 2005 06:35 -0800
[EMAIL PROTECTED] wrote:
...
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
--On Thursday, 06 January, 2005 07:42 -0800 Peter Constable
[EMAIL PROTECTED] wrote:
...
But Ned's concerns are legitimate, I think. I'd say they are
not necessarily blocking issues for this draft, because I
think a possible outcome of discussion is to characterize them
as concerns about
On Thu, 06 Jan 2005 11:04:54 -0500, John C Klensin wrote:
Peter, as soon as we get to valid concerns that deserve
attention, we remove the proposed document, I believe, as a
candidate for BCP.
That pretty much applies to all specifications. A Last Call that produces any
sort of serious
Subject: RE: draft-phillips-langtags-08, process, sp
ecifications,stability, and extensions
From: [EMAIL PROTECTED] [mailto:ietf-languages-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Again, your pejorative dismissal of other people's concerns does not
mean your position is valid
Dave Crocker wrote:
It occurs to me that a Last Call for an independent submission has an added
requirement to satisfy, namely that the community supports adoption of the
work. We take a working group as a demonstration of community support.
(However we used to pressure for explicit
Dave,
While we are pretty much in agreement, three observations, one
based on Scott's default no objection observation.
(1) I think you are right that there are two issues with an
independent submission, one of which is the notion of support
that doing something is a good idea. And I agree
This is similar to the reason why the language code comes before the country
code. If we had the order CH-fr, then we could end up mixing French and
German in the same page, because we would fall back (for one of the data
sources) from CH-fr to CH, which could be German.
It has to be
I notice two main types of arguments going on in this thread, where it seems to
me that there is frustration
and talking past each other occurring due to fundamentally different concerns
and assumptions between
different constituencies.
One type of conflict seems to me between what I will
Dave Singer scripsit:
It has to be application-specific which fallback happens. If the
user says he's swiss french, and the the content has alternative
offers for swiss german or french french, which do you present? If
the content actually differs for legal or geographic reasons ('the
From: Dave Singer [mailto:[EMAIL PROTECTED]
This is similar to the reason why the language code comes before the
country
code. If we had the order CH-fr, then we could end up mixing French
and
German in the same page, because we would fall back (for one of the
data
sources) from CH-fr to CH,
At 11:34 AM -0800 1/6/05, Peter Constable wrote:
From: Dave Singer [mailto:[EMAIL PROTECTED]
This is similar to the reason why the language code comes before the
country
code. If we had the order CH-fr, then we could end up mixing French
and
German in the same page, because we would fall back
From: Dave Singer [mailto:[EMAIL PROTECTED]
Sorry, I should have gone on to conclude: the important aspect of
sub-tags is that their nature and purpose be identifiable and
explained (e.g. that this is a country code), and that we retain
compatibility with previous specifications.
Ah! Then
Dave Singer scripsit:
This spec. should unambiguously allow me to extract the language,
country, script etc.,
It does (and RFC 3066 does not).
should say under what circumstances two
sub-tags of any type match, state the obvious that two tags exactly
match if they have the same sub-tags
John C Klensin scripsit:
Content-language: 3066-tag
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
At 12:14 PM -0800 1/6/05, Peter Constable wrote:
From: Dave Singer [mailto:[EMAIL PROTECTED]
Sorry, I should have gone on to conclude: the important aspect of
sub-tags is that their nature and purpose be identifiable and
explained (e.g. that this is a country code), and that we retain
Dave Singer scripsit:
as has been beautifully pointed out on the list, that is a view that
is lingo-centric. If what I am trying to differentiate is the price
(and the currency of the price) of an item, the country may be much
more important than the script that the price is written in.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
I notice two main types of arguments going on in this thread, where it
seems to me
that there is frustration
and talking past each other occurring due to fundamentally different
concerns and
assumptions between different constituencies...
I
I'm sorry, this example I gave doesn't correspond to *language*
matching. My error. My apologies.
(Nor should my questions on this subject be seen as suggesting either
that I as an individual, or particularly Apple as a company, is
unhappy revising RFC 3066.)
At 12:35 PM -0800 1/6/05, Dave
tags you will
encounter.
Mark
- Original Message -
From: [EMAIL PROTECTED]
To: Mark Davis [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org
Sent: Thursday, January 06, 2005 06:44
Subject: Re: draft-phillips-langtags-08, process, sp
ecifications,stability
From: [EMAIL PROTECTED] [mailto:ietf-languages-
[EMAIL PROTECTED] On Behalf Of John C Klensin
(3) Finally, there is apparently a procedural oddity with this
document. The people who put it together apparently held
extended discussions on the ietf-languages mailing list, a list
that was
And I will assume that it was that perceived insult that caused you to be
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
In a nutshell, Ned was elaborating on a comment from Dave Singer that,
once we have parsed a pair of tags and identified all the pieces, it's
not a trivial matter to decide in every case how the two tags compare,
and that there are factors that would exist if the draft were approved
that
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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
RFC 3066 left us with bigger problems: it doesn't give us any
way to identify pieces that we would be encountering in registered
tags
(apart from hard-coded tables compiled from versions of the registry
that pre-exist a given
--On Thursday, 06 January, 2005 15:28 -0500 John Cowan
[EMAIL PROTECTED] wrote:
John C Klensin scripsit:
Content-language: 3066-tag
X-Extended-Content-language: new-tag
This reflects a fundamental misunderstanding of what the draft
does compared to what RFC 3066 does. It imposes
--On Thursday, 06 January, 2005 16:30 -0800 Peter Constable
[EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
[mailto:ietf-languages- [EMAIL PROTECTED] On Behalf Of
John C Klensin
(3) Finally, there is apparently a procedural oddity with this
document. The people who put it together
From: [EMAIL PROTECTED] [mailto:ietf-languages-
[EMAIL PROTECTED] On Behalf Of John C Klensin
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
John:
Peter, just to clarify... In my opinion (which isn't necessarily
worth much)
(I sincerely doubt that's the case.)
, the procedures that were followed were perfectly
reasonable. Anyone can form a design team and put a document
together, and there are no rules that bar such a design
[EMAIL PROTECTED] 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
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
[EMAIL PROTECTED] scripsit:
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.
If you say so.
The point is that conformant code implementing RFC 3066 is
broken if it
: draft-phillips-langtags-08, process, sp
ecifications,stability, and extensions
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
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
Small typo: In my previous response I referred to RFC 1766 when I meant
RFC 3066. Too many documents open at once, sorry.
Ned
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
At 9:14 AM -0800 1/4/05, [EMAIL PROTECTED] wrote:
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
[EMAIL PROTECTED] scripsit:
I know of two other wrinkles in the RFC 1766 world:
Are you aware that RFC 1766 has been obsolete for four years now?
(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
Dave Singer scripsit:
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.
Indeed it is, which is why the draft provides only one simple algorithm
(described as the most common implementation, which it is)
From: Dave Singer [mailto:[EMAIL PROTECTED]
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.
These are questions that
From: [EMAIL PROTECTED] [mailto:ietf-languages-
[EMAIL PROTECTED] On Behalf Of John Cowan
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
[EMAIL PROTECTED] scripsit:
I know of two other wrinkles in the RFC 1766 world:
Are you aware that RFC 1766 has been obsolete for four years now?
Of course I am.
(2) SGN- requires special handling, in that SGN-FR and SGN-EN are in fact
sufficiently different languages that a primary
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
From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED]
Dear Peter,
please let focus on the discussion of draft to be approved by the IESG and
on its role.
Eh???!! I can't imagine what on earth do you think I was talking about if not
that.
This document intends to replace RFC 3066 but does
From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED]
Of course it would not be clear if you don't have a conceptual model of
what language tags are identifiers *of*. When RFC 3066 was being
developed, there was a suggestion that script IDs be incorporated, but
some were reluctant, raising
52 matches
Mail list logo
