--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
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
> > 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
> 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
> > 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
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
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
> > [...] RFC 1766/3066 need to be able to deal with tags that contain pieces
> > they don't
> know about -- the only subtags they can know about are initial subtags of
> "i", "x" or
> ISO 639 IDs, or
Bruce Lilly scripsit:
> I believe that John meant sect. 2.5 of RFC 3066, which does indeed
> mention a matching algorithm.
Yes.
> However, the proposed changes in the
> structure of tags interact badly with that algorithm.
It just makes the algorithm imperfect; however, it was imperfect before
> 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 RF
> Date: 2005-01-04 13:04
> From: John Cowan <[EMAIL PROTECTED]>
> 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
> Date: 2005-01-03 02:09
> From: "Peter Constable" <[EMAIL PROTECTED]>
> > 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
> > Â Âfollowed by an ISO 3166 co
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
> > I don't think it's that uncommon to refer to a specification A that
> makes use of another specification B as an application of B.
>
> Perhaps, but I think it's best to avoid misunderstanding in
> t
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
> > Ah, but RFC 3066 does not sanction use of tags like "sr-CS-Latn" without
> registration, and no such tags are registered.
>
> Precisely; an RFC 1766/3066 parser, based on the 1766 and
> 3066 specifi
> Date: 2005-01-01 21:27
> From: "Peter Constable" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], ietf@ietf.org
> > Separating the specification
> > of language via a field from registration procedure was entirely
> > appropriate, as BCP documents are used for procedures and policies
> > and not
Bruce wrote:
---
No, you seem to have missed the point; there exist RFC 3066
implementations. Such implementations, using the RFC 3066 rules,
could match something like "sr-CS-Latn" to "sr-CS", but could
not match "sr-Latn-CS" to "sr-CS". By changing the definition of
the interpretation of the sec
> Date: 2004-12-30 07:26
> From: "Peter Constable" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], ietf@ietf.org
>
> > From: [EMAIL PROTECTED] [mailto:ietf-languages-
> > [EMAIL PROTECTED] On Behalf Of Bruce Lilly
>
>
> > So why not then also throw in the closely linked specification of
> > the
> Date: 2004-12-30 10:46
> From: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]>
> To: "Peter Constable" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], ietf@ietf.org
> 1. OSI 3166 is refered to. RFC 1591 should. RFC 1591 introduces differences
> (we all live with) with OSI 3166 which is taken as a referenc
> Date: 2004-12-30 16:02
> From: Tex Texin <[EMAIL PROTECTED]>
> To:
> CC: [EMAIL PROTECTED], ietf@ietf.org
>
> As the number of question marks, exclamation marks, asterisks and other forms
> of expressing digital shock and awe increase with each mail, I would like to
> suggest a temporary c
)
âMark
- Original Message -
From: "Frank Ellermann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, December 29, 2004 21:55
Subject: Re: draft-phillips-langtags-08, process, specifications,
"stability", and extensions
> Addison Phil
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
> So why not then also throw in the closely linked specification of
> the Content-Language field, which has historically been in the same
> document (RFC 1766)?
It was removed in the development of RFC
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
> > Do what you feel is warranted, Bruce. You don't appear to be trying to
> achieve consensus, which is the touchstone of the IETF process as I
> understand it. If you feel issues should be taken to th
> Date: 2004-12-29 17:45
> From: "Addison Phillips [wM]" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], ietf@ietf.org
> Reply to: [EMAIL PROTECTED]
>
> Comments below. I must admit that I'm losing the ability to respond to this
> thread, since it contains direct statements that no response wil
@ietf.org
> Subject: Re: draft-phillips-langtags-08, process, specifications,
> "stability",and extensions (Was Language Identifier List Comments,
> updated)
>
>
> > RE: Language Identifier List Comments, updated
> > Date: 2004-12-28 18:22
> > From
Dear Bruce,
I agree with your comments. I understand that most come from the uncertain
nature of this mailing list, ambiguously positionned between the IETF and
the W3C. I commented that to Misha. Now, this might be different if an IETF
WG was created, this mailing list could comment the propose
> RE: Language Identifier List Comments, updated
> Date: 2004-12-28 18:22
> From: "Addison Phillips [wM]" <[EMAIL PROTECTED]>
> To: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]>, "John Cowan" <[EMAIL
> PROTECTED]>
> CC: [EMAIL PROTECTED]
> The draft isn't a process draft. Take your process problem
26 matches
Mail list logo
