From ltru-bounces@ietf.org Sat Apr 01 13:31:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPkt8-0002QO-Q0; Sat, 01 Apr 2006 13:31:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPkt7-0002QJ-Ej for ltru@ietf.org; Sat, 01 Apr 2006 13:31:53 -0500 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPkt6-0002jz-3p for ltru@ietf.org; Sat, 01 Apr 2006 13:31:53 -0500 Received: from duringpersonlx (snvvpn1-10-72-72-c10.corp.yahoo.com [10.72.72.10]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k31IVQ64027114; Sat, 1 Apr 2006 10:31:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=ZHgyYlV/OF5ABiWZ/9iqs42TXYDi8ag84nBljQVrWZD1W82I9aA228P9tjTfIK8w From: "Addison Phillips" To: "'Mark Davis'" Subject: RE: [Ltru] conformance requirements for matching Date: Sat, 1 Apr 2006 10:33:29 -0800 Message-ID: <000001c655ba$c69724f0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <442DF074.4010107@icu-project.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZVOrA+kb2KshGkTtanbMNIuWq4zwAfp1zw X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > I disagree with the wholesale removal. I think it is perfectly > reasonable for someone to claim conformance with additional > qualifications. That is done in quite a few other specifications. I agree (although maybe we were discussing different text?!?), but think = the problem is trying to rework the text as it stands rather than spell = out implementation-chosen detail. The problem with the current text is = that it makes interoperability more difficult. The text currently says: -- The types of matching in this document are designed so that = implementations are not required to validate or understand any of the = semantics of the language tags or ranges or of the subtags in them. None = of them require access to the IANA Language Subtag Registry (see Section = 3 in [RFC3066bis]). This simplifies implementation. Applications, = protocols, or specifications MUST NOT depend on the language ranges = being "well-formed" or "valid" (see [RFC3066bis], Section 2.2.9). Regardless of the matching scheme chosen, protocols and implementations = MAY canonicalize language tags and ranges by mapping grandfathered and = obsolete tags or subtags into modern equivalents. If an implementation = canonicalizes either ranges or tags, then the implementation will = require the IANA Language Subtag Registry information for that purpose. = Implementations MAY also use semantic information external to the = registry when matching tags. For example, the primary language subtags = 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) might both be = usefully matched to the more general subtag 'no' (Norwegian). Or an = implementation might infer that content labeled "zh-Hans" (Chinese as = written in the Simplified script) is more likely to match the range = "zh-CN" (Chinese as used in China, where the Simplified script is = predominant) than equivalent content labeled "zh-TW" (Chinese as used in = Taiwan, where the Traditional script is predominant). -- Instead of this, I propose: -- The matching schemes in this document do not require an = implementation to validate or understand any of the semantics of the = language tags or ranges or of the subtags in them, nor do they require = access to the IANA Language Subtag Registry (see Section 3 in ). This simplifies implementation. However, applications, protocols, or specifications are encouraged to = use information in the IANA Language Subtag Registry to canonicalize = language tags and ranges, mapping grandfathered and obsolete tags or = subtags into modern equivalents. Such an implementation MAY also use = semantic information contained in the tags to augment matching. For example, the primary language subtags 'nn' (Nynorsk Norwegian) = and 'nb' (Bokmal Norwegian) might both be usefully matched to the more = general subtag 'no' (Norwegian). Or an implementation might infer that = content labeled "zh-Hans" (Chinese as written in the Simplified script) = is more likely to match the range "zh-CN" (Chinese as used in China, = where the Simplified script is predominant) than equivalent content = labeled "zh-TW" (Chinese as used in Taiwan, where the Traditional script = is predominant). -- Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B43=E6=9C=8831=E6=97=A5 19:16 > To: Addison Phillips > Cc: 'Randy Presuhn'; 'LTRU Working Group' > Subject: Re: [Ltru] conformance requirements for matching >=20 > I disagree with the wholesale removal. I think it is perfectly > reasonable for someone to claim conformance with additional > qualifications. That is done in quite a few other specifications. >=20 > For example, I think it is perfectly reasonable to state the = following. >=20 > The implementation is conformant to RFC xxx Lookup, with the following > extensions: > - default content matches the default locale as specified in > setDefaultLocale() > - closely related variants, such as no, nn, nb, fallback to each other > first, before resorting to the default content. The exact mapping is > found with getVariantFallbacks(). >=20 > Mark >=20 > Addison Phillips wrote: > >> This would be absurd, and this text should be removed. > >> > > > > I have no problem with removing that text. > > > > > >> In its current form, it's not even clear how a protocol = specification > >> referencing this document is supposed to identify the portions of = the > >> matching specification it employs. > >> > > > > This I don't understand. There are three mechanisms. They are = clearly > named and identified. What would you suggest we do differently in the = text > to make implementation decisions clear? > > > > There are clearly a large number of potential applications that can = use > these schemes (ranging from language negotiation of web pages to = applying > styles to paragraphs to selecting content in a database). The actual > protocol or application has to define how the scheme chosen works in = the > context of this higher level application of matching. Specifically, = I'd > refer you to Harald's comment: > > > > http://article.gmane.org/gmane.ietf.ltru/4180/match=3Dprotocol > > > > (The text suggested in this message appears in Section 3.1) > > > > Can you identify examples of what the problem is? I have no idea how = we > would address this. > > > > > >> As a WG chair and as an I-D author / editor I know how frustrating > >> very general comments can be > >> > > > > Yeah. And you saved one for the last day of the Last Call too :-). > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > > > > >> -----Original Message----- > >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > >> Sent: 2006=E5=B9=B43=E6=9C=8830=E6=97=A5 13:41 > >> To: LTRU Working Group > >> Subject: [Ltru] conformance requirements for matching > >> > >> > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 01 19:54:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPqrM-0003Ld-9D; Sat, 01 Apr 2006 19:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPqrK-0003LY-EH for ltru@ietf.org; Sat, 01 Apr 2006 19:54:26 -0500 Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPqrJ-0000mN-6t for ltru@ietf.org; Sat, 01 Apr 2006 19:54:26 -0500 Received: from h-68-166-189-183.snvacaid.dynamic.covad.net ([68.166.189.183] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FPqrI-0002vV-00 for ltru@ietf.org; Sat, 01 Apr 2006 19:54:24 -0500 Message-ID: <001401c655f0$681ed180$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001901c65447$1b1b4120$f4fa15ac@ds.corp.yahoo.com> <442DF074.4010107@icu-project.org> Subject: Re: [Ltru] conformance requirements for matching Date: Sat, 1 Apr 2006 16:57:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Addison Phillips" > Cc: "'Randy Presuhn'" ; "'LTRU Working Group'" > Sent: Friday, March 31, 2006 7:16 PM > Subject: Re: [Ltru] conformance requirements for matching > > I disagree with the wholesale removal. I think it is perfectly > reasonable for someone to claim conformance with additional > qualifications. That is done in quite a few other specifications. > > For example, I think it is perfectly reasonable to state the following. > > The implementation is conformant to RFC xxx Lookup, with the following > extensions: > - default content matches the default locale as specified in > setDefaultLocale() > - closely related variants, such as no, nn, nb, fallback to each other > first, before resorting to the default content. The exact mapping is > found with getVariantFallbacks(). ... But the current text isn't just about extensions. Section three says: There are several types of matching scheme. This document presents two types: those that produce zero or more information items (called "filtering") and those that produce a single information item for a given request (called "lookup"). Implementations or protocols MAY use different matching schemes from the ones described in this document, as long as those mechanisms are clearly specified. It doesn't talk about extensions or augmentations or "additional qualifications." It says "different". That is *far* too loose. Furthermore, even if we do permit conformant implementations to have extensions, there needs to be some way of ensuring that they don't affect interoperability. If they do, then they defeat the whole point of claiming conformance to a specification. I don't care whether implementations support other algorithms, but when they claim to support one from this document, the observable behaviour must be exactly what is specified here, within the "wiggle room" of the defined options. Implementations might do other things as well, but those are outside the scope of this specification, and we really don't need to talk about them. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 03 16:16:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVTn-0002xM-HT; Mon, 03 Apr 2006 16:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVTm-0002xH-Br for ltru@ietf.org; Mon, 03 Apr 2006 16:16:50 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVTk-0003Bx-Sg for ltru@ietf.org; Mon, 03 Apr 2006 16:16:50 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k33KF95H002048; Mon, 3 Apr 2006 13:15:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=KiHGm7l5eaFarTtXNc/JyJL0EN3rWPrRZa26lbqUi18E1GhZNv0eujffgPE3tJzI From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] conformance requirements for matching Date: Mon, 3 Apr 2006 13:17:09 -0700 Message-ID: <000a01c6575b$9633b790$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <001401c655f0$681ed180$6401a8c0@oemcomputer> Thread-Index: AcZV8At+pW6Gz7T1QgSh1s/6i97t0wBX8N1w X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Okay... in the interest of expediency, I have implemented a bunch of = edits in the Editor's copy of draft-12 in an attempt to bring both sides = of this discussion together. I tried to quote them all in an email, but = the rewrites involved a lot of paragraphs of text. It is easier to view = the diff and see what I changed. http://www.inter-locale.com/ID/matching-diff-11-12.html The notable differences are: 1. Insertion of the "seems to imply" text into Section 2.1 2. A complete rewrite of the text describing the mapping of extended = language ranges to basic ones in Section 2.2 3. Upgrading of SHOULD to MUST in conformance requirements and = elimination of the text allowing unspecified algorithms to be used in = Section 3.0 4. A total rewrite of the material about canonicalization of tags/ranges = and understanding the semantics of language tags in Section 3.1 5. A full rewrite of Section 3.2.2 (Extended Filtering) to include a = step-by-step algorithm. 6. Insertion of Martin's text at the end of 3.2.2 7. A number of changes to Section 3.3 (Lookup) to make the return of = default content a requirement and to be specific that implementations = specify what the content is and how it is arrived at. 8. A rewrite of the text on extensions in Section 3.3 to make it more = specific. 9. Removed the SHOULDs in the paragraph about the range "*" in Section = 3.3 (this makes the specified behavior obligatory). 10. Added Martin's texts to Section 4.1 on subtag selection. 11. Removed the application specific directions in Section 4.1. One of = these makes a modified reappearance in Section 3.2.2 as part of the text = about removing extensions. Randy, Mark (and anyone else who cares): you comments on the relevant = changes would be most appreciated. Obviously the diff shows everything. Since substantive changes were = made, does this mean another trek through WG Last Call? Also, should I = publish this as draft-12? Martin: what is the process from here? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2006=E5=B9=B44=E6=9C=881=E6=97=A5 16:57 > To: LTRU Working Group > Subject: Re: [Ltru] conformance requirements for matching >=20 > Hi - >=20 > > From: "Mark Davis" > > To: "Addison Phillips" > > Cc: "'Randy Presuhn'" ; "'LTRU Working > Group'" > > Sent: Friday, March 31, 2006 7:16 PM > > Subject: Re: [Ltru] conformance requirements for matching > > > > I disagree with the wholesale removal. I think it is perfectly > > reasonable for someone to claim conformance with additional > > qualifications. That is done in quite a few other specifications. > > > > For example, I think it is perfectly reasonable to state the = following. > > > > The implementation is conformant to RFC xxx Lookup, with the = following > > extensions: > > - default content matches the default locale as specified in > > setDefaultLocale() > > - closely related variants, such as no, nn, nb, fallback to each = other > > first, before resorting to the default content. The exact mapping is > > found with getVariantFallbacks(). > ... >=20 > But the current text isn't just about extensions. Section three says: >=20 > There are several types of matching scheme. This document presents > two types: those that produce zero or more information items = (called > "filtering") and those that produce a single information item for a > given request (called "lookup"). >=20 > Implementations or protocols MAY use different matching schemes = from > the ones described in this document, as long as those mechanisms = are > clearly specified. >=20 > It doesn't talk about extensions or augmentations or > "additional qualifications." >=20 > It says "different". >=20 > That is *far* too loose. >=20 > Furthermore, even if we do permit conformant implementations to have > extensions, there needs to be some way of ensuring that they don't > affect interoperability. If they do, then they defeat the whole > point of claiming conformance to a specification. >=20 > I don't care whether implementations support other algorithms, but = when > they claim to support one from this document, the observable behaviour > must be exactly what is specified here, within the "wiggle room" of > the defined options. Implementations might do other things as well, > but those are outside the scope of this specification, and we really > don't need to talk about them. >=20 > Randy >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 03 16:26:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVcn-0001vr-9v; Mon, 03 Apr 2006 16:26:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVcl-0001vm-G8 for ltru@ietf.org; Mon, 03 Apr 2006 16:26:07 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVci-0003nk-85 for ltru@ietf.org; Mon, 03 Apr 2006 16:26:07 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FQVch-0003Il-VV; Mon, 03 Apr 2006 16:26:04 -0400 Date: Mon, 3 Apr 2006 16:26:03 -0400 To: Addison Phillips Subject: Re: [Ltru] conformance requirements for matching Message-ID: <20060403202603.GA6647@ccil.org> References: <001401c655f0$681ed180$6401a8c0@oemcomputer> <000a01c6575b$9633b790$9fcd15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000a01c6575b$9633b790$9fcd15ac@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Okay... in the interest of expediency, I have implemented a bunch of > edits in the Editor's copy of draft-12 in an attempt to bring both > sides of this discussion together. I tried to quote them all in an > email, but the rewrites involved a lot of paragraphs of text. It is > easier to view the diff and see what I changed. +1. I have no further comments. -- The experiences of the past show John Cowan that there has always been a discrepancy cowan@ccil.org between plans and performance. http://www.ap.org --Emperor Hirohito, August 1945 http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 03 18:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXRt-0001dW-RI; Mon, 03 Apr 2006 18:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXRs-0001U2-CT for ltru@ietf.org; Mon, 03 Apr 2006 18:23:00 -0400 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQXRr-0000kp-1z for ltru@ietf.org; Mon, 03 Apr 2006 18:23:00 -0400 Received: (qmail 93148 invoked from network); 3 Apr 2006 22:22:58 -0000 Received: from unknown (HELO ?172.24.99.232?) (unknown) by unknown with SMTP; 3 Apr 2006 22:22:58 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <4431A038.7090507@icu-project.org> Date: Mon, 03 Apr 2006 15:22:48 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] conformance requirements for matching References: <000a01c6575b$9633b790$9fcd15ac@ds.corp.yahoo.com> In-Reply-To: <000a01c6575b$9633b790$9fcd15ac@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This might be an artifact of the diff, but looks like a typo. > (see: ). Other than that, I like the rewrite. +1 Mark Addison Phillips wrote: > Okay... in the interest of expediency, I have implemented a bunch of edits in the Editor's copy of draft-12 in an attempt to bring both sides of this discussion together. I tried to quote them all in an email, but the rewrites involved a lot of paragraphs of text. It is easier to view the diff and see what I changed. > > http://www.inter-locale.com/ID/matching-diff-11-12.html > > The notable differences are: > > 1. Insertion of the "seems to imply" text into Section 2.1 > > 2. A complete rewrite of the text describing the mapping of extended language ranges to basic ones in Section 2.2 > > 3. Upgrading of SHOULD to MUST in conformance requirements and elimination of the text allowing unspecified algorithms to be used in Section 3.0 > > 4. A total rewrite of the material about canonicalization of tags/ranges and understanding the semantics of language tags in Section 3.1 > > 5. A full rewrite of Section 3.2.2 (Extended Filtering) to include a step-by-step algorithm. > > 6. Insertion of Martin's text at the end of 3.2.2 > > 7. A number of changes to Section 3.3 (Lookup) to make the return of default content a requirement and to be specific that implementations specify what the content is and how it is arrived at. > > 8. A rewrite of the text on extensions in Section 3.3 to make it more specific. > > 9. Removed the SHOULDs in the paragraph about the range "*" in Section 3.3 (this makes the specified behavior obligatory). > > 10. Added Martin's texts to Section 4.1 on subtag selection. > > 11. Removed the application specific directions in Section 4.1. One of these makes a modified reappearance in Section 3.2.2 as part of the text about removing extensions. > > Randy, Mark (and anyone else who cares): you comments on the relevant changes would be most appreciated. > > Obviously the diff shows everything. Since substantive changes were made, does this mean another trek through WG Last Call? Also, should I publish this as draft-12? Martin: what is the process from here? > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> Sent: 2006å¹´4月1æ—¥ 16:57 >> To: LTRU Working Group >> Subject: Re: [Ltru] conformance requirements for matching >> >> Hi - >> >> >>> From: "Mark Davis" >>> To: "Addison Phillips" >>> Cc: "'Randy Presuhn'" ; "'LTRU Working >>> >> Group'" >> >>> Sent: Friday, March 31, 2006 7:16 PM >>> Subject: Re: [Ltru] conformance requirements for matching >>> >>> I disagree with the wholesale removal. I think it is perfectly >>> reasonable for someone to claim conformance with additional >>> qualifications. That is done in quite a few other specifications. >>> >>> For example, I think it is perfectly reasonable to state the following. >>> >>> The implementation is conformant to RFC xxx Lookup, with the following >>> extensions: >>> - default content matches the default locale as specified in >>> setDefaultLocale() >>> - closely related variants, such as no, nn, nb, fallback to each other >>> first, before resorting to the default content. The exact mapping is >>> found with getVariantFallbacks(). >>> >> ... >> >> But the current text isn't just about extensions. Section three says: >> >> There are several types of matching scheme. This document presents >> two types: those that produce zero or more information items (called >> "filtering") and those that produce a single information item for a >> given request (called "lookup"). >> >> Implementations or protocols MAY use different matching schemes from >> the ones described in this document, as long as those mechanisms are >> clearly specified. >> >> It doesn't talk about extensions or augmentations or >> "additional qualifications." >> >> It says "different". >> >> That is *far* too loose. >> >> Furthermore, even if we do permit conformant implementations to have >> extensions, there needs to be some way of ensuring that they don't >> affect interoperability. If they do, then they defeat the whole >> point of claiming conformance to a specification. >> >> I don't care whether implementations support other algorithms, but when >> they claim to support one from this document, the observable behaviour >> must be exactly what is specified here, within the "wiggle room" of >> the defined options. Implementations might do other things as well, >> but those are outside the scope of this specification, and we really >> don't need to talk about them. >> >> Randy >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 03 19:09:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQYAu-0000aw-0Y; Mon, 03 Apr 2006 19:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQYAs-0000ZE-S8 for ltru@ietf.org; Mon, 03 Apr 2006 19:09:30 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQYAr-0002s1-Ao for ltru@ietf.org; Mon, 03 Apr 2006 19:09:30 -0400 Received: from duringpersonlx (wlanvpn-abc-233-87.corp.yahoo.com [172.21.233.87]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k33N75Dj064019; Mon, 3 Apr 2006 16:07:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=CMnCOLV3Q64SHyrqqAwz0yjSQGa4PC0J2p3oURINsi46lCsMbboOvkPdBLC2g8+B From: "Addison Phillips" To: "'Mark Davis'" Subject: RE: [Ltru] conformance requirements for matching Date: Mon, 3 Apr 2006 16:08:59 -0700 Message-ID: <002701c65773$9752cf40$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <4431A038.7090507@icu-project.org> Thread-Index: AcZXbTDkLh9ttDdlSiumb5+EUBI5DwABi3EA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > This might be an artifact of the diff, but looks like a typo. >=20 > > (see: ). Good catch. It's a typo: the format attribute of the xref is set to "none" instead = of "default" or "title". I've fixed it in my local copy and will post it = when I get a chance later tonight. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B44=E6=9C=883=E6=97=A5 15:23 > To: Addison Phillips > Cc: 'Randy Presuhn'; 'LTRU Working Group' > Subject: Re: [Ltru] conformance requirements for matching >=20 > This might be an artifact of the diff, but looks like a typo. >=20 > > (see: ). >=20 > Other than that, I like the rewrite. +1 > Mark >=20 > Addison Phillips wrote: > > Okay... in the interest of expediency, I have implemented a bunch of > edits in the Editor's copy of draft-12 in an attempt to bring both = sides > of this discussion together. I tried to quote them all in an email, = but > the rewrites involved a lot of paragraphs of text. It is easier to = view > the diff and see what I changed. > > > > http://www.inter-locale.com/ID/matching-diff-11-12.html > > > > The notable differences are: > > > > 1. Insertion of the "seems to imply" text into Section 2.1 > > > > 2. A complete rewrite of the text describing the mapping of extended > language ranges to basic ones in Section 2.2 > > > > 3. Upgrading of SHOULD to MUST in conformance requirements and > elimination of the text allowing unspecified algorithms to be used in > Section 3.0 > > > > 4. A total rewrite of the material about canonicalization of = tags/ranges > and understanding the semantics of language tags in Section 3.1 > > > > 5. A full rewrite of Section 3.2.2 (Extended Filtering) to include a > step-by-step algorithm. > > > > 6. Insertion of Martin's text at the end of 3.2.2 > > > > 7. A number of changes to Section 3.3 (Lookup) to make the return of > default content a requirement and to be specific that implementations > specify what the content is and how it is arrived at. > > > > 8. A rewrite of the text on extensions in Section 3.3 to make it = more > specific. > > > > 9. Removed the SHOULDs in the paragraph about the range "*" in = Section > 3.3 (this makes the specified behavior obligatory). > > > > 10. Added Martin's texts to Section 4.1 on subtag selection. > > > > 11. Removed the application specific directions in Section 4.1. One = of > these makes a modified reappearance in Section 3.2.2 as part of the = text > about removing extensions. > > > > Randy, Mark (and anyone else who cares): you comments on the = relevant > changes would be most appreciated. > > > > Obviously the diff shows everything. Since substantive changes were = made, > does this mean another trek through WG Last Call? Also, should I = publish > this as draft-12? Martin: what is the process from here? > > > > Addison > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > > > > >> -----Original Message----- > >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > >> Sent: 2006=E5=B9=B44=E6=9C=881=E6=97=A5 16:57 > >> To: LTRU Working Group > >> Subject: Re: [Ltru] conformance requirements for matching > >> > >> Hi - > >> > >> > >>> From: "Mark Davis" > >>> To: "Addison Phillips" > >>> Cc: "'Randy Presuhn'" ; "'LTRU = Working > >>> > >> Group'" > >> > >>> Sent: Friday, March 31, 2006 7:16 PM > >>> Subject: Re: [Ltru] conformance requirements for matching > >>> > >>> I disagree with the wholesale removal. I think it is perfectly > >>> reasonable for someone to claim conformance with additional > >>> qualifications. That is done in quite a few other specifications. > >>> > >>> For example, I think it is perfectly reasonable to state the = following. > >>> > >>> The implementation is conformant to RFC xxx Lookup, with the = following > >>> extensions: > >>> - default content matches the default locale as specified in > >>> setDefaultLocale() > >>> - closely related variants, such as no, nn, nb, fallback to each = other > >>> first, before resorting to the default content. The exact mapping = is > >>> found with getVariantFallbacks(). > >>> > >> ... > >> > >> But the current text isn't just about extensions. Section three = says: > >> > >> There are several types of matching scheme. This document = presents > >> two types: those that produce zero or more information items = (called > >> "filtering") and those that produce a single information item = for a > >> given request (called "lookup"). > >> > >> Implementations or protocols MAY use different matching schemes = from > >> the ones described in this document, as long as those mechanisms = are > >> clearly specified. > >> > >> It doesn't talk about extensions or augmentations or > >> "additional qualifications." > >> > >> It says "different". > >> > >> That is *far* too loose. > >> > >> Furthermore, even if we do permit conformant implementations to = have > >> extensions, there needs to be some way of ensuring that they don't > >> affect interoperability. If they do, then they defeat the whole > >> point of claiming conformance to a specification. > >> > >> I don't care whether implementations support other algorithms, but = when > >> they claim to support one from this document, the observable = behaviour > >> must be exactly what is specified here, within the "wiggle room" of > >> the defined options. Implementations might do other things as = well, > >> but those are outside the scope of this specification, and we = really > >> don't need to talk about them. > >> > >> Randy > >> > >> > >> _______________________________________________ > >> Ltru mailing list > >> Ltru@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ltru > >> > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 03:48:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgHK-0003Fz-MM; Tue, 04 Apr 2006 03:48:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgHJ-00037j-Da for ltru@ietf.org; Tue, 04 Apr 2006 03:48:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQfF7-0005Yw-FC for ltru@ietf.org; Tue, 04 Apr 2006 02:42:21 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FQeyI-0007Ev-55 for ltru@ietf.org; Tue, 04 Apr 2006 02:25:00 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k346Ojd03318; Tue, 4 Apr 2006 15:24:45 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 29a5_b551b60e_c3a3_11da_80c8_0014221fa3c9; Tue, 04 Apr 2006 15:24:44 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k346NOjZ031989; Tue, 4 Apr 2006 15:24:05 +0900 Message-Id: <6.0.0.20.2.20060404150502.091358e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 04 Apr 2006 15:23:06 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] conformance requirements for matching In-Reply-To: <001401c655f0$681ed180$6401a8c0@oemcomputer> References: <001901c65447$1b1b4120$f4fa15ac@ds.corp.yahoo.com> <442DF074.4010107@icu-project.org> <001401c655f0$681ed180$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat off] I was glad we cut back the spec to elimitate the too many options we gave users. Now Randy is saying that there are still too many options. At 09:57 06/04/02, Randy Presuhn wrote: >> From: "Mark Davis" >> For example, I think it is perfectly reasonable to state the following. >> >> The implementation is conformant to RFC xxx Lookup, with the following >> extensions: >> - default content matches the default locale as specified in >> setDefaultLocale() >> - closely related variants, such as no, nn, nb, fallback to each other >> first, before resorting to the default content. The exact mapping is >> found with getVariantFallbacks(). >... Very good. If we were not already at this stage, and maybe even at this stage, I'd propose that we work out a few more such examples of how to specify specifics (using specification rather than implementation in some examples). This is a very useful exercise, and might also make a nice addition to our document (e.g. in an Appendix). Mark, you seem to be good at these things, any other proposals? Anybody else? >But the current text isn't just about extensions. Section three says: > Implementations or protocols MAY use different matching schemes from > the ones described in this document, as long as those mechanisms are > clearly specified. >It says "different". > >That is *far* too loose. I think this language got here in part due to the fact that we are (part of a) BCP, and in part because some of the WG members (including at least me) didn't think that a sentence in a spec along the lines of "hey, there may be other ways to do what we do here, this may not be the only one" would be interpreted as "I can claim that I'm conforming even if I don't do anything of what this spec says.". >Furthermore, even if we do permit conformant implementations to have >extensions, there needs to be some way of ensuring that they don't >affect interoperability. If they do, then they defeat the whole >point of claiming conformance to a specification. Again, we are (part of) a BCP. In that sense, I see it as the document's main job to say "given the language tags in RFC 3066bis, here is we think how it makes most sense to match them for filtering and lookup". I do not currently see much of an interoperability problem. First, we have an additional layer of actual specifications. It is ultimately not our document, but specs such as HTTP, SMTP, POP, IMAP, CSS, XSLT, whatever,... that define what implementations have to do. If these specs actually choose the options we give them, they should lead to interoperable implementations (for each spec). We could try to achieve interoperability on a wider level. Our goal could be to make sure that users have portable (not only among implementations, but also among specs/protocols) language preferences, and content can be portably (same as above) used. But as I have explained in my last call comments, for a case such as zh/zh-Hans/zh-Hant, we already have blown that as soon as we both offer filtering and lookup. Also, regarding options, I'm not affraid to leave options open for specs to fix. The main criterion I personally care about is not whether we are totally precise, but to what extent giving options to other spec writers will help them get the best solution for their case, and to what extent it will get them into troubles because they have no clue which option to choose. Regards, Martin. >I don't care whether implementations support other algorithms, but when >they claim to support one from this document, the observable behaviour >must be exactly what is specified here, within the "wiggle room" of >the defined options. Implementations might do other things as well, >but those are outside the scope of this specification, and we really >don't need to talk about them. > >Randy > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 13:10:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp2r-0008Ii-R8; Tue, 04 Apr 2006 13:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp2q-0008Fq-4u for ltru@ietf.org; Tue, 04 Apr 2006 13:10:20 -0400 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQp2p-00089a-Rt for ltru@ietf.org; Tue, 04 Apr 2006 13:10:20 -0400 Received: (qmail 49398 invoked from network); 4 Apr 2006 17:10:19 -0000 Received: from unknown (HELO ?172.24.99.232?) (unknown) by unknown with SMTP; 4 Apr 2006 17:10:19 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <4432A85D.9090801@icu-project.org> Date: Tue, 04 Apr 2006 10:09:49 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] conformance requirements for matching References: <001901c65447$1b1b4120$f4fa15ac@ds.corp.yahoo.com> <442DF074.4010107@icu-project.org> <001401c655f0$681ed180$6401a8c0@oemcomputer> <6.0.0.20.2.20060404150502.091358e0@localhost> In-Reply-To: <6.0.0.20.2.20060404150502.091358e0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison's revised text (see from yesterday) is fine by me. Mark Martin Duerst wrote: > [co-chair hat off] > > I was glad we cut back the spec to elimitate the too many options > we gave users. Now Randy is saying that there are still too many > options. > > At 09:57 06/04/02, Randy Presuhn wrote: > > >> From: "Mark Davis" > > >> For example, I think it is perfectly reasonable to state the > following. > >> > >> The implementation is conformant to RFC xxx Lookup, with the following > >> extensions: > >> - default content matches the default locale as specified in > >> setDefaultLocale() > >> - closely related variants, such as no, nn, nb, fallback to each other > >> first, before resorting to the default content. The exact mapping is > >> found with getVariantFallbacks(). > >... > > Very good. If we were not already at this stage, and maybe even > at this stage, I'd propose that we work out a few more such examples > of how to specify specifics (using specification rather than > implementation > in some examples). This is a very useful exercise, and might also make > a nice addition to our document (e.g. in an Appendix). > > Mark, you seem to be good at these things, any other proposals? > Anybody else? > > >But the current text isn't just about extensions. Section three says: > > > Implementations or protocols MAY use different matching schemes from > > the ones described in this document, as long as those mechanisms are > > clearly specified. > > >It says "different". > > > >That is *far* too loose. > > I think this language got here in part due to the fact that we are > (part of a) BCP, and in part because some of the WG members > (including at least me) didn't think that a sentence in a spec > along the lines of "hey, there may be other ways to do what we > do here, this may not be the only one" would be interpreted as > "I can claim that I'm conforming even if I don't do anything of > what this spec says.". > > > >Furthermore, even if we do permit conformant implementations to have > >extensions, there needs to be some way of ensuring that they don't > >affect interoperability. If they do, then they defeat the whole > >point of claiming conformance to a specification. > > Again, we are (part of) a BCP. In that sense, I see it as the > document's main job to say "given the language tags in RFC 3066bis, > here is we think how it makes most sense to match them for > filtering and lookup". > > I do not currently see much of an interoperability problem. > First, we have an additional layer of actual specifications. > It is ultimately not our document, but specs such as HTTP, > SMTP, POP, IMAP, CSS, XSLT, whatever,... that define what > implementations have to do. If these specs actually choose > the options we give them, they should lead to interoperable > implementations (for each spec). > > We could try to achieve interoperability on a wider level. > Our goal could be to make sure that users have portable > (not only among implementations, but also among specs/protocols) > language preferences, and content can be portably (same as above) > used. But as I have explained in my last call comments, for a > case such as zh/zh-Hans/zh-Hant, we already have blown that > as soon as we both offer filtering and lookup. > > > Also, regarding options, I'm not affraid to leave options open > for specs to fix. The main criterion I personally care about is > not whether we are totally precise, but to what extent giving > options to other spec writers will help them get the best > solution for their case, and to what extent it will get them > into troubles because they have no clue which option to choose. > > > Regards, Martin. > > > >I don't care whether implementations support other algorithms, but when > >they claim to support one from this document, the observable behaviour > >must be exactly what is specified here, within the "wiggle room" of > >the defined options. Implementations might do other things as well, > >but those are outside the scope of this specification, and we really > >don't need to talk about them. > > > >Randy > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 14:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqTe-0002ln-05; Tue, 04 Apr 2006 14:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqTd-0002li-Jy for ltru@ietf.org; Tue, 04 Apr 2006 14:42:05 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQqTa-0003Qm-AO for ltru@ietf.org; Tue, 04 Apr 2006 14:42:05 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id 61F811E1347; Tue, 4 Apr 2006 11:41:59 -0700 (PDT) Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23569-11-2; Tue, 4 Apr 2006 11:41:57 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 246711E1349; Tue, 4 Apr 2006 11:41:57 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Apr 2006 11:41:57 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EDB3@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'LTRU Working Group' Date: Tue, 4 Apr 2006 11:41:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Virus-Scanned: amavisd-new at sharplabs.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] Link to revised Editor's copy??? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Addison, First, I applaud any rewrites to make conformance claims more specific and meaningful - thanks Randy! Based on a note you sent last week, I just downloaded: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12.xml Which are dated 1 April 2006 - are these your updated copies? ^^^^^^^^^^^^ The HTML page index at 'http://www.inter-locale.com/ID/' is wildly out-of-date for the matching document. My apologies for not reviewing in detail during the last call. I'm stuck in two printing standards meetings this week and next week. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: 4/4/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 14:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqcF-0000QI-Hg; Tue, 04 Apr 2006 14:50:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqcD-0000Pv-Uo for ltru@ietf.org; Tue, 04 Apr 2006 14:50:57 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQqcC-0003jD-Kb for ltru@ietf.org; Tue, 04 Apr 2006 14:50:57 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k34InLZF096338; Tue, 4 Apr 2006 11:49:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=08FiDBVTw+GnMrNliJdAi/HTs4T2BqpGQC7DTYNnssDwBrDYU12cvZ2cJRDwWqHG From: "Addison Phillips" To: "'McDonald, Ira'" , "'LTRU Working Group'" Date: Tue, 4 Apr 2006 11:51:19 -0700 Message-ID: <000801c65818$c27e6300$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EDB3@mailsrvnt05.enet.sharplabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZYF4B/PbxmDgvFQIuTenJ0A/s04AAAL+hw X-Spam-Score: -15.0 (---------------) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] RE: Link to revised Editor's copy??? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > The HTML page index at 'http://www.inter-locale.com/ID/' is wildly > out-of-date for the matching document. The home page, however, isn't "wildly out of date". The "HTML page index" is sporadically maintained: don't look at it. Look at http://www.inter-locale.com . It currently says the editor's copy date is 3 April 2006 (which is yesterday). The actual editor's copy posted is dated internally at 1 April 2006. The diff is an exact diff of the posted documents using the rfcdiff tool. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 15:17:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr2K-0006IY-S9; Tue, 04 Apr 2006 15:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr2K-0006IT-JT for ltru@ietf.org; Tue, 04 Apr 2006 15:17:56 -0400 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQr2J-0004W6-BV for ltru@ietf.org; Tue, 04 Apr 2006 15:17:56 -0400 Received: from h-68-165-6-16.snvacaid.dynamic.covad.net ([68.165.6.16] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FQr2I-0002OR-00 for ltru@ietf.org; Tue, 04 Apr 2006 15:17:54 -0400 Message-ID: <006c01c6581c$f0b8a880$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001901c65447$1b1b4120$f4fa15ac@ds.corp.yahoo.com> <442DF074.4010107@icu-project.org> <001401c655f0$681ed180$6401a8c0@oemcomputer> <6.0.0.20.2.20060404150502.091358e0@localhost> Subject: Re: [Ltru] conformance requirements for matching Date: Tue, 4 Apr 2006 12:21:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Martin Duerst" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Monday, April 03, 2006 11:23 PM > Subject: Re: [Ltru] conformance requirements for matching ... > Also, regarding options, I'm not affraid to leave options open > for specs to fix. The main criterion I personally care about is > not whether we are totally precise, but to what extent giving > options to other spec writers will help them get the best > solution for their case, and to what extent it will get them > into troubles because they have no clue which option to choose. ... I'm not arguing against options per se, though I'd be happy to do so. My point is we should provide a clear means for specifications using the BCP to identify the options used for each matching algorithm; and that we should make it clear which options must be nailed down by specifications using the BCP, and which options may be left entirely to implementations. For example, in the editor's copy (I'd rather reference the i-d, but in the interest of moving forward quickly I'll use the text at http://www.inter-locale.com/ID/matching-diff-11-12.html) it says: | Applications, protocols, or specifications that use basic ranges | might sometimes receive extended language ranges instead. An | application, protocol, or specification MUST choose to a) map | extended language ranges to basic ranges using the algorithm below, | b) skip over (or reject) any extended language ranges in the language | priority list that are not valid basic language ranges, or c) treat | each extended language range as if it were a basic language range | (these ranges will match *no* content). I think (b) as currently formulated overlaps (c). I'd suggest a slight reformulation as: b) reject any extended language ranges in the language priority list that are not valid basic language ranges, or c) treat each extended language range as if it were a basic language range, which will have the same result as ignoring them, since these ranges will match *no* content. In any event the text is an improvement over the previous version (though I'd strike the anthropomorphic "choose to"), but doesn't give a concise name or other way to refer to this particular set of options. I suggest: (1) that the paragraph cited above be made part of a new subsection, "2.2.1 Extended Language Range Compatibility Modes". (2) that the following sentence be added to the end of this paragraph: This choice of compatibility mode is to be documented as "map", "reject", and "ignore". Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 15:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQraN-0005bn-8w; Tue, 04 Apr 2006 15:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQraM-0005aQ-MQ for ltru@ietf.org; Tue, 04 Apr 2006 15:53:06 -0400 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQraL-0005xO-Ej for ltru@ietf.org; Tue, 04 Apr 2006 15:53:06 -0400 Received: from h-68-165-6-16.snvacaid.dynamic.covad.net ([68.165.6.16] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FQraK-0004Hu-00 for ltru@ietf.org; Tue, 04 Apr 2006 15:53:05 -0400 Message-ID: <007601c65821$dbdd0d20$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 4 Apr 2006 12:56:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ltru] Access to subtag registry by matching applications X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... In the editor's copy at http://www.inter-locale.com/ID/matching-diff-11-12.html the proposed text reads: | However, applications, protocols, or specifications are encouraged to | use information in the IANA Language Subtag Registry to canonicalize | language tags and ranges, mapping grandfathered and obsolete tags or | subtags into modern equivalents. Such an implementation MAY also use | semantic information contained in the tags to augment matching. I am concerned that the first sentence may be misconstrued as encouraging applications to access the subtag registry. This would be contrary to the WG's resolution of the concerns behind issue 968 https://rt.psg.com/Ticket/Display.html?id=968 (user "ietf", password "ietf", queue ltru-registry) Consequently, I suggest this minor tweak to the proposed text's first sentence: However, designers of applications, protocols, or specifications are encouraged to use information from the IANA Language Subtag Registry to support canonicalizing language tags and ranges, mapping grandfathered and obsolete tags or subtags into modern equivalents. Regarding the second sentence, I believe it goes beyond the scope of the algorithms defined by this BCP. I suggest the following replacement for the second sentence. The use of additional semantic information associated with subtags to augment matching is outside the scope of this memo. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 17:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQssU-0004yT-Jm; Tue, 04 Apr 2006 17:15:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQssS-0004vt-G0 for ltru@ietf.org; Tue, 04 Apr 2006 17:15:52 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQssR-0001WF-41 for ltru@ietf.org; Tue, 04 Apr 2006 17:15:52 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k34LEu4n020353; Tue, 4 Apr 2006 14:14:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=Jyy/TytSjxyshgAGwWcAdVGdFJ5SulNLwXy2wabOh8Ano/ftQy5L8KdBQThbyc0F From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] conformance requirements for matching Date: Tue, 4 Apr 2006 14:16:57 -0700 Message-ID: <000301c6582d$1afe64d0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <006c01c6581c$f0b8a880$6401a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZYHJNIgB5xeIzKQDe96gd4ACiXoQAD1GIQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Comments follow. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2006?4?4? 12:21 > > I'm not arguing against options per se, though I'd be happy to do so. If you do, try to be specific, please :-). > > For example, in the editor's copy (I'd rather reference the i-d, but in > the interest of moving forward quickly I'll use the text at > http://www.inter-locale.com/ID/matching-diff-11-12.html) it says: > > | Applications, protocols, or specifications that use basic ranges > | might sometimes receive extended language ranges instead. An > | application, protocol, or specification MUST choose to a) map > | extended language ranges to basic ranges using the algorithm below, > | b) skip over (or reject) any extended language ranges in the language > | priority list that are not valid basic language ranges, or c) treat > | each extended language range as if it were a basic language range > | (these ranges will match *no* content). > > I think (b) as currently formulated overlaps (c). I'd suggest a slight > reformulation as: > b) reject any extended language ranges in the language > priority list that are not valid basic language ranges, or c) treat > each extended language range as if it were a basic language range, > which will have the same result as ignoring them, since these ranges > will match *no* content. I don't quite see that. Skipping a range means not returning any content that might match that range. Rejecting a range might potentially be an error condition. Treating an extended language range as if it were a basic language range, by contrast, will cause the matching algorithm to attempt to match the content. Although the results should be the same, they might potentially not be. Nonetheless, your text is clearer than mine. I'll use yours. > > In any event the text is an improvement over the previous version > (though I'd strike the anthropomorphic "choose to"), but doesn't give > a concise name or other way to refer to this particular set of options. > I suggest: > (1) that the paragraph cited above be made part of a new subsection, > "2.2.1 Extended Language Range Compatibility Modes". That doesn't flow very nicely. Instead of that, why don't we put it where it belongs, as a new subsection following 3.1 and called "Implementation Considerations". This could also, then, include the last four paragraphs in the current S3.1. > (2) that the following sentence be added to the end of this paragraph: > This choice of compatibility mode is to be documented as "map", > "reject", and "ignore". > That's kind of icky. Let me play with it a bit. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 17:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQt6C-0003RY-UV; Tue, 04 Apr 2006 17:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQt6B-0003RS-M4 for ltru@ietf.org; Tue, 04 Apr 2006 17:30:03 -0400 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQt6A-00021F-E5 for ltru@ietf.org; Tue, 04 Apr 2006 17:30:03 -0400 Received: from h-68-165-6-16.snvacaid.dynamic.covad.net ([68.165.6.16] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FQt69-0006VI-00 for ltru@ietf.org; Tue, 04 Apr 2006 17:30:01 -0400 Message-ID: <007e01c6582f$674acb60$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 4 Apr 2006 14:33:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Ltru] ohterwises in procedure X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - I found it difficult to figure out the nesting of the ifs and otherwises in this proposed text in http://www.inter-locale.com/ID/matching-diff-11-12.html: 3. While there are more subtags left in the language range's list: A. If the subtag currently being examined in the range is the wildcard ('*'), move to the next subtag in the range until a non-wildcard subtag is found. B. Otherwise, if there are no more subtags in the language tag's list, the match fails. C. Otherwise, compare the current subtag in the range's list with the current subtag in the language tag's list. If they match, move to the next subtag in both lists and continue with the loop. D. Otherwise, if the language tag's subtag is a "singleton" (a single letter or digit, which includes the private-use subtag 'x') the match fails. E. Otherwise, move to the next subtag in the language tag's list and continue with the loop. In addition, the "until" construct embedded in A seems to duplicate the result of the "while" in 3 with the "if" in A. After completion of the "until" loop in A, at what step does processing resume? Since C and E explicity mention continuing with the loop, does it exit the loop or continue with step B? In short, I'm not able to figure out how to get this algorithm description to produce the results in the list of examples that follows it. Other than the special handling of singletons, I *think* the intended algorithm should behave something like this: do forever { while language range subtag is not wildcard { if language range subtag equals language tag subtag { next language range subtag next language tag subtag } else { return no match } } if language range exhausted { return match; all ranges act as though trailing wildcards } while language range subtag is wildcard { next language range subtag; treat multiple wildcards like a single one } if language range exhausted { return match; nothing but trailing wildcards } ; at this point we've encountered something other than a wildcard after a wildcard ; we need to advance through the language tag being examined to find the next ; subtag that matches while (language range subtag not equal language tag subtag) { next language tag subtag } if language tag exhausted { return no match; we found nothing to match the post-wildcard part } } BUT, this pseudo-code was reverse-engineered from the examples, not the algorithm description in section 3.2.2. The "Otherwise" in step C seems to be where the descriptions diverge. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 17:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtNs-0006w6-Ta; Tue, 04 Apr 2006 17:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtNS-0006ne-NW for ltru@ietf.org; Tue, 04 Apr 2006 17:47:54 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtBH-00029d-Vt for ltru@ietf.org; Tue, 04 Apr 2006 17:35:20 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k34LXo4Y026501; Tue, 4 Apr 2006 14:33:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=JSJizl02oUPbmon85pMeZNdULzKwg0GK7kYS2YiESESVlbbQzVvplAoBvjA3fN32 From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] Access to subtag registry by matching applications Date: Tue, 4 Apr 2006 14:35:53 -0700 Message-ID: <000401c6582f$c0462ed0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <007601c65821$dbdd0d20$6401a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZYIXNog/VQw3rnRIyPQjoBaCekugAC6/vQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Comments follow Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2006=E5=B9=B44=E6=9C=884=E6=97=A5 12:56 >=20 > | However, applications, protocols, or specifications are encouraged = to > | use information in the IANA Language Subtag Registry to canonicalize > | language tags and ranges, mapping grandfathered and obsolete tags or > | subtags into modern equivalents. Such an implementation MAY also = use > | semantic information contained in the tags to augment matching. >=20 > I am concerned that the first sentence may be misconstrued as = encouraging > applications to access the subtag registry. =20 Agreed. >=20 > Consequently, I suggest this minor tweak to the proposed text's > first sentence: >=20 > However, designers of applications, protocols, or specifications are > encouraged to use information from the IANA Language Subtag Registry > to support canonicalizing language tags and ranges, mapping > grandfathered and obsolete tags or subtags into modern equivalents. >=20 > Regarding the second sentence, I believe it goes beyond the scope of > the algorithms defined by this BCP. I suggest the following = replacement > for the second sentence. > The use of additional semantic information associated with subtags > to augment matching is outside the scope of this memo. >=20 I tend to disagree, from the perspective that we *are* documenting = potential implementation details permitted by an application. However, = strictly speaking such an implementation would deviate from the = algorithms specified by draft-matching. With an exception. We give general license to implementations to specify how default = content is located in the lookup algorithm (we require that they = document what the mechanism is). Since this text is mostly an example = anyway, recasting it for this particular purpose covers your concern and = preserves the useful example. I suggest: -- Some forms of matching might benefit from the use of additional = semantic information derived from subtags. For example, when defining = the default content for a lookup process, an implementation might = usefully include the primary language subtags 'nn' (Nynorsk Norwegian) = and 'nb' (Bokmal Norwegian) as synonyms for the more general subtag 'no' = (Norwegian). Or it might infer that content labeled "zh-Hans" (Chinese = as written in the Simplified script) is more likely to match the range = "zh-CN" (Chinese as used in China, where the Simplified script is = predominant) than equivalent content labeled "zh-TW" (Chinese as used in = Taiwan, where the Traditional script is predominant). -- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 17:56:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtVX-000054-2s; Tue, 04 Apr 2006 17:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtVV-0008Vq-CM for ltru@ietf.org; Tue, 04 Apr 2006 17:56:13 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtVU-0002mP-3N for ltru@ietf.org; Tue, 04 Apr 2006 17:56:13 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FQtVT-0007zY-RS; Tue, 04 Apr 2006 17:56:11 -0400 Date: Tue, 4 Apr 2006 17:56:11 -0400 To: Randy Presuhn Subject: Re: [Ltru] ohterwises in procedure Message-ID: <20060404215611.GA27817@ccil.org> References: <007e01c6582f$674acb60$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007e01c6582f$674acb60$6401a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > I found it difficult to figure out the nesting of the ifs and otherwises in > this proposed text in http://www.inter-locale.com/ID/matching-diff-11-12.html: The intention is a single if-then-elseif-then-elseif-then chain. "Otherwise" is a synonym for "else" that works better in English prose; see the Perl code in http://www1.ietf.org/mail-archive/web/ltru/current/msg04792.html for my original intentions. > 3. While there are more subtags left in the language range's list: > A. If the subtag currently being examined in the range is the > wildcard ('*'), move to the next subtag in the range until a > non-wildcard subtag is found. Addison seems to have modified this line's behavior. The words "until a non-wildcard subtag is found" are not necessary, as repeated steps through the main loop will remove multiple wildcards. I suggest these words be replaced with "and continue with the loop", as my original version had it. (My bad, for not checking that Addison's algorithm, which is phrased in terms of "moving to" subtags, was still equivalent to mine, which was phrased in terms of "removing" subtags.) > do forever I think this algorithm is flawed, but I'm not up to analyzing it just now. The Perl code is very close to my original pseudocode as well as to Addison's as amended, and it runs the test cases correctly. -- John Cowan cowan@ccil.org www.ap.org www.ccil.org/~cowan The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 17:56:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtW9-0000VU-FK; Tue, 04 Apr 2006 17:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtNQ-0006ne-2v for ltru@ietf.org; Tue, 04 Apr 2006 17:47:52 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtJn-0002Nt-RD for ltru@ietf.org; Tue, 04 Apr 2006 17:44:09 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k34Lh3rH029536; Tue, 4 Apr 2006 14:43:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=nhrQ2/eTdiJVwUg/g9DtGfCC1lDwsk4KcSPq+DB3TmeI/6vRFIzrKYSd0EGgsYWC From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] ohterwises in procedure Date: Tue, 4 Apr 2006 14:45:07 -0700 Message-ID: <000501c65831$0a0f6260$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <007e01c6582f$674acb60$6401a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZYLv/MHEXlxYs/SauBaXdqCBJa0AAAS+PQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org If you replace the word "otherwise" with "else" and remove the phrase = "until a non-wildcard subtag is found", then the result works correctly. = The pseudo-code is: while (range-subtag.remaining() > 0) { if (range-subtag =3D=3D "*") { next range-subtag; } else if (no-more-tag-subtags) { return no-match; } else if (range-subtag =3D=3D tag-subtag) { // NB> singletons in both match here next range-subtag; next tag-subtag; } else if (tag-subtag.length() =3D=3D 1) { return no-match; } else { // only increment the tag if none of the above true next tag-subtag; } } // loop around until out of range subtags return match; Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2006=E5=B9=B44=E6=9C=884=E6=97=A5 14:33 > To: LTRU Working Group > Subject: [Ltru] ohterwises in procedure >=20 > Hi - >=20 > I found it difficult to figure out the nesting of the ifs and = otherwises > in > this proposed text in http://www.inter-locale.com/ID/matching-diff-11- > 12.html: >=20 > 3. While there are more subtags left in the language range's list: > A. If the subtag currently being examined in the range is = the > wildcard ('*'), move to the next subtag in the range = until > a > non-wildcard subtag is found. >=20 > B. Otherwise, if there are no more subtags in the language > tag's > list, the match fails. >=20 > C. Otherwise, compare the current subtag in the range's = list > with the current subtag in the language tag's list. If > they > match, move to the next subtag in both lists and = continue > with the loop. >=20 > D. Otherwise, if the language tag's subtag is a = "singleton" (a > single letter or digit, which includes the private-use > subtag > 'x') the match fails. >=20 > E. Otherwise, move to the next subtag in the language = tag's > list > and continue with the loop. >=20 > In addition, the "until" construct embedded in A seems to duplicate = the > result of the "while" in 3 with the "if" in A. After completion of = the > "until" loop in A, at what step does processing resume? Since C and > E explicity mention continuing with the loop, does it exit the loop > or continue with step B? In short, I'm not able to figure out how to > get this algorithm description to produce the results in the list of > examples that follows it. >=20 > Other than the special handling of singletons, I *think* the intended > algorithm should behave something like this: >=20 > do forever > { > while language range subtag is not wildcard > { > if language range subtag equals language tag subtag > { > next language range subtag > next language tag subtag > } > else > { > return no match > } > } >=20 > if language range exhausted > { > return match; all ranges act as though > trailing wildcards > } >=20 > while language range subtag is wildcard > { > next language range subtag; treat multiple wildcards = like > a single one > } >=20 > if language range exhausted > { > return match; nothing but trailing = wildcards > } >=20 > ; at this point we've encountered something other than a wildcard = after > a wildcard > ; we need to advance through the language tag being examined to = find > the next > ; subtag that matches > while (language range subtag not equal language tag subtag) > { > next language tag subtag > } >=20 > if language tag exhausted > { > return no match; we found nothing to match = the > post-wildcard part > } > } >=20 > BUT, this pseudo-code was reverse-engineered from the examples, not = the > algorithm > description in section 3.2.2. The "Otherwise" in step C seems to be = where > the > descriptions diverge. >=20 > Randy >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 17:59:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtYS-0002XZ-8J; Tue, 04 Apr 2006 17:59:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtYR-0002XU-Na for ltru@ietf.org; Tue, 04 Apr 2006 17:59:15 -0400 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtYQ-0002uP-Gn for ltru@ietf.org; Tue, 04 Apr 2006 17:59:15 -0400 Received: from h-68-165-6-16.snvacaid.dynamic.covad.net ([68.165.6.16] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FQtYQ-00050q-00 for ltru@ietf.org; Tue, 04 Apr 2006 17:59:14 -0400 Message-ID: <008c01c65833$7be63a60$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 4 Apr 2006 15:02:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] default content X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... In section 3.3 of the proposed text at http://www.inter-locale.com/ID/matching-diff-11-12.html, | Each implementation MUST define the default content returned when no | tag matches the language priority list. An implementation might, for The greater specificity is good, but... (1) we should only be talking about what the result of the lookup function is. That result is NOT "content", but rather a language tag. What content results from that tag selection is farbeyond our scope. (2) do we really want to push the requirement for defining default behaviour all the way down to implementations, rather than permitting protocol specifications to do it as well? I'd be happy with something like "Applications, protocols, and specifications employing language tag lookup MUST specify how the default language tag is determined." I think this would be a reasonable balance between clarity and flexibility. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 18:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtc6-0007om-JI; Tue, 04 Apr 2006 18:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtc6-0007oh-93 for ltru@ietf.org; Tue, 04 Apr 2006 18:03:02 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtc4-00038N-UU for ltru@ietf.org; Tue, 04 Apr 2006 18:03:02 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k34M1NY2035435; Tue, 4 Apr 2006 15:01:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=omYbFM9Po7iZHfX2ah2KHUuTeVYust+XhpBRg8mN1ES6YVeux9mrl60r+D5mK2Gb From: "Addison Phillips" To: "'Addison Phillips'" , "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] various comments editorial action Date: Tue, 4 Apr 2006 15:03:13 -0700 Message-ID: <000701c65833$91b34860$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000401c6582f$c0462ed0$9fcd15ac@ds.corp.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZYIXNog/VQw3rnRIyPQjoBaCekugAC6/vQAAF0kcA= X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All: I have posted a "draft-12a" on inter-locale. A diff from draft-11 is = very difficult to interpret, so I have elected not to generate one. A = diff from the editor's copy of draft-12 can be generated by following = the URI: http://tinyurl.com/nx8uf I would suggest that we submit a draft-12 soon. I haven't done so = because I've been waiting on one or another co-chair to tell me what to = do with specific comments (i.e. whether we proceed with my editor's copy = or roll back). I also notice that the issues list server appears to be = dead, even using the IP address. New copies are: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12a.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12a.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12a.xml Best Regards (for the editors), Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 18:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQteS-0001IH-Fb; Tue, 04 Apr 2006 18:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQteR-0001HL-Bc for ltru@ietf.org; Tue, 04 Apr 2006 18:05:27 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQteQ-0003GD-1e for ltru@ietf.org; Tue, 04 Apr 2006 18:05:27 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k34M4Res036229; Tue, 4 Apr 2006 15:04:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=ZkcusPmCWXenIg6xd8/tUyVRYvbTqoKQ1j1XfacbL1HzsQ/awBYvyYa4W1z/XRpW From: "Addison Phillips" To: "'John Cowan'" , "'Randy Presuhn'" Subject: RE: [Ltru] ohterwises in procedure Date: Tue, 4 Apr 2006 15:06:16 -0700 Message-ID: <000801c65833$febaa8e0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060404215611.GA27817@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZYMqBwZG//mQSCRJuUx3ICIEvfKQAARPKA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > Addison seems to have modified this line's behavior. The words "until a > non-wildcard subtag is found" are not necessary, as repeated steps through > the main loop will remove multiple wildcards. I suggest these words be > replaced with "and continue with the loop", as my original version had it. You're right. My text is misleading. > > (My bad, for not checking that Addison's algorithm, which is phrased in > terms of "moving to" subtags, was still equivalent to mine, which was > phrased in terms of "removing" subtags.) I elected to use "moving to" to avoid giving the impression that one might modify the tag or subtags in some way. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 18:09:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtiD-0001u2-JI; Tue, 04 Apr 2006 18:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtiC-0001tO-1D for ltru@ietf.org; Tue, 04 Apr 2006 18:09:20 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtiA-0003SG-QT for ltru@ietf.org; Tue, 04 Apr 2006 18:09:20 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FQtiA-0000E5-4V; Tue, 04 Apr 2006 18:09:18 -0400 Date: Tue, 4 Apr 2006 18:09:18 -0400 To: Randy Presuhn Subject: Re: [Ltru] default content Message-ID: <20060404220918.GB27817@ccil.org> References: <008c01c65833$7be63a60$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008c01c65833$7be63a60$6401a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > (1) we should only be talking about what the result of the lookup > function is. That result is NOT "content", but rather a language tag. The first line of 3.3 says: # Lookup is used to select the single language tag that best matches the # language priority list for a given request and return the associated # content. Language throughout Section 3 is consistent with this: matching selects one or more matching tags and returns the corresponding content. Indeed, Section 1 speaks of # several schemes for selecting or filtering sets of content by comparing # the content's language tags to the user's preferences. also emphasizing that it is content that is returned. > (2) do we really want to push the requirement for defining default > behaviour all the way down to implementations, rather than permitting > protocol specifications to do it as well? I'd be happy with something > like "Applications, protocols, and specifications employing language > tag lookup MUST specify how the default language tag is determined." > I think this would be a reasonable balance between clarity and flexibility. +1 -- John Cowan http://www.ccil.org/~cowan One time I called in to the central system and started working on a big thick 'sed' and 'awk' heavy duty data bashing script. One of the geologists came by, looked over my shoulder and said 'Oh, that happens to me too. Try hanging up and phoning in again.' --Beverly Erlebacher _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 18:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtk6-0003Ag-PM; Tue, 04 Apr 2006 18:11:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtk5-0003Ab-J6 for ltru@ietf.org; Tue, 04 Apr 2006 18:11:17 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtk4-0003aG-Bj for ltru@ietf.org; Tue, 04 Apr 2006 18:11:17 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FQtk3-0000Hf-SS; Tue, 04 Apr 2006 18:11:15 -0400 Date: Tue, 4 Apr 2006 18:11:15 -0400 To: Addison Phillips Subject: Re: [Ltru] ohterwises in procedure Message-ID: <20060404221115.GC27817@ccil.org> References: <20060404215611.GA27817@ccil.org> <000801c65833$febaa8e0$9fcd15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c65833$febaa8e0$9fcd15ac@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > I elected to use "moving to" to avoid giving the impression that one might > modify the tag or subtags in some way. I understood that and agree with your reasoning. -- Henry S. Thompson said, / "Syntactic, structural, John Cowan Value constraints we / Express on the fly." cowan@ccil.org Simon St. Laurent: "Your / Incomprehensible http://www.ap.org Abracadabralike / schemas must die!" http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 18:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtrC-00019q-TQ; Tue, 04 Apr 2006 18:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtrB-00019l-F4 for ltru@ietf.org; Tue, 04 Apr 2006 18:18:37 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtrA-0003lF-2f for ltru@ietf.org; Tue, 04 Apr 2006 18:18:37 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k34MHCQp039904; Tue, 4 Apr 2006 15:17:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=TSft9FZIlONo4x1EYIgvb1JVpVHiH4waLH11Y97Y6uoFsOITBVtZyIzzEaQ3OcIW From: "Addison Phillips" To: "'John Cowan'" , "'Randy Presuhn'" Subject: RE: [Ltru] default content Date: Tue, 4 Apr 2006 15:18:59 -0700 Message-ID: <000a01c65835$c56d3f60$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060404220918.GB27817@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZYNH8QAncHkjN1TvaWaHOb/YzyHgAATMfQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 to both parts. My bad for implementing more "implementations" in the text. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 2006?4?4? 15:09 > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] default content > > Randy Presuhn scripsit: > > > (1) we should only be talking about what the result of the lookup > > function is. That result is NOT "content", but rather a language tag. > > The first line of 3.3 says: > > # Lookup is used to select the single language tag that best matches the > # language priority list for a given request and return the associated > # content. > > Language throughout Section 3 is consistent with this: matching selects > one or more matching tags and returns the corresponding content. > > Indeed, Section 1 speaks of > > # several schemes for selecting or filtering sets of content by comparing > # the content's language tags to the user's preferences. > > also emphasizing that it is content that is returned. > > > (2) do we really want to push the requirement for defining default > > behaviour all the way down to implementations, rather than permitting > > protocol specifications to do it as well? I'd be happy with something > > like "Applications, protocols, and specifications employing language > > tag lookup MUST specify how the default language tag is determined." > > I think this would be a reasonable balance between clarity and > flexibility. > > +1 > > -- > John Cowan http://www.ccil.org/~cowan > One time I called in to the central system and started working on a big > thick 'sed' and 'awk' heavy duty data bashing script. One of the > geologists > came by, looked over my shoulder and said 'Oh, that happens to me too. > Try hanging up and phoning in again.' --Beverly Erlebacher > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 18:50:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuMP-0006lH-LA; Tue, 04 Apr 2006 18:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuMO-0006jw-90 for ltru@ietf.org; Tue, 04 Apr 2006 18:50:52 -0400 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQuMN-0005CO-16 for ltru@ietf.org; Tue, 04 Apr 2006 18:50:52 -0400 Received: from h-68-165-6-16.snvacaid.dynamic.covad.net ([68.165.6.16] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FQuMM-0007Sr-00 for ltru@ietf.org; Tue, 04 Apr 2006 18:50:50 -0400 Message-ID: <00a101c6583a$b1ad2620$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <008c01c65833$7be63a60$6401a8c0@oemcomputer> <20060404220918.GB27817@ccil.org> Subject: Re: [Ltru] default content Date: Tue, 4 Apr 2006 15:54:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, April 04, 2006 3:09 PM > Subject: Re: [Ltru] default content > > Randy Presuhn scripsit: > > > (1) we should only be talking about what the result of the lookup > > function is. That result is NOT "content", but rather a language tag. > > The first line of 3.3 says: > > # Lookup is used to select the single language tag that best matches the > # language priority list for a given request and return the associated > # content. > > Language throughout Section 3 is consistent with this: matching selects > one or more matching tags and returns the corresponding content. It should only talk about the tags. Selection of content based on associated language tags is just one possible application of language tag matching. It is not the only one. Getting rid of "and return the associated content" is all I ask for. Matching algorithms make for nice components, suitable for wide reuse, whether as a specification or a library implementation. "Match tag and return associated content" does not make a reusable component, since what needs to be done to "return associated content" will vary wildly depending on the application or protocol. > Indeed, Section 1 speaks of > > # several schemes for selecting or filtering sets of content by comparing > # the content's language tags to the user's preferences. > > also emphasizing that it is content that is returned. ... Again, selection of content is only an example of a possible use of language tag matching algorithms. We shouldn't be talking about content except when an illustrative example is necessary. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 19:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQv42-0005aZ-6x; Tue, 04 Apr 2006 19:35:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQv41-0005aU-DA for ltru@ietf.org; Tue, 04 Apr 2006 19:35:57 -0400 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQv40-0007gL-6p for ltru@ietf.org; Tue, 04 Apr 2006 19:35:57 -0400 Received: from h-68-165-6-16.snvacaid.dynamic.covad.net ([68.165.6.16] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FQv3z-00016G-00 for ltru@ietf.org; Tue, 04 Apr 2006 19:35:55 -0400 Message-ID: <00c801c65840$fdb3ad40$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "'LTRU Working Group'" References: <000401c6582f$c0462ed0$9fcd15ac@ds.corp.yahoo.com> Subject: Re: [Ltru] Access to subtag registry by matching applications Date: Tue, 4 Apr 2006 16:39:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Addison Phillips" > To: "'Randy Presuhn'" ; "'LTRU Working Group'" > Sent: Tuesday, April 04, 2006 2:35 PM > Subject: RE: [Ltru] Access to subtag registry by matching applications ... > Since this text is mostly an example anyway, recasting it for this > particular purpose covers your concern and preserves the useful example. I suggest: > > -- > Some forms of matching might benefit from the use of additional semantic ... Change "forms of matching" to "forms of matching beyond the scope of this memo" and I could live with your proposal. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 04 20:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQw2J-0005UW-EB; Tue, 04 Apr 2006 20:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQw2I-0005UO-Pl for ltru@ietf.org; Tue, 04 Apr 2006 20:38:14 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQw2H-000262-Ib for ltru@ietf.org; Tue, 04 Apr 2006 20:38:14 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FQw2G-0005Ag-Ti; Tue, 04 Apr 2006 20:38:12 -0400 Date: Tue, 4 Apr 2006 20:38:12 -0400 To: Randy Presuhn Subject: Re: [Ltru] default content Message-ID: <20060405003812.GI7156@ccil.org> References: <008c01c65833$7be63a60$6401a8c0@oemcomputer> <20060404220918.GB27817@ccil.org> <00a101c6583a$b1ad2620$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a101c6583a$b1ad2620$6401a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > It should only talk about the tags. Selection of content based on associated > language tags is just one possible application of language tag matching. I think that such a radical and pervasive change to the draft should not be done now. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass. --DeXiderata, Sean McGrath _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 00:36:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQzl7-0006EZ-N6; Wed, 05 Apr 2006 00:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQzl5-0006EU-Sm for ltru@ietf.org; Wed, 05 Apr 2006 00:36:43 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQzl4-0002D6-IY for ltru@ietf.org; Wed, 05 Apr 2006 00:36:43 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id 761C71E132B; Tue, 4 Apr 2006 21:36:39 -0700 (PDT) Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31614-11; Tue, 4 Apr 2006 21:36:37 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 28C811E130C; Tue, 4 Apr 2006 21:36:37 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Apr 2006 21:36:37 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EDB6@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'John Cowan' , Randy Presuhn Subject: RE: [Ltru] default content Date: Tue, 4 Apr 2006 21:36:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Virus-Scanned: amavisd-new at sharplabs.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, I disagree with John. I strongly agree with Randy that the output of a matching algorithm implementation that's a resusable component MUST be a language tag and nothing else. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Tuesday, April 04, 2006 8:38 PM > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] default content > > > Randy Presuhn scripsit: > > > It should only talk about the tags. Selection of content > based on associated > > language tags is just one possible application of language > tag matching. > > I think that such a radical and pervasive change to the draft > should not > be done now. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > Be yourself. Especially do not feign a working knowledge of RDF where > no such knowledge exists. Neither be cynical about RELAX NG; for in > the face of all aridity and disenchantment in the world of markup, > James Clark is as perennial as the grass. --DeXiderata, Sean McGrath > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/301 - Release > Date: 4/4/2006 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: 4/4/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 12:01:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRARs-0005PF-O4; Wed, 05 Apr 2006 12:01:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRARs-0005Ot-4V for ltru@ietf.org; Wed, 05 Apr 2006 12:01:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRARs-0005Bu-32 for ltru@ietf.org; Wed, 05 Apr 2006 12:01:36 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FRAKD-0003FN-7e for ltru@ietf.org; Wed, 05 Apr 2006 11:53:43 -0400 Received: from duringpersonlx (snvvpn-10-72-66-c66.corp.yahoo.com [10.72.66.66]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k35FrA8u092127; Wed, 5 Apr 2006 08:53:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=LI1HxIo/xzHLWSuf+8SMlwN1sq5GM4Igsq/2+CDzX9ro7u0s7pCbY7OKFUbGrmMu From: "Addison Phillips" To: "'McDonald, Ira'" , "'John Cowan'" , "'Randy Presuhn'" Subject: RE: [Ltru] default content Date: Wed, 5 Apr 2006 08:56:15 -0700 Message-ID: <000401c658c9$792338a0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EDB6@mailsrvnt05.enet.sharplabs.com> Thread-Index: AcZYaplltqsAq2m5QD6ADzQEDSw8fwAXAJbA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I observe: 1. The first last call is essentially a failure, since the document is now highly different from the last called text (even if we were to reject Randy's comments). We will need another once we have addressed the issues raised in this one. > I strongly agree with Randy that the output of a matching > algorithm implementation that's a resusable component MUST > be a language tag and nothing else. 2. The changes are "pervasive", but almost entirely editorial. If you check out my proto-draft-12a (note the "a"), you can see a proposed version that excises "content" appropriately. http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12a.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12a.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12a.xml A diff from draft-12 can be generated by following this URI: http://tinyurl.com/nx8uf As a result: I intend to submit "draft-12a" as draft-12 at the end of (my) today. Maintaining diff lists and multiple copies of the XML is an enormous waste of time. I propose that: a. the co-chairs permit a *short* period for review and commentary on draft-12, culminating in a draft-13. This will allow people time to read the document again end-to-end and air any lingering concerns or comments. b. that draft-13 be used for a new WG Last Call of the usual length. c. that we finish this work *soon* (which means: if you have comments, please MAKE THEM NOW) Best Regards, Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: 2006?4?4? 21:37 > To: 'John Cowan'; Randy Presuhn > Cc: ltru@ietf.org > Subject: RE: [Ltru] default content > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 13:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCBK-00010K-E7; Wed, 05 Apr 2006 13:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCBJ-0000vd-1Z for ltru@ietf.org; Wed, 05 Apr 2006 13:52:37 -0400 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRCBH-0001En-Ng for ltru@ietf.org; Wed, 05 Apr 2006 13:52:37 -0400 Received: (qmail 22829 invoked from network); 5 Apr 2006 17:52:34 -0000 Received: from unknown (HELO ?172.19.10.243?) (unknown) by unknown with SMTP; 5 Apr 2006 17:52:34 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <443403D3.2070301@icu-project.org> Date: Wed, 05 Apr 2006 10:52:19 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Access to subtag registry by matching applications References: <000401c6582f$c0462ed0$9fcd15ac@ds.corp.yahoo.com> In-Reply-To: <000401c6582f$c0462ed0$9fcd15ac@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org We could make this more explicit, addressing Randy's concern, if we added that Each implementation MUST specify whether it is using semantic information to customize the matching, and if so, MUST define the mechanism used to do so. Mark Addison Phillips wrote: > Comments follow > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> Sent: 2006å¹´4月4æ—¥ 12:56 >> >> | However, applications, protocols, or specifications are encouraged to >> | use information in the IANA Language Subtag Registry to canonicalize >> | language tags and ranges, mapping grandfathered and obsolete tags or >> | subtags into modern equivalents. Such an implementation MAY also use >> | semantic information contained in the tags to augment matching. >> >> I am concerned that the first sentence may be misconstrued as encouraging >> applications to access the subtag registry. >> > > Agreed. > >> Consequently, I suggest this minor tweak to the proposed text's >> first sentence: >> >> However, designers of applications, protocols, or specifications are >> encouraged to use information from the IANA Language Subtag Registry >> to support canonicalizing language tags and ranges, mapping >> grandfathered and obsolete tags or subtags into modern equivalents. >> >> Regarding the second sentence, I believe it goes beyond the scope of >> the algorithms defined by this BCP. I suggest the following replacement >> for the second sentence. >> The use of additional semantic information associated with subtags >> to augment matching is outside the scope of this memo. >> >> > I tend to disagree, from the perspective that we *are* documenting potential implementation details permitted by an application. However, strictly speaking such an implementation would deviate from the algorithms specified by draft-matching. > > With an exception. > > We give general license to implementations to specify how default content is located in the lookup algorithm (we require that they document what the mechanism is). Since this text is mostly an example anyway, recasting it for this particular purpose covers your concern and preserves the useful example. I suggest: > > -- > Some forms of matching might benefit from the use of additional semantic information derived from subtags. For example, when defining the default content for a lookup process, an implementation might usefully include the primary language subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) as synonyms for the more general subtag 'no' (Norwegian). Or it might infer that content labeled "zh-Hans" (Chinese as written in the Simplified script) is more likely to match the range "zh-CN" (Chinese as used in China, where the Simplified script is predominant) than equivalent content labeled "zh-TW" (Chinese as used in Taiwan, where the Traditional script is predominant). > -- > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 13:52:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCBR-00017t-HH; Wed, 05 Apr 2006 13:52:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCBQ-00016g-Cb for ltru@ietf.org; Wed, 05 Apr 2006 13:52:44 -0400 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRCBP-0001Et-4l for ltru@ietf.org; Wed, 05 Apr 2006 13:52:44 -0400 Received: (qmail 22877 invoked from network); 5 Apr 2006 17:52:42 -0000 Received: from unknown (HELO ?172.19.10.243?) (unknown) by unknown with SMTP; 5 Apr 2006 17:52:42 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <443403DC.20206@icu-project.org> Date: Wed, 05 Apr 2006 10:52:28 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] default content References: <008c01c65833$7be63a60$6401a8c0@oemcomputer> <20060404220918.GB27817@ccil.org> <00a101c6583a$b1ad2620$6401a8c0@oemcomputer> In-Reply-To: <00a101c6583a$b1ad2620$6401a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree with Randy. Returning content is not the only purpose to matching, and even if returning content is the eventual goal, a particular process may only be concerned with the matching aspect; and leave it up to other processes to actually fetch content on that basis. Mark Randy Presuhn wrote: > Hi - > > As a technical contributor... > > >> From: "John Cowan" >> To: "Randy Presuhn" >> Cc: >> Sent: Tuesday, April 04, 2006 3:09 PM >> Subject: Re: [Ltru] default content >> >> Randy Presuhn scripsit: >> >> >>> (1) we should only be talking about what the result of the lookup >>> function is. That result is NOT "content", but rather a language tag. >>> >> The first line of 3.3 says: >> >> # Lookup is used to select the single language tag that best matches the >> # language priority list for a given request and return the associated >> # content. >> >> Language throughout Section 3 is consistent with this: matching selects >> one or more matching tags and returns the corresponding content. >> > > It should only talk about the tags. Selection of content based on associated > language tags is just one possible application of language tag matching. > It is not the only one. Getting rid of "and return the associated content" > is all I ask for. Matching algorithms make for nice components, suitable > for wide reuse, whether as a specification or a library implementation. > "Match tag and return associated content" does not make a reusable > component, since what needs to be done to "return associated content" > will vary wildly depending on the application or protocol. > > >> Indeed, Section 1 speaks of >> >> # several schemes for selecting or filtering sets of content by comparing >> # the content's language tags to the user's preferences. >> >> also emphasizing that it is content that is returned. >> > ... > > Again, selection of content is only an example of a possible > use of language tag matching algorithms. We shouldn't be talking > about content except when an illustrative example is necessary. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 14:33:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCog-0007oS-C2; Wed, 05 Apr 2006 14:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCof-0007oN-Q7 for ltru@ietf.org; Wed, 05 Apr 2006 14:33:17 -0400 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRCof-0003KW-H6 for ltru@ietf.org; Wed, 05 Apr 2006 14:33:17 -0400 Received: (qmail 89041 invoked from network); 5 Apr 2006 18:33:17 -0000 Received: from unknown (HELO ?172.19.10.243?) (unknown) by unknown with SMTP; 5 Apr 2006 18:33:17 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <44340D6E.4020000@icu-project.org> Date: Wed, 05 Apr 2006 11:33:18 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Access to subtag registry by matching applications References: <000401c6582f$c0462ed0$9fcd15ac@ds.corp.yahoo.com> In-Reply-To: <000401c6582f$c0462ed0$9fcd15ac@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org We could make this more explicit, addressing Randy's concern, if we added that Each implementation MUST specify whether it is using semantic information to customize the matching, and if so, MUST define the mechanism used to do so. Mark Addison Phillips wrote: > Comments follow > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> Sent: 2006å¹´4月4æ—¥ 12:56 >> >> | However, applications, protocols, or specifications are encouraged to >> | use information in the IANA Language Subtag Registry to canonicalize >> | language tags and ranges, mapping grandfathered and obsolete tags or >> | subtags into modern equivalents. Such an implementation MAY also use >> | semantic information contained in the tags to augment matching. >> >> I am concerned that the first sentence may be misconstrued as encouraging >> applications to access the subtag registry. >> > > Agreed. > >> Consequently, I suggest this minor tweak to the proposed text's >> first sentence: >> >> However, designers of applications, protocols, or specifications are >> encouraged to use information from the IANA Language Subtag Registry >> to support canonicalizing language tags and ranges, mapping >> grandfathered and obsolete tags or subtags into modern equivalents. >> >> Regarding the second sentence, I believe it goes beyond the scope of >> the algorithms defined by this BCP. I suggest the following replacement >> for the second sentence. >> The use of additional semantic information associated with subtags >> to augment matching is outside the scope of this memo. >> >> > I tend to disagree, from the perspective that we *are* documenting potential implementation details permitted by an application. However, strictly speaking such an implementation would deviate from the algorithms specified by draft-matching. > > With an exception. > > We give general license to implementations to specify how default content is located in the lookup algorithm (we require that they document what the mechanism is). Since this text is mostly an example anyway, recasting it for this particular purpose covers your concern and preserves the useful example. I suggest: > > -- > Some forms of matching might benefit from the use of additional semantic information derived from subtags. For example, when defining the default content for a lookup process, an implementation might usefully include the primary language subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) as synonyms for the more general subtag 'no' (Norwegian). Or it might infer that content labeled "zh-Hans" (Chinese as written in the Simplified script) is more likely to match the range "zh-CN" (Chinese as used in China, where the Simplified script is predominant) than equivalent content labeled "zh-TW" (Chinese as used in Taiwan, where the Traditional script is predominant). > -- > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 18:34:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGZd-0007q0-DH; Wed, 05 Apr 2006 18:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGZc-0007pv-69 for ltru@ietf.org; Wed, 05 Apr 2006 18:34:00 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGZb-000108-Rh for ltru@ietf.org; Wed, 05 Apr 2006 18:34:00 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k35MXNuZ022028; Wed, 5 Apr 2006 15:33:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=U+pbXxpaGfi2PjqDvPEussufJVvBcApMumPSfv7QH7Bt7EaFfGmuiAgBpxY4S9Tw From: "Addison Phillips" To: "'Mark Davis'" Subject: RE: [Ltru] Access to subtag registry by matching applications Date: Wed, 5 Apr 2006 15:35:23 -0700 Message-ID: <001001c65901$3ad62570$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZY33uG+4365THTTdGPZppiFajQFgAG0gTg In-Reply-To: <44340D6E.4020000@icu-project.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > We could make this more explicit, addressing Randy's concern, if we > added that Yes, we could do this, but that also makes it clear that this is beyond = the scope of the document anyway. I think the real problem here is that we're thinking too specifically = about examples such as 'nb'->'no'. The more general description is: = users wish to tailor or customize the matching in a particular matching = instance (so that, for example, 'zh-Hans' also matches 'zh-CN'). This = isn't really "semantic" information (given that I might wish to = associate the range "es-ES" with the tag "tlh-AQ", where no semantic = linkage exists except in my own fevered mind). The problem here is that = mappings of this sort can be described as (higher-level) features of the = "application, protocol, or specification" and usually in terms of = pre-processing the language priority list, the tags, or both.=20 I think we would best limit ourselves (*if* we say anything at all) to = something like: -- Applications, protocols, or specifications, in addressing their = particular requirements, can offer pre-processing or configuration = options. For example, an implementation could allow a user to associate = the language subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal = Norwegian) with the more general subtag 'no' (Norwegian). Or perhaps the = user could associate the range "zh-Hans" (Chinese as written in the = Simplified script) with the tag "zh-CN" (Chinese as used in China, where = the Simplified script is predominant). Such customization affects the = operation of the underlying matching scheme. Conformant implementations = SHOULD NOT enable such options by default and MUST offer a configuration = or mode compatible with the unmodified matching scheme or schemes = described in this document. -- Thoughts? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B44=E6=9C=885=E6=97=A5 11:33 > To: Addison Phillips > Cc: 'Randy Presuhn'; 'LTRU Working Group' > Subject: Re: [Ltru] Access to subtag registry by matching applications _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 18:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGpO-0006Qe-8P; Wed, 05 Apr 2006 18:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGpN-0006QZ-Ac for ltru@ietf.org; Wed, 05 Apr 2006 18:50:17 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGpM-0001hK-2m for ltru@ietf.org; Wed, 05 Apr 2006 18:50:17 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FRGpL-0004Lo-Pp; Wed, 05 Apr 2006 18:50:15 -0400 Date: Wed, 5 Apr 2006 18:50:15 -0400 To: Addison Phillips Subject: Re: [Ltru] Access to subtag registry by matching applications Message-ID: <20060405225015.GA11928@ccil.org> References: <44340D6E.4020000@icu-project.org> <001001c65901$3ad62570$9fcd15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001001c65901$3ad62570$9fcd15ac@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Applications, protocols, or specifications, in addressing their > particular requirements, can offer pre-processing or configuration > options. For example, an implementation could allow a user to > associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' > (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or > perhaps the user could associate the range "zh-Hans" (Chinese as written > in the Simplified script) with the tag "zh-CN" (Chinese as used in > China, where the Simplified script is predominant). Such customization > affects the operation of the underlying matching scheme. Conformant > implementations SHOULD NOT enable such options by default and MUST > offer a configuration or mode compatible with the unmodified matching > scheme or schemes described in this document. I don't like the last sentence. Enabling such options by default, if they are good ones, may be just the right thing to do: conformance isn't anything. And the second half of the sentence says that a conformant application MUST offer a conformant mode of operation, which is to say that conformance entails conformance. (BTW, graf 2 of Section 3 still talks about information items.) > -- > > Thoughts? > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Mark Davis [mailto:mark.davis@icu-project.org] > > Sent: 2006???4???5??? 11:33 > > To: Addison Phillips > > Cc: 'Randy Presuhn'; 'LTRU Working Group' > > Subject: Re: [Ltru] Access to subtag registry by matching applications > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- But that, he realized, was a foolish John Cowan thought; as no one knew better than he cowan@ccil.org that the Wall had no other side. http://www.ccil.org/~cowan --Arthur C. Clarke, "The Wall of Darkness" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 18:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGqT-0006Vu-L5; Wed, 05 Apr 2006 18:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGqS-0006Vp-NG for ltru@ietf.org; Wed, 05 Apr 2006 18:51:24 -0400 Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGqR-0001iM-G1 for ltru@ietf.org; Wed, 05 Apr 2006 18:51:24 -0400 Received: from h-68-166-37-245.snvacaid.dynamic.covad.net ([68.166.37.245] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FRGqQ-0007Wp-00 for ltru@ietf.org; Wed, 05 Apr 2006 18:51:23 -0400 Message-ID: <001201c65903$e5bed2a0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001001c65901$3ad62570$9fcd15ac@ds.corp.yahoo.com> Subject: Re: [Ltru] Access to subtag registry by matching applications Date: Wed, 5 Apr 2006 15:54:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Addison Phillips" > To: "'Mark Davis'" > Cc: "'Randy Presuhn'" ; "'LTRU Working Group'" > Sent: Wednesday, April 05, 2006 3:35 PM > Subject: RE: [Ltru] Access to subtag registry by matching applications > > We could make this more explicit, addressing Randy's concern, if we > added that ... > I think we would best limit ourselves (*if* we say anything at all) to something like: > > -- > Applications, protocols, or specifications, in addressing their particular > requirements, can offer pre-processing or configuration options. For example, > an implementation could allow a user to associate the language subtags 'nn' > (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general subtag > 'no' (Norwegian). Or perhaps the user could associate the range "zh-Hans" > (Chinese as written in the Simplified script) with the tag "zh-CN" (Chinese > as used in China, where the Simplified script is predominant). So far, so good. > Such customization affects the operation of the underlying matching scheme. Not necessarily; it could also be thought of as mapping a single tag into a set of tags or ranges before offering them to the matching algorithm. > Conformant implementations SHOULD NOT enable such options by default > and MUST offer a configuration or mode compatible with the unmodified > matching scheme or schemes described in this document. ... If we're clear that we're only talking about such capabilities being "built in" to the matching algorithm this would be ok, but I'm concerned that this might be misconstrued as being too strong, e.g., forbidding an application which used a conformant matching function from providing these more elaborate / useful services. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 18:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGtK-0007Gd-6f; Wed, 05 Apr 2006 18:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGtH-0007GT-MB for ltru@ietf.org; Wed, 05 Apr 2006 18:54:19 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGtG-0001lL-FR for ltru@ietf.org; Wed, 05 Apr 2006 18:54:19 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FRGtG-0004PK-7v for ltru@ietf.org; Wed, 05 Apr 2006 18:54:18 -0400 Date: Wed, 5 Apr 2006 18:54:18 -0400 To: ltru@ietf.org Message-ID: <20060405225418.GB11928@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] Eliminating "content" considered harmful X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It's fairly easy to cast both filtering algorithms in terms of just working through a list of ranges and a list of language tags, and Addison has heroically done so. The whole point of the lookup algorithm, though, is to find the best piece of content given a list of ranges and a set of information items with or without tags. Saying that lookup is supposed to return just one information item is correct; saying that it is supposed to return just one language tag is *not*. The present state of 12a is inconsistent between the view "return one tag" and "return one tag if you can". Cleaning up by making it "return one or zero tags" eliminates the whole purpose of the lookup algorithm, and requires an entirely new machinery of justification. (Having a matching draft in the first place was stupid; matching should have been left out, since everything in 3066 on the subject is just a restatement of 2616, which should have been left in charge. Too late now, I know.) -- "But I am the real Strider, fortunately," John Cowan he said, looking down at them with his face cowan@ccil.org softened by a sudden smile. "I am Aragorn son http://www.ccil.org/~cowan of Arathorn, and if by life or death I can save you, I will." --LotR Book I Chapter 10 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 19:03:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRH2S-0003T5-V7; Wed, 05 Apr 2006 19:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRH2R-0003T0-In for ltru@ietf.org; Wed, 05 Apr 2006 19:03:47 -0400 Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRH2Q-0001wt-Bd for ltru@ietf.org; Wed, 05 Apr 2006 19:03:47 -0400 Received: from h-68-166-37-245.snvacaid.dynamic.covad.net ([68.166.37.245] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FRH2P-0002CB-00 for ltru@ietf.org; Wed, 05 Apr 2006 19:03:46 -0400 Message-ID: <003101c65905$abc28b80$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20060405225418.GB11928@ccil.org> Subject: Re: [Ltru] Eliminating "content" considered harmful Date: Wed, 5 Apr 2006 16:07:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: > Sent: Wednesday, April 05, 2006 3:54 PM > Subject: [Ltru] Eliminating "content" considered harmful ... > The whole point of the lookup algorithm, though, is to find the best piece > of content given a list of ranges and a set of information items with or > without tags. Saying that lookup is supposed to return just one information > item is correct; saying that it is supposed to return just one language > tag is *not*. Returning content is *not* the sole possible use of language tag matching or lookup. Consider, for example, a multi-party negotiation in protocol to decide what language to use for a meeting, conference, or multicast session. > The present state of 12a is inconsistent between the > view "return one tag" and "return one tag if you can". This sounds like a problem of unclarity with respect to "default". > Cleaning up by making it "return one or zero tags" eliminates the whole > purpose of the lookup algorithm, and requires an entirely new machinery > of justification. ... Returning content is an application of the technology, an appropriate example of its use. Having given the example, however, we should then focus on what we are supposed to deliver, rather than the example. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 19:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRH3a-0003Wh-6N; Wed, 05 Apr 2006 19:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRH3Z-0003Wc-3Y for ltru@ietf.org; Wed, 05 Apr 2006 19:04:57 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRH3Y-0001xi-ML for ltru@ietf.org; Wed, 05 Apr 2006 19:04:57 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k35N3fGl031466; Wed, 5 Apr 2006 16:03:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=B/BZ8ofwJSFNb5pfex/4VrJ1LuKxcW/O7DdyNVGYZ+q1yNFLVLevgacJr191OQ/H From: "Addison Phillips" To: "'John Cowan'" Subject: RE: [Ltru] Access to subtag registry by matching applications Date: Wed, 5 Apr 2006 16:05:43 -0700 Message-ID: <001101c65905$77a0e720$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZA1kGO7wXq5Z4Sum+PuRDb4+4FAAAOwzA In-Reply-To: <20060405225015.GA11928@ccil.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > (BTW, graf 2 of Section 3 still talks about information items.) Good catch. Changed to: There are two types of matching scheme in this document. A matching scheme that produces zero or more matching language tags is called "filtering". A matching scheme that produces exactly one match for a given request is called "lookup". And also: > I don't like the last sentence. Enabling such options by default, if they > are good ones, may be just the right thing to do: conformance isn't > anything. I don't like it either. Randy meanwhile opines: > Not necessarily; it could also be thought of as mapping a single tag into > a set of tags or ranges before offering them to the matching algorithm. You're correct. I said as much in my preceding paragraphs too. It just isn't expressed well here. What it probably ought to say is something like: -- Modifying the language ranges or tags can affect the outcome of the matching operation. -- > If we're clear that we're only talking about such capabilities > being "built in" to the matching algorithm this would be ok, but > I'm concerned that this might be misconstrued as being too strong, > e.g., forbidding an application which used a conformant matching function > from providing these more elaborate / useful services. Let's forget the MUSTard. Question is: should we even mention the whole customization thing? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 2006?4?5? 15:50 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Access to subtag registry by matching applications > > Addison Phillips scripsit: > > > Applications, protocols, or specifications, in addressing their > > particular requirements, can offer pre-processing or configuration > > options. For example, an implementation could allow a user to > > associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' > > (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or > > perhaps the user could associate the range "zh-Hans" (Chinese as written > > in the Simplified script) with the tag "zh-CN" (Chinese as used in > > China, where the Simplified script is predominant). Such customization > > affects the operation of the underlying matching scheme. Conformant > > implementations SHOULD NOT enable such options by default and MUST > > offer a configuration or mode compatible with the unmodified matching > > scheme or schemes described in this document. > > I don't like the last sentence. Enabling such options by default, if they > are good ones, may be just the right thing to do: conformance isn't > anything. > And the second half of the sentence says that a conformant application > MUST offer a conformant mode of operation, which is to say that > conformance > entails conformance. > > > > -- > > > > Thoughts? > > > > Addison > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > > > > -----Original Message----- > > > From: Mark Davis [mailto:mark.davis@icu-project.org] > > > Sent: 2006???4???5??? 11:33 > > > To: Addison Phillips > > > Cc: 'Randy Presuhn'; 'LTRU Working Group' > > > Subject: Re: [Ltru] Access to subtag registry by matching applications > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > -- > But that, he realized, was a foolish John Cowan > thought; as no one knew better than he cowan@ccil.org > that the Wall had no other side. http://www.ccil.org/~cowan > --Arthur C. Clarke, "The Wall of Darkness" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 19:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRH6n-0004qV-Su; Wed, 05 Apr 2006 19:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRH6m-0004q5-Cd for ltru@ietf.org; Wed, 05 Apr 2006 19:08:16 -0400 Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRH6l-00022f-6P for ltru@ietf.org; Wed, 05 Apr 2006 19:08:16 -0400 Received: from h-68-166-37-245.snvacaid.dynamic.covad.net ([68.166.37.245] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FRH6k-0006jC-00 for ltru@ietf.org; Wed, 05 Apr 2006 19:08:14 -0400 Message-ID: <000401c65906$4c035340$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001101c65905$77a0e720$9fcd15ac@ds.corp.yahoo.com> Subject: Re: [Ltru] Access to subtag registry by matching applications Date: Wed, 5 Apr 2006 16:11:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "'John Cowan'" > Cc: > Sent: Wednesday, April 05, 2006 4:05 PM > Subject: RE: [Ltru] Access to subtag registry by matching applications ... > Let's forget the MUSTard. Question is: should we even mention the whole > customization thing? ... I'd be equally happy without that last sentence or without the entire paragraph. I can understand the value of the tutorial material, but don't feel strongly about retaining it. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 19:48:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHjb-000783-Bk; Wed, 05 Apr 2006 19:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHjY-00076J-UG for ltru@ietf.org; Wed, 05 Apr 2006 19:48:21 -0400 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRHjY-0003I5-Mj for ltru@ietf.org; Wed, 05 Apr 2006 19:48:20 -0400 Received: (qmail 94171 invoked from network); 5 Apr 2006 23:48:20 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 5 Apr 2006 23:48:20 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <44345738.1000006@icu-project.org> Date: Wed, 05 Apr 2006 16:48:08 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Eliminating "content" considered harmful References: <20060405225418.GB11928@ccil.org> In-Reply-To: <20060405225418.GB11928@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I disagree. It is perfectly reasonable for us to specify that the result must a language tag. (worst case, it could return "und"). While the point may be to return content, that is, as I've said, a logically separable feature -- no need for us to gum up the description. [The point of the bidi algorithm is to produce Arabic or Hebrew that is ordered corre ctly for the screen, but it is perfectly acceptable for a conformant process to simply produce the reordered text, and leave it to some other process to actually do the rendering on that basis.] Mark John Cowan wrote: > It's fairly easy to cast both filtering algorithms in terms of just working > through a list of ranges and a list of language tags, and Addison has > heroically done so. > > The whole point of the lookup algorithm, though, is to find the best piece > of content given a list of ranges and a set of information items with or > without tags. Saying that lookup is supposed to return just one information > item is correct; saying that it is supposed to return just one language > tag is *not*. The present state of 12a is inconsistent between the > view "return one tag" and "return one tag if you can". > > Cleaning up by making it "return one or zero tags" eliminates the whole > purpose of the lookup algorithm, and requires an entirely new machinery > of justification. > > (Having a matching draft in the first place was stupid; matching should have > been left out, since everything in 3066 on the subject is just a restatement > of 2616, which should have been left in charge. Too late now, I know.) > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 19:50:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHlr-0008BJ-3C; Wed, 05 Apr 2006 19:50:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHlq-0008BD-9A for ltru@ietf.org; Wed, 05 Apr 2006 19:50:42 -0400 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRHlq-0003Lw-1v for ltru@ietf.org; Wed, 05 Apr 2006 19:50:42 -0400 Received: (qmail 93219 invoked from network); 5 Apr 2006 23:44:02 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 5 Apr 2006 23:44:02 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <44345637.9000402@icu-project.org> Date: Wed, 05 Apr 2006 16:43:51 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Access to subtag registry by matching applications References: <44340D6E.4020000@icu-project.org> <001001c65901$3ad62570$9fcd15ac@ds.corp.yahoo.com> <20060405225015.GA11928@ccil.org> In-Reply-To: <20060405225015.GA11928@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree. Most of what Addison suggests is good, but the last sentence is too strong. Should be something like: Conformant implementations MUST specify whether they allow such configuration options, and if so, SHOULD describe the effects they have on the modification process. Mark John Cowan wrote: > Addison Phillips scripsit: > > >> Applications, protocols, or specifications, in addressing their >> particular requirements, can offer pre-processing or configuration >> options. For example, an implementation could allow a user to >> associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' >> (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or >> perhaps the user could associate the range "zh-Hans" (Chinese as written >> in the Simplified script) with the tag "zh-CN" (Chinese as used in >> China, where the Simplified script is predominant). Such customization >> affects the operation of the underlying matching scheme. Conformant >> implementations SHOULD NOT enable such options by default and MUST >> offer a configuration or mode compatible with the unmodified matching >> scheme or schemes described in this document. >> > > I don't like the last sentence. Enabling such options by default, if they > are good ones, may be just the right thing to do: conformance isn't anything. > And the second half of the sentence says that a conformant application > MUST offer a conformant mode of operation, which is to say that conformance > entails conformance. > > (BTW, graf 2 of Section 3 still talks about information items.) > > >> -- >> >> Thoughts? >> >> Addison >> >> Addison Phillips >> Internationalization Architect - Yahoo! Inc. >> >> Internationalization is an architecture. >> It is not a feature. >> >> >>> -----Original Message----- >>> From: Mark Davis [mailto:mark.davis@icu-project.org] >>> Sent: 2006???4???5??? 11:33 >>> To: Addison Phillips >>> Cc: 'Randy Presuhn'; 'LTRU Working Group' >>> Subject: Re: [Ltru] Access to subtag registry by matching applications >>> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> >> >> > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 19:51:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHme-0008Rl-J2; Wed, 05 Apr 2006 19:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHmd-0008Rg-7X for ltru@ietf.org; Wed, 05 Apr 2006 19:51:31 -0400 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRHmb-0003MG-UD for ltru@ietf.org; Wed, 05 Apr 2006 19:51:31 -0400 Received: (qmail 94892 invoked from network); 5 Apr 2006 23:51:29 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 5 Apr 2006 23:51:29 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <443457F3.8050101@icu-project.org> Date: Wed, 05 Apr 2006 16:51:15 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Access to subtag registry by matching applications References: <001101c65905$77a0e720$9fcd15ac@ds.corp.yahoo.com> In-Reply-To: <001101c65905$77a0e720$9fcd15ac@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Let's forget the MUSTard. Question is: should we even mention the whole customization thing? Given that I think that any implementation that *didn't* do some customization would be unacceptable our customers, I think we have to allow for it. See my previous message for suggested rephrasing. Mark Addison Phillips wrote: > John Cowan wrote: > > >> (BTW, graf 2 of Section 3 still talks about information items.) >> > > Good catch. Changed to: > > There are two types of matching scheme in this document. A matching > scheme that produces zero or more matching language tags is called > "filtering". A matching scheme that produces exactly one match for a given > request is called "lookup". > > And also: > > >> I don't like the last sentence. Enabling such options by default, if they >> are good ones, may be just the right thing to do: conformance isn't >> anything. >> > > I don't like it either. > > Randy meanwhile opines: > > >> Not necessarily; it could also be thought of as mapping a single tag into >> a set of tags or ranges before offering them to the matching algorithm. >> > > You're correct. I said as much in my preceding paragraphs too. It just isn't > expressed well here. What it probably ought to say is something like: > > -- > Modifying the language ranges or tags can affect the outcome of the matching > operation. > -- > > >> If we're clear that we're only talking about such capabilities >> being "built in" to the matching algorithm this would be ok, but >> I'm concerned that this might be misconstrued as being too strong, >> e.g., forbidding an application which used a conformant matching function >> from providing these more elaborate / useful services. >> > > Let's forget the MUSTard. Question is: should we even mention the whole > customization thing? > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: John Cowan [mailto:cowan@ccil.org] >> Sent: 2006?4?5? 15:50 >> To: Addison Phillips >> Cc: ltru@ietf.org >> Subject: Re: [Ltru] Access to subtag registry by matching applications >> >> Addison Phillips scripsit: >> >> >>> Applications, protocols, or specifications, in addressing their >>> particular requirements, can offer pre-processing or configuration >>> options. For example, an implementation could allow a user to >>> associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' >>> (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or >>> perhaps the user could associate the range "zh-Hans" (Chinese as written >>> in the Simplified script) with the tag "zh-CN" (Chinese as used in >>> China, where the Simplified script is predominant). Such customization >>> affects the operation of the underlying matching scheme. Conformant >>> implementations SHOULD NOT enable such options by default and MUST >>> offer a configuration or mode compatible with the unmodified matching >>> scheme or schemes described in this document. >>> >> I don't like the last sentence. Enabling such options by default, if they >> are good ones, may be just the right thing to do: conformance isn't >> anything. >> And the second half of the sentence says that a conformant application >> MUST offer a conformant mode of operation, which is to say that >> conformance >> entails conformance. >> >> >> >>> -- >>> >>> Thoughts? >>> >>> Addison >>> >>> Addison Phillips >>> Internationalization Architect - Yahoo! Inc. >>> >>> Internationalization is an architecture. >>> It is not a feature. >>> >>> >>>> -----Original Message----- >>>> From: Mark Davis [mailto:mark.davis@icu-project.org] >>>> Sent: 2006???4???5??? 11:33 >>>> To: Addison Phillips >>>> Cc: 'Randy Presuhn'; 'LTRU Working Group' >>>> Subject: Re: [Ltru] Access to subtag registry by matching applications >>>> >>> _______________________________________________ >>> Ltru mailing list >>> Ltru@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ltru >>> >>> >>> >> -- >> But that, he realized, was a foolish John Cowan >> thought; as no one knew better than he cowan@ccil.org >> that the Wall had no other side. http://www.ccil.org/~cowan >> --Arthur C. Clarke, "The Wall of Darkness" >> > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 20:43:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRIbD-0006M9-RV; Wed, 05 Apr 2006 20:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRIbC-0006M1-Ev for ltru@ietf.org; Wed, 05 Apr 2006 20:43:46 -0400 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRIbB-0005sL-4E for ltru@ietf.org; Wed, 05 Apr 2006 20:43:46 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k360hM4o024609; Wed, 5 Apr 2006 17:43:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=ppYm5B/X7uIlvghU7ARwqBrh6aysoYm8VFjVbzw/2sMnq175KpGW3ypixSgzKN6w From: "Addison Phillips" To: "'Mark Davis'" Subject: RE: [Ltru] Access to subtag registry by matching applications Date: Wed, 5 Apr 2006 17:45:15 -0700 Message-ID: <000301c65913$5f569bc0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZC+K6zdZZ04pMS/2h1T0x6bAiTAAB1IMA In-Reply-To: <443457F3.8050101@icu-project.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Alright. I did a rewrite on your suggestion, though. The paragraph now = reads: -- Applications, protocols, or specifications, in addressing their = particular requirements, can offer pre-processing or configuration = options. For example, an implementation could allow a user to associate = the language subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal = Norwegian) with the more general subtag 'no' (Norwegian). Or perhaps the = user could associate the range "zh-Hans" (Chinese as written in the = Simplified script) with the tag "zh-CN" (Chinese as used in China, where = the Simplified script is predominant). These options will influence the = results of a matching operation, so an application, protocol, or = specification SHOULD document how ranges or tags are altered, = prioritized, or compared in the subsequent match so that users can = modify their tags or language priority lists appropriately. -- Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B44=E6=9C=885=E6=97=A5 16:51 > To: Addison Phillips > Cc: 'John Cowan'; ltru@ietf.org > Subject: Re: [Ltru] Access to subtag registry by matching applications >=20 > > Let's forget the MUSTard. Question is: should we even mention the > whole customization thing? >=20 > Given that I think that any implementation that *didn't* do some > customization would be unacceptable our customers, I think we have to > allow for it. See my previous message for suggested rephrasing. >=20 > Mark >=20 > Addison Phillips wrote: > > John Cowan wrote: > > > > > >> (BTW, graf 2 of Section 3 still talks about information items.) > >> > > > > Good catch. Changed to: > > > > There are two types of matching scheme in this document. A = matching > > scheme that produces zero or more matching language tags is called > > "filtering". A matching scheme that produces exactly one match for a > given > > request is called "lookup". > > > > And also: > > > > > >> I don't like the last sentence. Enabling such options by default, = if > they > >> are good ones, may be just the right thing to do: conformance isn't > >> anything. > >> > > > > I don't like it either. > > > > Randy meanwhile opines: > > > > > >> Not necessarily; it could also be thought of as mapping a single = tag > into > >> a set of tags or ranges before offering them to the matching = algorithm. > >> > > > > You're correct. I said as much in my preceding paragraphs too. It = just > isn't > > expressed well here. What it probably ought to say is something = like: > > > > -- > > Modifying the language ranges or tags can affect the outcome of the > matching > > operation. > > -- > > > > > >> If we're clear that we're only talking about such capabilities > >> being "built in" to the matching algorithm this would be ok, but > >> I'm concerned that this might be misconstrued as being too strong, > >> e.g., forbidding an application which used a conformant matching > function > >> from providing these more elaborate / useful services. > >> > > > > Let's forget the MUSTard. Question is: should we even mention the = whole > > customization thing? > > > > Addison > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > > > > >> -----Original Message----- > >> From: John Cowan [mailto:cowan@ccil.org] > >> Sent: 2006?4?5? 15:50 > >> To: Addison Phillips > >> Cc: ltru@ietf.org > >> Subject: Re: [Ltru] Access to subtag registry by matching = applications > >> > >> Addison Phillips scripsit: > >> > >> > >>> Applications, protocols, or specifications, in addressing their > >>> particular requirements, can offer pre-processing or configuration > >>> options. For example, an implementation could allow a user to > >>> associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' > >>> (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). = Or > >>> perhaps the user could associate the range "zh-Hans" (Chinese as > written > >>> in the Simplified script) with the tag "zh-CN" (Chinese as used in > >>> China, where the Simplified script is predominant). Such = customization > >>> affects the operation of the underlying matching scheme. = Conformant > >>> implementations SHOULD NOT enable such options by default and MUST > >>> offer a configuration or mode compatible with the unmodified = matching > >>> scheme or schemes described in this document. > >>> > >> I don't like the last sentence. Enabling such options by default, = if > they > >> are good ones, may be just the right thing to do: conformance isn't > >> anything. > >> And the second half of the sentence says that a conformant = application > >> MUST offer a conformant mode of operation, which is to say that > >> conformance > >> entails conformance. > >> > >> > >> > >>> -- > >>> > >>> Thoughts? > >>> > >>> Addison > >>> > >>> Addison Phillips > >>> Internationalization Architect - Yahoo! Inc. > >>> > >>> Internationalization is an architecture. > >>> It is not a feature. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Mark Davis [mailto:mark.davis@icu-project.org] > >>>> Sent: 2006???4???5??? 11:33 > >>>> To: Addison Phillips > >>>> Cc: 'Randy Presuhn'; 'LTRU Working Group' > >>>> Subject: Re: [Ltru] Access to subtag registry by matching > applications > >>>> > >>> _______________________________________________ > >>> Ltru mailing list > >>> Ltru@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ltru > >>> > >>> > >>> > >> -- > >> But that, he realized, was a foolish John Cowan > >> thought; as no one knew better than he cowan@ccil.org > >> that the Wall had no other side. > http://www.ccil.org/~cowan > >> --Arthur C. Clarke, "The Wall of Darkness" > >> > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 21:16:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJ6o-0008IB-On; Wed, 05 Apr 2006 21:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJ6n-0008I6-D8 for ltru@ietf.org; Wed, 05 Apr 2006 21:16:25 -0400 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRJ6l-0007UV-Ml for ltru@ietf.org; Wed, 05 Apr 2006 21:16:25 -0400 Received: from h-68-166-37-245.snvacaid.dynamic.covad.net ([68.166.37.245] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FRJ6k-0006lO-00 for ltru@ietf.org; Wed, 05 Apr 2006 21:16:23 -0400 Message-ID: <000401c65918$324e0960$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <000301c65913$5f569bc0$9fcd15ac@ds.corp.yahoo.com> Subject: Re: [Ltru] Access to subtag registry by matching applications Date: Wed, 5 Apr 2006 18:19:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Works for me, though others, finickier than I, might complain about the SHOULD. Randy ----- Original Message ----- From: "Addison Phillips" To: "'Mark Davis'" Cc: Sent: Wednesday, April 05, 2006 5:45 PM Subject: RE: [Ltru] Access to subtag registry by matching applications Alright. I did a rewrite on your suggestion, though. The paragraph now reads: -- Applications, protocols, or specifications, in addressing their particular requirements, can offer pre-processing or configuration options. For example, an implementation could allow a user to associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or perhaps the user could associate the range "zh-Hans" (Chinese as written in the Simplified script) with the tag "zh-CN" (Chinese as used in China, where the Simplified script is predominant). These options will influence the results of a matching operation, so an application, protocol, or specification SHOULD document how ranges or tags are altered, prioritized, or compared in the subsequent match so that users can modify their tags or language priority lists appropriately. -- Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006å¹´4月5æ—¥ 16:51 > To: Addison Phillips > Cc: 'John Cowan'; ltru@ietf.org > Subject: Re: [Ltru] Access to subtag registry by matching applications > > > Let's forget the MUSTard. Question is: should we even mention the > whole customization thing? > > Given that I think that any implementation that *didn't* do some > customization would be unacceptable our customers, I think we have to > allow for it. See my previous message for suggested rephrasing. > > Mark > > Addison Phillips wrote: > > John Cowan wrote: > > > > > >> (BTW, graf 2 of Section 3 still talks about information items.) > >> > > > > Good catch. Changed to: > > > > There are two types of matching scheme in this document. A matching > > scheme that produces zero or more matching language tags is called > > "filtering". A matching scheme that produces exactly one match for a > given > > request is called "lookup". > > > > And also: > > > > > >> I don't like the last sentence. Enabling such options by default, if > they > >> are good ones, may be just the right thing to do: conformance isn't > >> anything. > >> > > > > I don't like it either. > > > > Randy meanwhile opines: > > > > > >> Not necessarily; it could also be thought of as mapping a single tag > into > >> a set of tags or ranges before offering them to the matching algorithm. > >> > > > > You're correct. I said as much in my preceding paragraphs too. It just > isn't > > expressed well here. What it probably ought to say is something like: > > > > -- > > Modifying the language ranges or tags can affect the outcome of the > matching > > operation. > > -- > > > > > >> If we're clear that we're only talking about such capabilities > >> being "built in" to the matching algorithm this would be ok, but > >> I'm concerned that this might be misconstrued as being too strong, > >> e.g., forbidding an application which used a conformant matching > function > >> from providing these more elaborate / useful services. > >> > > > > Let's forget the MUSTard. Question is: should we even mention the whole > > customization thing? > > > > Addison > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > > > > >> -----Original Message----- > >> From: John Cowan [mailto:cowan@ccil.org] > >> Sent: 2006?4?5? 15:50 > >> To: Addison Phillips > >> Cc: ltru@ietf.org > >> Subject: Re: [Ltru] Access to subtag registry by matching applications > >> > >> Addison Phillips scripsit: > >> > >> > >>> Applications, protocols, or specifications, in addressing their > >>> particular requirements, can offer pre-processing or configuration > >>> options. For example, an implementation could allow a user to > >>> associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' > >>> (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or > >>> perhaps the user could associate the range "zh-Hans" (Chinese as > written > >>> in the Simplified script) with the tag "zh-CN" (Chinese as used in > >>> China, where the Simplified script is predominant). Such customization > >>> affects the operation of the underlying matching scheme. Conformant > >>> implementations SHOULD NOT enable such options by default and MUST > >>> offer a configuration or mode compatible with the unmodified matching > >>> scheme or schemes described in this document. > >>> > >> I don't like the last sentence. Enabling such options by default, if > they > >> are good ones, may be just the right thing to do: conformance isn't > >> anything. > >> And the second half of the sentence says that a conformant application > >> MUST offer a conformant mode of operation, which is to say that > >> conformance > >> entails conformance. > >> > >> > >> > >>> -- > >>> > >>> Thoughts? > >>> > >>> Addison > >>> > >>> Addison Phillips > >>> Internationalization Architect - Yahoo! Inc. > >>> > >>> Internationalization is an architecture. > >>> It is not a feature. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Mark Davis [mailto:mark.davis@icu-project.org] > >>>> Sent: 2006???4???5??? 11:33 > >>>> To: Addison Phillips > >>>> Cc: 'Randy Presuhn'; 'LTRU Working Group' > >>>> Subject: Re: [Ltru] Access to subtag registry by matching > applications > >>>> > >>> _______________________________________________ > >>> Ltru mailing list > >>> Ltru@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ltru > >>> > >>> > >>> > >> -- > >> But that, he realized, was a foolish John Cowan > >> thought; as no one knew better than he cowan@ccil.org > >> that the Wall had no other side. > http://www.ccil.org/~cowan > >> --Arthur C. Clarke, "The Wall of Darkness" > >> > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 05 21:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJU1-0001lB-SN; Wed, 05 Apr 2006 21:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJTz-0001l6-W0 for ltru@ietf.org; Wed, 05 Apr 2006 21:40:23 -0400 Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRJTy-0008Sp-JC for ltru@ietf.org; Wed, 05 Apr 2006 21:40:23 -0400 Received: (qmail 58985 invoked from network); 6 Apr 2006 01:40:21 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 6 Apr 2006 01:40:21 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <4434717C.1020301@icu-project.org> Date: Wed, 05 Apr 2006 18:40:12 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Access to subtag registry by matching applications References: <000301c65913$5f569bc0$9fcd15ac@ds.corp.yahoo.com> <000401c65918$324e0960$6401a8c0@oemcomputer> In-Reply-To: <000401c65918$324e0960$6401a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Works for me. Randy Presuhn wrote: > Hi - > > Works for me, though others, finickier than I, might complain > about the SHOULD. > > Randy > > ----- Original Message ----- > From: "Addison Phillips" > To: "'Mark Davis'" > Cc: > Sent: Wednesday, April 05, 2006 5:45 PM > Subject: RE: [Ltru] Access to subtag registry by matching applications > > > Alright. I did a rewrite on your suggestion, though. The paragraph now reads: > > -- > Applications, protocols, or specifications, in addressing their particular requirements, can offer pre-processing or > configuration options. For example, an implementation could allow a user to associate the language subtags 'nn' (Nynorsk Norwegian) > and 'nb' (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or perhaps the user could associate the range "zh-Hans" > (Chinese as written in the Simplified script) with the tag "zh-CN" (Chinese as used in China, where the Simplified script is > predominant). These options will influence the results of a matching operation, so an application, protocol, or specification SHOULD > document how ranges or tags are altered, prioritized, or compared in the subsequent match so that users can modify their tags or > language priority lists appropriately. > -- > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > >> -----Original Message----- >> From: Mark Davis [mailto:mark.davis@icu-project.org] >> Sent: 2006å¹´4月5æ—¥ 16:51 >> To: Addison Phillips >> Cc: 'John Cowan'; ltru@ietf.org >> Subject: Re: [Ltru] Access to subtag registry by matching applications >> >> > Let's forget the MUSTard. Question is: should we even mention the >> whole customization thing? >> >> Given that I think that any implementation that *didn't* do some >> customization would be unacceptable our customers, I think we have to >> allow for it. See my previous message for suggested rephrasing. >> >> Mark >> >> Addison Phillips wrote: >> >>> John Cowan wrote: >>> >>> >>> >>>> (BTW, graf 2 of Section 3 still talks about information items.) >>>> >>>> >>> Good catch. Changed to: >>> >>> There are two types of matching scheme in this document. A matching >>> scheme that produces zero or more matching language tags is called >>> "filtering". A matching scheme that produces exactly one match for a >>> >> given >> >>> request is called "lookup". >>> >>> And also: >>> >>> >>> >>>> I don't like the last sentence. Enabling such options by default, if >>>> >> they >> >>>> are good ones, may be just the right thing to do: conformance isn't >>>> anything. >>>> >>>> >>> I don't like it either. >>> >>> Randy meanwhile opines: >>> >>> >>> >>>> Not necessarily; it could also be thought of as mapping a single tag >>>> >> into >> >>>> a set of tags or ranges before offering them to the matching algorithm. >>>> >>>> >>> You're correct. I said as much in my preceding paragraphs too. It just >>> >> isn't >> >>> expressed well here. What it probably ought to say is something like: >>> >>> -- >>> Modifying the language ranges or tags can affect the outcome of the >>> >> matching >> >>> operation. >>> -- >>> >>> >>> >>>> If we're clear that we're only talking about such capabilities >>>> being "built in" to the matching algorithm this would be ok, but >>>> I'm concerned that this might be misconstrued as being too strong, >>>> e.g., forbidding an application which used a conformant matching >>>> >> function >> >>>> from providing these more elaborate / useful services. >>>> >>>> >>> Let's forget the MUSTard. Question is: should we even mention the whole >>> customization thing? >>> >>> Addison >>> >>> Addison Phillips >>> Internationalization Architect - Yahoo! Inc. >>> >>> Internationalization is an architecture. >>> It is not a feature. >>> >>> >>> >>>> -----Original Message----- >>>> From: John Cowan [mailto:cowan@ccil.org] >>>> Sent: 2006?4?5? 15:50 >>>> To: Addison Phillips >>>> Cc: ltru@ietf.org >>>> Subject: Re: [Ltru] Access to subtag registry by matching applications >>>> >>>> Addison Phillips scripsit: >>>> >>>> >>>> >>>>> Applications, protocols, or specifications, in addressing their >>>>> particular requirements, can offer pre-processing or configuration >>>>> options. For example, an implementation could allow a user to >>>>> associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' >>>>> (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or >>>>> perhaps the user could associate the range "zh-Hans" (Chinese as >>>>> >> written >> >>>>> in the Simplified script) with the tag "zh-CN" (Chinese as used in >>>>> China, where the Simplified script is predominant). Such customization >>>>> affects the operation of the underlying matching scheme. Conformant >>>>> implementations SHOULD NOT enable such options by default and MUST >>>>> offer a configuration or mode compatible with the unmodified matching >>>>> scheme or schemes described in this document. >>>>> >>>>> >>>> I don't like the last sentence. Enabling such options by default, if >>>> >> they >> >>>> are good ones, may be just the right thing to do: conformance isn't >>>> anything. >>>> And the second half of the sentence says that a conformant application >>>> MUST offer a conformant mode of operation, which is to say that >>>> conformance >>>> entails conformance. >>>> >>>> >>>> >>>> >>>>> -- >>>>> >>>>> Thoughts? >>>>> >>>>> Addison >>>>> >>>>> Addison Phillips >>>>> Internationalization Architect - Yahoo! Inc. >>>>> >>>>> Internationalization is an architecture. >>>>> It is not a feature. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Mark Davis [mailto:mark.davis@icu-project.org] >>>>>> Sent: 2006???4???5??? 11:33 >>>>>> To: Addison Phillips >>>>>> Cc: 'Randy Presuhn'; 'LTRU Working Group' >>>>>> Subject: Re: [Ltru] Access to subtag registry by matching >>>>>> >> applications >> >>>>> _______________________________________________ >>>>> Ltru mailing list >>>>> Ltru@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ltru >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> But that, he realized, was a foolish John Cowan >>>> thought; as no one knew better than he cowan@ccil.org >>>> that the Wall had no other side. >>>> >> http://www.ccil.org/~cowan >> >>>> --Arthur C. Clarke, "The Wall of Darkness" >>>> >>>> >>> >>> _______________________________________________ >>> Ltru mailing list >>> Ltru@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ltru >>> >>> >>> >>> > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 06 08:51:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTxE-0002Y8-Vz; Thu, 06 Apr 2006 08:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTxE-0002Y3-84 for ltru@ietf.org; Thu, 06 Apr 2006 08:51:16 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTxC-00077r-Ja for ltru@ietf.org; Thu, 06 Apr 2006 08:51:16 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id AA3D81E1333; Thu, 6 Apr 2006 05:51:09 -0700 (PDT) Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21996-08; Thu, 6 Apr 2006 05:51:06 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 5A3FF1E132B; Thu, 6 Apr 2006 05:51:06 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Apr 2006 05:51:06 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EDB8@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Mark Davis' , Randy Presuhn Subject: RE: [Ltru] Access to subtag registry by matching applications Date: Thu, 6 Apr 2006 05:51:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: amavisd-new at sharplabs.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: Wednesday, April 05, 2006 9:40 PM > To: Randy Presuhn > Cc: LTRU Working Group > Subject: Re: [Ltru] Access to subtag registry by matching = applications >=20 >=20 > Works for me. >=20 > Randy Presuhn wrote: > > Hi - > > > > Works for me, though others, finickier than I, might complain > > about the SHOULD. > > > > Randy > > > > ----- Original Message -----=20 > > From: "Addison Phillips" > > To: "'Mark Davis'" > > Cc: > > Sent: Wednesday, April 05, 2006 5:45 PM > > Subject: RE: [Ltru] Access to subtag registry by matching=20 > applications > > > > > > Alright. I did a rewrite on your suggestion, though. The=20 > paragraph now reads: > > > > -- > > Applications, protocols, or specifications, in=20 > addressing their particular requirements, can offer pre-processing or > > configuration options. For example, an implementation could=20 > allow a user to associate the language subtags 'nn' (Nynorsk=20 > Norwegian) > > and 'nb' (Bokmal Norwegian) with the more general subtag=20 > 'no' (Norwegian). Or perhaps the user could associate the=20 > range "zh-Hans" > > (Chinese as written in the Simplified script) with the tag=20 > "zh-CN" (Chinese as used in China, where the Simplified script is > > predominant). These options will influence the results of a=20 > matching operation, so an application, protocol, or=20 > specification SHOULD > > document how ranges or tags are altered, prioritized, or=20 > compared in the subsequent match so that users can modify=20 > their tags or > > language priority lists appropriately. > > -- > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > =20 > >> -----Original Message----- > >> From: Mark Davis [mailto:mark.davis@icu-project.org] > >> Sent: 2006=E5=B9=B44=E6=9C=885=E6=97=A5 16:51 > >> To: Addison Phillips > >> Cc: 'John Cowan'; ltru@ietf.org > >> Subject: Re: [Ltru] Access to subtag registry by matching=20 > applications > >> > >> > Let's forget the MUSTard. Question is: should we even=20 > mention the > >> whole customization thing? > >> > >> Given that I think that any implementation that *didn't* do some > >> customization would be unacceptable our customers, I think=20 > we have to > >> allow for it. See my previous message for suggested rephrasing. > >> > >> Mark > >> > >> Addison Phillips wrote: > >> =20 > >>> John Cowan wrote: > >>> > >>> > >>> =20 > >>>> (BTW, graf 2 of Section 3 still talks about information items.) > >>>> > >>>> =20 > >>> Good catch. Changed to: > >>> > >>> There are two types of matching scheme in this=20 > document. A matching > >>> scheme that produces zero or more matching language tags is = called > >>> "filtering". A matching scheme that produces exactly one=20 > match for a > >>> =20 > >> given > >> =20 > >>> request is called "lookup". > >>> > >>> And also: > >>> > >>> > >>> =20 > >>>> I don't like the last sentence. Enabling such options=20 > by default, if > >>>> =20 > >> they > >> =20 > >>>> are good ones, may be just the right thing to do:=20 > conformance isn't > >>>> anything. > >>>> > >>>> =20 > >>> I don't like it either. > >>> > >>> Randy meanwhile opines: > >>> > >>> > >>> =20 > >>>> Not necessarily; it could also be thought of as mapping=20 > a single tag > >>>> =20 > >> into > >> =20 > >>>> a set of tags or ranges before offering them to the=20 > matching algorithm. > >>>> > >>>> =20 > >>> You're correct. I said as much in my preceding paragraphs=20 > too. It just > >>> =20 > >> isn't > >> =20 > >>> expressed well here. What it probably ought to say is=20 > something like: > >>> > >>> -- > >>> Modifying the language ranges or tags can affect the=20 > outcome of the > >>> =20 > >> matching > >> =20 > >>> operation. > >>> -- > >>> > >>> > >>> =20 > >>>> If we're clear that we're only talking about such capabilities > >>>> being "built in" to the matching algorithm this would be ok, but > >>>> I'm concerned that this might be misconstrued as being=20 > too strong, > >>>> e.g., forbidding an application which used a conformant matching > >>>> =20 > >> function > >> =20 > >>>> from providing these more elaborate / useful services. > >>>> > >>>> =20 > >>> Let's forget the MUSTard. Question is: should we even=20 > mention the whole > >>> customization thing? > >>> > >>> Addison > >>> > >>> Addison Phillips > >>> Internationalization Architect - Yahoo! Inc. > >>> > >>> Internationalization is an architecture. > >>> It is not a feature. > >>> > >>> > >>> =20 > >>>> -----Original Message----- > >>>> From: John Cowan [mailto:cowan@ccil.org] > >>>> Sent: 2006?4?5? 15:50 > >>>> To: Addison Phillips > >>>> Cc: ltru@ietf.org > >>>> Subject: Re: [Ltru] Access to subtag registry by=20 > matching applications > >>>> > >>>> Addison Phillips scripsit: > >>>> > >>>> > >>>> =20 > >>>>> Applications, protocols, or specifications, in addressing their > >>>>> particular requirements, can offer pre-processing or=20 > configuration > >>>>> options. For example, an implementation could allow a user to > >>>>> associate the language subtags 'nn' (Nynorsk Norwegian) and = 'nb' > >>>>> (Bokmal Norwegian) with the more general subtag 'no'=20 > (Norwegian). Or > >>>>> perhaps the user could associate the range "zh-Hans" (Chinese = as > >>>>> =20 > >> written > >> =20 > >>>>> in the Simplified script) with the tag "zh-CN" (Chinese=20 > as used in > >>>>> China, where the Simplified script is predominant).=20 > Such customization > >>>>> affects the operation of the underlying matching=20 > scheme. Conformant > >>>>> implementations SHOULD NOT enable such options by=20 > default and MUST > >>>>> offer a configuration or mode compatible with the=20 > unmodified matching > >>>>> scheme or schemes described in this document. > >>>>> > >>>>> =20 > >>>> I don't like the last sentence. Enabling such options=20 > by default, if > >>>> =20 > >> they > >> =20 > >>>> are good ones, may be just the right thing to do:=20 > conformance isn't > >>>> anything. > >>>> And the second half of the sentence says that a=20 > conformant application > >>>> MUST offer a conformant mode of operation, which is to say that > >>>> conformance > >>>> entails conformance. > >>>> > >>>> > >>>> > >>>> =20 > >>>>> -- > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Addison > >>>>> > >>>>> Addison Phillips > >>>>> Internationalization Architect - Yahoo! Inc. > >>>>> > >>>>> Internationalization is an architecture. > >>>>> It is not a feature. > >>>>> > >>>>> > >>>>> =20 > >>>>>> -----Original Message----- > >>>>>> From: Mark Davis [mailto:mark.davis@icu-project.org] > >>>>>> Sent: 2006???4???5??? 11:33 > >>>>>> To: Addison Phillips > >>>>>> Cc: 'Randy Presuhn'; 'LTRU Working Group' > >>>>>> Subject: Re: [Ltru] Access to subtag registry by matching > >>>>>> =20 > >> applications > >> =20 > >>>>> _______________________________________________ > >>>>> Ltru mailing list > >>>>> Ltru@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ltru > >>>>> > >>>>> > >>>>> > >>>>> =20 > >>>> -- > >>>> But that, he realized, was a foolish John Cowan > >>>> thought; as no one knew better than he cowan@ccil.org > >>>> that the Wall had no other side. > >>>> =20 > >> http://www.ccil.org/~cowan > >> =20 > >>>> --Arthur C. Clarke, "The Wall of Darkness" > >>>> > >>>> =20 > >>> > >>> _______________________________________________ > >>> Ltru mailing list > >>> Ltru@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ltru > >>> > >>> > >>> > >>> =20 > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > =20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 > --=20 > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release=20 > Date: 4/5/2006 > =20 >=20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 =20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 06 12:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWwh-0005Gt-II; Thu, 06 Apr 2006 12:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWwg-0005Gb-6s; Thu, 06 Apr 2006 12:02:54 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWwc-0005uB-HQ; Thu, 06 Apr 2006 12:02:54 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c182.corp.yahoo.com [10.72.72.182]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k36G1HAB076783; Thu, 6 Apr 2006 09:01:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:x-mailer:x-mimeole:thread-index; b=IHRPVA/Dfg8bSeqFNfHw0gZuLfYhDYkrHeDCZffeLITHPhc55WCrHgmCDsTmh0gC From: "Addison Phillips" To: Date: Thu, 6 Apr 2006 09:03:16 -0700 Message-ID: <002601c65993$9dc3fe90$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0027_01C65958.F1652690" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZk5yAaiha4+ECQf2Qn79p4B1nkQ== X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 10630bbe2fdd343a53fbae031e5d1faa Cc: ltru@ietf.org Subject: [Ltru] Sumission: draft-ietf-ltru-matching-12 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C65958.F1652690 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Dear Editors, Please find attached draft-12 of 'draft-ietf-ltru-matching'. Best Regards, Addison (for the editors) Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. ------=_NextPart_000_0027_01C65958.F1652690 Content-Type: text/plain; name="draft-ietf-ltru-matching-12.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ltru-matching-12.txt" =0A= =0A= =0A= Network Working Group A. Phillips, Ed.=0A= Internet-Draft Yahoo! Inc.=0A= Obsoletes: 3066 (if approved) M. Davis, Ed.=0A= Expires: October 8, 2006 Google=0A= April 6, 2006=0A= =0A= =0A= Matching of Language Tags=0A= draft-ietf-ltru-matching-12=0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on October 8, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= This document describes different mechanisms for comparing and=0A= matching language tags. Possible algorithms for language negotiation=0A= or content selection, filtering, and lookup are described. This=0A= document, in combination with RFC 3066bis (Ed.: replace "3066bis"=0A= with the RFC number assigned to draft-ietf-ltru-registry-14),=0A= replaces RFC 3066, which replaced RFC 1766.=0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 1]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. The Language Range . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2.1. Basic Language Range . . . . . . . . . . . . . . . . . . . 4=0A= 2.2. Extended Language Range . . . . . . . . . . . . . . . . . 5=0A= 2.3. The Language Priority List . . . . . . . . . . . . . . . . 5=0A= 3. Types of Matching . . . . . . . . . . . . . . . . . . . . . . 7=0A= 3.1. Choosing a Type of Matching . . . . . . . . . . . . . . . 7=0A= 3.2. Implementation Considerations . . . . . . . . . . . . . . 8=0A= 3.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 3.3.1. Basic Filtering . . . . . . . . . . . . . . . . . . . 10=0A= 3.3.2. Extended Filtering . . . . . . . . . . . . . . . . . . 10=0A= 3.4. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 12=0A= 3.4.1. Default Values . . . . . . . . . . . . . . . . . . . . 14=0A= 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16=0A= 4.1. Choosing Language Ranges . . . . . . . . . . . . . . . . . 16=0A= 4.2. Meaning of Language Tags and Ranges . . . . . . . . . . . 17=0A= 4.3. Considerations for Private Use Subtags . . . . . . . . . . 17=0A= 4.4. Length Considerations for Language Ranges . . . . . . . . 18=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19=0A= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20=0A= 7. Character Set Considerations . . . . . . . . . . . . . . . . . 21=0A= 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22=0A= 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22=0A= 8.2. Informative References . . . . . . . . . . . . . . . . . . 22=0A= Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24=0A= Intellectual Property and Copyright Statements . . . . . . . . . . 25=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 2]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= Human beings on our planet have, past and present, used a number of=0A= languages. There are many reasons why one would want to identify the=0A= language used when presenting or requesting information or in some=0A= specific set of information items.=0A= =0A= Applications, protocols, or specifications that use language=0A= identifiers, such as the language tags defined in [RFC3066bis],=0A= sometimes need to match language tags to a user's language=0A= preferences.=0A= =0A= This document defines a syntax (called a language range (Section 2))=0A= for specifying items in the user's list of language preferences=0A= (called a language priority list (Section 2.3)), as well as several=0A= schemes for selecting or filtering sets of language tags by comparing=0A= the language tags to the user's preferences. Applications,=0A= protocols, or specifications will have varying needs and requirements=0A= that affect the choice of a suitable matching scheme.=0A= =0A= This document describes: how to indicate a user's preferences using=0A= language ranges; three schemes for matching these ranges to a set of=0A= language tags; and the various practical considerations that apply to=0A= implementing and using these schemes.=0A= =0A= This document, in combination with [RFC3066bis] (Ed.: replace=0A= "3066bis" globally in this document with the RFC number assigned to=0A= draft-ietf-ltru-registry-14), replaces [RFC3066], which replaced=0A= [RFC1766].=0A= =0A= The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 3]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= 2. The Language Range=0A= =0A= Language tags [RFC3066bis] are used to help identify languages,=0A= whether spoken, written, signed, or otherwise signaled, for the=0A= purpose of communication. Applications, protocols, or specifications=0A= that use language tags are often faced with the problem of=0A= identifying sets of content that share certain language attributes.=0A= For example, HTTP/1.1 [RFC2616] describes one such mechanism in its=0A= discussion of the Accept-Language header (Section 14.4), which is=0A= used when selecting content from servers based on the language of=0A= that content.=0A= =0A= It is, thus, useful to have a mechanism for identifying sets of=0A= language tags that share specific attributes. This allows users to=0A= select or filter the language tags based on specific requirements.=0A= Such an identifier is called a "language range".=0A= =0A= There are different types of language range, whose specific=0A= attributes vary according to their application. Language ranges are=0A= similar to language tags: they consist of a sequence of subtags=0A= separated by hyphens. In a language range, each subtag MUST either=0A= be a sequence of ASCII alphanumeric characters or the single=0A= character '*' (%2A, ASTERISK). The character '*' is a "wildcard"=0A= that matches any sequence of subtags. The meaning and uses of=0A= wildcards vary according to the type of language range.=0A= =0A= Language tags and thus language ranges are to be treated as case-=0A= insensitive: there exist conventions for the capitalization of some=0A= of the subtags, but these MUST NOT be taken to carry meaning.=0A= Matching of language tags to language ranges MUST be done in a case-=0A= insensitive manner.=0A= =0A= 2.1. Basic Language Range=0A= =0A= A "basic language range" consists of a sequence of alphanumeric=0A= subtags separated by hyphens. It is defined by the following ABNF=0A= [RFC4234]:=0A= =0A= language-range =3D (1*8ALPHA *("-" 1*8alphanum)) / "*"=0A= alphanum =3D ALPHA / DIGIT=0A= =0A= Basic language ranges (originally described by HTTP/1.1 [RFC2616] and=0A= later [RFC3066]) have the same syntax as an [RFC3066] language tag or=0A= are the single character "*". They differ from the language tags=0A= defined in [RFC3066bis] only in that there is no requirement that=0A= they be "well-formed" or be validated against the IANA Language=0A= Subtag Registry. Such ill-formed ranges will probably not match=0A= anything. Note that the ABNF [RFC4234] in [RFC2616] is incorrect,=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 4]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= since it disallows the use of digits anywhere in the 'language-range'=0A= (see: [RFC2616errata]).=0A= =0A= 2.2. Extended Language Range=0A= =0A= Occasionally users will wish to select a set of language tags based=0A= on the presence of specific subtags. An "extended language range"=0A= describes a user's language preference as an ordered sequence of=0A= subtags. For example, a user might wish to select all language tags=0A= that contain the region subtag 'CH' (Switzerland). Extended language=0A= ranges are useful in specifying a particular sequence of subtags that=0A= appear in the set of matching tags without having to specify all of=0A= the intervening subtags.=0A= =0A= An extended language range can be represented by the following ABNF:=0A= =0A= extended-language-range =3D (1*8ALPHA / "*")=0A= *("-" (1*8alphanum / "*"))=0A= =0A= Figure 2: Extended Language Range=0A= =0A= The wildcard subtag '*' can occur in any position in the extended=0A= language range, where it matches any sequence of subtags that might=0A= occur in that position in a language tag. However, wildcards outside=0A= the first position are ignored by Extended Filtering (see Section=0A= 3.2.2). The use or absence of one or more wildcards cannot be taken=0A= to imply that a certain number of subtags will appear in the matching=0A= set of language tags.=0A= =0A= 2.3. The Language Priority List=0A= =0A= A user's language preferences will often need to specify more than=0A= one language range and thus users often need to specify a prioritized=0A= list of language ranges in order to best reflect their language=0A= preferences. This is especially true for speakers of minority=0A= languages. A speaker of Breton in France, for example, may specify=0A= "br" followed by "fr", meaning that if Breton is available, it is=0A= preferred, but otherwise French is the best alternative. It can get=0A= more complex: a user may wish to fall back from Skolt Sami to=0A= Northern Sami to Finnish.=0A= =0A= A "language priority list" is a prioritized or weighted list of=0A= language ranges. One well known example of such a list is the=0A= "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section=0A= 14.4) and RFC 3282 [RFC3282].=0A= =0A= The various matching operations described in this document include=0A= considerations for using a language priority list. This document=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 5]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= does not define the syntax for a language priority list; defining=0A= such a syntax is the responsibility of the protocol, application, or=0A= specification that uses it. When given as examples in this document,=0A= language priority lists will be shown as a quoted sequence of ranges=0A= separated by commas, like this: "en, fr, zh-Hant" (which would be=0A= read as "English before French before Chinese as written in the=0A= Traditional script").=0A= =0A= A simple list of ranges is considered to be in descending order of=0A= priority. Other language priority lists provide "quality weights"=0A= for the language ranges in order to specify the relative priority of=0A= the user's language preferences. An example of this would be the use=0A= of "q" values in the syntax of the "Accept-Language" header (defined=0A= in [RFC2616], Section 14.4, and [RFC3282]).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 6]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= 3. Types of Matching=0A= =0A= Matching language ranges to language tags can be done in many=0A= different ways. This section describes three such matching schemes,=0A= as well as the considerations for choosing between them. Protocols=0A= and specifications requiring conformance to this specification MUST=0A= clearly indicate the particular mechanism used in selecting or=0A= matching language tags.=0A= =0A= There are two types of matching scheme in this document. A matching=0A= scheme that produces zero or more matching language tags is called=0A= "filtering". A matching scheme that produces exactly one match for a=0A= given request is called "lookup".=0A= =0A= 3.1. Choosing a Type of Matching=0A= =0A= Applications, protocols, and specifications are faced with the=0A= decision of what type of matching to use. Sometimes, different=0A= styles of matching are suited to different kinds of processing within=0A= a particular application or protocol.=0A= =0A= This document describes three types of matching:=0A= =0A= 1. Basic Filtering (Section 3.3.1) matches a language priority list=0A= consisting of basic language ranges (Section 2.1) to sets of=0A= language tags.=0A= =0A= 2. Extended Filtering (Section 3.3.2) matches a language priority=0A= list consisting of extended language ranges (Section 2.2) to sets=0A= of language tags.=0A= =0A= 3. Lookup (Section 3.4) matches a language priority list consisting=0A= of basic language ranges to sets of language tags to find the one=0A= _exact_ language tag that best matches the range.=0A= =0A= Filtering can be used to produce a set of results (such as a=0A= collection of documents) by comparing the user's preferences to a set=0A= of language tags. For example, when performing a search, one might=0A= use filtering to limit the results to items tagged as being in the=0A= French language. Filtering can also be used when deciding whether to=0A= perform a language-sensitive process on some content. For example, a=0A= process might cause paragraphs whose language tag matched the=0A= language range "nl" to be displayed in italics within a document.=0A= =0A= Lookup produces the single result that best matches the user's=0A= preferences from the list of available tags, so it is useful in cases=0A= in which a single item is required (and for which only a single item=0A= can be returned). For example, if a process were to insert a human=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 7]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= readable error message into a protocol header, it might select the=0A= text based on the user's language priority list. Since the process=0A= can return only one item, it must choose a single item and it must=0A= return some item, even if none of the content's language tags match=0A= the language priority list supplied by the user.=0A= =0A= 3.2. Implementation Considerations=0A= =0A= Language tag matching is a tool, and does not by itself specify a=0A= complete procedure for the use of language tags. Such procedures are=0A= intimately tied to the application protocol in which they occur.=0A= When specifying a protocol operation using matching, the protocol=0A= MUST specify:=0A= =0A= o Which type(s) of language tag matching it uses=0A= =0A= o Whether the operation returns a single result (lookup) or a=0A= possibly empty set of results (filtering)=0A= =0A= o For lookup, what the default item is (or the sequence of=0A= operations or configuration information used to determine the=0A= default) when no matching tag is found. For instance, a protocol=0A= might define the result as failure of the operation, an empty=0A= value, returning some protocol defined or implementation defined=0A= default, or returning i-default [RFC2277].=0A= =0A= Applications, protocols, and specifications are not required to=0A= validate or understand any of the semantics of the language tags or=0A= ranges or of the subtags in them, nor do they require access to the=0A= IANA Language Subtag Registry (see Section 3 in [RFC3066bis]). This=0A= simplifies implementation.=0A= =0A= However, designers of applications, protocols, or specifications are=0A= encouraged to use the information from the IANA Language Subtag=0A= Registry to support canonicalizing language tags and ranges in order=0A= to map grandfathered and obsolete tags or subtags into modern=0A= equivalents.=0A= =0A= Applications, protocols, or specifications that canonicalize ranges=0A= MUST either perform matching operations with both the canonical and=0A= original (unmodified) form of the range or MUST also canonicalize=0A= each tag for the purposes of comparison.=0A= =0A= Note that canonicalizing language ranges makes certain operations=0A= impossible. For example, an implementation that canonicalizes the=0A= language range "art-lojban" to use the more modern "jbo" cannot be=0A= used to select just the items with the older tag.=0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 8]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= Applications, protocols, or specifications that use basic ranges=0A= might sometimes receive extended language ranges instead. An=0A= application, protocol, or specification MUST choose to: a) map=0A= extended language ranges to basic ranges using the algorithm below,=0A= b) reject any extended language ranges in the language priority list=0A= that are not valid basic language ranges, or c) treat each extended=0A= language range as if it were a basic language range, which will have=0A= the same result as ignoring them, since these ranges will won't match=0A= any valid language tags.=0A= =0A= An extended language range is mapped to a basic language range as=0A= follows: if the first subtag is a '*' then the entire range is=0A= treated as "*", otherwise each wildcard subtag is removed. For=0A= example, if the language range were "en-*-US", then the range would=0A= be mapped to "en-US".=0A= =0A= Applications, protocols, or specifications, in addressing their=0A= particular requirements, can offer pre-processing or configuration=0A= options. For example, an implementation could allow a user to=0A= associate or map a particular language range to a different value.=0A= Such a user might wish to associate the language range subtags 'nn'=0A= (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general=0A= subtag 'no' (Norwegian). Or perhaps the user could associate the=0A= range "zh-Hans" (Chinese as written in the Simplified script) with=0A= the language tag "zh-CN" (Chinese as used in China, where the=0A= Simplified script is predominant) because content is available with=0A= that tag. Documentation on how the ranges or tags are altered,=0A= prioritized, or compared in the subsequent match in such an=0A= implementation will assist users in making the best configuration=0A= choices.=0A= =0A= 3.3. Filtering=0A= =0A= Filtering is used to select the set of language tags that matches a=0A= given language priority list. It is called "filtering" because this=0A= set might contain no items at all or it might return an arbitrarily=0A= large number of matching items: as many items as match the language=0A= priority list, thus "filtering out" the non-matching items.=0A= =0A= In filtering, each language range represents the _least_ specific=0A= language tag (that is, the language tag with fewest number of=0A= subtags) which is an acceptable match. All of the language tags in=0A= the matching set of tags will have an equal or greater number of=0A= subtags than the language range. Every non-wildcard subtag in the=0A= language range will appear in every one of the matching language=0A= tags. For example, if the language priority list consists of the=0A= range "de-CH", one might see tags such as "de-CH-1996" but one will=0A= never see a tag such as "de" (because the 'CH' subtag is missing).=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 9]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= If the language priority list (see Section 2.3) contains more than=0A= one range, the content returned is typically ordered in descending=0A= level of preference, but it MAY be unordered, according to the needs=0A= of the application or protocol.=0A= =0A= Some examples of applications where filtering might be appropriate=0A= include:=0A= =0A= o Applying a style to sections of a document in a particular set of=0A= languages.=0A= =0A= o Displaying the set of documents containing a particular set of=0A= keywords written in a specific set of languages.=0A= =0A= o Selecting all email items written in a specific set of languages.=0A= =0A= o Selecting audio files spoken in a particular language.=0A= =0A= Filtering seems to imply that there is a semantic relationship=0A= between language tags that share the same prefix. While this is=0A= often the case, it is not always true and users should note that the=0A= set of language tags that match a specific language range do not=0A= necessarily represent mutually intelligible languages.=0A= =0A= 3.3.1. Basic Filtering=0A= =0A= Basic filtering uses basic language ranges. Each basic language=0A= range in the language priority list is considered in turn, according=0A= to priority. A language range matches a particular language tag if,=0A= in a case-insensitive comparison, it exactly equals the tag, or if it=0A= exactly equals a prefix of the tag such that the first character=0A= following the prefix is "-". For example, the language-range "de-de"=0A= matches the language tag "de-DE-1996", but not the language tags "de-=0A= Deva" or "de-Latn-DE".=0A= =0A= The special range "*" in a language priority list matches any tag. A=0A= protocol which uses language ranges MAY specify additional rules=0A= about the semantics of "*"; for instance, HTTP/1.1 [RFC2616]=0A= specifies that the range "*" matches only languages not matched by=0A= any other range within an "Accept-Language" header.=0A= =0A= Basic filtering is identical to the type of matching described in=0A= [RFC3066], Section 2.5 (Language-range).=0A= =0A= 3.3.2. Extended Filtering=0A= =0A= Extended filtering compares extended language ranges to language=0A= tags. Each extended language range in the language priority list is=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 10]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= considered in turn, according to priority. A language range matches=0A= a particular language tag if their list of subtags match. To=0A= determine a match:=0A= =0A= 1. Split both the extended language range and the language tag being=0A= compared into a list of subtags by dividing on the hyphen (%2D)=0A= character. Two subtags match if either they are the same when=0A= compared case-insensitively or the language range's subtag is the=0A= wildcard '*'.=0A= =0A= 2. Begin with the first subtag in each list. If the first subtag in=0A= the range does not match the first subtag in the tag, the overall=0A= match fails. Otherwise, move to the next subtag in both the=0A= range and the tag.=0A= =0A= 3. While there are more subtags left in the language range's list:=0A= =0A= A. If the subtag currently being examined in the range is the=0A= wildcard ('*'), move to the next subtag in the range and=0A= continue with the loop.=0A= =0A= B. Else, if there are no more subtags in the language tag's=0A= list, the match fails.=0A= =0A= C. Else, if the current subtag in the range's list matches the=0A= current subtag in the language tag's list, move to the next=0A= subtag in both lists and continue with the loop.=0A= =0A= D. Else, if the language tag's subtag is a "singleton" (a single=0A= letter or digit, which includes the private-use subtag 'x')=0A= the match fails.=0A= =0A= E. Else, move to the next subtag in the language tag's list and=0A= continue with the loop.=0A= =0A= 4. When the language range's list has no more subtags, the match=0A= succeeds.=0A= =0A= Subtags not specified, including those at the end of the language=0A= range, are thus treated as if assigned the wildcard value '*'. Much=0A= like basic filtering, extended filtering selects content with=0A= arbitrarily long tags that share the same initial subtags as the=0A= language range. In addition, extended filtering selects language=0A= tags that contain any intermediate subtags not specified in the=0A= language range. For example, the extended language range "de-*-DE"=0A= (or its synonym "de-DE") matches all of the following tags:=0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 11]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= de-DE=0A= =0A= de-Latn-DE=0A= =0A= de-Latf-DE=0A= =0A= de-de=0A= =0A= de-DE-x-goethe=0A= =0A= de-Latn-DE-1996=0A= =0A= de-Deva-DE=0A= =0A= The same range does not match any of the following tags for the=0A= reasons shown:=0A= =0A= de (missing 'DE')=0A= =0A= de-x-DE (singleton 'x' occurs before 'DE')=0A= =0A= de-Deva ('Deva' not equal to 'DE')=0A= =0A= Note: [RFC3066bis] defines each type of subtag (language, script,=0A= region, and so forth) according to position, size, and content. This=0A= means that subtags in a language range can only match specific types=0A= of subtags in a language tag. For example, a subtag such as 'Latn'=0A= is always a script subtag (unless it follows a singleton) while a=0A= subtag such as 'nedis' can only match the equivalent variant subtag.=0A= One such difference is that two-letter subtags in initial position=0A= have a different type (language) than two-letter subtags in later=0A= positions (region). This is the reason why a wildcard in the=0A= extended language range is significant in the first position and=0A= subsequently ignored.=0A= =0A= 3.4. Lookup=0A= =0A= Lookup is used to select the single language tag that best matches=0A= the language priority list for a given request. When performing=0A= lookup, each language range in the language priority list is=0A= considered in turn, according to priority. By contrast with=0A= filtering, each language range represents the _most_ specific tag=0A= which is an acceptable match. The first matching tag found,=0A= according to the user's priority, is considered the closest match and=0A= is the item returned. For example, if the language range is "de-ch",=0A= a lookup operation can produce content with the tags "de" or "de-CH"=0A= but never content with the tag "de-CH-1996". If no language tag=0A= matches the request, the "default" value is returned.=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 12]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= For example, if an application inserts some dynamic content into a=0A= document, returning an empty string if there is no exact match is not=0A= an option. Instead, the application "falls back" until it finds a=0A= matching language tag associated with a suitable piece of content to=0A= insert. Examples of lookup might include:=0A= =0A= o Selection of a template containing the text for an automated email=0A= response.=0A= =0A= o Selection of a item containing some text for inclusion in a=0A= particular Web page.=0A= =0A= o Selection of a string of text for inclusion in an error log.=0A= =0A= o Selection of an audio file to play as a prompt in a phone system.=0A= =0A= In the lookup scheme, the language range is progressively truncated=0A= from the end until a matching language tag is located. Single letter=0A= or digit subtags (including both the letter 'x' which introduces=0A= private-use sequences, and the subtags that introduce extensions) are=0A= removed at the same time as their closest trailing subtag. For=0A= example, starting with the range "zh-Hant-CN-x-private1-private2",=0A= the lookup progressively searches for content as shown below:=0A= =0A= Range to match: zh-Hant-CN-x-private1-private2=0A= 1. zh-Hant-CN-x-private1-private2=0A= 2. zh-Hant-CN-x-private1=0A= 3. zh-Hant-CN=0A= 4. zh-Hant=0A= 5. zh=0A= 6. (default)=0A= =0A= Figure 3: Example of a Lookup Fallback Pattern=0A= =0A= This allows some flexibility in finding a match. For example, lookup=0A= provides better results for cases in which content is not available=0A= that exactly matches the user request than if the default language=0A= for the system or content were returned immediately. Language=0A= material is sometimes sparsely populated, so an item might not be=0A= available at every level of tag granularity. "Falling back" through=0A= the subtag sequence provides more opportunity to find a match between=0A= available language tags and the user's request.=0A= =0A= Extensions and unrecognized private-use subtags might be unrelated to=0A= a particular application of lookup. Since these subtags come at the=0A= end of the subtag sequence, they are removed first during the=0A= fallback process and usually pose no barrier to interoperability.=0A= However, an implementation MAY remove these from ranges prior to=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 13]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= performing the lookup (provided the implementation also removes them=0A= from the tags being compared). Such modification is internal to the=0A= implementation and applications, protocols, or specifications SHOULD=0A= NOT remove or modify subtags in content that they return or forward,=0A= because this removes information that might be used elsewhere.=0A= =0A= The special language range "*" matches any language tag. In the=0A= lookup scheme, this range does not convey enough information by=0A= itself to determine which language tag is most appropriate, since it=0A= matches everything. If the language range "*" is followed by other=0A= language ranges, it is skipped. If the language range "*" is the=0A= only one in the language priority list or if no other language range=0A= follows, the default value is computed and returned.=0A= =0A= In some cases, the language priority list might contain one or more=0A= extended language ranges (as, for example, when the same language=0A= priority list is used as input for both lookup and filtering=0A= operations). Wildcard values in an extended language range normally=0A= match any value that can occur in that position in a language tag.=0A= Since only one item can be returned for any given lookup request,=0A= wildcards in a language range have to be processed in a consistent=0A= manner or the same request will produce widely varying results.=0A= Applications, protocols, or specifications that accept extended=0A= language ranges MUST define which item is returned when more than one=0A= item matches the extended language range.=0A= =0A= For example, an implementation could return the matching tag that is=0A= first in ASCII-order. If the language range were "*-CH" and the set=0A= of tags included "de-CH", "fr-CH", and "it-CH", then the tag "de-CH"=0A= would be returned. Another possibility would be for an=0A= implementation to map the extended language ranges to basic ranges.=0A= =0A= 3.4.1. Default Values=0A= =0A= Each application, protocol, or specification MUST define the=0A= defaulting behavior when no tag matches the language priority list.=0A= What this action consists of strongly depends on how lookup is being=0A= applied. Some examples of defaulting behavior might include:=0A= =0A= o return an item with no language tag or an item of a non-linguistic=0A= nature, such as an image or sound=0A= =0A= o return a null string as the language tag value, in cases where the=0A= protocol permits the empty value (see, for example, "xml:lang" in=0A= [XML10])=0A= =0A= o return a particular language tag designated for the operation=0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 14]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= o return the language tag "i-default" (see: [RFC2277])=0A= =0A= o return an error condition or error message=0A= =0A= o return a list of available languages for the user to select from=0A= =0A= When performing lookup using a language priority list, the=0A= progressive search MUST process each language range in the list=0A= before seeking or calculating the default.=0A= =0A= The default value MAY be calculated and might include additional=0A= searching or matching. Applications, protocols, or specifications=0A= can specify different ways in which users can specify or override the=0A= defaults.=0A= =0A= One common way to provide for a default is to allow a specific=0A= language range to be set as the default for a specific type of=0A= request. If this approach is chosen, this language range MUST be=0A= treated as if it were appended to the end of the language priority=0A= list as a whole, rather than after each item in the language priority=0A= list. The application, protocol, or specification MUST also define=0A= the defaulting behavior if that search fails to find a matching tag=0A= or item.=0A= =0A= For example, if a particular user's language priority list were=0A= "fr-FR, zh-Hant" and the program doing the matching had a default=0A= language range of "ja-JP", the program would search as follows:=0A= =0A= 1. fr-FR=0A= 2. fr=0A= 3. zh-Hant // next language=0A= 4. zh=0A= 5. ja-JP // now searching for the default content=0A= 6. ja=0A= 7. (implementation defined default)=0A= =0A= Figure 4: Lookup Using a Language Priority List=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 15]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= 4. Other Considerations=0A= =0A= When working with language ranges and matching schemes, there are=0A= some additional points that may influence the choice of either.=0A= =0A= 4.1. Choosing Language Ranges=0A= =0A= Users indicate their language preferences via the choice of a=0A= language range or the list of language ranges in a language priority=0A= list. The type of matching affects what the best choice is for a=0A= user.=0A= =0A= Most matching schemes make no attempt to process the semantic meaning=0A= of the subtags. The language range is compared, in a case-=0A= insensitive manner, to each language tag being matched, using basic=0A= string processing. Users SHOULD select language ranges that are=0A= well-formed, valid language tags according to [RFC3066bis]=0A= (substituting wildcards as appropriate in extended language ranges).=0A= =0A= Applications are encouraged to canonicalize language tags and ranges=0A= by using the Preferred-Value from the IANA Language Subtag Registry=0A= for tags or subtags which have been deprecated. If the user is=0A= working with content that might use the older form, the user might=0A= want to include both the new and old forms in a language priority=0A= list. For example, the tag "art-lojban" is deprecated. The subtag=0A= 'jbo' is supposed to be used instead, so the user might use it to=0A= form the language range. Or the user might include both in a=0A= language priority list: "jbo, art-lojban".=0A= =0A= Users SHOULD avoid subtags that add no distinguishing value to a=0A= language range. When filtering, the fewer the number of subtags that=0A= appear in the language range, the more content the range will=0A= probably match, while in lookup unnecessary subtags might cause=0A= "better", more-specific content to be skipped in favor of less=0A= specific content. For example, the range "de-Latn-DE" would return=0A= content tagged "de" instead of content tagged "de-DE", even though=0A= the latter is probably a better match.=0A= =0A= Whether a subtag adds distinguishing value can depend on the context=0A= of the request. For example, a user who reads both Simplified and=0A= Traditional Chinese, but who prefers Simplified, might use the range=0A= "zh" for filtering (matching all items that user can read) but "zh-=0A= Hans" for lookup (making sure that user gets the preferred form if=0A= it's available, but the fallback to "zh" will still work). On the=0A= other hand, content in this case should be labeled as "zh-Hans" (or=0A= "zh-Hant" if that applies) for filtering, but for lookup, if there is=0A= either "zh-Hans" content or "zh-Hant" content, then one of them (the=0A= one considered 'default') should also be available under a simple=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 16]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= "zh". Note that the user can create a language priority list "zh-=0A= Hans, zh" that delivers the best possible results for both schemes.=0A= If the user cannot be sure which scheme is being used (or if more=0A= than one might be applied to a given request), the user SHOULD=0A= specify the most specific (largest number of subtags) range first and=0A= then supply shorter prefixes later in the list to ensure that=0A= filtering returns a complete set of tags.=0A= =0A= Many languages are written predominantly in a single script. This is=0A= usually recorded in the Suppress-Script field in that language=0A= subtag's registry entry. For these languages, script subtags SHOULD=0A= NOT be used to form a language range. Thus the language range "en-=0A= Latn" is inappropriate in most cases (because the vast majority of=0A= English documents are written in the Latin script and thus the 'en'=0A= language subtag has a Suppress-Script field for 'Latn' in the=0A= registry).=0A= =0A= When working with tags and ranges, note that extensions and most=0A= private-use subtags are orthogonal to language tag matching, in that=0A= they specify additional attributes of the text not related to the=0A= goals of most matching schemes. Users SHOULD avoid using these=0A= subtags in language ranges, since they interfere with the selection=0A= of available content. When used in language tags (as opposed to=0A= ranges), these subtags normally do not interfere with filtering=0A= (Section 3), since they appear at the end of the tag and will match=0A= all prefixes. Lookup (Section 3.4) implementations are advised to=0A= ignore unrecognized private-use and extension subtags when performing=0A= language tag fallback.=0A= =0A= 4.2. Meaning of Language Tags and Ranges=0A= =0A= Selecting language tags using language ranges requires some=0A= understanding by users of what they are selecting. The meaning of=0A= the various subtags in a language range are identical to their=0A= meaning in a language tag (see Section 4.2 in [RFC3066bis]), with the=0A= addition that the wildcard "*" represents any matching sequence of=0A= values.=0A= =0A= 4.3. Considerations for Private Use Subtags=0A= =0A= Private-use subtags require private agreement between the parties=0A= that intend to use or exchange language tags that use them. They=0A= SHOULD NOT be used in content or protocols intended for general use.=0A= Private-use subtags are simply useless for information exchange=0A= without prior arrangement.=0A= =0A= The value and semantic meaning of private-use tags and of the subtags=0A= used within such a language tag are not defined. Matching private-=0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 17]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= use tags using language ranges or extended language ranges can result=0A= in unpredictable content being returned.=0A= =0A= 4.4. Length Considerations for Language Ranges=0A= =0A= Language ranges are very similar to language tags in terms of content=0A= and usage. The same types of restrictions on length that apply to=0A= language tags can also apply to language ranges. See [RFC3066bis]=0A= Section 4.3 (Length Considerations).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 18]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= 5. IANA Considerations=0A= =0A= This document presents no new or existing considerations for IANA.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 19]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= 6. Security Considerations=0A= =0A= Language ranges used in content negotiation might be used to infer=0A= the nationality of the sender, and thus identify potential targets=0A= for surveillance. In addition, unique or highly unusual language=0A= ranges or combinations of language ranges might be used to track a=0A= specific individual's activities.=0A= =0A= This is a special case of the general problem that anything you send=0A= is visible to the receiving party. It is useful to be aware that=0A= such concerns can exist in some cases.=0A= =0A= The evaluation of the exact magnitude of the threat, and any possible=0A= countermeasures, is left to each application or protocol.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 20]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= 7. Character Set Considerations=0A= =0A= Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN-=0A= MINUS (%x2D). Language ranges also use the character ASTERISK=0A= (%x2A). These characters are present in most character sets, so=0A= presentation or exchange of language tags or ranges should not be=0A= constrained by character set issues.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 21]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= 8. References=0A= =0A= 8.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and=0A= Languages", BCP 18, RFC 2277, January 1998.=0A= =0A= [RFC3066bis]=0A= Phillips, A., Ed. and M. Davis, Ed., "Tags for the=0A= Identification of Languages", October 2005, .=0A= =0A= [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax=0A= Specifications: ABNF", RFC 4234, October 2005.=0A= =0A= 8.2. Informative References=0A= =0A= [RFC1766] Alvestrand, H., "Tags for the Identification of=0A= Languages", RFC 1766, March 1995.=0A= =0A= [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,=0A= Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext=0A= Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.=0A= =0A= [RFC2616errata]=0A= IETF, "HTTP/1.1 Specification Errata", October 2004,=0A= .=0A= =0A= [RFC3066] Alvestrand, H., "Tags for the Identification of=0A= Languages", BCP 47, RFC 3066, January 2001.=0A= =0A= [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,=0A= May 2002.=0A= =0A= [XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0",=0A= February 2004.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 22]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= Appendix A. Acknowledgements=0A= =0A= Any list of contributors is bound to be incomplete; please regard the=0A= following as only a selection from the group of people who have=0A= contributed to make this document what it is today.=0A= =0A= The contributors to [RFC3066bis], [RFC3066] and [RFC1766], each of=0A= which is a precursor to this document, made enormous contributions=0A= directly or indirectly to this document and are generally responsible=0A= for the success of language tags.=0A= =0A= The following people (in alphabetical order by family name)=0A= contributed to this document:=0A= =0A= Harald Alvestrand, Stephane Bortzmeyer, Jeremy Carroll, John Cowan,=0A= Martin Duerst, Frank Ellermann, Doug Ewell, Debbie Garside, Marion=0A= Gunn, Kent Karlsson, Ira McDonald, M. Patton, Randy Presuhn, Eric van=0A= der Poel, Markus Scherer, and many, many others.=0A= =0A= Very special thanks must go to Harald Tveit Alvestrand, who=0A= originated RFCs 1766 and 3066, and without whom this document would=0A= not have been possible.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 23]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= Authors' Addresses=0A= =0A= Addison Phillips (editor)=0A= Yahoo! Inc.=0A= =0A= Email: addison@inter-locale.com=0A= =0A= =0A= Mark Davis (editor)=0A= Google=0A= =0A= Email: mark.davis@macchiato.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 24]=0A= =0C=0A= Internet-Draft ltru-matching April 2006=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2006). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires October 8, 2006 [Page 25]=0A= =0C=0A= ------=_NextPart_000_0027_01C65958.F1652690 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_0027_01C65958.F1652690-- From ltru-bounces@ietf.org Thu Apr 06 12:06:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRX00-0006p1-Gg; Thu, 06 Apr 2006 12:06:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWzz-0006ot-8r for ltru@ietf.org; Thu, 06 Apr 2006 12:06:19 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWzx-00060G-M4 for ltru@ietf.org; Thu, 06 Apr 2006 12:06:19 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c182.corp.yahoo.com [10.72.72.182]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k36G5JSd078057; Thu, 6 Apr 2006 09:05:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=iEKOaSBcXBlprhWIL0PD4MNB7pe23zQhUHr2NAUy4FX/xN7xQNFfwA7KrWH5Kfzr From: "Addison Phillips" To: "'Mark Davis'" , "'Randy Presuhn'" Subject: RE: [Ltru] Access to subtag registry by matching applications Date: Thu, 6 Apr 2006 09:07:17 -0700 Message-ID: <002a01c65994$2d9502d0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZGystEDUH+0vgTsOrkVVn5NBbiAAeMlOA In-Reply-To: <4434717C.1020301@icu-project.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org To address the overzealous MUSTard (SHOULD), I did another minor rewrite = of the para before submitting the text: -- Applications, protocols, or specifications, in addressing their = particular requirements, can offer pre-processing or configuration = options. For example, an implementation could allow a user to associate = or map a particular language range to a different value. Such a user = might wish to associate the language range subtags 'nn' (Nynorsk = Norwegian) and 'nb' (Bokmal Norwegian) with the more general subtag 'no' = (Norwegian). Or perhaps the user could associate the range "zh-Hans" = (Chinese as written in the Simplified script) with the language tag = "zh-CN" (Chinese as used in China, where the Simplified script is = predominant) because content is available with that tag. Documentation = on how the ranges or tags are altered, prioritized, or compared in the = subsequent match in such an implementation will assist users in making = the best configuration choices. -- Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B44=E6=9C=885=E6=97=A5 18:40 > To: Randy Presuhn > Cc: LTRU Working Group > Subject: Re: [Ltru] Access to subtag registry by matching applications >=20 > Works for me. >=20 > Randy Presuhn wrote: > > Hi - > > > > Works for me, though others, finickier than I, might complain > > about the SHOULD. > > > > Randy > > > > ----- Original Message ----- > > From: "Addison Phillips" > > To: "'Mark Davis'" > > Cc: > > Sent: Wednesday, April 05, 2006 5:45 PM > > Subject: RE: [Ltru] Access to subtag registry by matching = applications > > > > > > Alright. I did a rewrite on your suggestion, though. The paragraph = now > reads: > > > > -- > > Applications, protocols, or specifications, in addressing their > particular requirements, can offer pre-processing or > > configuration options. For example, an implementation could allow a = user > to associate the language subtags 'nn' (Nynorsk Norwegian) > > and 'nb' (Bokmal Norwegian) with the more general subtag 'no' > (Norwegian). Or perhaps the user could associate the range "zh-Hans" > > (Chinese as written in the Simplified script) with the tag "zh-CN" > (Chinese as used in China, where the Simplified script is > > predominant). These options will influence the results of a matching > operation, so an application, protocol, or specification SHOULD > > document how ranges or tags are altered, prioritized, or compared in = the > subsequent match so that users can modify their tags or > > language priority lists appropriately. > > -- > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > > >> -----Original Message----- > >> From: Mark Davis [mailto:mark.davis@icu-project.org] > >> Sent: 2006=E5=B9=B44=E6=9C=885=E6=97=A5 16:51 > >> To: Addison Phillips > >> Cc: 'John Cowan'; ltru@ietf.org > >> Subject: Re: [Ltru] Access to subtag registry by matching = applications > >> > >> > Let's forget the MUSTard. Question is: should we even mention = the > >> whole customization thing? > >> > >> Given that I think that any implementation that *didn't* do some > >> customization would be unacceptable our customers, I think we have = to > >> allow for it. See my previous message for suggested rephrasing. > >> > >> Mark > >> > >> Addison Phillips wrote: > >> > >>> John Cowan wrote: > >>> > >>> > >>> > >>>> (BTW, graf 2 of Section 3 still talks about information items.) > >>>> > >>>> > >>> Good catch. Changed to: > >>> > >>> There are two types of matching scheme in this document. A = matching > >>> scheme that produces zero or more matching language tags is called > >>> "filtering". A matching scheme that produces exactly one match for = a > >>> > >> given > >> > >>> request is called "lookup". > >>> > >>> And also: > >>> > >>> > >>> > >>>> I don't like the last sentence. Enabling such options by = default, if > >>>> > >> they > >> > >>>> are good ones, may be just the right thing to do: conformance = isn't > >>>> anything. > >>>> > >>>> > >>> I don't like it either. > >>> > >>> Randy meanwhile opines: > >>> > >>> > >>> > >>>> Not necessarily; it could also be thought of as mapping a single = tag > >>>> > >> into > >> > >>>> a set of tags or ranges before offering them to the matching > algorithm. > >>>> > >>>> > >>> You're correct. I said as much in my preceding paragraphs too. It = just > >>> > >> isn't > >> > >>> expressed well here. What it probably ought to say is something = like: > >>> > >>> -- > >>> Modifying the language ranges or tags can affect the outcome of = the > >>> > >> matching > >> > >>> operation. > >>> -- > >>> > >>> > >>> > >>>> If we're clear that we're only talking about such capabilities > >>>> being "built in" to the matching algorithm this would be ok, but > >>>> I'm concerned that this might be misconstrued as being too = strong, > >>>> e.g., forbidding an application which used a conformant matching > >>>> > >> function > >> > >>>> from providing these more elaborate / useful services. > >>>> > >>>> > >>> Let's forget the MUSTard. Question is: should we even mention the > whole > >>> customization thing? > >>> > >>> Addison > >>> > >>> Addison Phillips > >>> Internationalization Architect - Yahoo! Inc. > >>> > >>> Internationalization is an architecture. > >>> It is not a feature. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: John Cowan [mailto:cowan@ccil.org] > >>>> Sent: 2006?4?5? 15:50 > >>>> To: Addison Phillips > >>>> Cc: ltru@ietf.org > >>>> Subject: Re: [Ltru] Access to subtag registry by matching > applications > >>>> > >>>> Addison Phillips scripsit: > >>>> > >>>> > >>>> > >>>>> Applications, protocols, or specifications, in addressing their > >>>>> particular requirements, can offer pre-processing or = configuration > >>>>> options. For example, an implementation could allow a user to > >>>>> associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb' > >>>>> (Bokmal Norwegian) with the more general subtag 'no' = (Norwegian). Or > >>>>> perhaps the user could associate the range "zh-Hans" (Chinese as > >>>>> > >> written > >> > >>>>> in the Simplified script) with the tag "zh-CN" (Chinese as used = in > >>>>> China, where the Simplified script is predominant). Such > customization > >>>>> affects the operation of the underlying matching scheme. = Conformant > >>>>> implementations SHOULD NOT enable such options by default and = MUST > >>>>> offer a configuration or mode compatible with the unmodified > matching > >>>>> scheme or schemes described in this document. > >>>>> > >>>>> > >>>> I don't like the last sentence. Enabling such options by = default, if > >>>> > >> they > >> > >>>> are good ones, may be just the right thing to do: conformance = isn't > >>>> anything. > >>>> And the second half of the sentence says that a conformant > application > >>>> MUST offer a conformant mode of operation, which is to say that > >>>> conformance > >>>> entails conformance. > >>>> > >>>> > >>>> > >>>> > >>>>> -- > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Addison > >>>>> > >>>>> Addison Phillips > >>>>> Internationalization Architect - Yahoo! Inc. > >>>>> > >>>>> Internationalization is an architecture. > >>>>> It is not a feature. > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Mark Davis [mailto:mark.davis@icu-project.org] > >>>>>> Sent: 2006???4???5??? 11:33 > >>>>>> To: Addison Phillips > >>>>>> Cc: 'Randy Presuhn'; 'LTRU Working Group' > >>>>>> Subject: Re: [Ltru] Access to subtag registry by matching > >>>>>> > >> applications > >> > >>>>> _______________________________________________ > >>>>> Ltru mailing list > >>>>> Ltru@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ltru > >>>>> > >>>>> > >>>>> > >>>>> > >>>> -- > >>>> But that, he realized, was a foolish John Cowan > >>>> thought; as no one knew better than he cowan@ccil.org > >>>> that the Wall had no other side. > >>>> > >> http://www.ccil.org/~cowan > >> > >>>> --Arthur C. Clarke, "The Wall of Darkness" > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Ltru mailing list > >>> Ltru@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ltru > >>> > >>> > >>> > >>> > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 07 07:01:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRoil-0000NF-QL; Fri, 07 Apr 2006 07:01:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRoik-0000N9-7R for ltru@ietf.org; Fri, 07 Apr 2006 07:01:42 -0400 Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRoii-00087l-VE for ltru@ietf.org; Fri, 07 Apr 2006 07:01:42 -0400 Received: (qmail 48864 messnum 2901306 invoked from network[194.125.174.81/ts09-081.dublin.indigo.ie]); 7 Apr 2006 11:01:35 -0000 Received: from ts09-081.dublin.indigo.ie (HELO egt.ie) (194.125.174.81) by mail06.svc.cra.dublin.eircom.net (qp 48864) with SMTP; 7 Apr 2006 11:01:35 -0000 Message-ID: <4436461B.B2D7A6F@egt.ie> Date: Fri, 07 Apr 2006 11:59:38 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: 'LTRU Working Group' Subject: Re: [Ltru] Access to subtag registry by matching applications References: <002a01c65994$2d9502d0$660a0a0a@ds.corp.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Typographical comment: I'd like to see the full stop after '(Norwegan)' replaced with either a comma or a a semi-colon. Reason: I think starting a sentence with 'Or' is rather too dramatic in the context (good for effect, bad for continuity). I'd also prefer 'the user may' to 'perhaps the user could', the former being better EN-ISO (more authoritive, less casual language), IMHO. Hope this helps, mg Scríobh Addison Phillips: > > To address the overzealous MUSTard (SHOULD), I did another minor rewrite of the para before submitting the text: > > -- > Applications, protocols, or specifications, in addressing their particular requirements, can offer pre-processing or configuration options. For example, an implementation could allow a user to associate or map a particular language range to a different value. Such a user might wish to associate the language range subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or perhaps the user could... > > >>>>> -- > > >>>>> > > >>>>> Thoughts? > > >>>>> > > >>>>> Addison -- Marion Gunn * EGTeo (Estab.1991) 27 Páirc an Fhéithlinn, Baile an Bhóthair, Co. Átha Cliath, Éire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 07 09:48:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrJz-0007tn-LL; Fri, 07 Apr 2006 09:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrJz-0007td-0N for ltru@ietf.org; Fri, 07 Apr 2006 09:48:19 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRrJv-0005Ak-OQ for ltru@ietf.org; Fri, 07 Apr 2006 09:48:18 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060407134815.FWCG23465.mta10.adelphia.net@DGBP7M81> for ; Fri, 7 Apr 2006 09:48:15 -0400 Message-ID: <004401c65a49$e9cd0dc0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Subject: Re: [Ltru] Access to subtag registry by matching applications Date: Fri, 7 Apr 2006 06:48:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: > Typographical comment: I'd like to see the full stop after > '(Norwegan)' replaced with either a comma or a a semi-colon. Reason: > I think starting a sentence with 'Or' is rather too dramatic in the > context (good for effect, bad for continuity). I think he was just trying to break up one long sentence with two parallel thoughts. Personally I didn't see it as dramatic; it's consistent with Addison's writing style. > I'd also prefer 'the user may' to 'perhaps the user could', the former > being better EN-ISO (more authoritive, less casual language), IMHO. He MAY have been trying to avoid the appearance of an RFC 2119 MAY. We could easily continue wordsmithing this document for the rest of our natural lives if we so choose. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 07 10:58:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsPo-0001hy-4Q; Fri, 07 Apr 2006 10:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsPn-0001ht-B2 for ltru@ietf.org; Fri, 07 Apr 2006 10:58:23 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsPm-0007o5-3T for ltru@ietf.org; Fri, 07 Apr 2006 10:58:23 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c29.corp.yahoo.com [10.72.76.29]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k37Ew2kR080554; Fri, 7 Apr 2006 07:58:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:in-reply-to; b=jI0hfx6XSN2JlLO88wQj8L8z0uCYdUcLrx9KGcFiW+wxd0w7c9WJEyPLiGV7ALcn From: "Addison Phillips" To: "'Marion Gunn'" Subject: RE: [Ltru] Access to subtag registry by matching applications Date: Fri, 7 Apr 2006 07:59:29 -0700 Message-ID: <000701c65a53$dfa97d10$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZaMrlHwU0QaYBfQ7uhSBlL5VBinQAH2yhg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <4436461B.B2D7A6F@egt.ie> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, Integrating the two sentences into one would make a rather long run-on sentence. Besides: a little drama in an RFC is probably a good thing. = This stuff tends to be rather dry. Regarding the second comment, the word "may" has special meaning in an = RFC. It is an RFC 2119 keyword. In this particular set of documents we = editors have been trying to avoid these keywords except when they are = intentionally normative. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Marion Gunn [mailto:mgunn@egt.ie] > Sent: 2006?4?7? 4:00 > Cc: 'LTRU Working Group' > Subject: Re: [Ltru] Access to subtag registry by matching applications >=20 > Typographical comment: I'd like to see the full stop after = '(Norwegan)' > replaced with either a comma or a a semi-colon. Reason: I think = starting > a sentence with 'Or' is rather too dramatic in the context (good for > effect, bad for continuity). >=20 > I'd also prefer 'the user may' to 'perhaps the user could', the former > being better EN-ISO (more authoritive, less casual language), IMHO. >=20 > Hope this helps, > mg >=20 > Scr=EDobh Addison Phillips: > > > > To address the overzealous MUSTard (SHOULD), I did another minor = rewrite > of the para before submitting the text: > > > > -- > > Applications, protocols, or specifications, in addressing their > particular requirements, can offer pre-processing or configuration options. > For example, an implementation could allow a user to associate or map = a > particular language range to a different value. Such a user might wish = to > associate the language range subtags 'nn' (Nynorsk Norwegian) and 'nb' > (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or > perhaps the user could... > > > >>>>> -- > > > >>>>> > > > >>>>> Thoughts? > > > >>>>> > > > >>>>> Addison >=20 > -- >=20 > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 10 06:04:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FStG7-000573-28; Mon, 10 Apr 2006 06:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FStG5-00056y-Tn for ltru@ietf.org; Mon, 10 Apr 2006 06:04:33 -0400 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FStG4-0001Th-L9 for ltru@ietf.org; Mon, 10 Apr 2006 06:04:33 -0400 Received: (qmail 8201 messnum 2894502 invoked from network[194.125.174.85/ts09-085.dublin.indigo.ie]); 10 Apr 2006 10:04:30 -0000 Received: from ts09-085.dublin.indigo.ie (HELO egt.ie) (194.125.174.85) by mail07.svc.cra.dublin.eircom.net (qp 8201) with SMTP; 10 Apr 2006 10:04:30 -0000 Message-ID: <443A2D39.CFC803FB@egt.ie> Date: Mon, 10 Apr 2006 11:02:34 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: LTRU Working Group Subject: Re: [Ltru] Access to subtag registry by matching applications References: <004401c65a49$e9cd0dc0$040aa8c0@DGBP7M81> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All too true (I agree). We could, if we so chose. mg Scríobh Doug Ewell: > > Marion Gunn wrote: > > > Typographical comment: I'd like to see the full stop after > > '(Norwegan)' replaced with either a comma or a a semi-colon. Reason: > > I think starting a sentence with 'Or' is rather too dramatic in the > > context (good for effect, bad for continuity). > > I think he was just trying to break up one long sentence with two > parallel thoughts. Personally I didn't see it as dramatic; it's > consistent with Addison's writing style. > > > I'd also prefer 'the user may' to 'perhaps the user could', the former > > being better EN-ISO (more authoritive, less casual language), IMHO. > > He MAY have been trying to avoid the appearance of an RFC 2119 MAY. > > We could easily continue wordsmithing this document for the rest of our > natural lives if we so choose. > > -- > Doug Ewell -- Marion Gunn * EGTeo (Estab.1991) 27 Páirc an Fhéithlinn, Baile an Bhóthair, Co. Átha Cliath, Éire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 10 18:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5D0-0005Cm-JO; Mon, 10 Apr 2006 18:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5Cu-0005Aq-7o; Mon, 10 Apr 2006 18:50:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5Cr-0000Gh-U5; Mon, 10 Apr 2006 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3AMo1vP002670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Apr 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FT5Cr-0000Ze-Ge; Mon, 10 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 10 Apr 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-12.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Matching of Language Tags Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-matching-12.txt Pages : 25 Date : 2006-4-10 This document describes different mechanisms for comparing and matching language tags. Possible algorithms for language negotiation or content selection, filtering, and lookup are described. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-matching-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-matching-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-10152229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-10152229.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Tue Apr 11 15:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOMy-00005B-Lb; Tue, 11 Apr 2006 15:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOMy-000056-1E for ltru@ietf.org; Tue, 11 Apr 2006 15:17:44 -0400 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTOMx-0006JK-Os for ltru@ietf.org; Tue, 11 Apr 2006 15:17:44 -0400 Received: (qmail 70026 invoked from network); 11 Apr 2006 19:17:43 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 11 Apr 2006 19:17:43 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <443C00DE.5000506@icu-project.org> Date: Tue, 11 Apr 2006 12:17:50 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] I-D ACTION:draft-ietf-ltru-matching-12.txt References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin, how are we doing? Can we advance this now? Mark Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Language Tag Registry Update Working Group of the IETF. > > Title : Matching of Language Tags > Author(s) : A. Phillips, M. Davis > Filename : draft-ietf-ltru-matching-12.txt > Pages : 25 > Date : 2006-4-10 > > This document describes different mechanisms for comparing and > matching language tags. Possible algorithms for language negotiation > or content selection, filtering, and lookup are described. This > document, in combination with RFC 3066bis (Ed.: replace "3066bis" > with the RFC number assigned to draft-ietf-ltru-registry-14), > replaces RFC 3066, which replaced RFC 1766. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ltru-matching-12.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ltru-matching-12.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 18 10:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVqmZ-0000ZL-PQ; Tue, 18 Apr 2006 10:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVqmY-0000Z6-Hg for ltru@ietf.org; Tue, 18 Apr 2006 10:02:18 -0400 Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVqmW-0000XK-7N for ltru@ietf.org; Tue, 18 Apr 2006 10:02:18 -0400 Received: (qmail 90601 invoked from network); 18 Apr 2006 14:02:13 -0000 Received: from unknown (HELO ?192.168.1.103?) (unknown) by unknown with SMTP; 18 Apr 2006 14:02:13 -0000 X-pair-Authenticated: 67.160.251.31 Message-ID: <4444F150.7080507@icu-project.org> Date: Tue, 18 Apr 2006 07:01:52 -0700 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] I-D ACTION:draft-ietf-ltru-matching-12.txt X-Priority: 1 (Highest) References: <443C00DE.5000506@icu-project.org> In-Reply-To: <443C00DE.5000506@icu-project.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote (2006-04-11 12:17): > Martin, how are we doing? Can we advance this now? > > Mark > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Language Tag Registry Update Working >> Group of the IETF. >> >> Title : Matching of Language Tags >> Author(s) : A. Phillips, M. Davis >> Filename : draft-ietf-ltru-matching-12.txt >> Pages : 25 >> Date : 2006-4-10 >> >> This document describes different mechanisms for comparing and >> matching language tags. Possible algorithms for language negotiation >> or content selection, filtering, and lookup are described. This >> document, in combination with RFC 3066bis (Ed.: replace "3066bis" >> with the RFC number assigned to draft-ietf-ltru-registry-14), >> replaces RFC 3066, which replaced RFC 1766. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of the message. You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >> subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-ltru-matching-12.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-ltru-matching-12.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 19 02:38:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW6Kn-0005lO-GQ; Wed, 19 Apr 2006 02:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW6Km-0005hq-HM for ltru@ietf.org; Wed, 19 Apr 2006 02:38:40 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW6Ki-0000vE-9U for ltru@ietf.org; Wed, 19 Apr 2006 02:38:40 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060419063835.TYEL10520.mta11.adelphia.net@DGBP7M81> for ; Wed, 19 Apr 2006 02:38:35 -0400 Message-ID: <01a001c6637b$e0133440$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 18 Apr 2006 23:38:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: I-D ACTION:draft-ietf-ltru-matching-12.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > Mark Davis wrote (2006-04-11 12:17): >> Martin, how are we doing? Can we advance this now? I'm with Mark. What is causing the delay? There were some genuine philosophical differences two weeks ago that led to substantive rewording. Draft-12 was submitted on April 6 and published as an I-D on April 10. Since then it has garnered no discussion of any sort. Whether this reflects apathy or a genuine lack of fault in the current document, if there are no objections, it should be moved to WGLC and onward to the IETF as soon as possible. Failure to do this serves only to delay the publication of the whole of RFC 3066bis, costing it credibility as users and protocols stay with RFC 3066 rather than adopt a yet-unnumbered successor. I reiterate that I have no objection to the matching draft in its current form. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 19 11:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWF4z-0001Cy-9C; Wed, 19 Apr 2006 11:58:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWF4x-0001CT-Mz for ltru@ietf.org; Wed, 19 Apr 2006 11:58:55 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWF4w-0001dq-9a for ltru@ietf.org; Wed, 19 Apr 2006 11:58:55 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id 6436F1E13C4; Wed, 19 Apr 2006 08:58:53 -0700 (PDT) Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13301-11; Wed, 19 Apr 2006 08:58:50 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 809511E13BF; Wed, 19 Apr 2006 08:58:50 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <25PCCY7G>; Wed, 19 Apr 2006 08:58:50 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EDD8@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Doug Ewell' , LTRU Working Group Subject: RE: [Ltru] Re: I-D ACTION:draft-ietf-ltru-matching-12.txt Date: Wed, 19 Apr 2006 08:58:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Virus-Scanned: amavisd-new at sharplabs.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Let's move it to a very quick WG last call and get it into IETF last call ASAP. The recent impressive cleanup of the conformance words satisfies my only remaining reservations about this document. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Wednesday, April 19, 2006 2:39 AM > To: LTRU Working Group > Subject: [Ltru] Re: I-D ACTION:draft-ietf-ltru-matching-12.txt > > > Mark Davis wrote: > > > Mark Davis wrote (2006-04-11 12:17): > >> Martin, how are we doing? Can we advance this now? > > I'm with Mark. What is causing the delay? > > There were some genuine philosophical differences two weeks > ago that led > to substantive rewording. Draft-12 was submitted on April 6 and > published as an I-D on April 10. Since then it has garnered no > discussion of any sort. > > Whether this reflects apathy or a genuine lack of fault in > the current > document, if there are no objections, it should be moved to WGLC and > onward to the IETF as soon as possible. Failure to do this > serves only > to delay the publication of the whole of RFC 3066bis, costing it > credibility as users and protocols stay with RFC 3066 rather > than adopt > a yet-unnumbered successor. > > I reiterate that I have no objection to the matching draft in its > current form. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.4.4/318 - Release > Date: 4/18/2006 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.4/318 - Release Date: 4/18/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 23 23:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXs16-00043K-9g; Sun, 23 Apr 2006 23:45:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXs14-00043F-Hk for ltru@ietf.org; Sun, 23 Apr 2006 23:45:38 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXs12-00020u-VX for ltru@ietf.org; Sun, 23 Apr 2006 23:45:38 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k3O3jVM0015890; Mon, 24 Apr 2006 12:45:31 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7b49_c764f5f8_d344_11da_913c_0014221f2a2d; Mon, 24 Apr 2006 12:45:31 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k3O3g4wp012936; Mon, 24 Apr 2006 12:44:46 +0900 Message-Id: <6.0.0.20.2.20060423145959.0715bdb0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 23 Apr 2006 15:02:02 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Ltru] Fwd: LTRU Milestones past due (matching draft to IETF Last Call) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear WG, I received the following a few days ago. I propose that we ask for an extension until the end of May. I am quite confident that we should be able to make that deadline. Regards, Martin. >To: "LTRU Chair" ,"LTRU Chair" > >Cc: "APP ADs" , "APP ADs" >From: "WG Milestone Tracker" >Subject: LTRU Milestones past due >Date: Sat, 15 Apr 2006 02:30:02 -0400 > > >Dear LTRU Working Group Chair(s): > >Below is a list of the LTRU Working Group milestones that are past due. >Please be reminded that changes to existing milestones or due dates require >Area Director approval. Therefore, please send comments, requests, or >status reports regarding these milestones directly to your Area Directors. > >To report that a milestone has been achieved, please send a message to >iesg-secretary@ietf.org with the name of the milestone and the completion >date. If you do not provide a completion date, then the completion date >recorded will be the date that your message is received. > >The IESG Secretariat >-------------------------------------------------------------------------------------- > >Past Due Milestones: > >Oct 2005 Submit matching algorithms draft for IETF Last Call >-------------------------------------------------------------------------------------- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 25 00:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYFOE-0000Yv-SN; Tue, 25 Apr 2006 00:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYFOD-0000Yq-UY for ltru@ietf.org; Tue, 25 Apr 2006 00:43:05 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYFOC-0007yt-Kr for ltru@ietf.org; Tue, 25 Apr 2006 00:43:05 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060425044257.RXAE27153.mta13.adelphia.net@DGBP7M81> for ; Tue, 25 Apr 2006 00:42:57 -0400 Message-ID: <006301c66822$b733a630$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 24 Apr 2006 21:42:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Fwd: LTRU Milestones past due (matching draft to IETF Last Call) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I received the following a few days ago. I propose that we ask for an > extension until the end of May. I am quite confident that we should be > able to make that deadline. Mark Davis and I have been asking to have draft-matching advanced to WG Last Call for a few weeks now, with no response. No additional comments have appeared on the list since Addison submitted draft-matching-12 on April 6. Without this delay, we might have been able to hit the end of April. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 26 00:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYbXN-0002Q7-Fx; Wed, 26 Apr 2006 00:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYbXN-0002Q2-1X for ltru@ietf.org; Wed, 26 Apr 2006 00:22:01 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYbXL-0007U2-R1 for ltru@ietf.org; Wed, 26 Apr 2006 00:22:01 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060426042159.ZOJG10520.mta11.adelphia.net@DGBP7M81>; Wed, 26 Apr 2006 00:21:59 -0400 Message-ID: <002001c668e8$f4ecd160$040aa8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" Date: Tue, 25 Apr 2006 21:21:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] New version of Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just a quick note that IANA has published an updated version of the Language Subtag Registry, dated 2006-04-19. with a "Comments" field added to region subtag GB, as requested by Debbie Garside. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru