IETF Logo Mail Archive

Re: [Ltru] Macrolanguage usage

"Randy Presuhn" <randy_presuhn@mindspring.com> Thu, 15 May 2008 23:39 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 2CD923A6AA4; Thu, 15 May 2008 16:39:41 -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 4AC243A6AA2 for <ltru@core3.amsl.com>; Thu, 15 May 2008 16:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 ghivJ4luaAIU for <ltru@core3.amsl.com>; Thu, 15 May 2008 16:39:38 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 7490E3A6AA4 for <ltru@ietf.org>; Thu, 15 May 2008 16:39:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DOgnqCLq3aY6ozdtiFlw0vSgYnUIU2usWEt4Z7bltkZ6NhbdRT2WH2q5xUGRAVrp; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [68.164.89.32] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Jwn2r-0004Fd-EU for ltru@ietf.org; Thu, 15 May 2008 19:39:33 -0400
Message-ID: <00e501c8b6e4$e9f97e60$6801a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: LTRU Working Group <ltru@ietf.org>
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>
Date: Thu, 15 May 2008 16:39:17 -0700
MIME-Version: 1.0
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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b384dd20817a9dcaa4f935ed1b7541ca29350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.164.89.32
Subject: Re: [Ltru] Macrolanguage usage
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

Hi -

As a technical contributor...

> From: "Shawn Steele" <Shawn.Steele@microsoft.com>
> To: "Mark Davis" <mark.davis@icu-project.org>
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Thursday, May 15, 2008 2:50 PM
> Subject: Re: [Ltru] Macrolanguage usage
>
> I can understand that desire, however I’m not sure the full
> implications of lookup can be discussed in 4646bis.  You’d
> have to refer to 4647 to understand the comments and then
> 4646bis would have to make exceptions/additions to the 4647 behavior.
>
> Perhaps there could be a limited effort to add one section to address
> this in 4647 rather than rewriting the whole thing?
>
> 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.

Randy


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru

v2.23.0 | Report a Bug | By Email