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 registered tag
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 as the primary
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
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,
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
was given in RFC
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, this makes
[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
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
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.
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
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
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 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 and country
--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, 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 would be
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 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
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
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
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
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 about
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
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
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
The IESG has received a request from the Multiprotocol Label Switching WG to
consider the following document:
- 'Link Bundling in MPLS Traffic Engineering '
draft-ietf-mpls-bundle-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
A new Request for Comments is now available in online RFC libraries.
RFC 3958
Title: Domain-Based Application Service Location Using
SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)
Author(s): L. Daigle, A. Newton
A new Request for Comments is now available in online RFC libraries.
RFC 3981
Title: IRIS: The Internet Registry Information Service
(IRIS) Core Protocol
Author(s): A. Newton, M. Sanz
Status: Standards Track
Date:
A new Request for Comments is now available in online RFC libraries.
RFC 3982
Title: IRIS: A Domain Registry (dreg) Type for the
Internet Registry Information Service (IRIS)
Author(s): A. Newton, M. Sanz
Status: Standards Track
49 matches
Mail list logo
