IETF Logo Mail Archive

Re: [Ltru] Macrolanguage usage [OT?]

"Phillips, Addison" <addison@amazon.com> Fri, 16 May 2008 00:12 UTC

Return-Path: <ltru-bounces@ietf.org>
X-Original-To: ltru-archive@megatron.ietf.org
Delivered-To: ietfarch-ltru-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9FD3A6A18; Thu, 15 May 2008 17:12:05 -0700 (PDT)
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409F73A68EF for <ltru@core3.amsl.com>; Thu, 15 May 2008 17:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.669
X-Spam-Level:
X-Spam-Status: No, score=-106.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXdOmPxUhbXl for <ltru@core3.amsl.com>; Thu, 15 May 2008 17:12:03 -0700 (PDT)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by core3.amsl.com (Postfix) with ESMTP id 09DED3A6882 for <ltru@ietf.org>; Thu, 15 May 2008 17:12:02 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.25,459,1199664000"; d="scan'208";a="45227197"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2008 00:11:57 +0000
Received: from ex-hub-4103.ant.amazon.com (ex-hub-4103.sea5.amazon.com [10.248.163.24]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id m4G0BuBX001679 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 16 May 2008 00:11:57 GMT
Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.28]) by ex-hub-4103.ant.amazon.com ([10.248.163.24]) with mapi; Thu, 15 May 2008 17:11:56 -0700
From: "Phillips, Addison" <addison@amazon.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>, LTRU Working Group <ltru@ietf.org>
Date: Thu, 15 May 2008 17:11:55 -0700
Thread-Topic: [Ltru] Macrolanguage usage [OT?]
Thread-Index: Aci25PFvrOfIUOCBQ+Gs+WumkevTyQAALE9A
Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA013A118BF6@EX-SEA5-D.ant.amazon.com>
References: <30b660a20805150829hda2c1e4p114504a973843543@mail.gmail.com><C9BF0238EED3634BA1866AEF14C7A9E56155D47AF4@NA-EXMSG-C116.redmond.corp.microsoft.com><30b660a20805151400g7f84bc7em81304f19c6b969cc@mail.gmail.com><C9BF0238EED3634BA1866AEF14C7A9E56155D47BB5@NA-EXMSG-C116.redmond.corp.microsoft.com><30b660a20805151431w4a2f47dem32d566b26ee4a4c1@mail.gmail.com> <C9BF0238EED3634BA1866AEF14C7A9E56155D47BDD@NA-EXMSG-C116.redmond.corp.microsoft.com> <00e501c8b6e4$e9f97e60$6801a8c0@oemcomputer>
In-Reply-To: <00e501c8b6e4$e9f97e60$6801a8c0@oemcomputer>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Ltru] Macrolanguage usage [OT?]
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

> >
> > I’m also a bit concerned that a harried developer that thinks
> > “4646bis is names, I know how those work, 4647 is lookup, that’s
> > what I’m implementing, I’ll read that” could easily miss the
> > possible considerations of zh/cmn and whether or not his app
> > needs to be concerned with that.
> ...
>
> I agree.  Though these RFCs need to be taken together as a BCP,
> there's good reason to maintain modularity.  Consequently, I hate
> to see matching algorithm details "leaking" into 4646bis.
> Architecturally, it smells like something is broken.
>

I agree that we might need to do some revision in 4647. However, I think that such work would be limited in scope (this is one area where extlang has *more* impact). Certainly my implementation experience suggests it. There is one very permissive "MAY" in the current 4646bis [1] that users might miss and perhaps some additional text is needed about selecting ranges. This might be suitable as an erratum, although IETF policy may not permit that. We could also break out some of the very detailed information we've had on this list into an Informational RFC that both 4646bis and 4647 (with erratum) could reference. That strikes me as potentially an appropriate mechanism for helping implementers without polluting the RFCs with extensive information about specific languages.

Addison

[1] The quote I have in mind is:

--
Applications MAY use macrolanguage information to improve matching or language negotiation. For example, the information that 'sr' (Serbian) and 'hr' (Croatian) share a macrolanguage expresses a closer relation between those languages than between, say, 'sr' (Serbian) and 'ma' (Macedonian). While it is valid to use either the subtag of the encompassed language or of the macrolanguage to form a language tag, many matching applications will not be aware of the relationship between the languages.
--

http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14a.html#macrolanguages
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru

v2.23.0 | Report a Bug | By Email