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 des
> 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
--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 i
--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:
>
> This reflects a fundamental misunderstanding of what the draft
> does compared to what RFC 3066 does. It im
> 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 imp
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-pr
> 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
> 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
>
> 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 w
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
hi
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 Si
> 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.
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
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
comp
John C Klensin scripsit:
>Content-language: <3066-tag>
>X-Extended-Content-language:
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 proc
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-
> 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!
> From: Dave Crocker <[EMAIL PROTECTED]>
> 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.
You say "the community", tho
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 b
> 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-f
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
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 ter
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 application-s
> However the reason
> why many things come in as individual submissions is that the community
> doesn't care much.
I sure hope you are very, very wrong.
If the community does not care much, then I do not see the purpose in making it
an IETF standard.
A standards process is primarily abou
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 tha
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 statements
>3066) that go beyond the patterns 'll(-CC)" and "lll(-CC)". If we stick
with RFC 3066, we will have no way of writing forward-compatible
processors that will be able to do very useful matching.
I want to reinforce what Peter has said. In RFC 3066 we have already
registered language tags like zh-H
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 seriou
--On 6. januar 2005 06:24 -0800 [EMAIL PROTECTED] wrote:
I believe that John meant sect. 2.5 of RFC 3066, which does indeed
mention a matching algorithm. However, the proposed changes in the
structure of tags interact badly with that algorithm.
My reading of that text is that it goes out of its w
I have seen very little disagreement on the intent of the words in the
paragraphs I quoted, but quite a bit of wordsmithing. So let's try
again.
The members of the IAOC shall select one of its appointed voting
members to serve as the chair of the IAOC.
The term of the IAOC chair shall
On Thu, Jan 06, 2005 at 04:08:05PM +, Michael Everson wrote:
> At 16:56 +0100 2005-01-06, Keld Jørn Simonsen wrote:
>
> >I would also favour the country code as second field, as it would be
> >backwards compatible with RFC 3066, and also compatible with the order
> >used in locales.
>
> That
--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 ab
On Thu, Jan 06, 2005 at 06:31:40AM -0800, [EMAIL PROTECTED] wrote:
> > > For the triple of
> > > language/country/script to match usefully in the general case by
> > > RFC 3066 parsers (which are unaware of script in general), the first
> > > and second subtags would have to remain language code an
--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
> 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, th
> > From: [EMAIL PROTECTED] [mailto:ietf-languages-
> > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> > My reading of that text is that it goes out of its way to try and
> avoid
> > direct
> > discussion of a matching algorithm, talking instead about "rules" and
> > "constructs". I no longer
Brian E Carpenter wrote:
x.x Compensation for IOAC members
The IOAC members shall not receive any compensation (apart from
exceptional reimbursement of expenses) for their services as
members of the IOAC."
This text works for me. And I agree with Jonne that it makes
sense for the BCP to talk about
> > 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 tr
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> My reading of that text is that it goes out of its way to try and
avoid
> direct
> discussion of a matching algorithm, talking instead about "rules" and
> "constructs". I no longer recall the ci
> [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 i
> > For the triple of
> > language/country/script to match usefully in the general case by
> > RFC 3066 parsers (which are unaware of script in general), the first
> > and second subtags would have to remain language code and country
> > code respectively.
> If you consider realistic scenarios, th
> > Date: 2005-01-05 10:33
> > From: [EMAIL PROTECTED]
> > > 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.
> >
> > ??? Which in no way refutes my assertion that no matching rule algorithm
> > wa
JFC (Jefsey) Morfin scripsit:
> I also note the importance of the "entities" given by the Internet
> standard process in BCPs. I would be interested in knowing which entities
> are participating as such (or nearly as such - I see the W3C, which other
> entity?) to this proposition.
Construe, c
Hello,
Does anyone have an archive of the IETF list prior to 1991? I am
specifically looking for 88-90 incl.
Thanks,
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Bruce Lilly scripsit:
> > > Precisely; an RFC 1766/3066 parser, based on the 1766 and
> > > 3066 specifications, can expect four classes of language tags:
> > > 1. ISO 639 language code as the primary subtag, optionally
> > > )B followed by an ISO 3166 country code as the second tag
> > > 2. i
Bruce Lilly 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.
>
> I believe that:
> 1. it is not strictly true of the re
46 matches
Mail list logo
