From duerst@it.aoyama.ac.jp Wed Apr 1 00:55:33 2009 Return-Path: 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 22FEF3A6844 for ; Wed, 1 Apr 2009 00:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] 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 quVc9KtudgcD for ; Wed, 1 Apr 2009 00:55:31 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 8FB0A3A680B for ; Wed, 1 Apr 2009 00:55:27 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n317uQtE027643 for ; Wed, 1 Apr 2009 16:56:26 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 7bdb_99ffa88c_1e92_11de_9605_001d0969ab06; Wed, 01 Apr 2009 16:56:26 +0900 Received: from [IPv6:::1] ([133.2.210.1]:39348) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 1 Apr 2009 16:47:45 +0900 Message-ID: <49D31E17.6080305@it.aoyama.ac.jp> Date: Wed, 01 Apr 2009 16:56:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Mark Davis References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> In-Reply-To: <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Lisa Dusseault , LTRU Working Group , Doug Ewell , Alexey Melnikov , Chris Newman , Addison Phillips Subject: Re: [Ltru] LAST CALL REQUESTED X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:55:33 -0000 On 2009/04/01 13:33, Mark Davis wrote: > BTW, can someone point me to the tool for viewing the last call status? https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/ Alex, can you give us a hint about when to expect the next steps, or tell us what you need from our side, if anything? Regards, Martin. > > Mark > > > On Mon, Mar 2, 2009 at 03:19, Martin Duerst wrote: > >> Hello Chris, >> >> [I'm assuming you are the acting AD currently. >> I'm cc'ing Alex so he knows what might be comming up for him.] >> >> I'm glad to finally request IETF LAST CALL for >> draft-ietf-ltru-4645bis(-10) and draft-ietf-ltru-4646bis(-21), >> the two current WG documents of the LTRU WG. >> The intended status of 4645bis is informational, >> the intended status of 4646bis is BCP (BCP 47 together >> with RFC 4647, which stays as it is). >> >> I'm sending the shepherding documents in separate mails, >> but I'm using this mail as a trigger; that's what Ted Hardie >> told me to do when I did this thing last time. >> >> If I need to do anything else, please don't hesitate to tell me. >> >> Regards, Martin. >> >> >> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >> #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp >> >> > -- #-# Martin J.Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From mark.edward.davis@gmail.com Wed Apr 1 07:34:55 2009 Return-Path: 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 6D97B3A6DB5 for ; Wed, 1 Apr 2009 07:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] 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 1Df7qUS1pftU for ; Wed, 1 Apr 2009 07:34:53 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 39F393A67DF for ; Wed, 1 Apr 2009 07:34:53 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so59814wfg.31 for ; Wed, 01 Apr 2009 07:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Sd4Nv6gJpVyN5+5lXb2CGMB49eFM2WBf7cRQVJKZhL4=; b=ri/QMjAOQhv/h45dI7FFau8JG3fvEfe8LaVV2x1q3BMwnV76GjKWnYo4MJ12u7pSoM d9fNLAfPqRFIj8Yyoz/BMEEUfd7yjhmFpKPKkubb1OGpdx+LU/TPMDf4U+JBk0zQPs7I cMV8c+uFlYNvoqWTc/RfIKDlfDyjNq6Dez6C8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=OcxkBBCs8myubOP1+mzpd2e17yKkBnrDmb28Eg/bo6QYoP45yOZC2/QPp7k0mOANOt nl/Pc+ECyP/XldIcm/8Tdz8i2NQ8A9TVRuzHj2s/rMJ/Hc2+Tn9c8zsy4ExyXWUVC0rh Gw7m7O+o0GwqaUCmt0H+Kty/Dc3AOCfpbXKrU= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.134.20 with SMTP id h20mr3144002wfd.342.1238596551785; Wed, 01 Apr 2009 07:35:51 -0700 (PDT) In-Reply-To: <49D31E17.6080305@it.aoyama.ac.jp> References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> Date: Wed, 1 Apr 2009 07:35:51 -0700 X-Google-Sender-Auth: 349c2d222b6559f9 Message-ID: <30b660a20904010735q2a3e121dxf87d6d48261fc02c@mail.gmail.com> From: Mark Davis To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=000e0cd332267d3edd04667f3b7b Cc: Lisa Dusseault , LTRU Working Group , Doug Ewell , Alexey Melnikov , Chris Newman , Addison Phillips Subject: Re: [Ltru] LAST CALL REQUESTED X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:34:55 -0000 --000e0cd332267d3edd04667f3b7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmmm. I'd seen that page, but there wasn't any progress since 3/9, so I thought I was missing something. Mark On Wed, Apr 1, 2009 at 00:56, "Martin J. D=C3=BCrst" wrote: > On 2009/04/01 13:33, Mark Davis wrote: > >> BTW, can someone point me to the tool for viewing the last call status? >> > > https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/ > > Alex, can you give us a hint about when to expect the next steps, > or tell us what you need from our side, if anything? > > Regards, Martin. > > > > >> Mark >> >> >> On Mon, Mar 2, 2009 at 03:19, Martin Duerst >> wrote: >> >> Hello Chris, >>> >>> [I'm assuming you are the acting AD currently. >>> I'm cc'ing Alex so he knows what might be comming up for him.] >>> >>> I'm glad to finally request IETF LAST CALL for >>> draft-ietf-ltru-4645bis(-10) and draft-ietf-ltru-4646bis(-21), >>> the two current WG documents of the LTRU WG. >>> The intended status of 4645bis is informational, >>> the intended status of 4646bis is BCP (BCP 47 together >>> with RFC 4647, which stays as it is). >>> >>> I'm sending the shepherding documents in separate mails, >>> but I'm using this mail as a trigger; that's what Ted Hardie >>> told me to do when I did this thing last time. >>> >>> If I need to do anything else, please don't hesitate to tell me. >>> >>> Regards, Martin. >>> >>> >>> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >>> #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.j= p >>> >>> >>> >> > -- > #-# Martin J.D=C3=BCrst, Professor, Aoyama Gakuin University > > #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > --000e0cd332267d3edd04667f3b7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmmm. I'd seen that page, but there wasn't any progress since 3/9, = so I thought I was missing something.

Mark


On Wed, Apr 1, 2009 at 00:56, "Mart= in J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> wrote:
On 2009/04/01 13:33, Mark Davis wrote:
BTW, can someone point me to the tool for viewing the last call status?

https://datatracker.ietf.org/idtracker/draft-ietf-= ltru-4646bis/

Alex, can you give us a hint about when to expect the next steps,
or tell us what you need from our side, if anything?

Regards, =C2=A0 =C2=A0Martin.




Mark


On Mon, Mar 2, 2009 at 03:19, Martin Duerst<duerst@it.aoyama.ac.jp> =C2=A0wrote:=

Hello Chris,

[I'm assuming you are the acting AD currently.
I'm cc'ing Alex so he knows what might be comming up for him.]

I'm glad to finally request IETF LAST CALL for
draft-ietf-ltru-4645bis(-10) and draft-ietf-ltru-4646bis(-21),
the two current WG documents of the LTRU WG.
The intended status of 4645bis is informational,
the intended status of 4646bis is BCP (BCP 47 together
with RFC 4647, which stays as it is).

I'm sending the shepherding documents in separate mails,
but I'm using this mail as a trigger; that's what Ted Hardie
told me to do when I did this thing last time.

If I need to do anything else, please don't hesitate to tell me.

Regards, =C2=A0 =C2=A0Martin.


#-#-# =C2=A0Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin Universi= ty
#-#-# =C2=A0htt= p://www.sw.it.aoyama.ac.jp =C2=A0 =C2=A0 =C2=A0 mailto:duerst@it.aoyama.ac.jp




--
#-# Martin J.D=C3=BCrst, Professor, Aoyama Gakuin University

#-# http://www.= sw.it.aoyama.ac.jp =C2=A0 mailto:duerst@it.aoyama.ac.jp

--000e0cd332267d3edd04667f3b7b-- From mark.edward.davis@gmail.com Thu Apr 2 18:31:36 2009 Return-Path: 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 0A9113A6896 for ; Thu, 2 Apr 2009 18:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 9RcqN4TfmFyW for ; Thu, 2 Apr 2009 18:31:35 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 3A5C93A67EE for ; Thu, 2 Apr 2009 18:31:35 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so934185wfg.31 for ; Thu, 02 Apr 2009 18:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=0hwO8WSPUfiMvZV/4J22CrhMLowEnO9FpQcXRWAnMZo=; b=TS3bmz9YU+V9MVZDxjCk9nlLPTPeDQjGSUTCXO3aOANNQ3RRzwTx7JZQhvYkzg2oOr XuhQtfNoVzST7v+FYhddBbhp5U3mzepRKBlsL8Wy6Mdy0g5l6N5+I6hWoqvBynIOe7LA X93a0n8YFsqxcF3Tb7J/xOxXSFoZ1f93JkfGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=st9bCOffm2k5c20rIGsPLvxkTeVs2OnltZl2NTMgDhE/Ot1jHp8zskcMwgs1ID2K3M YRnGcMFphfyEdj2M+IAYm+bBi6/7Gz2SZOYSJtaRNd/Twwj2y/iEVQ/AQzg4aWgCTCtJ T12SkWKQVcaRYhf4v4fcvoXyarfdoyeg+F43k= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.9.11 with SMTP id m11mr158012wfi.44.1238722357304; Thu, 02 Apr 2009 18:32:37 -0700 (PDT) Date: Thu, 2 Apr 2009 18:32:37 -0700 X-Google-Sender-Auth: 4938334d8ef40d00 Message-ID: <30b660a20904021832t45ac5f02p92f9eb5e4bc75a13@mail.gmail.com> From: Mark Davis To: LTRU Working Group Content-Type: multipart/alternative; boundary=001636e90c9d151ced04669c86f1 Subject: [Ltru] Regex X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:31:36 -0000 --001636e90c9d151ced04669c86f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I just redid my regex for the new version. The only tweak I made was that it only allows one extlang (as per the description, item 4), which means that I had to retain zh-min-nan as irregular. (?i) (?: (?: ( [a-z]{2,8} | [a-z]{2,3} [-_] [a-z]{3} ) (?: [-_] ( [a-z]{4} ) )? (?: [-_] ( [a-z]{2} | [0-9]{3} ) )? (?: [-_] ( (?: [a-z 0-9]{5,8} | [0-9] [a-z 0-9]{3} ) (?: [-_] (?: [a-z 0-9]{5,8} | [0-9] [a-z 0-9]{3} ) )* ) )? (?: [-_] ( [a-w y-z] (?: [-_] [a-z 0-9]{2,8} )+ (?: [-_] [a-w y-z] (?: [-_] [a-z 0-9]{2,8} )+ )* ) )? (?: [-_] ( x (?: [-_] [a-z 0-9]{1,8} )+ ) )? ) | ( x (?: [-_] [a-z 0-9]{1,8} )+ ) | ( en [-_] GB [-_] oed | i [-_] (?: ami | bnn | default | enochian | hak | klingon | lux | mingo | navajo | pwn | tao | tay | tsu ) | no [-_] (?: bok | nyn ) | sgn [-_] (?: BE [-_] (?: fr | nl) | CH [-_] de ) | zh [-_] min [-_] nan ) ) As before, - the (?i) is for case insensitive matching, - the [-_] is for implemenatations (like Unicode) that allow alternate separators (can be replaced by [-] otherwise), and - the (?: is Perl/Java syntax for non-capturing groups. [That is, the regular (..) capture the main components of the regex, for extraction later.] Mark --001636e90c9d151ced04669c86f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just redid my regex for the new version. The only tweak I made was that i= t only allows one extlang (as per the description, item 4), which means tha= t I had to retain zh-min-nan as irregular.

(?i)
=C2=A0 (?:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (?: ( [a-z]{2,8} | [a-z= ]{2,3} [-_] [a-z]{3} )
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (?: [-_] ( [a-z]{4} ) )?
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (?: [-_] ( [a-z]{2} | [0-9]{3} ) )?
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (?: [-_] ( (?: [a-z 0-9]{5,8} | [0-9] [a-z 0-9]{3} ) (?: [-_] (?:= [a-z 0-9]{5,8} | [0-9] [a-z 0-9]{3} ) )* ) )?
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (?: [-_] ( [a-w y-z] (?: [-_] [a-z 0-9]{2,8} )+ (?: [-_] [a-w y-z= ] (?: [-_] [a-z 0-9]{2,8} )+ )* ) )?
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 (?: [-_] ( x (?: [-_] [a-z 0-9]{1,8} )+ ) )? ) =
=C2=A0=C2=A0=C2=A0 | ( = x (?: [-_] [a-z 0-9]{1,8} )+ )
=C2=A0=C2= =A0=C2=A0 | ( en [-_] GB [-_] oed
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | i [-_] (?: ami | bnn | default | enochian | hak | klingon | lux= | mingo | navajo | pwn | tao | tay | tsu )
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | sgn [-_] (?: BE [-_] (?: fr | nl) | CH [-_] de )
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | zh [-_] min [-_] nan ) = )

As before,
  • the (?i) is for case insensitive matching,
  • the [-_] is for implemenatations (like Unicode) that allow alternate = separators (can be replaced by [-] otherwise), and
  • the (?: is P= erl/Java syntax for non-capturing groups. [That is, the regular (..) captur= e the main components of the regex, for extraction later.]

Mark
--001636e90c9d151ced04669c86f1-- From doug@ewellic.org Mon Apr 6 06:20:37 2009 Return-Path: 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 607013A69E8 for ; Mon, 6 Apr 2009 06:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] 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 ribKbfykqDnn for ; Mon, 6 Apr 2009 06:20:31 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id 7019D3A6C2C for ; Mon, 6 Apr 2009 06:20:30 -0700 (PDT) Received: (qmail 26550 invoked from network); 6 Apr 2009 13:21:31 -0000 Received: from unknown (67.166.27.148) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 06 Apr 2009 13:21:31 -0000 Message-ID: <2B2DC77611BB4939AB212CFC5C74787D@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 6 Apr 2009 07:21:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] LAST CALL REQUESTED X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:20:37 -0000 Mark Davis wrote: >>> BTW, can someone point me to the tool for viewing the last call >>> status? >> >> https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/ >> >> Alex, can you give us a hint about when to expect the next steps, or >> tell us what you need from our side, if anything? > > Hmmm. I'd seen that page, but there wasn't any progress since 3/9, so > I thought I was missing something. I too would be interested to know what is causing the delay in moving these documents forward. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From randy_presuhn@mindspring.com Mon Apr 6 16:02:09 2009 Return-Path: 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 906243A6AC1 for ; Mon, 6 Apr 2009 16:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_50=0.001] 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 Ocp-ODh83wx8 for ; Mon, 6 Apr 2009 16:02:08 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id CB38E3A6CC2 for ; Mon, 6 Apr 2009 16:02:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UqN036e2XrqfT6j/yvXeMLmQdy8Sd1l3UGfE+X0wrl18Obv4RZHjcKQt3ELNiwwE; 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 [69.3.28.253] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LqxqU-0002FE-KI for ltru@ietf.org; Mon, 06 Apr 2009 19:03:14 -0400 Message-ID: <003a01c9b70c$20567f80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <2B2DC77611BB4939AB212CFC5C74787D@DGBP7M81> Date: Mon, 6 Apr 2009 16:05:04 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173e2fe74395c5b0d0702f3a4a56107a4ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.253 Subject: Re: [Ltru] LAST CALL REQUESTED X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 23:02:09 -0000 Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, April 06, 2009 6:21 AM > Subject: Re: [Ltru] LAST CALL REQUESTED ... > >> https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/ ... > I too would be interested to know what is causing the delay in moving > these documents forward. We're just waiting. The responsible AD (or someone designated by him) needs to complete a review of the documents before bringing them to the full IESG or taking up an IETF last call. This information is in the "State Exmplanations" link from the web page cited above. Randy From randy_presuhn@mindspring.com Wed Apr 8 16:03:48 2009 Return-Path: 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 3B8F53A6E60 for ; Wed, 8 Apr 2009 16:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_50=0.001] 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 kEo3Wi-YPjR4 for ; Wed, 8 Apr 2009 16:03:47 -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 7F4A53A6B2E for ; Wed, 8 Apr 2009 16:03:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ff7fDjLaY9B0Ta0d6qvI4YKcJ6ct+fK5MKsuYOjXPYZZ8P27qbvNo1W10c8of4WE; 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 [69.3.144.16] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrgpC-0006Qd-NJ for ltru@ietf.org; Wed, 08 Apr 2009 19:04:54 -0400 Message-ID: <000e01c9b89e$b3a13580$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <2B2DC77611BB4939AB212CFC5C74787D@DGBP7M81> <003a01c9b70c$20567f80$6801a8c0@oemcomputer> Date: Wed, 8 Apr 2009 16:06:50 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17356445c08fc1ab631dd43f3397a2ed6b9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.144.16 Subject: Re: [Ltru] LAST CALL REQUESTED X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:03:48 -0000 Hi - Update - Our Area Director (Alexey Melnikov ) has started digging into the documents. He has some questions, which he has promised to send out soon. Randy From randy_presuhn@mindspring.com Wed Apr 8 16:30:38 2009 Return-Path: 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 B058A3A6B7F for ; Wed, 8 Apr 2009 16:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 cridRD5g5VCF for ; Wed, 8 Apr 2009 16:30:37 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id A0A8A3A6B2E for ; Wed, 8 Apr 2009 16:30:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KAMpYn6eGIIxB50WA+uB5WQJE9n49tYoaOadQ2yxNFOj3bcChz5+MTjEKl/1yaZk; h=Received:Message-ID:From:To: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.166.37.221] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrhF0-0000io-Tr for ltru@ietf.org; Wed, 08 Apr 2009 19:31:35 -0400 Message-ID: <004201c9b8a2$5cd2c760$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 8 Apr 2009 16:32:37 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173386f36f5e066e116c99dc96fb7a4ccf8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.221 Subject: [Ltru] Fw: AD review of draft-ietf-ltru-4645bis-10.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:30:38 -0000 Hi - This from our AD. Randy ----- Original Message ----- From: "Alexey Melnikov" To: "Martin J. Dürst" ; "Mark Davis" ; "Chris Newman" ; "Randy Presuhn" ; "Addison Phillips" ; "Doug Ewell" Cc: "Lisa Dusseault" Sent: Wednesday, April 08, 2009 4:10 PM Subject: AD review of draft-ietf-ltru-4645bis-10.txt > Alexey Melnikov wrote: > > Martin J. Dürst wrote: > >> On 2009/04/01 13:33, Mark Davis wrote: >> >>> BTW, can someone point me to the tool for viewing the last call status? >> >> https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/ >> >> Alex, can you give us a hint about when to expect the next steps, >> or tell us what you need from our side, if anything? > > Folks, > I am on my last day of holidays before returning home. > I've started reviewing 4645bis few days (and forgot to download > 4646bis on my laptop), which proved to be problematic. > I have some comments/questions about 4645bis which I try to summarize > and send out shortly. Ok, here is my AD review of 4645bis. Please let me know if you agree/disagree with various issues I've raised. Answers to some of my questions might be obvious after I review 4646bis in details (I've only skimmed it so far). But I am sending my comments anyway in order to speed up the process. So far I don't have any issues with the document that I think need to be fixed before IETF LC. However, I would appreciate a reply to my review before issuing IETF LC. Also please let me know if you want me to last call the document as is, or if you would like to update the document to address my comments first. General: I hope the WG has discussed "let's remove all registrations from the document before publication" approach. Personally I would rather the document contain IANA registrations upon publication. > 1. Introduction [...] > In its initial phase as an Internet-Draft, this memo also contained a > complete replacement of the contents of the Language Subtag Registry > to be used by the Internet Assigned Numbers Authority (IANA) in > updating it. This content was deleted from this memo prior to > publication as an RFC. Is this paragraph useful? If the content is deleted when the updated RFC is published, this doesn't give a reader any useful information. If the content is not deleted when the updated RFC is published, then this text would be wrong. I think there is at least one more place where there is a similar issue. I've just picked a nearly random registration from the document: > Type: language > Subtag: orv > Description: Old Russian > Added: 2029-09-09 I am confused here. Why is the "Added" date in the future? > 6. Changes > > [RFC EDITOR NOTE: this section is provided for the convenience of > reviewers and will be removed from the final document.] > > This memo is a new work, not an incremental update of [RFC4645]. The > procedure for populating the original Language Subtag Registry, > specified by the earlier [RFC4646], is included by reference to > [RFC4645]. Therefore, no changes from [RFC4645] are listed in this > section. I am not sure I understand this comment and I don't think I find it convincing. At least one of the acting ADs thinks that any XXXXbis draft must contain "Changes since RFC XXXX" section, which tries to summarize all major changes. (I.e. the AD would put a DISCUSS on the document until this is resolved). Personally I find a section listing all changes to be very useful, but I don't consider lack of it as a blocking issue. If the document is really not a bis draft, then the draft name is confusing. Regards, Alexey From dzo@bisharat.net Wed Apr 8 16:39:06 2009 Return-Path: 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 68F8C3A6BAE for ; Wed, 8 Apr 2009 16:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 hWM67FM5uBWY for ; Wed, 8 Apr 2009 16:39:05 -0700 (PDT) Received: from 113166-www.kabissa.org (113166.kabissa.org [72.32.199.201]) by core3.amsl.com (Postfix) with ESMTP id 89D723A6988 for ; Wed, 8 Apr 2009 16:39:05 -0700 (PDT) Received: (qmail 13787 invoked from network); 8 Apr 2009 18:40:12 -0500 Received: from unknown (HELO LENOVOB85F541E) (198.24.31.70) by 72.32.229.137 with SMTP; 8 Apr 2009 18:40:11 -0500 From: "Don Osborn" To: "'LTRU Working Group'" , "'IETF Languages Discussion'" Date: Wed, 8 Apr 2009 19:40:05 -0400 Message-ID: <011e01c9b8a3$58ab9670$0a02c350$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011F_01C9B881.D199F670" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acm4o1fcV19UCBEISBqf9yM+k3MrCA== Content-Language: en-us Subject: [Ltru] How to handle macrolanguage when no code? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:39:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011F_01C9B881.D199F670 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In looking at the BBC website's offerings in African languages, one notes that they have grouped Kinyarwanda and Kirundi together under http://www.bbc.co.uk/greatlakes/ . This makes sense from a linguistic point of view since as I understand it, the two languages are almost the same. When looking at the view (page) source, one notes that they use lang="rw" (for Kinyarwanda). It may be that the pages I checked are properly Kinyarwanda and an expert would know that they are not Kirundi (rn), but it is in any event true that there is no code element to cover both languages. I'm curious if there is any other recommended way to handle such a situation where web content may be deliberately and easily designed to cover more than one language as defined by ISO 639 when there is not currently any macrolanguage code for them. Could one for example define a whole page as having two languages? E.g., something like lang="rw, rn"? Thanks in advance for any feedback. Don ------=_NextPart_000_011F_01C9B881.D199F670 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

In looking at the BBC website's offerings in = African languages, one notes that they have grouped Kinyarwanda and Kirundi = together under http://www.bbc.co.uk/greatlakes= /  . This makes sense from a linguistic point of view since as I understand = it, the two languages are almost the same. When looking at the view (page) = source, one notes that they use lang=3D"rw" (for Kinyarwanda). It may = be that the pages I checked are properly Kinyarwanda and an expert would know = that they are not Kirundi (rn), but it is in any event true that there is no code = element to cover both languages.

 

I'm curious if there is any other recommended way = to handle such a situation where web content may be deliberately and easily = designed to cover more than one language as defined by ISO 639 when there is not currently = any macrolanguage code for them. Could one for example define a whole page = as having two languages? E.g., something like lang=3D"rw, = rn"?

 

Thanks in advance for any feedback.

 

Don

 

 

------=_NextPart_000_011F_01C9B881.D199F670-- From randy_presuhn@mindspring.com Wed Apr 8 16:58:36 2009 Return-Path: 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 7145D3A6B9E for ; Wed, 8 Apr 2009 16:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 5905GvzVoOkq for ; Wed, 8 Apr 2009 16:58:35 -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 36D413A68F5 for ; Wed, 8 Apr 2009 16:58:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=N7XIiDR2lpq2N03WtO7upJtB1PhMbOksXnWXnOHiQZFd5TImDg//gSV+BPa8EH3V; h=Received:Message-ID:From:To:Cc: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.166.37.221] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrhgC-0003OM-KI; Wed, 08 Apr 2009 19:59:40 -0400 Message-ID: <004301c9b8a6$5bcb45a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> Date: Wed, 8 Apr 2009 17:01:38 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1735df39ff071ec2c40baee5278e845f369350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.221 Cc: LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] AD review of draft-ietf-ltru-4645bis-10.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:58:36 -0000 Hi - (I've added the ltru WG list, and trimmed from the recipient list those people subscribed to that list.) Responding as a co-chair... > From: "Alexey Melnikov" > To: "Martin J. Dürst" ; "Mark Davis" ; "Chris Newman" ; "Randy Presuhn" ; "Addison Phillips" ; "Doug Ewell" > Cc: "Lisa Dusseault" > Sent: Wednesday, April 08, 2009 4:10 PM > Subject: AD review of draft-ietf-ltru-4645bis-10.txt ... > Ok, here is my AD review of 4645bis. Please let me know if you > agree/disagree with various issues I've raised. > Answers to some of my questions might be obvious after I review 4646bis > in details (I've only skimmed it so far). But I am sending my comments > anyway in order to speed up the process. Thanks! > So far I don't have any issues with the document that I think need to be > fixed before IETF LC. However, I would appreciate a reply to my review > before issuing IETF LC. Also please let me know if you want me to last > call the document as is, or if you would like to update the document to > address my comments first. I'd prefer to last call it as is, but would defer to co-chair (and document shepherd) Martin Duerst's opinion. > General: I hope the WG has discussed "let's remove all registrations > from the document before publication" approach. Personally I would > rather the document contain IANA registrations upon publication. Yes, this was discussed at some length back when the WG produced RFC 4645. There was considerable concern that if the content were left in the RFC, even with health warnings, the risk would be too great that developers would use the RFC rather than the registry. > > 1. Introduction > > [...] > > > In its initial phase as an Internet-Draft, this memo also contained a > > complete replacement of the contents of the Language Subtag Registry > > to be used by the Internet Assigned Numbers Authority (IANA) in > > updating it. This content was deleted from this memo prior to > > publication as an RFC. > > Is this paragraph useful? If the content is deleted when the updated > RFC is published, this doesn't give a reader any useful information. If > the content is not deleted when the updated RFC is published, then this > text would be wrong. It's there to explain the absence of content in the RFC. Without it, the document would be puzzlingly content-free. We were pretty much painted into this corner by the rules on references to I-Ds, etc. Back when we did 4645, we considered many alternatives, and this was the path that got consensus. When we started the update, the question was raised whether we wanted to go this route again, but there was no groundswell of support for any alternative. > I think there is at least one more place where there is a similar issue. There is strong consensus to delete the content upon publication. If we had known of a tidier way of delivering the bulk update to IANA, we'd have used it. I've just picked a nearly random registration from the document: > > Type: language > > Subtag: orv > > Description: Old Russian > > Added: 2029-09-09 > > I am confused here. Why is the "Added" date in the future? See section 2.1: The values of the File-Date field, the Added date for each new subtag record, and the Deprecated date for each existing grandfathered or redundant tag deprecated by this update were set to a date as near as practical to the date of IESG approval of this memo. [RFC EDITOR NOTE: these dates are initially set to 2029-09-09 for easy recognition, and MUST be updated during AUTH48.] > > 6. Changes > > > > [RFC EDITOR NOTE: this section is provided for the convenience of > > reviewers and will be removed from the final document.] > > > > This memo is a new work, not an incremental update of [RFC4645]. The > > procedure for populating the original Language Subtag Registry, > > specified by the earlier [RFC4646], is included by reference to > > [RFC4645]. Therefore, no changes from [RFC4645] are listed in this > > section. > > I am not sure I understand this comment and I don't think I find it > convincing. At least one of the acting ADs thinks that any XXXXbis draft > must contain "Changes since RFC XXXX" section, which tries to summarize > all major changes. (I.e. the AD would put a DISCUSS on the document > until this is resolved). Personally I find a section listing all changes > to be very useful, but I don't consider lack of it as a blocking issue. > > If the document is really not a bis draft, then the draft name is confusing. We did discuss whether an incremental update or bulk-replace update was easier to cope with, and opted for the bulk-replace approach. To describe the detailed differences in the changes section would be counterproductive at best. If this MUST be done to clear a potential DISCUSS, perhaps a compromise would be to add a summary of the form "XXX new records added, YYY old records modified." Actually listing all the new ones would NOT be something I'd like to even consider. I think the scientific term is "a gazillion," and would nearly double the length of the document, which might make it a little unwieldy. :-) I *would* consider asking the editor to list the ones to which changes (other thatn formatting changes) were made (without detailing the nature of the change), but only if (1) necessary to clear a DISCUSS, and (2) endorsed by the WG. However, my strong preference is to provide no more detail than is absolutely necessary, particularly since the body is to be gutted as part of the publication process anyway. Randy From randy_presuhn@mindspring.com Wed Apr 8 17:09:06 2009 Return-Path: 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 B2E0A3A6A41 for ; Wed, 8 Apr 2009 17:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 Gjpk-KUNr-Xi for ; Wed, 8 Apr 2009 17:09:05 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 9444E3A6B9E for ; Wed, 8 Apr 2009 17:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d2CnJiSL25Gc4V/zzT53TTVICR5oojVOE0Lw7hzX+yFNUCy5k2pcTCDNw4cL7IAL; h=Received:Message-ID:From:To:Cc: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.166.37.221] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrhqO-0007nV-0z; Wed, 08 Apr 2009 20:10:12 -0400 Message-ID: <004c01c9b8a7$d43ebb60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <49DD3336.9040102@isode.com> Date: Wed, 8 Apr 2009 17:12:10 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17394bc7ec2ce8d591a5f7cdae1927a8e3d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.221 Cc: LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] AD review of draft-ietf-ltru-4645bis-10.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 00:09:06 -0000 Hi - > From: "Alexey Melnikov" > To: "Martin J. Dürst" ; "Randy Presuhn" > Cc: "Mark Davis" ; "Chris Newman" ; "Addison Phillips" ; "Doug Ewell" ; "Lisa Dusseault" > Sent: Wednesday, April 08, 2009 4:28 PM > Subject: Re: AD review of draft-ietf-ltru-4645bis-10.txt > > On a somewhat related note: please excuse my ignorance, but what is the > relationship between ISO639-3 and the updated IANA registry for language > tags? 693-3 was one of the sources of codes used to form subtags in the "bulk update" 4645bis. > On I read: > > An updated version of the code set will be released once each year, and > all changes since the inception of the code will be reported on this page. > > Who is going to keep the two registries in sync and is this desirable at > all? This happens on ietf-languages@iana.org, as a function of the language subtag reviewer. See 4646bis section 3.4 (12) (B) and surrounding material. BTW, these sections show some of the long-standing tension in the work between the desire for stability and for maintaining alignment. Randy From alexey.melnikov@isode.com Wed Apr 8 17:15:35 2009 Return-Path: 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 9DAA83A6A91 for ; Wed, 8 Apr 2009 17:15:35 -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=[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 8L+wOsDHJO+W for ; Wed, 8 Apr 2009 17:15:34 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3D4503A68F5 for ; Wed, 8 Apr 2009 17:15:34 -0700 (PDT) Received: from [10.224.15.245] (med0f36d0.tmodns.net [208.54.15.237]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Apr 2009 01:16:40 +0100 Message-ID: <49DD3E4A.7020103@isode.com> Date: Wed, 08 Apr 2009 17:16:10 -0700 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randy Presuhn References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <004301c9b8a6$5bcb45a0$6801a8c0@oemcomputer> In-Reply-To: <004301c9b8a6$5bcb45a0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] AD review of draft-ietf-ltru-4645bis-10.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 00:15:35 -0000 Randy Presuhn wrote: [...] >>General: I hope the WG has discussed "let's remove all registrations >>from the document before publication" approach. Personally I would >>rather the document contain IANA registrations upon publication. >> > >Yes, this was discussed at some length back when the WG produced RFC 4645. >There was considerable concern that if the content were left in the >RFC, even with health warnings, the risk would be too great that >developers would use the RFC rather than the registry. > Either way is fine with me, as long as this was discussed in the WG. >>>1. Introduction >>> >>[...] >> >> >>> In its initial phase as an Internet-Draft, this memo also contained a >>> complete replacement of the contents of the Language Subtag Registry >>> to be used by the Internet Assigned Numbers Authority (IANA) in >>> updating it. This content was deleted from this memo prior to >>> publication as an RFC. >>> >>> >>Is this paragraph useful? If the content is deleted when the updated >>RFC is published, this doesn't give a reader any useful information. If >>the content is not deleted when the updated RFC is published, then this >>text would be wrong. >> >> >It's there to explain the absence of content in the RFC. Without it, >the document would be puzzlingly content-free. We were pretty much >painted into this corner by the rules on references to I-Ds, etc. >Back when we did 4645, we considered many alternatives, and this was >the path that got consensus. When we started the update, the question >was raised whether we wanted to go this route again, but there was >no groundswell of support for any alternative. > > >>I think there is at least one more place where there is a similar issue. >> >> >There is strong consensus to delete the content upon publication. >If we had known of a tidier way of delivering the bulk update to IANA, >we'd have used it. > >I've just picked a nearly random registration from the document: > > >>>Type: language >>>Subtag: orv >>>Description: Old Russian >>>Added: 2029-09-09 >>> >>> >>I am confused here. Why is the "Added" date in the future? >> >> >See section 2.1: > The values of the File-Date field, the Added date for each new subtag > record, and the Deprecated date for each existing grandfathered or > redundant tag deprecated by this update were set to a date as near as > practical to the date of IESG approval of this memo. [RFC EDITOR > NOTE: these dates are initially set to 2029-09-09 for easy > recognition, and MUST be updated during AUTH48.] > > Ah, I've missed that. Thanks. >>>6. Changes >>> >>> [RFC EDITOR NOTE: this section is provided for the convenience of >>> reviewers and will be removed from the final document.] >>> >>> This memo is a new work, not an incremental update of [RFC4645]. The >>> procedure for populating the original Language Subtag Registry, >>> specified by the earlier [RFC4646], is included by reference to >>> [RFC4645]. Therefore, no changes from [RFC4645] are listed in this >>> section. >>> >>> >>I am not sure I understand this comment and I don't think I find it >>convincing. At least one of the acting ADs thinks that any XXXXbis draft >>must contain "Changes since RFC XXXX" section, which tries to summarize >>all major changes. (I.e. the AD would put a DISCUSS on the document >>until this is resolved). Personally I find a section listing all changes >>to be very useful, but I don't consider lack of it as a blocking issue. >> >>If the document is really not a bis draft, then the draft name is confusing. >> >We did discuss whether an incremental update or bulk-replace update was >easier to cope with, and opted for the bulk-replace approach. To describe >the detailed differences in the changes section would be counterproductive at best. >If this MUST be done to clear a potential DISCUSS, perhaps a compromise >would be to add a summary of the form "XXX new records added, YYY old >records modified." Actually listing all the new ones would NOT be something >I'd like to even consider. > I understand. No, I am not asking for this. >I think the scientific term is "a gazillion," >and would nearly double the length of the document, which might make it a >little unwieldy. :-) I *would* consider asking the editor to list the >ones to which changes (other thatn formatting changes) were made (without >detailing the nature of the change), > That what I had in mind. >but only if (1) necessary to clear a >DISCUSS, and (2) endorsed by the WG. > This is fine with me. >However, my strong preference >is to provide no more detail than is absolutely necessary, particularly >since the body is to be gutted as part of the publication process anyway. > > Ok. After your explanation I think the sentence that reads "This memo is a new work, not an incremental update of [RFC4645]" should be reworded or removed. Otherwise it is just asking for a question: "if this is new work, how come it is 4645bis"? At least it is not clear to me what the WG is calling "new work". From cowan@ccil.org Wed Apr 8 17:17:20 2009 Return-Path: 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 5C3243A6B6B for ; Wed, 8 Apr 2009 17:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 Y2gN0D2AJw7e for ; Wed, 8 Apr 2009 17:17:19 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 719D43A6A91 for ; Wed, 8 Apr 2009 17:17:19 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LrhyL-0000qw-LU; Wed, 08 Apr 2009 20:18:25 -0400 Date: Wed, 8 Apr 2009 20:18:25 -0400 To: Alexey Melnikov Message-ID: <20090409001825.GE10348@mercury.ccil.org> References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <004301c9b8a6$5bcb45a0$6801a8c0@oemcomputer> <49DD3E4A.7020103@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49DD3E4A.7020103@isode.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] AD review of draft-ietf-ltru-4645bis-10.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 00:17:20 -0000 Alexey Melnikov scripsit: > After your explanation I think the sentence that reads "This memo is a > new work, not an incremental update of [RFC4645]" should be reworded or > removed. Otherwise it is just asking for a question: "if this is new > work, how come it is 4645bis"? At least it is not clear to me what the > WG is calling "new work". Because it serves the same function as RFC 4645: to initialize the IANA registry. -- Unless it was by accident that I had John Cowan offended someone, I never apologized. cowan@ccil.org --Quentin Crisp http://www.ccil.org/~cowan From randy_presuhn@mindspring.com Wed Apr 8 17:20:27 2009 Return-Path: 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 31A043A6BA3 for ; Wed, 8 Apr 2009 17:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 PcLYJQJIxRSt for ; Wed, 8 Apr 2009 17:20:26 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 6B3473A68F5 for ; Wed, 8 Apr 2009 17:20:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RmqpbfrSAkinQoh4anvc1rURy5U9AbZqRsltN4OxW65f4DF2ZzA3nIqZ/xA5UlvD; h=Received:Message-ID:From:To:Cc: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.166.37.221] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lri1N-0005mp-0c; Wed, 08 Apr 2009 20:21:33 -0400 Message-ID: <005701c9b8a9$68e39960$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <004301c9b8a6$5bcb45a0$6801a8c0@oemcomputer> <49DD3E4A.7020103@isode.com> Date: Wed, 8 Apr 2009 17:23: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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1735990f225d0d279dd73fb260bb18fbf1e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.221 Cc: LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] AD review of draft-ietf-ltru-4645bis-10.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 00:20:27 -0000 Hi - > From: "Alexey Melnikov" > To: "Randy Presuhn" > Cc: "Lisa Dusseault" ; "LTRU Working Group" > Sent: Wednesday, April 08, 2009 5:16 PM > Subject: Re: AD review of draft-ietf-ltru-4645bis-10.txt ... > After your explanation I think the sentence that reads "This memo is a > new work, not an incremental update of [RFC4645]" should be reworded or > removed. Otherwise it is just asking for a question: "if this is new > work, how come it is 4645bis"? At least it is not clear to me what the > WG is calling "new work". As a technical contributor... I'd prefer to simply delete the sentence. Randy From cowan@ccil.org Wed Apr 8 17:37:57 2009 Return-Path: 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 7F3AE3A6BB1 for ; Wed, 8 Apr 2009 17:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 n6kFHXkwW-4x for ; Wed, 8 Apr 2009 17:37:56 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id C39503A6A91 for ; Wed, 8 Apr 2009 17:37:56 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LriII-00035k-Qo; Wed, 08 Apr 2009 20:39:02 -0400 Date: Wed, 8 Apr 2009 20:39:02 -0400 To: Don Osborn Message-ID: <20090409003902.GF10348@mercury.ccil.org> References: <011e01c9b8a3$58ab9670$0a02c350$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011e01c9b8a3$58ab9670$0a02c350$@net> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: 'IETF Languages Discussion' , 'LTRU Working Group' Subject: Re: [Ltru] How to handle macrolanguage when no code? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 00:37:57 -0000 Don Osborn scripsit: > I'm curious if there is any other recommended way to handle such a situation > where web content may be deliberately and easily designed to cover more than > one language as defined by ISO 639 when there is not currently any > macrolanguage code for them. Could one for example define a whole page as > having two languages? E.g., something like lang="rw, rn"? Petition 639-3/RA for a new macrolanguage, I guess. For sure this list can't help you. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh From addison@amazon.com Wed Apr 8 17:52:11 2009 Return-Path: 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 20ACC3A6EB2 for ; Wed, 8 Apr 2009 17:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.719 X-Spam-Level: X-Spam-Status: No, score=-105.719 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_20=-0.74, HTML_MESSAGE=0.001, 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 tEaLRtFYBlqY for ; Wed, 8 Apr 2009 17:52:10 -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 E6F993A6BC5 for ; Wed, 8 Apr 2009 17:52:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,157,1238976000"; d="scan'208,217";a="250584843" Received: from smtp-in-4104.sea5.amazon.com ([10.248.183.18]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Apr 2009 00:53:07 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-4104.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n390r7Xx001088 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 9 Apr 2009 00:53:07 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Wed, 8 Apr 2009 17:53:06 -0700 From: "Phillips, Addison" To: Don Osborn , "'LTRU Working Group'" , "'IETF Languages Discussion'" Date: Wed, 8 Apr 2009 17:53:05 -0700 Thread-Topic: [Ltru] How to handle macrolanguage when no code? Thread-Index: Acm4o1fcV19UCBEISBqf9yM+k3MrCAACY5+Q Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70@EX-SEA5-D.ant.amazon.com> References: <011e01c9b8a3$58ab9670$0a02c350$@net> In-Reply-To: <011e01c9b8a3$58ab9670$0a02c350$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70EXSEA5Dantama_" MIME-Version: 1.0 Subject: Re: [Ltru] How to handle macrolanguage when no code? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 00:52:11 -0000 --_000_4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70EXSEA5Dantama_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SFRNTCBjZXJ0YWlubHkgYWxsb3dzIHlvdSB0byBkZWNsYXJlIHRoYXQgc29tZSBjb250ZW50IGlz IGFwcGxpY2FibGUgdG8gbW9yZSB0aGFuIG9uZSBsYW5ndWFnZSBhdWRpZW5jZS4gU2VlOg0KDQog ICBodHRwOi8vd3d3LnczLm9yZy9UUi9pMThuLWh0bWwtdGVjaC1sYW5nLyNyaTIwMDQwNzI4LjEy MTM1ODQ0NA0KDQpPdGhlcndpc2UsIEpvaG4gQ293YW7igJlzIGFkdmljZSBzZWVtcyBhcHByb3By aWF0ZeKApiBJU08gNjM5LTMgb3IgSVNPIDYzOS01IHdvdWxkIGJlIHlvdXIgbmV4dCBzdG9wLiBO b3RlIHRoYXQgbWFjcm9sYW5ndWFnZXMgYXJlIHNvbWV0aW1lcyBwcm9ibGVtYXRpY2FsLCBzbyB5 b3UgbWlnaHQgYWxzbyBjb25zaWRlciBhIGNvbGxlY3Rpb24gY29kZSBpbnN0ZWFkLg0KDQpBZGRp c29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJu YXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4N Cg0KRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRG9uIE9zYm9ybg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwOCwg MjAwOSA0OjQwIFBNDQpUbzogJ0xUUlUgV29ya2luZyBHcm91cCc7ICdJRVRGIExhbmd1YWdlcyBE aXNjdXNzaW9uJw0KU3ViamVjdDogW0x0cnVdIEhvdyB0byBoYW5kbGUgbWFjcm9sYW5ndWFnZSB3 aGVuIG5vIGNvZGU/DQoNCkluIGxvb2tpbmcgYXQgdGhlIEJCQyB3ZWJzaXRlJ3Mgb2ZmZXJpbmdz IGluIEFmcmljYW4gbGFuZ3VhZ2VzLCBvbmUgbm90ZXMgdGhhdCB0aGV5IGhhdmUgZ3JvdXBlZCBL aW55YXJ3YW5kYSBhbmQgS2lydW5kaSB0b2dldGhlciB1bmRlciBodHRwOi8vd3d3LmJiYy5jby51 ay9ncmVhdGxha2VzLyAgLiBUaGlzIG1ha2VzIHNlbnNlIGZyb20gYSBsaW5ndWlzdGljIHBvaW50 IG9mIHZpZXcgc2luY2UgYXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUgdHdvIGxhbmd1YWdlcyBhcmUg YWxtb3N0IHRoZSBzYW1lLiBXaGVuIGxvb2tpbmcgYXQgdGhlIHZpZXcgKHBhZ2UpIHNvdXJjZSwg b25lIG5vdGVzIHRoYXQgdGhleSB1c2UgbGFuZz0icnciIChmb3IgS2lueWFyd2FuZGEpLiBJdCBt YXkgYmUgdGhhdCB0aGUgcGFnZXMgSSBjaGVja2VkIGFyZSBwcm9wZXJseSBLaW55YXJ3YW5kYSBh bmQgYW4gZXhwZXJ0IHdvdWxkIGtub3cgdGhhdCB0aGV5IGFyZSBub3QgS2lydW5kaSAocm4pLCBi dXQgaXQgaXMgaW4gYW55IGV2ZW50IHRydWUgdGhhdCB0aGVyZSBpcyBubyBjb2RlIGVsZW1lbnQg dG8gY292ZXIgYm90aCBsYW5ndWFnZXMuDQoNCkknbSBjdXJpb3VzIGlmIHRoZXJlIGlzIGFueSBv dGhlciByZWNvbW1lbmRlZCB3YXkgdG8gaGFuZGxlIHN1Y2ggYSBzaXR1YXRpb24gd2hlcmUgd2Vi IGNvbnRlbnQgbWF5IGJlIGRlbGliZXJhdGVseSBhbmQgZWFzaWx5IGRlc2lnbmVkIHRvIGNvdmVy IG1vcmUgdGhhbiBvbmUgbGFuZ3VhZ2UgYXMgZGVmaW5lZCBieSBJU08gNjM5IHdoZW4gdGhlcmUg aXMgbm90IGN1cnJlbnRseSBhbnkgbWFjcm9sYW5ndWFnZSBjb2RlIGZvciB0aGVtLiBDb3VsZCBv bmUgZm9yIGV4YW1wbGUgZGVmaW5lIGEgd2hvbGUgcGFnZSBhcyBoYXZpbmcgdHdvIGxhbmd1YWdl cz8gRS5nLiwgc29tZXRoaW5nIGxpa2UgbGFuZz0icncsIHJuIj8NCg0KVGhhbmtzIGluIGFkdmFu Y2UgZm9yIGFueSBmZWVkYmFjay4NCg0KRG9uDQoNCg0K --_000_4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70EXSEA5Dantama_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDMgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlBNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAz IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQXJpYWwgVW5pY29k ZSBNUyI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAUE1pbmdMaVUiOw0KCXBhbm9z ZS0xOjIgMiAzIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTHVj aWRhIFNhbnMgVW5pY29kZSI7DQoJcGFub3NlLTE6MiAxMSA2IDIgMyA1IDQgMiAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBBcmlhbCBVbmljb2RlIE1TIjsNCglwYW5vc2UtMToy IDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1p bmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQogLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rp b24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUg dmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkhUTUwgY2VydGFpbmx5IGFsbG93cyB5b3Ug dG8NCmRlY2xhcmUgdGhhdCBzb21lIGNvbnRlbnQgaXMgYXBwbGljYWJsZSB0byBtb3JlIHRoYW4g b25lIGxhbmd1YWdlIGF1ZGllbmNlLg0KU2VlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+wqDCoCA8YQ0KaHJlZj0iaHR0cDovL3d3dy53My5vcmcvVFIvaTE4bi1odG1sLXRl Y2gtbGFuZy8jcmkyMDA0MDcyOC4xMjEzNTg0NDQiPmh0dHA6Ly93d3cudzMub3JnL1RSL2kxOG4t aHRtbC10ZWNoLWxhbmcvI3JpMjAwNDA3MjguMTIxMzU4NDQ0PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+T3RoZXJ3aXNlLCBKb2huIENvd2Fu4oCZcyBhZHZpY2UNCnNl ZW1zIGFwcHJvcHJpYXRl4oCmIElTTyA2MzktMyBvciBJU08gNjM5LTUgd291bGQgYmUgeW91ciBu ZXh0IHN0b3AuIE5vdGUgdGhhdA0KbWFjcm9sYW5ndWFnZXMgYXJlIHNvbWV0aW1lcyBwcm9ibGVt YXRpY2FsLCBzbyB5b3UgbWlnaHQgYWxzbyBjb25zaWRlciBhDQpjb2xsZWN0aW9uIGNvZGUgaW5z dGVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseToiTHVjaWRhIFNhbnMgVW5pY29kZSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+QWRkaXNvbiBQaGlsbGlwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBT YW5zIFVuaWNvZGUiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkdsb2JhbGl6YXRpb24g QXJjaGl0ZWN0IC0tIExhYjEyNjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KOS4wcHQ7 Zm9udC1mYW1pbHk6Ikx1Y2lkYSBTYW5zIFVuaWNvZGUiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJMdWNpZGEgU2FucyBVbmljb2RlIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiJMdWNpZGEgU2FucyBVbmljb2RlIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz5JbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6Ikx1Y2lkYSBTYW5zIFVuaWNvZGUiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPkl0IGlzIGFuIGFyY2hpdGVjdHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0K PGRpdj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+DQpsdHJ1LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+RG9u DQpPc2Jvcm48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAwOCwgMjAwOSA0OjQw IFBNPGJyPg0KPGI+VG86PC9iPiAnTFRSVSBXb3JraW5nIEdyb3VwJzsgJ0lFVEYgTGFuZ3VhZ2Vz IERpc2N1c3Npb24nPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtMdHJ1XSBIb3cgdG8gaGFuZGxlIG1h Y3JvbGFuZ3VhZ2Ugd2hlbiBubyBjb2RlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD5JbiBsb29raW5nIGF0IHRoZSBCQkMgd2Vic2l0ZSdzIG9mZmVy aW5ncyBpbiBBZnJpY2FuDQpsYW5ndWFnZXMsIG9uZSBub3RlcyB0aGF0IHRoZXkgaGF2ZSBncm91 cGVkIEtpbnlhcndhbmRhIGFuZCBLaXJ1bmRpIHRvZ2V0aGVyDQp1bmRlciA8YSBocmVmPSJodHRw Oi8vd3d3LmJiYy5jby51ay9ncmVhdGxha2VzLyI+aHR0cDovL3d3dy5iYmMuY28udWsvZ3JlYXRs YWtlcy88L2E+Jm5ic3A7DQouIFRoaXMgbWFrZXMgc2Vuc2UgZnJvbSBhIGxpbmd1aXN0aWMgcG9p bnQgb2YgdmlldyBzaW5jZSBhcyBJIHVuZGVyc3RhbmQgaXQsDQp0aGUgdHdvIGxhbmd1YWdlcyBh cmUgYWxtb3N0IHRoZSBzYW1lLiBXaGVuIGxvb2tpbmcgYXQgdGhlIHZpZXcgKHBhZ2UpIHNvdXJj ZSwNCm9uZSBub3RlcyB0aGF0IHRoZXkgdXNlIGxhbmc9JnF1b3Q7cncmcXVvdDsgKGZvciBLaW55 YXJ3YW5kYSkuIEl0IG1heSBiZSB0aGF0DQp0aGUgcGFnZXMgSSBjaGVja2VkIGFyZSBwcm9wZXJs eSBLaW55YXJ3YW5kYSBhbmQgYW4gZXhwZXJ0IHdvdWxkIGtub3cgdGhhdCB0aGV5DQphcmUgbm90 IEtpcnVuZGkgKHJuKSwgYnV0IGl0IGlzIGluIGFueSBldmVudCB0cnVlIHRoYXQgdGhlcmUgaXMg bm8gY29kZSBlbGVtZW50DQp0byBjb3ZlciBib3RoIGxhbmd1YWdlcy48bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+SSdtIGN1cmlvdXMgaWYgdGhlcmUgaXMgYW55IG90aGVyIHJlY29tbWVuZGVkIHdh eSB0byBoYW5kbGUNCnN1Y2ggYSBzaXR1YXRpb24gd2hlcmUgd2ViIGNvbnRlbnQgbWF5IGJlIGRl bGliZXJhdGVseSBhbmQgZWFzaWx5IGRlc2lnbmVkIHRvDQpjb3ZlciBtb3JlIHRoYW4gb25lIGxh bmd1YWdlIGFzIGRlZmluZWQgYnkgSVNPIDYzOSB3aGVuIHRoZXJlIGlzIG5vdCBjdXJyZW50bHkN CmFueSBtYWNyb2xhbmd1YWdlIGNvZGUgZm9yIHRoZW0uIENvdWxkIG9uZSBmb3IgZXhhbXBsZSBk ZWZpbmUgYSB3aG9sZSBwYWdlIGFzDQpoYXZpbmcgdHdvIGxhbmd1YWdlcz8gRS5nLiwgc29tZXRo aW5nIGxpa2UgbGFuZz0mcXVvdDtydywgcm4mcXVvdDs/PG86cD48L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PlRoYW5rcyBpbiBhZHZhbmNlIGZvciBhbnkgZmVlZGJhY2suPG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPkRvbjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70EXSEA5Dantama_-- From petercon@microsoft.com Wed Apr 8 20:10:34 2009 Return-Path: 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 6E9A83A6B16 for ; Wed, 8 Apr 2009 20:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.932 X-Spam-Level: X-Spam-Status: No, score=-10.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 hVVuZKcFNHGT for ; Wed, 8 Apr 2009 20:10:33 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 411003A68CC for ; Wed, 8 Apr 2009 20:10:33 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 8 Apr 2009 20:11:40 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.18.53]) with mapi; Wed, 8 Apr 2009 20:11:39 -0700 From: Peter Constable To: "Phillips, Addison" , Don Osborn , 'LTRU Working Group' , 'IETF Languages Discussion' Date: Wed, 8 Apr 2009 20:11:39 -0700 Thread-Topic: [Ltru] How to handle macrolanguage when no code? Thread-Index: Acm4o1fcV19UCBEISBqf9yM+k3MrCAACY5+QAASS88A= Message-ID: References: <011e01c9b8a3$58ab9670$0a02c350$@net> <4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579566EBDDCC4DNAEXMSGC117re_" MIME-Version: 1.0 Subject: Re: [Ltru] How to handle macrolanguage when no code? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 03:10:34 -0000 --_000_DDB6DE6E9D27DD478AE6D1BBBB83579566EBDDCC4DNAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgaXQgaXMgY29udGVudCBpbiBvbmUgbGluZ3Vpc3RpYyB2YXJpZXR5IGFuZCBjcmFmdGVkIHRv IHNlcnZlIHR3byBhdWRpZW5jZXMgZGVlbWVkIGluIDYzOS0zIHRvIGJlIGRpc3RpbmN0IGxhbmd1 YWdlcywgdGhlbiB0aGF0IHN0cmlrZXMgbWUgYXMgYSBwb3RlbnRpYWwgbWFjcm9sYW5ndWFnZSBz Y2VuYXJpby4NCg0KT25lIGtleSBxdWVzdGlvbiBpcyBob3cgbmFycm93IGEgc2NvcGUgb2YgY29u dGVudCBpcyBuZWVkZWQgYW5kIGhvdyBtdWNoIGRlbGliZXJhdGUgZWZmb3J0IGlzIG5lZWRlZCB0 byBjcmFmdCBzb21ldGhpbmcgbGlrZSB0aGF0LiBGb3IgaW5zdGFuY2UsIGEgZG9jdW1lbnQgY29u c2lzdGluZyBvZiDigJxQYXBhIeKAnSBjYW4gc2VydmUgbWFueSBkaWZmZXJlbnQgYXVkaWVuY2Vz LCBidXQgdGhhdCBpcyBzb2xlbHkgYmVjYXVzZSB0aGUgc2NvcGUgb2YgY29udGVudCBpcyBzbyBj b25zdHJhaW5lZCwgYW5kIGZvciB0aGF0IHJlYXNvbiB0aGUgYmFyIGlzIG5vdCBtZXQgZm9yIGEg bWFjcm9sYW5ndWFnZS4gQnV0IGlmIGl04oCZcyBlYXN5IGZvciBhIGNvbnRlbnQgcHJvdmlkZXIg dG8gY29tZSB1cCB3aXRoIGNvbnRlbnQgdGhhdCBzZXJ2ZXMgYm90aCwgdGhlbiB0aGF04oCZcyBp bnRlcmVzdGluZy4NCg0KQW5vdGhlciBrZXkgcXVlc3Rpb24gaXMgd2h5IHRoYXQgY29udGVudCBp cyBmdW5jdGlvbmFsIGZvciBib3RoIGF1ZGllbmNlcy4gSXMgaXQgYmVjYXVzZSBpdCBpcyBleHBy ZXNzZWQgaW4gYSB2YXJpZXR5IHRoYXQgY2FuIHJlYWxseSBiZSBjb25zaWRlcmVkIGNvbW1vbiwg b3IgaXMgaXQgYmVjYXVzZSBpdOKAmXMgYWN0dWFsbHkgaW4gbGFuZ3VhZ2UgQSBhbmQgOTAlIG9m IHNwZWFrZXJzIGluIGxhbmd1YWdlIEIgYXJlIGZ1bmN0aW9uYWxseSBiaWxpbmd1YWwgaW4gQT8g RG9lcyB0aGUgY29tbW9uLWlkZW50aWZ5IGxhYmVsIHJlZmxlY3QgYWN0dWFsIGxpbmd1aXN0aWMg Y29tbW9uYWxpdHksIG9yIGlzIGl0IGEgbG9naXN0aWMgdG9vbCB1c2VkIGluIHRoZSByZXBvc2l0 b3J5IHRvIHJlZmxlY3QgbWVyZWx5IGEgZHVhbCB0YXNraW5nPw0KDQoNClNvbWUgdGhvdWdodHMu IERpc2N1c3MgaXQgd2l0aCB0aGUgNjM5LTMgUkEuDQoNCg0KUGV0ZXINCg0KRnJvbTogbHRydS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUGhpbGxpcHMsIEFkZGlzb24NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDgsIDIwMDkgNTo1 MyBQTQ0KVG86IERvbiBPc2Jvcm47ICdMVFJVIFdvcmtpbmcgR3JvdXAnOyAnSUVURiBMYW5ndWFn ZXMgRGlzY3Vzc2lvbicNClN1YmplY3Q6IFJlOiBbTHRydV0gSG93IHRvIGhhbmRsZSBtYWNyb2xh bmd1YWdlIHdoZW4gbm8gY29kZT8NCg0KSFRNTCBjZXJ0YWlubHkgYWxsb3dzIHlvdSB0byBkZWNs YXJlIHRoYXQgc29tZSBjb250ZW50IGlzIGFwcGxpY2FibGUgdG8gbW9yZSB0aGFuIG9uZSBsYW5n dWFnZSBhdWRpZW5jZS4gU2VlOg0KDQogICBodHRwOi8vd3d3LnczLm9yZy9UUi9pMThuLWh0bWwt dGVjaC1sYW5nLyNyaTIwMDQwNzI4LjEyMTM1ODQ0NA0KDQpPdGhlcndpc2UsIEpvaG4gQ293YW7i gJlzIGFkdmljZSBzZWVtcyBhcHByb3ByaWF0ZeKApiBJU08gNjM5LTMgb3IgSVNPIDYzOS01IHdv dWxkIGJlIHlvdXIgbmV4dCBzdG9wLiBOb3RlIHRoYXQgbWFjcm9sYW5ndWFnZXMgYXJlIHNvbWV0 aW1lcyBwcm9ibGVtYXRpY2FsLCBzbyB5b3UgbWlnaHQgYWxzbyBjb25zaWRlciBhIGNvbGxlY3Rp b24gY29kZSBpbnN0ZWFkLg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4N Ckl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRG9uIE9zYm9ybg0KU2Vu dDogV2VkbmVzZGF5LCBBcHJpbCAwOCwgMjAwOSA0OjQwIFBNDQpUbzogJ0xUUlUgV29ya2luZyBH cm91cCc7ICdJRVRGIExhbmd1YWdlcyBEaXNjdXNzaW9uJw0KU3ViamVjdDogW0x0cnVdIEhvdyB0 byBoYW5kbGUgbWFjcm9sYW5ndWFnZSB3aGVuIG5vIGNvZGU/DQoNCkluIGxvb2tpbmcgYXQgdGhl IEJCQyB3ZWJzaXRlJ3Mgb2ZmZXJpbmdzIGluIEFmcmljYW4gbGFuZ3VhZ2VzLCBvbmUgbm90ZXMg dGhhdCB0aGV5IGhhdmUgZ3JvdXBlZCBLaW55YXJ3YW5kYSBhbmQgS2lydW5kaSB0b2dldGhlciB1 bmRlciBodHRwOi8vd3d3LmJiYy5jby51ay9ncmVhdGxha2VzLyAgLiBUaGlzIG1ha2VzIHNlbnNl IGZyb20gYSBsaW5ndWlzdGljIHBvaW50IG9mIHZpZXcgc2luY2UgYXMgSSB1bmRlcnN0YW5kIGl0 LCB0aGUgdHdvIGxhbmd1YWdlcyBhcmUgYWxtb3N0IHRoZSBzYW1lLiBXaGVuIGxvb2tpbmcgYXQg dGhlIHZpZXcgKHBhZ2UpIHNvdXJjZSwgb25lIG5vdGVzIHRoYXQgdGhleSB1c2UgbGFuZz0icnci IChmb3IgS2lueWFyd2FuZGEpLiBJdCBtYXkgYmUgdGhhdCB0aGUgcGFnZXMgSSBjaGVja2VkIGFy ZSBwcm9wZXJseSBLaW55YXJ3YW5kYSBhbmQgYW4gZXhwZXJ0IHdvdWxkIGtub3cgdGhhdCB0aGV5 IGFyZSBub3QgS2lydW5kaSAocm4pLCBidXQgaXQgaXMgaW4gYW55IGV2ZW50IHRydWUgdGhhdCB0 aGVyZSBpcyBubyBjb2RlIGVsZW1lbnQgdG8gY292ZXIgYm90aCBsYW5ndWFnZXMuDQoNCkknbSBj dXJpb3VzIGlmIHRoZXJlIGlzIGFueSBvdGhlciByZWNvbW1lbmRlZCB3YXkgdG8gaGFuZGxlIHN1 Y2ggYSBzaXR1YXRpb24gd2hlcmUgd2ViIGNvbnRlbnQgbWF5IGJlIGRlbGliZXJhdGVseSBhbmQg ZWFzaWx5IGRlc2lnbmVkIHRvIGNvdmVyIG1vcmUgdGhhbiBvbmUgbGFuZ3VhZ2UgYXMgZGVmaW5l ZCBieSBJU08gNjM5IHdoZW4gdGhlcmUgaXMgbm90IGN1cnJlbnRseSBhbnkgbWFjcm9sYW5ndWFn ZSBjb2RlIGZvciB0aGVtLiBDb3VsZCBvbmUgZm9yIGV4YW1wbGUgZGVmaW5lIGEgd2hvbGUgcGFn ZSBhcyBoYXZpbmcgdHdvIGxhbmd1YWdlcz8gRS5nLiwgc29tZXRoaW5nIGxpa2UgbGFuZz0icncs IHJuIj8NCg0KVGhhbmtzIGluIGFkdmFuY2UgZm9yIGFueSBmZWVkYmFjay4NCg0KRG9uDQoNCg0K --_000_DDB6DE6E9D27DD478AE6D1BBBB83579566EBDDCC4DNAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpEPSJE QVY6IiB4bWxuczptdD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3Nv YXAvbWVldGluZ3MvIiB4bWxuczp4Mj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvZXhjZWwvMjAwMy94bWwiIHhtbG5zOm9pcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvc29hcC9kaXJlY3RvcnkvIiB4bWxuczpkcz0iaHR0cDovL3d3dy53 My5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6ZHNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vZGF0YS91ZGMiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl bWEiIHhtbG5zOnN1Yj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3Nv YXAvMjAwMi8xL2FsZXJ0cy8iIHhtbG5zOmVjPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3ht bGVuYyMiIHhtbG5zOnNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQv IiB4bWxuczpzcHM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2Fw LyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIg eG1sbnM6dWRjcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9zb2FwIiB4 bWxuczp1ZGN4Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxmaWxl IiB4bWxuczp1ZGNwMnA9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91ZGMvcGFy dHRvcGFydCIgeG1sbnM6d2Y9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL3dvcmtmbG93LyIgeG1sbnM6ZHNzcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2k9Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vb2ZmaWNlLzIwMDYvZGlnc2lnIiB4bWxuczptZHNzaT0iaHR0cDovL3NjaGVt YXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9kaWdpdGFsLXNpZ25hdHVyZSIgeG1s bnM6bXZlcj0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL21hcmt1cC1jb21wYXRp YmlsaXR5LzIwMDYiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNl LzIwMDQvMTIvb21tbCIgeG1sbnM6bXJlbHM9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRz Lm9yZy9wYWNrYWdlLzIwMDYvcmVsYXRpb25zaGlwcyIgeG1sbnM6c3B3cD0iaHR0cDovL21pY3Jv c29mdC5jb20vc2hhcmVwb2ludC93ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0PSJodHRwOi8vc2No ZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYvdHlwZXMiIHhtbG5zOmV4 MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv bWVzc2FnZXMiIHhtbG5zOnBwdHNsPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJl cG9pbnQvc29hcC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsPSJodHRwOi8vbWljcm9zb2Z0LmNv bS93ZWJzZXJ2aWNlcy9TaGFyZVBvaW50UG9ydGFsU2VydmVyL1B1Ymxpc2hlZExpbmtzU2Vydmlj ZSIgeG1sbnM6Wj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbToiIHhtbG5zOnN0PSImIzE7IiB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEg aHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04 Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0 ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDb3JkaWEgTmV3IjsNCglwYW5v c2UtMToyIDExIDMgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJD YW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ikx1Y2lkYSBTYW5zIFVuaWNvZGUiOw0KCXBhbm9zZS0xOjIgMTEgNiAyIDMgNSA0IDIgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdl OlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1GUiBsaW5rPWJs dWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SWYgaXQgaXMgY29u dGVudCBpbiBvbmUNCmxpbmd1aXN0aWMgdmFyaWV0eSBhbmQgY3JhZnRlZCB0byBzZXJ2ZSB0d28g YXVkaWVuY2VzIGRlZW1lZCBpbiA2MzktMyB0byBiZQ0KZGlzdGluY3QgbGFuZ3VhZ2VzLCB0aGVu IHRoYXQgc3RyaWtlcyBtZSBhcyBhIHBvdGVudGlhbCBtYWNyb2xhbmd1YWdlIHNjZW5hcmlvLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+T25lIGtleSBxdWVzdGlvbiBpcw0KaG93IG5hcnJvdyBhIHNjb3BlIG9mIGNvbnRlbnQgaXMg bmVlZGVkIGFuZCBob3cgbXVjaCBkZWxpYmVyYXRlIGVmZm9ydCBpcw0KbmVlZGVkIHRvIGNyYWZ0 IHNvbWV0aGluZyBsaWtlIHRoYXQuIEZvciBpbnN0YW5jZSwgYSBkb2N1bWVudCBjb25zaXN0aW5n IG9mIOKAnFBhcGEh4oCdDQpjYW4gc2VydmUgbWFueSBkaWZmZXJlbnQgYXVkaWVuY2VzLCBidXQg dGhhdCBpcyBzb2xlbHkgYmVjYXVzZSB0aGUgc2NvcGUgb2YNCmNvbnRlbnQgaXMgc28gY29uc3Ry YWluZWQsIGFuZCBmb3IgdGhhdCByZWFzb24gdGhlIGJhciBpcyBub3QgbWV0IGZvciBhDQptYWNy b2xhbmd1YWdlLiBCdXQgaWYgaXTigJlzIGVhc3kgZm9yIGEgY29udGVudCBwcm92aWRlciB0byBj b21lIHVwIHdpdGggY29udGVudA0KdGhhdCBzZXJ2ZXMgYm90aCwgdGhlbiB0aGF04oCZcyBpbnRl cmVzdGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5Bbm90aGVyIGtleSBxdWVzdGlvbg0KaXMgd2h5IHRoYXQgY29udGVudCBpcyBm dW5jdGlvbmFsIGZvciBib3RoIGF1ZGllbmNlcy4gSXMgaXQgYmVjYXVzZSBpdCBpcyBleHByZXNz ZWQNCmluIGEgdmFyaWV0eSB0aGF0IGNhbiByZWFsbHkgYmUgY29uc2lkZXJlZCBjb21tb24sIG9y IGlzIGl0IGJlY2F1c2UgaXTigJlzDQphY3R1YWxseSBpbiBsYW5ndWFnZSBBIGFuZCA5MCUgb2Yg c3BlYWtlcnMgaW4gbGFuZ3VhZ2UgQiBhcmUgZnVuY3Rpb25hbGx5DQpiaWxpbmd1YWwgaW4gQT8g RG9lcyB0aGUgY29tbW9uLWlkZW50aWZ5IGxhYmVsIHJlZmxlY3QgYWN0dWFsIGxpbmd1aXN0aWMN CmNvbW1vbmFsaXR5LCBvciBpcyBpdCBhIGxvZ2lzdGljIHRvb2wgdXNlZCBpbiB0aGUgcmVwb3Np dG9yeSB0byByZWZsZWN0IG1lcmVseQ0KYSBkdWFsIHRhc2tpbmc/PG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nY29sb3I6IzFGNDk3RCc+U29tZSB0aG91Z2h0cy4NCkRpc2N1c3MgaXQgd2l0aCB0aGUgNjM5 LTMgUkEuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UGV0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXY+DQoN CjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFob21h Iiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gbHRy dS1ib3VuY2VzQGlldGYub3JnDQpbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24g QmVoYWxmIE9mIDwvYj5QaGlsbGlwcywgQWRkaXNvbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEFwcmlsIDA4LCAyMDA5IDU6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IERvbiBPc2Jvcm47ICdM VFJVIFdvcmtpbmcgR3JvdXAnOyAnSUVURiBMYW5ndWFnZXMgRGlzY3Vzc2lvbic8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtMdHJ1XSBIb3cgdG8gaGFuZGxlIG1hY3JvbGFuZ3VhZ2Ugd2hlbiBu byBjb2RlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5IVE1MIGNlcnRhaW5seSBh bGxvd3MNCnlvdSB0byBkZWNsYXJlIHRoYXQgc29tZSBjb250ZW50IGlzIGFwcGxpY2FibGUgdG8g bW9yZSB0aGFuIG9uZSBsYW5ndWFnZQ0KYXVkaWVuY2UuIFNlZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsgPGEN CmhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSL2kxOG4taHRtbC10ZWNoLWxhbmcvI3JpMjAwNDA3 MjguMTIxMzU4NDQ0Ij5odHRwOi8vd3d3LnczLm9yZy9UUi9pMThuLWh0bWwtdGVjaC1sYW5nLyNy aTIwMDQwNzI4LjEyMTM1ODQ0NDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5PdGhlcndpc2UsIEpvaG4NCkNvd2Fu4oCZcyBhZHZp Y2Ugc2VlbXMgYXBwcm9wcmlhdGXigKYgSVNPIDYzOS0zIG9yIElTTyA2MzktNSB3b3VsZCBiZSB5 b3VyIG5leHQNCnN0b3AuIE5vdGUgdGhhdCBtYWNyb2xhbmd1YWdlcyBhcmUgc29tZXRpbWVzIHBy b2JsZW1hdGljYWwsIHNvIHlvdSBtaWdodCBhbHNvDQpjb25zaWRlciBhIGNvbGxlY3Rpb24gY29k ZSBpbnN0ZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiTHVjaWRhIFNhbnMgVW5pY29kZSIs InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+QWRkaXNvbiBQaGlsbGlwczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiTHVjaWRhIFNhbnMgVW5pY29kZSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+R2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2 PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJMdWNpZGEgU2FucyBVbmlj b2RlIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBTYW5zIFVuaWNvZGUiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJMdWNpZGEgU2FucyBVbmlj b2RlIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5JdCBpcyBhbiBhcmNoaXRlY3R1cmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBsdHJ1LWJvdW5jZXNA aWV0Zi5vcmcNClttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2Yg PC9iPkRvbiBPc2Jvcm48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAwOCwgMjAw OSA0OjQwIFBNPGJyPg0KPGI+VG86PC9iPiAnTFRSVSBXb3JraW5nIEdyb3VwJzsgJ0lFVEYgTGFu Z3VhZ2VzIERpc2N1c3Npb24nPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtMdHJ1XSBIb3cgdG8gaGFu ZGxlIG1hY3JvbGFuZ3VhZ2Ugd2hlbiBubyBjb2RlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTPkluIGxvb2tpbmcgYXQgdGhlIEJCQyB3ZWJzaXRlJ3Mgb2ZmZXJpbmdzDQppbiBB ZnJpY2FuIGxhbmd1YWdlcywgb25lIG5vdGVzIHRoYXQgdGhleSBoYXZlIGdyb3VwZWQgS2lueWFy d2FuZGEgYW5kIEtpcnVuZGkNCnRvZ2V0aGVyIHVuZGVyIDxhIGhyZWY9Imh0dHA6Ly93d3cuYmJj LmNvLnVrL2dyZWF0bGFrZXMvIj5odHRwOi8vd3d3LmJiYy5jby51ay9ncmVhdGxha2VzLzwvYT4m bmJzcDsNCi4gVGhpcyBtYWtlcyBzZW5zZSBmcm9tIGEgbGluZ3Vpc3RpYyBwb2ludCBvZiB2aWV3 IHNpbmNlIGFzIEkgdW5kZXJzdGFuZCBpdCwNCnRoZSB0d28gbGFuZ3VhZ2VzIGFyZSBhbG1vc3Qg dGhlIHNhbWUuIFdoZW4gbG9va2luZyBhdCB0aGUgdmlldyAocGFnZSkgc291cmNlLA0Kb25lIG5v dGVzIHRoYXQgdGhleSB1c2UgbGFuZz0mcXVvdDtydyZxdW90OyAoZm9yIEtpbnlhcndhbmRhKS4g SXQgbWF5IGJlIHRoYXQNCnRoZSBwYWdlcyBJIGNoZWNrZWQgYXJlIHByb3Blcmx5IEtpbnlhcndh bmRhIGFuZCBhbiBleHBlcnQgd291bGQga25vdyB0aGF0IHRoZXkNCmFyZSBub3QgS2lydW5kaSAo cm4pLCBidXQgaXQgaXMgaW4gYW55IGV2ZW50IHRydWUgdGhhdCB0aGVyZSBpcyBubyBjb2RlIGVs ZW1lbnQNCnRvIGNvdmVyIGJvdGggbGFuZ3VhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5JJ20gY3VyaW91 cyBpZiB0aGVyZSBpcyBhbnkgb3RoZXINCnJlY29tbWVuZGVkIHdheSB0byBoYW5kbGUgc3VjaCBh IHNpdHVhdGlvbiB3aGVyZSB3ZWIgY29udGVudCBtYXkgYmUNCmRlbGliZXJhdGVseSBhbmQgZWFz aWx5IGRlc2lnbmVkIHRvIGNvdmVyIG1vcmUgdGhhbiBvbmUgbGFuZ3VhZ2UgYXMgZGVmaW5lZCBi eQ0KSVNPIDYzOSB3aGVuIHRoZXJlIGlzIG5vdCBjdXJyZW50bHkgYW55IG1hY3JvbGFuZ3VhZ2Ug Y29kZSBmb3IgdGhlbS4gQ291bGQgb25lDQpmb3IgZXhhbXBsZSBkZWZpbmUgYSB3aG9sZSBwYWdl IGFzIGhhdmluZyB0d28gbGFuZ3VhZ2VzPyBFLmcuLCBzb21ldGhpbmcgbGlrZQ0KbGFuZz0mcXVv dDtydywgcm4mcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPlRoYW5rcyBpbiBhZHZhbmNlIGZvciBhbnkg ZmVlZGJhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPkRvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+ DQo= --_000_DDB6DE6E9D27DD478AE6D1BBBB83579566EBDDCC4DNAEXMSGC117re_-- From duerst@it.aoyama.ac.jp Wed Apr 8 21:10:48 2009 Return-Path: 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 B28B53A6A0A for ; Wed, 8 Apr 2009 21:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 Mt2P9WNiUQl8 for ; Wed, 8 Apr 2009 21:10:47 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id E41A83A68D0 for ; Wed, 8 Apr 2009 21:10:46 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n394BqfU023454 for ; Thu, 9 Apr 2009 13:11:52 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 4921_8e057838_24bc_11de_8023_0019b9e2b3d9; Thu, 09 Apr 2009 13:11:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40462) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 9 Apr 2009 13:10:57 +0900 Message-ID: <49DD7570.1090002@it.aoyama.ac.jp> Date: Thu, 09 Apr 2009 13:11:28 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: "Phillips, Addison" References: <011e01c9b8a3$58ab9670$0a02c350$@net> <4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70@EX-SEA5-D.ant.amazon.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 'IETF Languages Discussion' , 'LTRU Working Group' Subject: Re: [Ltru] How to handle macrolanguage when no code? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:10:48 -0000 On 2009/04/09 9:53, Phillips, Addison wrote: > HTML certainly allows you to declare that some content is applicable to more than one language audience. See: Read "HTTP" for "HTML" here. HTML allows you to declare that different parts of a Web page are in different languages, but not that one and the same (part of a) Web page are in more than one language. Regards, Martin. > > http://www.w3.org/TR/i18n-html-tech-lang/#ri20040728.121358444 > > Otherwise, John Cowan’s advice seems appropriate… ISO 639-3 or ISO 639-5 would be your next stop. Note that macrolanguages are sometimes problematical, so you might also consider a collection code instead. > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Don Osborn > Sent: Wednesday, April 08, 2009 4:40 PM > To: 'LTRU Working Group'; 'IETF Languages Discussion' > Subject: [Ltru] How to handle macrolanguage when no code? > > In looking at the BBC website's offerings in African languages, one notes that they have grouped Kinyarwanda and Kirundi together under http://www.bbc.co.uk/greatlakes/ . This makes sense from a linguistic point of view since as I understand it, the two languages are almost the same. When looking at the view (page) source, one notes that they use lang="rw" (for Kinyarwanda). It may be that the pages I checked are properly Kinyarwanda and an expert would know that they are not Kirundi (rn), but it is in any event true that there is no code element to cover both languages. > > I'm curious if there is any other recommended way to handle such a situation where web content may be deliberately and easily designed to cover more than one language as defined by ISO 639 when there is not currently any macrolanguage code for them. Could one for example define a whole page as having two languages? E.g., something like lang="rw, rn"? > > Thanks in advance for any feedback. > > Don > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From addison@amazon.com Wed Apr 8 21:15:55 2009 Return-Path: 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 F06783A6B14 for ; Wed, 8 Apr 2009 21:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.134 X-Spam-Level: X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, 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 9tSyIX+13D-s for ; Wed, 8 Apr 2009 21:15:55 -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 63FFB28C0EC for ; Wed, 8 Apr 2009 21:15:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,158,1238976000"; d="scan'208";a="250641350" 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; 09 Apr 2009 04:16:57 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n394Gtlr002613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 9 Apr 2009 04:16:57 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Wed, 8 Apr 2009 21:16:55 -0700 From: "Phillips, Addison" To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Date: Wed, 8 Apr 2009 21:16:52 -0700 Thread-Topic: [Ltru] How to handle macrolanguage when no code? Thread-Index: Acm4yVL8YEyQBxkmQ/mP40wkzV54rAAADogg Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019F40ED88@EX-SEA5-D.ant.amazon.com> References: <011e01c9b8a3$58ab9670$0a02c350$@net> <4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70@EX-SEA5-D.ant.amazon.com> <49DD7570.1090002@it.aoyama.ac.jp> In-Reply-To: <49DD7570.1090002@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: 'IETF Languages Discussion' , 'LTRU Working Group' Subject: Re: [Ltru] How to handle macrolanguage when no code? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:15:56 -0000 PiANCj4gT24gMjAwOS8wNC8wOSA5OjUzLCBQaGlsbGlwcywgQWRkaXNvbiB3cm90ZToNCj4gPiBI VE1MIGNlcnRhaW5seSBhbGxvd3MgeW91IHRvIGRlY2xhcmUgdGhhdCBzb21lIGNvbnRlbnQgaXMN Cj4gYXBwbGljYWJsZSB0byBtb3JlIHRoYW4gb25lIGxhbmd1YWdlIGF1ZGllbmNlLiBTZWU6DQo+ IA0KPiBSZWFkICJIVFRQIiBmb3IgIkhUTUwiIGhlcmUuIEhUTUwgYWxsb3dzIHlvdSB0byBkZWNs YXJlIHRoYXQNCj4gZGlmZmVyZW50DQo+IHBhcnRzIG9mIGEgV2ViIHBhZ2UgYXJlIGluIGRpZmZl cmVudCBsYW5ndWFnZXMsIGJ1dCBub3QgdGhhdCBvbmUNCj4gYW5kIHRoZQ0KPiBzYW1lIChwYXJ0 IG9mIGEpIFdlYiBwYWdlIGFyZSBpbiBtb3JlIHRoYW4gb25lIGxhbmd1YWdlLg0KPiANCg0KVGhh dCdzIGNvcnJlY3QuIEFsdGhvdWdoIHRoaXMgYWxzbyBhcHBsaWVzIHRvIEhUTUwgdmlhIHRoZSA8 bWV0YT4gdGFnLg0KDQpUaGUgJ2xhbmcnIGF0dHJpYnV0ZSBpbiBIVE1MIChhcyB3aXRoIHRoZSB4 bWw6bGFuZyBhdHRyaWJ1dGUgaW4gWE1MKSBhbGxvdyBvbmx5IGEgc2luZ2xlIGxhbmd1YWdlIHRh ZyB0byBiZSBhcHBsaWVkIHRvIGEgc3BlY2lmaWMgc2NvcGUgKndpdGhpbiogYSBkb2N1bWVudC4g SSBzaG91bGQgcG9pbnQgb3V0IHRoYXQgdGhlIGJlc3QgcHJhY3RpY2UgbGluayBJIHBvaW50ZWQg dG8gYWxzbyBtYWtlcyB0aGlzIGRpc3RpbmN0aW9uOiB5b3UgY2FuIGRlY2xhcmUgdGhlICJ0YXJn ZXQgYXVkaWVuY2UiIGluIG9uZSB3YXkgYW5kIHRoZSAiZG9jdW1lbnQgcHJvY2Vzc2luZyBsYW5n dWFnZSIgc2VwYXJhdGVseSBpbiBhbm90aGVyLg0KDQpBZGRpc29uDQo= From duerst@it.aoyama.ac.jp Thu Apr 9 00:30:58 2009 Return-Path: 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 E63423A6403 for ; Thu, 9 Apr 2009 00:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.126 X-Spam-Level: X-Spam-Status: No, score=-0.126 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 wY3mMrngXDjy for ; Thu, 9 Apr 2009 00:30:56 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 9BB073A6B01 for ; Thu, 9 Apr 2009 00:30:56 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n397W3nK015815 for ; Thu, 9 Apr 2009 16:32:03 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 05ab_84eaa838_24d8_11de_883b_001d0969ab06; Thu, 09 Apr 2009 16:32:02 +0900 Received: from [IPv6:::1] ([133.2.210.1]:50827) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 9 Apr 2009 16:31:08 +0900 Message-ID: <49DDA45B.407@it.aoyama.ac.jp> Date: Thu, 09 Apr 2009 16:31:39 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Randy Presuhn References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <004301c9b8a6$5bcb45a0$6801a8c0@oemcomputer> In-Reply-To: <004301c9b8a6$5bcb45a0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexey Melnikov , LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] AD review of draft-ietf-ltru-4645bis-10.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:30:59 -0000 Hello Alex, On 2009/04/09 9:01, Randy Presuhn wrote: > Hi - > > (I've added the ltru WG list, and trimmed from the recipient list those people > subscribed to that list.) > > Responding as a co-chair... Responding as the other co-chair... >> From: "Alexey Melnikov" >> To: "Martin J. Dürst"; "Mark Davis"; "Chris Newman"; "Randy > Presuhn"; "Addison Phillips"; "Doug Ewell" >> Cc: "Lisa Dusseault" >> Sent: Wednesday, April 08, 2009 4:10 PM >> Subject: AD review of draft-ietf-ltru-4645bis-10.txt > ... >> Ok, here is my AD review of 4645bis. Please let me know if you >> agree/disagree with various issues I've raised. >> Answers to some of my questions might be obvious after I review 4646bis >> in details (I've only skimmed it so far). But I am sending my comments >> anyway in order to speed up the process. > > Thanks! Thanks, too! >> So far I don't have any issues with the document that I think need to be >> fixed before IETF LC. However, I would appreciate a reply to my review >> before issuing IETF LC. Also please let me know if you want me to last >> call the document as is, or if you would like to update the document to >> address my comments first. > > I'd prefer to last call it as is, but would defer to co-chair (and document > shepherd) Martin Duerst's opinion. I'd also prefer to last call it as is, unless your comments result in (relatively) major changes. >> General: I hope the WG has discussed "let's remove all registrations >> from the document before publication" approach. Personally I would >> rather the document contain IANA registrations upon publication. > > Yes, this was discussed at some length back when the WG produced RFC 4645. > There was considerable concern that if the content were left in the > RFC, even with health warnings, the risk would be too great that > developers would use the RFC rather than the registry. Indeed. This is something that I would by now call well established, at least between the WG, IANA, and the RFC Editor. I guess we could even recommend it to other WGs, although there are probably not that many that face similar problems. >>> 1. Introduction >> [...] >> >>> In its initial phase as an Internet-Draft, this memo also contained a >>> complete replacement of the contents of the Language Subtag Registry >>> to be used by the Internet Assigned Numbers Authority (IANA) in >>> updating it. This content was deleted from this memo prior to >>> publication as an RFC. >> Is this paragraph useful? If the content is deleted when the updated >> RFC is published, this doesn't give a reader any useful information. If >> the content is not deleted when the updated RFC is published, then this >> text would be wrong. > > It's there to explain the absence of content in the RFC. Without it, > the document would be puzzlingly content-free. We were pretty much > painted into this corner by the rules on references to I-Ds, etc. > Back when we did 4645, we considered many alternatives, and this was > the path that got consensus. When we started the update, the question > was raised whether we wanted to go this route again, but there was > no groundswell of support for any alternative. Yes, in particular also because this way of things worked well the last time, and there was no indication that it wouldn't this time. >> I think there is at least one more place where there is a similar issue. > > There is strong consensus to delete the content upon publication. > If we had known of a tidier way of delivering the bulk update to IANA, > we'd have used it. > > I've just picked a nearly random registration from the document: > >>> Type: language >>> Subtag: orv >>> Description: Old Russian >>> Added: 2029-09-09 >> I am confused here. Why is the "Added" date in the future? > > See section 2.1: > The values of the File-Date field, the Added date for each new subtag > record, and the Deprecated date for each existing grandfathered or > redundant tag deprecated by this update were set to a date as near as > practical to the date of IESG approval of this memo. [RFC EDITOR > NOTE: these dates are initially set to 2029-09-09 for easy > recognition, and MUST be updated during AUTH48.] > >>> 6. Changes >>> >>> [RFC EDITOR NOTE: this section is provided for the convenience of >>> reviewers and will be removed from the final document.] >>> >>> This memo is a new work, not an incremental update of [RFC4645]. The >>> procedure for populating the original Language Subtag Registry, >>> specified by the earlier [RFC4646], is included by reference to >>> [RFC4645]. Therefore, no changes from [RFC4645] are listed in this >>> section. >> I am not sure I understand this comment and I don't think I find it >> convincing. At least one of the acting ADs thinks that any XXXXbis draft >> must contain "Changes since RFC XXXX" section, which tries to summarize >> all major changes. (I.e. the AD would put a DISCUSS on the document >> until this is resolved). Personally I find a section listing all changes >> to be very useful, but I don't consider lack of it as a blocking issue. >> >> If the document is really not a bis draft, then the draft name is confusing. > > We did discuss whether an incremental update or bulk-replace update was > easier to cope with, and opted for the bulk-replace approach. To describe > the detailed differences in the changes section would be counterproductive at best. > If this MUST be done to clear a potential DISCUSS, perhaps a compromise > would be to add a summary of the form "XXX new records added, YYY old > records modified." Actually listing all the new ones would NOT be something > I'd like to even consider. I think the scientific term is "a gazillion," > and would nearly double the length of the document, which might make it a > little unwieldy. :-) I *would* consider asking the editor to list the > ones to which changes (other thatn formatting changes) were made (without > detailing the nature of the change), but only if (1) necessary to clear a > DISCUSS, and (2) endorsed by the WG. However, my strong preference > is to provide no more detail than is absolutely necessary, particularly > since the body is to be gutted as part of the publication process anyway. I very much agree with Randy here. I think one way of describing the differences to RFC 4645 would be to say that they are the the sum of a) changes to the IANA registry since it was set up with RFC 4645, as documented by the registration process (pointer to ietf-languages mailing list,...) b) changes to the IANA registry as documented in the draft itself It is b) that any actual or potential implementer should care about. Anybody interested in the differences between RFC 4646 in draft stage and the current draft would do so only for pure curiosity, unrelated to implementation/deployment issues. There is also the question of what exactly "bis" means. The original Latin meaning seems to mean just "twice". One use I know of is as an additional label when inserting new paragraphs or chapters into a law. In that case, e.g. 45 and 45bis are related only by proximity (of location and topic, the later being the reason for the former), but 45bis is explicitly not a revised version of 45, otherwise, 45 would have been updated/amended directly, rather than inserting a new 45bis. In the IETF, 'bis' usually denotes a new version of something existing, but I'm not aware of any provisions that require this to be a strict, direct update. It was very natural for the WG to call this 4645bis in parallel with 4646bis, and because in many ways it actually is a new version of 4645, it is 4645 all over, although with a the twist that in the meantime, the IANA registry has evolved. In conclusion, I very much understand said ADs desire to have changes to specs clearly documented, and I guess I'd ask for the same if I were in his/her position. However, I hope it is clear from all of the above that for our specific situation, 4645bis is slightly different in function from an average draft-bis, and that documenting the full differences between 4645 and 4645bis wouldn't make sense operationally, and that we have documented the differences in as far as they are relevant and sensible. Personally, I also hope that said AD will be open to the argumentation given above, and I promise to make every effort to convince him/her, unless you (Alex) think that such convincing efforts are a lost cause in the first place. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Thu Apr 9 00:46:28 2009 Return-Path: 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 3F09D3A6E82 for ; Thu, 9 Apr 2009 00:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.116 X-Spam-Level: X-Spam-Status: No, score=-0.116 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 GBDoMuI+vMNK for ; Thu, 9 Apr 2009 00:46:27 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 570DC3A6A05 for ; Thu, 9 Apr 2009 00:46:26 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n397lY4r018449 for ; Thu, 9 Apr 2009 16:47:34 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 226d_b0096048_24da_11de_a27d_0019b9e2b3d9; Thu, 09 Apr 2009 16:47:34 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37673) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 9 Apr 2009 16:46:33 +0900 Message-ID: <49DDA7F7.3050000@it.aoyama.ac.jp> Date: Thu, 09 Apr 2009 16:47:03 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Randy Presuhn References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <004301c9b8a6$5bcb45a0$6801a8c0@oemcomputer> <49DD3E4A.7020103@isode.com> <005701c9b8a9$68e39960$6801a8c0@oemcomputer> In-Reply-To: <005701c9b8a9$68e39960$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexey Melnikov , LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] AD review of draft-ietf-ltru-4645bis-10.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:46:28 -0000 On 2009/04/09 9:23, Randy Presuhn wrote: > Hi - > >> From: "Alexey Melnikov" >> To: "Randy Presuhn" >> Cc: "Lisa Dusseault"; "LTRU Working Group" >> Sent: Wednesday, April 08, 2009 5:16 PM >> Subject: Re: AD review of draft-ietf-ltru-4645bis-10.txt > ... >> After your explanation I think the sentence that reads "This memo is a >> new work, not an incremental update of [RFC4645]" should be reworded or >> removed. Otherwise it is just asking for a question: "if this is new >> work, how come it is 4645bis"? At least it is not clear to me what the >> WG is calling "new work". > > As a technical contributor... > > I'd prefer to simply delete the sentence. Fine with me, too (both technically and as a co-chair). Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From randy_presuhn@mindspring.com Thu Apr 9 11:55:54 2009 Return-Path: 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 5944C3A6B4B for ; Thu, 9 Apr 2009 11:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 Y-bxgI+g0IZH for ; Thu, 9 Apr 2009 11:55:53 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C538D3A6CBA for ; Thu, 9 Apr 2009 11:55:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UiWJpps1fow/Fit/GwrbPBOPCYY5QPZp8q6IKp2iLDUuf0sTtbuiWXqvSFiO4dwJ; h=Received:Message-ID:From:To:Cc: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 [69.3.145.83] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrzQl-0005U8-J0; Thu, 09 Apr 2009 14:56:55 -0400 Message-ID: <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <578826AC751B478EA347DE854007AE70@DGBP7M81> <49DE37C1.9060900@isode.com> Date: Thu, 9 Apr 2009 11:58:56 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173a12b9ddd9785d7565b973db15b72ac89350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.83 Cc: Alexey Melnikov , Lisa Dusseault Subject: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 18:55:54 -0000 Hi - Our AD has made a request: > From: "Alexey Melnikov" > To: "Doug Ewell" > Cc: "Martin J. Dürst" ; "Mark Davis" ; "Chris Newman" ; "Randy Presuhn" ; "Addison Phillips" ; "Lisa Dusseault" > Sent: Thursday, April 09, 2009 11:00 AM > Subject: Re: AD review of draft-ietf-ltru-4645bis-10.txt > > Doug Ewell wrote: > > > Alexey Melnikov wrote: > > [...] > > >>> This memo is a new work, not an incremental update of [RFC4645]. The > >>> procedure for populating the original Language Subtag Registry, > >>> specified by the earlier [RFC4646], is included by reference to > >>> [RFC4645]. Therefore, no changes from [RFC4645] are listed in this > >>> section. > >> > >> I am not sure I understand this comment and I don't think I find it > >> convincing. At least one of the acting ADs thinks that any XXXXbis > >> draft must contain "Changes since RFC XXXX" section, which tries to > >> summarize all major changes. (I.e. the AD would put a DISCUSS on the > >> document until this is resolved). Personally I find a section listing > >> all changes to be very useful, but I don't consider lack of it as a > >> blocking issue. > >> > >> If the document is really not a bis draft, then the draft name is > >> confusing. > > > > This is a good point. Technically, I supposed this is not really > > "4645bis" in the traditional sense. Rather, it is the accompanying > > document to 4646bis, in exactly the same way that 4645 was the > > accompanying document to 4646. > > > > The paragraph is correct; 4645bis does not start from zero and apply > > the 4645 processes, modulo some "bis" changes. Rather, it starts from > > the current (post-4645) Registry and applies processes that are > > similar (but not identical) to those of 4645, against different > > standards (ISO 639-3 and 639-5). > > > > If a change must be made to avoid a DISCUSS, then probably the most > > sensible change would be to rename the draft. Listing all the changes > > from 4645 would be like describing the development of the airplane by > > starting with a recapitulation of the development of the car. > > I would like the WG to reach consensus if the document should be renamed > or not. > Personally I would prefer the document to be renamed, as I find the > whole concept of "this is names as 4645bis, but really isn't" to be > quite confusing. > But I can issue IETF LC on the current document, if this is what people > want. As co-chair... The document in question has the file name draft-ietf-ltru-4645bis-10.txt If we change the name, we'd need to update 464bis accordingly. I'm not sure how the I-D tracker tool would handle a name change at this stage of the process, but I assume the IESG can cope with it. The question for this working group is two-fold: (1) Do we want to change the name of the file? (2) If so, what do we want the new name to be? We need to hear from the WG quickly so we can put this issue to rest. Randy From addison@amazon.com Thu Apr 9 12:07:29 2009 Return-Path: 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 297923A6A17 for ; Thu, 9 Apr 2009 12:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 c7juJ4TRwj6f for ; Thu, 9 Apr 2009 12:07:28 -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 D8F4E3A6C92 for ; Thu, 9 Apr 2009 12:07:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,161,1238976000"; d="scan'208";a="251003998" 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; 09 Apr 2009 19:08:35 +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 n39J8Ycj016923 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 9 Apr 2009 19:08:35 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4103.ant.amazon.com ([10.248.163.24]) with mapi; Thu, 9 Apr 2009 12:08:34 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 9 Apr 2009 12:08:32 -0700 Thread-Topic: [Ltru] Ltru consensus call: rename 4645bis I-D? Thread-Index: Acm5RPuTXG/I2vrcSpqTRmeCPTdriAAAJfCA Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019F40F437@EX-SEA5-D.ant.amazon.com> References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <578826AC751B478EA347DE854007AE70@DGBP7M81> <49DE37C1.9060900@isode.com> <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> In-Reply-To: <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Alexey Melnikov , Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 19:07:29 -0000 V2UgY2FsbGVkIGl0IDQ2NDViaXMgbWFpbmx5IGJlY2F1c2Ugd2UgY2FsbGVkIDQ2NDZiaXMgIjQ2 NDZiaXMiICh0aGF0IGRvY3VtZW50IHJlYWxseSBpcyBhICdiaXMnIGRvY3VtZW50KS4gQW5kIGl0 ICppcyoga2luZCBvZiBjb25mdXNpbmcgdGhhdCB0aGUgImZpcnN0IiBJRCBieSBuYW1lIGlzIHRo ZSByZWdpc3RyeSBhbmQgbm90IHRoZSAiZ292ZXJuaW5nIGRvY3VtZW50IiwgYnV0IHRoYXQgaXMg YW4gYXJ0aWZhY3Qgb2YgdGhlIG9yaWdpbmFsIFJGQyBudW1iZXIgYXNzaWdubWVudC4NCg0KU2lu Y2UgdGhlIElEIG5hbWUgZG9lc24ndCByZWFsbHkgbWVhbiBhbnl0aGluZyBhbmQgaXQgZGlzYXBw ZWFycyBkdXJpbmcgdGhlIFJGQyBwdWJsaXNoaW5nIHByb2Nlc3MgYW5kIHNpbmNlIG9uZSBjb3Vs ZCBtYWtlIHRoZSBjYXNlIHRoYXQgaXQgaXMgdGhlICJzZWNvbmQiIHJlZ2lzdHJ5IG1hc3MgdXBk YXRlLCBoZW5jZSAnYmlzJywgSSB0aGluayBpdCB1bm5lY2Vzc2FyeSB0byBjaGFuZ2UgdGhlIG5h bWUgYW5kIHdvdWxkIGRpc2NvdXJhZ2UgY2hhbmdpbmcgaXQuDQoNCklmIHdlIHdlcmUgdG8gY2hh bmdlIGl0LCBhIG5pY2UgZ2VuZXJpYyBuYW1lIHdvdWxkIHByb2JhYmx5IGJlIG1vc3QgYXBwcm9w cmlhdGU6ICJkcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnkiLCAiZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lz dHJ5LXVwZGF0ZSIgKHdoaWNoIGlzIHJlZHVuZGFudCwgc2luY2UgJ2x0cnUnIHN0YW5kcyBmb3Ig TGFuZ3VhZ2UgVGFnIFJlZ2lzdHJ5IFVwZGF0ZSksIG9yIGV2ZW4gImRyYWZ0LWlldGYtbHRydS1k YXRhIj8/DQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNo aXRlY3QgLS0gTGFiMTI2DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUu DQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYu b3JnXSBPbg0KPiBCZWhhbGYgT2YgUmFuZHkgUHJlc3Vobg0KPiBTZW50OiBUaHVyc2RheSwgQXBy aWwgMDksIDIwMDkgMTE6NTkgQU0NCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBDYzogQWxl eGV5IE1lbG5pa292OyBMaXNhIER1c3NlYXVsdA0KPiBTdWJqZWN0OiBbTHRydV0gTHRydSBjb25z ZW5zdXMgY2FsbDogcmVuYW1lIDQ2NDViaXMgSS1EPw0KPiANCj4gSGkgLQ0KPiANCj4gT3VyIEFE IGhhcyBtYWRlIGEgcmVxdWVzdDoNCj4gDQo+ID4gRnJvbTogIkFsZXhleSBNZWxuaWtvdiIgPGFs ZXhleS5tZWxuaWtvdkBpc29kZS5jb20+DQo+ID4gVG86ICJEb3VnIEV3ZWxsIiA8ZG91Z0Bld2Vs bGljLm9yZz4NCj4gPiBDYzogIk1hcnRpbiBKLiBEw7xyc3QiIDxkdWVyc3RAaXQuYW95YW1hLmFj LmpwPjsgIk1hcmsgRGF2aXMiDQo+IDxtYXJrQG1hY2NoaWF0by5jb20+OyAiQ2hyaXMgTmV3bWFu IiA8Q2hyaXMuTmV3bWFuQHN1bi5jb20+OyAiUmFuZHkNCj4gUHJlc3VobiIgPHJhbmR5X3ByZXN1 aG5AbWluZHNwcmluZy5jb20+OyAiQWRkaXNvbiBQaGlsbGlwcyINCj4gPGFkZGlzb25AaW50ZXIt bG9jYWxlLmNvbT47ICJMaXNhIER1c3NlYXVsdCINCj4gPGxpc2EuZHVzc2VhdWx0QG1lc3NhZ2lu Z2FyY2hpdGVjdHMuY29tPg0KPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwOSwgMjAwOSAxMTow MCBBTQ0KPiA+IFN1YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sdHJ1LTQ2NDVi aXMtMTAudHh0DQo+ID4NCj4gPiBEb3VnIEV3ZWxsIHdyb3RlOg0KPiA+DQo+ID4gPiBBbGV4ZXkg TWVsbmlrb3YgPGFsZXhleSBkb3QgbWVsbmlrb3YgYXQgaXNvZGUgZG90IGNvbT4gd3JvdGU6DQo+ ID4NCj4gPiAgWy4uLl0NCj4gPg0KPiA+ID4+PiBUaGlzIG1lbW8gaXMgYSBuZXcgd29yaywgbm90 IGFuIGluY3JlbWVudGFsIHVwZGF0ZSBvZg0KPiBbUkZDNDY0NV0uICBUaGUNCj4gPiA+Pj4gcHJv Y2VkdXJlIGZvciBwb3B1bGF0aW5nIHRoZSBvcmlnaW5hbCBMYW5ndWFnZSBTdWJ0YWcNCj4gUmVn aXN0cnksDQo+ID4gPj4+IHNwZWNpZmllZCBieSB0aGUgZWFybGllciBbUkZDNDY0Nl0sIGlzIGlu Y2x1ZGVkIGJ5IHJlZmVyZW5jZQ0KPiB0bw0KPiA+ID4+PiBbUkZDNDY0NV0uICBUaGVyZWZvcmUs IG5vIGNoYW5nZXMgZnJvbSBbUkZDNDY0NV0gYXJlIGxpc3RlZA0KPiBpbiB0aGlzDQo+ID4gPj4+ IHNlY3Rpb24uDQo+ID4gPj4NCj4gPiA+PiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGlz IGNvbW1lbnQgYW5kIEkgZG9uJ3QgdGhpbmsgSQ0KPiBmaW5kIGl0DQo+ID4gPj4gY29udmluY2lu Zy4gQXQgbGVhc3Qgb25lIG9mIHRoZSBhY3RpbmcgQURzIHRoaW5rcyB0aGF0IGFueQ0KPiBYWFhY YmlzDQo+ID4gPj4gZHJhZnQgbXVzdCBjb250YWluICJDaGFuZ2VzIHNpbmNlIFJGQyBYWFhYIiBz ZWN0aW9uLCB3aGljaA0KPiB0cmllcyB0bw0KPiA+ID4+IHN1bW1hcml6ZSBhbGwgbWFqb3IgY2hh bmdlcy4gKEkuZS4gdGhlIEFEIHdvdWxkIHB1dCBhIERJU0NVU1MNCj4gb24gdGhlDQo+ID4gPj4g ZG9jdW1lbnQgdW50aWwgdGhpcyBpcyByZXNvbHZlZCkuIFBlcnNvbmFsbHkgSSBmaW5kIGEgc2Vj dGlvbg0KPiBsaXN0aW5nDQo+ID4gPj4gYWxsIGNoYW5nZXMgdG8gYmUgdmVyeSB1c2VmdWwsIGJ1 dCBJIGRvbid0IGNvbnNpZGVyIGxhY2sgb2YgaXQNCj4gYXMgYQ0KPiA+ID4+IGJsb2NraW5nIGlz c3VlLg0KPiA+ID4+DQo+ID4gPj4gSWYgdGhlIGRvY3VtZW50IGlzIHJlYWxseSBub3QgYSBiaXMg ZHJhZnQsIHRoZW4gdGhlIGRyYWZ0IG5hbWUNCj4gaXMNCj4gPiA+PiBjb25mdXNpbmcuDQo+ID4g Pg0KPiA+ID4gVGhpcyBpcyBhIGdvb2QgcG9pbnQuICBUZWNobmljYWxseSwgSSBzdXBwb3NlZCB0 aGlzIGlzIG5vdA0KPiByZWFsbHkNCj4gPiA+ICI0NjQ1YmlzIiBpbiB0aGUgdHJhZGl0aW9uYWwg c2Vuc2UuICBSYXRoZXIsIGl0IGlzIHRoZQ0KPiBhY2NvbXBhbnlpbmcNCj4gPiA+IGRvY3VtZW50 IHRvIDQ2NDZiaXMsIGluIGV4YWN0bHkgdGhlIHNhbWUgd2F5IHRoYXQgNDY0NSB3YXMgdGhlDQo+ ID4gPiBhY2NvbXBhbnlpbmcgZG9jdW1lbnQgdG8gNDY0Ni4NCj4gPiA+DQo+ID4gPiBUaGUgcGFy YWdyYXBoIGlzIGNvcnJlY3Q7IDQ2NDViaXMgZG9lcyBub3Qgc3RhcnQgZnJvbSB6ZXJvIGFuZA0K PiBhcHBseQ0KPiA+ID4gdGhlIDQ2NDUgcHJvY2Vzc2VzLCBtb2R1bG8gc29tZSAiYmlzIiBjaGFu Z2VzLiAgUmF0aGVyLCBpdA0KPiBzdGFydHMgZnJvbQ0KPiA+ID4gdGhlIGN1cnJlbnQgKHBvc3Qt NDY0NSkgUmVnaXN0cnkgYW5kIGFwcGxpZXMgcHJvY2Vzc2VzIHRoYXQgYXJlDQo+ID4gPiBzaW1p bGFyIChidXQgbm90IGlkZW50aWNhbCkgdG8gdGhvc2Ugb2YgNDY0NSwgYWdhaW5zdCBkaWZmZXJl bnQNCj4gPiA+IHN0YW5kYXJkcyAoSVNPIDYzOS0zIGFuZCA2MzktNSkuDQo+ID4gPg0KPiA+ID4g SWYgYSBjaGFuZ2UgbXVzdCBiZSBtYWRlIHRvIGF2b2lkIGEgRElTQ1VTUywgdGhlbiBwcm9iYWJs eSB0aGUNCj4gbW9zdA0KPiA+ID4gc2Vuc2libGUgY2hhbmdlIHdvdWxkIGJlIHRvIHJlbmFtZSB0 aGUgZHJhZnQuICBMaXN0aW5nIGFsbCB0aGUNCj4gY2hhbmdlcw0KPiA+ID4gZnJvbSA0NjQ1IHdv dWxkIGJlIGxpa2UgZGVzY3JpYmluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlDQo+IGFpcnBsYW5l IGJ5DQo+ID4gPiBzdGFydGluZyB3aXRoIGEgcmVjYXBpdHVsYXRpb24gb2YgdGhlIGRldmVsb3Bt ZW50IG9mIHRoZSBjYXIuDQo+ID4NCj4gPiBJIHdvdWxkIGxpa2UgdGhlIFdHIHRvIHJlYWNoIGNv bnNlbnN1cyBpZiB0aGUgZG9jdW1lbnQgc2hvdWxkIGJlDQo+IHJlbmFtZWQNCj4gPiBvciBub3Qu DQo+ID4gUGVyc29uYWxseSBJIHdvdWxkIHByZWZlciB0aGUgZG9jdW1lbnQgdG8gYmUgcmVuYW1l ZCwgYXMgSSBmaW5kDQo+IHRoZQ0KPiA+IHdob2xlIGNvbmNlcHQgb2YgInRoaXMgaXMgbmFtZXMg YXMgNDY0NWJpcywgYnV0IHJlYWxseSBpc24ndCIgdG8NCj4gYmUNCj4gPiBxdWl0ZSBjb25mdXNp bmcuDQo+ID4gQnV0IEkgY2FuIGlzc3VlIElFVEYgTEMgb24gdGhlIGN1cnJlbnQgZG9jdW1lbnQs IGlmIHRoaXMgaXMgd2hhdA0KPiBwZW9wbGUNCj4gPiB3YW50Lg0KPiANCj4gQXMgY28tY2hhaXIu Li4NCj4gDQo+IFRoZSBkb2N1bWVudCBpbiBxdWVzdGlvbiBoYXMgdGhlIGZpbGUgbmFtZSBkcmFm dC1pZXRmLWx0cnUtNDY0NWJpcy0NCj4gMTAudHh0DQo+IElmIHdlIGNoYW5nZSB0aGUgbmFtZSwg d2UnZCBuZWVkIHRvIHVwZGF0ZSA0NjRiaXMgYWNjb3JkaW5nbHkuICBJJ20NCj4gbm90DQo+IHN1 cmUgaG93IHRoZSBJLUQgdHJhY2tlciB0b29sIHdvdWxkIGhhbmRsZSBhIG5hbWUgY2hhbmdlIGF0 IHRoaXMNCj4gc3RhZ2UNCj4gb2YgdGhlIHByb2Nlc3MsIGJ1dCBJIGFzc3VtZSB0aGUgSUVTRyBj YW4gY29wZSB3aXRoIGl0LiAgVGhlDQo+IHF1ZXN0aW9uIGZvcg0KPiB0aGlzIHdvcmtpbmcgZ3Jv dXAgaXMgdHdvLWZvbGQ6DQo+ICAgICgxKSBEbyB3ZSB3YW50IHRvIGNoYW5nZSB0aGUgbmFtZSBv ZiB0aGUgZmlsZT8NCj4gICAgKDIpIElmIHNvLCB3aGF0IGRvIHdlIHdhbnQgdGhlIG5ldyBuYW1l IHRvIGJlPw0KPiANCj4gV2UgbmVlZCB0byBoZWFyIGZyb20gdGhlIFdHIHF1aWNrbHkgc28gd2Ug Y2FuIHB1dCB0aGlzIGlzc3VlIHRvDQo+IHJlc3QuDQo+IA0KPiBSYW5keQ0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFp bGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sdHJ1DQo= From mark.edward.davis@gmail.com Thu Apr 9 12:09:10 2009 Return-Path: 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 A0CDA3A6CC3 for ; Thu, 9 Apr 2009 12:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 t6OzEn2VQu3N for ; Thu, 9 Apr 2009 12:09:09 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 535173A6C93 for ; Thu, 9 Apr 2009 12:09:09 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so751645wfg.31 for ; Thu, 09 Apr 2009 12:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=OE7tpbCKbtI+eCjdfHYkxRrm+aq4+Iwg4agJCWl3Yg0=; b=pUJXUfgcWSTHKNwyNlsJteaA29LoyNRNdVaQ/FtEfDipGgc4ZYd+4KfYgOxBQi2N/A 37FMiNF8qBrE1dLFK3aAhZuz4QnG0MBwpxRtgJnRzRfJPKOS1JS6KxCQBdP6V3Kl92VO tt0kno/neWIen7d8J+wpqDHF4wAlMS6vokKt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=wqIJlvkItG/Bo+pSQayEA3tmyXrMgLVS/ykJtPanYjxWwjYfuy8loNRCZkKYx4R5HX I4aP7E+qdpALzu95XxCxNqupvIyyHuGcCvOrrjmMfccDB7YWTq1PQsJAyE3JeMKM5Dej SiotTELWaybn1NF4J+NguwvzsSVP5uFiw90lE= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.82.13 with SMTP id f13mr957689wfb.301.1239304217527; Thu, 09 Apr 2009 12:10:17 -0700 (PDT) In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019F40F437@EX-SEA5-D.ant.amazon.com> References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <578826AC751B478EA347DE854007AE70@DGBP7M81> <49DE37C1.9060900@isode.com> <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019F40F437@EX-SEA5-D.ant.amazon.com> Date: Thu, 9 Apr 2009 12:10:17 -0700 X-Google-Sender-Auth: 961a7997c92f6a53 Message-ID: <30b660a20904091210v757db30dl1cfe7645076494b7@mail.gmail.com> From: Mark Davis To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=001636e90e87a78b65046723ff03 Cc: Alexey Melnikov , LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 19:09:10 -0000 --001636e90e87a78b65046723ff03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree; it isn't worth futzing with. Mark On Thu, Apr 9, 2009 at 12:08, Phillips, Addison wrote: > We called it 4645bis mainly because we called 4646bis "4646bis" (that > document really is a 'bis' document). And it *is* kind of confusing that = the > "first" ID by name is the registry and not the "governing document", but > that is an artifact of the original RFC number assignment. > > Since the ID name doesn't really mean anything and it disappears during t= he > RFC publishing process and since one could make the case that it is the > "second" registry mass update, hence 'bis', I think it unnecessary to cha= nge > the name and would discourage changing it. > > If we were to change it, a nice generic name would probably be most > appropriate: "draft-ietf-ltru-registry", "draft-ietf-ltru-registry-update= " > (which is redundant, since 'ltru' stands for Language Tag Registry Update= ), > or even "draft-ietf-ltru-data"?? > > Addison > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > > Behalf Of Randy Presuhn > > Sent: Thursday, April 09, 2009 11:59 AM > > To: LTRU Working Group > > Cc: Alexey Melnikov; Lisa Dusseault > > Subject: [Ltru] Ltru consensus call: rename 4645bis I-D? > > > > Hi - > > > > Our AD has made a request: > > > > > From: "Alexey Melnikov" > > > To: "Doug Ewell" > > > Cc: "Martin J. D=C3=BCrst" ; "Mark Davis" > > ; "Chris Newman" ; "Randy > > Presuhn" ; "Addison Phillips" > > ; "Lisa Dusseault" > > > > > Sent: Thursday, April 09, 2009 11:00 AM > > > Subject: Re: AD review of draft-ietf-ltru-4645bis-10.txt > > > > > > Doug Ewell wrote: > > > > > > > Alexey Melnikov wrote: > > > > > > [...] > > > > > > >>> This memo is a new work, not an incremental update of > > [RFC4645]. The > > > >>> procedure for populating the original Language Subtag > > Registry, > > > >>> specified by the earlier [RFC4646], is included by reference > > to > > > >>> [RFC4645]. Therefore, no changes from [RFC4645] are listed > > in this > > > >>> section. > > > >> > > > >> I am not sure I understand this comment and I don't think I > > find it > > > >> convincing. At least one of the acting ADs thinks that any > > XXXXbis > > > >> draft must contain "Changes since RFC XXXX" section, which > > tries to > > > >> summarize all major changes. (I.e. the AD would put a DISCUSS > > on the > > > >> document until this is resolved). Personally I find a section > > listing > > > >> all changes to be very useful, but I don't consider lack of it > > as a > > > >> blocking issue. > > > >> > > > >> If the document is really not a bis draft, then the draft name > > is > > > >> confusing. > > > > > > > > This is a good point. Technically, I supposed this is not > > really > > > > "4645bis" in the traditional sense. Rather, it is the > > accompanying > > > > document to 4646bis, in exactly the same way that 4645 was the > > > > accompanying document to 4646. > > > > > > > > The paragraph is correct; 4645bis does not start from zero and > > apply > > > > the 4645 processes, modulo some "bis" changes. Rather, it > > starts from > > > > the current (post-4645) Registry and applies processes that are > > > > similar (but not identical) to those of 4645, against different > > > > standards (ISO 639-3 and 639-5). > > > > > > > > If a change must be made to avoid a DISCUSS, then probably the > > most > > > > sensible change would be to rename the draft. Listing all the > > changes > > > > from 4645 would be like describing the development of the > > airplane by > > > > starting with a recapitulation of the development of the car. > > > > > > I would like the WG to reach consensus if the document should be > > renamed > > > or not. > > > Personally I would prefer the document to be renamed, as I find > > the > > > whole concept of "this is names as 4645bis, but really isn't" to > > be > > > quite confusing. > > > But I can issue IETF LC on the current document, if this is what > > people > > > want. > > > > As co-chair... > > > > The document in question has the file name draft-ietf-ltru-4645bis- > > 10.txt > > If we change the name, we'd need to update 464bis accordingly. I'm > > not > > sure how the I-D tracker tool would handle a name change at this > > stage > > of the process, but I assume the IESG can cope with it. The > > question for > > this working group is two-fold: > > (1) Do we want to change the name of the file? > > (2) If so, what do we want the new name to be? > > > > We need to hear from the WG quickly so we can put this issue to > > rest. > > > > Randy > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e90e87a78b65046723ff03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree; it isn't worth futzing with.

Mark


On Thu, Apr 9, 2009 at 12:08, Phillips, = Addison <addison= @amazon.com> wrote:
We called it 4645bis mainly because we called 4646bis "4646bis" (= that document really is a 'bis' document). And it *is* kind of conf= using that the "first" ID by name is the registry and not the &qu= ot;governing document", but that is an artifact of the original RFC nu= mber assignment.

Since the ID name doesn't really mean anything and it disappears during= the RFC publishing process and since one could make the case that it is th= e "second" registry mass update, hence 'bis', I think it = unnecessary to change the name and would discourage changing it.

If we were to change it, a nice generic name would probably be most appropr= iate: "draft-ietf-ltru-registry", "draft-ietf-ltru-registry-= update" (which is redundant, since 'ltru' stands for Language = Tag Registry Update), or even "draft-ietf-ltru-data"??

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On
> Behalf Of Randy Presuhn
> Sent: Thursday, April 09, 2009 11:59 AM
> To: LTRU Working Group
> Cc: Alexey Melnikov; Lisa Dusseault
> Subject: [Ltru] Ltru consensus call: rename 4645bis I-D?
>
> Hi -
>
> Our AD has made a request:
>
> > From: "Alexey Melnikov" <alexey.melnikov@isode.com>
> > To: "Doug Ewell" <doug@ewellic.org>
> > Cc: "Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp>; "Mark Davis" > <mark@macchiato.com>; = "Chris Newman" <Chris.= Newman@sun.com>; "Randy
> Presuhn" <rand= y_presuhn@mindspring.com>; "Addison Phillips"
> <addison@inter-locale.c= om>; "Lisa Dusseault"
> <lisa.dus= seault@messagingarchitects.com>
> > Sent: Thursday, April 09, 2009 11:00 AM
> > Subject: Re: AD review of draft-ietf-ltru-4645bis-10.txt
> >
> > Doug Ewell wrote:
> >
> > > Alexey Melnikov <alexey dot melnikov at isode dot com>= wrote:
> >
> > =C2=A0[...]
> >
> > >>> This memo is a new work, not an incremental update o= f
> [RFC4645]. =C2=A0The
> > >>> procedure for populating the original Language Subta= g
> Registry,
> > >>> specified by the earlier [RFC4646], is included by r= eference
> to
> > >>> [RFC4645]. =C2=A0Therefore, no changes from [RFC4645= ] are listed
> in this
> > >>> section.
> > >>
> > >> I am not sure I understand this comment and I don't = think I
> find it
> > >> convincing. At least one of the acting ADs thinks that a= ny
> XXXXbis
> > >> draft must contain "Changes since RFC XXXX" se= ction, which
> tries to
> > >> summarize all major changes. (I.e. the AD would put a DI= SCUSS
> on the
> > >> document until this is resolved). Personally I find a se= ction
> listing
> > >> all changes to be very useful, but I don't consider = lack of it
> as a
> > >> blocking issue.
> > >>
> > >> If the document is really not a bis draft, then the draf= t name
> is
> > >> confusing.
> > >
> > > This is a good point. =C2=A0Technically, I supposed this is = not
> really
> > > "4645bis" in the traditional sense. =C2=A0Rather, = it is the
> accompanying
> > > document to 4646bis, in exactly the same way that 4645 was t= he
> > > accompanying document to 4646.
> > >
> > > The paragraph is correct; 4645bis does not start from zero a= nd
> apply
> > > the 4645 processes, modulo some "bis" changes. =C2= =A0Rather, it
> starts from
> > > the current (post-4645) Registry and applies processes that = are
> > > similar (but not identical) to those of 4645, against differ= ent
> > > standards (ISO 639-3 and 639-5).
> > >
> > > If a change must be made to avoid a DISCUSS, then probably t= he
> most
> > > sensible change would be to rename the draft. =C2=A0Listing = all the
> changes
> > > from 4645 would be like describing the development of the > airplane by
> > > starting with a recapitulation of the development of the car= .
> >
> > I would like the WG to reach consensus if the document should be<= br> > renamed
> > or not.
> > Personally I would prefer the document to be renamed, as I find > the
> > whole concept of "this is names as 4645bis, but really isn&#= 39;t" to
> be
> > quite confusing.
> > But I can issue IETF LC on the current document, if this is what<= br> > people
> > want.
>
> As co-chair...
>
> The document in question has the file name draft-ietf-ltru-4645bis- > 10.txt
> If we change the name, we'd need to update 464bis accordingly. =C2= =A0I'm
> not
> sure how the I-D tracker tool would handle a name change at this
> stage
> of the process, but I assume the IESG can cope with it. =C2=A0The
> question for
> this working group is two-fold:
> =C2=A0 =C2=A0(1) Do we want to change the name of the file?
> =C2=A0 =C2=A0(2) If so, what do we want the new name to be?
>
> We need to hear from the WG quickly so we can put this issue to
> rest.
>
> Randy
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e90e87a78b65046723ff03-- From addison@amazon.com Thu Apr 9 12:09:26 2009 Return-Path: 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 A619C3A6CC3 for ; Thu, 9 Apr 2009 12:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 5dSMtJ3dZ1pb for ; Thu, 9 Apr 2009 12:09:25 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id D029228C0DE for ; Thu, 9 Apr 2009 12:09:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,161,1238976000"; d="scan'208";a="209067697" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Apr 2009 19:10:33 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n39JAW9f005981 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Thu, 9 Apr 2009 19:10:33 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Thu, 9 Apr 2009 12:10:32 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Thu, 9 Apr 2009 12:10:31 -0700 Thread-Topic: one co-editor on vacation... Thread-Index: Acm5Rtn/98+U2i3VSB+1yHIvO991+Q== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019F40F43E@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] one co-editor on vacation... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 19:09:26 -0000 QWxsLA0KDQpJIHdpbGwgYmUgb24gdmFjYXRpb24sIGZhciBmcm9tIHRoZSBJbnRlcm5ldCwgZm9y IHRoZSBuZXh0IHRlbiBkYXlzIChzdGFydGluZyB0b21vcnJvdywgOSBBcHJpbCkuIER1cmluZyBt eSBhYnNlbmNlLCBNYXJrIERhdmlzIHdpbGwgYmUgd2VhcmluZyB0aGUgZWRpdG9yIGhhdCBmb3Ig NDY0NmJpcy4gSSB3aWxsIHJldHVybiBvbiAyMCBBcHJpbC4NCg0KQWRkaXNvbg0KDQpBZGRpc29u IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRp b25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0K DQo= From kent.karlsson14@comhem.se Thu Apr 9 13:19:17 2009 Return-Path: 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 B21A43A6CD0 for ; Thu, 9 Apr 2009 13:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 UvVSYchpWw2u for ; Thu, 9 Apr 2009 13:19:17 -0700 (PDT) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by core3.amsl.com (Postfix) with ESMTP id D01CA3A6407 for ; Thu, 9 Apr 2009 13:19:16 -0700 (PDT) Received: from c83-248-191-93.bredband.comhem.se ([83.248.191.93]:33893 helo=[192.168.1.4]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1Ls0jN-0004ok-3c; Thu, 09 Apr 2009 22:20:15 +0200 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 09 Apr 2009 22:20:01 +0200 From: Kent Karlsson To: Randy Presuhn , LTRU Working Group Message-ID: Thread-Topic: [Ltru] Ltru consensus call: rename 4645bis I-D? Thread-Index: Acm5UI9UaZ76fOHTQUGp8+cSSUBfgw== In-Reply-To: <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 83.248.191.93 X-Scan-Result: No virus found in message 1Ls0jN-0004ok-3c. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Ls0jN-0004ok-3c 16a8880befad3984555de2c765c3b022 Cc: Alexey Melnikov , Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:19:17 -0000 > (1) Do we want to change the name of the file? I think that such a filename change would be quite pointless. That filename is fine as it is. /kent k From randy_presuhn@mindspring.com Thu Apr 9 13:23:55 2009 Return-Path: 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 81AC73A696C for ; Thu, 9 Apr 2009 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 Wb1sGci5Fav6 for ; Thu, 9 Apr 2009 13:23:54 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id CC3DC3A6BE0 for ; Thu, 9 Apr 2009 13:23:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gh5BI0UiLJaafNZgxqh6qFMluDInlh9a8s6UKhDw14L7Iquvot6LzBGlXHLAxlx4; h=Received:Message-ID:From:To:Cc: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 [69.3.145.83] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ls0o2-0000kz-Gr; Thu, 09 Apr 2009 16:25:02 -0400 Message-ID: <000b01c9b951$8b87eb80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.0.0.20.2.20090301210247.09515b90@localhost> <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> <49D31E17.6080305@it.aoyama.ac.jp> <49DD20BB.7040706@isode.com> <49DD2EE2.7040302@isode.com> <578826AC751B478EA347DE854007AE70@DGBP7M81> <49DE37C1.9060900@isode.com> <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019F40F437@EX-SEA5-D.ant.amazon.com> <30b660a20904091210v757db30dl1cfe7645076494b7@mail.gmail.com> Date: Thu, 9 Apr 2009 13:27:02 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1731315be38af04dc86c7e8f63c629e0ba6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.83 Cc: Alexey Melnikov , Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:23:55 -0000 Hi - As a technical contributor... > (1) Do we want to change the name of the file? I think this would be a particularly pointless bit of hoop-jumping. I would prefer to *not* change the file name unless that's the only way we can get it through the IESG. > (2) If so, what do we want the new name to be? If we *must* change the name, something like draft-ietf-ltru-registry-content-reinitialization-data might make sense, though I don't think it would really be helpful. Randy From petercon@microsoft.com Thu Apr 9 15:54:52 2009 Return-Path: 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 196963A6CE2 for ; Thu, 9 Apr 2009 15:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.884 X-Spam-Level: X-Spam-Status: No, score=-10.884 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jGxDxMoIrQoE for ; Thu, 9 Apr 2009 15:54:51 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 710DD3A6BB9 for ; Thu, 9 Apr 2009 15:54:51 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 9 Apr 2009 15:55:59 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.88.96]) with mapi; Thu, 9 Apr 2009 15:55:59 -0700 From: Peter Constable To: Kent Karlsson , Randy Presuhn , LTRU Working Group Date: Thu, 9 Apr 2009 15:55:57 -0700 Thread-Topic: [Ltru] Ltru consensus call: rename 4645bis I-D? Thread-Index: Acm5UI9UaZ76fOHTQUGp8+cSSUBfgwAFcTzw Message-ID: References: <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexey Melnikov , Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 22:54:52 -0000 +1 -----Original Message----- From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Ken= t Karlsson Sent: Thursday, April 09, 2009 1:20 PM To: Randy Presuhn; LTRU Working Group Cc: Alexey Melnikov; Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? > (1) Do we want to change the name of the file? I think that such a filename change would be quite pointless. That filename is fine as it is. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru From alexey.melnikov@isode.com Thu Apr 9 16:13:47 2009 Return-Path: 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 32D553A6358 for ; Thu, 9 Apr 2009 16:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_SBL=1.551] 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 zIqqUnJrgosd for ; Thu, 9 Apr 2009 16:13:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 367323A68BF for ; Thu, 9 Apr 2009 16:13:46 -0700 (PDT) Received: from [92.40.31.65] (92.40.31.65.sub.mbb.three.co.uk [92.40.31.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 10 Apr 2009 00:14:52 +0100 Message-ID: <49DE8141.7050608@isode.com> Date: Fri, 10 Apr 2009 00:14:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: LTRU Working Group References: <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 23:13:47 -0000 Ok, I think I have enough feedback on this. I've requested IETF LC. Peter Constable wrote: >+1 > >-----Original Message----- >From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Kent Karlsson >Sent: Thursday, April 09, 2009 1:20 PM >To: Randy Presuhn; LTRU Working Group >Cc: Alexey Melnikov; Lisa Dusseault >Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? > > >>(1) Do we want to change the name of the file? >> >> >I think that such a filename change would be quite pointless. That filename >is fine as it is. > From duerst@it.aoyama.ac.jp Thu Apr 9 18:03:50 2009 Return-Path: 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 23D393A6C9E for ; Thu, 9 Apr 2009 18:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 C4WxbSpU71xm for ; Thu, 9 Apr 2009 18:03:48 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 929193A6CBD for ; Thu, 9 Apr 2009 18:03:47 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n3A14tlU020051 for ; Fri, 10 Apr 2009 10:04:55 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 63d1_9a56323a_256b_11de_a791_001d0969ab06; Fri, 10 Apr 2009 10:04:54 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40490) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 10 Apr 2009 10:03:53 +0900 Message-ID: <49DE9B25.7030606@it.aoyama.ac.jp> Date: Fri, 10 Apr 2009 10:04:37 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Alexey Melnikov References: <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> <49DE8141.7050608@isode.com> In-Reply-To: <49DE8141.7050608@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 01:03:50 -0000 On 2009/04/10 8:14, Alexey Melnikov wrote: > Ok, I think I have enough feedback on this. I've requested IETF LC. To Alex, with co-chair hat on: Thanks for moving so quickly. However, I strongly suggest to make sure LC happens for both 4646bis and 4645bis together. To the WG, with co-chair hat off: I agree with everybody that changing the filename at this point is pointless. Regards, Martin. > Peter Constable wrote: > >> +1 >> >> -----Original Message----- >> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf >> Of Kent Karlsson >> Sent: Thursday, April 09, 2009 1:20 PM >> To: Randy Presuhn; LTRU Working Group >> Cc: Alexey Melnikov; Lisa Dusseault >> Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? >> >> >>> (1) Do we want to change the name of the file? >>> >> I think that such a filename change would be quite pointless. That >> filename >> is fine as it is. >> > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From alexey.melnikov@isode.com Thu Apr 9 18:09:22 2009 Return-Path: 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 4B0073A6D0A for ; Thu, 9 Apr 2009 18:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SBL=1.551] 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 f1+awS0PQIqJ for ; Thu, 9 Apr 2009 18:09:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5422D3A6AE2 for ; Thu, 9 Apr 2009 18:09:21 -0700 (PDT) Received: from [92.40.31.65] (92.40.31.65.sub.mbb.three.co.uk [92.40.31.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 10 Apr 2009 02:10:27 +0100 Message-ID: <49DE9C58.2050305@isode.com> Date: Fri, 10 Apr 2009 02:09:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <003d01c9b945$3c84fc00$6801a8c0@oemcomputer> <49DE8141.7050608@isode.com> <49DE9B25.7030606@it.aoyama.ac.jp> In-Reply-To: <49DE9B25.7030606@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: LTRU Working Group , Lisa Dusseault Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 01:09:22 -0000 Martin J. D=FCrst wrote: > On 2009/04/10 8:14, Alexey Melnikov wrote: > >> Ok, I think I have enough feedback on this. I've requested IETF LC. > > To Alex, with co-chair hat on: > > Thanks for moving so quickly. However, I strongly suggest to make sure=20 > LC happens for both 4646bis and 4645bis together. I am reviewing 4646bis now and this is likely to be the case. In the=20 worst case IETF LC for 4646bis might start a couple of days later. From wwwrun@core3.amsl.com Thu Apr 9 18:57:01 2009 Return-Path: X-Original-To: ltru@ietf.org Delivered-To: ltru@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 71A4F3A6D18; Thu, 9 Apr 2009 18:57:00 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090410015701.71A4F3A6D18@core3.amsl.com> Date: Thu, 9 Apr 2009 18:57:01 -0700 (PDT) Cc: ltru@ietf.org Subject: [Ltru] Last Call: draft-ietf-ltru-4645bis (Update to the Language Subtag Registry) to Informational RFC X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 01:57:01 -0000 The IESG has received a request from the Language Tag Registry Update WG (ltru) to consider the following document: - 'Update to the Language Subtag Registry ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15205&rfc_flag=0 From doug@ewellic.org Thu Apr 9 21:05:44 2009 Return-Path: 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 7513E28C147 for ; Thu, 9 Apr 2009 21:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 VvTwVWH54gFb for ; Thu, 9 Apr 2009 21:05:43 -0700 (PDT) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by core3.amsl.com (Postfix) with SMTP id 9C2703A67D7 for ; Thu, 9 Apr 2009 21:05:37 -0700 (PDT) Received: (qmail 9239 invoked from network); 10 Apr 2009 04:06:46 -0000 Received: from unknown (67.166.27.148) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 10 Apr 2009 04:06:45 -0000 Message-ID: <4EF6A69C69F2427B817DE6A288B0B2D0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 9 Apr 2009 22:06:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 04:05:44 -0000 Randy Presuhn wrote: > The document in question has the file name > draft-ietf-ltru-4645bis-10.txt > If we change the name, we'd need to update 464bis accordingly. I'm > not sure how the I-D tracker tool would handle a name change at this > stage of the process, but I assume the IESG can cope with it. The > question for this working group is two-fold: > (1) Do we want to change the name of the file? > (2) If so, what do we want the new name to be? Just for the record, since Alexey has already requested Last Call, and I wouldn't want to delay that... As editor, I have no particular opinion on this. I had always assumed from the moment we started referring to "4646bis" and "4645bis" that the names made sense and would stick, but if the IETF wants to apply a particularly rigid interpretation to the suffix "bis"--referring only to a revised version of an existing document and never to a new document that serves the same purpose as an older one, in a new context--then that is their culture and far be it from me to change it. Virtually any name change would be a better alternative than retooling the draft as a revised version of 4645. That would be a disaster on many levels. As Addison pointed out, the name of the draft will disappear anyway once it is published as an RFC. As a side note, if we did change the name, it would entail almost no work from me, but might entail substantial work from Addison and/or Mark (whose draft contains references to mine) and from the co-chairs and/or AD (who have to deal with the I-D tracker and other records). -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From petercon@microsoft.com Thu Apr 9 23:58:29 2009 Return-Path: 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 899883A6845 for ; Thu, 9 Apr 2009 23:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.849 X-Spam-Level: X-Spam-Status: No, score=-10.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VEFOlcdSJ35I for ; Thu, 9 Apr 2009 23:58:28 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id DF30D3A6D41 for ; Thu, 9 Apr 2009 23:58:28 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 9 Apr 2009 23:59:37 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.18.53]) with mapi; Thu, 9 Apr 2009 23:59:37 -0700 From: Peter Constable To: LTRU Working Group Importance: low Date: Thu, 9 Apr 2009 23:59:35 -0700 Thread-Topic: [Ltru] Ltru consensus call: rename 4645bis I-D? Thread-Index: Acm5kd/7zdcvyEX3SwGKDaxPhgXivQAF8QsA Message-ID: References: <4EF6A69C69F2427B817DE6A288B0B2D0@DGBP7M81> In-Reply-To: <4EF6A69C69F2427B817DE6A288B0B2D0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 06:58:29 -0000 RG9lcyBhbnlvbmUga25vdyBpZiB1c2Ugb2YgImJpcyIgd2l0aGluIElFVEYgb3JpZ2luYXRlZCBp biBvbmUgb2YgdGhlIHJldmlzaW9ucyBvZiBCQ1A0Nz8gU29tZXdoZXJlIGFsb25nIHRoZSB3YXkg SSBnb3QgdGhhdCBpbXByZXNzaW9uLg0KDQoNCg0KUGV0ZXINCg== From duerst@it.aoyama.ac.jp Fri Apr 10 03:10:25 2009 Return-Path: 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 C66293A6CF6 for ; Fri, 10 Apr 2009 03:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 0LIZNyfDTJcr for ; Fri, 10 Apr 2009 03:10:24 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 0B8D23A6B2F for ; Fri, 10 Apr 2009 03:10:23 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n3AABVgF005350 for ; Fri, 10 Apr 2009 19:11:31 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 14ad_f662b584_25b7_11de_99b3_001d0969ab06; Fri, 10 Apr 2009 19:11:31 +0900 Received: from [IPv6:::1] ([133.2.210.1]:34450) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 10 Apr 2009 19:10:35 +0900 Message-ID: <49DF1B46.6060907@it.aoyama.ac.jp> Date: Fri, 10 Apr 2009 19:11:18 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Peter Constable References: <4EF6A69C69F2427B817DE6A288B0B2D0@DGBP7M81> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 10:10:25 -0000 I don't think so at all. http://tools.ietf.org/id/bis?maxhits=425&key=name&dir=asc will give you a list of all the drafts with 'bis' in it, as far as the tools site knows. Regards, Martin. On 2009/04/10 15:59, Peter Constable wrote: > Does anyone know if use of "bis" within IETF originated in one of the revisions of BCP47? Somewhere along the way I got that impression. > > > > Peter > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From addison@amazon.com Fri Apr 10 07:43:12 2009 Return-Path: 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 76C8A3A6DD5 for ; Fri, 10 Apr 2009 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.47 X-Spam-Level: X-Spam-Status: No, score=-106.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 CbGwkUCzUDPP for ; Fri, 10 Apr 2009 07:43:11 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id 8EB413A6DCA for ; Fri, 10 Apr 2009 07:43:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,167,1238976000"; d="scan'208";a="209346196" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2009 14:44:19 +0000 Received: from ex-hub-4103.ant.amazon.com (ex-hub-4103.sea5.amazon.com [10.248.163.24]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3AEiIiw029884 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 10 Apr 2009 14:44:19 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4103.ant.amazon.com ([10.248.163.24]) with mapi; Fri, 10 Apr 2009 07:44:18 -0700 From: "Phillips, Addison" To: Peter Constable , LTRU Working Group Date: Fri, 10 Apr 2009 07:44:15 -0700 Thread-Topic: [Ltru] Ltru consensus call: rename 4645bis I-D? Thread-Index: Acm5kd/7zdcvyEX3SwGKDaxPhgXivQAF8QsAABAuIjA= Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019F4BEF2E@EX-SEA5-D.ant.amazon.com> References: <4EF6A69C69F2427B817DE6A288B0B2D0@DGBP7M81> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 14:43:12 -0000 Tm8sIGl0IGRpZG4ndC4gJ2JpcycgaXMgYW4gYXBwZWxsYXRpb24gb2YgbG9uZy1zdGFuZGluZyBp biBJRVRGIGNpcmNsZXMuIEkgYmVsaWV2ZSBpdCBhY3R1YWxseSBvcmlnaW5hdGVkIHdpdGggSVRV ICh0ZWxlcGhvbnkgc3RhbmRhcmRzKS4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFBoaWxsaXBzDQpH bG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Omx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIFBldGVyIENvbnN0YWJsZQ0K PiBTZW50OiBGcmlkYXksIEFwcmlsIDEwLCAyMDA5IDEyOjAwIEFNDQo+IFRvOiBMVFJVIFdvcmtp bmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBMdHJ1IGNvbnNlbnN1cyBjYWxsOiByZW5h bWUgNDY0NWJpcyBJLUQ/DQo+IEltcG9ydGFuY2U6IExvdw0KPiANCj4gRG9lcyBhbnlvbmUga25v dyBpZiB1c2Ugb2YgImJpcyIgd2l0aGluIElFVEYgb3JpZ2luYXRlZCBpbiBvbmUgb2YNCj4gdGhl IHJldmlzaW9ucyBvZiBCQ1A0Nz8gU29tZXdoZXJlIGFsb25nIHRoZSB3YXkgSSBnb3QgdGhhdA0K PiBpbXByZXNzaW9uLg0KPiANCj4gDQo+IA0KPiBQZXRlcg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1 QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K From randy_presuhn@mindspring.com Fri Apr 10 11:42:37 2009 Return-Path: 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 58D793A6832 for ; Fri, 10 Apr 2009 11:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 EfaGLCOfCa+1 for ; Fri, 10 Apr 2009 11:42:36 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id A4C7A3A659B for ; Fri, 10 Apr 2009 11:42:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Q6zlA53+74rSJer0jYg7VgY2uc1Txbz8advpCBGojDkvSs9hA8SnyYDAuLeq2AVt; 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.80.250] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsLhZ-0003qC-Di for ltru@ietf.org; Fri, 10 Apr 2009 14:43:45 -0400 Message-ID: <002201c9ba0c$90283da0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4EF6A69C69F2427B817DE6A288B0B2D0@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019F4BEF2E@EX-SEA5-D.ant.amazon.com> Date: Fri, 10 Apr 2009 11:45:46 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1738779bc64ca578029bbff268c165d4723350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.250 Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 18:42:37 -0000 Hi - > From: "Phillips, Addison" > To: "Peter Constable" ; "LTRU Working Group" > Sent: Friday, April 10, 2009 7:44 AM > Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D? > > No, it didn't. 'bis' is an appellation of long-standing in IETF circles. > I believe it actually originated with ITU (telephony standards). For example, V.32bis, (never mind V.32ter) published in 1991 was an "extension" to V.32. (As a sometime writer of modem firmware, I have to say that calling it an "extension" was quite a stretch - the training/retraining protocol is substantially different, and there's a huge difference in capabilities.) As others have explained, "bis" has been around in other contexts for a long time. But we're straying off-topic. This thread has served its purpose. let's end it. Randy From alexey.melnikov@isode.com Sat Apr 11 01:07:48 2009 Return-Path: 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 0A1FB3A684B for ; Sat, 11 Apr 2009 01:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_SBL=1.551] 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 UzEsmnNTYiqf for ; Sat, 11 Apr 2009 01:07:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CF5DE3A659C for ; Sat, 11 Apr 2009 01:07:45 -0700 (PDT) Received: from [92.40.223.234] (92.40.223.234.sub.mbb.three.co.uk [92.40.223.234]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 11 Apr 2009 09:08:51 +0100 Message-ID: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 09:08:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: LTRU Working Group MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 08:07:48 -0000 I think the document is well written, but IANA registration rules are overwhelmingly complex. But I don't know if anything can be done about complexity of the registration procedure. IANA lists Michael Everson and Doug Ewell as the registry reviewers. Are they happy to continue being reviewers for the 4646bis? I have some comments/issues that need to be addressed or at least discussed before requesting IESG review of the document. However I am happy for the document to go to the IETF LC as is, so I've initiated IETF LC for the document. Below are my comments: 1). > 2.2.1. Primary Language Subtag [...] > 5. Any language subtags of 5 to 8 characters in length in the IANA [...] > At the time this document was created, there were no examples of > this kind of subtag and future registrations of this type are > discouraged: primary languages are strongly RECOMMENDED for > registration with ISO 639, and proposals rejected by ISO 639/ > RA-JAC will be closely scrutinized before they are registered > with IANA. [Unclear text] Scrutinized by whom? At this point in the document it is not clear who is going to perform the action. I think you meant that this would be done by the designated registry reviewer, so I suggest adding a forward reference here. 2). > 2.2.2. Extended Language Subtags [...] > 4. Although the ABNF production 'extlang' permits up to three > extended language tags in the language tag, extended language > subtags MUST NOT include another extended language subtag in > their Prefix. That is, the second and third extended language > subtag positions in a language tag are permanently reserved and > tags that include subtags in that position are invalid. [Unclear text] Clarification on what is meant by "permanently reserved" here would be appreciated. ("Permanently reserved" == "MUST NOT be registered, unless a future version of this document changes that"?) 3). Section 2.2.4 says: > F. All other UN numeric codes for countries or areas that do not > have an associated ISO 3166-1 alpha-2 code MUST NOT be > entered into the registry and MUST NOT be used to form > language tags. For more information about these codes, see > Section 3.4. And Section 3.4 says: > 16. UN M.49 has codes for both countries and areas (such as '276' > for Germany) and geographical regions and sub-regions (such as > '150' for Europe). UN M.49 country or area codes for which > there is no corresponding ISO 3166-1 code SHOULD NOT be Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in section 2.2.4. I think you need to change one of 2 sections. > registered, except as a surrogate for an ISO 3166-1 code that is > blocked from registration by an existing subtag. If such a code > becomes necessary, then the registration authority for ISO > 3166-1 SHOULD first be petitioned to assign a code to the > region. If the petition for a code assignment by ISO 3166-1 is > refused or not acted on in a timely manner, the registration > process described in Section 3.5 MAY then be used to register > the corresponding UN M.49 code. This way, UN M.49 codes remain > available as the value of last resort in cases where ISO 3166-1 > reassigns a deprecated value in the registry. 4). In Section 2.2.9: > Note well: although the 'Language-Tag' production appearing in this > document is functionally equivalent to the one in [RFC4646], it has > been changed to prevent certain errors in well-formedness arising > from the old 'grandfathered' production. This version of the ABNF is > RECOMMENDED as a replacement for the older version. (nit) I suggest deleting the last sentence, as it doesn't provide any useful information to a reader (as the WG wants draft-ietf-ltru-4646bis-21bis.txt to replace RFC 4646, it is clear that the WG believes that the new ABNF is better). Also I don't think it uses RFC 2119 keyword properly. 5). In Section 2.2.9: > The format of the registry is described by the following ABNF (per > [RFC5234]): > > registry = record *("%%" CRLF record) > record = 1*field > field = ( field-name field-sep field-body CRLF ) > field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] > field-sep = *SP ":" *SP > field-body = *([[*SP CRLF] 1*SP] 1*CHARS) > CHARS = (%x21-10FFFF) ; Unicode code points [ABNF error] While I understand what you mean here, I think the definition of CHARS doesn't match the requirement to use UTF-8 encoding stated earlier in section 3.1.1: The registry is a [Unicode] text file, using the UTF-8 [RFC3629] character encoding, and consists of a series of records stored in a format based on "record-jar" (described in [record-jar]). IMHO, you can use ABNF productions from [RFC3629] to fix that. 6). In Section 3.1.2: > Field-names MUST occur no more > than once per record, with the exception of the 'Description', > 'Comments', and sometimes the 'Prefix' field. (nit) Suggestion to reword using MUST NOT. E.g.: Field-names MUST NOT occur more than once per record, with the exception of the 'Description', 'Comments', and sometimes the 'Prefix' field. 7). In Section 3.4: > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that > conflict with existing subtags of the associated type, including > subtags that are deprecated, MUST NOT be entered into the > registry. The following additional considerations apply to > subtag values that are reassigned: [...] > F. For ISO 3166-1 codes, if there is no associated UN numeric > code, then the Language Subtag Reviewer SHALL petition the > UN to create one. If there is no response from the UN > within ninety days of the request being sent, the Language > Subtag Reviewer SHALL prepare a proposal for entering in the > IANA registry as soon as practical a registered variant > subtag as an alternate value for the new code. The form of > the registered variant subtag will be at the discretion of > the Language Subtag Reviewer and MUST conform to other > restrictions on variant subtags in this document. This > situation is very unlikely to ever occur. > > 16. UN M.49 has codes for both countries and areas (such as '276' > for Germany) and geographical regions and sub-regions (such as > '150' for Europe). UN M.49 country or area codes for which > there is no corresponding ISO 3166-1 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166-1 code that is > blocked from registration by an existing subtag. If such a code > becomes necessary, then the registration authority for ISO > 3166-1 SHOULD Why SHOULD is used here instead of SHALL? Similar text in 15.F says SHALL, which is stronger. Also, 15.F specifies expected response time (90 days), which is missing below. Any reason why you don't want to specify deadline in this case? > first be petitioned to assign a code to the > region. If the petition for a code assignment by ISO 3166-1 is > refused or not acted on in a timely manner, the registration > process described in Section 3.5 MAY then be used to register > the corresponding UN M.49 code. This way, UN M.49 codes remain > available as the value of last resort in cases where ISO 3166-1 > reassigns a deprecated value in the registry. 8). In Section 3.5: > The fields in the "Record Requested" section SHOULD follow the > requirements in Section 3.1. What are the reasons not to follow requirements in Section 3.1? (I.e. why is SHOULD used instead of MUST?) 9). > 3.8. Update of the Language Subtag Registry > > Upon adoption of this document the IANA Language Subtag Registry will > need an update so that it contains the complete set of subtags valid > in a language tag. This collection of subtags, along with a > description of the process used to create it, is described by > [draft-4645bis]. IANA will publish the updated version of the > registry described by this document using the instructions and > content of [draft-4645bis]. (nit) I think both 4645bis and 4646bis should be published at the same time. If this happens, then use of future tense in the published RFC would be confusing and will not match the reality. I suggest adding an RFC Editor note asking to fix this sentence. > Once published by IANA, the maintenance > procedures, rules, and registration processes described in this > document will be available for new registrations or updates. 10). > 5.1. Language Subtag Registry [...] > Whenever an entry is created or modified in the registry, the 'File- > Date' record at the start of the registry is updated to reflect the > most recent modification date in the [RFC3339] "full-date" format: > included in any request to insert or modify records will be a new > File-Date record indicating the acceptance date of the record. This > record is to be placed first in the registry, replacing the existing > File-Date record. In the event that the File-Date record present in > the registry has a later date than the record being inserted or > modified, then the latest (most recent) record will be preserved. I am confused by which date is going to be used by IANA in this case. Section 3.1.2 says: The first record in the registry is always the "File-Date" record. This record occurs only once in the file and contains a single field whose field-name is "File-Date". The field-body of this record contains the last modification date of this copy of the registry, making it possible to compare different versions of the registry. I think if File-Date record present in the registry has a later date than the record being inserted or modified, then IANA should use the date of update (which I assume would be after the record modification/addition date). This way any change to the IANA registry can be detected. 11). > 4.2. Meaning of the Language Tag [...] > o For information objects whose purpose is to provide alternatives, > the associated language tags could be regarded as a hint that the > content is provided in several languages and that one has to > inspect each of the alternatives in order to find its language or > languages. In this case, the presence of multiple tags might not > mean that one needs to be multi-lingual to get complete > understanding of the document. Example: MIME multipart/ > alternative. I think this needs an informative reference to MIME. 12). > 4.5. Canonicalization of Language Tags [...] > 3. Subtags of type 'extlang' SHOULD be mapped to their Preferred- > Value. Why use of SHOULD here? I.e. what is a good reason for violating this rule? A pointer here to some case(s) would be appreciated here. > The field-body of the Preferred-Value for extlangs is an > "extended language range" and typically maps to a primary > language subtag. For example, the subtag sequence "zh-hak" > (Chinese, Hakka) would be replaced with the tag "hak" (Hakka). 13). > 4.6. Considerations for Private Use Subtags [...] > However, in some cases content tagged with private use subtags MAY > interact with other systems in a different and possibly unsuitable > manner compared to tags that use opaque, privately defined subtags, > so the choice of the best approach sometimes depends on the > particular domain in question. I think use of MAY is improper here and I suggest changing it to "can" 14). In Section 3.1.2: > o Preferred-Value > > * Preferred-Value's field body contains a canonical mapping from > this record's value to a modern equivalent that is preferred in > its place. Depending on the value of the 'Type' field, this > value can take different forms: [...] > + For fields of type 'extlang', 'grandfathered', or > 'redundant', 'Preferred-Value' contains an "extended > language range" ([RFC4647]) that is preferred for forming > the language tag. That is, each of the subtags that appears > in the value MUST appear in the replacement tag; You lost me here: what is "the value" and what is "the replacement tag" in this case. > additional > fields can be included in a language tag as described > elsewhere in this document. For example, the replacement > for the grandfathered tag "zh-min-nan" (Min Nan Chinese) is > "nan", which can be used as the basis for tags such as "nan- > Hant" or "nan-TW" (note that the extended language subtag > form such as "zh-nan-Hant" or "zh-nan-TW" can also be used). From randy_presuhn@mindspring.com Sat Apr 11 11:21:57 2009 Return-Path: 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 E04403A6B66 for ; Sat, 11 Apr 2009 11:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_50=0.001] 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 KAGfs1Mjya8O for ; Sat, 11 Apr 2009 11:21:57 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 34C753A69D4 for ; Sat, 11 Apr 2009 11:21:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YUh6/WmCbtYwYwGCA5SV6M+WCJ0xXf+C9bvVJT7eSI0KpXJesGfkBmh950Qbhpfh; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lshr8-0005Zu-Eb; Sat, 11 Apr 2009 14:23:06 -0400 Message-ID: <000e01c9bad2$d8e11d20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 11:25:08 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17319eb69f5530bd221d9f5a98e3d0391b0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 18:21:58 -0000 Hi - Since our AD has supplied us with a fairly lengthy set of detailed comments and has kindly numbered them, I'll enter them into the issue tracker. Please put yours responses to keep each issue in a separate thread with an appropriate subject line - it'll make the job of the editors and the document shepherd *much* easier. Randy From alexey.melnikov@isode.com Sat Apr 11 12:08:20 2009 Return-Path: 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 93C6F3A6A2B for ; Sat, 11 Apr 2009 12:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_SBL=1.551] 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 T2B04EyudnNS for ; Sat, 11 Apr 2009 12:08:20 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CA0BB3A6AC9 for ; Sat, 11 Apr 2009 12:08:19 -0700 (PDT) Received: from [92.40.27.75] (92.40.27.75.sub.mbb.three.co.uk [92.40.27.75]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 11 Apr 2009 20:09:28 +0100 Message-ID: <49E0EAB8.80903@isode.com> Date: Sat, 11 Apr 2009 20:08:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randy Presuhn References: <49E04FF4.1040804@isode.com> <000e01c9bad2$d8e11d20$6801a8c0@oemcomputer> In-Reply-To: <000e01c9bad2$d8e11d20$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:08:20 -0000 Randy Presuhn wrote: >Hi - > >Since our AD has supplied us with a fairly lengthy set of detailed >comments and has kindly numbered them, I'll enter them into the >issue tracker. Please put yours responses to keep each issue in >a separate thread with an appropriate subject line - it'll make the >job of the editors and the document shepherd *much* easier. > > It is probably worth reviewing the list of comments first. Some of them might be bogus. From randy_presuhn@mindspring.com Sat Apr 11 12:13:58 2009 Return-Path: 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 13D4C3A6B56 for ; Sat, 11 Apr 2009 12:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 TVaN+5b5Jgp6 for ; Sat, 11 Apr 2009 12:13:57 -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 52A4F3A6AC9 for ; Sat, 11 Apr 2009 12:13:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HeanE7WeKpq/+iezz6wzwpjLZg73WaIdXLQSQ059yYiQWzBLDUfTu/nUOGHAKsHu; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsifS-00026b-Ez; Sat, 11 Apr 2009 15:15:06 -0400 Message-ID: <001d01c9bada$1d74cac0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 12:17:10 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173ce291905e81f8f2dc3537ce24867c1ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #34 (AD comment #1) - who scrutinizes primary subtags refected by ISO 639/RA-JAC? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:13:58 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 1). > > > 2.2.1. Primary Language Subtag > > [...] > > > 5. Any language subtags of 5 to 8 characters in length in the IANA > > [...] > > > At the time this document was created, there were no examples of > > this kind of subtag and future registrations of this type are > > discouraged: primary languages are strongly RECOMMENDED for > > registration with ISO 639, and proposals rejected by ISO 639/ > > RA-JAC will be closely scrutinized before they are registered > > with IANA. > > [Unclear text] Scrutinized by whom? At this point in the document it is > not clear who is going to perform the action. > I think you meant that this would be done by the designated registry > reviewer, so I suggest adding a forward reference here. ... Ok with me. Proposed text: replace "scrutinized" with "scrutinized by the Language Subtag Reviewer (see 3.2)" Randy From randy_presuhn@mindspring.com Sat Apr 11 12:19:06 2009 Return-Path: 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 E87B83A6E56 for ; Sat, 11 Apr 2009 12:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 mXfKk5afRVvc for ; Sat, 11 Apr 2009 12:19:06 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 30E2F3A6956 for ; Sat, 11 Apr 2009 12:19:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=T9AY4vukCVPF25MOAlI1zI4Eo6CGx0miY9B/2EuewXxTlSyAnWJSHjoDYlph0oJ4; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsikR-0006w7-8Y; Sat, 11 Apr 2009 15:20:15 -0400 Message-ID: <002201c9bada$d631e200$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 12:22:20 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173b164f7b9bb6b0807a8974ee00818ef49350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #35 (AD comment #2) what is meant by "permanently reserved"? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:19:07 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 2). > > > 2.2.2. Extended Language Subtags > > [...] > > > 4. Although the ABNF production 'extlang' permits up to three > > extended language tags in the language tag, extended language > > subtags MUST NOT include another extended language subtag in > > their Prefix. That is, the second and third extended language > > subtag positions in a language tag are permanently reserved and > > tags that include subtags in that position are invalid. > > [Unclear text] Clarification on what is meant by "permanently reserved" > here would be appreciated. > ("Permanently reserved" == "MUST NOT be registered, unless a future > version of this document changes that"?) ... As a technical contributor, I agree that a little clarification would be helpful. Your suggested text would be ok with me. Randy From alexey.melnikov@isode.com Sat Apr 11 12:19:13 2009 Return-Path: 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 A311B3A6E6A for ; Sat, 11 Apr 2009 12:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_SBL=1.551] 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 II3uoW9cOlda for ; Sat, 11 Apr 2009 12:19:13 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A05273A6956 for ; Sat, 11 Apr 2009 12:19:12 -0700 (PDT) Received: from [92.40.27.75] (92.40.27.75.sub.mbb.three.co.uk [92.40.27.75]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 11 Apr 2009 20:20:21 +0100 Message-ID: <49E0ED46.4010903@isode.com> Date: Sat, 11 Apr 2009 20:19:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randy Presuhn References: <49E04FF4.1040804@isode.com> <001d01c9bada$1d74cac0$6801a8c0@oemcomputer> In-Reply-To: <001d01c9bada$1d74cac0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #34 (AD comment #1) - who scrutinizes primary subtags refected by ISO 639/RA-JAC? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:19:13 -0000 Randy Presuhn wrote: >Hi - > > >>From: "Alexey Melnikov" >>To: "LTRU Working Group" >>Sent: Saturday, April 11, 2009 1:08 AM >>Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt >> >> >... > > >>1). >> >> >> >>>2.2.1. Primary Language Subtag >>> >>> >> [...] >> >> >>> 5. Any language subtags of 5 to 8 characters in length in the IANA >>> >>> >> [...] >> >> >>> At the time this document was created, there were no examples of >>> this kind of subtag and future registrations of this type are >>> discouraged: primary languages are strongly RECOMMENDED for >>> registration with ISO 639, and proposals rejected by ISO 639/ >>> RA-JAC will be closely scrutinized before they are registered >>> with IANA. >>> >>> >>[Unclear text] Scrutinized by whom? At this point in the document it is >>not clear who is going to perform the action. >>I think you meant that this would be done by the designated registry >>reviewer, so I suggest adding a forward reference here. >> >> >... > >Ok with me. Proposed text: >replace "scrutinized" with "scrutinized by the Language Subtag Reviewer >(see 3.2)" > > Works for me. From randy_presuhn@mindspring.com Sat Apr 11 12:22:42 2009 Return-Path: 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 7B5593A68C4 for ; Sat, 11 Apr 2009 12:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 lLiHkZxSRvyG for ; Sat, 11 Apr 2009 12:22:41 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 9C8FF3A68C3 for ; Sat, 11 Apr 2009 12:22:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KDspZtZKg1lZ6ylMg0Dhu1HtYLLXG6FnWxPXzgtZq8QbjGx0D3G/+wdpQZQz+I09; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lsinu-0006wT-Ut; Sat, 11 Apr 2009 15:23:51 -0400 Message-ID: <002701c9badb$56985dc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 12:25:55 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173bf9f780671f55721fe1d3a0911e08c49350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #36 (AD comment #3) rules for UN M.49 codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:22:42 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... ... > 3). Section 2.2.4 says: > > > F. All other UN numeric codes for countries or areas that do not > > have an associated ISO 3166-1 alpha-2 code MUST NOT be > > entered into the registry and MUST NOT be used to form > > language tags. For more information about these codes, see > > Section 3.4. > > And Section 3.4 says: > > > 16. UN M.49 has codes for both countries and areas (such as '276' > > for Germany) and geographical regions and sub-regions (such as > > '150' for Europe). UN M.49 country or area codes for which > > there is no corresponding ISO 3166-1 code SHOULD NOT be > > Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in > section 2.2.4. > I think you need to change one of 2 sections. > > > registered, except as a surrogate for an ISO 3166-1 code that is > > blocked from registration by an existing subtag. If such a code > > becomes necessary, then the registration authority for ISO > > 3166-1 SHOULD first be petitioned to assign a code to the > > region. If the petition for a code assignment by ISO 3166-1 is > > refused or not acted on in a timely manner, the registration > > process described in Section 3.5 MAY then be used to register > > the corresponding UN M.49 code. This way, UN M.49 codes remain > > available as the value of last resort in cases where ISO 3166-1 > > reassigns a deprecated value in the registry. As co-chair - we should make sure that the resolution of this issue and tracker issue #40 (AD comment #7) are coordinated. Randy From randy_presuhn@mindspring.com Sat Apr 11 12:27:37 2009 Return-Path: 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 8B7753A699A for ; Sat, 11 Apr 2009 12:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 2i8hCVDX9jI9 for ; Sat, 11 Apr 2009 12:27:36 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id D65A23A68C3 for ; Sat, 11 Apr 2009 12:27:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=p/TIz+VRRxJyJmuJoc4LoUJbap5NmdJD4mamUoZ1yZXwub/JXkeJyC1wXzUAwul+; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lsisg-000290-60; Sat, 11 Apr 2009 15:28:46 -0400 Message-ID: <002c01c9badc$06d40720$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 12:30:51 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1739f8660d1aece22ace9ba6689d038a76c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #37 (AD comment #4) delete last sentence of 2.2.9 note X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:27:37 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 4). In Section 2.2.9: > > > Note well: although the 'Language-Tag' production appearing in this > > document is functionally equivalent to the one in [RFC4646], it has > > been changed to prevent certain errors in well-formedness arising > > from the old 'grandfathered' production. This version of the ABNF is > > RECOMMENDED as a replacement for the older version. > > (nit) I suggest deleting the last sentence, as it doesn't provide any > useful information to a reader (as the WG wants > draft-ietf-ltru-4646bis-21bis.txt to replace RFC 4646, it is clear that > the WG believes that the new ABNF is better). Also I don't think it uses > RFC 2119 keyword properly. ... As a technical contributor, I agree with deleting the sentence. The whole paragraph arose as a result of concerns about the perception of the stability of the grammar. Randy From randy_presuhn@mindspring.com Sat Apr 11 12:30:21 2009 Return-Path: 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 E71743A6A74 for ; Sat, 11 Apr 2009 12:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 lBOBUvqIDYGp for ; Sat, 11 Apr 2009 12:30:20 -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 B28B23A6A10 for ; Sat, 11 Apr 2009 12:30:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KcK1O2V2DMxB4MP43YwQHP/KbI1JGlVQZ149kYh/VXDavFJKsGUeC/9yhzhYiftH; h=Received:Message-ID:From:To:Cc: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 [69.3.28.129] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsivK-0004FL-4R; Sat, 11 Apr 2009 15:31:30 -0400 Message-ID: <003101c9badc$68947120$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <49E04FF4.1040804@isode.com> <000e01c9bad2$d8e11d20$6801a8c0@oemcomputer> <49E0EAB8.80903@isode.com> Date: Sat, 11 Apr 2009 12:33:35 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1735b21afd7c14b053863899b282a1a4c67350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Cc: LTRU Working Group Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:30:22 -0000 Hi - > From: "Alexey Melnikov" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Saturday, April 11, 2009 12:08 PM > Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt > > Randy Presuhn wrote: > > >Hi - > > > >Since our AD has supplied us with a fairly lengthy set of detailed > >comments and has kindly numbered them, I'll enter them into the > >issue tracker. Please put yours responses to keep each issue in > >a separate thread with an appropriate subject line - it'll make the > >job of the editors and the document shepherd *much* easier. > > > > > It is probably worth reviewing the list of comments first. Some of them > might be bogus. They're already in the tracker. I actually prefer to have a complete list, even if it turns out that some require little discussion. The list of open issues is available at http://trac.tools.ietf.org/wg/ltru/trac/report/1 Randy From randy_presuhn@mindspring.com Sat Apr 11 12:39:00 2009 Return-Path: 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 BF3243A6E7C for ; Sat, 11 Apr 2009 12:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 L7BRdP3U7Rnw for ; Sat, 11 Apr 2009 12:39:00 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id ED4B23A6E7A for ; Sat, 11 Apr 2009 12:38:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=G4G4dviJeqSOx23wdyuI+fTw+UbdfWcuFYbKNX/4AYoeyLEsrPAl7iKZWSQvv92c; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lsj3h-0003KL-CR; Sat, 11 Apr 2009 15:40:09 -0400 Message-ID: <003801c9badd$9de466e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 12:42:14 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1736e70ef89e65b1e6e8917557b2d562f87350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #38 (AD comment #5) ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:39:00 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 5). In Section 2.2.9: > > > The format of the registry is described by the following ABNF (per > > [RFC5234]): > > > > registry = record *("%%" CRLF record) > > record = 1*field > > field = ( field-name field-sep field-body CRLF ) > > field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] > > field-sep = *SP ":" *SP > > field-body = *([[*SP CRLF] 1*SP] 1*CHARS) > > CHARS = (%x21-10FFFF) ; Unicode code points > > [ABNF error] While I understand what you mean here, I think the > definition of CHARS doesn't match the requirement to use UTF-8 encoding > stated earlier in section 3.1.1: > > The registry is a [Unicode] text file, using the UTF-8 [RFC3629] > character encoding, and consists of a series of records stored in a > format based on "record-jar" (described in [record-jar]). > > IMHO, you can use ABNF productions from [RFC3629] to fix that. ... As a technical contributor... Ewwww. Our intention in the ABNF was *NOT* to describe the registry as a byte-stream, but rather to describe it as a character stream. I view the encoding of the registry as UTF-8 (rather than UTF-16 or UTF-32 or EBCDIC :-) as a separate matter from the ABNF, and think that trying to accomplish both in the ABNF would only serve to confuse rather than enlighten. Randy From randy_presuhn@mindspring.com Sat Apr 11 12:41:15 2009 Return-Path: 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 61B5A3A6A4E for ; Sat, 11 Apr 2009 12:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 JXxvz1sm6HGX for ; Sat, 11 Apr 2009 12:41:14 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id A30403A6A43 for ; Sat, 11 Apr 2009 12:41:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UAV7S/A+zZ0EyFUmB4cUasMcUAtbT0RRFRAznyqGqOj8eHvVzrGjvANgJh8Ar3gN; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lsj5r-0000xk-Uk; Sat, 11 Apr 2009 15:42:24 -0400 Message-ID: <003d01c9badd$ee542340$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 12:44:29 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173f94114033432b35410ef042412a15736350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #39 (AD comment #6) field name occurance limit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:41:15 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 6). In Section 3.1.2: > > > Field-names MUST occur no more > > than once per record, with the exception of the 'Description', > > 'Comments', and sometimes the 'Prefix' field. > > (nit) Suggestion to reword using MUST NOT. E.g.: > > Field-names MUST NOT occur more > than once per record, with the exception of the 'Description', > 'Comments', and sometimes the 'Prefix' field. ... As a technical contributor, I agree with the proposed change. Randy From randy_presuhn@mindspring.com Sat Apr 11 12:47:42 2009 Return-Path: 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 E38983A6A43 for ; Sat, 11 Apr 2009 12:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 f3FjK2T3ZIvb for ; Sat, 11 Apr 2009 12:47:42 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 0033B3A68C3 for ; Sat, 11 Apr 2009 12:47:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HSjKl/Vyc+AS5F5N7E/79yjjOq5+O6ajeOG40T05I1j5ivwKMdNtXjqnsSjVI0F/; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsjC7-0008Vx-Cw; Sat, 11 Apr 2009 15:48:51 -0400 Message-ID: <004201c9bade$d52a6040$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 12:50:56 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17311e6be679a0b7524c983b2a447b70457350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #40 (AD comment #7) section 3.4 on ISO 3166 vs UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:47:43 -0000 Hi - As co-chair - we should coordinate any changes we make here with the resolution to issue #36 (AD comment #3). > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 7). In Section 3.4: > > > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that > > conflict with existing subtags of the associated type, including > > subtags that are deprecated, MUST NOT be entered into the > > registry. The following additional considerations apply to > > subtag values that are reassigned: > > [...] > > > F. For ISO 3166-1 codes, if there is no associated UN numeric > > code, then the Language Subtag Reviewer SHALL petition the > > UN to create one. If there is no response from the UN > > within ninety days of the request being sent, the Language > > Subtag Reviewer SHALL prepare a proposal for entering in the > > IANA registry as soon as practical a registered variant > > subtag as an alternate value for the new code. The form of > > the registered variant subtag will be at the discretion of > > the Language Subtag Reviewer and MUST conform to other > > restrictions on variant subtags in this document. This > > situation is very unlikely to ever occur. > > > > 16. UN M.49 has codes for both countries and areas (such as '276' > > for Germany) and geographical regions and sub-regions (such as > > '150' for Europe). UN M.49 country or area codes for which > > there is no corresponding ISO 3166-1 code SHOULD NOT be > > registered, except as a surrogate for an ISO 3166-1 code that is > > blocked from registration by an existing subtag. If such a code > > becomes necessary, then the registration authority for ISO > > 3166-1 SHOULD > > Why SHOULD is used here instead of SHALL? > Similar text in 15.F says SHALL, which is stronger. > Also, 15.F specifies expected response time (90 days), which is missing > below. Any reason why you don't want to specify deadline in this case? > > > first be petitioned to assign a code to the > > region. If the petition for a code assignment by ISO 3166-1 is > > refused or not acted on in a timely manner, the registration > > process described in Section 3.5 MAY then be used to register > > the corresponding UN M.49 code. This way, UN M.49 codes remain > > available as the value of last resort in cases where ISO 3166-1 > > reassigns a deprecated value in the registry. As a technical contributor, I agree that the two should be aligned. Using "SHALL" here definitely makes sense. I'd leave it to the folks who have had dealings with the relevant agencies to comment on whether specifying a 90-day timeout is necessary - there may be concerns about a need for flexibility. Randy From alexey.melnikov@isode.com Sat Apr 11 12:51:27 2009 Return-Path: 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 515243A6917 for ; Sat, 11 Apr 2009 12:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_SBL=1.551, SARE_SUB_ENC_UTF8=0.152] 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 kdJVeBlfqTa4 for ; Sat, 11 Apr 2009 12:51:26 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 435BD3A68C3 for ; Sat, 11 Apr 2009 12:51:26 -0700 (PDT) Received: from [92.40.27.75] (92.40.27.75.sub.mbb.three.co.uk [92.40.27.75]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 11 Apr 2009 20:52:33 +0100 Message-ID: <49E0F4D9.6000402@isode.com> Date: Sat, 11 Apr 2009 20:51:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randy Presuhn References: <49E04FF4.1040804@isode.com> <003801c9badd$9de466e0$6801a8c0@oemcomputer> In-Reply-To: <003801c9badd$9de466e0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #38 (AD comment #5) ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:51:27 -0000 Randy Presuhn wrote: >Hi - > > >>From: "Alexey Melnikov" >>To: "LTRU Working Group" >>Sent: Saturday, April 11, 2009 1:08 AM >>Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt >> >> >... > > >>5). In Section 2.2.9: >> >> >>> The format of the registry is described by the following ABNF (per >>> [RFC5234]): >>> >>> registry = record *("%%" CRLF record) >>> record = 1*field >>> field = ( field-name field-sep field-body CRLF ) >>> field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] >>> field-sep = *SP ":" *SP >>> field-body = *([[*SP CRLF] 1*SP] 1*CHARS) >>> CHARS = (%x21-10FFFF) ; Unicode code points >>> >>> >>[ABNF error] While I understand what you mean here, I think the >>definition of CHARS doesn't match the requirement to use UTF-8 encoding >>stated earlier in section 3.1.1: >> >> The registry is a [Unicode] text file, using the UTF-8 [RFC3629] >> character encoding, and consists of a series of records stored in a >> format based on "record-jar" (described in [record-jar]). >> >>IMHO, you can use ABNF productions from [RFC3629] to fix that. >> >> >... > >As a technical contributor... > >Ewwww. > >Our intention in the ABNF was *NOT* to describe the registry as a byte-stream, >but rather to describe it as a character stream. I view the encoding of the >registry as UTF-8 (rather than UTF-16 or UTF-32 or EBCDIC :-) as a separate >matter from the ABNF, and think that trying to accomplish both in the >ABNF would only serve to confuse rather than enlighten. > > In this case a comment saying that would be appreciated. If you want to do both though, you can define CHARS using UTF-8 sequences and add a comment that that corresponds to '%x21-10FFFF' Unicode range. From doug@ewellic.org Sat Apr 11 12:51:28 2009 Return-Path: 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 1BA163A68C3 for ; Sat, 11 Apr 2009 12:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_40=-0.185, SARE_SUB_ENC_UTF8=0.152, STOX_REPLY_TYPE=0.001] 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 oGRMYXNT5tur for ; Sat, 11 Apr 2009 12:51:27 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id EE9C43A68FE for ; Sat, 11 Apr 2009 12:51:26 -0700 (PDT) Received: (qmail 22194 invoked from network); 11 Apr 2009 19:52:36 -0000 Received: from unknown (67.166.27.148) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 11 Apr 2009 19:52:36 -0000 Message-ID: <97BE315F0F8B4C9BB1EDAD873F735242@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 11 Apr 2009 13:52:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Issue #38 (AD comment #5) ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:51:28 -0000 Randy Presuhn wrote: > Our intention in the ABNF was *NOT* to describe the registry as a > byte-stream, but rather to describe it as a character stream. I view > the encoding of the registry as UTF-8 (rather than UTF-16 or UTF-32 or > EBCDIC :-) as a separate matter from the ABNF, and think that trying > to accomplish both in the ABNF would only serve to confuse rather than > enlighten. I agree completely. The main aspect of this revision as it pertains to representation of the Registry is that characters beyond U+007F will no longer be represented by hex references like Á but as themselves. The UTF-8 encoding of these characters is a separate matter from the grammar. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From randy_presuhn@mindspring.com Sat Apr 11 12:53:58 2009 Return-Path: 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 1AAB23A6973 for ; Sat, 11 Apr 2009 12:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=1.212, BAYES_00=-2.599, GB_I_LETTER=-2] 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 FRaO54jcQ55V for ; Sat, 11 Apr 2009 12:53:57 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 59CDC3A68FE for ; Sat, 11 Apr 2009 12:53:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lD0Z/aOmFIx9hssvlGH3zTaT5uzcMQHcx8HMbWdCb+wxFt+Y2S9p6ymtEI3qT2m9; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsjIA-0004Jb-Lt; Sat, 11 Apr 2009 15:55:06 -0400 Message-ID: <004701c9badf$b4e5c440$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 12:57:12 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17393a35e8811b1b7b245b7c2f185bba980350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:53:58 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 8). In Section 3.5: > > > The fields in the "Record Requested" section SHOULD follow the > > requirements in Section 3.1. > > What are the reasons not to follow requirements in Section 3.1? > (I.e. why is SHOULD used instead of MUST?) ... As a technical contributor... I think the idea was to allow the language subtag reviewer to consider requests that followed the spirit, if not the letter of the syntax. Since the LSR is not an automated process, and we do not want to introduce artificial barriers to those needing language subtags, a little flexibility is desirable. Consequently, I think the SHOULD is ok - it's operational advice, and failure to follow it to the letter won't necessarily cause any problems at all. Randy From cowan@ccil.org Sat Apr 11 12:54:04 2009 Return-Path: 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 AC3AE3A68FE for ; Sat, 11 Apr 2009 12:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 Zj3p3qCpdz3x for ; Sat, 11 Apr 2009 12:54:03 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 2468B3A6A10 for ; Sat, 11 Apr 2009 12:54:03 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LsjIG-0007C4-02; Sat, 11 Apr 2009 15:55:12 -0400 Date: Sat, 11 Apr 2009 15:55:11 -0400 To: Alexey Melnikov Message-ID: <20090411195511.GA24528@mercury.ccil.org> References: <49E04FF4.1040804@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E04FF4.1040804@isode.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:54:04 -0000 General disclaimer: I speak for myself, not for the WG. When I say "we", I'm reporting what I believe to be the facts. Alexey Melnikov scripsit: > I think the document is well written, but IANA registration rules are > overwhelmingly complex. But I don't know if anything can be done about > complexity of the registration procedure. IANA lists Michael Everson and > Doug Ewell as the registry reviewers. Are they happy to continue being > reviewers for the 4646bis? Technically, only Michael is the Registry Reviewer. Doug's role is that of Imperial Chancellor. :-) > > 4. Although the ABNF production 'extlang' permits up to three > > extended language tags in the language tag, extended language > > subtags MUST NOT include another extended language subtag in > > their Prefix. That is, the second and third extended language > > subtag positions in a language tag are permanently reserved and > > tags that include subtags in that position are invalid. > > [Unclear text] Clarification on what is meant by "permanently reserved" > here would be appreciated. > ("Permanently reserved" == "MUST NOT be registered, unless a future > version of this document changes that"?) No, it means "We guarantee that such subtags will never be registered even if this document is revised." A constraint on 4646bis is that every tag that was well-formed in 4646 is still well-formed, so we did not remove the grammar that allows tags like abc-def-ghi; however, we give explicit permission for validators to reject them out of hand. > 3). Section 2.2.4 says: > > > F. All other UN numeric codes for countries or areas that do not > > have an associated ISO 3166-1 alpha-2 code MUST NOT be > > entered into the registry and MUST NOT be used to form > > language tags. For more information about these codes, see > > Section 3.4. > > And Section 3.4 says: > > > 16. UN M.49 has codes for both countries and areas (such as '276' > > for Germany) and geographical regions and sub-regions (such as > > '150' for Europe). UN M.49 country or area codes for which > > there is no corresponding ISO 3166-1 code SHOULD NOT be > > Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in > section 2.2.4. I agree: 3.4 rule 16 should be MUST NOT. > 4). In Section 2.2.9: > > > Note well: although the 'Language-Tag' production appearing in this > > document is functionally equivalent to the one in [RFC4646], it has > > been changed to prevent certain errors in well-formedness arising > > from the old 'grandfathered' production. This version of the ABNF is > > RECOMMENDED as a replacement for the older version. > > (nit) I suggest deleting the last sentence, as it doesn't provide any > useful information to a reader (as the WG wants > draft-ietf-ltru-4646bis-21bis.txt to replace RFC 4646, it is clear that > the WG believes that the new ABNF is better). Also I don't think it uses > RFC 2119 keyword properly. +1 > 5). In Section 2.2.9: > > > The format of the registry is described by the following ABNF (per > > [RFC5234]): > > > > registry = record *("%%" CRLF record) > > record = 1*field > > field = ( field-name field-sep field-body CRLF ) > > field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] > > field-sep = *SP ":" *SP > > field-body = *([[*SP CRLF] 1*SP] 1*CHARS) > > CHARS = (%x21-10FFFF) ; Unicode code points > > [ABNF error] While I understand what you mean here, I think the > definition of CHARS doesn't match the requirement to use UTF-8 encoding > stated earlier in section 3.1.1: Note that we don't use ABNF in quite the standard way: we use it to describe sequences of characters rather than sequences of bytes, as is usual. This is explained in the last paragraph of 2.1. > 6). In Section 3.1.2: > > >Field-names MUST occur no more > > than once per record, with the exception of the 'Description', > > 'Comments', and sometimes the 'Prefix' field. > > (nit) Suggestion to reword using MUST NOT. E.g.: > > Field-names MUST NOT occur more > than once per record, with the exception of the 'Description', > 'Comments', and sometimes the 'Prefix' field. +1 > > 16. UN M.49 has codes for both countries and areas (such as '276' > > for Germany) and geographical regions and sub-regions (such as > > '150' for Europe). UN M.49 country or area codes for which > > there is no corresponding ISO 3166-1 code SHOULD NOT be > > registered, except as a surrogate for an ISO 3166-1 code that is > > blocked from registration by an existing subtag. If such a code > > becomes necessary, then the registration authority for ISO > > 3166-1 SHOULD > > Why SHOULD is used here instead of SHALL? > Similar text in 15.F says SHALL, which is stronger. > Also, 15.F specifies expected response time (90 days), which is missing > below. Any reason why you don't want to specify deadline in this case? +1 > 8). In Section 3.5: > > > The fields in the "Record Requested" section SHOULD follow the > > requirements in Section 3.1. > > What are the reasons not to follow requirements in Section 3.1? > (I.e. why is SHOULD used instead of MUST?) +1 > 9). > > >3.8. Update of the Language Subtag Registry > > > > Upon adoption of this document the IANA Language Subtag Registry will > > need an update so that it contains the complete set of subtags valid > > in a language tag. This collection of subtags, along with a > > description of the process used to create it, is described by > > [draft-4645bis]. IANA will publish the updated version of the > > registry described by this document using the instructions and > > content of [draft-4645bis]. > > (nit) I think both 4645bis and 4646bis should be published at the same time. > If this happens, then use of future tense in the published RFC would be > confusing and will not match the reality. In principle, IANA's change does not happen until after both 4646 and 4646bis have been adopted (which is not the same as publication; publication usually long postdates it), which is why the future is appropriate. > I think if File-Date record present in the registry has a later date > than the record being inserted or modified, then IANA should use the > date of update (which I assume would be after the record > modification/addition date). This way any change to the IANA registry > can be detected. This is a "shouldn't happen" situation, where at the time a modification is made, the File-Date is later than the current date. But if it does happen, we never want to set the File-Date of the new version to be earlier than the File-Date of the version being superseded. That would cause any entity trying to decide which of two versions to use to get the wrong answer. A great deal of the complexity of BCP 47, in any version, reflects experience with the mistakes made over the years by IANA, the various RAs and MAs, and ietf-languages. > > o For information objects whose purpose is to provide alternatives, > > the associated language tags could be regarded as a hint that the > > content is provided in several languages and that one has to > > inspect each of the alternatives in order to find its language or > > languages. In this case, the presence of multiple tags might not > > mean that one needs to be multi-lingual to get complete > > understanding of the document. Example: MIME multipart/ > > alternative. > > I think this needs an informative reference to MIME. +1 > 12). > > >4.5. Canonicalization of Language Tags > > [...] > > > 3. Subtags of type 'extlang' SHOULD be mapped to their Preferred- > > Value. > > Why use of SHOULD here? I.e. what is a good reason for violating this rule? > A pointer here to some case(s) would be appreciated here. This is a political compromise between those who like extlangs and those who don't, both of whom were very vehement in the WG. We allow both and we don't insist that one MUST be used. It's better not to upset the applecart here. > > However, in some cases content tagged with private use subtags MAY > > interact with other systems in a different and possibly unsuitable > > manner compared to tags that use opaque, privately defined subtags, > > so the choice of the best approach sometimes depends on the > > particular domain in question. > > I think use of MAY is improper here and I suggest changing it to "can" +1 > 14). In Section 3.1.2: > > > o Preferred-Value > > > > * Preferred-Value's field body contains a canonical mapping from > > this record's value to a modern equivalent that is preferred in > > its place. Depending on the value of the 'Type' field, this > > value can take different forms: > > [...] > > > + For fields of type 'extlang', 'grandfathered', or > > 'redundant', 'Preferred-Value' contains an "extended > > language range" ([RFC4647]) that is preferred for forming > > the language tag. That is, each of the subtags that appears > > in the value MUST appear in the replacement tag; > > You lost me here: what is "the value" and what is "the replacement tag" > in this case. The input and the output, respectively, to the preferred-value-normalization process. -- BALIN FUNDINUL UZBAD KHAZADDUMU cowan@ccil.org BALIN SON OF FUNDIN LORD OF KHAZAD-DUM http://www.ccil.org/~cowan From doug@ewellic.org Sat Apr 11 12:57:03 2009 Return-Path: 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 4AA423A68FE for ; Sat, 11 Apr 2009 12:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] 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 MDdkwBL8MBam for ; Sat, 11 Apr 2009 12:57:02 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 5013F3A68C3 for ; Sat, 11 Apr 2009 12:57:02 -0700 (PDT) Received: (qmail 2755 invoked from network); 11 Apr 2009 19:58:12 -0000 Received: from unknown (67.166.27.148) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 11 Apr 2009 19:58:11 -0000 Message-ID: From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 11 Apr 2009 13:58:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Michael Everson Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:57:03 -0000 Alexey Melnikov wrote: > IANA lists Michael Everson and Doug Ewell as the registry reviewers. > Are they happy to continue being reviewers for the 4646bis? I know I am, and I'm pretty sure Michael is. But draft-4646bis-21, Section 3.2, second paragraph requires the IESG to solicit nominees and feedback and make the appointment(s) all over again, for some reason not clear to me, and so the question of who the Reviewer(s) will be is best deferred until that time. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From randy_presuhn@mindspring.com Sat Apr 11 13:02:10 2009 Return-Path: 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 8EDA83A6895 for ; Sat, 11 Apr 2009 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 TH6bQ-kf+mwf for ; Sat, 11 Apr 2009 13:02:09 -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 193E63A6E7A for ; Sat, 11 Apr 2009 13:01:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=IXM2r1jhvEcY+6IUEqAxh9FEyJRM5iwcQyn9oEKjoxwv+LxyiURmdDTQEnPvtMmf; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsjPm-0006n1-80; Sat, 11 Apr 2009 16:02:58 -0400 Message-ID: <005a01c9bae0$ce05d860$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 13:05:03 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173d9938710707b9d3104d0a691da059411350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #42 (AD comment #9) confusing future tense X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:02:10 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 9). > > > 3.8. Update of the Language Subtag Registry > > > > Upon adoption of this document the IANA Language Subtag Registry will > > need an update so that it contains the complete set of subtags valid > > in a language tag. This collection of subtags, along with a > > description of the process used to create it, is described by > > [draft-4645bis]. IANA will publish the updated version of the > > registry described by this document using the instructions and > > content of [draft-4645bis]. > > (nit) I think both 4645bis and 4646bis should be published at the same time. > If this happens, then use of future tense in the published RFC would be > confusing and will not match the reality. > > I suggest adding an RFC Editor note asking to fix this sentence. > > > Once published by IANA, the maintenance > > procedures, rules, and registration processes described in this > > document will be available for new registrations or updates. ... As a technical contributor... the proposed fix works for me. Randy From doug@ewellic.org Sat Apr 11 13:13:16 2009 Return-Path: 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 3F1033A67E1 for ; Sat, 11 Apr 2009 13:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 1X9TAZCowylG for ; Sat, 11 Apr 2009 13:13:15 -0700 (PDT) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id 20BC83A67D0 for ; Sat, 11 Apr 2009 13:13:15 -0700 (PDT) Received: (qmail 23229 invoked from network); 11 Apr 2009 20:14:24 -0000 Received: from unknown (67.166.27.148) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 11 Apr 2009 20:14:23 -0000 Message-ID: <73F13E6B4E024C26B10A25353F6F688C@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 11 Apr 2009 14:14:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:13:16 -0000 John Cowan wrote: > Technically, only Michael is the Registry Reviewer. Doug's role is > that of Imperial Chancellor. :-) Cool! I'll have business cards printed at once. >> Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in >> section 2.2.4. > > I agree: 3.4 rule 16 should be MUST NOT. Please make whatever changes are deemed necessary to straighten out the RFC 2119 issues. In particular, I've always felt that the WG insisted on capitalized MAYs where the words refer to that which might be, not to optional protocol features. >> I think if File-Date record present in the registry has a later date >> than the record being inserted or modified, then IANA should use the >> date of update (which I assume would be after the record >> modification/addition date). This way any change to the IANA registry >> can be detected. > > This is a "shouldn't happen" situation, where at the time a > modification is made, the File-Date is later than the current date. It just did happen, and happens regularly. We (Michael) submitted the latest batch of changes to IANA on April 3, with dates of 2009-04-03 as appropriate. In particular, the script subtag 'Zinh' was submitted with an Added date of 2009-04-03. But IANA did not add these to the Registry until April 7, and so they applied File-Date: 2009-04-07 to the entire Registry while keeping the Added: 2009-04-03 date for 'Zinh'. > But if it does happen, we never want to set the File-Date of the new > version to be earlier than the File-Date of the version being > superseded. That would cause any entity trying to decide which of two > versions to use to get the wrong answer. Correct, and that is why I for one have never worried much about the mismatch described above. > A great deal of the complexity of BCP 47, in any version, reflects > experience with the mistakes made over the years by IANA, the various > RAs and MAs, and ietf-languages. +1 emphatically. All of us would have loved to be able to make this simpler and less rigid, as it was in RFC 1766 and 3066. > This is a political compromise between those who like extlangs and > those who don't, both of whom were very vehement in the WG. We allow > both and we don't insist that one MUST be used. It's better not to > upset the applecart here. +1 -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From randy_presuhn@mindspring.com Sat Apr 11 13:15:19 2009 Return-Path: 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 DF0FC3A695B for ; Sat, 11 Apr 2009 13:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 vZGfTHa3Pop6 for ; Sat, 11 Apr 2009 13:15:19 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id D31303A68FE for ; Sat, 11 Apr 2009 13:15:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NDlPUloz5+aG/3KALxsI/43fT2Y9MGADVz2Rh6Zm8c23eoEPir2efOWy4LYj6idZ; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lsjco-0003ht-9i; Sat, 11 Apr 2009 16:16:26 -0400 Message-ID: <006701c9bae2$af887260$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 13:18:31 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173f717d6fac9c1b2189e7527bcdd611de7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #43 (AD comment #10) section 5.1 vs 3.2 on file-date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:15:20 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 10). > > > 5.1. Language Subtag Registry > > [...] > > > Whenever an entry is created or modified in the registry, the 'File- > > Date' record at the start of the registry is updated to reflect the > > most recent modification date in the [RFC3339] "full-date" format: > > included in any request to insert or modify records will be a new > > File-Date record indicating the acceptance date of the record. This > > record is to be placed first in the registry, replacing the existing > > File-Date record. In the event that the File-Date record present in > > the registry has a later date than the record being inserted or > > modified, then the latest (most recent) record will be preserved. > > I am confused by which date is going to be used by IANA in this case. > Section 3.1.2 says: > > The first record in the registry is always the "File-Date" record. > This record occurs only once in the file and contains a single field > whose field-name is "File-Date". The field-body of this record > contains the last modification date of this copy of the registry, > making it possible to compare different versions of the registry. > > I think if File-Date record present in the registry has a later date > than the record being inserted or modified, then IANA should use the > date of update (which I assume would be after the record > modification/addition date). This way any change to the IANA registry > can be detected. As a technical contributor... I think the intent here is to handle a sequence of update requests that arrive out of order. (I frequently see delays of several hours from IETF mailing lists, and things normally arrive thoroughly jumbled). It would probably have been simpler to just say that it should always simply be the date that the file was updated, and not talk about the dates on the record(s) being added or updated. Randy From alexey.melnikov@isode.com Sat Apr 11 13:16:09 2009 Return-Path: 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 A70DF3A68E8 for ; Sat, 11 Apr 2009 13:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=1.134, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_SBL=1.551] 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 jByScjSkHNzD for ; Sat, 11 Apr 2009 13:16:04 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A56593A69D4 for ; Sat, 11 Apr 2009 13:15:44 -0700 (PDT) Received: from [92.40.27.75] (92.40.27.75.sub.mbb.three.co.uk [92.40.27.75]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 11 Apr 2009 21:16:51 +0100 Message-ID: <49E0FA8C.2060105@isode.com> Date: Sat, 11 Apr 2009 21:16:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randy Presuhn References: <49E04FF4.1040804@isode.com> <004701c9badf$b4e5c440$6801a8c0@oemcomputer> In-Reply-To: <004701c9badf$b4e5c440$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:16:09 -0000 Randy Presuhn wrote: >Hi - > > >>From: "Alexey Melnikov" >>To: "LTRU Working Group" >>Sent: Saturday, April 11, 2009 1:08 AM >>Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt >> >> >... > > >>8). In Section 3.5: >> >> >>> The fields in the "Record Requested" section SHOULD follow the >>> requirements in Section 3.1. >>> >>> >>What are the reasons not to follow requirements in Section 3.1? >>(I.e. why is SHOULD used instead of MUST?) >> >> >... > >As a technical contributor... > >I think the idea was to allow the language subtag reviewer to consider >requests that followed the spirit, if not the letter of the syntax. Since >the LSR is not an automated process, and we do not want to introduce >artificial barriers to those needing language subtags, a little flexibility >is desirable. Consequently, I think the SHOULD is ok - it's operational >advice, and failure to follow it to the letter won't necessarily cause any >problems at all. > > I understand and agree with the desire to be flexible. However my understanding is that the request sent to IANA must be in the correct form. Maybe you should clarify that. From alexey.melnikov@isode.com Sat Apr 11 13:16:57 2009 Return-Path: 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 8EC013A695B for ; Sat, 11 Apr 2009 13:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_SBL=1.551] 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 s1IxCiiTKxtF for ; Sat, 11 Apr 2009 13:16:56 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7E4CD3A6977 for ; Sat, 11 Apr 2009 13:16:56 -0700 (PDT) Received: from [92.40.27.75] (92.40.27.75.sub.mbb.three.co.uk [92.40.27.75]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 11 Apr 2009 21:18:03 +0100 Message-ID: <49E0FAD4.1050803@isode.com> Date: Sat, 11 Apr 2009 21:17:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randy Presuhn References: <49E04FF4.1040804@isode.com> <006701c9bae2$af887260$6801a8c0@oemcomputer> In-Reply-To: <006701c9bae2$af887260$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #43 (AD comment #10) section 5.1 vs 3.2 on file-date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:16:57 -0000 Randy Presuhn wrote: >Hi - > > >>From: "Alexey Melnikov" >>To: "LTRU Working Group" >>Sent: Saturday, April 11, 2009 1:08 AM >>Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt >> >> >... > > >>10). >> >> >>>5.1. Language Subtag Registry >>> >>> >> [...] >> >> >>> Whenever an entry is created or modified in the registry, the 'File- >>> Date' record at the start of the registry is updated to reflect the >>> most recent modification date in the [RFC3339] "full-date" format: >>> included in any request to insert or modify records will be a new >>> File-Date record indicating the acceptance date of the record. This >>> record is to be placed first in the registry, replacing the existing >>> File-Date record. In the event that the File-Date record present in >>> the registry has a later date than the record being inserted or >>> modified, then the latest (most recent) record will be preserved. >>> >>> >>I am confused by which date is going to be used by IANA in this case. >>Section 3.1.2 says: >> >> The first record in the registry is always the "File-Date" record. >> This record occurs only once in the file and contains a single field >> whose field-name is "File-Date". The field-body of this record >> contains the last modification date of this copy of the registry, >> making it possible to compare different versions of the registry. >> >>I think if File-Date record present in the registry has a later date >>than the record being inserted or modified, then IANA should use the >>date of update (which I assume would be after the record >>modification/addition date). This way any change to the IANA registry >>can be detected. >> >> >As a technical contributor... >I think the intent here is to handle a sequence of update requests >that arrive out of order. (I frequently see delays of several hours >from IETF mailing lists, and things normally arrive thoroughly jumbled). >It would probably have been simpler to just say that it should always >simply be the date that the file was updated, and not talk about >the dates on the record(s) being added or updated. > > Agreed. From randy_presuhn@mindspring.com Sat Apr 11 13:17:11 2009 Return-Path: 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 064A03A68FE for ; Sat, 11 Apr 2009 13:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 caifu3IiLDnY for ; Sat, 11 Apr 2009 13:17:10 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 3FEC13A695B for ; Sat, 11 Apr 2009 13:17:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ipAaxWYUttv4sKZWazcIAFc//Z5IXDklNNiHsnIcBItTILWU9P+YnM1xrgO7QH+W; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lsjed-0001A3-JU; Sat, 11 Apr 2009 16:18:19 -0400 Message-ID: <006c01c9bae2$f32c1ee0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 13:20:25 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17310238aa4894ceb22eed444ff8d4d7862350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #44 (AD comment #11) informative reference to MIME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:17:11 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 11). > > > 4.2. Meaning of the Language Tag > > [...] > > > o For information objects whose purpose is to provide alternatives, > > the associated language tags could be regarded as a hint that the > > content is provided in several languages and that one has to > > inspect each of the alternatives in order to find its language or > > languages. In this case, the presence of multiple tags might not > > mean that one needs to be multi-lingual to get complete > > understanding of the document. Example: MIME multipart/ > > alternative. > > I think this needs an informative reference to MIME. ... As a technical contributor... I'd prefer to simply delete the example. Randy From alexey.melnikov@isode.com Sat Apr 11 13:23:10 2009 Return-Path: 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 244AF3A6B5B for ; Sat, 11 Apr 2009 13:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_SBL=1.551] 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 EHunhT1il+cN for ; Sat, 11 Apr 2009 13:23:09 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 363B23A6977 for ; Sat, 11 Apr 2009 13:23:09 -0700 (PDT) Received: from [92.40.27.75] (92.40.27.75.sub.mbb.three.co.uk [92.40.27.75]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 11 Apr 2009 21:24:17 +0100 Message-ID: <49E0FC49.7000208@isode.com> Date: Sat, 11 Apr 2009 21:23:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randy Presuhn References: <49E04FF4.1040804@isode.com> <006c01c9bae2$f32c1ee0$6801a8c0@oemcomputer> In-Reply-To: <006c01c9bae2$f32c1ee0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference to MIME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:23:10 -0000 Randy Presuhn wrote: >Hi - > > >>From: "Alexey Melnikov" >>To: "LTRU Working Group" >>Sent: Saturday, April 11, 2009 1:08 AM >>Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt >> >> >... > > >>11). >> >> >>>4.2. Meaning of the Language Tag >>> >>> >> [...] >> >> >>> o For information objects whose purpose is to provide alternatives, >>> the associated language tags could be regarded as a hint that the >>> content is provided in several languages and that one has to >>> inspect each of the alternatives in order to find its language or >>> languages. In this case, the presence of multiple tags might not >>> mean that one needs to be multi-lingual to get complete >>> understanding of the document. Example: MIME multipart/ >>> alternative. >>> >>> >>I think this needs an informative reference to MIME. >> >> >... > >As a technical contributor... >I'd prefer to simply delete the example. > > I actually like the example. But this is up to the WG. From randy_presuhn@mindspring.com Sat Apr 11 13:30:28 2009 Return-Path: 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 B71BC3A68B5 for ; Sat, 11 Apr 2009 13:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 SmvLWEbD7lSZ for ; Sat, 11 Apr 2009 13:30:25 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 063A63A683D for ; Sat, 11 Apr 2009 13:30:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Un+W1f37CIclDyNipRgnNTm1WDLucWn3HVmqplcFG4nQ1J/WMjGyLmxIvr/mbrT5; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsjrS-0001a8-Cx; Sat, 11 Apr 2009 16:31:34 -0400 Message-ID: <007701c9bae4$cce46600$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 13:33: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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1738eff101992a1cbe25d9b85de335c04ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #45 (AD comment #12) SHOULD in section 4.5 on preferred value mappings X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:30:28 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 12). > > > 4.5. Canonicalization of Language Tags > > [...] > > > 3. Subtags of type 'extlang' SHOULD be mapped to their Preferred- > > Value. > > Why use of SHOULD here? I.e. what is a good reason for violating this rule? > A pointer here to some case(s) would be appreciated here. > > > The field-body of the Preferred-Value for extlangs is an > > "extended language range" and typically maps to a primary > > language subtag. For example, the subtag sequence "zh-hak" > > (Chinese, Hakka) would be replaced with the tag "hak" (Hakka). ... As co-chair... This point is at the intersection of a couple very contentious issues. One is the question of whether the canonical form is stable over time, and the other is the macrolanguage problem. This language reflects a compromise that I think leaves all parties to the debates equally unhappy. The reason for the "SHOULD" is that there are situations where NOT doing the mapping would be operationally preferable. As a technical contribtor... Chinese and Arabic written materials are the "poster children" here, especially when working with remove-from-right matching algorithms. Randy From randy_presuhn@mindspring.com Sat Apr 11 13:33:40 2009 Return-Path: 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 25D123A6AB3 for ; Sat, 11 Apr 2009 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 EQyTGLVvbaxt for ; Sat, 11 Apr 2009 13:33:39 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 681543A69D4 for ; Sat, 11 Apr 2009 13:33:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eCQccfv6N+KW26BiFlOtSiuNCPzKo+VwF4y10CbDL/tDafCe8pwQnfbtCTtEqVc8; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lsjua-0007iY-Nt; Sat, 11 Apr 2009 16:34:48 -0400 Message-ID: <007c01c9bae5$40da5f60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 13:36:54 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173a0106b04320f9328ce6d7bac191631c9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #46 (AD comment 13) MAY -> can in section 4.6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:33:40 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 13). > > > 4.6. Considerations for Private Use Subtags > > [...] > > > However, in some cases content tagged with private use subtags MAY > > interact with other systems in a different and possibly unsuitable > > manner compared to tags that use opaque, privately defined subtags, > > so the choice of the best approach sometimes depends on the > > particular domain in question. > > I think use of MAY is improper here and I suggest changing it to "can" ... As a technical contributor... I agree with the proposed change. Randy From randy_presuhn@mindspring.com Sat Apr 11 13:59:47 2009 Return-Path: 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 862263A6929 for ; Sat, 11 Apr 2009 13:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 Gnro2ir4MAqW for ; Sat, 11 Apr 2009 13:59:46 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id AC4153A68FE for ; Sat, 11 Apr 2009 13:59:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Pq78nk7FWzuUOMObTitnPOpRPGdAeGzK1oA8w8qAs9OtpTaGPgaTqJ3ES+6ZJxai; 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 [69.3.28.129] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LskJs-0005Xf-6q; Sat, 11 Apr 2009 17:00:56 -0400 Message-ID: <027d01c9bae8$e6ef6f00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "LTRU Working Group" References: <49E04FF4.1040804@isode.com> Date: Sat, 11 Apr 2009 14:03:01 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1737b49b444aed5184facdf5d0c9d6fad29350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Subject: [Ltru] Issue #47 (AD comment #14) section 3.1.2 confusing text on replacement tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:59:47 -0000 Hi - > From: "Alexey Melnikov" > To: "LTRU Working Group" > Sent: Saturday, April 11, 2009 1:08 AM > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > 14). In Section 3.1.2: > > > o Preferred-Value > > > > * Preferred-Value's field body contains a canonical mapping from > > this record's value to a modern equivalent that is preferred in > > its place. Depending on the value of the 'Type' field, this > > value can take different forms: > > [...] > > > + For fields of type 'extlang', 'grandfathered', or > > 'redundant', 'Preferred-Value' contains an "extended > > language range" ([RFC4647]) that is preferred for forming > > the language tag. As co-chair: I think we have a problem here. In December 2008 we had lengthy discussion of whether "extended language range" from RFC 4647 was the right thing to use for prefixes. The conclusion was that it was not. I think we may have a similar problem here. > > That is, each of the subtags that appears > > in the value MUST appear in the replacement tag; > > You lost me here: what is "the value" and what is "the replacement tag" > in this case. > > > additional > > fields can be included in a language tag as described > > elsewhere in this document. For example, the replacement > > for the grandfathered tag "zh-min-nan" (Min Nan Chinese) is > > "nan", which can be used as the basis for tags such as "nan- > > Hant" or "nan-TW" (note that the extended language subtag > > form such as "zh-nan-Hant" or "zh-nan-TW" can also be used). As a technical contributor... I agree that the text as written might perhaps be described as "obvious only if previously understood." I'm not sure how to fix it. Randy From doug@ewellic.org Sat Apr 11 14:07:27 2009 Return-Path: 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 9F1C33A6929 for ; Sat, 11 Apr 2009 14:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=1.520, BAYES_00=-2.599, GB_I_LETTER=-2, STOX_REPLY_TYPE=0.001] 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 9EFOKqyFMfX0 for ; Sat, 11 Apr 2009 14:07:26 -0700 (PDT) Received: from smtpout04.prod.mesa1.secureserver.net (smtpout04-01.prod.mesa1.secureserver.net [64.202.165.196]) by core3.amsl.com (Postfix) with SMTP id 971BE3A6905 for ; Sat, 11 Apr 2009 14:07:26 -0700 (PDT) Received: (qmail 8527 invoked from network); 11 Apr 2009 21:08:35 -0000 Received: from unknown (67.166.27.148) by smtpout04.prod.mesa1.secureserver.net (64.202.165.196) with ESMTP; 11 Apr 2009 21:08:35 -0000 Message-ID: <33BB16DECE674C149C783F76BFD0C366@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 11 Apr 2009 15:08:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 21:07:27 -0000 Alexey Melnikov wrote: >>>> The fields in the "Record Requested" section SHOULD follow the >>>> requirements in Section 3.1. >>> >>> What are the reasons not to follow requirements in Section 3.1? >>> (I.e. why is SHOULD used instead of MUST?) >> >> I think the idea was to allow the language subtag reviewer to >> consider requests that followed the spirit, if not the letter of the >> syntax. Since the LSR is not an automated process, and we do not >> want to introduce artificial barriers to those needing language >> subtags, a little flexibility is desirable. Consequently, I think >> the SHOULD is ok - it's operational advice, and failure to follow it >> to the letter won't necessarily cause any problems at all. > > I understand and agree with the desire to be flexible. > However my understanding is that the request sent to IANA must be in > the correct form. Maybe you should clarify that. My understanding is that people submitting requests to ietf-languages are encouraged, but not required, to follow the requirements in Section 3.1, and the Reviewer and clerical assistant (with the help of ietf-languages contributors) are expected to fix any editorial problems before approving a submission and sending it to IANA. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From everson@evertype.com Sat Apr 11 14:55:00 2009 Return-Path: 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 1180C3A68B5 for ; Sat, 11 Apr 2009 14:55:00 -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=[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 vLY5HxRr1V0x for ; Sat, 11 Apr 2009 14:54:59 -0700 (PDT) Received: from lh22.dnsireland.com (lh22.dnsireland.com [78.137.164.62]) by core3.amsl.com (Postfix) with ESMTP id 06DAE3A6835 for ; Sat, 11 Apr 2009 14:54:58 -0700 (PDT) Received: from murrisk2.westnet.ie ([88.81.100.235] helo=[192.168.1.112]) by lh22.dnsireland.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Lsl8s-0004A3-WB; Sat, 11 Apr 2009 22:53:39 +0100 From: Michael Everson To: Doug Ewell In-Reply-To: X-Priority: 3 References: Message-Id: <8DACDDC4-CA70-4A88-B7D3-2E25B9989C26@evertype.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 11 Apr 2009 22:56:05 +0100 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - lh22.dnsireland.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - evertype.com X-Source: X-Source-Args: X-Source-Dir: Cc: LTRU Working Group Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 21:59:23 -0000 Yes, I am happy to continue being reviewer for the 4646bis. On 11 Apr 2009, at 20:58, Doug Ewell wrote: > Alexey Melnikov wrote: > >> IANA lists Michael Everson and Doug Ewell as the registry =20 >> reviewers. Are they happy to continue being reviewers for the =20 >> 4646bis? > > I know I am, and I'm pretty sure Michael is. But draft-4646bis-21, =20= > Section 3.2, second paragraph requires the IESG to solicit nominees =20= > and feedback and make the appointment(s) all over again, for some =20 > reason not clear to me, and so the question of who the Reviewer(s) =20 > will be is best deferred until that time. > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages =88 > Michael Everson * http://www.evertype.com/ From randy_presuhn@mindspring.com Sat Apr 11 16:07:48 2009 Return-Path: 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 52F9C3A6B5C for ; Sat, 11 Apr 2009 16:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 cuE2EeY0POFs for ; Sat, 11 Apr 2009 16:07:47 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 84C6E3A6E08 for ; Sat, 11 Apr 2009 16:07:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gf1QCxM3J1uOk7sNYGRiWKDAaUCm97ZLjUI6gYabESSIgSnZ3UzxuwpKAm35wuH4; h=Received:Message-ID:From:To:Cc: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 [69.3.28.129] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsmJk-0007Ar-SQ; Sat, 11 Apr 2009 19:08:57 -0400 Message-ID: <003c01c9bafa$c8d71920$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Sat, 11 Apr 2009 16:11:01 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1737224fd6b6aa9c31c89989b88bef7c42a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Cc: Alexey Melnikov Subject: [Ltru] (AD comment #0) reviewer appointment X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 23:07:48 -0000 Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Cc: "Michael Everson" > Sent: Saturday, April 11, 2009 12:58 PM > Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt > > Alexey Melnikov wrote: > > > IANA lists Michael Everson and Doug Ewell as the registry reviewers. > > Are they happy to continue being reviewers for the 4646bis? > > I know I am, and I'm pretty sure Michael is. But draft-4646bis-21, > Section 3.2, second paragraph requires the IESG to solicit nominees and > feedback and make the appointment(s) all over again, for some reason not > clear to me, and so the question of who the Reviewer(s) will be is best > deferred until that time. > ... I have *not* entered this as an issue, and will not do so unless someone wants to explicitly raise it as an issue. Randy From randy_presuhn@mindspring.com Sat Apr 11 16:13:38 2009 Return-Path: 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 56FC43A6AF9 for ; Sat, 11 Apr 2009 16:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 xQnElcFhJ43M for ; Sat, 11 Apr 2009 16:13:37 -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 6EB2C3A6A24 for ; Sat, 11 Apr 2009 16:13:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oslyFq7i4I23e6OsOT8mx+3UzMlBAkvEo8zQNwvTHCx+LWhpUgbHdo5hfvXjqDGR; h=Received:Message-ID:From:To:Cc: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 [69.3.28.129] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LsmPO-0002o4-S1; Sat, 11 Apr 2009 19:14:47 -0400 Message-ID: <004301c9bafb$9a3b3960$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <49E04FF4.1040804@isode.com> <20090411195511.GA24528@mercury.ccil.org> Date: Sat, 11 Apr 2009 16:16:53 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173c311e8c345c7f12c344d6ccdf29249ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Cc: LTRU Working Group Subject: Re: [Ltru] Issue #35 (AD comment #2) what is meant by "permanently reserved"? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 23:13:38 -0000 Hi - > From: "John Cowan" > To: "Alexey Melnikov" > Cc: "LTRU Working Group" > Sent: Saturday, April 11, 2009 12:55 PM > Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt ... > > > 4. Although the ABNF production 'extlang' permits up to three > > > extended language tags in the language tag, extended language > > > subtags MUST NOT include another extended language subtag in > > > their Prefix. That is, the second and third extended language > > > subtag positions in a language tag are permanently reserved and > > > tags that include subtags in that position are invalid. > > > > [Unclear text] Clarification on what is meant by "permanently reserved" > > here would be appreciated. > > ("Permanently reserved" == "MUST NOT be registered, unless a future > > version of this document changes that"?) > > No, it means "We guarantee that such subtags will never be registered > even if this document is revised." A constraint on 4646bis is that > every tag that was well-formed in 4646 is still well-formed, so we > did not remove the grammar that allows tags like abc-def-ghi; however, > we give explicit permission for validators to reject them out of hand. ... As a technical contributor... I have to agree with Alexey that some clarification is in order. I wouldn't have come to the "will never be registered even if this document is revised" from reading just what's in the I-D. If we're really really sure that's what we mean, I suggest replacing "are invalid" with "are (and will always be) invalid". Randy From mark.edward.davis@gmail.com Sat Apr 11 17:44:48 2009 Return-Path: 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 E0A2C3A6855 for ; Sat, 11 Apr 2009 17:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 jic7gscKndAC for ; Sat, 11 Apr 2009 17:44:48 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 135603A67F6 for ; Sat, 11 Apr 2009 17:44:47 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1580329wfg.31 for ; Sat, 11 Apr 2009 17:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=CVKnvXt2mn3hgWsncbPuKyUtb1u9EbypCCAKcOT/l6U=; b=Z6vW6zH0XhkMP/NOaOOU0Qxyq4P6MdAh6lgHhe/wTNstpEFoR8Umw0cpkcbXCGmnyU gU0O7XYX870Z40zQDx32n2gm7fHbDBaGCPEj+gADmRpFWw41ssuMBHC2DVdN+u41G/Cl 6YsVM+m+eRujforGJ0OcOzQ2ZAAlaCgCauLio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=IAuCtMFmX/hmOANpeIkoAxyFNPCJB+fu81yBR9dkGZD/l0fCpRjW8uYVCDoGfZnoRR omwAuhGfoxPIbPgFvMGWvpcc33v0exhoTeciJpfu9Tf6tOzwk4Pc4xzkMeywQGZupwMj Lm+Cf7ora/QNwnXJWygoqftFryZX0srLkOVmU= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.58.20 with SMTP id g20mr1981655wfa.1.1239497157705; Sat, 11 Apr 2009 17:45:57 -0700 (PDT) In-Reply-To: <002c01c9badc$06d40720$6801a8c0@oemcomputer> References: <49E04FF4.1040804@isode.com> <002c01c9badc$06d40720$6801a8c0@oemcomputer> Date: Sat, 11 Apr 2009 17:45:57 -0700 X-Google-Sender-Auth: f737a97f0e932d6d Message-ID: <30b660a20904111745p6b1cac4h3fb6bb9d0f3d076e@mail.gmail.com> From: Mark Davis To: Randy Presuhn Content-Type: multipart/alternative; boundary=001636e8ffd2c90090046750eb9d Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #37 (AD comment #4) delete last sentence of 2.2.9 note X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:44:49 -0000 --001636e8ffd2c90090046750eb9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit agreed Mark On Sat, Apr 11, 2009 at 12:30, Randy Presuhn wrote: > Hi - > > > From: "Alexey Melnikov" > > To: "LTRU Working Group" > > Sent: Saturday, April 11, 2009 1:08 AM > > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt > ... > > 4). In Section 2.2.9: > > > > > Note well: although the 'Language-Tag' production appearing in this > > > document is functionally equivalent to the one in [RFC4646], it has > > > been changed to prevent certain errors in well-formedness arising > > > from the old 'grandfathered' production. This version of the ABNF > is > > > RECOMMENDED as a replacement for the older version. > > > > (nit) I suggest deleting the last sentence, as it doesn't provide any > > useful information to a reader (as the WG wants > > draft-ietf-ltru-4646bis-21bis.txt to replace RFC 4646, it is clear that > > the WG believes that the new ABNF is better). Also I don't think it uses > > RFC 2119 keyword properly. > ... > > As a technical contributor, I agree with deleting the sentence. > The whole paragraph arose as a result of concerns about the > perception of the stability of the grammar. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e8ffd2c90090046750eb9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable agreed
Mark


On Sat, Apr 11, 2009 at 12:30, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

> From: "Alexey Melnikov" <alexey.melnikov@isode.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Saturday, April 11, 2009 1:08 AM
> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt
...
> 4). In Section 2.2.9:
>
> > =C2=A0 =C2=A0Note well: although the 'Language-Tag' produ= ction appearing in this
> > =C2=A0 =C2=A0document is functionally equivalent to the one in [R= FC4646], it has
> > =C2=A0 =C2=A0been changed to prevent certain errors in well-forme= dness arising
> > =C2=A0 =C2=A0from the old 'grandfathered' production. =C2= =A0This version of the ABNF is
> > =C2=A0 =C2=A0RECOMMENDED as a replacement for the older version.<= br> >
> (nit) I suggest deleting the last sentence, as it doesn't provide = any
> useful information to a reader (as the WG wants
> draft-ietf-ltru-4646bis-21bis.txt to replace RFC 4646, it is clear tha= t
> the WG believes that the new ABNF is better). Also I don't think i= t uses
> RFC 2119 keyword properly.
...

As a technical contributor, I agree with deleting the sentence.
The whole paragraph arose as a result of concerns about the
perception of the stability of the grammar.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e8ffd2c90090046750eb9d-- From mark.edward.davis@gmail.com Sat Apr 11 17:46:05 2009 Return-Path: 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 BD44E3A69C2 for ; Sat, 11 Apr 2009 17:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 vA85W9SGRYDs for ; Sat, 11 Apr 2009 17:46:04 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id ADEDC3A6876 for ; Sat, 11 Apr 2009 17:45:37 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1281811rvb.49 for ; Sat, 11 Apr 2009 17:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=JLG+tooWxKuIRonFZTo/Mfy/roUQ7QGjFAnMBHyTb04=; b=FI0urEIuS0ZPplSANaBkASjn91bXXERIaltcXb0/7A+pqwWJ3kkmipP20k20UNIrTe rIaJSQaOudbgAZH5B72yIUJrmMjTqTwvkJTIQqfEntn2f9fzdg+gbFGcnGgxGwsCpppQ E5BTBeaxziklMn/AuGYz1TLW5GgG+Dk3npq3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=WptQgECmlAy6qj67nJa0GgcHT7WdrWzVz9Dm69bFNx6ro4g7Uj6zou831+cevmLSG+ uzyIYK6caFBtplZ9J6+k9iN+5EhN6RscI86AlPUKjZpeKmLQtAjSLX9gD+H7pCZr0CVs bjPq4T+hQykyC0dfuT+jo2gEMY05RMxZLROHM= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.223.4 with SMTP id v4mr1982834wfg.11.1239497207496; Sat, 11 Apr 2009 17:46:47 -0700 (PDT) In-Reply-To: <002701c9badb$56985dc0$6801a8c0@oemcomputer> References: <49E04FF4.1040804@isode.com> <002701c9badb$56985dc0$6801a8c0@oemcomputer> Date: Sat, 11 Apr 2009 17:46:47 -0700 X-Google-Sender-Auth: b173caf1e15c09f8 Message-ID: <30b660a20904111746nf25cab9ta2a7d8c4013b69ae@mail.gmail.com> From: Mark Davis To: Randy Presuhn Content-Type: multipart/alternative; boundary=000e0cd25534c0c0b2046750ee9a Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #36 (AD comment #3) rules for UN M.49 codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:46:05 -0000 --000e0cd25534c0c0b2046750ee9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Agreed. (and this should be a MUST NOT) Mark On Sat, Apr 11, 2009 at 12:25, Randy Presuhn wrote: > Hi - > > > From: "Alexey Melnikov" > > To: "LTRU Working Group" > > Sent: Saturday, April 11, 2009 1:08 AM > > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt > ... > > ... > > 3). Section 2.2.4 says: > > > > > F. All other UN numeric codes for countries or areas that do > not > > > have an associated ISO 3166-1 alpha-2 code MUST NOT be > > > entered into the registry and MUST NOT be used to form > > > language tags. For more information about these codes, see > > > Section 3.4. > > > > And Section 3.4 says: > > > > > 16. UN M.49 has codes for both countries and areas (such as '276' > > > for Germany) and geographical regions and sub-regions (such as > > > '150' for Europe). UN M.49 country or area codes for which > > > there is no corresponding ISO 3166-1 code SHOULD NOT be > > > > Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in > > section 2.2.4. > > I think you need to change one of 2 sections. > > > > > registered, except as a surrogate for an ISO 3166-1 code that > is > > > blocked from registration by an existing subtag. If such a > code > > > becomes necessary, then the registration authority for ISO > > > 3166-1 SHOULD first be petitioned to assign a code to the > > > region. If the petition for a code assignment by ISO 3166-1 is > > > refused or not acted on in a timely manner, the registration > > > process described in Section 3.5 MAY then be used to register > > > the corresponding UN M.49 code. This way, UN M.49 codes remain > > > available as the value of last resort in cases where ISO 3166-1 > > > reassigns a deprecated value in the registry. > > As co-chair - we should make sure that the resolution of this issue and > tracker issue #40 (AD comment #7) are coordinated. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --000e0cd25534c0c0b2046750ee9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. (and this should be a MUST NOT)
Mark


On Sat, Apr 11, 2009 at 12:25, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

> From: "Alexey Melnikov" <alexey.melnikov@isode.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Saturday, April 11, 2009 1:08 AM
> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt
...

...
> 3). Section 2.2.4 says:
>
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0F. =C2=A0All other UN numeric codes fo= r countries or areas that do not
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have an associated ISO 3= 166-1 alpha-2 code MUST NOT be
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entered into the registr= y and MUST NOT be used to form
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0language tags. =C2=A0For= more information about these codes, see
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.4.
>
> And Section 3.4 says:
>
> > =C2=A0 16. =C2=A0UN M.49 has codes for both countries and areas (= such as '276'
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 for Germany) and geographical regions= and sub-regions (such as
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 '150' for Europe). =C2=A0UN M= .49 country or area codes for which
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 there is no corresponding ISO 3166-1 = code SHOULD NOT be
>
> Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in<= br> > section 2.2.4.
> I think you need to change one of 2 sections.
>
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 registered, except as a surrogate for= an ISO 3166-1 code that is
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 blocked from registration by an exist= ing subtag. =C2=A0If such a code
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 becomes necessary, then the registrat= ion authority for ISO
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 3166-1 SHOULD first be petitioned to = assign a code to the
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 region. =C2=A0If the petition for a c= ode assignment by ISO 3166-1 is
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 refused or not acted on in a timely m= anner, the registration
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 process described in Section 3.5 MAY = then be used to register
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 the corresponding UN M.49 code. =C2= =A0This way, UN M.49 codes remain
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 available as the value of last resort= in cases where ISO 3166-1
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 reassigns a deprecated value in the r= egistry.

As co-chair - we should make sure that the resolution of this issue and
tracker issue #40 (AD comment #7) are coordinated.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--000e0cd25534c0c0b2046750ee9a-- From mark.edward.davis@gmail.com Sat Apr 11 17:47:54 2009 Return-Path: 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 A70AC3A6ABA for ; Sat, 11 Apr 2009 17:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 UOPNhN7M3jsI for ; Sat, 11 Apr 2009 17:47:53 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id C898F3A6A48 for ; Sat, 11 Apr 2009 17:47:53 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1580946wfg.31 for ; Sat, 11 Apr 2009 17:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=n6a7kpQy8ZiEaR9PAq2KBNxOY+EyytNoigcYEJpCtSY=; b=J4ZghsdDK2gSCPMyCprTF25SLJ0QEFqOr06x3FnPuRtne0sMGlq9WM5TLi0W2NPeiB x67AlayA8eMfhRyD1vVmkHeJui1BEhqg73d2lxI27TYCofpv39j2+nPcQqk4Xd+nwA6x CbtsbQlbLxESB5tMFNzopIF7XYZ+pfQqY0Ito= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=NjkwKMuq8ElZjykuG7Xy/ilUPmT8Pw1DPN9+urC+eMStzXfet0PXjC3XrZIj133orO QP6SvQJtCAnOowsnyinmr5ldKgoPttvr7UL1soTSajbBqG4jYsbvhyy770A+N8RvqeUh D2c4IGRwbncLJrZP3icjzOOWQS12Gielh2gtg= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.187.19 with SMTP id k19mr1984214wff.63.1239497343663; Sat, 11 Apr 2009 17:49:03 -0700 (PDT) In-Reply-To: <005a01c9bae0$ce05d860$6801a8c0@oemcomputer> References: <49E04FF4.1040804@isode.com> <005a01c9bae0$ce05d860$6801a8c0@oemcomputer> Date: Sat, 11 Apr 2009 17:49:03 -0700 X-Google-Sender-Auth: 0cb549cd64065018 Message-ID: <30b660a20904111749j2c253107sc70f3154ec9c45d0@mail.gmail.com> From: Mark Davis To: Randy Presuhn Content-Type: multipart/alternative; boundary=000e0cd2dda4de7f12046750f65c Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #42 (AD comment #9) confusing future tense X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:47:54 -0000 --000e0cd2dda4de7f12046750f65c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit agreed Mark On Sat, Apr 11, 2009 at 13:05, Randy Presuhn wrote: > Hi - > > > From: "Alexey Melnikov" > > To: "LTRU Working Group" > > Sent: Saturday, April 11, 2009 1:08 AM > > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt > ... > > 9). > > > > > 3.8. Update of the Language Subtag Registry > > > > > > Upon adoption of this document the IANA Language Subtag Registry > will > > > need an update so that it contains the complete set of subtags valid > > > in a language tag. This collection of subtags, along with a > > > description of the process used to create it, is described by > > > [draft-4645bis]. IANA will publish the updated version of the > > > registry described by this document using the instructions and > > > content of [draft-4645bis]. > > > > (nit) I think both 4645bis and 4646bis should be published at the same > time. > > If this happens, then use of future tense in the published RFC would be > > confusing and will not match the reality. > > > > I suggest adding an RFC Editor note asking to fix this sentence. > > > > > Once published by IANA, the maintenance > > > procedures, rules, and registration processes described in this > > > document will be available for new registrations or updates. > ... > > As a technical contributor... > the proposed fix works for me. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --000e0cd2dda4de7f12046750f65c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable agreed
Mark


On Sat, Apr 11, 2009 at 13:05, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

> From: "Alexey Melnikov" <alexey.melnikov@isode.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Saturday, April 11, 2009 1:08 AM
> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt
...
> 9).
>
> > 3.8. =C2=A0Update of the Language Subtag Registry
> >
> > =C2=A0 =C2=A0Upon adoption of this document the IANA Language Sub= tag Registry will
> > =C2=A0 =C2=A0need an update so that it contains the complete set = of subtags valid
> > =C2=A0 =C2=A0in a language tag. =C2=A0This collection of subtags,= along with a
> > =C2=A0 =C2=A0description of the process used to create it, is des= cribed by
> > =C2=A0 =C2=A0[draft-4645bis]. =C2=A0IANA will publish the updated= version of the
> > =C2=A0 =C2=A0registry described by this document using the instru= ctions and
> > =C2=A0 =C2=A0content of [draft-4645bis].
>
> (nit) I think both 4645bis and 4646bis should be published at the same= time.
> If this happens, then use of future tense in the published RFC would b= e
> confusing and will not match the reality.
>
> I suggest adding an RFC Editor note asking to fix this sentence.
>
> > Once published by IANA, the maintenance
> > =C2=A0 =C2=A0procedures, rules, and registration processes descri= bed in this
> > =C2=A0 =C2=A0document will be available for new registrations or = updates.
...

As a technical contributor...
the proposed fix works for me.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--000e0cd2dda4de7f12046750f65c-- From mark.edward.davis@gmail.com Sat Apr 11 17:49:18 2009 Return-Path: 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 41B6C3A6B30 for ; Sat, 11 Apr 2009 17:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 22GAFwqw6sqc for ; Sat, 11 Apr 2009 17:49:17 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 6951F3A6B46 for ; Sat, 11 Apr 2009 17:49:17 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1581277wfg.31 for ; Sat, 11 Apr 2009 17:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=kXSJN1nBfcrJgiyrCevqMFqXiDWCKQTLgl5uQqQNyPU=; b=sFM/3TBRLXQ623W485ArEPe8Qs8bNJZ91CS9yylFvMtflJkAMeMvUQThTD/mH/Ih5h lp4Adrt6Pxm5h8WfBrjYouiN5NiWpccd4T7VZsJ4G7vZs86W/zxdfYoM/tNrMD3BZ4s3 A1I1EO5lACc2F6eVzrlhtNwYCkTEalXSr0c3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=g19CzshXb5efrB37PPItpuO/1PHYvrkaOdKGpBP5sFlZDOlMvyU6ClF5+W9UwFRUwB oYCHJB4uV8cY/XDvsVHG3/Akj2c32wEv/8Ou0gRUXBRWicfnyq+Sfqe8s7utEqQeJFwo nFd5yfF7h7jYUP9gctgMNCBiCkGyCran9EL6M= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.41.5 with SMTP id t5mr1979687wfj.134.1239497427325; Sat, 11 Apr 2009 17:50:27 -0700 (PDT) In-Reply-To: <49E0FC49.7000208@isode.com> References: <49E04FF4.1040804@isode.com> <006c01c9bae2$f32c1ee0$6801a8c0@oemcomputer> <49E0FC49.7000208@isode.com> Date: Sat, 11 Apr 2009 17:50:26 -0700 X-Google-Sender-Auth: 97cdaa570954989f Message-ID: <30b660a20904111750qfc53f2cpb52ba7d10432b88d@mail.gmail.com> From: Mark Davis To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001636e8ffc5db134e046750fb26 Cc: LTRU Working Group Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference to MIME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:49:18 -0000 --001636e8ffc5db134e046750fb26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I would rather keep examples; they are usually helpful in understanding the text. Mark On Sat, Apr 11, 2009 at 13:23, Alexey Melnikov wrote: > Randy Presuhn wrote: > > Hi - >> >> >>> From: "Alexey Melnikov" >>> To: "LTRU Working Group" >>> Sent: Saturday, April 11, 2009 1:08 AM >>> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt >>> >>> >> ... >> >> >>> 11). >>> >>> >>>> 4.2. Meaning of the Language Tag >>>> >>>> >>> [...] >>> >>> >>>> o For information objects whose purpose is to provide alternatives, >>>> the associated language tags could be regarded as a hint that the >>>> content is provided in several languages and that one has to >>>> inspect each of the alternatives in order to find its language or >>>> languages. In this case, the presence of multiple tags might not >>>> mean that one needs to be multi-lingual to get complete >>>> understanding of the document. Example: MIME multipart/ >>>> alternative. >>>> >>>> >>> I think this needs an informative reference to MIME. >>> >>> >> ... >> >> As a technical contributor... >> I'd prefer to simply delete the example. >> >> > I actually like the example. But this is up to the WG. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e8ffc5db134e046750fb26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would rather keep examples; they are usually helpful in understanding the= text.

Mark


On Sat, Apr 11, 2009 at 13:23, Alexey Me= lnikov <a= lexey.melnikov@isode.com> wrote:
Randy Presuhn wrote:

Hi -
=C2=A0
From: "Alexey Melnikov" <alexey.melnikov@isode.com>
To: "LTRU Working Group" <ltru@ietf.org>
Sent: Saturday, April 11, 2009 1:08 AM
Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt
=C2=A0
...
=C2=A0
11).
=C2=A0
4.2. =C2=A0Meaning of the Language Tag
=C2=A0 =C2=A0
[...]
=C2=A0
=C2=A0o =C2=A0For information objects whose purpose is to provide alternat= ives,
=C2=A0 =C2=A0 the associated language tags could be regarded as a hint tha= t the
=C2=A0 =C2=A0 content is provided in several languages and that one has to=
=C2=A0 =C2=A0 inspect each of the alternatives in order to find its langua= ge or
=C2=A0 =C2=A0 languages. =C2=A0In this case, the presence of multiple tags= might not
=C2=A0 =C2=A0 mean that one needs to be multi-lingual to get complete
=C2=A0 =C2=A0 understanding of the document. =C2=A0Example: MIME multipart= /
=C2=A0 =C2=A0 alternative.
=C2=A0 =C2=A0
I think this needs an informative reference to MIME.
=C2=A0
...

As a technical contributor...
I'd prefer to simply delete the example.
=C2=A0
I actually like the example. But this is up to the WG.


_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e8ffc5db134e046750fb26-- From mark.edward.davis@gmail.com Sat Apr 11 17:51:05 2009 Return-Path: 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 184863A6BA9 for ; Sat, 11 Apr 2009 17:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 9YuFRc1fILwH for ; Sat, 11 Apr 2009 17:51:04 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 311593A6B30 for ; Sat, 11 Apr 2009 17:50:43 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1282690rvb.49 for ; Sat, 11 Apr 2009 17:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=M4pUInVbfUo9V9DjsJeSQ7Nx1WYz83G4GkGk0ZmiD7g=; b=swqAZbTaEylY6h52uaRFi49C5GUk9P+fiM7sE7gVJMjLwlsOX9b1h94o1ggwshAtmH NrsGIqXBwLl81och6Rs0zAG5mmG2KZnlHr3m8zcuulqvG3C/EaC0r0gCuRaeaM1ddHWx Ulov9WrJRv9TgwHzUQzIWiMCyAQx7VYVlqu1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=I0w/sM64Yxs8D4eI9+y9mhN606fvJidqiawShWkhq5CIPYClc+vLuETGdFRTx1NiCz EvVyVnFXTf5L3CPdarOqyvRTjJ4at4hJ9b/wwupv0ymGuH5Ddmjhfri+qgBkmoEyCOS4 jzW/ZMTj2FKjOJIDpZfxhr1VoXgHGy7c+5r/Y= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.88.4 with SMTP id l4mr1984855wfb.112.1239497512999; Sat, 11 Apr 2009 17:51:52 -0700 (PDT) In-Reply-To: <007701c9bae4$cce46600$6801a8c0@oemcomputer> References: <49E04FF4.1040804@isode.com> <007701c9bae4$cce46600$6801a8c0@oemcomputer> Date: Sat, 11 Apr 2009 17:51:52 -0700 X-Google-Sender-Auth: b026cb855620024e Message-ID: <30b660a20904111751x1124b33bif3e53704a5a97987@mail.gmail.com> From: Mark Davis To: Randy Presuhn Content-Type: multipart/alternative; boundary=00504502c3c8f65acf0467510034 Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #45 (AD comment #12) SHOULD in section 4.5 on preferred value mappings X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:51:05 -0000 --00504502c3c8f65acf0467510034 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Yes, it needs to remain a SHOULD (not changed to MUST). Mark On Sat, Apr 11, 2009 at 13:33, Randy Presuhn wrote: > Hi - > > > From: "Alexey Melnikov" > > To: "LTRU Working Group" > > Sent: Saturday, April 11, 2009 1:08 AM > > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt > ... > > 12). > > > > > 4.5. Canonicalization of Language Tags > > > > [...] > > > > > 3. Subtags of type 'extlang' SHOULD be mapped to their Preferred- > > > Value. > > > > Why use of SHOULD here? I.e. what is a good reason for violating this > rule? > > A pointer here to some case(s) would be appreciated here. > > > > > The field-body of the Preferred-Value for extlangs is an > > > "extended language range" and typically maps to a primary > > > language subtag. For example, the subtag sequence "zh-hak" > > > (Chinese, Hakka) would be replaced with the tag "hak" (Hakka). > ... > > As co-chair... > This point is at the intersection of a couple very contentious issues. > One is the question of whether the canonical form is stable over time, > and the other is the macrolanguage problem. This language reflects > a compromise that I think leaves all parties to the debates equally > unhappy. The reason for the "SHOULD" is that there are situations > where NOT doing the mapping would be operationally preferable. > > As a technical contribtor... > Chinese and Arabic written materials are the "poster children" here, > especially when working with remove-from-right matching algorithms. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --00504502c3c8f65acf0467510034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, it needs to remain a SHOULD (not changed to MUST).=C2=A0

= Mark


On Sat, Apr 11, 2009 at 13:33, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

> From: "Alexey Melnikov" <alexey.melnikov@isode.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Saturday, April 11, 2009 1:08 AM
> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt
...
> 12).
>
> > 4.5. =C2=A0Canonicalization of Language Tags
>
> =C2=A0[...]
>
> > =C2=A0 =C2=A03. =C2=A0Subtags of type 'extlang' SHOULD be= mapped to their Preferred-
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Value.
>
> Why use of SHOULD here? I.e. what is a good reason for violating this = rule?
> A pointer here to some case(s) would be appreciated here.
>
> > =C2=A0 The field-body of the Preferred-Value for extlangs is an > > =C2=A0 =C2=A0 =C2=A0 =C2=A0"extended language range" an= d typically maps to a primary
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0language subtag. =C2=A0For example, th= e subtag sequence "zh-hak"
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0(Chinese, Hakka) would be replaced wit= h the tag "hak" (Hakka).
...

As co-chair...
This point is at the intersection of a couple very contentious issues.
One is the question of whether the canonical form is stable over time,
and the other is the macrolanguage problem. =C2=A0This language reflects a compromise that I think leaves all parties to the debates equally
unhappy. =C2=A0The reason for the "SHOULD" is that there are situ= ations
where NOT doing the mapping would be operationally preferable.

As a technical contribtor...
Chinese and Arabic written materials are the "poster children" he= re,
especially when working with remove-from-right matching algorithms.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--00504502c3c8f65acf0467510034-- From mark.edward.davis@gmail.com Sat Apr 11 17:51:06 2009 Return-Path: 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 B73B13A6B9A for ; Sat, 11 Apr 2009 17:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 K-i4aN1fyNmA for ; Sat, 11 Apr 2009 17:51:06 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 135B43A6B9E for ; Sat, 11 Apr 2009 17:50:59 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1581650wfg.31 for ; Sat, 11 Apr 2009 17:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=cDlxVWPX+sx3+HkF4mjzb/fhSQvKvtjipMO4yytvmek=; b=h7SMnsNLV/BA/xh+eo2pJZQ0p54ZTg0i+iXivHphpdyfh5eub5NaLywhKuRaZbqw8P qD4CZOzYFGZodRqnc9NNQHxz/B8Jw6z7/TQPF0Krh7i8x2JN9dC6asZgvyqU0A9h5ot/ LckKy/hiE8iWSbgHpKHDJ9zbZRVyOEYeis5P8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=fgeDwd8f3nGNXqdcv0oFKpOxlK+oZ1zVSwhYv7476xbYWKNTRf7qrCQNlyXTEXksv9 fCBgKSHFXglgxC7y/BqqtJit6r+SqSYO3Aqo3SYUJ60jaI77bvt/N7+xfTEE44C6A1px SnLKEkuZeg0hhyrijg4GOVQLXtK8pjVc86IDE= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.79.17 with SMTP id c17mr1977375wfb.171.1239497528902; Sat, 11 Apr 2009 17:52:08 -0700 (PDT) In-Reply-To: <007c01c9bae5$40da5f60$6801a8c0@oemcomputer> References: <49E04FF4.1040804@isode.com> <007c01c9bae5$40da5f60$6801a8c0@oemcomputer> Date: Sat, 11 Apr 2009 17:52:08 -0700 X-Google-Sender-Auth: ca408fd54a833332 Message-ID: <30b660a20904111752h36e4bb89s7711ed967e503a1c@mail.gmail.com> From: Mark Davis To: Randy Presuhn Content-Type: multipart/alternative; boundary=001636e0b159e905c90467510148 Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #46 (AD comment 13) MAY -> can in section 4.6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:51:06 -0000 --001636e0b159e905c90467510148 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit agreed Mark On Sat, Apr 11, 2009 at 13:36, Randy Presuhn wrote: > Hi - > > > From: "Alexey Melnikov" > > To: "LTRU Working Group" > > Sent: Saturday, April 11, 2009 1:08 AM > > Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt > ... > > 13). > > > > > 4.6. Considerations for Private Use Subtags > > > > [...] > > > > > However, in some cases content tagged with private use subtags MAY > > > interact with other systems in a different and possibly unsuitable > > > manner compared to tags that use opaque, privately defined subtags, > > > so the choice of the best approach sometimes depends on the > > > particular domain in question. > > > > I think use of MAY is improper here and I suggest changing it to "can" > ... > > As a technical contributor... > I agree with the proposed change. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e0b159e905c90467510148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable agreed

Mark


On Sat, Apr 11, 2009 at 13:36, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

> From: "Alexey Melnikov" <alexey.melnikov@isode.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Saturday, April 11, 2009 1:08 AM
> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt
...
> 13).
>
> > 4.6. =C2=A0Considerations for Private Use Subtags
>
> =C2=A0[...]
>
> > =C2=A0 =C2=A0However, in some cases content tagged with private u= se subtags MAY
> > =C2=A0 =C2=A0interact with other systems in a different and possi= bly unsuitable
> > =C2=A0 =C2=A0manner compared to tags that use opaque, privately d= efined subtags,
> > =C2=A0 =C2=A0so the choice of the best approach sometimes depends= on the
> > =C2=A0 =C2=A0particular domain in question.
>
> I think use of MAY is improper here and I suggest changing it to "= ;can"
...

As a technical contributor...
I agree with the proposed change.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e0b159e905c90467510148-- From mark.edward.davis@gmail.com Sat Apr 11 17:55:00 2009 Return-Path: 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 144573A6B30 for ; Sat, 11 Apr 2009 17:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.118 X-Spam-Level: X-Spam-Status: No, score=-3.118 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 Z7JnzWI5yi7n for ; Sat, 11 Apr 2009 17:54:59 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id F23283A690B for ; Sat, 11 Apr 2009 17:54:58 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1582463wfg.31 for ; Sat, 11 Apr 2009 17:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=rE3aNlQVo4wwUfP+EcJlxI7QCCDv5HuXDu8RHxzoTD4=; b=ckpGiyQpfqVwkKB6nvmT3OIfca1IENduD04KFa58ki/G3bcFbwZpMJwZ6AJpY/0hV6 y50adEfeoCSVgnD30ibEYdCi/FVPqZDorRZwFF20YAbsW2BYw92jIufUK2pYcw8EZL+S BzIT70jNMQK1fcoYYgGY8hVlf+Q67D3VTuvzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=xOskIOHRWVDX5FOecKF0y7n+19aa3LnquuQ27Gd5LsucH6MCgxX1CzG6hCdTg2EPqK Mk2MuIP6fb4jWE+mQ5LUQs4Ql8f/VHO7MPqQeSRYLlmKp3P3VgjryPdDCbiL6GcCsf48 rm10ZqKl1BBDcUNMw7Zork1GzepeQ5pYxVagk= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.89.13 with SMTP id m13mr1980369wfb.185.1239497768688; Sat, 11 Apr 2009 17:56:08 -0700 (PDT) In-Reply-To: <33BB16DECE674C149C783F76BFD0C366@DGBP7M81> References: <33BB16DECE674C149C783F76BFD0C366@DGBP7M81> Date: Sat, 11 Apr 2009 17:56:08 -0700 X-Google-Sender-Auth: e285ae81ffd6b6b8 Message-ID: <30b660a20904111756m7b248c9bu2d95ad53d70f0aba@mail.gmail.com> From: Mark Davis To: Doug Ewell Content-Type: multipart/alternative; boundary=00504502ccc333dcb004675110d0 Cc: LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:55:00 -0000 --00504502ccc333dcb004675110d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it should be a MUST. A SHOULD implies that you don't need to do it if there are good / reasonable reasons not to. That isn't the case here; th= e requirements are clear. That doesn't prevent us from taking the request and making fixes to format, spelling, etc before approving. Mark On Sat, Apr 11, 2009 at 14:08, Doug Ewell wrote: > Alexey Melnikov wrote: > > The fields in the "Record Requested" section SHOULD follow the >>>>> requirements in Section 3.1. >>>>> >>>> >>>> What are the reasons not to follow requirements in Section 3.1? (I.e. >>>> why is SHOULD used instead of MUST?) >>>> >>> >>> I think the idea was to allow the language subtag reviewer to consider >>> requests that followed the spirit, if not the letter of the syntax. Si= nce >>> the LSR is not an automated process, and we do not want to introduce >>> artificial barriers to those needing language subtags, a little flexibi= lity >>> is desirable. Consequently, I think the SHOULD is ok - it's operationa= l >>> advice, and failure to follow it to the letter won't necessarily cause = any >>> problems at all. >>> >> >> I understand and agree with the desire to be flexible. >> However my understanding is that the request sent to IANA must be in the >> correct form. Maybe you should clarify that. >> > > My understanding is that people submitting requests to ietf-languages are > encouraged, but not required, to follow the requirements in Section 3.1, = and > the Reviewer and clerical assistant (with the help of ietf-languages > contributors) are expected to fix any editorial problems before approving= a > submission and sending it to IANA. > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --00504502ccc333dcb004675110d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it should be a MUST. A SHOULD implies that you don't need to do= it if there are good / reasonable reasons not to. That isn't the case = here; the requirements are clear.=C2=A0

That doesn't= prevent us from taking the request and making fixes to format, spelling, e= tc before approving.

Mark


On Sat, Apr 11, 2009 at 14:08, Doug Ewel= l <doug@ewellic.or= g> wrote:
Alexey Melnikov <alexey dot melnikov at isode dot com&= gt; wrote:

The fields in the "Record Requested" section SHOULD follow the re= quirements in Section 3.1.

What are the reasons not to follow requirements in Section 3.1? (I.e. why i= s SHOULD used instead of MUST?)

I think the idea was to allow the language subtag reviewer to consider requ= ests that followed the spirit, if not the letter of the syntax. =C2=A0Since= the LSR is not an automated process, and we do not want to introduce artif= icial barriers to those needing language subtags, a little flexibility is d= esirable. =C2=A0Consequently, I think the SHOULD is ok - it's operation= al advice, and failure to follow it to the letter won't necessarily cau= se any problems at all.

I understand and agree with the desire to be flexible.
However my understanding is that the request sent to IANA must be in the co= rrect form. Maybe you should clarify that.

My understanding is that people submitting requests to ietf-languages are e= ncouraged, but not required, to follow the requirements in Section 3.1, and= the Reviewer and clerical assistant (with the help of ietf-languages contr= ibutors) are expected to fix any editorial problems before approving a subm= ission and sending it to IANA.

--
Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 4645 =C2= =A0* =C2=A0UTN #14
http://www.ewellic.org=
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages = =C2=A0=CB=86




_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--00504502ccc333dcb004675110d0-- From randy_presuhn@mindspring.com Sat Apr 11 17:58:33 2009 Return-Path: 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 4D0823A6B6B for ; Sat, 11 Apr 2009 17:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 BRMfygLztQWv for ; Sat, 11 Apr 2009 17:58:32 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 9C2CC3A68F0 for ; Sat, 11 Apr 2009 17:58:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=A1ivtZNshivIakNFnJKKUfU8PQKVVUL7zmbHjfyc40EhkbLteDum/hU+8sQLlcKj; h=Received:Message-ID:From:To:Cc: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 [69.3.28.129] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lso2b-0002UJ-BR; Sat, 11 Apr 2009 20:59:21 -0400 Message-ID: <001301c9bb0a$26d17ca0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <49E04FF4.1040804@isode.com> <006c01c9bae2$f32c1ee0$6801a8c0@oemcomputer> <49E0FC49.7000208@isode.com> <30b660a20904111750qfc53f2cpb52ba7d10432b88d@mail.gmail.com> Date: Sat, 11 Apr 2009 18:00:36 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173eabd8d93dbec67abfbfb27f6a41c80cf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.129 Cc: LTRU Working Group Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference to MIME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:58:33 -0000 Hi - > From: "Mark Davis" > To: "Alexey Melnikov" > Cc: "Randy Presuhn" ; "LTRU Working Group" > Sent: Saturday, April 11, 2009 5:50 PM > Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference to MIME > > I would rather keep examples; they are usually helpful in understanding the > text. I could live with adding the necessary informative reference if folks prefer to keep the example. Randy From doug@ewellic.org Sat Apr 11 18:01:58 2009 Return-Path: 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 02CF43A6876 for ; Sat, 11 Apr 2009 18:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 4KPGZlalvcA5 for ; Sat, 11 Apr 2009 18:01:57 -0700 (PDT) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by core3.amsl.com (Postfix) with SMTP id 02ED63A67F6 for ; Sat, 11 Apr 2009 18:01:56 -0700 (PDT) Received: (qmail 19783 invoked from network); 12 Apr 2009 01:03:06 -0000 Received: from unknown (67.166.27.148) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 12 Apr 2009 01:03:04 -0000 Message-ID: <6C21E317EB6440D0864273EB02A3AE20@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 11 Apr 2009 19:03:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Issue #45 (AD comment #12) SHOULD in section 4.5 on preferred value mappings X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 01:01:58 -0000 Randy Presuhn wrote: > This point is at the intersection of a couple very contentious issues. > One is the question of whether the canonical form is stable over time, > and the other is the macrolanguage [recte: extlang] problem. This > language reflects a compromise that I think leaves all parties to the > debates equally unhappy. The reason for the "SHOULD" is that there > are situations where NOT doing the mapping would be operationally > preferable. As one of the combatants in the extlang debate, I agree that the current language was the best (or perhaps the "least bad") that we could agree upon. "hak" is Officially Preferred, but "zh-hak" is at least tolerated -- more so than using "iw" instead of "he", a typical deprecated/preferred case. Messing around with this language would probably send us all back to square 1. I hope we don't go there. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From doug@ewellic.org Sat Apr 11 18:10:39 2009 Return-Path: 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 824083A6AF9 for ; Sat, 11 Apr 2009 18:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[AWL=1.413, BAYES_00=-2.599, GB_I_LETTER=-2, STOX_REPLY_TYPE=0.001] 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 Y6Oc4q6Hpoal for ; Sat, 11 Apr 2009 18:10:38 -0700 (PDT) Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by core3.amsl.com (Postfix) with SMTP id 57DD83A69C2 for ; Sat, 11 Apr 2009 18:10:36 -0700 (PDT) Received: (qmail 6360 invoked from network); 12 Apr 2009 01:11:46 -0000 Received: from unknown (67.166.27.148) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 12 Apr 2009 01:11:45 -0000 Message-ID: <469D799FF3A54AE79F6DB16F9FC2958F@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <33BB16DECE674C149C783F76BFD0C366@DGBP7M81> <30b660a20904111756m7b248c9bu2d95ad53d70f0aba@mail.gmail.com> Date: Sat, 11 Apr 2009 19:11:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 01:10:39 -0000 Mark Davis wrote: > I think it should be a MUST. A SHOULD implies that you don't need to > do it if there are good / reasonable reasons not to. That isn't the > case here; the requirements are clear. > > That doesn't prevent us from taking the request and making fixes to > format, spelling, etc before approving. I think it comes down to how much deviation is acceptable. RFC 4646bis is a long document with some rather arcane rules, and it is likely that some very sensible subtag requests will come along that Mark On Sat, Apr 11, 2009 at 14:08, Doug Ewell wrote: Alexey Melnikov wrote: The fields in the "Record Requested" section SHOULD follow the requirements in Section 3.1. What are the reasons not to follow requirements in Section 3.1? (I.e. why is SHOULD used instead of MUST?) I think the idea was to allow the language subtag reviewer to consider requests that followed the spirit, if not the letter of the syntax. Since the LSR is not an automated process, and we do not want to introduce artificial barriers to those needing language subtags, a little flexibility is desirable. Consequently, I think the SHOULD is ok - it's operational advice, and failure to follow it to the letter won't necessarily cause any problems at all. I understand and agree with the desire to be flexible. However my understanding is that the request sent to IANA must be in the correct form. Maybe you should clarify that. My understanding is that people submitting requests to ietf-languages are encouraged, but not required, to follow the requirements in Section 3.1, and the Reviewer and clerical assistant (with the help of ietf-languages contributors) are expected to fix any editorial problems before approving a submission and sending it to IANA. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru From mark.edward.davis@gmail.com Sat Apr 11 18:29:24 2009 Return-Path: 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 BA2823A6A1D for ; Sat, 11 Apr 2009 18:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 orsjLKHdd4BV for ; Sat, 11 Apr 2009 18:29:23 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 5268F3A67F6 for ; Sat, 11 Apr 2009 18:29:23 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1288520rvb.49 for ; Sat, 11 Apr 2009 18:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=ft+eEveFv/ZyXVPH/WbX1xH7nA1jsw5Oj9pXxV8WWbo=; b=gbrnz3ZfkJOfQlYfHhoLblZaJ7ErIOgnbkMeEpnOXGt+zJ5MMIQrvU5W9io+P5inMY zxGLWMmm59cxJ2S/wWaUTHFFYU78khaTPW4BaWIJpAInCE/iqEvtj1V48e2PwEqzlWB3 s74VG7kG/q6TOpVQ/n3WsK4J1r5O6Yo2nuFoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=KlQfjcg8RkLYynqsJSAn7NvCPam5laWULtUCY/nXydZiAOt1ix3Wvpwe9HceaEV7Z+ UQUaPU+HC9GqkkXHjrW/lru0PA8T5cVq4ksY+sdtNQ9ctXMBPxBE67MAMrdj2iSdqf49 J564YtAQt7J9JVRBBSHEW0NPzpxCAx2fPnj4g= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.214.5 with SMTP id m5mr1991136wfg.110.1239499832984; Sat, 11 Apr 2009 18:30:32 -0700 (PDT) In-Reply-To: <469D799FF3A54AE79F6DB16F9FC2958F@DGBP7M81> References: <33BB16DECE674C149C783F76BFD0C366@DGBP7M81> <30b660a20904111756m7b248c9bu2d95ad53d70f0aba@mail.gmail.com> <469D799FF3A54AE79F6DB16F9FC2958F@DGBP7M81> Date: Sat, 11 Apr 2009 18:30:32 -0700 X-Google-Sender-Auth: 01ab85f368f9c096 Message-ID: <30b660a20904111830r367c8c62y5620196f4efb8b29@mail.gmail.com> From: Mark Davis To: Doug Ewell Content-Type: multipart/alternative; boundary=000e0cd2e12c3e84540467518b2f Cc: LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 01:29:24 -0000 --000e0cd2e12c3e84540467518b2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your message was cut off. Let me try to answer anyway. If someone submits a registration form that is either (a) factually incorrect, or (b) breaks the MUST clause (and they are MUSTs for good reason), then in review those problems are pointed out, corrections are made, and the proposal is resubmitted. I don't think this is a real problem. Mark On Sat, Apr 11, 2009 at 18:11, Doug Ewell wrote: > Mark Davis wrote: > > I think it should be a MUST. A SHOULD implies that you don't need to do = it >> if there are good / reasonable reasons not to. That isn't the case here;= the >> requirements are clear. >> >> That doesn't prevent us from taking the request and making fixes to >> format, spelling, etc before approving. >> > > I think it comes down to how much deviation is acceptable. RFC 4646bis i= s > a long document with some rather arcane rules, and it is likely that some > very sensible subtag requests will come along that > > > > Mark > > > > On Sat, Apr 11, 2009 at 14:08, Doug Ewell wrote: > > Alexey Melnikov wrote: > > > The fields in the "Record Requested" section SHOULD follow the requiremen= ts > in Section 3.1. > > > What are the reasons not to follow requirements in Section 3.1? (I.e. why > is SHOULD used instead of MUST?) > > > > I think the idea was to allow the language subtag reviewer to consider > requests that followed the spirit, if not the letter of the syntax. Since > the LSR is not an automated process, and we do not want to introduce > artificial barriers to those needing language subtags, a little flexibili= ty > is desirable. Consequently, I think the SHOULD is ok - it's operational > advice, and failure to follow it to the letter won't necessarily cause an= y > problems at all. > > > I understand and agree with the desire to be flexible. > However my understanding is that the request sent to IANA must be in the > correct form. Maybe you should clarify that. > > > My understanding is that people submitting requests to ietf-languages are > encouraged, but not required, to follow the requirements in Section 3.1, = and > the Reviewer and clerical assistant (with the help of ietf-languages > contributors) are expected to fix any editorial problems before approving= a > submission and sending it to IANA. > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --000e0cd2e12c3e84540467518b2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your message was cut off. Let me try to answer anyway. If someone submits a= registration form that is either (a) factually incorrect, or (b) breaks th= e MUST clause (and they are MUSTs for good reason), then in review those pr= oblems are pointed out, corrections are made, and the proposal is resubmitt= ed.

I don't think this is a real problem.

Mark


On Sat, Apr 11, 2009 at 18:11, Doug Ewel= l <doug@ewellic.or= g> wrote:
Mark Davis wrote:

I think it should be a MUST. A SHOULD implies that you don't need to do= it if there are good / reasonable reasons not to. That isn't the case = here; the requirements are clear.

That doesn't prevent us from taking the request and making fixes to for= mat, spelling, etc before approving.

I think it comes down to how much deviation is acceptable. =C2=A0RFC 4646bi= s is a long document with some rather arcane rules, and it is likely that s= ome very sensible subtag requests will come along that



Mark



On Sat, Apr 11, 2009 at 14:08, Doug Ewell <doug@ewellic.org> wrote:

Alexey Melnikov <alexey dot melnikov at isode dot com> wrote:


The fields in the "Record Requested" section SHOULD follow the re= quirements in Section 3.1.


What are the reasons not to follow requirements in Section 3.1? (I.e. why i= s SHOULD used instead of MUST?)



I think the idea was to allow the language subtag reviewer to consider requ= ests that followed the spirit, if not the letter of the syntax. Since the L= SR is not an automated process, and we do not want to introduce artificial = barriers to those needing language subtags, a little flexibility is desirab= le. =C2=A0Consequently, I think the SHOULD is ok - it's operational adv= ice, and failure to follow it to the letter won't necessarily cause any= problems at all.


I understand and agree with the desire to be flexible.
However my understanding is that the request sent to IANA must be in the co= rrect form. Maybe you should clarify that.


My understanding is that people submitting requests to ietf-languages are e= ncouraged, but not required, to follow the requirements in Section 3.1, and= the Reviewer and clerical assistant (with the help of ietf-languages contr= ibutors) are expected to fix any editorial problems before approving a subm= ission and sending it to IANA.

--
Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 4645 =C2= =A0* =C2=A0UTN #14
http://www.ewellic.org=
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages = =C2=A0=CB=86




_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--000e0cd2e12c3e84540467518b2f-- From doug@ewellic.org Sat Apr 11 21:22:55 2009 Return-Path: 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 D9F6E3A6B96 for ; Sat, 11 Apr 2009 21:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, FAKE_REPLY_C=2.012] 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 nd0vnLty5q5n for ; Sat, 11 Apr 2009 21:22:55 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 6F7793A6B8E for ; Sat, 11 Apr 2009 21:22:53 -0700 (PDT) Received: (qmail 22742 invoked from network); 12 Apr 2009 04:24:03 -0000 Received: from unknown (67.166.27.148) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 12 Apr 2009 04:24:02 -0000 Message-ID: <4AB59300F74F48E2A617997574AD259F@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 11 Apr 2009 22:24:00 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 04:22:55 -0000 Sorry, I hit Send prematurely. Mark Davis wrote: > I think it should be a MUST. A SHOULD implies that you don't need to > do it if there are good / reasonable reasons not to. That isn't the > case here; the requirements are clear. > > That doesn't prevent us from taking the request and making fixes to > format, spelling, etc before approving. I think it comes down to how much deviation is acceptable. RFC 4646bis is a long document with some rather arcane rules, and it is likely that at least one very sensible subtag request will come along on ietf-languages that doesn't conform completely to the RFC. The question is whether such a request will be rejected summarily, or sent back to the requestor with instructions to fix the errors, or whether the deviations are of such a nature that ietf-languages and the Reviewer can figure out what is meant and (with approval of the requestor) correct them as necessary. Debbie Garside and I had a useful discussion about this 2 years ago; see http://www.alvestrand.no/pipermail/ietf-languages/2007-January/005719.html . -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From mark.edward.davis@gmail.com Sat Apr 11 21:36:08 2009 Return-Path: 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 CDC2E3A67AD for ; Sat, 11 Apr 2009 21:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 j-5EI+und2cw for ; Sat, 11 Apr 2009 21:36:07 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id A388028C0DE for ; Sat, 11 Apr 2009 21:35:59 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1317620rvb.49 for ; Sat, 11 Apr 2009 21:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=dGlE+fMQo+RtchnJWNvAas/Zdx8eQ5lwZPXrJGo+ZZs=; b=eOnaNjOCbEuQa6zIWekvTQxPyojW2P46IL29zWIE/ffSmmUZYWJrmbOO8Nmen5UoiP uHGHacZNYRaOtZrXqx+bsbsdxL2E07GxxDP6ADoWgn9eT22mRq0lSPlbzb+gl3jDIxzV QORi1A9Xg/9gASOvPVIfhiGpkUgkM/ahrdh7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=rdLgeGDEUxbtE90h/L9FzrKpe1ba4FlCDgqSonhZcQcqllMmrEyRWfIWp55jWemKBM hdiNfdmNLVUJZ+ag9aNF6UVMoJVp/rApzzwJVmIGbh8h+ZMjfhnKehoD4BqUqwSAm0Pj HgT6Nm7xbPyb82EflypmQxf6q4t5kY0xTiFvc= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.77.7 with SMTP id z7mr2050607wfa.18.1239511029037; Sat, 11 Apr 2009 21:37:09 -0700 (PDT) In-Reply-To: <4AB59300F74F48E2A617997574AD259F@DGBP7M81> References: <4AB59300F74F48E2A617997574AD259F@DGBP7M81> Date: Sat, 11 Apr 2009 21:37:08 -0700 X-Google-Sender-Auth: 54130ec29dc14c2c Message-ID: <30b660a20904112137j4d3e18b3jb7ec4d07b5e5807c@mail.gmail.com> From: Mark Davis To: Doug Ewell Content-Type: multipart/alternative; boundary=001636e90f6c94bc6a04675426bf Cc: LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 04:36:08 -0000 --001636e90f6c94bc6a04675426bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mark On Sat, Apr 11, 2009 at 21:24, Doug Ewell wrote: > Sorry, I hit Send prematurely. > > Mark Davis wrote: > > I think it should be a MUST. A SHOULD implies that you don't need to do = it >> if there are good / reasonable reasons not to. That isn't the case here;= the >> requirements are clear. >> >> That doesn't prevent us from taking the request and making fixes to >> format, spelling, etc before approving. >> > > I think it comes down to how much deviation is acceptable. RFC 4646bis i= s > a long document with some rather arcane rules, and it is likely that at > least one very sensible subtag request will come along on ietf-languages > that doesn't conform completely to the RFC. The question is whether such= a > request will be rejected summarily, or sent back to the requestor with > instructions to fix the errors, or whether the deviations are of such a > nature that ietf-languages and the Reviewer can figure out what is meant = and > (with approval of the requestor) correct them as necessary. Debbie Garsi= de > and I had a useful discussion about this 2 years ago; see > http://www.alvestrand.no/pipermail/ietf-languages/2007-January/005719.htm= l. Well, we can't send them on to IANA without fixes, so they need to be fixed= . Nothing should be rejected summarily - your other two options are the right way to proceed. > > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > --001636e90f6c94bc6a04675426bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mark


On Sat, Apr 11, 2009 at 21:24, Doug Ewel= l <doug@ewellic.or= g> wrote:
Sorry, I hit Send prematurely.


Mark Davis wrote:

I think it should be a MUST. A SHOULD implies that you don't need to do= it if there are good / reasonable reasons not to. That isn't the case = here; the requirements are clear.

That doesn't prevent us from taking the request and making fixes to for= mat, spelling, etc before approving.

I think it comes down to how much deviation is acceptable. =C2=A0RFC 4646bi= s is a long document with some rather arcane rules, and it is likely that a= t least one very sensible subtag request will come along on ietf-languages = that doesn't conform completely to the RFC. =C2=A0The question is wheth= er such a request will be rejected summarily, or sent back to the requestor= with instructions to fix the errors, or whether the deviations are of such= a nature that ietf-languages and the Reviewer can figure out what is meant= and (with approval of the requestor) correct them as necessary. =C2=A0Debb= ie Garside and I had a useful discussion about this 2 years ago; see http://www.alvestrand.no/pipermail/ietf-languages/2= 007-January/005719.html .

Well, we can't send them on to IANA without fixes, = so they need to be fixed. Nothing should be rejected summarily - your other= two options are the right way to proceed.
=C2=A0


--
Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 4645 =C2= =A0* =C2=A0UTN #14
http://www.ewellic.org=
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages = =C2=A0=CB=86


--001636e90f6c94bc6a04675426bf-- From randy_presuhn@mindspring.com Sat Apr 11 22:03:23 2009 Return-Path: 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 268F03A6E9B for ; Sat, 11 Apr 2009 22:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 O8e9LwYeMGsG for ; Sat, 11 Apr 2009 22:03:22 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 1D7083A6869 for ; Sat, 11 Apr 2009 22:03:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=N8MAUnYuHJ8Ak/1pcKlbf/suutw5LAanvZRewcHeIMTfrFHXO99ZebkSKVw+j98y; h=Received:Message-ID:From:To:Cc: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 [64.105.137.122] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lsrrr-0002QC-G9; Sun, 12 Apr 2009 01:04:31 -0400 Message-ID: <003001c9bb2c$75e88e60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <33BB16DECE674C149C783F76BFD0C366@DGBP7M81><30b660a20904111756m7b248c9bu2d95ad53d70f0aba@mail.gmail.com><469D799FF3A54AE79F6DB16F9FC2958F@DGBP7M81> <30b660a20904111830r367c8c62y5620196f4efb8b29@mail.gmail.com> Date: Sat, 11 Apr 2009 22:06:37 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173661b886df5d3de3e8d78f203011a9889350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.137.122 Cc: LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 05:03:23 -0000 Hi - As a technical contributor... > From: "Mark Davis" > To: "Doug Ewell" > Cc: "LTRU Working Group" > Sent: Saturday, April 11, 2009 6:30 PM > Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST > > Your message was cut off. Let me try to answer anyway. If someone submits a > registration form that is either (a) factually incorrect, or (b) breaks the > MUST clause (and they are MUSTs for good reason), then in review those > problems are pointed out, corrections are made, and the proposal is > resubmitted. > I don't think this is a real problem. ... Getting back to the text in question in section 3.5: | The fields in the "Record Requested" section SHOULD follow the | requirements in Section 3.1. I think the point is that we don't want to reject otherwise legitimate requests just because the submitter didn't get some element of syntax exactly right in the request. As Mark points out, the review process is there for good reason. The SHOULD is there because it is operationally helpful if the request gets every last detail of syntax exactly right. Randy From duerst@it.aoyama.ac.jp Sun Apr 12 02:32:10 2009 Return-Path: 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 1B7DA3A6ADD for ; Sun, 12 Apr 2009 02:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.081 X-Spam-Level: X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 YLDvO3f1-5M2 for ; Sun, 12 Apr 2009 02:32:08 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 585943A680E for ; Sun, 12 Apr 2009 02:32:07 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n3C9XGPq012093 for ; Sun, 12 Apr 2009 18:33:16 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 60e1_f365b988_2744_11de_bf0d_001d0969ab06; Sun, 12 Apr 2009 18:33:16 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53114) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 12 Apr 2009 18:32:19 +0900 Message-ID: <49E1B54C.2090204@it.aoyama.ac.jp> Date: Sun, 12 Apr 2009 18:33:00 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Randy Presuhn References: <49E04FF4.1040804@isode.com> <001d01c9bada$1d74cac0$6801a8c0@oemcomputer> In-Reply-To: <001d01c9bada$1d74cac0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #34 (AD comment #1) - who scrutinizes primary subtags refected by ISO 639/RA-JAC? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 09:32:10 -0000 In my impression, this was not specifically the Language Subtag Reviewer, but the overall review process. But of course the Language Subtag Reviewer is a very important part of that process, and the ultimate arbiter. So I guess the proposed text should be fine. We don't have a (sub)section for the review process as such to point to. Regards, Martin. On 2009/04/12 4:17, Randy Presuhn wrote: > Hi - > >> From: "Alexey Melnikov" >> To: "LTRU Working Group" >> Sent: Saturday, April 11, 2009 1:08 AM >> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt > ... >> 1). >> >>> 2.2.1. Primary Language Subtag >> [...] >> >>> 5. Any language subtags of 5 to 8 characters in length in the IANA >> [...] >> >>> At the time this document was created, there were no examples of >>> this kind of subtag and future registrations of this type are >>> discouraged: primary languages are strongly RECOMMENDED for >>> registration with ISO 639, and proposals rejected by ISO 639/ >>> RA-JAC will be closely scrutinized before they are registered >>> with IANA. >> [Unclear text] Scrutinized by whom? At this point in the document it is >> not clear who is going to perform the action. >> I think you meant that this would be done by the designated registry >> reviewer, so I suggest adding a forward reference here. > ... > > Ok with me. Proposed text: > replace "scrutinized" with "scrutinized by the Language Subtag Reviewer > (see 3.2)" > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Sun Apr 12 02:56:27 2009 Return-Path: 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 9823C3A68C5 for ; Sun, 12 Apr 2009 02:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 1fDVYl00rB0P for ; Sun, 12 Apr 2009 02:56:26 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 6440F3A65A6 for ; Sun, 12 Apr 2009 02:56:25 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n3C9vYwW017245 for ; Sun, 12 Apr 2009 18:57:34 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 2c35_58d88540_2748_11de_ac38_001d0969ab06; Sun, 12 Apr 2009 18:57:34 +0900 Received: from [IPv6:::1] ([133.2.210.1]:58391) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 12 Apr 2009 18:56:37 +0900 Message-ID: <49E1BAFF.5050702@it.aoyama.ac.jp> Date: Sun, 12 Apr 2009 18:57:19 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Alexey Melnikov References: <49E04FF4.1040804@isode.com> <003801c9badd$9de466e0$6801a8c0@oemcomputer> <49E0F4D9.6000402@isode.com> In-Reply-To: <49E0F4D9.6000402@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #38 (AD comment #5) ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 09:56:27 -0000 Hello Alex, On 2009/04/12 4:51, Alexey Melnikov wrote: > Randy Presuhn wrote: >>> From: "Alexey Melnikov" >>> 5). In Section 2.2.9: >>> >>>> The format of the registry is described by the following ABNF (per >>>> [RFC5234]): >>>> >>>> registry = record *("%%" CRLF record) >>>> record = 1*field >>>> field = ( field-name field-sep field-body CRLF ) >>>> field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] >>>> field-sep = *SP ":" *SP >>>> field-body = *([[*SP CRLF] 1*SP] 1*CHARS) >>>> CHARS = (%x21-10FFFF) ; Unicode code points >>>> >>> [ABNF error] While I understand what you mean here, I think the >>> definition of CHARS doesn't match the requirement to use UTF-8 >>> encoding stated earlier in section 3.1.1: >>> >>> The registry is a [Unicode] text file, using the UTF-8 [RFC3629] >>> character encoding, and consists of a series of records stored in a >>> format based on "record-jar" (described in [record-jar]). >>> >>> IMHO, you can use ABNF productions from [RFC3629] to fix that. There is nothing wrong in using the ABNF to describe characters rather than bytes. This has been done in the past. In some cases, it's actually the only solution, because the 'encoding' may not be limited to e.g. UTF-8, but also include things such as paper. For an example, please see http://tools.ietf.org/html/rfc3987#section-2.2, in particular the ucschar and iprivate productions. Befor the actual ABNF, RFC 3987 uses the following text: The syntax of this ABNF is described in [RFC2234]. Character numbers are taken from the UCS, without implying any actual binary encoding. Terminals in the ABNF are characters, not bytes. I hope this provides enough of a precedent. When drafting RFC 3987, I carefully checked the ABNF spec, to make sure this is the way this works. For our draft, I suggest replacing The format of the registry is described by the following ABNF (per [RFC5234]): with something like: The format of the registry is described by the ABNF [RFC5234] below. Character numbers are taken from the UCS. Terminals in the ABNF are characters, not bytes. The information about the file being in UTF-8 is higher up in the same subsection, so I don't think it needs to be repeated here. But if you think it's better to add it, we probably can do that. Regards, Martin. >> As a technical contributor... >> Our intention in the ABNF was *NOT* to describe the registry as a >> byte-stream, >> but rather to describe it as a character stream. I view the encoding >> of the >> registry as UTF-8 (rather than UTF-16 or UTF-32 or EBCDIC :-) as a >> separate >> matter from the ABNF, and think that trying to accomplish both in the >> ABNF would only serve to confuse rather than enlighten. >> >> > In this case a comment saying that would be appreciated. > > If you want to do both though, you can define CHARS using UTF-8 > sequences and add a comment that that corresponds to '%x21-10FFFF' > Unicode range. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Sun Apr 12 03:14:12 2009 Return-Path: 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 7FD743A68C5 for ; Sun, 12 Apr 2009 03:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.064 X-Spam-Level: X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 X71xNlkOqEnf for ; Sun, 12 Apr 2009 03:14:11 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 8B3813A67E7 for ; Sun, 12 Apr 2009 03:14:11 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n3CAFKVL018155 for ; Sun, 12 Apr 2009 19:15:20 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 429d_d3ba3fb8_274a_11de_8bb8_0019b9e2b3d9; Sun, 12 Apr 2009 19:15:20 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53980) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 12 Apr 2009 19:14:23 +0900 Message-ID: <49E1BF28.9000905@it.aoyama.ac.jp> Date: Sun, 12 Apr 2009 19:15:04 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Randy Presuhn References: <49E04FF4.1040804@isode.com> <006c01c9bae2$f32c1ee0$6801a8c0@oemcomputer> <49E0FC49.7000208@isode.com> <30b660a20904111750qfc53f2cpb52ba7d10432b88d@mail.gmail.com> <001301c9bb0a$26d17ca0$6801a8c0@oemcomputer> In-Reply-To: <001301c9bb0a$26d17ca0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference to MIME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 10:14:12 -0000 [co-chair/shepherd hat on] Okay, let's add the reference. This is RFC 2046 (Section 5.1.4, but I don't think a section number is necessary). Regards, Martin. On 2009/04/12 10:00, Randy Presuhn wrote: > Hi - > >> From: "Mark Davis" >> To: "Alexey Melnikov" >> Cc: "Randy Presuhn"; "LTRU Working Group" >> Sent: Saturday, April 11, 2009 5:50 PM >> Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference to MIME >> >> I would rather keep examples; they are usually helpful in understanding the >> text. > > I could live with adding the necessary informative reference if folks > prefer to keep the example. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Sun Apr 12 03:14:27 2009 Return-Path: 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 4EDC33A67E7 for ; Sun, 12 Apr 2009 03:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 casAP2xq9JeO for ; Sun, 12 Apr 2009 03:14:26 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 4F0863A65A6 for ; Sun, 12 Apr 2009 03:14:26 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n3CAFZZu022728 for ; Sun, 12 Apr 2009 19:15:35 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 6a53_dc9d1f38_274a_11de_a69d_001d0969ab06; Sun, 12 Apr 2009 19:15:35 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53981) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 12 Apr 2009 19:14:37 +0900 Message-ID: <49E1BF37.5080503@it.aoyama.ac.jp> Date: Sun, 12 Apr 2009 19:15:19 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Alexey Melnikov References: <49E04FF4.1040804@isode.com> <004701c9badf$b4e5c440$6801a8c0@oemcomputer> <49E0FA8C.2060105@isode.com> In-Reply-To: <49E0FA8C.2060105@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 10:14:27 -0000 On 2009/04/12 5:16, Alexey Melnikov wrote: > Randy Presuhn wrote: >>> From: "Alexey Melnikov" >>> 8). In Section 3.5: >>> >>>> The fields in the "Record Requested" section SHOULD follow the >>>> requirements in Section 3.1. >>>> >>> What are the reasons not to follow requirements in Section 3.1? >>> (I.e. why is SHOULD used instead of MUST?) >> I think the idea was to allow the language subtag reviewer to consider >> requests that followed the spirit, if not the letter of the syntax. Since >> the LSR is not an automated process, and we do not want to introduce >> artificial barriers to those needing language subtags, a little >> flexibility >> is desirable. Consequently, I think the SHOULD is ok - it's operational >> advice, and failure to follow it to the letter won't necessarily cause >> any >> problems at all. I agree with Randy and Doug that this should stay a SHOULD. If we view this as a protocol between the submitter and the reviewer(s)/list, a MUST is not appropriate because interoperability is possible otherwise, and because there might be good reasons (e.g. the submitter being an expert for a specific language, but not an expert in reading RFCs) to not be able to follow every last detail. > I understand and agree with the desire to be flexible. > However my understanding is that the request sent to IANA must be in the > correct form. Maybe you should clarify that. That's already done, a bit lower (currently on the same page, at the bottom, although that might change): Before forwarding any registration to IANA, the Language Subtag Reviewer MUST ensure that all requirements in this document are met. This includes ensuring that values in the 'Subtag' field match case according to the description in Section 3.1.4 and that 'Description' fields are unique for the given record type as described in Section 3.1.5. The Reviewer MUST also ensure that an appropriate File-Date record is included in the request, to assist IANA when updating the registry (see Section 5.1). I don't think we need more; it's a fate of long and complicated documents that not everything is said in every place where a reader might look for it. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Sun Apr 12 03:14:44 2009 Return-Path: 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 78F513A6ADD for ; Sun, 12 Apr 2009 03:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.075 X-Spam-Level: X-Spam-Status: No, score=-0.075 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 Ov+CtNn4rtn4 for ; Sun, 12 Apr 2009 03:14:43 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 7DD293A6B53 for ; Sun, 12 Apr 2009 03:14:43 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n3CAFqB7018283 for ; Sun, 12 Apr 2009 19:15:52 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 4426_e738794c_274a_11de_bf90_0019b9e2b3d9; Sun, 12 Apr 2009 19:15:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53982) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 12 Apr 2009 19:14:55 +0900 Message-ID: <49E1BF49.1030908@it.aoyama.ac.jp> Date: Sun, 12 Apr 2009 19:15:37 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Alexey Melnikov References: <49E04FF4.1040804@isode.com> <006701c9bae2$af887260$6801a8c0@oemcomputer> <49E0FAD4.1050803@isode.com> In-Reply-To: <49E0FAD4.1050803@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #43 (AD comment #10) section 5.1 vs 3.2 on file-date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 10:14:44 -0000 Alex - Do you want a change here, or does "Agreed" mean that you are fine with the explanation? Others: Can somebody propose text for a change? Regards, Martin. On 2009/04/12 5:17, Alexey Melnikov wrote: > Randy Presuhn wrote: >>> From: "Alexey Melnikov" >>>> Whenever an entry is created or modified in the registry, the 'File- >>>> Date' record at the start of the registry is updated to reflect the >>>> most recent modification date in the [RFC3339] "full-date" format: >>>> included in any request to insert or modify records will be a new >>>> File-Date record indicating the acceptance date of the record. This >>>> record is to be placed first in the registry, replacing the existing >>>> File-Date record. In the event that the File-Date record present in >>>> the registry has a later date than the record being inserted or >>>> modified, then the latest (most recent) record will be preserved. >>>> >>> I am confused by which date is going to be used by IANA in this case. >>> Section 3.1.2 says: >>> >>> The first record in the registry is always the "File-Date" record. >>> This record occurs only once in the file and contains a single field >>> whose field-name is "File-Date". The field-body of this record >>> contains the last modification date of this copy of the registry, >>> making it possible to compare different versions of the registry. >>> >>> I think if File-Date record present in the registry has a later date >>> than the record being inserted or modified, then IANA should use the >>> date of update (which I assume would be after the record >>> modification/addition date). This way any change to the IANA registry >>> can be detected. >>> >> As a technical contributor... >> I think the intent here is to handle a sequence of update requests >> that arrive out of order. (I frequently see delays of several hours >> from IETF mailing lists, and things normally arrive thoroughly jumbled). >> It would probably have been simpler to just say that it should always >> simply be the date that the file was updated, and not talk about >> the dates on the record(s) being added or updated. > Agreed. > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Sun Apr 12 03:16:53 2009 Return-Path: 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 D83193A68C5 for ; Sun, 12 Apr 2009 03:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.068 X-Spam-Level: X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 JY3aUeTEI1Ez for ; Sun, 12 Apr 2009 03:16:53 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id C79863A6839 for ; Sun, 12 Apr 2009 03:16:52 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n3CAI1dY023415 for ; Sun, 12 Apr 2009 19:18:01 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 72c7_33b962f4_274b_11de_93d0_001d0969ab06; Sun, 12 Apr 2009 19:18:01 +0900 Received: from [IPv6:::1] ([133.2.210.1]:34766) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 12 Apr 2009 19:17:03 +0900 Message-ID: <49E1BFC9.8060209@it.aoyama.ac.jp> Date: Sun, 12 Apr 2009 19:17:45 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Mark Davis References: <49E04FF4.1040804@isode.com> <007c01c9bae5$40da5f60$6801a8c0@oemcomputer> <30b660a20904111752h36e4bb89s7711ed967e503a1c@mail.gmail.com> In-Reply-To: <30b660a20904111752h36e4bb89s7711ed967e503a1c@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #46 (AD comment 13) MAY -> can in section 4.6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 10:16:53 -0000 +1 (hats off). Regards, Martin. On 2009/04/12 9:52, Mark Davis wrote: > agreed > Mark > > > On Sat, Apr 11, 2009 at 13:36, Randy Presuhn > wrote: > >> Hi - >> >>> From: "Alexey Melnikov" >>> To: "LTRU Working Group" >>> Sent: Saturday, April 11, 2009 1:08 AM >>> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt >> ... >>> 13). >>> >>>> 4.6. Considerations for Private Use Subtags >>> [...] >>> >>>> However, in some cases content tagged with private use subtags MAY >>>> interact with other systems in a different and possibly unsuitable >>>> manner compared to tags that use opaque, privately defined subtags, >>>> so the choice of the best approach sometimes depends on the >>>> particular domain in question. >>> I think use of MAY is improper here and I suggest changing it to "can" >> ... >> >> As a technical contributor... >> I agree with the proposed change. >> >> Randy >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www.ietf.org/mailman/listinfo/ltru >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From alexey.melnikov@isode.com Sun Apr 12 03:46:23 2009 Return-Path: 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 B52EF3A6C01 for ; Sun, 12 Apr 2009 03:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 uAa2t+Ry3Qx9 for ; Sun, 12 Apr 2009 03:46:23 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BAFE73A6ADD for ; Sun, 12 Apr 2009 03:46:22 -0700 (PDT) Received: from [172.16.2.111] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Apr 2009 11:47:31 +0100 Message-ID: <49E1C688.9050508@isode.com> Date: Sun, 12 Apr 2009 11:46:32 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <49E04FF4.1040804@isode.com> <006c01c9bae2$f32c1ee0$6801a8c0@oemcomputer> <49E0FC49.7000208@isode.com> <30b660a20904111750qfc53f2cpb52ba7d10432b88d@mail.gmail.com> <001301c9bb0a$26d17ca0$6801a8c0@oemcomputer> <49E1BF28.9000905@it.aoyama.ac.jp> In-Reply-To: <49E1BF28.9000905@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: LTRU Working Group Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference to MIME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 10:46:23 -0000 Martin J. D=FCrst wrote: > [co-chair/shepherd hat on] > > Okay, let's add the reference. This is RFC 2046 (Section 5.1.4, but I=20 > don't think a section number is necessary). This would be fine with me. > Regards, Martin. > > On 2009/04/12 10:00, Randy Presuhn wrote: > >> Hi - >> >>> From: "Mark Davis" >>> To: "Alexey Melnikov" >>> Cc: "Randy Presuhn"; "LTRU Working=20 >>> Group" >>> Sent: Saturday, April 11, 2009 5:50 PM >>> Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference=20 >>> to MIME >>> >>> I would rather keep examples; they are usually helpful in=20 >>> understanding the >>> text. >> >> I could live with adding the necessary informative reference if folks >> prefer to keep the example.=20 > From alexey.melnikov@isode.com Sun Apr 12 03:48:14 2009 Return-Path: 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 9987C3A6C17 for ; Sun, 12 Apr 2009 03:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 2wsiWwn7QulV for ; Sun, 12 Apr 2009 03:48:13 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6F7A53A6E73 for ; Sun, 12 Apr 2009 03:48:13 -0700 (PDT) Received: from [172.16.2.111] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Apr 2009 11:49:19 +0100 Message-ID: <49E1C6FA.9080006@isode.com> Date: Sun, 12 Apr 2009 11:48:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <49E04FF4.1040804@isode.com> <006701c9bae2$af887260$6801a8c0@oemcomputer> <49E0FAD4.1050803@isode.com> <49E1BF49.1030908@it.aoyama.ac.jp> In-Reply-To: <49E1BF49.1030908@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: LTRU Working Group Subject: Re: [Ltru] Issue #43 (AD comment #10) section 5.1 vs 3.2 on file-date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 10:48:14 -0000 Martin J. D=FCrst wrote: > Alex - Do you want a change here, or does "Agreed" mean that you are=20 > fine with the explanation? I would like to see a change/clarification. I was agreeing with: It would probably have been simpler to just say that it should always simply be the date that the file was updated, and not talk about the dates on the record(s) being added or updated. I think this procedure is much simpler. > Others: Can somebody propose text for a change? > > Regards, Martin. > > On 2009/04/12 5:17, Alexey Melnikov wrote: > >> Randy Presuhn wrote: > >>>> From: "Alexey Melnikov" >>> >>>>> Whenever an entry is created or modified in the registry, the 'File- >>>>> Date' record at the start of the registry is updated to reflect the >>>>> most recent modification date in the [RFC3339] "full-date" format: >>>>> included in any request to insert or modify records will be a new >>>>> File-Date record indicating the acceptance date of the record. This >>>>> record is to be placed first in the registry, replacing the existing >>>>> File-Date record. In the event that the File-Date record present in >>>>> the registry has a later date than the record being inserted or >>>>> modified, then the latest (most recent) record will be preserved. >>>> >>>> I am confused by which date is going to be used by IANA in this case. >>>> Section 3.1.2 says: >>>> >>>> The first record in the registry is always the "File-Date" record. >>>> This record occurs only once in the file and contains a single field >>>> whose field-name is "File-Date". The field-body of this record >>>> contains the last modification date of this copy of the registry, >>>> making it possible to compare different versions of the registry. >>>> >>>> I think if File-Date record present in the registry has a later date >>>> than the record being inserted or modified, then IANA should use the >>>> date of update (which I assume would be after the record >>>> modification/addition date). This way any change to the IANA registry >>>> can be detected. >>>> >>> As a technical contributor... >>> I think the intent here is to handle a sequence of update requests >>> that arrive out of order. (I frequently see delays of several hours >>> from IETF mailing lists, and things normally arrive thoroughly=20 >>> jumbled). >>> It would probably have been simpler to just say that it should always >>> simply be the date that the file was updated, and not talk about >>> the dates on the record(s) being added or updated. >> >> Agreed. > From alexey.melnikov@isode.com Sun Apr 12 05:47:25 2009 Return-Path: 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 C9A833A692E for ; Sun, 12 Apr 2009 05:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.016 X-Spam-Level: X-Spam-Status: No, score=-0.016 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_SBL=1.551, SARE_SUB_ENC_UTF8=0.152] 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 PG8oSUdNCWkO for ; Sun, 12 Apr 2009 05:47:25 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DA3A53A68B9 for ; Sun, 12 Apr 2009 05:47:22 -0700 (PDT) Received: from [92.40.112.135] (92.40.112.135.sub.mbb.three.co.uk [92.40.112.135]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Apr 2009 13:48:26 +0100 Message-ID: <49E1E261.6050800@isode.com> Date: Sun, 12 Apr 2009 13:45:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <49E04FF4.1040804@isode.com> <003801c9badd$9de466e0$6801a8c0@oemcomputer> <49E0F4D9.6000402@isode.com> <49E1BAFF.5050702@it.aoyama.ac.jp> In-Reply-To: <49E1BAFF.5050702@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: LTRU Working Group Subject: Re: [Ltru] Issue #38 (AD comment #5) ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 12:47:25 -0000 Martin J. D=FCrst wrote: > Hello Alex, > > On 2009/04/12 4:51, Alexey Melnikov wrote: > >> Randy Presuhn wrote: > >>>> From: "Alexey Melnikov" >>> >>>> 5). In Section 2.2.9: >>>> >>>>> The format of the registry is described by the following ABNF (per >>>>> [RFC5234]): >>>>> >>>>> registry =3D record *("%%" CRLF record) >>>>> record =3D 1*field >>>>> field =3D ( field-name field-sep field-body CRLF ) >>>>> field-name =3D (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)= ] >>>>> field-sep =3D *SP ":" *SP >>>>> field-body =3D *([[*SP CRLF] 1*SP] 1*CHARS) >>>>> CHARS =3D (%x21-10FFFF) ; Unicode code points >>>> >>>> [ABNF error] While I understand what you mean here, I think the >>>> definition of CHARS doesn't match the requirement to use UTF-8 >>>> encoding stated earlier in section 3.1.1: >>>> >>>> The registry is a [Unicode] text file, using the UTF-8 [RFC3629] >>>> character encoding, and consists of a series of records stored in a >>>> format based on "record-jar" (described in [record-jar]). >>>> >>>> IMHO, you can use ABNF productions from [RFC3629] to fix that. >>> > There is nothing wrong in using the ABNF to describe characters rather=20 > than bytes. I didn't say or wanted to imply that it was wrong. My concern is that a naive reader would assume that UTF-8 doesn't need=20 to be applied to the grammar. > This has been done in the past. In some cases, it's actually the only=20 > solution, because the 'encoding' may not be limited to e.g. UTF-8, but=20 > also include things such as paper. For an example, please see=20 > http://tools.ietf.org/html/rfc3987#section-2.2, in particular the=20 > ucschar and iprivate productions. > > Befor the actual ABNF, RFC 3987 uses the following text: > > The syntax of this > ABNF is described in [RFC2234]. Character numbers are taken from the > UCS, without implying any actual binary encoding. Terminals in the > ABNF are characters, not bytes. > > I hope this provides enough of a precedent. When drafting RFC 3987, I=20 > carefully checked the ABNF spec, to make sure this is the way this works. > > For our draft, I suggest replacing > > The format of the registry is described by the following ABNF (per > [RFC5234]): > > with something like: > > The format of the registry is described by the ABNF [RFC5234] below. > Character numbers are taken from the UCS. Terminals in the ABNF are > characters, not bytes. Yes, that would be much better. > The information about the file being in UTF-8 is higher up in the same=20 > subsection, so I don't think it needs to be repeated here. But if you=20 > think it's better to add it, we probably can do that. > > Regards, Martin. > >>> As a technical contributor... >> >>> Our intention in the ABNF was *NOT* to describe the registry as a >>> byte-stream, >>> but rather to describe it as a character stream. I view the encoding >>> of the >>> registry as UTF-8 (rather than UTF-16 or UTF-32 or EBCDIC :-) as a >>> separate >>> matter from the ABNF, and think that trying to accomplish both in the >>> ABNF would only serve to confuse rather than enlighten. >> >> In this case a comment saying that would be appreciated. >> >> If you want to do both though, you can define CHARS using UTF-8 >> sequences and add a comment that that corresponds to '%x21-10FFFF' >> Unicode range. > From alexey.melnikov@isode.com Sun Apr 12 05:51:04 2009 Return-Path: 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 B8A253A6C17 for ; Sun, 12 Apr 2009 05:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_SBL=1.551] 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 Wmw+MBaQngT1 for ; Sun, 12 Apr 2009 05:51:04 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8CA353A69CF for ; Sun, 12 Apr 2009 05:51:00 -0700 (PDT) Received: from [92.40.112.135] (92.40.112.135.sub.mbb.three.co.uk [92.40.112.135]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Apr 2009 13:52:08 +0100 Message-ID: <49E1E3DC.6050508@isode.com> Date: Sun, 12 Apr 2009 13:51:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <49E04FF4.1040804@isode.com> <004701c9badf$b4e5c440$6801a8c0@oemcomputer> <49E0FA8C.2060105@isode.com> <49E1BF37.5080503@it.aoyama.ac.jp> In-Reply-To: <49E1BF37.5080503@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 12:51:04 -0000 Martin J. D=FCrst wrote: > On 2009/04/12 5:16, Alexey Melnikov wrote: > >> Randy Presuhn wrote: > >>>> From: "Alexey Melnikov" >>> >>>> 8). In Section 3.5: >>>> >>>>> The fields in the "Record Requested" section SHOULD follow the >>>>> requirements in Section 3.1. >>>> >>>> What are the reasons not to follow requirements in Section 3.1? >>>> (I.e. why is SHOULD used instead of MUST?) >>> >>> I think the idea was to allow the language subtag reviewer to consider >>> requests that followed the spirit, if not the letter of the syntax.=20 >>> Since >>> the LSR is not an automated process, and we do not want to introduce >>> artificial barriers to those needing language subtags, a little >>> flexibility is desirable. Consequently, I think the SHOULD is ok -=20 >>> it's operational >>> advice, and failure to follow it to the letter won't necessarily cause >>> any problems at all. >> > I agree with Randy and Doug that this should stay a SHOULD. If we view=20 > this as a protocol between the submitter and the reviewer(s)/list, a=20 > MUST is not appropriate because interoperability is possible=20 > otherwise, and because there might be good reasons (e.g. the submitter=20 > being an expert for a specific language, but not an expert in reading=20 > RFCs) to not be able to follow every last detail. Ok. >> I understand and agree with the desire to be flexible. >> However my understanding is that the request sent to IANA must be in the >> correct form. Maybe you should clarify that. > > That's already done, a bit lower (currently on the same page, at the=20 > bottom, although that might change): > > Before forwarding any registration to IANA, the Language Subtag > Reviewer MUST ensure that all requirements in this document are met. (Pedantic) This still means that the Reviewer might violate the SHOULD=20 while complying with the MUST. > This includes ensuring that values in the 'Subtag' field match case > according to the description in Section 3.1.4 and that 'Description' > fields are unique for the given record type as described in > > Section 3.1.5. The Reviewer MUST also ensure that an appropriate > File-Date record is included in the request, to assist IANA when > updating the registry (see Section 5.1). > > I don't think we need more; it's a fate of long and complicated=20 > documents that not everything is said in every place where a reader=20 > might look for it. Ok. From cewcathar@hotmail.com Sun Apr 12 06:52:29 2009 Return-Path: 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 974723A6C28 for ; Sun, 12 Apr 2009 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 XC5mMnTrpTw7 for ; Sun, 12 Apr 2009 06:52:28 -0700 (PDT) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by core3.amsl.com (Postfix) with ESMTP id 9C76C3A6C1D for ; Sun, 12 Apr 2009 06:52:28 -0700 (PDT) Received: from BLU109-W23 ([65.55.116.72]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Apr 2009 06:53:38 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c426dc20-4d7d-4de6-896b-42c9791e8ed9_" X-Originating-IP: [70.88.11.82] From: CE Whitehead To: Date: Sun, 12 Apr 2009 09:53:38 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Apr 2009 13:53:38.0636 (UTC) FILETIME=[14CE28C0:01C9BB76] Subject: Re: [Ltru] Issue #36 (AD comment #3) rules for UN M.49 codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 13:52:29 -0000 --_c426dc20-4d7d-4de6-896b-42c9791e8ed9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don't know if I should inject my two cents here=3B I agree with Mark that "= SHOULD NOT" should=20 become a "MUST NOT" As for the other "SHOULD"s/"MUST"s (section 3.5=2C 4.5) I don't know enough= to comment. Best=2C C. E. Whitehead cewcathar@hotmail.com >> From: "Alexey Melnikov" >> To: "LTRU Working Group" >> Sent: Saturday=2C April 11=2C 2009 1:08 AM >> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt >> 3). Section 2.2.4 says: >> >> > F. All other UN numeric codes for countries or areas that do n= ot >> > have an associated ISO 3166-1 alpha-2 code MUST NOT be >> > entered into the registry and MUST NOT be used to form >> > language tags. For more information about these codes=2C s= ee >> > Section 3.4. >> >> And Section 3.4 says: >> >> > 16. UN M.49 has codes for both countries and areas (such as '276' >> > for Germany) and geographical regions and sub-regions (such as >> > '150' for Europe). UN M.49 country or area codes for which >> > there is no corresponding ISO 3166-1 code SHOULD NOT be >> >> Unless I am confused=2C I think this SHOULD NOT contradicts MUST NOT in >> section 2.2.4. > I think you need to change one of 2 sections.= --_c426dc20-4d7d-4de6-896b-42c9791e8ed9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Don't know if I should inject my two cents here=3B I agree with Ma=
rk that "SHOULD NOT" should 
become a "MUST NOT"
As for the other "SH=
OULD"s/"MUST"s (section 3.5=2C 4.5) I don't know enough to comment.

=
Best=2C

C. E. Whitehead
cewcathar@hotmail.com




=



>=3B>=3B From: "Alexey Melnikov" <=3B=
alexey=
.melnikov at isode.com>=3B

>=3B>=3B To: "LTRU Working Grou=
p" <=3Bltru at i=
etf.org>=3B

>=3B>=3B Sent: Saturday=2C April 11=2C 2009 1:=
08 AM

>=3B>=3B Subject: [Ltru] AD review of draft-ietf-ltru-4646=
bis-21bis.txt



>=3B>=3B 3). Section 2.2.4 says:

&g=
t=3B>=3B

>=3B>=3B >=3B  =3B  =3B  =3B  =3BF.=
  =3BAll other UN numeric codes for countries or areas that do not
<=
br>>=3B>=3B >=3B  =3B  =3B  =3B  =3B  =3B  =
=3Bhave an associated ISO 3166-1 alpha-2 code MUST NOT be

>=3B>=
=3B >=3B  =3B  =3B  =3B  =3B  =3B  =3Bentered int=
o the registry and MUST NOT be used to form

>=3B>=3B >=3B &nbs=
p=3B  =3B  =3B  =3B  =3B  =3Blanguage tags.  =3BFor=
 more information about these codes=2C see

>=3B>=3B >=3B  =
=3B  =3B  =3B  =3B  =3B  =3BSection 3.4.

>=3B&=
gt=3B

>=3B>=3B And Section 3.4 says:

>=3B>=3B

=
>=3B>=3B >=3B  =3B 16.  =3BUN M.49 has codes for both countri=
es and areas (such as '276'

>=3B>=3B >=3B  =3B  =3B &n=
bsp=3B  =3B for Germany) and geographical regions and sub-regions (such=
 as

>=3B>=3B >=3B  =3B  =3B  =3B  =3B '150' fo=
r Europe).  =3BUN M.49 country or area codes for which

>=3B>=
=3B >=3B  =3B  =3B  =3B  =3B there is no corresponding IS=
O 3166-1 code SHOULD NOT be

>=3B>=3B

>=3B>=3B Unless =
I am confused=2C I think this SHOULD NOT contradicts MUST NOT in

>=
=3B>=3B section 2.2.4.

>=3B I think you need to change one of 2 =
sections.
= --_c426dc20-4d7d-4de6-896b-42c9791e8ed9_-- From cewcathar@hotmail.com Sun Apr 12 07:01:33 2009 Return-Path: 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 5D80C3A6961 for ; Sun, 12 Apr 2009 07:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_05=-1.11, HTML_MESSAGE=0.001] 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 cMme-kA1EvKi for ; Sun, 12 Apr 2009 07:01:32 -0700 (PDT) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by core3.amsl.com (Postfix) with ESMTP id DAEC23A6946 for ; Sun, 12 Apr 2009 07:01:31 -0700 (PDT) Received: from BLU109-W32 ([65.55.116.72]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Apr 2009 07:02:42 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_2bc987fc-e645-40e3-b60d-9af357928c66_" X-Originating-IP: [70.88.11.82] From: CE Whitehead To: Date: Sun, 12 Apr 2009 10:02:41 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Apr 2009 14:02:42.0004 (UTC) FILETIME=[58AD8940:01C9BB77] Subject: Re: [Ltru] Issue #46 (AD comment 13) MAY -> can in section 4.6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 14:01:33 -0000 --_2bc987fc-e645-40e3-b60d-9af357928c66_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We had a similar discussion and changed another misused "MAY" to "can" (I = see it as a similar discussion because it involved the use of a keyword whe= re a keyword was not what was needed=3B and the intendend meaning was very = similar): http://www.ietf.org/mail-archive/web/ltru/current/msg12163.html http://www.ietf.org/mail-archive/web/ltru/current/msg12041.html It makes sense to change this one too=2C and there seems to be no disagreem= ent. --C. E. Whitehead cewcathar@hotmail.com From: "Martin J. D=FCrst" Date: Sun=2C 12 Apr 2009 19:17:45 +0900 +1 (hats off). Regards=2C Martin. On 2009/04/12 9:52=2C Mark Davis wrote: --_2bc987fc-e645-40e3-b60d-9af357928c66_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We had a similar discussion and changed another misused "MAY" to "can" = =3B (I see it as a similar discussion because it involved the use of a keyw= ord where a keyword was not what was needed=3B and the intendend meaning wa= s very similar):
http://www.ietf.org/mail-archive/web/ltru/current/msg12= 163.html
http://www.ietf.org/mail-archive/web/ltru/current/msg12041.html=


It makes sense to change this one too=2C and there seems to be = no disagreement.

--C. E. Whitehead
cewcathar@hotmail.com
From: "Martin J. D=FCrst" <=3Bduerst at it.aoyama.ac.jp>=3B

Date: Su= n=2C 12 Apr 2009 19:17:45 +0900

+1 (hats off).   Regards=2C   Martin.

On 2009/04/12 9:52=2C Mar=
k Davis wrote:

= --_2bc987fc-e645-40e3-b60d-9af357928c66_-- From dzo@bisharat.net Sun Apr 12 09:00:17 2009 Return-Path: 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 207C33A6C0E for ; Sun, 12 Apr 2009 09:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 0-VCb1qMRwOU for ; Sun, 12 Apr 2009 09:00:15 -0700 (PDT) Received: from 113166-www.kabissa.org (113166.kabissa.org [72.32.199.201]) by core3.amsl.com (Postfix) with ESMTP id 9FAAC3A68A5 for ; Sun, 12 Apr 2009 09:00:12 -0700 (PDT) Received: (qmail 30614 invoked from network); 12 Apr 2009 11:01:21 -0500 Received: from wsip-70-168-133-136.dc.dc.cox.net (HELO LENOVOB85F541E) (70.168.133.136) by 72.32.229.137 with SMTP; 12 Apr 2009 11:01:21 -0500 From: "Don Osborn" To: "'Peter Constable'" , "'Phillips, Addison'" , "'LTRU Working Group'" , "'IETF Languages Discussion'" References: <011e01c9b8a3$58ab9670$0a02c350$@net> <4D25F22093241741BC1D0EEBC2DBB1DA019F40EC70@EX-SEA5-D.ant.amazon.com> In-Reply-To: Date: Sun, 12 Apr 2009 12:01:14 -0400 Message-ID: <044101c9bb87$e8beb080$ba3c1180$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0442_01C9BB66.61AD1080" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acm4o1fcV19UCBEISBqf9yM+k3MrCAACY5+QAASS88AALR3NsA== Content-Language: en-us Subject: Re: [Ltru] How to handle macrolanguage when no code? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 16:00:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0442_01C9BB66.61AD1080 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks to all who replied on this question with suggestions, additional = questions, and pointers. =20 I will try (to find the time) to get an answer from BBC on their = approach and intentions, and also to get some feedback from someone = familiar with Kinyarwanda and Kirundi. This sort of situation is one = that I think is potential with a number of languages (per some past = threads), and that in such cases, the idea of a clear-cut single = language definition and/or audience for page content may not hold. More = information on such situations is will certainly become available as = more web content in diverse languages is created. =20 As for requesting macrolanguage codes, that is another level, but = obviously one to keep in mind. I think it is viable in many = circumstances, but in others it may be difficult to make the case. The = ad hoc way that ISO 639 evolved, however, means that there are similar = cases of related tongues that are sometimes given a common code = (interpreted after the fact as macrolanguage) and sometimes not. I = think that developments such as more web content in diverse languages = and efforts such as the locales sub-project of ANLoc (African Network = for Localisation) have the potential to highlight such issues.=20 =20 Thanks again and all the best. =20 Don =20 =20 From: Peter Constable [mailto:petercon@microsoft.com]=20 Sent: Wednesday, April 08, 2009 11:12 PM To: Phillips, Addison; Don Osborn; 'LTRU Working Group'; 'IETF Languages = Discussion' Subject: RE: [Ltru] How to handle macrolanguage when no code? =20 If it is content in one linguistic variety and crafted to serve two = audiences deemed in 639-3 to be distinct languages, then that strikes me = as a potential macrolanguage scenario.=20 =20 One key question is how narrow a scope of content is needed and how much = deliberate effort is needed to craft something like that. For instance, = a document consisting of =E2=80=9CPapa!=E2=80=9D can serve many = different audiences, but that is solely because the scope of content is = so constrained, and for that reason the bar is not met for a = macrolanguage. But if it=E2=80=99s easy for a content provider to come = up with content that serves both, then that=E2=80=99s interesting. =20 Another key question is why that content is functional for both = audiences. Is it because it is expressed in a variety that can really be = considered common, or is it because it=E2=80=99s actually in language A = and 90% of speakers in language B are functionally bilingual in A? Does = the common-identify label reflect actual linguistic commonality, or is = it a logistic tool used in the repository to reflect merely a dual = tasking? =20 =20 Some thoughts. Discuss it with the 639-3 RA. =20 =20 Peter =20 From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of = Phillips, Addison Sent: Wednesday, April 08, 2009 5:53 PM To: Don Osborn; 'LTRU Working Group'; 'IETF Languages Discussion' Subject: Re: [Ltru] How to handle macrolanguage when no code? =20 HTML certainly allows you to declare that some content is applicable to = more than one language audience. See: =20 http://www.w3.org/TR/i18n-html-tech-lang/#ri20040728.121358444 =20 Otherwise, John Cowan=E2=80=99s advice seems appropriate=E2=80=A6 ISO = 639-3 or ISO 639-5 would be your next stop. Note that macrolanguages are = sometimes problematical, so you might also consider a collection code = instead. =20 Addison Phillips Globalization Architect -- Lab126 =20 Internationalization is not a feature. It is an architecture. =20 From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of = Don Osborn Sent: Wednesday, April 08, 2009 4:40 PM To: 'LTRU Working Group'; 'IETF Languages Discussion' Subject: [Ltru] How to handle macrolanguage when no code? =20 In looking at the BBC website's offerings in African languages, one = notes that they have grouped Kinyarwanda and Kirundi together under = http://www.bbc.co.uk/greatlakes/ . This makes sense from a linguistic = point of view since as I understand it, the two languages are almost the = same. When looking at the view (page) source, one notes that they use = lang=3D"rw" (for Kinyarwanda). It may be that the pages I checked are = properly Kinyarwanda and an expert would know that they are not Kirundi = (rn), but it is in any event true that there is no code element to cover = both languages. =20 I'm curious if there is any other recommended way to handle such a = situation where web content may be deliberately and easily designed to = cover more than one language as defined by ISO 639 when there is not = currently any macrolanguage code for them. Could one for example define = a whole page as having two languages? E.g., something like lang=3D"rw, = rn"? =20 Thanks in advance for any feedback. =20 Don =20 =20 ------=_NextPart_000_0442_01C9BB66.61AD1080 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks to all who = replied on this question with suggestions, additional questions, and = pointers.

 

I will try (to find = the time) to get an answer from BBC on their approach and intentions, and also to get = some feedback from someone familiar with Kinyarwanda and Kirundi.=C2=A0 This = sort of situation is one that I think is potential with a number of languages = (per some past threads), and that in such cases, the idea of a clear-cut single = language definition and/or audience for page content may not hold. More = information on such situations is will certainly become available as more web content = in diverse languages is created.

 

As for requesting = macrolanguage codes, that is another level, but obviously one to keep in mind. I think = it is viable in many circumstances, but in others it may be difficult to make = the case. The ad hoc way that ISO 639 evolved, however, means that there are = similar cases of related tongues that are sometimes given a common code = (interpreted after the fact as macrolanguage) and sometimes not. =C2=A0I think that = developments such as more web content in diverse languages and efforts such as the = locales sub-project of ANLoc (African Network for Localisation) have the = potential to highlight such issues.

 

Thanks again and all = the best.

 

Don

=C2=A0

 

From:= Peter = Constable [mailto:petercon@microsoft.com]
Sent: Wednesday, April 08, 2009 11:12 PM
To: Phillips, Addison; Don Osborn; 'LTRU Working Group'; 'IETF = Languages Discussion'
Subject: RE: [Ltru] How to handle macrolanguage when no = code?

 

If it is content in = one linguistic variety and crafted to serve two audiences deemed in 639-3 to = be distinct languages, then that strikes me as a potential macrolanguage = scenario.

 

One key question is = how narrow a scope of content is needed and how much deliberate effort is needed to = craft something like that. For instance, a document consisting of = =E2=80=9CPapa!=E2=80=9D can serve many different audiences, but that is solely because the scope of = content is so constrained, and for that reason the bar is not met for a macrolanguage. = But if it=E2=80=99s easy for a content provider to come up with content that = serves both, then that=E2=80=99s interesting.

 

Another key question = is why that content is functional for both audiences. Is it because it is expressed = in a variety that can really be considered common, or is it because = it=E2=80=99s actually in language A and 90% of speakers in language B are functionally bilingual = in A? Does the common-identify label reflect actual linguistic commonality, or = is it a logistic tool used in the repository to reflect merely a dual = tasking?

 

 

Some thoughts. = Discuss it with the 639-3 RA.

 

 

Peter

 

From:= ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of = Phillips, Addison
Sent: Wednesday, April 08, 2009 5:53 PM
To: Don Osborn; 'LTRU Working Group'; 'IETF Languages = Discussion'
Subject: Re: [Ltru] How to handle macrolanguage when no = code?

 

HTML certainly allows = you to declare that some content is applicable to more than one language = audience. See:

 

   h= ttp://www.w3.org/TR/i18n-html-tech-lang/#ri20040728.121358444

 

Otherwise, John = Cowan=E2=80=99s advice seems appropriate=E2=80=A6 ISO 639-3 or ISO 639-5 would be your next = stop. Note that macrolanguages are sometimes problematical, so you might also consider a collection code instead.

 

Addison Phillips

Globalization Architect -- Lab126

 

Internationalization is not a = feature.

It is an architecture.

 

From:= = ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Don Osborn
Sent: Wednesday, April 08, 2009 4:40 PM
To: 'LTRU Working Group'; 'IETF Languages Discussion'
Subject: [Ltru] How to handle macrolanguage when no = code?

 

In looking at the BBC website's offerings in = African languages, one notes that they have grouped Kinyarwanda and Kirundi = together under http://www.bbc.co.uk/greatlakes= /  . This makes sense from a linguistic point of view since as I understand = it, the two languages are almost the same. When looking at the view (page) = source, one notes that they use lang=3D"rw" (for Kinyarwanda). It may = be that the pages I checked are properly Kinyarwanda and an expert would know = that they are not Kirundi (rn), but it is in any event true that there is no code = element to cover both languages.

 

I'm curious if there is any other recommended way = to handle such a situation where web content may be deliberately and easily = designed to cover more than one language as defined by ISO 639 when there is not currently = any macrolanguage code for them. Could one for example define a whole page = as having two languages? E.g., something like lang=3D"rw, = rn"?

 

Thanks in advance for any feedback.

 

Don

 

 

------=_NextPart_000_0442_01C9BB66.61AD1080-- From doug@ewellic.org Sun Apr 12 09:02:06 2009 Return-Path: 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 7173D3A6B67 for ; Sun, 12 Apr 2009 09:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 34xomqm5QQ-i for ; Sun, 12 Apr 2009 09:02:05 -0700 (PDT) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id 81B3D3A6887 for ; Sun, 12 Apr 2009 09:02:05 -0700 (PDT) Received: (qmail 5401 invoked from network); 12 Apr 2009 16:03:15 -0000 Received: from unknown (67.166.27.148) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 12 Apr 2009 16:03:15 -0000 Message-ID: <3CBFFC58FC484DC2A801F307AECCA286@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 12 Apr 2009 10:03:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 16:02:06 -0000 Alexey Melnikov wrote: >> Before forwarding any registration to IANA, the Language Subtag >> Reviewer MUST ensure that all requirements in this document are met. > > (Pedantic) This still means that the Reviewer might violate the SHOULD > while complying with the MUST. The SHOULD applies to the original requester; the MUST applies to the LSR. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From mark.edward.davis@gmail.com Sun Apr 12 09:34:58 2009 Return-Path: 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 531333A6C09 for ; Sun, 12 Apr 2009 09:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 yQPm2O-xaeHL for ; Sun, 12 Apr 2009 09:34:56 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 9FD2D3A6BE4 for ; Sun, 12 Apr 2009 09:34:56 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1757113wfg.31 for ; Sun, 12 Apr 2009 09:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=624DY4jHIYcyyYHWmMgWXP5BY4eHVxJeC0B/lBgVIYE=; b=qk8TzNEcJ/m5MUQ3Gi5JlaZF4Rymqt2CKfd9f9CSL7oZUKelJoDQeuDIYWi3oB7+h5 pMz4uH80FZbrYVnTKFNMuoQkJnIxvtacKm2Siqe1ketjhSaIcHhNdtVz5dDLCxdiZuOt We4/urdpO6LjOtN2o5i/IrxaehWmmoVZHWKf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=c7gsmSZUIUyqH3V5dAUFHiQRGYe3UnQzC94nHOEl6jzNxS+VJHegFsAB+2iU3sU82k gy/CGCpE3s3VF8Ngvd4F5MzomE8hgJYdNkXHO6UckWe81ZMwDYN9z0YsQb0tt8wwYTjh L4ai3R+toSzG9ncHyqq0+/EAPvwjkNgyyb2YU= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.230.11 with SMTP id c11mr2250502wfh.305.1239554166942; Sun, 12 Apr 2009 09:36:06 -0700 (PDT) In-Reply-To: <49E1BF37.5080503@it.aoyama.ac.jp> References: <49E04FF4.1040804@isode.com> <004701c9badf$b4e5c440$6801a8c0@oemcomputer> <49E0FA8C.2060105@isode.com> <49E1BF37.5080503@it.aoyama.ac.jp> Date: Sun, 12 Apr 2009 09:36:06 -0700 X-Google-Sender-Auth: 8d92cf14550ca5da Message-ID: <30b660a20904120936k60265201ja0f3415f4777c9ec@mail.gmail.com> From: Mark Davis To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=000e0cd2301accebdf04675e31f9 Cc: Alexey Melnikov , LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 16:34:58 -0000 --000e0cd2301accebdf04675e31f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks; I'd forgotten that the Reviewer has a MUST further down. Given that= , a SHOULD is fine for the submitter. Mark On Sun, Apr 12, 2009 at 03:15, "Martin J. D=C3=BCrst" wrote: > On 2009/04/12 5:16, Alexey Melnikov wrote: > >> Randy Presuhn wrote: >> > > From: "Alexey Melnikov" >>>> >>> > 8). In Section 3.5: >>>> >>>> The fields in the "Record Requested" section SHOULD follow the >>>>> requirements in Section 3.1. >>>>> >>>>> What are the reasons not to follow requirements in Section 3.1? >>>> (I.e. why is SHOULD used instead of MUST?) >>>> >>> > I think the idea was to allow the language subtag reviewer to consider >>> requests that followed the spirit, if not the letter of the syntax. Sin= ce >>> the LSR is not an automated process, and we do not want to introduce >>> artificial barriers to those needing language subtags, a little >>> flexibility >>> is desirable. Consequently, I think the SHOULD is ok - it's operational >>> advice, and failure to follow it to the letter won't necessarily cause >>> any >>> problems at all. >>> >> > I agree with Randy and Doug that this should stay a SHOULD. If we view th= is > as a protocol between the submitter and the reviewer(s)/list, a MUST is n= ot > appropriate because interoperability is possible otherwise, and because > there might be good reasons (e.g. the submitter being an expert for a > specific language, but not an expert in reading RFCs) to not be able to > follow every last detail. > > I understand and agree with the desire to be flexible. >> However my understanding is that the request sent to IANA must be in the >> correct form. Maybe you should clarify that. >> > > That's already done, a bit lower (currently on the same page, at the > bottom, although that might change): > > Before forwarding any registration to IANA, the Language Subtag > Reviewer MUST ensure that all requirements in this document are met. > This includes ensuring that values in the 'Subtag' field match case > according to the description in Section 3.1.4 and that 'Description' > fields are unique for the given record type as described in > > Section 3.1.5. The Reviewer MUST also ensure that an appropriate > File-Date record is included in the request, to assist IANA when > updating the registry (see Section 5.1). > > I don't think we need more; it's a fate of long and complicated documents > that not everything is said in every place where a reader might look for = it. > > Regards, Martin. > -- > #-# Martin J. D=C3=BCrst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --000e0cd2301accebdf04675e31f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks; I'd forgotten that the Reviewer has a MUST further down. Given = that, a SHOULD is fine for the submitter.

Mark


On Sun, Apr 12, 2009 at 03:15, "Mar= tin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> wrote:
On 2009/04/12 5:16, Alexey Melnikov wrote:

Randy Presuhn wrote:

From: "Alexey Melnikov" <alexey.melnikov@isode.com>

8). In Section 3.5:

The fields in the "Record Requested" section SHOULD follow the requirements in Section 3.1.

What are the reasons not to follow requirements in Section 3.1?
(I.e. why is SHOULD used instead of MUST?)

I think the idea was to allow the language subtag reviewer to consider
requests that followed the spirit, if not the letter of the syntax. Since the LSR is not an automated process, and we do not want to introduce
artificial barriers to those needing language subtags, a little
flexibility
is desirable. Consequently, I think the SHOULD is ok - it's operational=
advice, and failure to follow it to the letter won't necessarily cause<= br> any
problems at all.

I agree with Randy and Doug that this should stay a SHOULD. If we view this= as a protocol between the submitter and the reviewer(s)/list, a MUST is no= t appropriate because interoperability is possible otherwise, and because t= here might be good reasons (e.g. the submitter being an expert for a specif= ic language, but not an expert in reading RFCs) to not be able to follow ev= ery last detail.


I understand and agree with the desire to be flexible.
However my understanding is that the request sent to IANA must be in the correct form. Maybe you should clarify that.

That's already done, a bit lower (currently on the same page, at the bo= ttom, although that might change):

=C2=A0 Before forwarding any registration to IANA, the Language Subtag
=C2=A0 Reviewer MUST ensure that all requirements in this document are met= .
=C2=A0 This includes ensuring that values in the 'Subtag' field ma= tch case
=C2=A0 according to the description in Section 3.1.4 and that 'Descrip= tion'
=C2=A0 fields are unique for the given record type as described in

=C2=A0 Section 3.1.5. =C2=A0The Reviewer MUST also ensure that an appropri= ate
=C2=A0 File-Date record is included in the request, to assist IANA when =C2=A0 updating the registry (see Section 5.1).

I don't think we need more; it's a fate of long and complicated doc= uments that not everything is said in every place where a reader might look= for it.

Regards, =C2=A0 =C2=A0Martin.
--
#-# Martin J. D=C3=BCrst, Professor, Aoyama Gakuin University
#-# http://www.= sw.it.aoyama.ac.jp =C2=A0 mailto:duerst@it.aoyama.ac.jp

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--000e0cd2301accebdf04675e31f9-- From cowan@ccil.org Sun Apr 12 11:02:52 2009 Return-Path: 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 F3E013A68E0 for ; Sun, 12 Apr 2009 11:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 V4AyLzxy50ud for ; Sun, 12 Apr 2009 11:02:51 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id EF8DE3A68DE for ; Sun, 12 Apr 2009 11:02:50 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Lt42A-0000O4-1K; Sun, 12 Apr 2009 14:03:58 -0400 Date: Sun, 12 Apr 2009 14:03:58 -0400 To: Alexey Melnikov Message-ID: <20090412180357.GA26340@mercury.ccil.org> References: <49E04FF4.1040804@isode.com> <006701c9bae2$af887260$6801a8c0@oemcomputer> <49E0FAD4.1050803@isode.com> <49E1BF49.1030908@it.aoyama.ac.jp> <49E1C6FA.9080006@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E1C6FA.9080006@isode.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] Issue #43 (AD comment #10) section 5.1 vs 3.2 on file-date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 18:02:52 -0000 Alexey Melnikov scripsit: > It would probably have been simpler to just say that it should always > simply be the date that the file was updated, and not talk about > the dates on the record(s) being added or updated. Simpler, yes; but it has bad knock-on effects. If IANA erroneously creates a version of the Registry with a File-Date in the future (and the Official Doug has assured us that this does happen), then the next update may create a situation where the File-Date of the new version is less than the File-Date of the old version. A process that relies on the File-Date to decide whether to update its cached copy of the Registry would be deceived into assuming the old version is newer than the new version. The current algorithm is more complicated, but guarantees (provided the dates on the updated items are correct, of course) that the File-Date is monotonically increasing. I strongly object to changing the current algorithm. -- First known example of political correctness: John Cowan After Nurhachi had united all the other http://www.ccil.org/~cowan Jurchen tribes under the leadership of the cowan@ccil.org Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus. From alexey.melnikov@isode.com Sun Apr 12 11:14:12 2009 Return-Path: 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 D98B13A698C for ; Sun, 12 Apr 2009 11:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_SBL=1.551] 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 efEK-y6OPEIe for ; Sun, 12 Apr 2009 11:14:12 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BEFD83A67B7 for ; Sun, 12 Apr 2009 11:14:11 -0700 (PDT) Received: from [92.40.112.135] (92.40.112.135.sub.mbb.three.co.uk [92.40.112.135]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Apr 2009 19:15:20 +0100 Message-ID: <49E22F81.3020102@isode.com> Date: Sun, 12 Apr 2009 19:14:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John Cowan References: <49E04FF4.1040804@isode.com> <006701c9bae2$af887260$6801a8c0@oemcomputer> <49E0FAD4.1050803@isode.com> <49E1BF49.1030908@it.aoyama.ac.jp> <49E1C6FA.9080006@isode.com> <20090412180357.GA26340@mercury.ccil.org> In-Reply-To: <20090412180357.GA26340@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: Re: [Ltru] Issue #43 (AD comment #10) section 5.1 vs 3.2 on file-date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 18:14:12 -0000 John Cowan wrote: >Alexey Melnikov scripsit: > > >> It would probably have been simpler to just say that it should always >> simply be the date that the file was updated, and not talk about >> the dates on the record(s) being added or updated. >> >> >Simpler, yes; but it has bad knock-on effects. If IANA erroneously creates a version of >the Registry with a File-Date in the future (and the Official Doug has assured us >that this does happen), then the next update may create a situation where the File-Date >of the new version is less than the File-Date of the old version. A process that >relies on the File-Date to decide whether to update its cached copy of the Registry >would be deceived into assuming the old version is newer than the new version. > > If that is one of the goals, then Ok. I wish all requirements are properly documented. >The current algorithm is more complicated, but guarantees (provided the dates on the >updated items are correct, of course) that the File-Date is monotonically increasing. > >I strongly object to changing the current algorithm. > > I am not sure the current algorithm is correctly (or clearly) documented. What would be result of the algorithm in the following case: 1). Update 1 with File-Date A, such as A > I1 (where I1 is IANA File-Date before the update 1) 2). Update 2 with File-Date B, B < A ? From randy_presuhn@mindspring.com Sun Apr 12 14:33:12 2009 Return-Path: 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 020303A698C for ; Sun, 12 Apr 2009 14:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 JU6yc-r4k+Xe for ; Sun, 12 Apr 2009 14:33:11 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 403A03A680D for ; Sun, 12 Apr 2009 14:33:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EyM95CzsYuTEeVOMEW2/9OcDBwlesPctcUkW77RztqaK0pMzMoEHMCr0K+biFjrF; h=Received:Message-ID:From:To:Cc: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 [64.105.35.65] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lt7Jl-00062y-88; Sun, 12 Apr 2009 17:34:21 -0400 Message-ID: <001301c9bbb6$bce906c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" References: <49E04FF4.1040804@isode.com> <004701c9badf$b4e5c440$6801a8c0@oemcomputer> <49E0FA8C.2060105@isode.com> <49E1BF37.5080503@it.aoyama.ac.jp> <49E1E3DC.6050508@isode.com> Date: Sun, 12 Apr 2009 14:36:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17399d69e2c21aaac2de61206764bcb246a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.65 Cc: LTRU Working Group Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 21:33:12 -0000 Hi - > From: "Alexey Melnikov" > To: "Martin J. Dürst" > Cc: "Randy Presuhn" ; "LTRU Working Group" > Sent: Sunday, April 12, 2009 5:51 AM > Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST ... > > Before forwarding any registration to IANA, the Language Subtag > > Reviewer MUST ensure that all requirements in this document are met. > > (Pedantic) This still means that the Reviewer might violate the SHOULD > while complying with the MUST. ... The key point is that the SHOULD applies to the submitter; the MUST applies to the reviewer. Randy From doug@ewellic.org Sun Apr 12 18:49:02 2009 Return-Path: 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 763003A6C90 for ; Sun, 12 Apr 2009 18:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 ILSQ3bp6ubyq for ; Sun, 12 Apr 2009 18:49:01 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 60EEA3A6BBC for ; Sun, 12 Apr 2009 18:49:01 -0700 (PDT) Received: (qmail 22949 invoked from network); 13 Apr 2009 01:50:11 -0000 Received: from unknown (67.166.27.148) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 13 Apr 2009 01:50:11 -0000 Message-ID: <0B5DE691021E45F38A8FBAA46BBFCD96@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 12 Apr 2009 19:50:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Issue #43 (AD comment #10) section 5.1 vs 3.2 on file-date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 01:49:02 -0000 John Cowan wrote: > If IANA erroneously creates a version of the Registry with a File-Date > in the future (and the Official Doug has assured us that this does > happen), then the next update may create a situation where the > File-Date of the new version is less than the File-Date of the old > version. I fear there may have been a misunderstanding, probably on my part in interpreting the original concern. IANA has never issued a Registry with a File-Date in the future -- that is, later than the actual date of issue. OTOH, they have often issued a Registry with a File-Date later than the Added date of any of the tags and subtags it contains. This happens when they insert new subtag records with an Added date of X, but don't publish the new file until Y. Furthermore, as I should have pointed out before, it is *supposed* to happen when there is a round of changes that includes no new subtags, only modifications to existing subtags (because there is no "Modified" date). This might happen, for example, when the only change is to add or delete Suppress-Script fields. The latest round of changes instigated by ISO 639-2 name changes would have been like this, if we also hadn't deferred 'Zinh' until that round. There was an error once (2007-12-05) where IANA forgot to update the File-Date at all, leaving it at 2007-11-06, the date of the previous update. This was spotted quickly and corrected the next day. Michael and I do attempt to batch the IANA requests together so they do not receive some today, some tomorrow, some a few days after that, because this would surely lead to confusion on the part of both IANA and users. The two-week review periods, often seen as unnecessary in the case of uncontroversial or mechanical changes, do help us coordinate this. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From wwwrun@core3.amsl.com Mon Apr 13 05:25:53 2009 Return-Path: X-Original-To: ltru@ietf.org Delivered-To: ltru@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DC72328C0F8; Mon, 13 Apr 2009 05:25:53 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090413122553.DC72328C0F8@core3.amsl.com> Date: Mon, 13 Apr 2009 05:25:53 -0700 (PDT) Cc: ltru@ietf.org Subject: [Ltru] Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 12:25:54 -0000 The IESG has received a request from the Language Tag Registry Update WG (ltru) to consider the following document: - 'Tags for Identifying Languages ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-21.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15152&rfc_flag=0 From randy_presuhn@mindspring.com Thu Apr 16 14:38:21 2009 Return-Path: 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 53BEE3A6AC1 for ; Thu, 16 Apr 2009 14:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 zi67u-CKd8PN for ; Thu, 16 Apr 2009 14:38:20 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 84E1F3A68C0 for ; Thu, 16 Apr 2009 14:38:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SW+a+8nOCtxtu4Ow0KWks9yiBg3j23W57MKSRJ73ivUWkTEb5nuYVtL6NgbeDdfl; h=Received:Message-ID:From:To: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.165.6.224] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LuZIz-0005No-DA for ltru@ietf.org; Thu, 16 Apr 2009 17:39:33 -0400 Message-ID: <000401c9bedc$22efe740$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 16 Apr 2009 14:41:43 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1733fe77c0bd3d3fd24d04ae2426e49262f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.224 Subject: [Ltru] Fw: Review of draft-ietf-ltru-4645bis-10 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:38:21 -0000 Hi - Forwarded for your information. Randy ----- Original Message ----- > From: "Sean Turner" > To: "secdir" ; ; ; "Randy Presuhn" ; "Martin Duerst" > Sent: Thursday, April 16, 2009 2:27 PM > Subject: Review of draft-ietf-ltru-4645bis-10 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > My heart sank when I was assigned this document because it's 950 pages, > but 940ish of the pages are a registry ;) > > This document provides procedures to update the IANA Language Subtag > Registry. The Subtags are copied from ISO documents. I can't think of > any security concerns for the procedures themselves. The Security > Considerations section points to draft-ietf-ltru-4646bis-21.txt for any > issue with tags themselves. > > Assuming the copy from the ISO document was exact, I support this > document becoming an RFC > > spt From randy_presuhn@mindspring.com Thu Apr 16 20:56:06 2009 Return-Path: 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 3481B3A67F3 for ; Thu, 16 Apr 2009 20:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 8it8yuqDAvB0 for ; Thu, 16 Apr 2009 20:56:05 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 1D2253A6BB8 for ; Thu, 16 Apr 2009 20:56:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Egtf3Kxejfnrekq+QMTiuiie54WV6ME/qSMK3qFtiHuaC9zSEiq9yB/v0ISu1oKC; h=Received:Message-ID:From:To: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 [64.105.34.12] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LufCY-0006uS-5Y for ltru@ietf.org; Thu, 16 Apr 2009 23:57:18 -0400 Message-ID: <000601c9bf10$e83c07c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 16 Apr 2009 20:59:28 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173599db26a725ff41992350ea62f377b17350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.12 Subject: [Ltru] Fw: Review of draft-ietf-ltru-4645bis-10 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 03:56:06 -0000 Hi - Forwarded for your information. Randy ----- Original Message ----- > From: "Doug Ewell" > To: "Sean Turner" ; "secdir" ; ; "Randy Presuhn" ; "Martin Duerst" > Sent: Thursday, April 16, 2009 8:50 PM > Subject: Re: Review of draft-ietf-ltru-4645bis-10 > > Sean Turner wrote: > > > My heart sank when I was assigned this document because it's 950 > > pages, but 940ish of the pages are a registry ;) > > > > This document provides procedures to update the IANA Language Subtag > > Registry. The Subtags are copied from ISO documents. > > Not all of them, and not exactly. They are adapted from ISO documents > and from the existing Registry according to the process described in the > other 10ish pages. > > > I can't think of any security concerns for the procedures themselves. > > The Security Considerations section points to > > draft-ietf-ltru-4646bis-21.txt for any issue with tags themselves. > > > > Assuming the copy from the ISO document was exact, I support this > > document becoming an RFC > > I'm glad to see the support. However, I'd like to be sure it is for the > right reasons. Other reviewers who read this and assume the Registry is > copied exactly from ISO sources may balk when they find that it is not > exact. The text explains everything. > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > Editor, draft-ietf-ltru-4645bis > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ > From randy_presuhn@mindspring.com Mon Apr 27 11:04:58 2009 Return-Path: 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 C80173A6FC1 for ; Mon, 27 Apr 2009 11:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_50=0.001] 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 SYDTzlI2RXbe for ; Mon, 27 Apr 2009 11:04:58 -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 E51573A6F31 for ; Mon, 27 Apr 2009 11:04:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LpzbHgpxkHoK7oqdRr9jUje4au3PC7TfAtx/LEukbmTjZDMvFmAk+CRoj88sqE0U; h=Received:Message-ID:From:To: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.165.6.199] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LyVDe-00005j-Ix for ltru@ietf.org; Mon, 27 Apr 2009 14:06:18 -0400 Message-ID: <001601c9c763$3bedcde0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 27 Apr 2009 11:08:56 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968183b6d4b4b40a694f68644eadc29b5bd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.199 Subject: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:04:58 -0000 Hi - Forwarded for your information. Martin (as document shepherd) and the editors will work through the issue list at http://trac.tools.ietf.org/wg/ltru/trac/report/1 to make sure all the issues are resolved and to produce an updated document. Randy > From: "Alexey Melnikov" > To: "Randy Presuhn" > Cc: "Martin Duerst" > Sent: Monday, April 27, 2009 4:32 AM > Subject: Re: [Ltru] Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP > > Randy Presuhn wrote: > > >Hi - > > > > > >>From: "The IESG" > >>To: "IETF-Announce" > >>Cc: > >>Sent: Monday, April 13, 2009 5:25 AM > >>Subject: [Ltru] Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP > >> > >>The IESG has received a request from the Language Tag Registry Update WG > >>(ltru) to consider the following document: > >> > >>- 'Tags for Identifying Languages ' > >> as a BCP > >> > >> > >... > > > >We have a bunch of minor issues resulting from the AD review > >in the tracker at http://trac.tools.ietf.org/wg/ltru/trac/report/1 > > > >At least a few of them have been resolved in ways that will > >result in (minor) changes to the text. How do you want to > >handle the logistics of folding these in? > > > > > I think I need to see a new revision. If a new draft is posted before > the end of this Thursday (April 30th) [and it addresses my concerns, of > course], then both LTRU documents can be on May 5th IESG telechat. > From addison@amazon.com Mon Apr 27 11:17:28 2009 Return-Path: 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 997493A6B01 for ; Mon, 27 Apr 2009 11:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 Q1GJX2lWoOnC for ; Mon, 27 Apr 2009 11:17:27 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 96E4F3A6ACC for ; Mon, 27 Apr 2009 11:17:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,255,1238976000"; d="scan'208";a="177574746" Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2009 18:18:48 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3RIIlmF009579 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 27 Apr 2009 18:18:47 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Mon, 27 Apr 2009 11:18:46 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Mon, 27 Apr 2009 11:18:45 -0700 Thread-Topic: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP Thread-Index: AcnHYt9eg48vjVlcTVCWNxdkm/XG1gAAaOuA Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FCA51E4@EX-SEA5-D.ant.amazon.com> References: <001601c9c763$3bedcde0$6801a8c0@oemcomputer> In-Reply-To: <001601c9c763$3bedcde0$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:17:28 -0000 SGkgUmFuZHksDQoNClRoYW5rcyBmb3IgdGhpcy4gSSBsb29rIGZvcndhcmQgdG8gcHJvZHVjaW5n IHRoZSBuZWNlc3NhcnkgZHJhZnQgdGhpcyB3ZWVrLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUGhp bGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJbnRlcm5hdGlvbmFs aXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIFJhbmR5IFByZXN1 aG4NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAyNywgMjAwOSAxMTowOSBBTQ0KPiBUbzogTFRSVSBX b3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFtMdHJ1XSBGdzogTGFzdCBDYWxsOiBkcmFmdC1pZXRm LWx0cnUtNDY0NmJpcyAoVGFncyBmb3INCj4gSWRlbnRpZnlpbmcgTGFuZ3VhZ2VzKSB0byBCQ1AN Cj4gDQo+IEhpIC0NCj4gDQo+IEZvcndhcmRlZCBmb3IgeW91ciBpbmZvcm1hdGlvbi4NCj4gDQo+ IE1hcnRpbiAoYXMgZG9jdW1lbnQgc2hlcGhlcmQpIGFuZCB0aGUgZWRpdG9ycyB3aWxsDQo+IHdv cmsgdGhyb3VnaCB0aGUgaXNzdWUgbGlzdCBhdA0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy93Zy9sdHJ1L3RyYWMvcmVwb3J0LzENCj4gdG8gbWFrZSBzdXJlIGFsbCB0aGUgaXNzdWVzIGFy ZSByZXNvbHZlZCBhbmQgdG8gcHJvZHVjZSBhbiB1cGRhdGVkDQo+IGRvY3VtZW50Lg0KPiANCj4g UmFuZHkNCj4gDQo+ID4gRnJvbTogIkFsZXhleSBNZWxuaWtvdiIgPGFsZXhleS5tZWxuaWtvdkBp c29kZS5jb20+DQo+ID4gVG86ICJSYW5keSBQcmVzdWhuIiA8cmFuZHlfcHJlc3VobkBtaW5kc3By aW5nLmNvbT4NCj4gPiBDYzogIk1hcnRpbiBEdWVyc3QiIDxkdWVyc3RAaXQuYW95YW1hLmFjLmpw Pg0KPiA+IFNlbnQ6IE1vbmRheSwgQXByaWwgMjcsIDIwMDkgNDozMiBBTQ0KPiA+IFN1YmplY3Q6 IFJlOiBbTHRydV0gTGFzdCBDYWxsOiBkcmFmdC1pZXRmLWx0cnUtNDY0NmJpcyAoVGFncyBmb3IN Cj4gSWRlbnRpZnlpbmcgTGFuZ3VhZ2VzKSB0byBCQ1ANCj4gPg0KPiA+IFJhbmR5IFByZXN1aG4g d3JvdGU6DQo+ID4NCj4gPiA+SGkgLQ0KPiA+ID4NCj4gPiA+DQo+ID4gPj5Gcm9tOiAiVGhlIElF U0ciIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4NCj4gPiA+PlRvOiAiSUVURi1Bbm5vdW5jZSIg PGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+ID4gPj5DYzogPGx0cnVAaWV0Zi5vcmc+DQo+ID4g Pj5TZW50OiBNb25kYXksIEFwcmlsIDEzLCAyMDA5IDU6MjUgQU0NCj4gPiA+PlN1YmplY3Q6IFtM dHJ1XSBMYXN0IENhbGw6IGRyYWZ0LWlldGYtbHRydS00NjQ2YmlzIChUYWdzIGZvcg0KPiBJZGVu dGlmeWluZyBMYW5ndWFnZXMpIHRvIEJDUA0KPiA+ID4+DQo+ID4gPj5UaGUgSUVTRyBoYXMgcmVj ZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIExhbmd1YWdlIFRhZyBSZWdpc3RyeQ0KPiBVcGRhdGUg V0cNCj4gPiA+PihsdHJ1KSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiA+ ID4+DQo+ID4gPj4tICdUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMgJw0KPiA+ID4+ICAg PGRyYWZ0LWlldGYtbHRydS00NjQ2YmlzLTIxLnR4dD4gYXMgYSBCQ1ANCj4gPiA+Pg0KPiA+ID4+ DQo+ID4gPi4uLg0KPiA+ID4NCj4gPiA+V2UgaGF2ZSBhIGJ1bmNoIG9mIG1pbm9yIGlzc3VlcyBy ZXN1bHRpbmcgZnJvbSB0aGUgQUQgcmV2aWV3DQo+ID4gPmluIHRoZSB0cmFja2VyIGF0DQo+IGh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2x0cnUvdHJhYy9yZXBvcnQvMQ0KPiA+ID4NCj4g PiA+QXQgbGVhc3QgYSBmZXcgb2YgdGhlbSBoYXZlIGJlZW4gcmVzb2x2ZWQgaW4gd2F5cyB0aGF0 IHdpbGwNCj4gPiA+cmVzdWx0IGluIChtaW5vcikgY2hhbmdlcyB0byB0aGUgdGV4dC4gIEhvdyBk byB5b3Ugd2FudCB0bw0KPiA+ID5oYW5kbGUgdGhlIGxvZ2lzdGljcyBvZiBmb2xkaW5nIHRoZXNl IGluPw0KPiA+ID4NCj4gPiA+DQo+ID4gSSB0aGluayBJIG5lZWQgdG8gc2VlIGEgbmV3IHJldmlz aW9uLiBJZiBhIG5ldyBkcmFmdCBpcyBwb3N0ZWQNCj4gYmVmb3JlDQo+ID4gdGhlIGVuZCBvZiB0 aGlzIFRodXJzZGF5IChBcHJpbCAzMHRoKSBbYW5kIGl0IGFkZHJlc3NlcyBteQ0KPiBjb25jZXJu cywgb2YNCj4gPiBjb3Vyc2VdLCB0aGVuIGJvdGggTFRSVSBkb2N1bWVudHMgY2FuIGJlIG9uIE1h eSA1dGggSUVTRyB0ZWxlY2hhdC4NCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== From pete.mccann@motorola.com Mon Apr 27 09:18:25 2009 Return-Path: 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 7BB3E28C0EB; Mon, 27 Apr 2009 09:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.702 X-Spam-Level: X-Spam-Status: No, score=-5.702 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_MED=-4] 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 Nbgn1QRcp9Sy; Mon, 27 Apr 2009 09:18:24 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 4A6B83A6A8B; Mon, 27 Apr 2009 09:18:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1240849181!17249236!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 18564 invoked from network); 27 Apr 2009 16:19:42 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-12.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Apr 2009 16:19:42 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n3RGJft6023870; Mon, 27 Apr 2009 09:19:41 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n3RGJfCE019782; Mon, 27 Apr 2009 11:19:41 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n3RGJexh019777; Mon, 27 Apr 2009 11:19:41 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 12:19:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcnHU+om3D3EL/wHR0yHYLJv5Yyz9A== From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 27 Apr 2009 21:29:58 -0700 Cc: ltru-ads@tools.ietf.org, ltru@ietf.org, ltru-chairs@tools.ietf.org Subject: [Ltru] (no subject) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:18:25 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Sorry this is a few days late. Document: draft-ietf-ltru-4645bis-10 Reviewer: Pete McCann Review Date: 27 April 2009 IETF LC End Date: 23 April 2009 IESG Telechat date: unknown=20 Summary: Ready for publication as an Informational RFC. Major issues: none Minor issues: none Nits/editorial comments: idnits complains: -- Obsolete informational reference (is this intentional?): RFC 1766 (Obsoleted by RFC 3066, RFC 3282) -- Obsolete informational reference (is this intentional?): RFC 3066 (Obsoleted by RFC 4646, RFC 4647) From randy_presuhn@mindspring.com Mon Apr 27 21:50:05 2009 Return-Path: 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 CEA333A6781 for ; Mon, 27 Apr 2009 21:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 9fJ1h0wQ2nDj for ; Mon, 27 Apr 2009 21:50:04 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id C91193A6FDF for ; Mon, 27 Apr 2009 21:50:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZmJ4sa/R8ZrxVDi9V4Vnm+72pW8Im4cHkZKjcfkNuBZ+lVqiSJXdYQH9OdxHXFB9; h=Received:Message-ID:From:To: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 [69.3.145.249] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LyfHw-0003Hg-KW for ltru@ietf.org; Tue, 28 Apr 2009 00:51:25 -0400 Message-ID: <004c01c9c7bd$599d57c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 27 Apr 2009 21:54:00 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968d5ba98bace402248e99e908490758f40350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.249 Subject: [Ltru] Fw: 75th IETF - Working Group/BOF Scheduling X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 04:50:05 -0000 Hi - There are currently no plans for the ltru WG to meet in Stockholm. If anyone believes there is good reason for the WG to meet there, they should please post proposals for an agenda, for discussion on this mailing list. Randy ltru co-chair ----- Original Message ----- > From: "IETF Agenda" > To: "Working Group Chairs" > Cc: ; > Sent: Monday, April 27, 2009 7:56 AM > Subject: 75th IETF - Working Group/BOF Scheduling > > ----------------------------------------------------------------- > 75th IETF Stockholm, Sweden > Meeting Dates: July 26-31, 2009 > Host: .SE > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday mid-afternoon > (15:15). > > We are accepting scheduling requests for all Working Groups and BOFs > starting. The milestones and deadlines for scheduling-related activities > are as follows: > > NOTE: cutoff dates are subject to change. > > May 25, Monday - Cutoff date for requests to schedule Working Group > meetings and for preliminary BOF proposals to ADs at 17:00 PDT (24:00 > UTC/GMT). > June 8, Monday - Cutoff date for requests to Area Directors to schedule > BOFs at 17:00 PDT (24:00 UTC/GMT). > June 15, Monday - Cutoff date for Area Directors to approve BOFs at 17:00 > PDT (24:00 UTC/GMT). > June 19, Friday - Preliminary agenda published for comment. > July 1, Wednesday - Cutoff date for requests to reschedule Working Group > and BOF meetings 17:00 PDT (24:00 UTC/GMT). > July 6, Monday - Final agenda to be published. > July 15, Wednesday - Draft Working Group agendas due by 17:00 PT (24:00 > UTC/GMT). > July 20, Monday - Revised Working Group agendas due by 17:00 PT (24:00 > UTC/GMT). > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using the > "IETF Meeting Session Request Tool," a Web-based tool for submitting all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the message, > and include all of the information specified in item (4) of "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, July 15 by 17:00 PDT (24:00 > UTC/GMT). Revised Working Group agendas are due no later than Monday, > July 20 at 17:00 PDT (24:00 UTC/GMT). The proposed agenda for a BOF > session should be submitted along with your request for a session. Please > be sure to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 75 Meeting Materials" Web page is: > > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=75 > > If you are a Working Group chair, then you already have accounts on the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both tools. > If you are a BOF chair who is not also a Working Group chair, then you > will be given an account on the "IETF Meeting Materials Management Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =============================================================== > For your convenience, comprehensive information on requesting meeting > sessions at IETF 75 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted using > the "IETF Meeting Session Request Tool," a Web-based tool for submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, then > please send a message to ietf-action@ietf.org. If you are unable to use > the tool, then you may send your request via e-mail to agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please read the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request must be > approved by an Area Director. Additional sessions will be assigned, based > on availability, after Wednesday, July 1 at 17:00 PDT (24:00 UTC/GMT), the > cut-off date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance (figures from the 74th IETF meeting are > included at the end of this message): > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =============================================================== > For your convenience please find here a list of the IETF Area Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Lisa Dusseault > Alexey Melnikov > > Internet Area (int) > Jari Arkko > Ralph Droms > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Cullen Jennings > Robert Sparks > > Routing Area (rtg) > Ross Callon > Adrian Farrel > > Security Area (sec) > Pasi Eronen > Tim Polk > > Transport Area (tsv) > Lars Eggert > Magnus Westerlund > =========================================================== > 74th IETF Meeting Attendance Number > > 6ai 189 > 6lowpan NO SHEETS > 6man 138 > alto 112 > ancp 21 > apparea 92 > atoca 77 > autoconf 34 > avt 77 > avt (2nd session) 65 > behave 150 > behave (2nd session) 116 > bliss 64 > bmwg 23 > capwap 16 > ccamp 76 > ccamp (2nd session) 55 > csi 16 > dccp 18 > dhc 50 > dime 31 > dkim 46 > dnsop 90 > drinks 69 > dtnrg 44 > ecrit 80 > emu 35 > fecframe 17 > forces 20 > geopriv 68 > grow 75 > hiprg 38 > hokey 40 > httpbis 25 > idnabis 70 > idnabis (2nd session) 41 > idr 127 > intarea 207 > ipfix 32 > ippm 46 > ipsecme 44 > isms 25 > keyprov 24 > kitten 11 > krb-wg 26 > l2vpn 149 > l3vpn 48 > ledbat 30 > lisp 176 > manet 45 > mboned 37 > mediactrl 47 > mext 96 > mif 68 > mip4 35 > mipshop 57 > mmox 77 > mmusic 75 > morg 15 > mpls 144 > mpls (2nd session) 135 > msec 30 > nea 28 > netconf 39 > netext 68 > netmod 25 > netmod (2nd session) 32 > nfsv4 22 > nsis 23 > oauth 105 > opsarea 86 > opsec 24 > ospf 34 > p2prg 99 > p2psip 71 > pce 63 > pcn 24 > pim 41 > pkix 50 > pmol 27 > pre8prob 44 > pwe3 115 > radext 19 > rtgarea 122 > rmt 12 > roll 69 > rrg 106 > rtgwg 112 > saag 116 > sasl 24 > savi 60 > shara 155 > sidr 77 > sieve 17 > simple 69 > sip 126 > sip (2nd session) 117 > sipping 92 > softwire 73 > speermint 63 > storm 14 > tcpm 33 > tcpm (2nd session) 59 > tictoc 37 > tls 44 > trill 55 > tsvarea 72 > tsvwg 47 > v6ops 126 > v6ops (second session) 65 > vcarddav 18 > xcon 48 > xmpp2 86 > yam 41 From duerst@it.aoyama.ac.jp Mon Apr 27 23:04:34 2009 Return-Path: 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 2B9503A7042 for ; Mon, 27 Apr 2009 23:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 BbDECUJkxlTT for ; Mon, 27 Apr 2009 23:04:33 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 262E23A7041 for ; Mon, 27 Apr 2009 23:04:32 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n3S65qSu027933 for ; Tue, 28 Apr 2009 15:05:52 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 08de_a0b15b3e_33ba_11de_9e60_001d0969ab06; Tue, 28 Apr 2009 15:05:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:60553) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 28 Apr 2009 15:04:42 +0900 Message-ID: <49F69CAB.60407@it.aoyama.ac.jp> Date: Tue, 28 Apr 2009 15:05:31 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: "Phillips, Addison" References: <001601c9c763$3bedcde0$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FCA51E4@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FCA51E4@EX-SEA5-D.ant.amazon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group Subject: Re: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 06:04:34 -0000 Very good. Please note that part of this week and part of next is "Golden Week" here in Japan, mostly holidays. But I'll see what I can do. Regards, Martin. On 2009/04/28 3:18, Phillips, Addison wrote: > Hi Randy, > > Thanks for this. I look forward to producing the necessary draft this week. > > Addison > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > >> -----Original Message----- >> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On >> Behalf Of Randy Presuhn >> Sent: Monday, April 27, 2009 11:09 AM >> To: LTRU Working Group >> Subject: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for >> Identifying Languages) to BCP >> >> Hi - >> >> Forwarded for your information. >> >> Martin (as document shepherd) and the editors will >> work through the issue list at >> http://trac.tools.ietf.org/wg/ltru/trac/report/1 >> to make sure all the issues are resolved and to produce an updated >> document. >> >> Randy >> >>> From: "Alexey Melnikov" >>> To: "Randy Presuhn" >>> Cc: "Martin Duerst" >>> Sent: Monday, April 27, 2009 4:32 AM >>> Subject: Re: [Ltru] Last Call: draft-ietf-ltru-4646bis (Tags for >> Identifying Languages) to BCP >>> Randy Presuhn wrote: >>> >>>> Hi - >>>> >>>> >>>>> From: "The IESG" >>>>> To: "IETF-Announce" >>>>> Cc: >>>>> Sent: Monday, April 13, 2009 5:25 AM >>>>> Subject: [Ltru] Last Call: draft-ietf-ltru-4646bis (Tags for >> Identifying Languages) to BCP >>>>> The IESG has received a request from the Language Tag Registry >> Update WG >>>>> (ltru) to consider the following document: >>>>> >>>>> - 'Tags for Identifying Languages ' >>>>> as a BCP >>>>> >>>>> >>>> ... >>>> >>>> We have a bunch of minor issues resulting from the AD review >>>> in the tracker at >> http://trac.tools.ietf.org/wg/ltru/trac/report/1 >>>> At least a few of them have been resolved in ways that will >>>> result in (minor) changes to the text. How do you want to >>>> handle the logistics of folding these in? >>>> >>>> >>> I think I need to see a new revision. If a new draft is posted >> before >>> the end of this Thursday (April 30th) [and it addresses my >> concerns, of >>> course], then both LTRU documents can be on May 5th IESG telechat. >>> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Tue Apr 28 00:33:17 2009 Return-Path: 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 2B2113A707E for ; Tue, 28 Apr 2009 00:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 NoGsRNF0Q8PT for ; Tue, 28 Apr 2009 00:33:16 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 6AE183A7079 for ; Tue, 28 Apr 2009 00:33:14 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n3S6Zqc0004783 for ; Tue, 28 Apr 2009 15:35:52 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 73dd_d1e74bf6_33be_11de_b9d8_001d0969ab06; Tue, 28 Apr 2009 15:35:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:45753) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 28 Apr 2009 15:34:44 +0900 Message-ID: <49F6A3B4.4090108@it.aoyama.ac.jp> Date: Tue, 28 Apr 2009 15:35:32 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: McCann Peter-A001034 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ltru-ads@tools.ietf.org, darft-ietf-ltru-4645bis@tools.ietf.org, gen-art@ietf.org, ltru@ietf.org, ltru-chairs@tools.ietf.org Subject: [Ltru] Gen-Art review for 4645bis (was: no subject) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:33:17 -0000 Hello Peter, On 2009/04/28 1:19, McCann Peter-A001034 wrote: > I have been selected as the General Area Review Team (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Many thanks! > Please resolve these comments along with any other Last Call comments > you may receive. > > Sorry this is a few days late. > > Document: draft-ietf-ltru-4645bis-10 > Reviewer: Pete McCann > Review Date: 27 April 2009 > IETF LC End Date: 23 April 2009 > IESG Telechat date: unknown > > Summary: Ready for publication as an Informational RFC. > > Major issues: none > > Minor issues: none > > Nits/editorial comments: idnits complains: > > -- Obsolete informational reference (is this intentional?): RFC 1766 > (Obsoleted by RFC 3066, RFC 3282) > > -- Obsolete informational reference (is this intentional?): RFC 3066 > (Obsoleted by RFC 4646, RFC 4647) Both of these are intentional, and we intend to keep them. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From addison@amazon.com Tue Apr 28 07:58:00 2009 Return-Path: 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 CE71F3A70F2 for ; Tue, 28 Apr 2009 07:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.337 X-Spam-Level: X-Spam-Status: No, score=-106.337 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 o+Yf5Ixz3f4Z for ; Tue, 28 Apr 2009 07:57:58 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id 19C983A709C for ; Tue, 28 Apr 2009 07:57:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,261,1238976000"; d="scan'208";a="215465919" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2009 14:59:14 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3SExECo010885 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 28 Apr 2009 14:59:14 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Tue, 28 Apr 2009 07:59:14 -0700 From: "Phillips, Addison" To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Date: Tue, 28 Apr 2009 07:59:10 -0700 Thread-Topic: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP Thread-Index: AcnHx2XmuyNl22p5Sw+BnCFgi1kgOAASQFlQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FCA5BEE@EX-SEA5-D.ant.amazon.com> References: <001601c9c763$3bedcde0$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FCA51E4@EX-SEA5-D.ant.amazon.com> <49F69CAB.60407@it.aoyama.ac.jp> In-Reply-To: <49F69CAB.60407@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "markdavis@google.com" , LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:58:00 -0000 SGkgTWFydGluLA0KDQpXaGlsZSBJIHJlYWxpemUgdGhhdCBpdCBpcyBhIGhvbGlkYXkgZm9yIHlv dSwgaXQgd291bGQgYmUgUmVhbGx5IE5pY2Ugbm90IHRvIG1pc3MgdGhlIG5leHQgSUVTRyB0ZWxl Y2hhdCwgc2luY2UgdGhhdCB3b3VsZCBiZSB0aGUgZW5kIG9mIHRoaXMgd29yayAobGVzcyBBVVRI NDggYW5kIHRoZSBSRkMgRWRpdG9yKS4uLi4gYXMgYW4gZWRpdG9yLCBJJ20gaGFwcHkgdG8gdGFr ZSBtdWNoIG9mIHRoZSBidXJkZW4gb2YgcHJlcGFyaW5nIHRoZSByZXNwb25zZXMuDQoNClRoZSB0 cmFja2VyIHRvb2wgZG9lc24ndCBlbnVtZXJhdGUgd2hhdCBzb2x1dGlvbiB0byBhcHBseSB0byBl YWNoIGl0ZW0uIFdoYXQgSSdkIGxpa2UgdG8gZG8gaXMgcHJvcG9zZSBhIHNwZWNpZmljIHNvbHV0 aW9uIG9uIGxpc3QgdG8gZWFjaCBpdGVtLCBtYWtpbmcgdGhlbSBhdmFpbGFibGUgaW4gdGhlIGVk aXRvcidzIGNvcHkuIE9idmlvdXNseSwgbGlzdCBjb25zZW5zdXMgYXBwbGllcywgc28gaWYgdGhl cmUgaXMgYW55IGRlYmF0ZSwgSSB3b3VsZCBwcmVmZXIgaWYgeW91IGFuZCBSYW5keSBjb3VsZCB3 b3JrIHRvZ2V0aGVyIHRvIG1ha2UgYW55IGNvbnNlbnN1cyBkZWNpc2lvbnMgY2xlYXJseSBhbmQs IGlmIGFwcHJvcHJpYXRlLCBxdWlja2x5Lg0KDQpJZiB0aGlzIHBsYW4gaXMgYWNjZXB0YWJsZSwg SSB3aWxsIHN0YXJ0IG1ha2luZyBwcm9wb3NhbHMsIHVzaW5nIHRoZSB0cmFja2VyIGl0ZW0gbnVt YmVycyBpbiBzdWJqZWN0IGxpbmVzLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUGhpbGxpcHMNCkds b2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBp cyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogIk1hcnRpbiBKLiBEw7xyc3QiIFttYWlsdG86ZHVl cnN0QGl0LmFveWFtYS5hYy5qcF0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAyNywgMjAwOSAxMTow NiBQTQ0KPiBUbzogUGhpbGxpcHMsIEFkZGlzb24NCj4gQ2M6IFJhbmR5IFByZXN1aG47IExUUlUg V29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIEZ3OiBMYXN0IENhbGw6IGRyYWZ0 LWlldGYtbHRydS00NjQ2YmlzIChUYWdzDQo+IGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMpIHRv IEJDUA0KPiANCj4gVmVyeSBnb29kLiBQbGVhc2Ugbm90ZSB0aGF0IHBhcnQgb2YgdGhpcyB3ZWVr IGFuZCBwYXJ0IG9mIG5leHQgaXMNCj4gIkdvbGRlbiBXZWVrIiBoZXJlIGluIEphcGFuLCBtb3N0 bHkgaG9saWRheXMuIEJ1dCBJJ2xsIHNlZSB3aGF0IEkNCj4gY2FuIGRvLg0KPiANCj4gUmVnYXJk cywgICAgTWFydGluLg0KPiANCj4gT24gMjAwOS8wNC8yOCAzOjE4LCBQaGlsbGlwcywgQWRkaXNv biB3cm90ZToNCj4gPiBIaSBSYW5keSwNCj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhpcy4gSSBsb29r IGZvcndhcmQgdG8gcHJvZHVjaW5nIHRoZSBuZWNlc3NhcnkgZHJhZnQNCj4gdGhpcyB3ZWVrLg0K PiA+DQo+ID4gQWRkaXNvbg0KPiA+DQo+ID4gQWRkaXNvbiBQaGlsbGlwcw0KPiA+IEdsb2JhbGl6 YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KPiA+DQo+ID4gSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCj4gPiBJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQo+ID4NCj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+PiBCZWhhbGYgT2YgUmFu ZHkgUHJlc3Vobg0KPiA+PiBTZW50OiBNb25kYXksIEFwcmlsIDI3LCAyMDA5IDExOjA5IEFNDQo+ ID4+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gPj4gU3ViamVjdDogW0x0cnVdIEZ3OiBMYXN0 IENhbGw6IGRyYWZ0LWlldGYtbHRydS00NjQ2YmlzIChUYWdzIGZvcg0KPiA+PiBJZGVudGlmeWlu ZyBMYW5ndWFnZXMpIHRvIEJDUA0KPiA+Pg0KPiA+PiBIaSAtDQo+ID4+DQo+ID4+IEZvcndhcmRl ZCBmb3IgeW91ciBpbmZvcm1hdGlvbi4NCj4gPj4NCj4gPj4gTWFydGluIChhcyBkb2N1bWVudCBz aGVwaGVyZCkgYW5kIHRoZSBlZGl0b3JzIHdpbGwNCj4gPj4gd29yayB0aHJvdWdoIHRoZSBpc3N1 ZSBsaXN0IGF0DQo+ID4+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2x0cnUvdHJhYy9y ZXBvcnQvMQ0KPiA+PiB0byBtYWtlIHN1cmUgYWxsIHRoZSBpc3N1ZXMgYXJlIHJlc29sdmVkIGFu ZCB0byBwcm9kdWNlIGFuDQo+IHVwZGF0ZWQNCj4gPj4gZG9jdW1lbnQuDQo+ID4+DQo+ID4+IFJh bmR5DQo+ID4+DQo+ID4+PiBGcm9tOiAiQWxleGV5IE1lbG5pa292IjxhbGV4ZXkubWVsbmlrb3ZA aXNvZGUuY29tPg0KPiA+Pj4gVG86ICJSYW5keSBQcmVzdWhuIjxyYW5keV9wcmVzdWhuQG1pbmRz cHJpbmcuY29tPg0KPiA+Pj4gQ2M6ICJNYXJ0aW4gRHVlcnN0IjxkdWVyc3RAaXQuYW95YW1hLmFj LmpwPg0KPiA+Pj4gU2VudDogTW9uZGF5LCBBcHJpbCAyNywgMjAwOSA0OjMyIEFNDQo+ID4+PiBT dWJqZWN0OiBSZTogW0x0cnVdIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMgKFRh Z3MNCj4gZm9yDQo+ID4+IElkZW50aWZ5aW5nIExhbmd1YWdlcykgdG8gQkNQDQo+ID4+PiBSYW5k eSBQcmVzdWhuIHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBIaSAtDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+PiBGcm9tOiAiVGhlIElFU0ciPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPg0KPiA+Pj4+PiBU bzogIklFVEYtQW5ub3VuY2UiPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+ID4+Pj4+IENjOjxs dHJ1QGlldGYub3JnPg0KPiA+Pj4+PiBTZW50OiBNb25kYXksIEFwcmlsIDEzLCAyMDA5IDU6MjUg QU0NCj4gPj4+Pj4gU3ViamVjdDogW0x0cnVdIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1sdHJ1LTQ2 NDZiaXMgKFRhZ3MgZm9yDQo+ID4+IElkZW50aWZ5aW5nIExhbmd1YWdlcykgdG8gQkNQDQo+ID4+ Pj4+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgTGFuZ3VhZ2UgVGFn DQo+IFJlZ2lzdHJ5DQo+ID4+IFVwZGF0ZSBXRw0KPiA+Pj4+PiAobHRydSkgdG8gY29uc2lkZXIg dGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCj4gPj4+Pj4NCj4gPj4+Pj4gLSAnVGFncyBmb3IgSWRl bnRpZnlpbmcgTGFuZ3VhZ2VzICcNCj4gPj4+Pj4gICAgPGRyYWZ0LWlldGYtbHRydS00NjQ2Ymlz LTIxLnR4dD4gIGFzIGEgQkNQDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4gLi4uDQo+ID4+Pj4N Cj4gPj4+PiBXZSBoYXZlIGEgYnVuY2ggb2YgbWlub3IgaXNzdWVzIHJlc3VsdGluZyBmcm9tIHRo ZSBBRCByZXZpZXcNCj4gPj4+PiBpbiB0aGUgdHJhY2tlciBhdA0KPiA+PiBodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy93Zy9sdHJ1L3RyYWMvcmVwb3J0LzENCj4gPj4+PiBBdCBsZWFzdCBhIGZl dyBvZiB0aGVtIGhhdmUgYmVlbiByZXNvbHZlZCBpbiB3YXlzIHRoYXQgd2lsbA0KPiA+Pj4+IHJl c3VsdCBpbiAobWlub3IpIGNoYW5nZXMgdG8gdGhlIHRleHQuICBIb3cgZG8geW91IHdhbnQgdG8N Cj4gPj4+PiBoYW5kbGUgdGhlIGxvZ2lzdGljcyBvZiBmb2xkaW5nIHRoZXNlIGluPw0KPiA+Pj4+ DQo+ID4+Pj4NCj4gPj4+IEkgdGhpbmsgSSBuZWVkIHRvIHNlZSBhIG5ldyByZXZpc2lvbi4gSWYg YSBuZXcgZHJhZnQgaXMgcG9zdGVkDQo+ID4+IGJlZm9yZQ0KPiA+Pj4gdGhlIGVuZCBvZiB0aGlz IFRodXJzZGF5IChBcHJpbCAzMHRoKSBbYW5kIGl0IGFkZHJlc3NlcyBteQ0KPiA+PiBjb25jZXJu cywgb2YNCj4gPj4+IGNvdXJzZV0sIHRoZW4gYm90aCBMVFJVIGRvY3VtZW50cyBjYW4gYmUgb24g TWF5IDV0aCBJRVNHDQo+IHRlbGVjaGF0Lg0KPiA+Pj4NCj4gPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gTHRydSBtYWlsaW5nIGxpc3QNCj4g Pj4gTHRydUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2x0cnUNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IEx0cnUgbWFpbGluZyBsaXN0DQo+ID4gTHRydUBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KPiA+DQo+IA0KPiAtLQ0KPiAj LSMgTWFydGluIEouIETDvHJzdCwgUHJvZmVzc29yLCBBb3lhbWEgR2FrdWluIFVuaXZlcnNpdHkN Cj4gIy0jIGh0dHA6Ly93d3cuc3cuaXQuYW95YW1hLmFjLmpwICAgbWFpbHRvOmR1ZXJzdEBpdC5h b3lhbWEuYWMuanANCg== From randy_presuhn@mindspring.com Tue Apr 28 10:49:00 2009 Return-Path: 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 0C6733A6CC0 for ; Tue, 28 Apr 2009 10:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_20=-0.74] 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 pzVMqhZuPYkd for ; Tue, 28 Apr 2009 10:48:59 -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 186B23A6CB7 for ; Tue, 28 Apr 2009 10:48:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cxztO+3ZT9s55tANqCbWWJc3KkIV4Nueh8sTWN5DjNAKUigIpqScvKjVxG7UTWrr; 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.80.153] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LyrRk-0006b8-FA for ltru@ietf.org; Tue, 28 Apr 2009 13:50:20 -0400 Message-ID: <002701c9c82a$2caa26e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001601c9c763$3bedcde0$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FCA51E4@EX-SEA5-D.ant.amazon.com> <49F69CAB.60407@it.aoyama.ac.jp> <4D25F22093241741BC1D0EEBC2DBB1DA019FCA5BEE@EX-SEA5-D.ant.amazon.com> Date: Tue, 28 Apr 2009 10:53:00 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968cb70fee06014ead012bd19edc5f80784350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.153 Subject: Re: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:49:00 -0000 Hi - > From: "Phillips, Addison" > To: "Martin J. Dürst" > Cc: "Randy Presuhn" ; ; "Doug Ewell" ; "LTRU Working Group" > Sent: Tuesday, April 28, 2009 7:59 AM > Subject: RE: [Ltru] Fw: Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP ... > The tracker tool doesn't enumerate what solution to apply to each item. The resolution for each item needs to be entered. It can't read our minds. :-( Martin and I can both make the entries. > What I'd like to do is propose a specific solution on list to each item, > making them available in the editor's copy. Obviously, list consensus > applies, so if there is any debate, I would prefer if you and Randy > could work together to make any consensus decisions clearly and, if > appropriate, quickly. Fine with me. I think it would work if both Martin and I were to update entries as the data becomes available to us. There's enough difference in our timezones that overlap should not be a significant problem. I'm up to my ears in another (non-IETF) project at the moment, so it's best to just think of me as a back-up to Martin in his role as document shepherd. > If this plan is acceptable, I will start making proposals, using the > tracker item numbers in subject lines. Sounds good and very good to me. Randy From addison@amazon.com Tue Apr 28 20:57:04 2009 Return-Path: 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 CA1C53A6993 for ; Tue, 28 Apr 2009 20:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 4pkpd0dTB8fX for ; Tue, 28 Apr 2009 20:56:58 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id BF78E3A67F6 for ; Tue, 28 Apr 2009 20:56:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,264,1238976000"; d="scan'208";a="178360976" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 03:58:19 +0000 Received: from ex-hub-4103.ant.amazon.com (ex-hub-4103.sea5.amazon.com [10.248.163.24]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3T3wI9D028492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 03:58:19 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4103.ant.amazon.com ([10.248.163.24]) with mapi; Tue, 28 Apr 2009 20:58:18 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Tue, 28 Apr 2009 20:58:16 -0700 Thread-Topic: Ticket #38, AD issue #5: ABNF vs UTF-8 Thread-Index: AcnIfrmo0IshcVpxQ825RYhODhY2Yw== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A588@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 03:57:04 -0000 SW4gdGhpcyBpc3N1ZSwgdGhlIEFEIHN1Z2dlc3RzOg0KDQotLS0NCltBQk5GIGVycm9yXSBXaGls ZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBoZXJlLCBJIHRoaW5rIHRoZQ0KZGVmaW5pdGlv biBvZiBDSEFSUyBkb2Vzbid0IG1hdGNoIHRoZSByZXF1aXJlbWVudCB0byB1c2UgVVRGLTggZW5j b2RpbmcNCnN0YXRlZCBlYXJsaWVyIGluIHNlY3Rpb24gMy4xLjE6DQoNCiAgICBUaGUgcmVnaXN0 cnkgaXMgYSBbVW5pY29kZV0gdGV4dCBmaWxlLCB1c2luZyB0aGUgVVRGLTggW1JGQzM2MjldDQog ICAgY2hhcmFjdGVyIGVuY29kaW5nLCBhbmQgY29uc2lzdHMgb2YgYSBzZXJpZXMgb2YgcmVjb3Jk cyBzdG9yZWQgaW4gYQ0KICAgIGZvcm1hdCBiYXNlZCBvbiAicmVjb3JkLWphciIgKGRlc2NyaWJl ZCBpbiBbcmVjb3JkLWphcl0pLg0KDQpJTUhPLCB5b3UgY2FuIHVzZSBBQk5GIHByb2R1Y3Rpb25z IGZyb20gW1JGQzM2MjldIHRvIGZpeCB0aGF0Lg0KLS0tDQoNCkkgZG9uJ3QgYmVsaWV2ZSB0aGF0 IHRoaXMgaXMgbmVjZXNzYXJ5IHRvIGNoYW5nZS4gVGhlIHJlZ2lzdHJ5IGlzIGEgVW5pY29kZSB0 ZXh0IGZpbGUuIFRoZSBjaGFyYWN0ZXIgZW5jb2RpbmcgdXNlZCB0byByZWNvcmQgaXQgaGFwcGVu cyB0byBiZSBVVEYtOCAoYnkgcnVsZSkuIFJlcHJvZHVjaW5nIHRoZSBSRkMgMzYyOSBBQk5GIHBy b2R1Y3Rpb25zIGFyZSBub3QgbmVjZXNzYXJ5LCBhbmQsIGluIGZhY3QsIHdvdWxkIG1ha2UgdGhl IEFCTkYgdW5uZWNlc3NhcmlseSBjb21wbGV4LiBUaGUgQUJORiBwcm9kdWN0aW9uIGluIHRoZSBj dXJyZW50IGRvY3VtZW50IGlzOg0KDQogICBDSEFSUyAgICAgID0gKCV4MjEtMTBGRkZGKSAgICAg IDsgVW5pY29kZSBjb2RlIHBvaW50cw0KDQpUaGlzIHBhcnRpY3VsYXIgcHJvZHVjdGlvbiB3YXMg bW9kZWxlZCBvbiBvdGhlcnMgcmVsYXRlZCB0byBjb2RlIHBvaW50cywgc3VjaCBhcyB0aG9zZSBp biBSRkMgMzk4Ny4gSXQgaXMgbm90IGFuIGVycm9yIHRvIHRhbGsgYWJvdXQgY29kZSBwb2ludHMu IFVzZXJzIGFyZSBnaXZlbiB0aGUgbmVjZXNzYXJ5IHBvaW50ZXJzIHNob3VsZCB0aGV5IGJlIHVu YXdhcmUgb2Ygd2hhdCBhIGNoYXJhY3RlciBlbmNvZGluZyBpcy4NCg0KUHJvcG9zZSByZXNvbHV0 aW9uOiBubyBjaGFuZ2VzLg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCAtLSBMYWIxMjYNCk1lbWJlciAtLSBVbmljb2RlIEVkaXRvcmlhbCBDb21taXR0ZWUNCg0K SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVj dHVyZS4NCg0K From addison@amazon.com Tue Apr 28 21:06:40 2009 Return-Path: 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 6EF973A6D6A for ; Tue, 28 Apr 2009 21:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 oN3wTyyV58Gr for ; Tue, 28 Apr 2009 21:06:39 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 8AEBD3A67F6 for ; Tue, 28 Apr 2009 21:05:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,264,1238976000"; d="scan'208";a="178362694" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 04:07:08 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3T47838000326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 04:07:08 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Tue, 28 Apr 2009 21:07:08 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Tue, 28 Apr 2009 21:07:06 -0700 Thread-Topic: Ticket #34, AD Issue #1: who scrutinizes primary subtags rejected by ISO 639/RA-JAC Thread-Index: AcnIf/Xms7/W/G0GSKChv+qNO7C6Hg== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A590@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #34, AD Issue #1: who scrutinizes primary subtags rejected by ISO 639/RA-JAC X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 04:06:40 -0000 VGhlIEFEIHBvaW50cyBvdXQ6DQoNCi0tLQ0KICAgICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50 IHdhcyBjcmVhdGVkLCB0aGVyZSB3ZXJlIG5vIGV4YW1wbGVzIG9mDQogICAgdGhpcyBraW5kIG9m IHN1YnRhZyBhbmQgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgb2YgdGhpcyB0eXBlIGFyZQ0KICAgIGRp c2NvdXJhZ2VkOiBwcmltYXJ5IGxhbmd1YWdlcyBhcmUgc3Ryb25nbHkgUkVDT01NRU5ERUQgZm9y DQogICAgcmVnaXN0cmF0aW9uIHdpdGggSVNPIDYzOSwgYW5kIHByb3Bvc2FscyByZWplY3RlZCBi eSBJU08gNjM5Lw0KICAgIFJBLUpBQyB3aWxsIGJlIGNsb3NlbHkgc2NydXRpbml6ZWQgYmVmb3Jl IHRoZXkgYXJlIHJlZ2lzdGVyZWQNCiAgICB3aXRoIElBTkEuDQoNCltVbmNsZWFyIHRleHRdIFNj cnV0aW5pemVkIGJ5IHdob20/IEF0IHRoaXMgcG9pbnQgaW4gdGhlIGRvY3VtZW50IGl0IGlzDQpu b3QgY2xlYXIgd2hvIGlzIGdvaW5nIHRvIHBlcmZvcm0gdGhlIGFjdGlvbi4NCkkgdGhpbmsgeW91 IG1lYW50IHRoYXQgdGhpcyB3b3VsZCBiZSBkb25lIGJ5IHRoZSBkZXNpZ25hdGVkIHJlZ2lzdHJ5 DQpyZXZpZXdlciwgc28gSSBzdWdnZXN0IGFkZGluZyBhIGZvcndhcmQgcmVmZXJlbmNlIGhlcmUu DQotLS0NCg0KVGhpcyBpcyB0ZXh0IGZyb20gUkZDIDQ2NDYgdGhhdCBpcyB1bmNoYW5nZWQuIFRo ZSBub3Rpb24gaGVyZSBpcyB0aGF0IHRoZSBjb21tdW5pdHkvaWV0Zi1sYW5ndWFnZXMgbGlzdCBh bmQgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBhcmUgdW5saWtlbHkgdG8gYWNjZXB0IHNv bWV0aGluZyB0aGF0IElTTyA2MzkgaGFzIGFscmVhZHkgcmVqZWN0ZWQuDQoNCk5vdGUgdGhhdCB0 aGlzIHRleHQgaXMgbWlycm9yZWQgbGF0ZXIgaW4gdGhlIGRvY3VtZW50LCBpbiBTZWN0aW9uIDMu NjoNCg0KLS0NClByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBmb3IgbGFuZ3VhZ2VzIG5vdCBsaXN0 ZWQgaW4gSVNPIDYzOSB0aGF0IGFyZSBub3QgdmFyaWFudHMgb2YgYW55IGxpc3RlZCBvciByZWdp c3RlcmVkIGxhbmd1YWdlIE1BWSBiZSByZWdpc3RlcmVkLiBBdCB0aGUgdGltZSB0aGlzIGRvY3Vt ZW50IHdhcyBjcmVhdGVkLCB0aGVyZSB3ZXJlIG5vIGV4YW1wbGVzIG9mIHRoaXMgZm9ybSBvZiBz dWJ0YWcuIEJlZm9yZSBhdHRlbXB0aW5nIHRvIHJlZ2lzdGVyIGEgbGFuZ3VhZ2Ugc3VidGFnLCB0 aGVyZSBNVVNUIGJlIGFuIGF0dGVtcHQgdG8gcmVnaXN0ZXIgdGhlIGxhbmd1YWdlIHdpdGggSVNP IDYzOS4gU3VidGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIGZvciBsYW5ndWFnZXMgZGVmaW5l ZCBieSBjb2RlcyB0aGF0IGV4aXN0IGluIElTTyA2MzktMSwgSVNPIDYzOS0yLCBvciBJU08gNjM5 LTMsIG9yIHRoYXQgYXJlIHVuZGVyIGNvbnNpZGVyYXRpb24gYnkgdGhlIElTTyA2MzkgcmVnaXN0 cmF0aW9uIGF1dGhvcml0aWVzLCBvciB0aGF0IGhhdmUgbmV2ZXIgYmVlbiBhdHRlbXB0ZWQgZm9y IHJlZ2lzdHJhdGlvbiB3aXRoIHRob3NlIGF1dGhvcml0aWVzLiBJZiBJU08gNjM5IGhhcyBwcmV2 aW91c2x5IHJlamVjdGVkIGEgbGFuZ3VhZ2UgZm9yIHJlZ2lzdHJhdGlvbiwgaXQgaXMgcmVhc29u YWJsZSB0byBhc3N1bWUgdGhhdCB0aGVyZSBtdXN0IGJlIGFkZGl0aW9uYWwsIHZlcnkgY29tcGVs bGluZyBldmlkZW5jZSBvZiBuZWVkIGJlZm9yZSBpdCB3aWxsIGJlIHJlZ2lzdGVyZWQgYXMgYSBw cmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdpc3RyeSAodG8gdGhlIGV4dGVu dCB0aGF0IGl0IGlzIHZlcnkgdW5saWtlbHkgdGhhdCBhbnkgc3VidGFncyB3aWxsIGJlIHJlZ2lz dGVyZWQgb2YgdGhpcyB0eXBlKS4NCi0tDQoNClByb3Bvc2VkIHJlc29sdXRpb246IGNoYW5nZSB0 aGUgdGV4dCB0byByZWFkOg0KDQotLQ0KQXQgdGhlIHRpbWUgdGhpcyBkb2N1bWVudCB3YXMgY3Jl YXRlZCwgdGhlcmUgd2VyZSBubyBleGFtcGxlcyBvZiB0aGlzIGtpbmQgb2Ygc3VidGFnIGFuZCBm dXR1cmUgcmVnaXN0cmF0aW9ucyBvZiB0aGlzIHR5cGUgYXJlIGRpc2NvdXJhZ2VkOiBwcmltYXJ5 IGxhbmd1YWdlcyBhcmUgc3Ryb25nbHkgUkVDT01NRU5ERUQgZm9yIHJlZ2lzdHJhdGlvbiB3aXRo IElTTyA2MzksIGFuZCBpZiBwcmV2aW91c2x5IHJlamVjdGVkIGJ5IElTTyA2MzksIGl0IGlzIHJl YXNvbmFibGUgdG8gYXNzdW1lIHRoYXQgdGhlcmUgbmVlZHMgdG8gYmUgYWRkaXRpb25hbCwgdmVy eSBjb21wZWxsaW5nLCBldmlkZW5jZSBvZiBuZWVkIGJlZm9yZSBpdCB3aWxsIGJlIHJlZ2lzdGVy ZWQgYXMgYSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdpc3RyeSAodG8g dGhlIGV4dGVudCB0aGF0IGl0IGlzIHZlcnkgdW5saWtlbHkgdGhhdCBhbnkgc3VidGFncyB3aWxs IGJlIHJlZ2lzdGVyZWQgb2YgdGhpcyB0eXBlKS4NCi0tDQoNCg0KDQpBZGRpc29uIFBoaWxsaXBz DQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRp b24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KDQo= From addison@amazon.com Tue Apr 28 21:10:00 2009 Return-Path: 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 202083A6DDE for ; Tue, 28 Apr 2009 21:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 6cmvLIh0vMHw for ; Tue, 28 Apr 2009 21:09:59 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id 69A263A67F6 for ; Tue, 28 Apr 2009 21:09:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,264,1238976000"; d="scan'208";a="215721118" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 04:11:21 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3T4BLd8004367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 04:11:21 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Tue, 28 Apr 2009 21:11:21 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Tue, 28 Apr 2009 21:11:19 -0700 Thread-Topic: Ticket #35, AD Issue #2: what is meant by "permanently reserved" Thread-Index: AcnIgIys4bVY10F6SmybbRFmZ80BXA== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A591@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #35, AD Issue #2: what is meant by "permanently reserved" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 04:10:00 -0000 VGhlIEFEIG9waW5lZDoNCg0KLS0NCltVbmNsZWFyIHRleHRdIENsYXJpZmljYXRpb24gb24gd2hh dCBpcyBtZWFudCBieSAicGVybWFuZW50bHkgcmVzZXJ2ZWQiDQpoZXJlIHdvdWxkIGJlIGFwcHJl Y2lhdGVkLg0KKCJQZXJtYW5lbnRseSByZXNlcnZlZCIgPT0gIk1VU1QgTk9UIGJlIHJlZ2lzdGVy ZWQsIHVubGVzcyBhIGZ1dHVyZQ0KdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IGNoYW5nZXMgdGhh dCI/KQ0KLS0NCg0KVGhlIHRleHQgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCBhZGRpdGlvbmFsIGV4 dGxhbmdzIGFyZSBmb3JldmVyIGJhbm5lZC4gSSBwcm9wb3NlIHRvIG1ha2UgaXQgY2xlYXJlciBi eSBjaGFuZ2luZyB0aGlzIHRleHQ6DQoNCi0tDQpUaGF0IGlzLCB0aGUgc2Vjb25kIGFuZCB0aGly ZCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcgcG9zaXRpb25zIGluIGEgbGFuZ3VhZ2UgdGFnIGFy ZSBwZXJtYW5lbnRseSByZXNlcnZlZCBhbmQgdGFncyB0aGF0IGluY2x1ZGUgc3VidGFncyBpbiB0 aGF0IHBvc2l0aW9uIGFyZSBpbnZhbGlkLg0KLS0NCg0KLi4uIHRvIHJlYWQuLi4NCg0KLS0NClRo YXQgaXMsIHRoZSBzZWNvbmQgYW5kIHRoaXJkIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZyBwb3Np dGlvbnMgaW4gYSBsYW5ndWFnZSB0YWcgYXJlIHBlcm1hbmVudGx5IHJlc2VydmVkIGFuZCB0YWdz IHRoYXQgaW5jbHVkZSB0aG9zZSBzdWJ0YWdzIGluIHRoYXQgcG9zaXRpb24gYXJlLCBhbmQgd2ls bCBhbHdheXMgcmVtYWluLCBpbnZhbGlkLg0KLS0NCg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xvYmFs aXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5v dCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQoNCg0K From addison@amazon.com Tue Apr 28 21:36:52 2009 Return-Path: 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 1DA1D3A6CA7 for ; Tue, 28 Apr 2009 21:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 KGuSBY+DewD5 for ; Tue, 28 Apr 2009 21:36:51 -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 BDAB13A6C7E for ; Tue, 28 Apr 2009 21:36:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,264,1238976000"; d="scan'208";a="259644240" 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; 29 Apr 2009 04:38:12 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3T4cBhH008696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 04:38:12 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Tue, 28 Apr 2009 21:38:11 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Tue, 28 Apr 2009 21:38:10 -0700 Thread-Topic: Ticket #36: AD Issue #3: rules for UN M.49 codes Thread-Index: AcnIhEyKp+3coR8wREiLnydE4AtAAA== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5A6@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #36: AD Issue #3: rules for UN M.49 codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 04:36:52 -0000 VGhlIEFEIHN1Z2dlc3RlZDoNCg0KLS0NCklzc3VlICMzIGZyb20gQUQgcmV2aWV3IC0gZm9yIGRl dGFpbHMgc2VlDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbHRydS9jdXJy ZW50L21zZzEyMzk5Lmh0bWwNCg0KMykuIFNlY3Rpb24gMi4yLjQgc2F5czoNCg0KICAgIEYuIEFs bCBvdGhlciBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMgdGhhdCBkbyBu b3QNCiAgICBoYXZlIGFuIGFzc29jaWF0ZWQgSVNPIDMxNjYtMSBhbHBoYS0yIGNvZGUgTVVTVCBO T1QgYmUNCiAgICBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFuZCBNVVNUIE5PVCBiZSB1c2Vk IHRvIGZvcm0NCiAgICBsYW5ndWFnZSB0YWdzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0 aGVzZSBjb2Rlcywgc2VlDQogICAgU2VjdGlvbiAzLjQuDQoNCkFuZCBTZWN0aW9uIDMuNCBzYXlz Og0KDQogICAgMTYuIFVOIE0uNDkgaGFzIGNvZGVzIGZvciBib3RoIGNvdW50cmllcyBhbmQgYXJl YXMgKHN1Y2ggYXMgJzI3NicNCiAgICBmb3IgR2VybWFueSkgYW5kIGdlb2dyYXBoaWNhbCByZWdp b25zIGFuZCBzdWItcmVnaW9ucyAoc3VjaCBhcw0KICAgICcxNTAnIGZvciBFdXJvcGUpLiBVTiBN LjQ5IGNvdW50cnkgb3IgYXJlYSBjb2RlcyBmb3Igd2hpY2gNCiAgICB0aGVyZSBpcyBubyBjb3Jy ZXNwb25kaW5nIElTTyAzMTY2LTEgY29kZSBTSE9VTEQgTk9UIGJlDQoNClVubGVzcyBJIGFtIGNv bmZ1c2VkLCBJIHRoaW5rIHRoaXMgU0hPVUxEIE5PVCBjb250cmFkaWN0cyBNVVNUIE5PVCBpbg0K c2VjdGlvbiAyLjIuNC4NCkkgdGhpbmsgeW91IG5lZWQgdG8gY2hhbmdlIG9uZSBvZiAyIHNlY3Rp b25zLg0KDQogICAgcmVnaXN0ZXJlZCwgZXhjZXB0IGFzIGEgc3Vycm9nYXRlIGZvciBhbiBJU08g MzE2Ni0xIGNvZGUgdGhhdCBpcw0KICAgIGJsb2NrZWQgZnJvbSByZWdpc3RyYXRpb24gYnkgYW4g ZXhpc3Rpbmcgc3VidGFnLiBJZiBzdWNoIGEgY29kZQ0KICAgIGJlY29tZXMgbmVjZXNzYXJ5LCB0 aGVuIHRoZSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IGZvciBJU08NCiAgICAzMTY2LTEgU0hPVUxE IGZpcnN0IGJlIHBldGl0aW9uZWQgdG8gYXNzaWduIGEgY29kZSB0byB0aGUNCiAgICByZWdpb24u IElmIHRoZSBwZXRpdGlvbiBmb3IgYSBjb2RlIGFzc2lnbm1lbnQgYnkgSVNPIDMxNjYtMSBpcw0K ICAgIHJlZnVzZWQgb3Igbm90IGFjdGVkIG9uIGluIGEgdGltZWx5IG1hbm5lciwgdGhlIHJlZ2lz dHJhdGlvbg0KICAgIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41IE1BWSB0aGVuIGJl IHVzZWQgdG8gcmVnaXN0ZXINCiAgICB0aGUgY29ycmVzcG9uZGluZyBVTiBNLjQ5IGNvZGUuIFRo aXMgd2F5LCBVTiBNLjQ5IGNvZGVzIHJlbWFpbg0KICAgIGF2YWlsYWJsZSBhcyB0aGUgdmFsdWUg b2YgbGFzdCByZXNvcnQgaW4gY2FzZXMgd2hlcmUgSVNPIDMxNjYtMQ0KICAgIHJlYXNzaWducyBh IGRlcHJlY2F0ZWQgdmFsdWUgaW4gdGhlIHJlZ2lzdHJ5Lg0KLS0NCg0KSSBiZWxpZXZlIHRoZSBB RCBoYXMgYSBwb2ludCBoZXJlLiBOb3RlIHRoYXQgUnVsZSBGIGluIDIuMi40IGlzIG5vdCBjb21w bGV0ZSB1bnRvIGl0c2VsZi4gVGhlIHJ1bGVzIGluIHRoYXQgc2VjdGlvbiBmb3IgVU4gTS40OSBj b2RlcyBhcmUgKGJhc2ljYWxseSk6DQoNCi0gY29udGluZW50cyBhbmQgc3VicmVnaW9uczogcmVn aXN0ZXJlZA0KLSBlY29ub21pYyBhbmQgJ290aGVyJyBncm91cGluZ3M6IGV4Y2x1ZGVkDQotIGNv ZGVzIGFzc29jaWF0ZWQgd2l0aCBjb2RlcyByZWN5Y2xlZCBieSBJU08gMzE2NjogcmVnaXN0ZXJl ZA0KLSBjb2RlcyBvdGhlcndpc2UgYXNzb2NpYXRlZCB3aXRoIElTTyAzMTY2IGNvZGVzOiBleGNs dWRlZA0KLSBjb2RlIDgzMDogcGVybWl0dGVkIHRvIGJlIChidXQgbm90IGN1cnJlbnRseSkgcmVn aXN0ZXJlZA0KLSBhbnkgb3RoZXIgY29kZXM6IGV4Y2x1ZGVkDQoNClRoZSBydWxlICMxNiBpbiBz ZWN0aW9uIDMuNCBpcyBhIHJlc3RhdGVtZW50IG9mIG9uZSBvZiB0aGUgYWJvdmUgcnVsZXMgKHNw ZWNpZmljYWxseSwgdGhlIGZvdXJ0aCBvbmUpLiBJIHJlY2FsbCB0aGF0IHdlIGFkZGVkIHRoZSB0 ZXh0IGluIHJ1bGUgIzE2IGR1cmluZyB0aGlzIGRvY3VtZW50J3MgZ2VzdGF0aW9uLg0KDQpQcm9w b3NlZCByZXNvbHV0aW9uOg0KDQpJIHByb3Bvc2UgdGhhdCB3ZSBjaGFuZ2UgdGhlIHRleHQgaW4g c2VjdGlvbiAyLjIuNCB0byByZWFkOg0KDQo8dD5PdGhlciBVTiBudW1lcmljIGNvZGVzIGZvciBj b3VudHJpZXMgb3IgYXJlYXMgdGhhdCBkbyBub3QgaGF2ZSBhbiBhc3NvY2lhdGVkIElTTyAzMTY2 LTEgYWxwaGEtMiBjb2RlIE1BWSBiZSBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IHZpYSB0aGUg cHJvY2VzcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJyZWdpc3RyYXRpb25Qcm9jIj48L3hy ZWY+LCBzdWJqZWN0IHRvIHRoZSByZXN0cmljdGlvbnMgaW4gPHhyZWYgdGFyZ2V0PSJpYW5hc3Rh YmlsaXR5Ij48L3hyZWY+LCBpdGVtICMxNi48L3Q+DQoNCg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xv YmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlz IG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQoNCg0K From addison@amazon.com Tue Apr 28 21:41:41 2009 Return-Path: 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 401493A6918 for ; Tue, 28 Apr 2009 21:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 5to85vgec8B8 for ; Tue, 28 Apr 2009 21:41:40 -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 9B0553A6E65 for ; Tue, 28 Apr 2009 21:41:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,264,1238976000"; d="scan'208";a="259645108" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 04:42:47 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n3T4gkvN030336 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 04:42:47 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Tue, 28 Apr 2009 21:42:46 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Tue, 28 Apr 2009 21:42:44 -0700 Thread-Topic: Ticket #37: AD Issue #4: delete last sentence in Section 2.2.9 Thread-Index: AcnIhPAwDfqgw2BzTDGGFD6ygP9AxQ== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5AA@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #37: AD Issue #4: delete last sentence in Section 2.2.9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 04:41:41 -0000 VGhlIEFEIHBvaW50cyBvdXQ6DQoNCi0tDQpBRCByZXZpZXcgaXNzdWUgIzQgLSBmb3IgZGV0YWls cyBzZWUNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQv bXNnMTIzOTkuaHRtbA0KDQo0KS4gSW4gU2VjdGlvbiAyLjIuOToNCg0KICAgIE5vdGUgd2VsbDog YWx0aG91Z2ggdGhlICdMYW5ndWFnZS1UYWcnIHByb2R1Y3Rpb24gYXBwZWFyaW5nIGluIHRoaXMN CiAgICBkb2N1bWVudCBpcyBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB0byB0aGUgb25lIGluIFtS RkM0NjQ2XSwgaXQgaGFzDQogICAgYmVlbiBjaGFuZ2VkIHRvIHByZXZlbnQgY2VydGFpbiBlcnJv cnMgaW4gd2VsbC1mb3JtZWRuZXNzIGFyaXNpbmcNCiAgICBmcm9tIHRoZSBvbGQgJ2dyYW5kZmF0 aGVyZWQnIHByb2R1Y3Rpb24uIFRoaXMgdmVyc2lvbiBvZiB0aGUgQUJORiBpcw0KICAgIFJFQ09N TUVOREVEIGFzIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBvbGRlciB2ZXJzaW9uLg0KDQoobml0KSBJ IHN1Z2dlc3QgZGVsZXRpbmcgdGhlIGxhc3Qgc2VudGVuY2UsIGFzIGl0IGRvZXNuJ3QgcHJvdmlk ZSBhbnkNCnVzZWZ1bCBpbmZvcm1hdGlvbiB0byBhIHJlYWRlciAoYXMgdGhlIFdHIHdhbnRzDQpk cmFmdC1pZXRmLWx0cnUtNDY0NmJpcy0yMWJpcy50eHQgdG8gcmVwbGFjZSBSRkMgNDY0NiwgaXQg aXMgY2xlYXIgdGhhdA0KdGhlIFdHIGJlbGlldmVzIHRoYXQgdGhlIG5ldyBBQk5GIGlzIGJldHRl cikuIEFsc28gSSBkb24ndCB0aGluayBpdCB1c2VzDQpSRkMgMjExOSBrZXl3b3JkIHByb3Blcmx5 Lg0KLS0NCg0KSSB0aGluayB0aGlzIGlzIG5vdCBuZWNlc3NhcnkuIFdlIGhhdmUgaGFkLCBhcyBh IHVzZXIgY29tbXVuaXR5LCBhIGxvbmctc3RhbmRpbmcgcHJvYmxlbSB3aXRoIHN0YWxlIHJlZmVy ZW5jZXMgdG8gQkNQIDQ3LiBXZSB3YW50IHRvIGhlbHAgZW5zdXJlIHRoYXQgaW1wbGVtZW50ZXJz IGFuZCBzdGFuZGFyZGl6ZXJzIHVzZSB0aGUgcmlnaHQgQUJORi4gSXQgaXMgd2VsbC1rbm93biB0 aGF0IG1hbnkgaW1wbGVtZW50ZXJzIHJlbHkgZXhjZXNzaXZlbHkgb3IgZXZlbiBleGNsdXNpdmVs eSBvbiB0aGUgQUJORiB0byBkZXRlcm1pbmUgIndoYXQgaXMgcmlnaHQiLiBUaGVyZWZvcmUsIGl0 IGlzIHVzZWZ1bCB0byBoYXZlIHNvbWUgZG9jdW1lbnRhdGlvbiBleHBsYWluaW5nIHdoeSB0aGlz IEFCTkYgaXMgYmV0dGVyLg0KDQpQcm9wb3NlZCByZXNvbHV0aW9uOiBubyBjaGFuZ2UNCg0KQWRk aXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVy bmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUu DQoNCg0K From addison@amazon.com Tue Apr 28 21:49:17 2009 Return-Path: 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 B6D553A6B57 for ; Tue, 28 Apr 2009 21:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 VXOcXNdWRvRr for ; Tue, 28 Apr 2009 21:49:16 -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 79D083A6949 for ; Tue, 28 Apr 2009 21:49:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,264,1238976000"; d="scan'208";a="259646979" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 04:50:38 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n3T4obLc006683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 04:50:37 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Tue, 28 Apr 2009 21:50:34 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Tue, 28 Apr 2009 21:50:32 -0700 Thread-Topic: Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 Thread-Index: AcnIhgcHdn3MPcUkQqaPi5yK/xxpDg== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 04:49:17 -0000 VGhlIEFEIG1lbnRpb25zOg0KDQotLQ0KQ29tbWVudCBudW1iZXIgNyBmcm9tIHRoZSBBRCByZXZp ZXcgYXQNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQv bXNnMTIzOTkuaHRtbA0KDQo3KS4gSW4gU2VjdGlvbiAzLjQ6DQoNCiAgICAxNS4gQ29kZXMgYXNz aWduZWQgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBvciBJU08gMzE2Ni0xIHRoYXQNCiAgICBjb25m bGljdCB3aXRoIGV4aXN0aW5nIHN1YnRhZ3Mgb2YgdGhlIGFzc29jaWF0ZWQgdHlwZSwgaW5jbHVk aW5nDQogICAgc3VidGFncyB0aGF0IGFyZSBkZXByZWNhdGVkLCBNVVNUIE5PVCBiZSBlbnRlcmVk IGludG8gdGhlDQogICAgcmVnaXN0cnkuIFRoZSBmb2xsb3dpbmcgYWRkaXRpb25hbCBjb25zaWRl cmF0aW9ucyBhcHBseSB0bw0KICAgIHN1YnRhZyB2YWx1ZXMgdGhhdCBhcmUgcmVhc3NpZ25lZDoN Cg0KICAgIFsuLi5dDQoNCiAgICBGLiBGb3IgSVNPIDMxNjYtMSBjb2RlcywgaWYgdGhlcmUgaXMg bm8gYXNzb2NpYXRlZCBVTiBudW1lcmljDQogICAgY29kZSwgdGhlbiB0aGUgTGFuZ3VhZ2UgU3Vi dGFnIFJldmlld2VyIFNIQUxMIHBldGl0aW9uIHRoZQ0KICAgIFVOIHRvIGNyZWF0ZSBvbmUuIElm IHRoZXJlIGlzIG5vIHJlc3BvbnNlIGZyb20gdGhlIFVODQogICAgd2l0aGluIG5pbmV0eSBkYXlz IG9mIHRoZSByZXF1ZXN0IGJlaW5nIHNlbnQsIHRoZSBMYW5ndWFnZQ0KICAgIFN1YnRhZyBSZXZp ZXdlciBTSEFMTCBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yIGVudGVyaW5nIGluIHRoZQ0KICAgIElB TkEgcmVnaXN0cnkgYXMgc29vbiBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIHZhcmlhbnQNCiAg ICBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRlIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUuIFRoZSBmb3Jt IG9mDQogICAgdGhlIHJlZ2lzdGVyZWQgdmFyaWFudCBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlz Y3JldGlvbiBvZg0KICAgIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYW5kIE1VU1QgY29u Zm9ybSB0byBvdGhlcg0KICAgIHJlc3RyaWN0aW9ucyBvbiB2YXJpYW50IHN1YnRhZ3MgaW4gdGhp cyBkb2N1bWVudC4gVGhpcw0KICAgIHNpdHVhdGlvbiBpcyB2ZXJ5IHVubGlrZWx5IHRvIGV2ZXIg b2NjdXIuDQoNCiAgICAxNi4gVU4gTS40OSBoYXMgY29kZXMgZm9yIGJvdGggY291bnRyaWVzIGFu ZCBhcmVhcyAoc3VjaCBhcyAnMjc2Jw0KICAgIGZvciBHZXJtYW55KSBhbmQgZ2VvZ3JhcGhpY2Fs IHJlZ2lvbnMgYW5kIHN1Yi1yZWdpb25zIChzdWNoIGFzDQogICAgJzE1MCcgZm9yIEV1cm9wZSku IFVOIE0uNDkgY291bnRyeSBvciBhcmVhIGNvZGVzIGZvciB3aGljaA0KICAgIHRoZXJlIGlzIG5v IGNvcnJlc3BvbmRpbmcgSVNPIDMxNjYtMSBjb2RlIFNIT1VMRCBOT1QgYmUNCiAgICByZWdpc3Rl cmVkLCBleGNlcHQgYXMgYSBzdXJyb2dhdGUgZm9yIGFuIElTTyAzMTY2LTEgY29kZSB0aGF0IGlz DQogICAgYmxvY2tlZCBmcm9tIHJlZ2lzdHJhdGlvbiBieSBhbiBleGlzdGluZyBzdWJ0YWcuIElm IHN1Y2ggYSBjb2RlDQogICAgYmVjb21lcyBuZWNlc3NhcnksIHRoZW4gdGhlIHJlZ2lzdHJhdGlv biBhdXRob3JpdHkgZm9yIElTTw0KICAgIDMxNjYtMSBTSE9VTEQNCg0KV2h5IFNIT1VMRCBpcyB1 c2VkIGhlcmUgaW5zdGVhZCBvZiBTSEFMTD8NClNpbWlsYXIgdGV4dCBpbiAxNS5GIHNheXMgU0hB TEwsIHdoaWNoIGlzIHN0cm9uZ2VyLg0KQWxzbywgMTUuRiBzcGVjaWZpZXMgZXhwZWN0ZWQgcmVz cG9uc2UgdGltZSAoOTAgZGF5cyksIHdoaWNoIGlzIG1pc3NpbmcNCmJlbG93LiBBbnkgcmVhc29u IHdoeSB5b3UgZG9uJ3Qgd2FudCB0byBzcGVjaWZ5IGRlYWRsaW5lIGluIHRoaXMgY2FzZT8NCg0K ICAgIGZpcnN0IGJlIHBldGl0aW9uZWQgdG8gYXNzaWduIGEgY29kZSB0byB0aGUNCiAgICByZWdp b24uIElmIHRoZSBwZXRpdGlvbiBmb3IgYSBjb2RlIGFzc2lnbm1lbnQgYnkgSVNPIDMxNjYtMSBp cw0KICAgIHJlZnVzZWQgb3Igbm90IGFjdGVkIG9uIGluIGEgdGltZWx5IG1hbm5lciwgdGhlIHJl Z2lzdHJhdGlvbg0KICAgIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41IE1BWSB0aGVu IGJlIHVzZWQgdG8gcmVnaXN0ZXINCiAgICB0aGUgY29ycmVzcG9uZGluZyBVTiBNLjQ5IGNvZGUu IFRoaXMgd2F5LCBVTiBNLjQ5IGNvZGVzIHJlbWFpbg0KICAgIGF2YWlsYWJsZSBhcyB0aGUgdmFs dWUgb2YgbGFzdCByZXNvcnQgaW4gY2FzZXMgd2hlcmUgSVNPIDMxNjYtMQ0KICAgIHJlYXNzaWdu cyBhIGRlcHJlY2F0ZWQgdmFsdWUgaW4gdGhlIHJlZ2lzdHJ5Lg0KLS0NCg0KSSB0aGluayB0aGUg Y2FzZXMgYXJlIGRpZmZlcmVudC4NCg0KSW4gdGhlIGZvcm1lciBjYXNlLCBCQ1AgNDcgcmVxdWly ZXMgYSBVTiBNLjQ5IGNvZGUgdG8gZXhpc3QuIEluIHRoZSBleHRyZW1lbHkgdW5saWtlbHkgZXZl bnQgdGhhdCAid2UiIGFyZSB0aGUgZmlyc3QgdG8gbm90aWNlIHRoYXQgb25lIGhhc24ndCBiZWVu IGFzc2lnbmVkLCB0aGUgTFNSIGlzIG9ibGlnYXRlZCB0byBhc2sgZm9yIG9uZS4NCg0KSW4gdGhl IGxhdHRlciBjYXNlIChydWxlIDE2KSB3ZSBwcmVzdW1lIHRoYXQgc29tZW9uZSBpcyBhc2tpbmcg Zm9yIGEgVU4gTS40OSBjb2RlIHRoYXQgaGFzIG5vIGNvcnJlc3BvbmRpbmcgSVNPIDMxNjYgY29k ZS4gVGhpcyBpcyBub3QgdW5oZWFyZCBvZi4gSXQgaXMgbWVyZWx5IGV4Y2VwdGlvbmFsbHkgcmFy ZSBhbmQgdHlwaWNhbGx5IGEgQmFkIElkZWEgdG8gcmVnaXN0ZXIgZXhjZXB0aW9uYWxseSAoaGVu Y2UgdGhlIHJlY29tbWVuZGF0aW9uIHRvIGdvIHRvIElTTywgZXRjLikuIEl0IGlzbid0IFNIQUxM IGJlY2F1c2Ugd2UgZG9uJ3QgcmVseSBvbiB0aGUgY29kZSBmb3IgY29udGludWVkIHN0YWJsZSBv cGVyYXRpb24gb2YgdGhlIHJlZ2lzdHJ5LiANCg0KUHJvcG9zZWQgcmVzb2x1dGlvbjogbm8gY2hh bmdlLg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIx MjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFy Y2hpdGVjdHVyZS4NCg0KDQo= From duerst@it.aoyama.ac.jp Wed Apr 29 01:54:34 2009 Return-Path: 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 4B49B3A70AB for ; Wed, 29 Apr 2009 01:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 57C917VqiXJN for ; Wed, 29 Apr 2009 01:54:33 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 1F91F3A7099 for ; Wed, 29 Apr 2009 01:54:32 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n3T8tO1p024053 for ; Wed, 29 Apr 2009 17:55:51 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 14f9_7a1e69da_349b_11de_8cd7_0019b9e2b3d9; Wed, 29 Apr 2009 17:55:24 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35302) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Apr 2009 17:54:15 +0900 Message-ID: <49F815E6.6040309@it.aoyama.ac.jp> Date: Wed, 29 Apr 2009 17:55:02 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: "Phillips, Addison" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A588@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A588@EX-SEA5-D.ant.amazon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 08:54:34 -0000 Addison, I suggest that where possible, you follow previous discussions on these issues. In particular, for this specific issue, I made a wording proposal, and Alex said that he would prefer the new wording. My judgement as a co-chair and shepherd is that if our AD prefers something, and nobody from the WG opposed, then that's what we should do :-). For more details, please see http://www.ietf.org/mail-archive/web/ltru/current/msg12445.html and http://www.ietf.org/mail-archive/web/ltru/current/msg12452.html. Regards, Martin. On 2009/04/29 12:58, Phillips, Addison wrote: > In this issue, the AD suggests: > > --- > [ABNF error] While I understand what you mean here, I think the > definition of CHARS doesn't match the requirement to use UTF-8 encoding > stated earlier in section 3.1.1: > > The registry is a [Unicode] text file, using the UTF-8 [RFC3629] > character encoding, and consists of a series of records stored in a > format based on "record-jar" (described in [record-jar]). > > IMHO, you can use ABNF productions from [RFC3629] to fix that. > --- > > I don't believe that this is necessary to change. The registry is a Unicode text file. The character encoding used to record it happens to be UTF-8 (by rule). Reproducing the RFC 3629 ABNF productions are not necessary, and, in fact, would make the ABNF unnecessarily complex. The ABNF production in the current document is: > > CHARS = (%x21-10FFFF) ; Unicode code points > > This particular production was modeled on others related to code points, such as those in RFC 3987. It is not an error to talk about code points. Users are given the necessary pointers should they be unaware of what a character encoding is. > > Propose resolution: no changes. > > Addison Phillips > Globalization Architect -- Lab126 > Member -- Unicode Editorial Committee > > Internationalization is not a feature. > It is an architecture. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From addison@amazon.com Wed Apr 29 07:53:34 2009 Return-Path: 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 CBF9C28C199 for ; Wed, 29 Apr 2009 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.34 X-Spam-Level: X-Spam-Status: No, score=-106.34 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 33i9A6l2WMYO for ; Wed, 29 Apr 2009 07:53:33 -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 7549528C247 for ; Wed, 29 Apr 2009 07:53:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,266,1238976000"; d="scan'208";a="259855874" Received: from smtp-in-4104.sea5.amazon.com ([10.248.183.18]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 14:54:54 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-4104.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TEsro1032473 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 29 Apr 2009 14:54:54 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Wed, 29 Apr 2009 07:54:53 -0700 From: "Phillips, Addison" To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Date: Wed, 29 Apr 2009 07:54:52 -0700 Thread-Topic: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 Thread-Index: AcnIqEaYUh4gU3G7SMmJitjMJYjjRwAMTwgA Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A773@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A588@EX-SEA5-D.ant.amazon.com> <49F815E6.6040309@it.aoyama.ac.jp> In-Reply-To: <49F815E6.6040309@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 14:53:34 -0000 SWYgd2UgaGF2ZSByZXNvbHV0aW9ucywgaXQgd291bGQgYmUgcmVhbGx5IHVzZWZ1bCBpZiB0aGV5 IHdlcmUsIHdlbGwsIHRyYWNrZWQgaW4gdGhlIHRyYWNrZXIuIEkgZ290IHVwd2FyZHMgb2YgMzAw MCBlbWFpbHMgd2hpbGUgb24gdmFjYXRpb24gYW5kLCBubywgSSBkaWRuJ3QgcmVhZCB0aGVtIGFs bCA6LSkuDQoNCkkgd2lsbCBleHRyYWN0IHRoZSBwcm9wb3NlZCB0ZXh0IGZyb20gdGhlc2UgbWVz c2FnZXMgYW5kIGluY29ycG9yYXRlIGl0Lg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEg ZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206ICJNYXJ0aW4gSi4gRMO8cnN0IiBbbWFpbHRvOmR1ZXJzdEBpdC5h b3lhbWEuYWMuanBdDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMDkgMTo1NSBBTQ0K PiBUbzogUGhpbGxpcHMsIEFkZGlzb24NCj4gQ2M6IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJq ZWN0OiBSZTogW0x0cnVdIFRpY2tldCAjMzgsIEFEIGlzc3VlICM1OiBBQk5GIHZzIFVURi04DQo+ IA0KPiBBZGRpc29uLCBJIHN1Z2dlc3QgdGhhdCB3aGVyZSBwb3NzaWJsZSwgeW91IGZvbGxvdyBw cmV2aW91cw0KPiBkaXNjdXNzaW9ucw0KPiBvbiB0aGVzZSBpc3N1ZXMuIEluIHBhcnRpY3VsYXIs IGZvciB0aGlzIHNwZWNpZmljIGlzc3VlLCBJIG1hZGUgYQ0KPiB3b3JkaW5nIHByb3Bvc2FsLCBh bmQgQWxleCBzYWlkIHRoYXQgaGUgd291bGQgcHJlZmVyIHRoZSBuZXcNCj4gd29yZGluZy4NCj4g DQo+IE15IGp1ZGdlbWVudCBhcyBhIGNvLWNoYWlyIGFuZCBzaGVwaGVyZCBpcyB0aGF0IGlmIG91 ciBBRCBwcmVmZXJzDQo+IHNvbWV0aGluZywgYW5kIG5vYm9keSBmcm9tIHRoZSBXRyBvcHBvc2Vk LCB0aGVuIHRoYXQncyB3aGF0IHdlDQo+IHNob3VsZCBkbw0KPiA6LSkuDQo+IA0KPiBGb3IgbW9y ZSBkZXRhaWxzLCBwbGVhc2Ugc2VlDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9sdHJ1L2N1cnJlbnQvbXNnMTI0NDUuaHRtbCBhbmQNCj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cxMjQ1Mi5odG1sLg0KPiANCj4gUmVn YXJkcywgICAgTWFydGluLg0KPiANCj4gDQo+IE9uIDIwMDkvMDQvMjkgMTI6NTgsIFBoaWxsaXBz LCBBZGRpc29uIHdyb3RlOg0KPiA+IEluIHRoaXMgaXNzdWUsIHRoZSBBRCBzdWdnZXN0czoNCj4g Pg0KPiA+IC0tLQ0KPiA+IFtBQk5GIGVycm9yXSBXaGlsZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3Ug bWVhbiBoZXJlLCBJIHRoaW5rIHRoZQ0KPiA+IGRlZmluaXRpb24gb2YgQ0hBUlMgZG9lc24ndCBt YXRjaCB0aGUgcmVxdWlyZW1lbnQgdG8gdXNlIFVURi04DQo+IGVuY29kaW5nDQo+ID4gc3RhdGVk IGVhcmxpZXIgaW4gc2VjdGlvbiAzLjEuMToNCj4gPg0KPiA+ICAgICAgVGhlIHJlZ2lzdHJ5IGlz IGEgW1VuaWNvZGVdIHRleHQgZmlsZSwgdXNpbmcgdGhlIFVURi04DQo+IFtSRkMzNjI5XQ0KPiA+ ICAgICAgY2hhcmFjdGVyIGVuY29kaW5nLCBhbmQgY29uc2lzdHMgb2YgYSBzZXJpZXMgb2YgcmVj b3Jkcw0KPiBzdG9yZWQgaW4gYQ0KPiA+ICAgICAgZm9ybWF0IGJhc2VkIG9uICJyZWNvcmQtamFy IiAoZGVzY3JpYmVkIGluIFtyZWNvcmQtamFyXSkuDQo+ID4NCj4gPiBJTUhPLCB5b3UgY2FuIHVz ZSBBQk5GIHByb2R1Y3Rpb25zIGZyb20gW1JGQzM2MjldIHRvIGZpeCB0aGF0Lg0KPiA+IC0tLQ0K PiA+DQo+ID4gSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhpcyBpcyBuZWNlc3NhcnkgdG8gY2hhbmdl LiBUaGUgcmVnaXN0cnkgaXMNCj4gYSBVbmljb2RlIHRleHQgZmlsZS4gVGhlIGNoYXJhY3RlciBl bmNvZGluZyB1c2VkIHRvIHJlY29yZCBpdA0KPiBoYXBwZW5zIHRvIGJlIFVURi04IChieSBydWxl KS4gUmVwcm9kdWNpbmcgdGhlIFJGQyAzNjI5IEFCTkYNCj4gcHJvZHVjdGlvbnMgYXJlIG5vdCBu ZWNlc3NhcnksIGFuZCwgaW4gZmFjdCwgd291bGQgbWFrZSB0aGUgQUJORg0KPiB1bm5lY2Vzc2Fy aWx5IGNvbXBsZXguIFRoZSBBQk5GIHByb2R1Y3Rpb24gaW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQN Cj4gaXM6DQo+ID4NCj4gPiAgICAgQ0hBUlMgICAgICA9ICgleDIxLTEwRkZGRikgICAgICA7IFVu aWNvZGUgY29kZSBwb2ludHMNCj4gPg0KPiA+IFRoaXMgcGFydGljdWxhciBwcm9kdWN0aW9uIHdh cyBtb2RlbGVkIG9uIG90aGVycyByZWxhdGVkIHRvIGNvZGUNCj4gcG9pbnRzLCBzdWNoIGFzIHRo b3NlIGluIFJGQyAzOTg3LiBJdCBpcyBub3QgYW4gZXJyb3IgdG8gdGFsayBhYm91dA0KPiBjb2Rl IHBvaW50cy4gVXNlcnMgYXJlIGdpdmVuIHRoZSBuZWNlc3NhcnkgcG9pbnRlcnMgc2hvdWxkIHRo ZXkgYmUNCj4gdW5hd2FyZSBvZiB3aGF0IGEgY2hhcmFjdGVyIGVuY29kaW5nIGlzLg0KPiA+DQo+ ID4gUHJvcG9zZSByZXNvbHV0aW9uOiBubyBjaGFuZ2VzLg0KPiA+DQo+ID4gQWRkaXNvbiBQaGls bGlwcw0KPiA+IEdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KPiA+IE1lbWJlciAt LSBVbmljb2RlIEVkaXRvcmlhbCBDb21taXR0ZWUNCj4gPg0KPiA+IEludGVybmF0aW9uYWxpemF0 aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQo+ID4gSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBM dHJ1IG1haWxpbmcgbGlzdA0KPiA+IEx0cnVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCj4gPg0KPiANCj4gLS0NCj4gIy0jIE1hcnRpbiBK LiBEw7xyc3QsIFByb2Zlc3NvciwgQW95YW1hIEdha3VpbiBVbml2ZXJzaXR5DQo+ICMtIyBodHRw Oi8vd3d3LnN3Lml0LmFveWFtYS5hYy5qcCAgIG1haWx0bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpw DQo= From addison@amazon.com Wed Apr 29 08:09:11 2009 Return-Path: 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 46BC53A6CCA for ; Wed, 29 Apr 2009 08:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.332 X-Spam-Level: X-Spam-Status: No, score=-106.332 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 3nPc59-EVWEM for ; Wed, 29 Apr 2009 08:09:09 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 13E6F3A7144 for ; Wed, 29 Apr 2009 08:09:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,266,1238976000"; d="scan'208";a="178585344" Received: from smtp-in-4104.sea5.amazon.com ([10.248.183.18]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 15:10:30 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-4104.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TFAT1E018607 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 29 Apr 2009 15:10:29 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Wed, 29 Apr 2009 08:10:29 -0700 From: "Phillips, Addison" To: "Phillips, Addison" , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Date: Wed, 29 Apr 2009 08:10:27 -0700 Thread-Topic: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 Thread-Index: AcnIqEaYUh4gU3G7SMmJitjMJYjjRwAMTwgAAABpJRA= Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A7A6@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A588@EX-SEA5-D.ant.amazon.com> <49F815E6.6040309@it.aoyama.ac.jp> <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A773@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A773@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:09:11 -0000 VGhlIGxhc3QgZW1haWwgY2l0ZWQgYnkgTWFydGluIGNvbnRhaW5zIHNvbWUgYWRkaXRpb25hbCBk aXNjdXNzaW9uIGZyb20gdGhlIEFEIGFib3V0IHRoZSBuZWVkIHRvIHNlcGFyYXRlIFVURi04IGZy b20gdGhlIHJlZ2lzdHJ5IGRlc2NyaXB0aW9uLCBldGMuIFNvIG15IHByb3Bvc2VkIHJlc29sdXRp b24gaXNuJ3QgYSBzaW1wbGUgY3V0LWFuZC1wYXN0ZSBqb2IuIEhlcmUncyB3aGF0IEkgcHJvcG9z ZToNCg0KQ2hhbmdlIHRoZSBmaXJzdCBwYXJhZ3JhcGggZnJvbToNCg0KLS0NClRoZSByZWdpc3Ry eSBpcyBhIFtVbmljb2RlXSB0ZXh0IGZpbGUsIHVzaW5nIHRoZSBVVEYtOCBbUkZDMzYyOV0gY2hh cmFjdGVyIGVuY29kaW5nLCBhbmQgY29uc2lzdHMgb2YgYSBzZXJpZXMgb2YgcmVjb3JkcyBzdG9y ZWQgaW4gYSBmb3JtYXQgYmFzZWQgb24gInJlY29yZC1qYXIiIChkZXNjcmliZWQgaW4gW3JlY29y ZOKAkWphcl0uIEVhY2ggcmVjb3JkLCBpbiB0dXJuLCBjb25zaXN0cyBvZiBhIHNlcmllcyBvZiBm aWVsZHMgdGhhdCBkZXNjcmliZSB0aGUgdmFyaW91cyBzdWJ0YWdzIGFuZCB0YWdzLg0KLS0NCg0K VG8gcmVhZDoNCg0KLS0NClRoZSByZWdpc3RyeSBpcyBhIFtVbmljb2RlXSB0ZXh0IGZpbGUgYW5k IGNvbnNpc3RzIG9mIGEgc2VyaWVzIG9mIHJlY29yZHMgaW4gYSBmb3JtYXQgYmFzZWQgb24gInJl Y29yZC1qYXIiICh3aGljaCBkZXNjcmliZWQgaW4gW3JlY29yZC1qYXJdKS4gRWFjaCByZWNvcmQs IGluIHR1cm4sIGNvbnNpc3RzIG9mIGEgc2VyaWVzIG9mIGZpZWxkcyB0aGF0IGRlc2NyaWJlIHRo ZSB2YXJpb3VzIHN1YnRhZ3MgYW5kIHRhZ3MuIFRoZSBhY3R1YWwgcmVnaXN0cnkgZmlsZSBpcyBl bmNvZGVkIHVzaW5nIHRoZSBVVEYtOCBbUkZDMzYyOV0gY2hhcmFjdGVyIGVuY29kaW5nLg0KLS0N Cg0KVGhlbiwgZnVydGhlciBkb3duLCBjaGFuZ2UgdGhpcyBwYXJhOg0KDQotLQ0KQWx0aG91Z2gg dGhlIGZpbGUgZm9ybWF0IHVzZXMgdGhlIFVURi04IGVuY29kaW5nLCBmaWVsZHMgYXJlIHJlc3Ry aWN0ZWQgdG8gdGhlIHByaW50YWJsZSBjaGFyYWN0ZXJzIGZyb20gdGhlIFVTLUFTQ0lJIFtJU082 NDZdIHJlcGVydG9pcmUgdW5sZXNzIG90aGVyd2lzZSBpbmRpY2F0ZWQgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIGEgc3BlY2lmaWMgZmllbGQtbmFtZSAoUmVjb3JkIGFuZCBGaWVsZCBEZWZpbml0aW9u cykuDQotLQ0KDQpUbyByZWFkOg0KDQotLQ0KPHQ+QWx0aG91Z2ggdGhlIGZpbGUgZm9ybWF0IHVz ZXMgdGhlIFVuaWNvZGUgY2hhcmFjdGVyIHNldCBhbmQgdGhlIGZpbGUgaXRzZWxmIGVuY29kZWQg dXNpbmcgdGhlIFVURi04IGVuY29kaW5nLCBmaWVsZHMgYXJlIHJlc3RyaWN0ZWQgdG8gdGhlIHBy aW50YWJsZSBjaGFyYWN0ZXJzIGZyb20gdGhlIDx4cmVmIHRhcmdldD0iSVNPNjQ2Ij5VUy1BU0NJ STwveHJlZj4gcmVwZXJ0b2lyZSB1bmxlc3Mgb3RoZXJ3aXNlIGluZGljYXRlZCBpbiB0aGUgZGVz Y3JpcHRpb24gb2YgYSBzcGVjaWZpYyA8eHJlZiB0YXJnZXQ9InJlY29yZGZvcm1hdCI+ZmllbGQt bmFtZTwveHJlZj4uPC90Pg0KLS0NCg0KQW5kIGZpbmFsbHksIGJlZm9yZSB0aGUgQUJORiwgY2hh bmdlIHRoaXMgdGV4dDoNCg0KLS0NClRoZSBmb3JtYXQgb2YgdGhlIHJlZ2lzdHJ5IGlzIGRlc2Ny aWJlZCBieSB0aGUgZm9sbG93aW5nIEFCTkYgKHBlciBbUkZDNTIzNF0gKENyb2NrZXIsIEQuIGFu ZCBQLiBPdmVyZWxsLCDigJxBdWdtZW50ZWQgQk5GIGZvciBTeW50YXggU3BlY2lmaWNhdGlvbnM6 IEFCTkYs4oCdIEphbnVhcnkgMjAwOC4pKToNCi0tDQoNClRvIHJlYWQ6DQoNCi0tDQpUaGUgZm9y bWF0IG9mIHRoZSByZWdpc3RyeSBpcyBkZXNjcmliZWQgYnkgdGhlIGZvbGxvd2luZyA8eHJlZiB0 YXJnZXQ9IlJGQzUyMzQiPkFCTkY8L3hyZWY+LiBDaGFyYWN0ZXIgbnVtYmVycyAoY29kZSBwb2lu dHMpIGFyZSB0YWtlbiBmcm9tIFVuaWNvZGUgYW5kIHRlcm1pbmFscyBpbiB0aGUgQUJORiBwcm9k dWN0aW9ucyBhcmUgaW4gdGVybXMgb2YgY2hhcmFjdGVycyByYXRoZXIgdGhhbiBieXRlcy4NCi0t DQoNCg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIx MjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFy Y2hpdGVjdHVyZS4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0 cnUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4g QmVoYWxmIE9mIFBoaWxsaXBzLCBBZGRpc29uDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjks IDIwMDkgNzo1NSBBTQ0KPiBUbzogIk1hcnRpbiBKLiBEw7xyc3QiDQo+IENjOiBMVFJVIFdvcmtp bmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBUaWNrZXQgIzM4LCBBRCBpc3N1ZSAjNTog QUJORiB2cyBVVEYtOA0KPiANCj4gSWYgd2UgaGF2ZSByZXNvbHV0aW9ucywgaXQgd291bGQgYmUg cmVhbGx5IHVzZWZ1bCBpZiB0aGV5IHdlcmUsDQo+IHdlbGwsIHRyYWNrZWQgaW4gdGhlIHRyYWNr ZXIuIEkgZ290IHVwd2FyZHMgb2YgMzAwMCBlbWFpbHMgd2hpbGUgb24NCj4gdmFjYXRpb24gYW5k LCBubywgSSBkaWRuJ3QgcmVhZCB0aGVtIGFsbCA6LSkuDQo+IA0KPiBJIHdpbGwgZXh0cmFjdCB0 aGUgcHJvcG9zZWQgdGV4dCBmcm9tIHRoZXNlIG1lc3NhZ2VzIGFuZA0KPiBpbmNvcnBvcmF0ZSBp dC4NCj4gDQo+IEFkZGlzb24gUGhpbGxpcHMNCj4gR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0g TGFiMTI2DQo+IA0KPiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiBJ dCBpcyBhbiBhcmNoaXRlY3R1cmUuDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+IEZyb206ICJNYXJ0aW4gSi4gRMO8cnN0IiBbbWFpbHRvOmR1ZXJzdEBpdC5hb3lh bWEuYWMuanBdDQo+ID4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyOSwgMjAwOSAxOjU1IEFNDQo+ ID4gVG86IFBoaWxsaXBzLCBBZGRpc29uDQo+ID4gQ2M6IExUUlUgV29ya2luZyBHcm91cA0KPiA+ IFN1YmplY3Q6IFJlOiBbTHRydV0gVGlja2V0ICMzOCwgQUQgaXNzdWUgIzU6IEFCTkYgdnMgVVRG LTgNCj4gPg0KPiA+IEFkZGlzb24sIEkgc3VnZ2VzdCB0aGF0IHdoZXJlIHBvc3NpYmxlLCB5b3Ug Zm9sbG93IHByZXZpb3VzDQo+ID4gZGlzY3Vzc2lvbnMNCj4gPiBvbiB0aGVzZSBpc3N1ZXMuIElu IHBhcnRpY3VsYXIsIGZvciB0aGlzIHNwZWNpZmljIGlzc3VlLCBJIG1hZGUgYQ0KPiA+IHdvcmRp bmcgcHJvcG9zYWwsIGFuZCBBbGV4IHNhaWQgdGhhdCBoZSB3b3VsZCBwcmVmZXIgdGhlIG5ldw0K PiA+IHdvcmRpbmcuDQo+ID4NCj4gPiBNeSBqdWRnZW1lbnQgYXMgYSBjby1jaGFpciBhbmQgc2hl cGhlcmQgaXMgdGhhdCBpZiBvdXIgQUQgcHJlZmVycw0KPiA+IHNvbWV0aGluZywgYW5kIG5vYm9k eSBmcm9tIHRoZSBXRyBvcHBvc2VkLCB0aGVuIHRoYXQncyB3aGF0IHdlDQo+ID4gc2hvdWxkIGRv DQo+ID4gOi0pLg0KPiA+DQo+ID4gRm9yIG1vcmUgZGV0YWlscywgcGxlYXNlIHNlZQ0KPiA+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMTI0NDUu aHRtbA0KPiBhbmQNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbHRy dS9jdXJyZW50L21zZzEyNDUyLmh0bWwuDQo+ID4NCj4gPiBSZWdhcmRzLCAgICBNYXJ0aW4uDQo+ ID4NCj4gPg0KPiA+IE9uIDIwMDkvMDQvMjkgMTI6NTgsIFBoaWxsaXBzLCBBZGRpc29uIHdyb3Rl Og0KPiA+ID4gSW4gdGhpcyBpc3N1ZSwgdGhlIEFEIHN1Z2dlc3RzOg0KPiA+ID4NCj4gPiA+IC0t LQ0KPiA+ID4gW0FCTkYgZXJyb3JdIFdoaWxlIEkgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIGhl cmUsIEkgdGhpbmsgdGhlDQo+ID4gPiBkZWZpbml0aW9uIG9mIENIQVJTIGRvZXNuJ3QgbWF0Y2gg dGhlIHJlcXVpcmVtZW50IHRvIHVzZSBVVEYtOA0KPiA+IGVuY29kaW5nDQo+ID4gPiBzdGF0ZWQg ZWFybGllciBpbiBzZWN0aW9uIDMuMS4xOg0KPiA+ID4NCj4gPiA+ICAgICAgVGhlIHJlZ2lzdHJ5 IGlzIGEgW1VuaWNvZGVdIHRleHQgZmlsZSwgdXNpbmcgdGhlIFVURi04DQo+ID4gW1JGQzM2Mjld DQo+ID4gPiAgICAgIGNoYXJhY3RlciBlbmNvZGluZywgYW5kIGNvbnNpc3RzIG9mIGEgc2VyaWVz IG9mIHJlY29yZHMNCj4gPiBzdG9yZWQgaW4gYQ0KPiA+ID4gICAgICBmb3JtYXQgYmFzZWQgb24g InJlY29yZC1qYXIiIChkZXNjcmliZWQgaW4gW3JlY29yZC1qYXJdKS4NCj4gPiA+DQo+ID4gPiBJ TUhPLCB5b3UgY2FuIHVzZSBBQk5GIHByb2R1Y3Rpb25zIGZyb20gW1JGQzM2MjldIHRvIGZpeCB0 aGF0Lg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhpcyBp cyBuZWNlc3NhcnkgdG8gY2hhbmdlLiBUaGUgcmVnaXN0cnkNCj4gaXMNCj4gPiBhIFVuaWNvZGUg dGV4dCBmaWxlLiBUaGUgY2hhcmFjdGVyIGVuY29kaW5nIHVzZWQgdG8gcmVjb3JkIGl0DQo+ID4g aGFwcGVucyB0byBiZSBVVEYtOCAoYnkgcnVsZSkuIFJlcHJvZHVjaW5nIHRoZSBSRkMgMzYyOSBB Qk5GDQo+ID4gcHJvZHVjdGlvbnMgYXJlIG5vdCBuZWNlc3NhcnksIGFuZCwgaW4gZmFjdCwgd291 bGQgbWFrZSB0aGUgQUJORg0KPiA+IHVubmVjZXNzYXJpbHkgY29tcGxleC4gVGhlIEFCTkYgcHJv ZHVjdGlvbiBpbiB0aGUgY3VycmVudA0KPiBkb2N1bWVudA0KPiA+IGlzOg0KPiA+ID4NCj4gPiA+ ICAgICBDSEFSUyAgICAgID0gKCV4MjEtMTBGRkZGKSAgICAgIDsgVW5pY29kZSBjb2RlIHBvaW50 cw0KPiA+ID4NCj4gPiA+IFRoaXMgcGFydGljdWxhciBwcm9kdWN0aW9uIHdhcyBtb2RlbGVkIG9u IG90aGVycyByZWxhdGVkIHRvDQo+IGNvZGUNCj4gPiBwb2ludHMsIHN1Y2ggYXMgdGhvc2UgaW4g UkZDIDM5ODcuIEl0IGlzIG5vdCBhbiBlcnJvciB0byB0YWxrDQo+IGFib3V0DQo+ID4gY29kZSBw b2ludHMuIFVzZXJzIGFyZSBnaXZlbiB0aGUgbmVjZXNzYXJ5IHBvaW50ZXJzIHNob3VsZCB0aGV5 DQo+IGJlDQo+ID4gdW5hd2FyZSBvZiB3aGF0IGEgY2hhcmFjdGVyIGVuY29kaW5nIGlzLg0KPiA+ ID4NCj4gPiA+IFByb3Bvc2UgcmVzb2x1dGlvbjogbm8gY2hhbmdlcy4NCj4gPiA+DQo+ID4gPiBB ZGRpc29uIFBoaWxsaXBzDQo+ID4gPiBHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYN Cj4gPiA+IE1lbWJlciAtLSBVbmljb2RlIEVkaXRvcmlhbCBDb21taXR0ZWUNCj4gPiA+DQo+ID4g PiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiA+ID4gSXQgaXMgYW4g YXJjaGl0ZWN0dXJlLg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiA+ID4gTHRydUBp ZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1 DQo+ID4gPg0KPiA+DQo+ID4gLS0NCj4gPiAjLSMgTWFydGluIEouIETDvHJzdCwgUHJvZmVzc29y LCBBb3lhbWEgR2FrdWluIFVuaXZlcnNpdHkNCj4gPiAjLSMgaHR0cDovL3d3dy5zdy5pdC5hb3lh bWEuYWMuanAgICBtYWlsdG86ZHVlcnN0QGl0LmFveWFtYS5hYy5qcA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0K PiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHRydQ0K From mark.edward.davis@gmail.com Wed Apr 29 08:17:59 2009 Return-Path: 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 790A93A6CD1 for ; Wed, 29 Apr 2009 08:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 cQdxcYnKZ22b for ; Wed, 29 Apr 2009 08:17:57 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id D1DF93A692F for ; Wed, 29 Apr 2009 08:17:57 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so938785wff.31 for ; Wed, 29 Apr 2009 08:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=0gN1HqUtcfgh6Il42gBnMLs7BUjko30Xh3mz6T0GH7M=; b=qJwoUEj97bnOO8zxxyuym99NJG+5QTCgArTWdORilomom30fiAp9y7ZMADpxJ6WsQA 7efqtVuaiDLV8xuPVzUIDIoaQuAp8gcs5GpmooUBIR+aBSG7B5kVWUxGHKktRkzqh7Hd XE9luqPyihd4fTn/v9aCJOSqHFJhs0Zygl+kY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=c+cO01HdZ1ro37PHxVrd3w0kfMmrV5vgDLhjZ0ZdIcFXOK+F/tUSh69VWmCekRR0L/ HtHJvnXPb8+QkajC0mN1jgMHZk9Gd4VNKURt9fCghlarCYCwqhSc2DFNXM7TqUmBtHFa fKsNVH7Tipn8QyXieM/gyjslgx7TsXOFGlNEU= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.241.15 with SMTP id o15mr111229wfh.258.1241018360050; Wed, 29 Apr 2009 08:19:20 -0700 (PDT) In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A7A6@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A588@EX-SEA5-D.ant.amazon.com> <49F815E6.6040309@it.aoyama.ac.jp> <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A773@EX-SEA5-D.ant.amazon.com> <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A7A6@EX-SEA5-D.ant.amazon.com> Date: Wed, 29 Apr 2009 08:19:20 -0700 X-Google-Sender-Auth: e77c08e843a63430 Message-ID: <30b660a20904290819l31dd6205uae0be48c4bb4dc62@mail.gmail.com> From: Mark Davis To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=000e0cd1469082baa50468b31af0 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:17:59 -0000 --000e0cd1469082baa50468b31af0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Mark On Wed, Apr 29, 2009 at 08:10, Phillips, Addison wrote= : > The last email cited by Martin contains some additional discussion from t= he > AD about the need to separate UTF-8 from the registry description, etc. S= o > my proposed resolution isn't a simple cut-and-paste job. Here's what I > propose: > > Change the first paragraph from: > > -- > The registry is a [Unicode] text file, using the UTF-8 [RFC3629] characte= r > encoding, and consists of a series of records stored in a format based on > "record-jar" (described in [record=E2=80=91jar]. Each record, in turn, co= nsists of a > series of fields that describe the various subtags and tags. > -- > > To read: > > -- > The registry is a [Unicode] text file and consists of a series of records > in a format based on "record-jar" (which described in [record-jar]). Each > record, in turn, consists of a series of fields that describe the various > subtags and tags. The actual registry file is encoded using the UTF-8 > [RFC3629] character encoding. > -- > > Then, further down, change this para: > > -- > Although the file format uses the UTF-8 encoding, fields are restricted t= o > the printable characters from the US-ASCII [ISO646] repertoire unless > otherwise indicated in the description of a specific field-name (Record a= nd > Field Definitions). > -- > > To read: > > -- > Although the file format uses the Unicode character set and the file > itself encoded using the UTF-8 encoding, fields are restricted to the > printable characters from the US-ASCII > repertoire unless otherwise indicated in the description of a specific target=3D"recordformat">field-name. > -- > > And finally, before the ABNF, change this text: > > -- > The format of the registry is described by the following ABNF (per > [RFC5234] (Crocker, D. and P. Overell, =E2=80=9CAugmented BNF for Syntax > Specifications: ABNF,=E2=80=9D January 2008.)): > -- > > To read: > > -- > The format of the registry is described by the following target=3D"RFC5234">ABNF. Character numbers (code points) are taken= from > Unicode and terminals in the ABNF productions are in terms of characters > rather than bytes. > -- > > > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > > Behalf Of Phillips, Addison > > Sent: Wednesday, April 29, 2009 7:55 AM > > To: "Martin J. D=C3=BCrst" > > Cc: LTRU Working Group > > Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 > > > > If we have resolutions, it would be really useful if they were, > > well, tracked in the tracker. I got upwards of 3000 emails while on > > vacation and, no, I didn't read them all :-). > > > > I will extract the proposed text from these messages and > > incorporate it. > > > > Addison Phillips > > Globalization Architect -- Lab126 > > > > Internationalization is not a feature. > > It is an architecture. > > > > > > > -----Original Message----- > > > From: "Martin J. D=C3=BCrst" [mailto:duerst@it.aoyama.ac.jp] > > > Sent: Wednesday, April 29, 2009 1:55 AM > > > To: Phillips, Addison > > > Cc: LTRU Working Group > > > Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 > > > > > > Addison, I suggest that where possible, you follow previous > > > discussions > > > on these issues. In particular, for this specific issue, I made a > > > wording proposal, and Alex said that he would prefer the new > > > wording. > > > > > > My judgement as a co-chair and shepherd is that if our AD prefers > > > something, and nobody from the WG opposed, then that's what we > > > should do > > > :-). > > > > > > For more details, please see > > > http://www.ietf.org/mail-archive/web/ltru/current/msg12445.html > > and > > > http://www.ietf.org/mail-archive/web/ltru/current/msg12452.html. > > > > > > Regards, Martin. > > > > > > > > > On 2009/04/29 12:58, Phillips, Addison wrote: > > > > In this issue, the AD suggests: > > > > > > > > --- > > > > [ABNF error] While I understand what you mean here, I think the > > > > definition of CHARS doesn't match the requirement to use UTF-8 > > > encoding > > > > stated earlier in section 3.1.1: > > > > > > > > The registry is a [Unicode] text file, using the UTF-8 > > > [RFC3629] > > > > character encoding, and consists of a series of records > > > stored in a > > > > format based on "record-jar" (described in [record-jar]). > > > > > > > > IMHO, you can use ABNF productions from [RFC3629] to fix that. > > > > --- > > > > > > > > I don't believe that this is necessary to change. The registry > > is > > > a Unicode text file. The character encoding used to record it > > > happens to be UTF-8 (by rule). Reproducing the RFC 3629 ABNF > > > productions are not necessary, and, in fact, would make the ABNF > > > unnecessarily complex. The ABNF production in the current > > document > > > is: > > > > > > > > CHARS =3D (%x21-10FFFF) ; Unicode code points > > > > > > > > This particular production was modeled on others related to > > code > > > points, such as those in RFC 3987. It is not an error to talk > > about > > > code points. Users are given the necessary pointers should they > > be > > > unaware of what a character encoding is. > > > > > > > > Propose resolution: no changes. > > > > > > > > Addison Phillips > > > > Globalization Architect -- Lab126 > > > > Member -- Unicode Editorial Committee > > > > > > > > Internationalization is not a feature. > > > > It is an architecture. > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ltru > > > > > > > > > > -- > > > #-# Martin J. D=C3=BCrst, Professor, Aoyama Gakuin University > > > #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --000e0cd1469082baa50468b31af0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1

Mark


On Wed, Apr 29, 2009 at 08:10, Phillips,= Addison <addiso= n@amazon.com> wrote:
The last email cited by Martin contains some additional discussion from the= AD about the need to separate UTF-8 from the registry description, etc. So= my proposed resolution isn't a simple cut-and-paste job. Here's wh= at I propose:

Change the first paragraph from:

--
The registry is a [Unicode] text file, using the UTF-8 [RFC3629] character = encoding, and consists of a series of records stored in a format based on &= quot;record-jar" (described in [record=E2=80=91jar]. Each record, in t= urn, consists of a series of fields that describe the various subtags and t= ags.
--

To read:

--
The registry is a [Unicode] text file and consists of a series of records i= n a format based on "record-jar" (which described in [record-jar]= ). Each record, in turn, consists of a series of fields that describe the v= arious subtags and tags. The actual registry file is encoded using the UTF-= 8 [RFC3629] character encoding.
--

Then, further down, change this para:

--
Although the file format uses the UTF-8 encoding, fields are restricted to = the printable characters from the US-ASCII [ISO646] repertoire unless other= wise indicated in the description of a specific field-name (Record and Fiel= d Definitions).
--

To read:

--
<t>Although the file format uses the Unicode character set and the fi= le itself encoded using the UTF-8 encoding, fields are restricted to the pr= intable characters from the <xref target=3D"ISO646">US-ASCI= I</xref> repertoire unless otherwise indicated in the description of = a specific <xref target=3D"recordformat">field-name</xre= f>.</t>
--

And finally, before the ABNF, change this text:

--
The format of the registry is described by the following ABNF (per [RFC5234= ] (Crocker, D. and P. Overell, =E2=80=9CAugmented BNF for Syntax Specificat= ions: ABNF,=E2=80=9D January 2008.)):
--

To read:

--
The format of the registry is described by the following <xref target=3D= "RFC5234">ABNF</xref>. Character numbers (code points) a= re taken from Unicode and terminals in the ABNF productions are in terms of= characters rather than bytes.
--



Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On
> Behalf Of Phillips, Addison
> Sent: Wednesday, April 29, 2009 7:55 AM
> To: "Martin J. D=C3=BCrst"
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8
>
> If we have resolutions, it would be really useful if they were,
> well, tracked in the tracker. I got upwards of 3000 emails while on > vacation and, no, I didn't read them all :-).
>
> I will extract the proposed text from these messages and
> incorporate it.
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
> > -----Original Message-----
> > From: "Martin J. D=C3=BCrst" [mailto:duerst@it.aoyama.ac.jp]
> > Sent: Wednesday, April 29, 2009 1:55 AM
> > To: Phillips, Addison
> > Cc: LTRU Working Group
> > Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8
> >
> > Addison, I suggest that where possible, you follow previous
> > discussions
> > on these issues. In particular, for this specific issue, I made a=
> > wording proposal, and Alex said that he would prefer the new
> > wording.
> >
> > My judgement as a co-chair and shepherd is that if our AD prefers=
> > something, and nobody from the WG opposed, then that's what w= e
> > should do
> > :-).
> >
> > For more details, please see
> > http://www.ietf.org/mail-archive/web/ltru/curr= ent/msg12445.html
> and
> > http://www.ietf.org/mail-archive/web/ltru/curr= ent/msg12452.html.
> >
> > Regards, =C2=A0 =C2=A0Martin.
> >
> >
> > On 2009/04/29 12:58, Phillips, Addison wrote:
> > > In this issue, the AD suggests:
> > >
> > > ---
> > > [ABNF error] While I understand what you mean here, I think = the
> > > definition of CHARS doesn't match the requirement to use= UTF-8
> > encoding
> > > stated earlier in section 3.1.1:
> > >
> > > =C2=A0 =C2=A0 =C2=A0The registry is a [Unicode] text file, u= sing the UTF-8
> > [RFC3629]
> > > =C2=A0 =C2=A0 =C2=A0character encoding, and consists of a se= ries of records
> > stored in a
> > > =C2=A0 =C2=A0 =C2=A0format based on "record-jar" (= described in [record-jar]).
> > >
> > > IMHO, you can use ABNF productions from [RFC3629] to fix tha= t.
> > > ---
> > >
> > > I don't believe that this is necessary to change. The re= gistry
> is
> > a Unicode text file. The character encoding used to record it
> > happens to be UTF-8 (by rule). Reproducing the RFC 3629 ABNF
> > productions are not necessary, and, in fact, would make the ABNF<= br> > > unnecessarily complex. The ABNF production in the current
> document
> > is:
> > >
> > > =C2=A0 =C2=A0 CHARS =C2=A0 =C2=A0 =C2=A0=3D (%x21-10FFFF) = =C2=A0 =C2=A0 =C2=A0; Unicode code points
> > >
> > > This particular production was modeled on others related to<= br> > code
> > points, such as those in RFC 3987. It is not an error to talk
> about
> > code points. Users are given the necessary pointers should they > be
> > unaware of what a character encoding is.
> > >
> > > Propose resolution: no changes.
> > >
> > > Addison Phillips
> > > Globalization Architect -- Lab126
> > > Member -- Unicode Editorial Committee
> > >
> > > Internationalization is not a feature.
> > > It is an architecture.
> > >
> > > _______________________________________________
> > > Ltru mailing list
> > > Ltru@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ltru
> > >
> >
> > --
> > #-# Martin J. D=C3=BCrst, Professor, Aoyama Gakuin University
> > #-# h= ttp://www.sw.it.aoyama.ac.jp =C2=A0 mailto:duerst@it.aoyama.ac.jp
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--000e0cd1469082baa50468b31af0-- From alexey.melnikov@isode.com Wed Apr 29 14:51:48 2009 Return-Path: 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 7B6A63A6C69 for ; Wed, 29 Apr 2009 14:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 3Gdh6cId85Pe for ; Wed, 29 Apr 2009 14:51:47 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A79D43A690D for ; Wed, 29 Apr 2009 14:51:47 -0700 (PDT) Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 29 Apr 2009 22:52:40 +0100 Message-ID: <49F8CBF2.2000707@isode.com> Date: Wed, 29 Apr 2009 22:51:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: LTRU Working Group References: <49E04FF4.1040804@isode.com> In-Reply-To: <49E04FF4.1040804@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:51:48 -0000 Folks, The IETF LC for the document has ended and I am waiting for a new revision that addresses my issues before requesting IESG to review the document. Thank you, Alexey From addison@amazon.com Wed Apr 29 14:53:11 2009 Return-Path: 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 0C9153A6F07 for ; Wed, 29 Apr 2009 14:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 Fc+u5ujvzhQ1 for ; Wed, 29 Apr 2009 14:53:10 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id 39C133A6AF2 for ; Wed, 29 Apr 2009 14:53:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,268,1238976000"; d="scan'208";a="216047700" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 21:54:08 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TLrxef028526 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 29 Apr 2009 21:54:08 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Wed, 29 Apr 2009 14:54:05 -0700 From: "Phillips, Addison" To: Alexey Melnikov , LTRU Working Group Date: Wed, 29 Apr 2009 14:54:04 -0700 Thread-Topic: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt Thread-Index: AcnJFOUlkTZOr/FqTa66bircHcM/yAAAAzAQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6ADFD@EX-SEA5-D.ant.amazon.com> References: <49E04FF4.1040804@isode.com> <49F8CBF2.2000707@isode.com> In-Reply-To: <49F8CBF2.2000707@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:53:11 -0000 KGVkaXRvciBoYXQgb24pIEl0J3MgaW4gcHJvZ3Jlc3MgYW5kIHNob3VsZCBiZSBjb21wbGV0ZWQg Zm9yIFdHIHJldmlldyB0b25pZ2h0Lg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUGhpbGxpcHMNCkds b2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBp cyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgQWxleGV5IE1lbG5pa292DQo+ IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMDkgMjo1MiBQTQ0KPiBUbzogTFRSVSBXb3Jr aW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYt bHRydS00NjQ2YmlzLTIxYmlzLnR4dA0KPiANCj4gRm9sa3MsDQo+IFRoZSBJRVRGIExDIGZvciB0 aGUgZG9jdW1lbnQgaGFzIGVuZGVkIGFuZCBJIGFtIHdhaXRpbmcgZm9yIGEgbmV3DQo+IHJldmlz aW9uIHRoYXQgYWRkcmVzc2VzIG15IGlzc3VlcyBiZWZvcmUgcmVxdWVzdGluZyBJRVNHIHRvIHJl dmlldw0KPiB0aGUNCj4gZG9jdW1lbnQuDQo+IA0KPiBUaGFuayB5b3UsDQo+IEFsZXhleQ0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRy dSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== From addison@amazon.com Wed Apr 29 15:28:20 2009 Return-Path: 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 AE4A33A6E21 for ; Wed, 29 Apr 2009 15:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 EVkx4tBEtlTv for ; Wed, 29 Apr 2009 15:28:19 -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 A37483A6DE8 for ; Wed, 29 Apr 2009 15:28:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,268,1238976000"; d="scan'208";a="260104571" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 22:29:41 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TMTetn002091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 22:29:40 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Wed, 29 Apr 2009 15:29:40 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 15:29:38 -0700 Thread-Topic: Ticket #43: AD Issue #10: File-Date value Thread-Index: AcnJGfuhh3jss6BPS/293OKRY1mIRQ== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AE8A@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #43: AD Issue #10: File-Date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:28:20 -0000 VGhlIEFEIG5vdGljZXMgdGhhdDoNCg0KLS0NCkFEIHJldmlldyBjb21tZW50ICMxMCBmcm9tDQpo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbHRydS9jdXJyZW50L21zZzEyMzk5 Lmh0bWwNCg0KMTApLg0KDQogICAgNS4xLiBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkNCg0KICAg IFsuLi5dDQoNCiAgICBXaGVuZXZlciBhbiBlbnRyeSBpcyBjcmVhdGVkIG9yIG1vZGlmaWVkIGlu IHRoZSByZWdpc3RyeSwgdGhlICdGaWxlLQ0KICAgIERhdGUnIHJlY29yZCBhdCB0aGUgc3RhcnQg b2YgdGhlIHJlZ2lzdHJ5IGlzIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUNCiAgICBtb3N0IHJlY2Vu dCBtb2RpZmljYXRpb24gZGF0ZSBpbiB0aGUgW1JGQzMzMzldICJmdWxsLWRhdGUiIGZvcm1hdDoN CiAgICBpbmNsdWRlZCBpbiBhbnkgcmVxdWVzdCB0byBpbnNlcnQgb3IgbW9kaWZ5IHJlY29yZHMg d2lsbCBiZSBhIG5ldw0KICAgIEZpbGUtRGF0ZSByZWNvcmQgaW5kaWNhdGluZyB0aGUgYWNjZXB0 YW5jZSBkYXRlIG9mIHRoZSByZWNvcmQuIFRoaXMNCiAgICByZWNvcmQgaXMgdG8gYmUgcGxhY2Vk IGZpcnN0IGluIHRoZSByZWdpc3RyeSwgcmVwbGFjaW5nIHRoZSBleGlzdGluZw0KICAgIEZpbGUt RGF0ZSByZWNvcmQuIEluIHRoZSBldmVudCB0aGF0IHRoZSBGaWxlLURhdGUgcmVjb3JkIHByZXNl bnQgaW4NCiAgICB0aGUgcmVnaXN0cnkgaGFzIGEgbGF0ZXIgZGF0ZSB0aGFuIHRoZSByZWNvcmQg YmVpbmcgaW5zZXJ0ZWQgb3INCiAgICBtb2RpZmllZCwgdGhlbiB0aGUgbGF0ZXN0IChtb3N0IHJl Y2VudCkgcmVjb3JkIHdpbGwgYmUgcHJlc2VydmVkLg0KDQpJIGFtIGNvbmZ1c2VkIGJ5IHdoaWNo IGRhdGUgaXMgZ29pbmcgdG8gYmUgdXNlZCBieSBJQU5BIGluIHRoaXMgY2FzZS4NClNlY3Rpb24g My4xLjIgc2F5czoNCg0KICAgIFRoZSBmaXJzdCByZWNvcmQgaW4gdGhlIHJlZ2lzdHJ5IGlzIGFs d2F5cyB0aGUgIkZpbGUtRGF0ZSIgcmVjb3JkLg0KICAgIFRoaXMgcmVjb3JkIG9jY3VycyBvbmx5 IG9uY2UgaW4gdGhlIGZpbGUgYW5kIGNvbnRhaW5zIGEgc2luZ2xlIGZpZWxkDQogICAgd2hvc2Ug ZmllbGQtbmFtZSBpcyAiRmlsZS1EYXRlIi4gVGhlIGZpZWxkLWJvZHkgb2YgdGhpcyByZWNvcmQN CiAgICBjb250YWlucyB0aGUgbGFzdCBtb2RpZmljYXRpb24gZGF0ZSBvZiB0aGlzIGNvcHkgb2Yg dGhlIHJlZ2lzdHJ5LA0KICAgIG1ha2luZyBpdCBwb3NzaWJsZSB0byBjb21wYXJlIGRpZmZlcmVu dCB2ZXJzaW9ucyBvZiB0aGUgcmVnaXN0cnkuDQoNCkkgdGhpbmsgaWYgRmlsZS1EYXRlIHJlY29y ZCBwcmVzZW50IGluIHRoZSByZWdpc3RyeSBoYXMgYSBsYXRlciBkYXRlDQp0aGFuIHRoZSByZWNv cmQgYmVpbmcgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQsIHRoZW4gSUFOQSBzaG91bGQgdXNlIHRoZQ0K ZGF0ZSBvZiB1cGRhdGUgKHdoaWNoIEkgYXNzdW1lIHdvdWxkIGJlIGFmdGVyIHRoZSByZWNvcmQN Cm1vZGlmaWNhdGlvbi9hZGRpdGlvbiBkYXRlKS4gVGhpcyB3YXkgYW55IGNoYW5nZSB0byB0aGUg SUFOQSByZWdpc3RyeQ0KY2FuIGJlIGRldGVjdGVkLg0KLS0NCg0KVGhlIEFEIGhhcyBhIHBvaW50 LiBIb3dldmVyLCB0aGUgcmVhc29uIHdlIGRvbid0IHB1dCAidG9kYXkncyBkYXRlIiBpbnRvIHRo ZSBmaWxlIGlzIHRoYXQgdGhlIHJlY29yZHMgYXJlIHNlcGFyYXRlbHkgcHJlc2VydmVkIGJ5IElB TkEsIGluY2x1ZGluZyB0aGUgZGF0ZSBmaWVsZHMuIE5vdGUgdGhhdCB0aGUgQUQgZGlkbid0IHF1 b3RlIHRoZSBwYXJ0IGFib3V0IGhhbmRsaW5nIGluc2VydGlvbnMgaW4gZGF0ZSBvcmRlci4NCg0K U3RpbGwsIHdlIGNvdWxkIGNsYXJpZnkgdGhlIHRleHQuDQoNClByb3Bvc2VkIHJlc29sdXRpb246 DQoNCkZvciBjb25zaXN0ZW5jeSwgY2hhbmdlIHRoZSB0ZXh0IGluIHNlY3Rpb24gMy4xLjIgZnJv bToNCg0KLS0NCjx0PlRoZSBmaXJzdCByZWNvcmQgaW4gdGhlIHJlZ2lzdHJ5IGlzIGFsd2F5cyB0 aGUgIkZpbGUtRGF0ZSIgcmVjb3JkLiBUaGlzIHJlY29yZCBvY2N1cnMgb25seSBvbmNlIGluIHRo ZSBmaWxlIGFuZCBjb250YWlucyBhIHNpbmdsZSBmaWVsZCB3aG9zZSBmaWVsZC1uYW1lIGlzICJG aWxlLURhdGUiLiBUaGUgZmllbGQtYm9keSBvZiB0aGlzIHJlY29yZCBjb250YWlucyB0aGUgbGFz dA0KbW9kaWZpY2F0aW9uIGRhdGUgb2YgdGhpcyBjb3B5IG9mIHRoZSByZWdpc3RyeSwgbWFraW5n IGl0IHBvc3NpYmxlIHRvIGNvbXBhcmUgZGlmZmVyZW50IHZlcnNpb25zIG9mIHRoZSByZWdpc3Ry eS4gIFRoZSByZWdpc3RyeSBvbiB0aGUgSUFOQSB3ZWJzaXRlIGlzDQp0aGUgbW9zdCBjdXJyZW50 LiAgIFZlcnNpb25zIHdpdGggYW4gb2xkZXIgZGF0ZSB0aGFuIHRoYXQgb25lDQphcmUgbm90IHVw LXRvLWRhdGUuPC90Pg0KLS0NCg0KVG8gcmVhZDoNCg0KLS0NCjx0PlRoZSBmaXJzdCByZWNvcmQg aW4gdGhlIHJlZ2lzdHJ5IGlzIGFsd2F5cyB0aGUgIkZpbGUtRGF0ZSIgcmVjb3JkLiBUaGlzIHJl Y29yZCBvY2N1cnMgb25seSBvbmNlIGluIHRoZSBmaWxlIGFuZCBjb250YWlucyBhIHNpbmdsZSBm aWVsZCB3aG9zZSBmaWVsZC1uYW1lIGlzICJGaWxlLURhdGUiLiBUaGUgZmllbGQtYm9keSBvZiB0 aGlzIHJlY29yZCBjb250YWlucyB0aGUgYXBwcm92YWwgZGF0ZSBvZiB0aGUgbW9zdCByZWNlbnQg Y2hhbmdlIHRvIHRoZSByZWdpc3RyeSwgbWFraW5nIGl0IHBvc3NpYmxlIHRvIGNvbXBhcmUgZGlm ZmVyZW50IHZlcnNpb25zIG9mIHRoZSByZWdpc3RyeS4gIFRoZSByZWdpc3RyeSBvbiB0aGUgSUFO QSB3ZWJzaXRlIGlzDQp0aGUgbW9zdCBjdXJyZW50LiAgIFZlcnNpb25zIHdpdGggYW4gb2xkZXIg ZGF0ZSB0aGFuIHRoYXQgb25lDQphcmUgbm90IHVwLXRvLWRhdGUuPC90Pg0KLS0NCg0KQWRkaXNv biBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVybmF0 aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQoN Cg0K From addison@amazon.com Wed Apr 29 15:34:59 2009 Return-Path: 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 BCDAB3A6EF5 for ; Wed, 29 Apr 2009 15:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 uyuM8unMNxvx for ; Wed, 29 Apr 2009 15:34:54 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id D49F83A6D07 for ; Wed, 29 Apr 2009 15:34:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,268,1238976000"; d="scan'208";a="216061090" Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 22:36:16 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3TMaF6J012986 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 22:36:16 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Wed, 29 Apr 2009 15:36:15 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 15:36:13 -0700 Thread-Topic: Ticket #44: AD Issue #11: informative reference to MIME Thread-Index: AcnJGubo/zZhwLHgQOiT77HHnzaLlA== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEA7@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #44: AD Issue #11: informative reference to MIME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:34:59 -0000 VGhlIEFEIHN1Z2dlc3RzOg0KDQotLQ0KQUQgcmV2aWV3IGNvbW1lbnQgIzExIGZyb20NCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMTIzOTkuaHRt bA0KDQoxMSkuDQoNCiAgICA0LjIuIE1lYW5pbmcgb2YgdGhlIExhbmd1YWdlIFRhZw0KDQogICAg Wy4uLl0NCg0KICAgIG8gRm9yIGluZm9ybWF0aW9uIG9iamVjdHMgd2hvc2UgcHVycG9zZSBpcyB0 byBwcm92aWRlIGFsdGVybmF0aXZlcywNCiAgICB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0YWdz IGNvdWxkIGJlIHJlZ2FyZGVkIGFzIGEgaGludCB0aGF0IHRoZQ0KICAgIGNvbnRlbnQgaXMgcHJv dmlkZWQgaW4gc2V2ZXJhbCBsYW5ndWFnZXMgYW5kIHRoYXQgb25lIGhhcyB0bw0KICAgIGluc3Bl Y3QgZWFjaCBvZiB0aGUgYWx0ZXJuYXRpdmVzIGluIG9yZGVyIHRvIGZpbmQgaXRzIGxhbmd1YWdl IG9yDQogICAgbGFuZ3VhZ2VzLiBJbiB0aGlzIGNhc2UsIHRoZSBwcmVzZW5jZSBvZiBtdWx0aXBs ZSB0YWdzIG1pZ2h0IG5vdA0KICAgIG1lYW4gdGhhdCBvbmUgbmVlZHMgdG8gYmUgbXVsdGktbGlu Z3VhbCB0byBnZXQgY29tcGxldGUNCiAgICB1bmRlcnN0YW5kaW5nIG9mIHRoZSBkb2N1bWVudC4g RXhhbXBsZTogTUlNRSBtdWx0aXBhcnQvDQogICAgYWx0ZXJuYXRpdmUuDQoNCkkgdGhpbmsgdGhp cyBuZWVkcyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gTUlNRS4NCi0tDQoNClNpbXBsZSBl bm91Z2guDQoNClByb3Bvc2VkIHJlc29sdXRpb246DQoNCkluc2VydGVkIGFuIGluZm9ybWF0aXZl IHJlZmVyZW5jZSB0byBSRkMgMjA0Ni4NCg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlv biBBcmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZl YXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQoNCg0K From addison@amazon.com Wed Apr 29 15:42:09 2009 Return-Path: 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 AD1013A696F for ; Wed, 29 Apr 2009 15:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 8e57zB5mQIaF for ; Wed, 29 Apr 2009 15:42:09 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id B0F3A3A67F8 for ; Wed, 29 Apr 2009 15:42:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208";a="178811635" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 22:43:30 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TMhMJw005737 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 22:43:30 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Wed, 29 Apr 2009 15:43:24 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 15:43:22 -0700 Thread-Topic: Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping Thread-Index: AcnJG+a4aiBvlTyxSXuTB+7LC0CJZA== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEBB@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:42:09 -0000 VGhlIEFEIGFza2VkOg0KDQotLQ0KQUQgcmV2aWV3IGNvbW1lbnQgIzEyIGZyb20NCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMTIzOTkuaHRtbA0K DQoxMikuDQoNCiAgICA0LjUuIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0KDQog ICAgWy4uLl0NCg0KICAgIDMuIFN1YnRhZ3Mgb2YgdHlwZSAnZXh0bGFuZycgU0hPVUxEIGJlIG1h cHBlZCB0byB0aGVpciBQcmVmZXJyZWQtDQogICAgVmFsdWUuDQoNCldoeSB1c2Ugb2YgU0hPVUxE IGhlcmU/IEkuZS4gd2hhdCBpcyBhIGdvb2QgcmVhc29uIGZvciB2aW9sYXRpbmcgdGhpcyBydWxl Pw0KQSBwb2ludGVyIGhlcmUgdG8gc29tZSBjYXNlKHMpIHdvdWxkIGJlIGFwcHJlY2lhdGVkIGhl cmUuDQoNCiAgICBUaGUgZmllbGQtYm9keSBvZiB0aGUgUHJlZmVycmVkLVZhbHVlIGZvciBleHRs YW5ncyBpcyBhbg0KICAgICJleHRlbmRlZCBsYW5ndWFnZSByYW5nZSIgYW5kIHR5cGljYWxseSBt YXBzIHRvIGEgcHJpbWFyeQ0KICAgIGxhbmd1YWdlIHN1YnRhZy4gRm9yIGV4YW1wbGUsIHRoZSBz dWJ0YWcgc2VxdWVuY2UgInpoLWhhayINCiAgICAoQ2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJl cGxhY2VkIHdpdGggdGhlIHRhZyAiaGFrIiAoSGFra2ENCi0tDQoNClRoZSBrZXl3b3JkIGlzIChj b3JyZWN0bHkpIFNIT1VMRCBiZWNhdXNlIHJlbW92aW5nIHRoZSBwcmltYXJ5IGxhbmd1YWdlIHN1 YnRhZyByZW1vdmVzIGluZm9ybWF0aW9uIHRoYXQgc29tZSBhcHBsaWNhdGlvbnMgbWF5IHdpc2gg dG8gcHJlc2VydmUuDQoNClByb3Bvc2VkIHJlc29sdXRpb246DQoNCkFkZCB0aGlzIHRleHQgdG8g dGhlIGFib3ZlIHBhcmFncmFwaCwgaW5kaWNhdGluZyB3aHkgeW91IG1pZ2h0IG5vdCBwZXJmb3Jt IHRoZSBtYXBwaW5nOg0KDQotLQ0KQmVjYXVzZSB0aGlzIGludm9sdmVzIHJlbW92aW5nIHRoZSBt YWNyb2xhbmd1YWdlIGluZm9ybWF0aW9uIGZyb20gdGhlIHRhZywgYW4gaW1wbGVtZW50YXRpb24g bWlnaHQgY2hvb3NlIG5vdCB0byBwZXJmb3JtIHRoaXMgcGFydGljdWxhciBjYW5vbmljYWxpemF0 aW9uLCBpZiBzdWNoIGEgY2Fub25pY2FsaXphdGlvbiB3b3VsZCByZWR1Y2UgdGhlIGVmZmVjdGl2 ZW5lc3Mgb2YgdGhhdCByZXN1bHRpbmcgdGFncyBmb3IgbWF0Y2hpbmcgb3Igc2VsZWN0aW9uIGxh dGVyLg0KLS0NCg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0g TGFiMTI2DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBh biBhcmNoaXRlY3R1cmUuDQoNCg0K From addison@amazon.com Wed Apr 29 15:43:18 2009 Return-Path: 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 3E57628C2DE for ; Wed, 29 Apr 2009 15:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 2gbSGfxB+TMq for ; Wed, 29 Apr 2009 15:43:17 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 4CE4728C2CB for ; Wed, 29 Apr 2009 15:43:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208";a="178812117" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 22:44:39 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TMic91017565 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 22:44:38 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Wed, 29 Apr 2009 15:44:38 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 15:44:36 -0700 Thread-Topic: Ticket #46: AD Issue #13: MAY->can in 4.6 Thread-Index: AcnJHBKX6NFGfESyQJ6zGzAq2Zh5UA== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEBD@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #46: AD Issue #13: MAY->can in 4.6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:43:18 -0000 VGhlIEFEIGNvbW1lbnRlZDoNCg0KLS0NCkNvbW1lbnQgIzEzIGZyb20gdGhlIEFEIHJldmlldyBp bg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cx MjM5OS5odG1sDQoNCjEzKS4NCg0KICAgIDQuNi4gQ29uc2lkZXJhdGlvbnMgZm9yIFByaXZhdGUg VXNlIFN1YnRhZ3MNCg0KICAgIFsuLi5dDQoNCiAgICBIb3dldmVyLCBpbiBzb21lIGNhc2VzIGNv bnRlbnQgdGFnZ2VkIHdpdGggcHJpdmF0ZSB1c2Ugc3VidGFncyBNQVkNCiAgICBpbnRlcmFjdCB3 aXRoIG90aGVyIHN5c3RlbXMgaW4gYSBkaWZmZXJlbnQgYW5kIHBvc3NpYmx5IHVuc3VpdGFibGUN CiAgICBtYW5uZXIgY29tcGFyZWQgdG8gdGFncyB0aGF0IHVzZSBvcGFxdWUsIHByaXZhdGVseSBk ZWZpbmVkIHN1YnRhZ3MsDQogICAgc28gdGhlIGNob2ljZSBvZiB0aGUgYmVzdCBhcHByb2FjaCBz b21ldGltZXMgZGVwZW5kcyBvbiB0aGUNCiAgICBwYXJ0aWN1bGFyIGRvbWFpbiBpbiBxdWVzdGlv bi4NCg0KSSB0aGluayB1c2Ugb2YgTUFZIGlzIGltcHJvcGVyIGhlcmUgYW5kIEkgc3VnZ2VzdCBj aGFuZ2luZyBpdCB0byAiY2FuIg0KLS0NCg0KUHJvcG9zZWQgcmVzb2x1dGlvbjogY2hhbmdlZCB0 byAnY2FuJy4NCg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0g TGFiMTI2DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBh biBhcmNoaXRlY3R1cmUuDQoNCg0K From addison@amazon.com Wed Apr 29 15:51:50 2009 Return-Path: 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 54F933A696F for ; Wed, 29 Apr 2009 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 T+tPNY7QbsnU for ; Wed, 29 Apr 2009 15:51:49 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 9FCC43A6BA5 for ; Wed, 29 Apr 2009 15:51:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208";a="178815300" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 22:53:08 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TMr7Iu016686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 22:53:08 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Wed, 29 Apr 2009 15:53:07 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 15:53:05 -0700 Thread-Topic: Ticket #47: AD Issue #14: section 3.1.2 confusing text on replacement tags Thread-Index: AcnJHUHGeYbwQhr2TPuwjsVzMw854A== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AED3@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #47: AD Issue #14: section 3.1.2 confusing text on replacement tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:51:50 -0000 VGhlIEFEIHN1Z2dlc3RzOg0KDQotLQ0KICAgICArIEZvciBmaWVsZHMgb2YgdHlwZSAnZXh0bGFu ZycsICdncmFuZGZhdGhlcmVkJywgb3INCiAgICAncmVkdW5kYW50JywgJ1ByZWZlcnJlZC1WYWx1 ZScgY29udGFpbnMgYW4gImV4dGVuZGVkDQogICAgbGFuZ3VhZ2UgcmFuZ2UiIChbUkZDNDY0N10p IHRoYXQgaXMgcHJlZmVycmVkIGZvciBmb3JtaW5nDQogICAgdGhlIGxhbmd1YWdlIHRhZy4gVGhh dCBpcywgZWFjaCBvZiB0aGUgc3VidGFncyB0aGF0IGFwcGVhcnMNCiAgICBpbiB0aGUgdmFsdWUg TVVTVCBhcHBlYXIgaW4gdGhlIHJlcGxhY2VtZW50IHRhZzsNCg0KWW91IGxvc3QgbWUgaGVyZTog d2hhdCBpcyAidGhlIHZhbHVlIiBhbmQgd2hhdCBpcyAidGhlIHJlcGxhY2VtZW50IHRhZyINCmlu IHRoaXMgY2FzZS4NCg0KLS0NCg0KUHJvcG9zZWQgcmVzb2x1dGlvbjoNCg0KQ2hhbmdlZCB0aGUg YWJvdmUgdGV4dCB0byByZWFkOg0KDQotLQ0KRm9yIGZpZWxkcyBvZiB0eXBlICdleHRsYW5nJywg J2dyYW5kZmF0aGVyZWQnLCBvciAncmVkdW5kYW50JywgJ1ByZWZlcnJlZC1WYWx1ZScgY29udGFp bnMgYW4gImV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIiAoPHhyZWYgdGFyZ2V0PSJSRkM0NjQ3Ij48 L3hyZWY+KSB0aGF0IGlzIHByZWZlcnJlZCBmb3IgZm9ybWluZyB0aGUgbGFuZ3VhZ2UgdGFnLiBU aGF0IGlzLCB0aGUgcHJlZmVycmVkIGxhbmd1YWdlIHRhZyB3aWxsIGNvbnRhaW4sIGluIG9yZGVy LCBlYWNoIG9mIHRoZSBzdWJ0YWdzIHRoYXQgYXBwZWFycyBpbiB0aGUgUHJlZmVycmVkLVZhbHVl OyBhZGRpdGlvbmFsIGZpZWxkcyBjYW4gYmUgaW5jbHVkZWQgaW4gYSBsYW5ndWFnZSB0YWcgYXMg ZGVzY3JpYmVkIGVsc2V3aGVyZSBpbiB0aGlzIGRvY3VtZW50Lg0KLS0NCg0KQWRkaXNvbiBQaGls bGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVybmF0aW9uYWxp emF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQoNCg0K From addison@amazon.com Wed Apr 29 15:53:49 2009 Return-Path: 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 A02943A6D7E for ; Wed, 29 Apr 2009 15:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 Jn4XRUPfh-7V for ; Wed, 29 Apr 2009 15:53:48 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id D81353A6ABB for ; Wed, 29 Apr 2009 15:53:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208";a="216066436" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 22:55:11 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TMt9Ic018960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 22:55:10 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Wed, 29 Apr 2009 15:55:02 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 15:54:59 -0700 Thread-Topic: Ticket #39: AD Issues #6: field name occurance limit Thread-Index: AcnJHYYlrFpiBLbdQeK0vVy2Hxrmiw== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEDD@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #39: AD Issues #6: field name occurance limit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:53:49 -0000 VGhlIEFEIHN1Z2dlc3RzOg0KDQotLQ0KQ29tbWVudCAjNiBmcm9tIHRoZSBBRCByZXZpZXcgLSBz ZWUNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNn MTIzOTkuaHRtbA0KDQo2KS4gSW4gU2VjdGlvbiAzLjEuMjoNCg0KICAgIEZpZWxkLW5hbWVzIE1V U1Qgb2NjdXIgbm8gbW9yZQ0KICAgIHRoYW4gb25jZSBwZXIgcmVjb3JkLCB3aXRoIHRoZSBleGNl cHRpb24gb2YgdGhlICdEZXNjcmlwdGlvbicsDQogICAgJ0NvbW1lbnRzJywgYW5kIHNvbWV0aW1l cyB0aGUgJ1ByZWZpeCcgZmllbGQuDQoNCihuaXQpIFN1Z2dlc3Rpb24gdG8gcmV3b3JkIHVzaW5n IE1VU1QgTk9ULiBFLmcuOg0KDQogICAgRmllbGQtbmFtZXMgTVVTVCBOT1Qgb2NjdXIgbW9yZQ0K ICAgIHRoYW4gb25jZSBwZXIgcmVjb3JkLCB3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhlICdEZXNj cmlwdGlvbicsDQogICAgJ0NvbW1lbnRzJywgYW5kIHNvbWV0aW1lcyB0aGUgJ1ByZWZpeCcgZmll bGQuDQotLQ0KDQpQcm9wb3NlZCBSZXNvbHV0aW9uOiBtYWRlIHRoaXMgY2hhbmdlLg0KDQpBZGRp c29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJu YXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4N Cg0KDQo= From addison@amazon.com Wed Apr 29 15:56:11 2009 Return-Path: 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 060133A6D7E for ; Wed, 29 Apr 2009 15:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 nMbOZuC5ibGF for ; Wed, 29 Apr 2009 15:56:10 -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 5010B3A6DBD for ; Wed, 29 Apr 2009 15:56:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208";a="260116025" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 22:57:31 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3TMvUN7026448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 22:57:31 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Wed, 29 Apr 2009 15:57:30 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 15:57:29 -0700 Thread-Topic: Ticket #41: AD Issue #8: section 3.5 SHOULD vs. MUST Thread-Index: AcnJHd8oZCJQKSsBTRmZxB1qvamHrg== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEE3@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #41: AD Issue #8: section 3.5 SHOULD vs. MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:56:11 -0000 VGhlIEFEIGlucXVpcmVzOg0KDQotLQ0KQUQgcmV2aWV3IGNvbW1lbnQgbnVtYmVyIDggZnJvbQ0K aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cxMjM5 OS5odG1sDQoNCjgpLiBJbiBTZWN0aW9uIDMuNToNCg0KICAgIFRoZSBmaWVsZHMgaW4gdGhlICJS ZWNvcmQgUmVxdWVzdGVkIiBzZWN0aW9uIFNIT1VMRCBmb2xsb3cgdGhlDQogICAgcmVxdWlyZW1l bnRzIGluIFNlY3Rpb24gMy4xLg0KDQpXaGF0IGFyZSB0aGUgcmVhc29ucyBub3QgdG8gZm9sbG93 IHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDMuMT8NCihJLmUuIHdoeSBpcyBTSE9VTEQgdXNlZCBp bnN0ZWFkIG9mIE1VU1Q/KQ0KLS0NCg0KR29vZCBxdWVzdGlvbi4NCg0KUHJvcG9zZWQgUmVzb2x1 dGlvbjogcy9TSE9VTEQvTVVTVC8gaW4gdGhpcyBzZW50ZW5jZS4NCg0KQWRkaXNvbiBQaGlsbGlw cw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVybmF0aW9uYWxpemF0 aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQoNCg0K From cowan@ccil.org Wed Apr 29 16:02:04 2009 Return-Path: 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 099503A6C3D for ; Wed, 29 Apr 2009 16:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_05=-1.11] 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 HEfSFB-04So5 for ; Wed, 29 Apr 2009 16:02:03 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 50BBD3A6A9E for ; Wed, 29 Apr 2009 16:02:03 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LzIoH-0003HH-8m; Wed, 29 Apr 2009 19:03:25 -0400 Date: Wed, 29 Apr 2009 19:03:25 -0400 To: "Phillips, Addison" Message-ID: <20090429230325.GH7401@mercury.ccil.org> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEE3@EX-SEA5-D.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEE3@EX-SEA5-D.ant.amazon.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #41: AD Issue #8: section 3.5 SHOULD vs. MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:02:04 -0000 Phillips, Addison scripsit: > What are the reasons not to follow requirements in Section 3.1? > (I.e. why is SHOULD used instead of MUST?) The reason, as stated in earlier emails, is that we want people to be able to submit mildly incorrect forms without being REQUIRED to heave them overboard. MUST is used further down, when the forms are sent from the LSR to IANA. -- John Cowan cowan@ccil.org "Mr. Lane, if you ever wish anything that I can do, all you will have to do will be to send me a telegram asking and it will be done." "Mr. Hearst, if you ever get a telegram from me asking you to do anything, you can put the telegram down as a forgery." From addison@amazon.com Wed Apr 29 16:16:49 2009 Return-Path: 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 237843A68F2 for ; Wed, 29 Apr 2009 16:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 Z+CT2Tnf6Dfo for ; Wed, 29 Apr 2009 16:16:48 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 032273A68BC for ; Wed, 29 Apr 2009 16:16:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208";a="178824357" Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 23:18:09 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3TNI91x029420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 23:18:09 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Wed, 29 Apr 2009 16:18:08 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 16:18:07 -0700 Thread-Topic: Ticket #42: AD Issue #9: confusing future tense Thread-Index: AcnJIMGHHuDoPTKlTVW0jjBq46vGvg== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AF24@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] Ticket #42: AD Issue #9: confusing future tense X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:16:49 -0000 VGhlIEFEIGNvbW1lbnRlZDoNCg0KLS0NCkFEIHJldmlldyBjb21tZW50ICM5IGZyb20NCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMTIzOTkuaHRt bA0KDQo5KS4NCg0KICAgIDMuOC4gVXBkYXRlIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0 cnkNCg0KICAgIFVwb24gYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB0aGUgSUFOQSBMYW5ndWFn ZSBTdWJ0YWcgUmVnaXN0cnkgd2lsbA0KICAgIG5lZWQgYW4gdXBkYXRlIHNvIHRoYXQgaXQgY29u dGFpbnMgdGhlIGNvbXBsZXRlIHNldCBvZiBzdWJ0YWdzIHZhbGlkDQogICAgaW4gYSBsYW5ndWFn ZSB0YWcuIFRoaXMgY29sbGVjdGlvbiBvZiBzdWJ0YWdzLCBhbG9uZyB3aXRoIGENCiAgICBkZXNj cmlwdGlvbiBvZiB0aGUgcHJvY2VzcyB1c2VkIHRvIGNyZWF0ZSBpdCwgaXMgZGVzY3JpYmVkIGJ5 DQogICAgW2RyYWZ0LTQ2NDViaXNdLiBJQU5BIHdpbGwgcHVibGlzaCB0aGUgdXBkYXRlZCB2ZXJz aW9uIG9mIHRoZQ0KICAgIHJlZ2lzdHJ5IGRlc2NyaWJlZCBieSB0aGlzIGRvY3VtZW50IHVzaW5n IHRoZSBpbnN0cnVjdGlvbnMgYW5kDQogICAgY29udGVudCBvZiBbZHJhZnQtNDY0NWJpc10uDQoN CihuaXQpIEkgdGhpbmsgYm90aCA0NjQ1YmlzIGFuZCA0NjQ2YmlzIHNob3VsZCBiZSBwdWJsaXNo ZWQgYXQgdGhlIHNhbWUgdGltZS4NCklmIHRoaXMgaGFwcGVucywgdGhlbiB1c2Ugb2YgZnV0dXJl IHRlbnNlIGluIHRoZSBwdWJsaXNoZWQgUkZDIHdvdWxkIGJlDQpjb25mdXNpbmcgYW5kIHdpbGwg bm90IG1hdGNoIHRoZSByZWFsaXR5Lg0KDQpJIHN1Z2dlc3QgYWRkaW5nIGFuIFJGQyBFZGl0b3Ig bm90ZSBhc2tpbmcgdG8gZml4IHRoaXMgc2VudGVuY2UuDQoNCiAgICBPbmNlIHB1Ymxpc2hlZCBi eSBJQU5BLCB0aGUgbWFpbnRlbmFuY2UNCiAgICBwcm9jZWR1cmVzLCBydWxlcywgYW5kIHJlZ2lz dHJhdGlvbiBwcm9jZXNzZXMgZGVzY3JpYmVkIGluIHRoaXMNCiAgICBkb2N1bWVudCB3aWxsIGJl IGF2YWlsYWJsZSBmb3IgbmV3IHJlZ2lzdHJhdGlvbnMgb3IgdXBkYXRlcy4NCi0tDQoNClByb3Bv c2VkIFJlc29sdXRpb246IA0KDQpOb3RlIHRoYXQgdGhpcyBpcyB0ZXh0IG9ubHkgbWlsZGx5IG1v ZGlmaWVkIGZyb20gNDY0Ni4gSSBpbnNlcnRlZCBhbiBSRkMgRWRpdG9yIG5vdGUgc2F5aW5nOg0K DQpSRkMgRWRpdG9yOiBwbGVhc2UgbW9kaWZ5IHRoaXMgcGFyYWdyYXBoIHVwb24gcHVibGljYXRp b24gdG8gcmVmbGVjdCB0aGUgZmFjdCB0aGF0IFJGQyA0NjQ1YmlzIGhhcyBhbHNvIGJlZW4gcHVi bGlzaGVkIChwYXN0IHRlbnNlKS4NCg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9u IEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVh dHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KDQo= From addison@amazon.com Wed Apr 29 16:19:48 2009 Return-Path: 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 864703A6D6D for ; Wed, 29 Apr 2009 16:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 cPhV1spJRIcD for ; Wed, 29 Apr 2009 16:19:47 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 8E5AB3A6AB4 for ; Wed, 29 Apr 2009 16:19:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208";a="178825344" Received: from smtp-in-0201.sea3.amazon.com ([172.20.19.24]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 23:21:09 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-0201.sea3.amazon.com (8.12.11/8.12.11) with ESMTP id n3TNL8ZM011219 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 29 Apr 2009 23:21:08 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Wed, 29 Apr 2009 16:21:05 -0700 From: "Phillips, Addison" To: John Cowan Date: Wed, 29 Apr 2009 16:21:03 -0700 Thread-Topic: [Ltru] Ticket #41: AD Issue #8: section 3.5 SHOULD vs. MUST Thread-Index: AcnJHrX7w0nRbIlVQey7VBfK68XugwAADJTQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AF3C@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEE3@EX-SEA5-D.ant.amazon.com> <20090429230325.GH7401@mercury.ccil.org> In-Reply-To: <20090429230325.GH7401@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #41: AD Issue #8: section 3.5 SHOULD vs. MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:19:48 -0000 RWl0aGVyIGtleXdvcmQgaXMgaW5hcHByb3ByaWF0ZSwgYWN0dWFsbHkuIA0KDQpUaGUgcmVxdWVz dCwgYmVmb3JlIGl0IGlzIGFwcHJvdmVkLCBpcyByZXF1aXJlZCAoTVVTVCkgdG8gbWVldCB0aGUg dmFyaW91cyByZXF1aXJlbWVudHMuIA0KDQpNaXN0YWtlcyBhdCByZXF1ZXN0IHRpbWUgY2FuIGV4 aXN0LCBidXQgdGhhdCBkb2VzIG5vdCBtZWFuIHRoYXQgb25lIGlzIGZyZWUgdG8ga25vd2luZ2x5 IHJlcXVlc3QgKGFuZCBleHBlY3QgdG8gaGF2ZSBhcHByb3ZlZCkgYSByZWNvcmQgY29udGFpbmlu ZyBzb21ldGhpbmcgdGhhdCB2aW9sYXRlcyB0aGUgcnVsZXMtLXdoaWNoIGlzIHdoYXQgdXNpbmcg U0hPVUxEIGltcGxpZXMgKGl0IGltcGxpZXMgdGhhdCB0aGVyZSBtYXkgYmUgImdvb2QgcmVhc29u cyIgdG8gc3VibWl0IGEgcmVxdWVzdCB0aGF0IGlzIGtub3dpbmdseSBpbiB2aW9sYXRpb24pLiBU aGlzIGlzIHJlYWxseSAiZ3VpZGFuY2UgdG8gdGhlIGZvcm0gZmlsbGVyIi4NCg0KUGVyaGFwcyBp bnN0ZWFkIHNheToNCg0KLS0NClRoZSBmaWVsZHMgaW4gdGhlICJSZWNvcmQgUmVxdWVzdGVkIiBz ZWN0aW9uIG5lZWQgdG8gZm9sbG93IHRoZSByZXF1aXJlbWVudHMgaW4gPHhyZWYgdGFyZ2V0PSJp YW5hZm9ybWF0Ii8+IGJlZm9yZSB0aGUgcmVjb3JkIHdpbGwgYmUgYXBwcm92ZWQuDQotLQ0KDQoN CkFkZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJ bnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0 dXJlLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9obiBDb3dh biBbbWFpbHRvOmNvd2FuQGNjaWwub3JnXQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI5LCAy MDA5IDQ6MDMgUE0NCj4gVG86IFBoaWxsaXBzLCBBZGRpc29uDQo+IENjOiBMVFJVIFdvcmtpbmcg R3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBUaWNrZXQgIzQxOiBBRCBJc3N1ZSAjODogc2Vj dGlvbiAzLjUgU0hPVUxEIHZzLg0KPiBNVVNUDQo+IA0KPiBQaGlsbGlwcywgQWRkaXNvbiBzY3Jp cHNpdDoNCj4gDQo+ID4gV2hhdCBhcmUgdGhlIHJlYXNvbnMgbm90IHRvIGZvbGxvdyByZXF1aXJl bWVudHMgaW4gU2VjdGlvbiAzLjE/DQo+ID4gKEkuZS4gd2h5IGlzIFNIT1VMRCB1c2VkIGluc3Rl YWQgb2YgTVVTVD8pDQo+IA0KPiBUaGUgcmVhc29uLCBhcyBzdGF0ZWQgaW4gZWFybGllciBlbWFp bHMsIGlzIHRoYXQgd2Ugd2FudCBwZW9wbGUgdG8NCj4gYmUgYWJsZSB0byBzdWJtaXQgbWlsZGx5 IGluY29ycmVjdCBmb3JtcyB3aXRob3V0IGJlaW5nIFJFUVVJUkVEDQo+IHRvIGhlYXZlIHRoZW0g b3ZlcmJvYXJkLiAgTVVTVCBpcyB1c2VkIGZ1cnRoZXIgZG93biwgd2hlbiB0aGUNCj4gZm9ybXMg YXJlIHNlbnQgZnJvbSB0aGUgTFNSIHRvIElBTkEuDQo+IA0KPiAtLQ0KPiBKb2huIENvd2FuICAg Y293YW5AY2NpbC5vcmcNCj4gICAgICJNci4gTGFuZSwgaWYgeW91IGV2ZXIgd2lzaCBhbnl0aGlu ZyB0aGF0IEkgY2FuIGRvLCBhbGwgeW91DQo+IHdpbGwgaGF2ZQ0KPiAgICAgICAgIHRvIGRvIHdp bGwgYmUgdG8gc2VuZCBtZSBhIHRlbGVncmFtIGFza2luZyBhbmQgaXQgd2lsbCBiZQ0KPiBkb25l LiINCj4gICAgICJNci4gSGVhcnN0LCBpZiB5b3UgZXZlciBnZXQgYSB0ZWxlZ3JhbSBmcm9tIG1l IGFza2luZyB5b3UgdG8NCj4gZG8NCj4gICAgICAgICBhbnl0aGluZywgeW91IGNhbiBwdXQgdGhl IHRlbGVncmFtIGRvd24gYXMgYSBmb3JnZXJ5LiINCg== From addison@amazon.com Wed Apr 29 16:21:44 2009 Return-Path: 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 43E6B3A7188 for ; Wed, 29 Apr 2009 16:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 j7ASM+wN6OY8 for ; Wed, 29 Apr 2009 16:21:42 -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 5D3DB3A7150 for ; Wed, 29 Apr 2009 16:20:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208";a="260124957" Received: from smtp-in-4104.sea5.amazon.com ([10.248.183.18]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 23:22:12 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-4104.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3TNMBWs031672 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 29 Apr 2009 23:22:11 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Wed, 29 Apr 2009 16:22:07 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Wed, 29 Apr 2009 16:22:06 -0700 Thread-Topic: can't find a reference for ticket #31 Thread-Index: AcnJIU9pAeGNDeLMR3+wGw+dslx3lQ== Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AF43@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] can't find a reference for ticket #31 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:21:44 -0000 Q291bGQgc29tZWJvZHkgcG9pbnQgbWUgdG8gS2VudCdzIGVtYWlsIHNvIEkgY2FuIGNvcnJlY3Qg dGhlIHRpdGxlcz8NCg0KSGVyZSBpcyB0aGUgdGlja2V0Og0KDQogIGh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL3dnL2x0cnUvdHJhYy90aWNrZXQvMzENCg0KdGhhbmtzLA0KDQpBZGRpc29uDQoN CkFkZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJ bnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0 dXJlLg0KDQoNCg== From mark.edward.davis@gmail.com Wed Apr 29 16:28:47 2009 Return-Path: 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 359133A6B09 for ; Wed, 29 Apr 2009 16:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 7wsvYT7QmCgr for ; Wed, 29 Apr 2009 16:28:45 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 9D35A3A71C9 for ; Wed, 29 Apr 2009 16:28:45 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1155060wff.31 for ; Wed, 29 Apr 2009 16:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=TIE2SsrOOU5XFblcJyeKCO8kKTPIFDsd92KQmWDvSJA=; b=pinAgTAD/vgKnwAnxrDFtxq2ORSQnoJyZe4Obmxl5eqU0QE3G1wsyfI4gQoq7WV69x XIUXJi9Vp7PiydzxA484zWwHL+kxCb2ALHSY5oFhKgm3Hq32+18o4NF5fdCxUUpO5ZzC vpEzPlzjLFRrLv+k0E/Vpux5kN1fPUZt2mBCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=HaYJcyFV9NpRmDFjvxt+/fB7yph7Y5iXZnYyjqzFMqKeZDsdEd3EoAJvuMiY4c24tu ArRmVv1LsQv5uSSJr0aFO/tU5rCtiDamLrI27mtQHPUL8lyxaoPRCp6h9Ln4rNfhrCBd KSfHhWhO/r8VYsWlRiog0FJGTR6Udkjv16zX0= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.12.14 with SMTP id 14mr246409wfl.63.1241047808342; Wed, 29 Apr 2009 16:30:08 -0700 (PDT) In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEBB@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEBB@EX-SEA5-D.ant.amazon.com> Date: Wed, 29 Apr 2009 16:30:08 -0700 X-Google-Sender-Auth: 1c5e153ed7deb927 Message-ID: <30b660a20904291630k1aa78a96lc7197d8238c12d93@mail.gmail.com> From: Mark Davis To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=000e0cd2e2d2c3fa7b0468b9f5a5 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:28:47 -0000 --000e0cd2e2d2c3fa7b0468b9f5a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This doesn't really solve the problem. A language tag is either in canonical format or it is not, and we need to be crystal-clear about what the format is. The problem arises from the numbered clauses being a mixture of descriptive (*a language-tag is in canonical form WHEN X, Y, Z*) text, and procedural text (*in order to canonicalize a language-tag, you MUST do A, B, C*). For example: - A language tag *IS* in canonical form when it contains no tags/subtags with Preferred-Values. - In order to *put* a language-tag into a canonical form, the tags/subtags *MUST be* replaced by their Preferred-Values. The text should be restructured to something like the following, and have consistent use of MUST for each clause. I tried to make the minimal changes necessary to resolve the issue. At the end, we can then make clear that there are perfectly good circumstances where people can -- with perfect reason -- avoid doing the extlang mapping, using a recast version of your paragraph. The changes are marked in yellow. A language tag is in canonical form when: 1. The tag is well-formed according the rules in Section 2.1 and Section 2.2 . 2. It has been canonicalized according to the following process: 1. Redundant or grandfathered tags that have a Preferred-Value mapping in the IANA registry (see Section 3.1 ) MUST be replaced with their mapped value. These items either are deprecated mappings created before the adoption of this document (such as the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are the result of later registrations or additions to this document (for example, "zh-hakka" was deprecated in favor of the ISO 639-3 code 'hak' when this document was adopted). These mappings MUST be applied before subsequent canonicalization steps, since there can be additional changes to the mapped subtag values. These field-body of the Preferred-Value for grandfathered and redundant tags is an "extended language range" ([RFC4647 ]) and might consist of more than one subtag. 2. Subtags of type 'extlang' MUST be mapped to their Preferred- Value. The field-body of the Preferred-Value for extlangs is an "extended language range" and typically maps to a primary language subtag. For example, the subtag sequence "zh-hak" (Chinese, Hakka) would be replaced with the tag "hak" (Hakka). 3. Other subtags that have a Preferred-Value field in the IANA registry (see Section 3.1 ) MUST be replaced with their mapped value. Most of these are either Region subtags where the country name or designation has changed or clerical corrections to ISO 639-1. 4. If more than one extension subtag sequence exists, the extension sequences MUST be ordered into case-insensitive ASCII order by singleton subtag (that is, the subtag sequence '-a-babble' comes before '-b-warble'). Step 2.2 maps extlang fields by removing the macrolanguage information from the tag. That information can be restored with access to the language subtag registry. A partial canonicalization (omitting step 2.2) may also be performed. Such a partial canonicalization may be useful in environments where the macrolanguage is used in matching or selection and there is no access to the registry. For comparison, the original text is: The original text is: A language tag is in canonical form when: 1. The tag is well-formed according the rules in Section 2.1 and Section 2.2 . 2. Redundant or grandfathered tags that have a Preferred-Value mapping in the IANA registry (see Section 3.1 ) MUST be replaced with their mapped value. These items either are deprecated mappings created before the adoption of this document (such as the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are the result of later registrations or additions to this document (for example, "zh-hakka" was deprecated in favor of the ISO 639-3 code 'hak' when this document was adopted). These mappings SHOULD be done before additional processing, since there can be additional changes to subtag values. These field-body of the Preferred-Value for grandfathered and redundant tags is an "extended language range" ([RFC4647 ]) and might consist of more than one subtag. 3. Subtags of type 'extlang' SHOULD be mapped to their Preferred- Value. The field-body of the Preferred-Value for extlangs is an "extended language range" and typically maps to a primary language subtag. For example, the subtag sequence "zh-hak" (Chinese, Hakka) would be replaced with the tag "hak" (Hakka). 4. Other subtags that have a Preferred-Value field in the IANA registry (see Section 3.1 ) MUST be replaced with their mapped value. Most of these are either Region subtags where the country name or designation has changed or clerical corrections to ISO 639-1. 5. If more than one extension subtag sequence exists, the extension sequences are ordered into case-insensitive ASCII order by singleton subtag (that is, the subtag sequence '-a-babble' comes before '-b-warble'). Mark On Wed, Apr 29, 2009 at 15:43, Phillips, Addison wrote: > The AD asked: > > -- > AD review comment #12 from > http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html > > 12). > > 4.5. Canonicalization of Language Tags > > [...] > > 3. Subtags of type 'extlang' SHOULD be mapped to their Preferred- > Value. > > Why use of SHOULD here? I.e. what is a good reason for violating this rule? > A pointer here to some case(s) would be appreciated here. > > The field-body of the Preferred-Value for extlangs is an > "extended language range" and typically maps to a primary > language subtag. For example, the subtag sequence "zh-hak" > (Chinese, Hakka) would be replaced with the tag "hak" (Hakka > -- > > The keyword is (correctly) SHOULD because removing the primary language > subtag removes information that some applications may wish to preserve. > > Proposed resolution: > > Add this text to the above paragraph, indicating why you might not perform > the mapping: > > -- > Because this involves removing the macrolanguage information from the tag, > an implementation might choose not to perform this particular > canonicalization, if such a canonicalization would reduce the effectiveness > of that resulting tags for matching or selection later. > -- > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --000e0cd2e2d2c3fa7b0468b9f5a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This doesn't really solve the problem. A language tag is either in cano= nical format or it is not, and we need to be crystal-clear about what the f= ormat is. The problem arises from the numbered clauses being a mixture of d= escriptive (a language-tag is in canonical form WHEN X, Y, Z)= text, and procedural text (in order to canonicalize a language-tag, you= MUST do A, B, C).

For example:
  • A language tag IS in canonical form whe= n it contains no tags/subtags with Preferred-Values.
  • In order to put a language-tag into a canonical form, the tags/subtags M= UST be replaced by their Preferred-Values.
The text should be restructured to something like the following, and h= ave consistent use of MUST for each clause. I tried to make the minimal cha= nges necessary to resolve the issue. At the end, we can then make clear tha= t there are perfectly good circumstances where people can -- with perfect r= eason -- avoid doing the extlang mapping, using a recast version of your pa= ragraph.

The changes are marked in yellow.

   A=
 language tag is in canonical form when:

   1.  The tag is well-form=
ed according the rules in Section 2.1 and

       Section 2.2.

   2.  It has been canonicalized according to the following pr=
ocess:


     1.  Redundant or grandfathered tags that have a Preferred-Value         mapping in the IANA registry (see Section 3.1) MUST be rep=
laced

         with their mapped value.  These items either are deprecated
   =
      mappings created before the adoption of this document (such as
   =
      the mapping of "no-nyn" to "nn" or "i-klingo=
n" to "tlh") or are

         the result of later registrations or additions to this document         (for example, "zh-hakka" was deprecated in favor of the=
 ISO 639-3
         code 'hak' when this document was adopted). =
 These mapping=
s

         MUST be appl=
ied before subsequent canonicalization steps, 
         since the=
re can be additional changes to the mapped subtag values.

         These field-body of the
         Preferred-Value for grandfathe=
red and redundant tags is an
         "extended language range"=
; ([RFC4647]) and might consist of more

         than one subtag.

     2.  Subtags of type 'extlang'=
 MUST be mappe=
d to their Preferred-
         Value.  The field-body of the Preferred-V=
alue for extlangs is an

         "extended language range" and typically maps to a primar=
y
         language subtag.  For example, the subtag sequence "zh-h=
ak"
         (Chinese, Hakka) would be replaced with the tag "=
hak" (Hakka).


     3.  Other subtags that have a Preferred-Value field in the IANA         registry (see Section 3.1) MUST be replaced with their map=
ped

         value.  Most of these are either Region subtags where the country<=
br>         name or designation has changed or clerical corrections to ISO<=
br>         639-1.
     4.  If more than on=
e extension subtag sequence exists, the extension

         sequences MU=
ST be ordered into case-insensitive ASCII order by
         singl=
eton subtag (that is, the subtag sequence '-a-babble' comes
    =
     before '-b-warble').
   tag. That information can=
 be restored with access to the language subtag registry.

   A partial canonicalization (omitting step 2.2) may also be performed. Such a

   partial can=
onicalization =
may be useful =
in environment=
s where the macrolanguage

   is used in =
matching or selection and there is no access to the registry.
For comparison, the original text is:

The original text is:
   A language tag is in canonical form when:

   1.=
  The tag is well-formed according the rules in Section 2.1 and

       Section 2.2.

   2.  Redundant or grandfathered tags th=
at have a Preferred-Value
       mapping in the IANA registry (see Se=
ction 3.1) MUST be replaced

       with their mapped value.  These items either are deprecated
     =
  mappings created before the adoption of this document (such as
       =
the mapping of "no-nyn" to "nn" or "i-klingon"=
; to "tlh") or are

       the result of later registrations or additions to this document
 =
      (for example, "zh-hakka" was deprecated in favor of the ISO=
 639-3
       code 'hak' when this document was adopted).  These=
 mappings

       SHOULD be done before additional processing, since there can be
 =
      additional changes to subtag values.  These field-body of the
    =
   Preferred-Value for grandfathered and redundant tags is an
       &qu=
ot;extended language range" ([RFC4647]) and mi=
ght consist of more

       than one subtag.

   3.  Subtags of type 'extlang' SHO=
ULD be mapped to their Preferred-
       Value.  The field-body of the P=
referred-Value for extlangs is an
       "extended language range&q=
uot; and typically maps to a primary

       language subtag.  For example, the subtag sequence "zh-hak"=
;
       (Chinese, Hakka) would be replaced with the tag "hak"=
 (Hakka).

   4.  Other subtags that have a Preferred-Value field in =
the IANA

       registry (see Section 3.1) MUST be replaced with their mapped=

       value.  Most of these are either Region subtags where the countr=
y

       name or designation has changed or clerical corrections to ISO
  =
     639-1.
   5.  If more than one extensi=
on subtag sequence exists, the extension
       sequences are ordered in=
to case-insensitive ASCII order by

       singleton subtag (that is, the subtag sequence '-a-babble' c=
omes
       before '-b-warble').

Mark


On Wed, Apr 29, 2009 at 15:43, Phillips,= Addison <addiso= n@amazon.com> wrote:
The AD asked:

--
AD review comment #12 from
http://www.ietf.org/mail-archive/web/ltru/current/msg123= 99.html

12).

=C2=A0 =C2=A04.5. Canonicalization of Language Tags

=C2=A0 =C2=A0[...]

=C2=A0 =C2=A03. Subtags of type 'extlang' SHOULD be mapped to thei= r Preferred-
=C2=A0 =C2=A0Value.

Why use of SHOULD here? I.e. what is a good reason for violating this rule?=
A pointer here to some case(s) would be appreciated here.

=C2=A0 =C2=A0The field-body of the Preferred-Value for extlangs is an
=C2=A0 =C2=A0"extended language range" and typically maps to a p= rimary
=C2=A0 =C2=A0language subtag. For example, the subtag sequence "zh-ha= k"
=C2=A0 =C2=A0(Chinese, Hakka) would be replaced with the tag "hak&quo= t; (Hakka
--

The keyword is (correctly) SHOULD because removing the primary language sub= tag removes information that some applications may wish to preserve.

Proposed resolution:

Add this text to the above paragraph, indicating why you might not perform = the mapping:

--
Because this involves removing the macrolanguage information from the tag, = an implementation might choose not to perform this particular canonicalizat= ion, if such a canonicalization would reduce the effectiveness of that resu= lting tags for matching or selection later.
--

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--000e0cd2e2d2c3fa7b0468b9f5a5-- From cowan@ccil.org Wed Apr 29 16:55:15 2009 Return-Path: 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 E2BBF3A7188 for ; Wed, 29 Apr 2009 16:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.161, 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 ZKe7KlyiVUWV for ; Wed, 29 Apr 2009 16:55:14 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id BCA0A3A716A for ; Wed, 29 Apr 2009 16:55:14 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LzJdj-0000mq-GO; Wed, 29 Apr 2009 19:56:35 -0400 Date: Wed, 29 Apr 2009 19:56:35 -0400 To: Mark Davis Message-ID: <20090429235635.GJ7401@mercury.ccil.org> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEBB@EX-SEA5-D.ant.amazon.com> <30b660a20904291630k1aa78a96lc7197d8238c12d93@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20904291630k1aa78a96lc7197d8238c12d93@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:55:16 -0000 Mark Davis scripsit: > The text should be restructured to something like the following, and have > consistent use of MUST for each clause. I tried to make the minimal changes > necessary to resolve the issue. At the end, we can then make clear that > there are perfectly good circumstances where people can -- with perfect > reason -- avoid doing the extlang mapping, using a recast version of your > paragraph. +1 to all points. -- I suggest you solicit aid of my followers John Cowan or learn the difficult art of mud-breathing. cowan@ccil.org --Great-Souled Sam http://www.ccil.org/~cowan From addison@amazon.com Wed Apr 29 19:47:53 2009 Return-Path: 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 064B73A6CAC for ; Wed, 29 Apr 2009 19:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0OtuPihqxcLR for ; Wed, 29 Apr 2009 19:47:51 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id D7BF83A680B for ; Wed, 29 Apr 2009 19:47:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,269,1238976000"; d="scan'208,217";a="216119488" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 02:49:07 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3U2n7ep011557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 02:49:07 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Wed, 29 Apr 2009 19:49:07 -0700 From: "Phillips, Addison" To: Mark Davis Date: Wed, 29 Apr 2009 19:49:02 -0700 Thread-Topic: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping Thread-Index: AcnJInCEgS38Ny5LQ+WOkdKDud7rFQAGl9Aw Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE33D68@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEBB@EX-SEA5-D.ant.amazon.com> <30b660a20904291630k1aa78a96lc7197d8238c12d93@mail.gmail.com> In-Reply-To: <30b660a20904291630k1aa78a96lc7197d8238c12d93@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE33D68EXSEA5Dantama_" MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 02:47:53 -0000 --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE33D68EXSEA5Dantama_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VWxwLg0KDQpZZXMsIG9mIGNvdXJzZSwgeW914oCZcmUgcmlnaHQuIEhvd2V2ZXIgdGhlIGNhbm9u aWNhbGl6YXRpb24gb2YgZXh0bGFuZ3MsIElJUkMsIHdhcyAgYSBzdHVtYmxpbmcgYmxvY2sgYW5k IHRoaXMgd2FzIHRoZSBjb21wcm9taXNlLiBJdOKAmXMgcHVyZSBmdWRnZS4gSSBzdXBwb3J0IHlv dXIgY2hhbmdlcy4NCg0KT25lIGJpdCBvZiB0ZXh0IHlvdSBzdWdnZXN0IGlzOg0KDQotLQ0KVGhh dCBpbmZvcm1hdGlvbiBjYW4gYmUgcmVzdG9yZWQgd2l0aCBhY2Nlc3MgdG8gdGhlIGxhbmd1YWdl IHN1YnRhZyByZWdpc3RyeS4NCi0tDQoNCkFjdHVhbGx5LCB0aGF04oCZcyBub3QgcXVpdGUgcmln aHQuIFRoZXJlIGFyZSB0d28gY2Fub25pY2FsIGZvcm1zOiDigJxubyBleHRsYW5n4oCdIGFuZCDi gJxhbHdheXMgZXh0bGFuZ+KAnS4gT25jZSB0aGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaGFz IGJlZW4gcmVtb3ZlZCwgeW91IGNhbuKAmXQgdGVsbCBpZiBpdCB3YXMgdGhlcmUgKG9yIG5vdCks IHNvIOKAnHJlc3RvcmF0aW9u4oCdIG1pZ2h0IGJlIGNoYW5naW5nIHRoZSBvcmlnaW5hbCB0YWcu IFNvIG9uZSBjYW5vbmljYWxpemF0aW9uIGZvcm0gaXMgYXMgeW91IHdyaXRlIGJlbG93LiBUaGUg b3RoZXIgZm9ybSBhbHdheXMgcHVzaGVzIHRoZSBtYWNyb2xhbmd1YWdlIG9udG8gdGhlIHRhZy4N Cg0K4oCcTk/igJ0gZm9ybToNCg0KWmgtaGFrIC0+IGhhaw0KWmgtY21uLUhhbnQtQ04gLT4gY21u LUhhbnQtQ04NCg0K4oCdRVhUTEFOR+KAnSBmb3JtOg0KDQpaaC1oYWsgPT4gemgtaGFrDQpaaC1j bW4taGFudC1jbiA9PiB6aC1jbW4tSGFudC1DTg0KSGFrID0+IHpoLWhhaw0KQ21uLWhhbnQtY24g PT4gemgtY21uLUhhbnQtQ04NCg0KVGhlIG5vLWV4dGxhbmcgZm9ybSByZXF1aXJlcyBubyByZWdp c3RyeSBhY2Nlc3MgYW5kIGlzIHRoZSBkZWZhdWx0LiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB3ZSBk ZWZpbmUgYm90aCBmb3Jtcywgd2l0aCB0aGUg4oCcbm/igJ0gZm9ybSBhcyBkZWZhdWx0LCBhbmQg aGF2ZSBhIG5vdGUgdGhhdCBzYXlzIHRoYXQgY2Fub25pY2FsaXphdGlvbiBpcyBub3QgcmVxdWly ZWQgdXNpbmcgeW91ciB0ZXh0Lg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUGhpbGxpcHMNCkdsb2Jh bGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBu b3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KDQpGcm9tOiBtYXJrLmVkd2Fy ZC5kYXZpc0BnbWFpbC5jb20gW21haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb21dIE9u IEJlaGFsZiBPZiBNYXJrIERhdmlzDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI5LCAyMDA5IDQ6 MzAgUE0NClRvOiBQaGlsbGlwcywgQWRkaXNvbg0KQ2M6IExUUlUgV29ya2luZyBHcm91cA0KU3Vi amVjdDogUmU6IFtMdHJ1XSBUaWNrZXQgIzQ1OiBBRCBJc3N1ZSAjMTI6IHJlYXNvbiBmb3IgU0hP VUxEIGluIDQuNSBleHRsYW5nIG1hcHBpbmcNCg0KVGhpcyBkb2Vzbid0IHJlYWxseSBzb2x2ZSB0 aGUgcHJvYmxlbS4gQSBsYW5ndWFnZSB0YWcgaXMgZWl0aGVyIGluIGNhbm9uaWNhbCBmb3JtYXQg b3IgaXQgaXMgbm90LCBhbmQgd2UgbmVlZCB0byBiZSBjcnlzdGFsLWNsZWFyIGFib3V0IHdoYXQg dGhlIGZvcm1hdCBpcy4gVGhlIHByb2JsZW0gYXJpc2VzIGZyb20gdGhlIG51bWJlcmVkIGNsYXVz ZXMgYmVpbmcgYSBtaXh0dXJlIG9mIGRlc2NyaXB0aXZlIChhIGxhbmd1YWdlLXRhZyBpcyBpbiBj YW5vbmljYWwgZm9ybSBXSEVOIFgsIFksIFopIHRleHQsIGFuZCBwcm9jZWR1cmFsIHRleHQgKGlu IG9yZGVyIHRvIGNhbm9uaWNhbGl6ZSBhIGxhbmd1YWdlLXRhZywgeW91IE1VU1QgZG8gQSwgQiwg QykuDQoNCkZvciBleGFtcGxlOg0KDQogKiAgIEEgbGFuZ3VhZ2UgdGFnIElTIGluIGNhbm9uaWNh bCBmb3JtIHdoZW4gaXQgY29udGFpbnMgbm8gdGFncy9zdWJ0YWdzIHdpdGggUHJlZmVycmVkLVZh bHVlcy4NCiAqICAgSW4gb3JkZXIgdG8gcHV0IGEgbGFuZ3VhZ2UtdGFnIGludG8gYSBjYW5vbmlj YWwgZm9ybSwgdGhlIHRhZ3Mvc3VidGFncyBNVVNUIGJlIHJlcGxhY2VkIGJ5IHRoZWlyIFByZWZl cnJlZC1WYWx1ZXMuDQpUaGUgdGV4dCBzaG91bGQgYmUgcmVzdHJ1Y3R1cmVkIHRvIHNvbWV0aGlu ZyBsaWtlIHRoZSBmb2xsb3dpbmcsIGFuZCBoYXZlIGNvbnNpc3RlbnQgdXNlIG9mIE1VU1QgZm9y IGVhY2ggY2xhdXNlLiBJIHRyaWVkIHRvIG1ha2UgdGhlIG1pbmltYWwgY2hhbmdlcyBuZWNlc3Nh cnkgdG8gcmVzb2x2ZSB0aGUgaXNzdWUuIEF0IHRoZSBlbmQsIHdlIGNhbiB0aGVuIG1ha2UgY2xl YXIgdGhhdCB0aGVyZSBhcmUgcGVyZmVjdGx5IGdvb2QgY2lyY3Vtc3RhbmNlcyB3aGVyZSBwZW9w bGUgY2FuIC0tIHdpdGggcGVyZmVjdCByZWFzb24gLS0gYXZvaWQgZG9pbmcgdGhlIGV4dGxhbmcg bWFwcGluZywgdXNpbmcgYSByZWNhc3QgdmVyc2lvbiBvZiB5b3VyIHBhcmFncmFwaC4NCg0KVGhl IGNoYW5nZXMgYXJlIG1hcmtlZCBpbiB5ZWxsb3cuDQoNCiAgIEEgbGFuZ3VhZ2UgdGFnIGlzIGlu IGNhbm9uaWNhbCBmb3JtIHdoZW46DQoNCg0KDQogICAxLiAgVGhlIHRhZyBpcyB3ZWxsLWZvcm1l ZCBhY2NvcmRpbmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gMi4xPGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbHRydS00NjQ2YmlzLTIxI3NlY3Rpb24tMi4xPiBhbmQNCg0KDQoN Cg0KDQogICAgICAgU2VjdGlvbiAyLjI8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1sdHJ1LTQ2NDZiaXMtMjEjc2VjdGlvbi0yLjI+Lg0KDQoNCg0KICAgMi4gIEl0IGhhcyBi ZWVuIGNhbm9uaWNhbGl6ZWQgYWNjb3JkaW5nIHRvIHRoZSBmb2xsb3dpbmcgcHJvY2VzczoNCg0K DQoNCg0KDQoNCiAgICAgMS4gIFJlZHVuZGFudCBvciBncmFuZGZhdGhlcmVkIHRhZ3MgdGhhdCBo YXZlIGEgUHJlZmVycmVkLVZhbHVlDQoNCiAgICAgICAgIG1hcHBpbmcgaW4gdGhlIElBTkEgcmVn aXN0cnkgKHNlZSBTZWN0aW9uIDMuMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWx0cnUtNDY0NmJpcy0yMSNzZWN0aW9uLTMuMT4pIE1VU1QgYmUgcmVwbGFjZWQNCg0KDQoN Cg0KDQogICAgICAgICB3aXRoIHRoZWlyIG1hcHBlZCB2YWx1ZS4gIFRoZXNlIGl0ZW1zIGVpdGhl ciBhcmUgZGVwcmVjYXRlZA0KDQogICAgICAgICBtYXBwaW5ncyBjcmVhdGVkIGJlZm9yZSB0aGUg YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCAoc3VjaCBhcw0KDQogICAgICAgICB0aGUgbWFwcGlu ZyBvZiAibm8tbnluIiB0byAibm4iIG9yICJpLWtsaW5nb24iIHRvICJ0bGgiKSBvciBhcmUNCg0K DQoNCg0KDQogICAgICAgICB0aGUgcmVzdWx0IG9mIGxhdGVyIHJlZ2lzdHJhdGlvbnMgb3IgYWRk aXRpb25zIHRvIHRoaXMgZG9jdW1lbnQNCg0KICAgICAgICAgKGZvciBleGFtcGxlLCAiemgtaGFr a2EiIHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTMNCg0KICAgICAgICAg Y29kZSAnaGFrJyB3aGVuIHRoaXMgZG9jdW1lbnQgd2FzIGFkb3B0ZWQpLiAgVGhlc2UgbWFwcGlu Z3MNCg0KDQoNCg0KDQogICAgICAgICBNVVNUIGJlIGFwcGxpZWQgYmVmb3JlIHN1YnNlcXVlbnQg Y2Fub25pY2FsaXphdGlvbiBzdGVwcywNCg0KICAgICAgICAgc2luY2UgdGhlcmUgY2FuIGJlIGFk ZGl0aW9uYWwgY2hhbmdlcyB0byB0aGUgbWFwcGVkIHN1YnRhZyB2YWx1ZXMuDQoNCg0KDQoNCg0K ICAgICAgICAgVGhlc2UgZmllbGQtYm9keSBvZiB0aGUNCg0KICAgICAgICAgUHJlZmVycmVkLVZh bHVlIGZvciBncmFuZGZhdGhlcmVkIGFuZCByZWR1bmRhbnQgdGFncyBpcyBhbg0KDQogICAgICAg ICAiZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UiIChbUkZDNDY0NzxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM0NjQ3Pl0pIGFuZCBtaWdodCBjb25zaXN0IG9mIG1vcmUNCg0KDQoNCg0KDQog ICAgICAgICB0aGFuIG9uZSBzdWJ0YWcuDQoNCg0KDQogICAgIDIuICBTdWJ0YWdzIG9mIHR5cGUg J2V4dGxhbmcnIE1VU1QgYmUgbWFwcGVkIHRvIHRoZWlyIFByZWZlcnJlZC0NCg0KICAgICAgICAg VmFsdWUuICBUaGUgZmllbGQtYm9keSBvZiB0aGUgUHJlZmVycmVkLVZhbHVlIGZvciBleHRsYW5n cyBpcyBhbg0KDQoNCg0KDQoNCiAgICAgICAgICJleHRlbmRlZCBsYW5ndWFnZSByYW5nZSIgYW5k IHR5cGljYWxseSBtYXBzIHRvIGEgcHJpbWFyeQ0KDQogICAgICAgICBsYW5ndWFnZSBzdWJ0YWcu ICBGb3IgZXhhbXBsZSwgdGhlIHN1YnRhZyBzZXF1ZW5jZSAiemgtaGFrIg0KDQogICAgICAgICAo Q2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJlcGxhY2VkIHdpdGggdGhlIHRhZyAiaGFrIiAoSGFr a2EpLg0KDQoNCg0KDQoNCg0KICAgICAzLiAgT3RoZXIgc3VidGFncyB0aGF0IGhhdmUgYSBQcmVm ZXJyZWQtVmFsdWUgZmllbGQgaW4gdGhlIElBTkENCg0KICAgICAgICAgcmVnaXN0cnkgKHNlZSBT ZWN0aW9uIDMuMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx0cnUtNDY0 NmJpcy0yMSNzZWN0aW9uLTMuMT4pIE1VU1QgYmUgcmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwZWQN Cg0KDQoNCg0KDQogICAgICAgICB2YWx1ZS4gIE1vc3Qgb2YgdGhlc2UgYXJlIGVpdGhlciBSZWdp b24gc3VidGFncyB3aGVyZSB0aGUgY291bnRyeQ0KDQogICAgICAgICBuYW1lIG9yIGRlc2lnbmF0 aW9uIGhhcyBjaGFuZ2VkIG9yIGNsZXJpY2FsIGNvcnJlY3Rpb25zIHRvIElTTw0KDQogICAgICAg ICA2MzktMS4NCg0KICAgICA0LiAgSWYgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24gc3VidGFnIHNl cXVlbmNlIGV4aXN0cywgdGhlIGV4dGVuc2lvbg0KDQoNCg0KDQoNCiAgICAgICAgIHNlcXVlbmNl cyBNVVNUIGJlIG9yZGVyZWQgaW50byBjYXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVyIGJ5DQoN CiAgICAgICAgIHNpbmdsZXRvbiBzdWJ0YWcgKHRoYXQgaXMsIHRoZSBzdWJ0YWcgc2VxdWVuY2Ug Jy1hLWJhYmJsZScgY29tZXMNCg0KICAgICAgICAgYmVmb3JlICctYi13YXJibGUnKS4NCg0KICAg U3RlcCAyLjIgbWFwcyBleHRsYW5nIGZpZWxkcyBieSByZW1vdmluZyB0aGUgbWFjcm9sYW5ndWFn ZSBpbmZvcm1hdGlvbiBmcm9tIHRoZQ0KDQogICB0YWcuIFRoYXQgaW5mb3JtYXRpb24gY2FuIGJl IHJlc3RvcmVkIHdpdGggYWNjZXNzIHRvIHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkuDQoN Cg0KDQoNCg0KICAgQSBwYXJ0aWFsIGNhbm9uaWNhbGl6YXRpb24gKG9taXR0aW5nIHN0ZXAgMi4y KSBtYXkgYWxzbyBiZSBwZXJmb3JtZWQuIFN1Y2ggYQ0KDQoNCg0KDQoNCiAgIHBhcnRpYWwgY2Fu b25pY2FsaXphdGlvbiBtYXkgYmUgdXNlZnVsIGluIGVudmlyb25tZW50cyB3aGVyZSB0aGUgbWFj cm9sYW5ndWFnZQ0KDQoNCg0KDQoNCiAgIGlzIHVzZWQgaW4gbWF0Y2hpbmcgb3Igc2VsZWN0aW9u IGFuZCB0aGVyZSBpcyBubyBhY2Nlc3MgdG8gdGhlIHJlZ2lzdHJ5Lg0KRm9yIGNvbXBhcmlzb24s IHRoZSBvcmlnaW5hbCB0ZXh0IGlzOg0KDQpUaGUgb3JpZ2luYWwgdGV4dCBpczoNCg0KICAgQSBs YW5ndWFnZSB0YWcgaXMgaW4gY2Fub25pY2FsIGZvcm0gd2hlbjoNCg0KDQoNCiAgIDEuICBUaGUg dGFnIGlzIHdlbGwtZm9ybWVkIGFjY29yZGluZyB0aGUgcnVsZXMgaW4gU2VjdGlvbiAyLjE8aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMtMjEjc2VjdGlv bi0yLjE+IGFuZA0KDQoNCg0KDQoNCiAgICAgICBTZWN0aW9uIDIuMjxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx0cnUtNDY0NmJpcy0yMSNzZWN0aW9uLTIuMj4uDQoNCg0K DQogICAyLiAgUmVkdW5kYW50IG9yIGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IGhhdmUgYSBQcmVm ZXJyZWQtVmFsdWUNCg0KICAgICAgIG1hcHBpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgKHNlZSBT ZWN0aW9uIDMuMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx0cnUtNDY0 NmJpcy0yMSNzZWN0aW9uLTMuMT4pIE1VU1QgYmUgcmVwbGFjZWQNCg0KDQoNCg0KDQogICAgICAg d2l0aCB0aGVpciBtYXBwZWQgdmFsdWUuICBUaGVzZSBpdGVtcyBlaXRoZXIgYXJlIGRlcHJlY2F0 ZWQNCg0KICAgICAgIG1hcHBpbmdzIGNyZWF0ZWQgYmVmb3JlIHRoZSBhZG9wdGlvbiBvZiB0aGlz IGRvY3VtZW50IChzdWNoIGFzDQoNCiAgICAgICB0aGUgbWFwcGluZyBvZiAibm8tbnluIiB0byAi bm4iIG9yICJpLWtsaW5nb24iIHRvICJ0bGgiKSBvciBhcmUNCg0KDQoNCg0KDQogICAgICAgdGhl IHJlc3VsdCBvZiBsYXRlciByZWdpc3RyYXRpb25zIG9yIGFkZGl0aW9ucyB0byB0aGlzIGRvY3Vt ZW50DQoNCiAgICAgICAoZm9yIGV4YW1wbGUsICJ6aC1oYWtrYSIgd2FzIGRlcHJlY2F0ZWQgaW4g ZmF2b3Igb2YgdGhlIElTTyA2MzktMw0KDQogICAgICAgY29kZSAnaGFrJyB3aGVuIHRoaXMgZG9j dW1lbnQgd2FzIGFkb3B0ZWQpLiAgVGhlc2UgbWFwcGluZ3MNCg0KDQoNCg0KDQogICAgICAgU0hP VUxEIGJlIGRvbmUgYmVmb3JlIGFkZGl0aW9uYWwgcHJvY2Vzc2luZywgc2luY2UgdGhlcmUgY2Fu IGJlDQoNCiAgICAgICBhZGRpdGlvbmFsIGNoYW5nZXMgdG8gc3VidGFnIHZhbHVlcy4gIFRoZXNl IGZpZWxkLWJvZHkgb2YgdGhlDQoNCiAgICAgICBQcmVmZXJyZWQtVmFsdWUgZm9yIGdyYW5kZmF0 aGVyZWQgYW5kIHJlZHVuZGFudCB0YWdzIGlzIGFuDQoNCiAgICAgICAiZXh0ZW5kZWQgbGFuZ3Vh Z2UgcmFuZ2UiIChbUkZDNDY0NzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjQ3Pl0p IGFuZCBtaWdodCBjb25zaXN0IG9mIG1vcmUNCg0KDQoNCg0KDQogICAgICAgdGhhbiBvbmUgc3Vi dGFnLg0KDQoNCg0KICAgMy4gIFN1YnRhZ3Mgb2YgdHlwZSAnZXh0bGFuZycgU0hPVUxEIGJlIG1h cHBlZCB0byB0aGVpciBQcmVmZXJyZWQtDQoNCiAgICAgICBWYWx1ZS4gIFRoZSBmaWVsZC1ib2R5 IG9mIHRoZSBQcmVmZXJyZWQtVmFsdWUgZm9yIGV4dGxhbmdzIGlzIGFuDQoNCiAgICAgICAiZXh0 ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UiIGFuZCB0eXBpY2FsbHkgbWFwcyB0byBhIHByaW1hcnkNCg0K DQoNCg0KDQogICAgICAgbGFuZ3VhZ2Ugc3VidGFnLiAgRm9yIGV4YW1wbGUsIHRoZSBzdWJ0YWcg c2VxdWVuY2UgInpoLWhhayINCg0KICAgICAgIChDaGluZXNlLCBIYWtrYSkgd291bGQgYmUgcmVw bGFjZWQgd2l0aCB0aGUgdGFnICJoYWsiIChIYWtrYSkuDQoNCg0KDQogICA0LiAgT3RoZXIgc3Vi dGFncyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUgZmllbGQgaW4gdGhlIElBTkENCg0KDQoN Cg0KDQogICAgICAgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMuMTxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWx0cnUtNDY0NmJpcy0yMSNzZWN0aW9uLTMuMT4pIE1VU1QgYmUg cmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwZWQNCg0KICAgICAgIHZhbHVlLiAgTW9zdCBvZiB0aGVz ZSBhcmUgZWl0aGVyIFJlZ2lvbiBzdWJ0YWdzIHdoZXJlIHRoZSBjb3VudHJ5DQoNCg0KDQoNCg0K ICAgICAgIG5hbWUgb3IgZGVzaWduYXRpb24gaGFzIGNoYW5nZWQgb3IgY2xlcmljYWwgY29ycmVj dGlvbnMgdG8gSVNPDQoNCiAgICAgICA2MzktMS4NCg0KICAgNS4gIElmIG1vcmUgdGhhbiBvbmUg ZXh0ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZSBleGlzdHMsIHRoZSBleHRlbnNpb24NCg0KICAgICAg IHNlcXVlbmNlcyBhcmUgb3JkZXJlZCBpbnRvIGNhc2UtaW5zZW5zaXRpdmUgQVNDSUkgb3JkZXIg YnkNCg0KDQoNCg0KDQogICAgICAgc2luZ2xldG9uIHN1YnRhZyAodGhhdCBpcywgdGhlIHN1YnRh ZyBzZXF1ZW5jZSAnLWEtYmFiYmxlJyBjb21lcw0KDQogICAgICAgYmVmb3JlICctYi13YXJibGUn KS4NCg0KTWFyaw0KDQpPbiBXZWQsIEFwciAyOSwgMjAwOSBhdCAxNTo0MywgUGhpbGxpcHMsIEFk ZGlzb24gPGFkZGlzb25AYW1hem9uLmNvbTxtYWlsdG86YWRkaXNvbkBhbWF6b24uY29tPj4gd3Jv dGU6DQpUaGUgQUQgYXNrZWQ6DQoNCi0tDQpBRCByZXZpZXcgY29tbWVudCAjMTIgZnJvbQ0KaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cxMjM5OS5o dG1sDQoNCjEyKS4NCg0KICAgNC41LiBDYW5vbmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MN Cg0KICAgWy4uLl0NCg0KICAgMy4gU3VidGFncyBvZiB0eXBlICdleHRsYW5nJyBTSE9VTEQgYmUg bWFwcGVkIHRvIHRoZWlyIFByZWZlcnJlZC0NCiAgIFZhbHVlLg0KDQpXaHkgdXNlIG9mIFNIT1VM RCBoZXJlPyBJLmUuIHdoYXQgaXMgYSBnb29kIHJlYXNvbiBmb3IgdmlvbGF0aW5nIHRoaXMgcnVs ZT8NCkEgcG9pbnRlciBoZXJlIHRvIHNvbWUgY2FzZShzKSB3b3VsZCBiZSBhcHByZWNpYXRlZCBo ZXJlLg0KDQogICBUaGUgZmllbGQtYm9keSBvZiB0aGUgUHJlZmVycmVkLVZhbHVlIGZvciBleHRs YW5ncyBpcyBhbg0KICAgImV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIiBhbmQgdHlwaWNhbGx5IG1h cHMgdG8gYSBwcmltYXJ5DQogICBsYW5ndWFnZSBzdWJ0YWcuIEZvciBleGFtcGxlLCB0aGUgc3Vi dGFnIHNlcXVlbmNlICJ6aC1oYWsiDQogICAoQ2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJlcGxh Y2VkIHdpdGggdGhlIHRhZyAiaGFrIiAoSGFra2ENCi0tDQoNClRoZSBrZXl3b3JkIGlzIChjb3Jy ZWN0bHkpIFNIT1VMRCBiZWNhdXNlIHJlbW92aW5nIHRoZSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRh ZyByZW1vdmVzIGluZm9ybWF0aW9uIHRoYXQgc29tZSBhcHBsaWNhdGlvbnMgbWF5IHdpc2ggdG8g cHJlc2VydmUuDQoNClByb3Bvc2VkIHJlc29sdXRpb246DQoNCkFkZCB0aGlzIHRleHQgdG8gdGhl IGFib3ZlIHBhcmFncmFwaCwgaW5kaWNhdGluZyB3aHkgeW91IG1pZ2h0IG5vdCBwZXJmb3JtIHRo ZSBtYXBwaW5nOg0KDQotLQ0KQmVjYXVzZSB0aGlzIGludm9sdmVzIHJlbW92aW5nIHRoZSBtYWNy b2xhbmd1YWdlIGluZm9ybWF0aW9uIGZyb20gdGhlIHRhZywgYW4gaW1wbGVtZW50YXRpb24gbWln aHQgY2hvb3NlIG5vdCB0byBwZXJmb3JtIHRoaXMgcGFydGljdWxhciBjYW5vbmljYWxpemF0aW9u LCBpZiBzdWNoIGEgY2Fub25pY2FsaXphdGlvbiB3b3VsZCByZWR1Y2UgdGhlIGVmZmVjdGl2ZW5l c3Mgb2YgdGhhdCByZXN1bHRpbmcgdGFncyBmb3IgbWF0Y2hpbmcgb3Igc2VsZWN0aW9uIGxhdGVy Lg0KLS0NCg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFi MTI2DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBh cmNoaXRlY3R1cmUuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkx0cnUgbWFpbGluZyBsaXN0DQpMdHJ1QGlldGYub3JnPG1haWx0bzpMdHJ1QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE33D68EXSEA5Dantama_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpQTWluZ0xpVTsNCglwYW5vc2UtMToyIDIg MyAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJ cGFub3NlLTE6MiAyIDMgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJBcmlhbCBVbmljb2RlIE1TIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xh czsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQFBNaW5nTGlVIjsNCglwYW5vc2UtMToyIDIgMyAwIDAgMCAwIDAgMCAwO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBTYW5zIFVuaWNvZGUiOw0KCXBhbm9zZS0x OjIgMTEgNiAyIDMgNSA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAQXJp YWwgVW5pY29kZSBNUyI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAy IDUgOCAzIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFn ZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjQ3Nzc3MDc5ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzY2NTE5NjU0O30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8 Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2Vj dGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+VWxw LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+WWVzLCBvZiBjb3Vyc2UsIHlvdeKAmXJl IHJpZ2h0LiBIb3dldmVyIHRoZSBjYW5vbmljYWxpemF0aW9uIG9mDQpleHRsYW5ncywgSUlSQywg d2FzwqAgYSBzdHVtYmxpbmcgYmxvY2sgYW5kIHRoaXMgd2FzIHRoZSBjb21wcm9taXNlLiBJdOKA mXMgcHVyZQ0KZnVkZ2UuIEkgc3VwcG9ydCB5b3VyIGNoYW5nZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5PbmUgYml0IG9mIHRleHQgeW91IHN1Z2dlc3QgaXM6PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5UaGF0IGluZm9ybWF0aW9uIGNhbiBi ZSByZXN0b3JlZCB3aXRoIGFjY2VzcyB0byB0aGUgbGFuZ3VhZ2UNCnN1YnRhZyByZWdpc3RyeS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29s b3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkFjdHVhbGx5LCB0 aGF04oCZcyBub3QgcXVpdGUgcmlnaHQuIFRoZXJlIGFyZSB0d28gY2Fub25pY2FsIGZvcm1zOg0K 4oCcbm8gZXh0bGFuZ+KAnSBhbmQg4oCcYWx3YXlzIGV4dGxhbmfigJ0uIE9uY2UgdGhlIHByaW1h cnkgbGFuZ3VhZ2Ugc3VidGFnIGhhcyBiZWVuDQpyZW1vdmVkLCB5b3UgY2Fu4oCZdCB0ZWxsIGlm IGl0IHdhcyB0aGVyZSAob3Igbm90KSwgc28g4oCccmVzdG9yYXRpb27igJ0gbWlnaHQgYmUNCmNo YW5naW5nIHRoZSBvcmlnaW5hbCB0YWcuIFNvIG9uZSBjYW5vbmljYWxpemF0aW9uIGZvcm0gaXMg YXMgeW91IHdyaXRlIGJlbG93Lg0KVGhlIG90aGVyIGZvcm0gYWx3YXlzIHB1c2hlcyB0aGUgbWFj cm9sYW5ndWFnZSBvbnRvIHRoZSB0YWcuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz7i gJxOT+KAnSBmb3JtOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+WmgtaGFrIC0mZ3Q7 IGhhazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9U1YtRkkgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlpoLWNtbi1IYW50LUNOIC0mZ3Q7IGNtbi1IYW50 LUNOPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1TVi1GSSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+4oCd RVhUTEFOR+KAnSBmb3JtOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPlpoLWhhayA9Jmd0OyB6aC1oYWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5aaC1jbW4taGFu dC1jbiA9Jmd0OyB6aC1jbW4tSGFudC1DTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkhhayA9Jmd0OyB6 aC1oYWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPURFIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5DbW4taGFudC1jbiA9Jmd0OyB6aC1jbW4tSGFudC1D TjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 REUgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5UaGUgbm8tZXh0bGFuZyBm b3JtIHJlcXVpcmVzIG5vIHJlZ2lzdHJ5IGFjY2VzcyBhbmQgaXMgdGhlDQpkZWZhdWx0LiBJIHdv dWxkIHN1Z2dlc3QgdGhhdCB3ZSBkZWZpbmUgYm90aCBmb3Jtcywgd2l0aCB0aGUg4oCcbm/igJ0g Zm9ybSBhcw0KZGVmYXVsdCwgYW5kIGhhdmUgYSBub3RlIHRoYXQgc2F5cyB0aGF0IGNhbm9uaWNh bGl6YXRpb24gaXMgbm90IHJlcXVpcmVkIHVzaW5nDQp5b3VyIHRleHQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz5BZGRpc29uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBTYW5zIFVuaWNvZGUiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPkFkZGlzb24gUGhpbGxpcHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJM dWNpZGEgU2FucyBVbmljb2RlIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5HbG9iYWxp emF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjY8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjkuMHB0O2ZvbnQtZmFtaWx5OiJMdWNpZGEgU2FucyBVbmljb2RlIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiTHVjaWRhIFNhbnMgVW5p Y29kZSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseToiTHVjaWRhIFNhbnMgVW5pY29kZSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzFGNDk3RCc+SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiJMdWNpZGEgU2FucyBVbmljb2RlIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5JdCBpcyBhbiBhcmNoaXRlY3R1cmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0KPGRpdj4N Cg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+DQptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5j b20gW21haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb21dIDxiPk9uIEJlaGFsZg0KT2Yg PC9iPk1hcmsgRGF2aXM8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAyOSwgMjAw OSA0OjMwIFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsbGlwcywgQWRkaXNvbjxicj4NCjxiPkNjOjwv Yj4gTFRSVSBXb3JraW5nIEdyb3VwPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTHRydV0gVGlj a2V0ICM0NTogQUQgSXNzdWUgIzEyOiByZWFzb24gZm9yIFNIT1VMRCBpbiA0LjUNCmV4dGxhbmcg bWFwcGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD5UaGlzIGRvZXNuJ3QgcmVhbGx5IHNvbHZlIHRoZSBwcm9ibGVtLiBBIGxhbmd1YWdlIHRhZyBp cw0KZWl0aGVyIGluIGNhbm9uaWNhbCBmb3JtYXQgb3IgaXQgaXMgbm90LCBhbmQgd2UgbmVlZCB0 byBiZSBjcnlzdGFsLWNsZWFyIGFib3V0DQp3aGF0IHRoZSBmb3JtYXQgaXMuIFRoZSBwcm9ibGVt IGFyaXNlcyBmcm9tIHRoZSBudW1iZXJlZCBjbGF1c2VzIGJlaW5nIGENCm1peHR1cmUgb2YgZGVz Y3JpcHRpdmUgKDxpPmEgbGFuZ3VhZ2UtdGFnIGlzIGluIGNhbm9uaWNhbCBmb3JtIDxiPldIRU4g WCwgWSwgWjwvYj48L2k+KQ0KdGV4dCwgYW5kIHByb2NlZHVyYWwgdGV4dCAoPGk+aW4gb3JkZXIg dG8gY2Fub25pY2FsaXplIGEgbGFuZ3VhZ2UtdGFnLCB5b3UgPGI+TVVTVA0KZG8gQSwgQiwgQzwv Yj48L2k+KS48YnI+DQo8YnI+DQpGb3IgZXhhbXBsZTogPG86cD48L286cD48L3A+DQoNCjx1bCB0 eXBlPWRpc2M+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwwIGxldmVs MSBsZm8xJz5BIGxhbmd1YWdlIHRhZyA8Yj5JUzwvYj4gaW4gY2Fub25pY2FsIGZvcm0gd2hlbg0K ICAgICBpdCBjb250YWlucyBubyB0YWdzL3N1YnRhZ3Mgd2l0aCBQcmVmZXJyZWQtVmFsdWVzLjxv OnA+PC9vOnA+PC9saT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEnPkluIG9yZGVyIHRvIDxiPjxpPnB1dDwvaT48L2I+IGEgbGFuZ3VhZ2UtdGFn IGludG8NCiAgICAgYSBjYW5vbmljYWwgZm9ybSwgdGhlIHRhZ3Mvc3VidGFncyA8Yj5NVVNUIGJl PC9iPiByZXBsYWNlZCBieSB0aGVpcg0KICAgICBQcmVmZXJyZWQtVmFsdWVzLjxvOnA+PC9vOnA+ PC9saT4NCjwvdWw+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPlRoZSB0ZXh0IHNob3VsZCBiZSByZXN0cnVjdHVyZWQNCnRvIHNvbWV0aGluZyBsaWtl IHRoZSBmb2xsb3dpbmcsIGFuZCBoYXZlIGNvbnNpc3RlbnQgdXNlIG9mIE1VU1QgZm9yIGVhY2gN CmNsYXVzZS4gSSB0cmllZCB0byBtYWtlIHRoZSBtaW5pbWFsIGNoYW5nZXMgbmVjZXNzYXJ5IHRv IHJlc29sdmUgdGhlIGlzc3VlLiBBdA0KdGhlIGVuZCwgd2UgY2FuIHRoZW4gbWFrZSBjbGVhciB0 aGF0IHRoZXJlIGFyZSBwZXJmZWN0bHkgZ29vZCBjaXJjdW1zdGFuY2VzDQp3aGVyZSBwZW9wbGUg Y2FuIC0tIHdpdGggcGVyZmVjdCByZWFzb24gLS0gYXZvaWQgZG9pbmcgdGhlIGV4dGxhbmcgbWFw cGluZywNCnVzaW5nIGEgcmVjYXN0IHZlcnNpb24gb2YgeW91ciBwYXJhZ3JhcGguPGJyPg0KPGJy Pg0KVGhlIGNoYW5nZXMgYXJlIG1hcmtlZCBpbiB5ZWxsb3cuPG86cD48L286cD48L3A+DQoNCjxw cmU+wqDCoCBBIGxhbmd1YWdlIHRhZyBpcyBpbiBjYW5vbmljYWwgZm9ybSB3aGVuOjxicj4NCjxi cj4NCsKgwqAgMS7CoCBUaGUgdGFnIGlzIHdlbGwtZm9ybWVkIGFjY29yZGluZyB0aGUgcnVsZXMg aW4gPGENCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbHRydS00 NjQ2YmlzLTIxI3NlY3Rpb24tMi4xIj5TZWN0aW9uIDIuMTwvYT4gYW5kPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoCA8YQ0KaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMtMjEjc2VjdGlvbi0yLjIiPlNlY3Rp b24gMi4yPC9hPi48YnI+DQo8YnI+DQrCoMKgIDxzcGFuIHN0eWxlPSdiYWNrZ3JvdW5kOiNGRkZG NjYnPjIuwqAgSXQgaGFzIGJlZW4gY2Fub25pY2FsaXplZCBhY2NvcmRpbmcgdG8gdGhlIGZvbGxv d2luZyBwcm9jZXNzOjwvc3Bhbj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGJy Pg0KwqDCoMKgwqAgMS7CoCBSZWR1bmRhbnQgb3IgZ3JhbmRmYXRoZXJlZCB0YWdzIHRoYXQgaGF2 ZSBhIFByZWZlcnJlZC1WYWx1ZTxicj4NCsKgwqDCoMKgwqDCoMKgwqAgbWFwcGluZyBpbiB0aGUg SUFOQSByZWdpc3RyeSAoc2VlIDxhDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWx0cnUtNDY0NmJpcy0yMSNzZWN0aW9uLTMuMSI+U2VjdGlvbiAzLjE8L2E+KSBN VVNUIGJlIHJlcGxhY2VkPGJyPg0KPGJyPg0KPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKg wqDCoMKgwqAgd2l0aCB0aGVpciBtYXBwZWQgdmFsdWUuwqAgVGhlc2UgaXRlbXMgZWl0aGVyIGFy ZSBkZXByZWNhdGVkPGJyPg0KwqDCoMKgwqDCoMKgwqDCoCBtYXBwaW5ncyBjcmVhdGVkIGJlZm9y ZSB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCAoc3VjaCBhczxicj4NCsKgwqDCoMKgwqDC oMKgwqAgdGhlIG1hcHBpbmcgb2YgJnF1b3Q7bm8tbnluJnF1b3Q7IHRvICZxdW90O25uJnF1b3Q7 IG9yICZxdW90O2kta2xpbmdvbiZxdW90OyB0byAmcXVvdDt0bGgmcXVvdDspIG9yIGFyZTxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKgwqDCoMKgIHRoZSByZXN1bHQg b2YgbGF0ZXIgcmVnaXN0cmF0aW9ucyBvciBhZGRpdGlvbnMgdG8gdGhpcyBkb2N1bWVudDxicj4N CsKgwqDCoMKgwqDCoMKgwqAgKGZvciBleGFtcGxlLCAmcXVvdDt6aC1oYWtrYSZxdW90OyB3YXMg ZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgSVNPIDYzOS0zPGJyPg0KwqDCoMKgwqDCoMKgwqDC oCBjb2RlICdoYWsnIHdoZW4gdGhpcyBkb2N1bWVudCB3YXMgYWRvcHRlZCkuwqAgVGhlc2UgbWFw cGluZ3M8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgwqDCoCA8 c3BhbiBzdHlsZT0nYmFja2dyb3VuZDojRkZGRjY2Jz5NVVNUIGJlIGFwcGxpZWQgYmVmb3JlIHN1 YnNlcXVlbnQgY2Fub25pY2FsaXphdGlvbiBzdGVwczwvc3Bhbj4sIDxicj4NCsKgwqDCoMKgwqDC oMKgwqAgc2luY2UgdGhlcmUgY2FuIGJlIGFkZGl0aW9uYWwgY2hhbmdlcyB0byA8c3BhbiBzdHls ZT0nYmFja2dyb3VuZDojRkZGRjY2Jz50aGUgbWFwcGVkIDwvc3Bhbj5zdWJ0YWcgdmFsdWVzLjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKgwqDCoMKgIFRoZXNlIGZp ZWxkLWJvZHkgb2YgdGhlPGJyPg0KwqDCoMKgwqDCoMKgwqDCoCBQcmVmZXJyZWQtVmFsdWUgZm9y IGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFudCB0YWdzIGlzIGFuPGJyPg0KwqDCoMKgwqDCoMKg wqDCoCAmcXVvdDtleHRlbmRlZCBsYW5ndWFnZSByYW5nZSZxdW90OyAoWzxhDQpocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjQ3IiB0aXRsZT0iJnF1b3Q7TWF0Y2hpbmcgb2Yg TGFuZ3VhZ2UgVGFncyZxdW90OyI+UkZDNDY0NzwvYT5dKSBhbmQgbWlnaHQgY29uc2lzdCBvZiBt b3JlPGJyPg0KPGJyPg0KPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoMKgwqAgdGhh biBvbmUgc3VidGFnLjxicj4NCjxicj4NCsKgwqDCoMKgIDIuwqAgU3VidGFncyBvZiB0eXBlICdl eHRsYW5nJyA8c3BhbiBzdHlsZT0nYmFja2dyb3VuZDojRkZGRjY2Jz5NVVNUPC9zcGFuPiBiZSBt YXBwZWQgdG8gdGhlaXIgUHJlZmVycmVkLTxicj4NCsKgwqDCoMKgwqDCoMKgwqAgVmFsdWUuwqAg VGhlIGZpZWxkLWJvZHkgb2YgdGhlIFByZWZlcnJlZC1WYWx1ZSBmb3IgZXh0bGFuZ3MgaXMgYW48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgwqDCoCAmcXVvdDtl eHRlbmRlZCBsYW5ndWFnZSByYW5nZSZxdW90OyBhbmQgdHlwaWNhbGx5IG1hcHMgdG8gYSBwcmlt YXJ5PGJyPg0KwqDCoMKgwqDCoMKgwqDCoCBsYW5ndWFnZSBzdWJ0YWcuwqAgRm9yIGV4YW1wbGUs IHRoZSBzdWJ0YWcgc2VxdWVuY2UgJnF1b3Q7emgtaGFrJnF1b3Q7PGJyPg0KwqDCoMKgwqDCoMKg wqDCoCAoQ2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJlcGxhY2VkIHdpdGggdGhlIHRhZyAmcXVv dDtoYWsmcXVvdDsgKEhha2thKS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGJy Pg0KwqDCoMKgwqAgMy7CoCBPdGhlciBzdWJ0YWdzIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1 ZSBmaWVsZCBpbiB0aGUgSUFOQTxicj4NCsKgwqDCoMKgwqDCoMKgwqAgcmVnaXN0cnkgKHNlZSA8 YQ0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZi aXMtMjEjc2VjdGlvbi0zLjEiPlNlY3Rpb24gMy4xPC9hPikgTVVTVCBiZSByZXBsYWNlZCB3aXRo IHRoZWlyIG1hcHBlZDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKg wqDCoMKgIHZhbHVlLsKgIE1vc3Qgb2YgdGhlc2UgYXJlIGVpdGhlciBSZWdpb24gc3VidGFncyB3 aGVyZSB0aGUgY291bnRyeTxicj4NCsKgwqDCoMKgwqDCoMKgwqAgbmFtZSBvciBkZXNpZ25hdGlv biBoYXMgY2hhbmdlZCBvciBjbGVyaWNhbCBjb3JyZWN0aW9ucyB0byBJU088YnI+DQrCoMKgwqDC oMKgwqDCoMKgIDYzOS0xLjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoCA0LsKgIElmIG1v cmUgdGhhbiBvbmUgZXh0ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZSBleGlzdHMsIHRoZSBleHRlbnNp b248YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgwqDCoCBzZXF1 ZW5jZXMgPHNwYW4gc3R5bGU9J2JhY2tncm91bmQ6I0ZGRkY2Nic+TVVTVCBiZTwvc3Bhbj4gb3Jk ZXJlZCBpbnRvIGNhc2UtaW5zZW5zaXRpdmUgQVNDSUkgb3JkZXIgYnk8YnI+DQrCoMKgwqDCoMKg wqDCoMKgIHNpbmdsZXRvbiBzdWJ0YWcgKHRoYXQgaXMsIHRoZSBzdWJ0YWcgc2VxdWVuY2UgJy1h LWJhYmJsZScgY29tZXM8YnI+DQrCoMKgwqDCoMKgwqDCoMKgIGJlZm9yZSAnLWItd2FyYmxlJyku PG86cD48L286cD48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdiYWNrZ3JvdW5kOg0KI0ZGRkY2Nic+ wqDCoCBTdGVwIDIuMiBtYXBzIGV4dGxhbmcgZmllbGRzIGJ5IHJlbW92aW5nIHRoZSBtYWNyb2xh bmd1YWdlIGluZm9ybWF0aW9uIGZyb20gdGhlPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSdiYWNr Z3JvdW5kOiNGRkZGNjYnPsKgwqAgdGFnLiBUaGF0IGluZm9ybWF0aW9uIGNhbiBiZSByZXN0b3Jl ZCB3aXRoIGFjY2VzcyB0byB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5Ljxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2JhY2tncm91bmQ6I0ZG RkY2Nic+wqDCoCBBIHBhcnRpYWwgY2Fub25pY2FsaXphdGlvbiAob21pdHRpbmcgc3RlcCAyLjIp IG1heSBhbHNvIGJlIHBlcmZvcm1lZC4gU3VjaCBhPGJyPg0KPGJyPg0KPG86cD48L286cD48L3Nw YW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nYmFja2dyb3VuZDojRkZGRjY2Jz7CoMKgIHBhcnRp YWwgY2Fub25pY2FsaXphdGlvbiBtYXkgYmUgdXNlZnVsIGluIGVudmlyb25tZW50cyB3aGVyZSB0 aGUgbWFjcm9sYW5ndWFnZTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+ PHNwYW4gc3R5bGU9J2JhY2tncm91bmQ6I0ZGRkY2Nic+wqDCoCBpcyB1c2VkIGluIG1hdGNoaW5n IG9yIHNlbGVjdGlvbiBhbmQgdGhlcmUgaXMgbm8gYWNjZXNzIHRvIHRoZSByZWdpc3RyeS48L3Nw YW4+PG86cD48L286cD48L3ByZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkZvciBjb21wYXJpc29u LCB0aGUgb3JpZ2luYWwgdGV4dCBpczo8YnI+DQo8YnI+DQpUaGUgb3JpZ2luYWwgdGV4dCBpczo8 bzpwPjwvbzpwPjwvcD4NCg0KPHByZT7CoMKgIEEgbGFuZ3VhZ2UgdGFnIGlzIGluIGNhbm9uaWNh bCBmb3JtIHdoZW46PGJyPg0KPGJyPg0KwqDCoCAxLsKgIFRoZSB0YWcgaXMgd2VsbC1mb3JtZWQg YWNjb3JkaW5nIHRoZSBydWxlcyBpbiA8YQ0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMtMjEjc2VjdGlvbi0yLjEiPlNlY3Rpb24gMi4xPC9h PiBhbmQ8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgIDxhDQpo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx0cnUtNDY0NmJpcy0y MSNzZWN0aW9uLTIuMiI+U2VjdGlvbiAyLjI8L2E+Ljxicj4NCjxicj4NCsKgwqAgMi7CoCBSZWR1 bmRhbnQgb3IgZ3JhbmRmYXRoZXJlZCB0YWdzIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1ZTxi cj4NCsKgwqDCoMKgwqDCoCBtYXBwaW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IChzZWUgPGENCmhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbHRydS00NjQ2YmlzLTIx I3NlY3Rpb24tMy4xIj5TZWN0aW9uIDMuMTwvYT4pIE1VU1QgYmUgcmVwbGFjZWQ8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgIHdpdGggdGhlaXIgbWFwcGVkIHZh bHVlLsKgIFRoZXNlIGl0ZW1zIGVpdGhlciBhcmUgZGVwcmVjYXRlZDxicj4NCsKgwqDCoMKgwqDC oCBtYXBwaW5ncyBjcmVhdGVkIGJlZm9yZSB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCAo c3VjaCBhczxicj4NCsKgwqDCoMKgwqDCoCB0aGUgbWFwcGluZyBvZiAmcXVvdDtuby1ueW4mcXVv dDsgdG8gJnF1b3Q7bm4mcXVvdDsgb3IgJnF1b3Q7aS1rbGluZ29uJnF1b3Q7IHRvICZxdW90O3Rs aCZxdW90Oykgb3IgYXJlPGJyPg0KPGJyPg0KPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKg wqDCoCB0aGUgcmVzdWx0IG9mIGxhdGVyIHJlZ2lzdHJhdGlvbnMgb3IgYWRkaXRpb25zIHRvIHRo aXMgZG9jdW1lbnQ8YnI+DQrCoMKgwqDCoMKgwqAgKGZvciBleGFtcGxlLCAmcXVvdDt6aC1oYWtr YSZxdW90OyB3YXMgZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgSVNPIDYzOS0zPGJyPg0KwqDC oMKgwqDCoMKgIGNvZGUgJ2hhaycgd2hlbiB0aGlzIGRvY3VtZW50IHdhcyBhZG9wdGVkKS7CoCBU aGVzZSBtYXBwaW5nczxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKg wqAgU0hPVUxEIGJlIGRvbmUgYmVmb3JlIGFkZGl0aW9uYWwgcHJvY2Vzc2luZywgc2luY2UgdGhl cmUgY2FuIGJlPGJyPg0KwqDCoMKgwqDCoMKgIGFkZGl0aW9uYWwgY2hhbmdlcyB0byBzdWJ0YWcg dmFsdWVzLsKgIFRoZXNlIGZpZWxkLWJvZHkgb2YgdGhlPGJyPg0KwqDCoMKgwqDCoMKgIFByZWZl cnJlZC1WYWx1ZSBmb3IgZ3JhbmRmYXRoZXJlZCBhbmQgcmVkdW5kYW50IHRhZ3MgaXMgYW48YnI+ DQrCoMKgwqDCoMKgwqAgJnF1b3Q7ZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UmcXVvdDsgKFs8YQ0K aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDY0NyIgdGl0bGU9IiZxdW90O01h dGNoaW5nIG9mIExhbmd1YWdlIFRhZ3MmcXVvdDsiPlJGQzQ2NDc8L2E+XSkgYW5kIG1pZ2h0IGNv bnNpc3Qgb2YgbW9yZTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKg wqAgdGhhbiBvbmUgc3VidGFnLjxicj4NCjxicj4NCsKgwqAgMy7CoCBTdWJ0YWdzIG9mIHR5cGUg J2V4dGxhbmcnIFNIT1VMRCBiZSBtYXBwZWQgdG8gdGhlaXIgUHJlZmVycmVkLTxicj4NCsKgwqDC oMKgwqDCoCBWYWx1ZS7CoCBUaGUgZmllbGQtYm9keSBvZiB0aGUgUHJlZmVycmVkLVZhbHVlIGZv ciBleHRsYW5ncyBpcyBhbjxicj4NCsKgwqDCoMKgwqDCoCAmcXVvdDtleHRlbmRlZCBsYW5ndWFn ZSByYW5nZSZxdW90OyBhbmQgdHlwaWNhbGx5IG1hcHMgdG8gYSBwcmltYXJ5PGJyPg0KPGJyPg0K PG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoCBsYW5ndWFnZSBzdWJ0YWcuwqAgRm9y IGV4YW1wbGUsIHRoZSBzdWJ0YWcgc2VxdWVuY2UgJnF1b3Q7emgtaGFrJnF1b3Q7PGJyPg0KwqDC oMKgwqDCoMKgIChDaGluZXNlLCBIYWtrYSkgd291bGQgYmUgcmVwbGFjZWQgd2l0aCB0aGUgdGFn ICZxdW90O2hhayZxdW90OyAoSGFra2EpLjxicj4NCjxicj4NCsKgwqAgNC7CoCBPdGhlciBzdWJ0 YWdzIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1ZSBmaWVsZCBpbiB0aGUgSUFOQTxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKgwqAgcmVnaXN0cnkgKHNlZSA8YQ0K aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMt MjEjc2VjdGlvbi0zLjEiPlNlY3Rpb24gMy4xPC9hPikgTVVTVCBiZSByZXBsYWNlZCB3aXRoIHRo ZWlyIG1hcHBlZDxicj4NCsKgwqDCoMKgwqDCoCB2YWx1ZS7CoCBNb3N0IG9mIHRoZXNlIGFyZSBl aXRoZXIgUmVnaW9uIHN1YnRhZ3Mgd2hlcmUgdGhlIGNvdW50cnk8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgIG5hbWUgb3IgZGVzaWduYXRpb24gaGFzIGNoYW5n ZWQgb3IgY2xlcmljYWwgY29ycmVjdGlvbnMgdG8gSVNPPGJyPg0KwqDCoMKgwqDCoMKgIDYzOS0x LjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIDUuwqAgSWYgbW9yZSB0aGFuIG9uZSBleHRlbnNp b24gc3VidGFnIHNlcXVlbmNlIGV4aXN0cywgdGhlIGV4dGVuc2lvbjxicj4NCsKgwqDCoMKgwqDC oCBzZXF1ZW5jZXMgYXJlIG9yZGVyZWQgaW50byBjYXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVy IGJ5PGJyPg0KPGJyPg0KPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoCBzaW5nbGV0 b24gc3VidGFnICh0aGF0IGlzLCB0aGUgc3VidGFnIHNlcXVlbmNlICctYS1iYWJibGUnIGNvbWVz PGJyPg0KwqDCoMKgwqDCoMKgIGJlZm9yZSAnLWItd2FyYmxlJykuPG86cD48L286cD48L3ByZT4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyIGNs ZWFyPWFsbD4NCk1hcms8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPk9uIFdlZCwgQXByIDI5LCAyMDA5IGF0IDE1OjQzLCBQaGlsbGlwcywg QWRkaXNvbiAmbHQ7PGENCmhyZWY9Im1haWx0bzphZGRpc29uQGFtYXpvbi5jb20iPmFkZGlzb25A YW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+VGhlIEFEIGFza2VkOjxicj4NCjxicj4NCi0tPGJyPg0KQUQgcmV2aWV3IGNvbW1lbnQg IzEyIGZyb208YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvbHRydS9jdXJyZW50L21zZzEyMzk5Lmh0bWwiDQp0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cxMjM5OS5odG1sPC9h Pjxicj4NCjxicj4NCjEyKS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7NC41LiBDYW5vbmljYWxp emF0aW9uIG9mIExhbmd1YWdlIFRhZ3M8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Wy4uLl08YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7My4gU3VidGFncyBvZiB0eXBlICdleHRsYW5nJyBTSE9VTEQg YmUgbWFwcGVkIHRvIHRoZWlyIFByZWZlcnJlZC08YnI+DQombmJzcDsgJm5ic3A7VmFsdWUuPGJy Pg0KPGJyPg0KV2h5IHVzZSBvZiBTSE9VTEQgaGVyZT8gSS5lLiB3aGF0IGlzIGEgZ29vZCByZWFz b24gZm9yIHZpb2xhdGluZyB0aGlzIHJ1bGU/PGJyPg0KQSBwb2ludGVyIGhlcmUgdG8gc29tZSBj YXNlKHMpIHdvdWxkIGJlIGFwcHJlY2lhdGVkIGhlcmUuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw O1RoZSBmaWVsZC1ib2R5IG9mIHRoZSBQcmVmZXJyZWQtVmFsdWUgZm9yIGV4dGxhbmdzIGlzIGFu PGJyPg0KJm5ic3A7ICZuYnNwOyZxdW90O2V4dGVuZGVkIGxhbmd1YWdlIHJhbmdlJnF1b3Q7IGFu ZCB0eXBpY2FsbHkgbWFwcyB0byBhDQpwcmltYXJ5PGJyPg0KJm5ic3A7ICZuYnNwO2xhbmd1YWdl IHN1YnRhZy4gRm9yIGV4YW1wbGUsIHRoZSBzdWJ0YWcgc2VxdWVuY2UNCiZxdW90O3poLWhhayZx dW90Ozxicj4NCiZuYnNwOyAmbmJzcDsoQ2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJlcGxhY2Vk IHdpdGggdGhlIHRhZyAmcXVvdDtoYWsmcXVvdDsNCihIYWtrYTxicj4NCi0tPGJyPg0KPGJyPg0K VGhlIGtleXdvcmQgaXMgKGNvcnJlY3RseSkgU0hPVUxEIGJlY2F1c2UgcmVtb3ZpbmcgdGhlIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFnDQpyZW1vdmVzIGluZm9ybWF0aW9uIHRoYXQgc29tZSBhcHBs aWNhdGlvbnMgbWF5IHdpc2ggdG8gcHJlc2VydmUuPGJyPg0KPGJyPg0KUHJvcG9zZWQgcmVzb2x1 dGlvbjo8YnI+DQo8YnI+DQpBZGQgdGhpcyB0ZXh0IHRvIHRoZSBhYm92ZSBwYXJhZ3JhcGgsIGlu ZGljYXRpbmcgd2h5IHlvdSBtaWdodCBub3QgcGVyZm9ybSB0aGUNCm1hcHBpbmc6PGJyPg0KPGJy Pg0KLS08YnI+DQpCZWNhdXNlIHRoaXMgaW52b2x2ZXMgcmVtb3ZpbmcgdGhlIG1hY3JvbGFuZ3Vh Z2UgaW5mb3JtYXRpb24gZnJvbSB0aGUgdGFnLCBhbg0KaW1wbGVtZW50YXRpb24gbWlnaHQgY2hv b3NlIG5vdCB0byBwZXJmb3JtIHRoaXMgcGFydGljdWxhciBjYW5vbmljYWxpemF0aW9uLCBpZg0K c3VjaCBhIGNhbm9uaWNhbGl6YXRpb24gd291bGQgcmVkdWNlIHRoZSBlZmZlY3RpdmVuZXNzIG9m IHRoYXQgcmVzdWx0aW5nIHRhZ3MNCmZvciBtYXRjaGluZyBvciBzZWxlY3Rpb24gbGF0ZXIuPGJy Pg0KLS08YnI+DQo8YnI+DQpBZGRpc29uIFBoaWxsaXBzPGJyPg0KR2xvYmFsaXphdGlvbiBBcmNo aXRlY3QgLS0gTGFiMTI2PGJyPg0KPGJyPg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEg ZmVhdHVyZS48YnI+DQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuPGJyPg0KPGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpMdHJ1IG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbHRydTwvYT48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+ DQoNCjwvaHRtbD4NCg== --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE33D68EXSEA5Dantama_-- From randy_presuhn@mindspring.com Wed Apr 29 20:01:30 2009 Return-Path: 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 0606E3A6C41 for ; Wed, 29 Apr 2009 20:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_20=-0.74] 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 8drbpHKyMICC for ; Wed, 29 Apr 2009 20:01:29 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4AF473A6B19 for ; Wed, 29 Apr 2009 20:01:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rHHzm5bR48ftwC792DC/kD9lD4Hiuoe7QYy9VuJ7SDrLwjSuhVPLXTzY32nsndlZ; 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 [69.3.145.200] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzMXz-0001yc-MF for ltru@ietf.org; Wed, 29 Apr 2009 23:02:51 -0400 Message-ID: <003601c9c940$88ad04a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AF43@EX-SEA5-D.ant.amazon.com> Date: Wed, 29 Apr 2009 20:05:35 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968692864cdf5bf7d65af5c476823e9b70a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.200 Subject: Re: [Ltru] can't find a reference for ticket #31 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 03:01:30 -0000 Hi - > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Wednesday, April 29, 2009 4:22 PM > Subject: [Ltru] can't find a reference for ticket #31 > > Could somebody point me to Kent's email so I can correct the titles? http://www.ietf.org/mail-archive/web/ltru/current/msg12285.html Randy From doug@ewellic.org Wed Apr 29 20:31:17 2009 Return-Path: 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 13B883A67D1 for ; Wed, 29 Apr 2009 20:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] 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 Dyy597zb7xaR for ; Wed, 29 Apr 2009 20:31:16 -0700 (PDT) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id 1935828C0EE for ; Wed, 29 Apr 2009 20:30:57 -0700 (PDT) Received: (qmail 25721 invoked from network); 30 Apr 2009 03:32:19 -0000 Received: from unknown (67.166.27.148) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 30 Apr 2009 03:32:18 -0000 Message-ID: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 29 Apr 2009 21:32:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 03:31:17 -0000 Mark Davis wrote: > The changes are marked in yellow. Not useful when reading the plain-text digest. > A language tag is in canonical form when: > ... > 2. It has been canonicalized according to the following process: > ... > 2. Subtags of type 'extlang' MUST be mapped to their Preferred-Value. As Addison pointed out, the existing wording with SHOULD was a compromise. The battle between extlang and no-extlang camps was lengthy and painful, and this was the wording the WG finally agreed upon. I object to using the IETF Last Call process to undo this compromise and swing the wording back in favor of the no-extlang side. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From bortzmeyer@nic.fr Thu Apr 30 07:34:59 2009 Return-Path: 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 5C8423A6EF1 for ; Thu, 30 Apr 2009 07:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 w8lScmo83mKE for ; Thu, 30 Apr 2009 07:34:58 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id 7AB283A6F0A for ; Thu, 30 Apr 2009 07:34:58 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0F2A11C0117 for ; Thu, 30 Apr 2009 16:36:19 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0B6FE1C0020 for ; Thu, 30 Apr 2009 16:36:19 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id F3FC17B003D for ; Thu, 30 Apr 2009 16:36:18 +0200 (CEST) Date: Thu, 30 Apr 2009 16:36:18 +0200 From: Stephane Bortzmeyer To: LTRU Working Group Message-ID: <20090430143618.GA1373@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Ltru] [OT] Language icon X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:34:59 -0000 http://languageicon.org/ You have finally found the "language icon", the language icon is an initiative to standardise language selection icon. [...] ... When you create a multi-lingual web page, you are limited to use flags, language names or iso codes. You did not have an option to use an icon to signify "choose/select/switch language", as no such icon existed. From cowan@ccil.org Thu Apr 30 07:49:10 2009 Return-Path: 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 D56323A6ECA for ; Thu, 30 Apr 2009 07:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 Cwyfv3KE56kH for ; Thu, 30 Apr 2009 07:49:10 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id F10483A68FD for ; Thu, 30 Apr 2009 07:49:09 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LzXaq-0004Wb-Ah; Thu, 30 Apr 2009 10:50:32 -0400 Date: Thu, 30 Apr 2009 10:50:32 -0400 To: Stephane Bortzmeyer Message-ID: <20090430145032.GD15356@mercury.ccil.org> References: <20090430143618.GA1373@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090430143618.GA1373@nic.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] [OT] Language icon X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:49:10 -0000 Stephane Bortzmeyer scripsit: > http://languageicon.org/ > > You have finally found the "language icon", the language icon is an > initiative to standardise language selection icon. [...] It looks like an emoji symbol for the Arc de Triomphe. -- While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like cowan@ccil.org ours, only more of it consists of Toronto. http://www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes From addison@amazon.com Thu Apr 30 08:19:18 2009 Return-Path: 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 0BCE43A6C19 for ; Thu, 30 Apr 2009 08:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.562 X-Spam-Level: X-Spam-Status: No, score=-107.562 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, GB_I_LETTER=-2, 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 vbi0lqVBcQqT for ; Thu, 30 Apr 2009 08:19:16 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 8555B3A69E9 for ; Thu, 30 Apr 2009 08:19:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208";a="179132979" Received: from smtp-in-0201.sea3.amazon.com ([172.20.19.24]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 15:20:38 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-0201.sea3.amazon.com (8.12.11/8.12.11) with ESMTP id n3UFKbSC000526 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 15:20:37 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Thu, 30 Apr 2009 08:20:34 -0700 From: "Phillips, Addison" To: Doug Ewell , LTRU Working Group Date: Thu, 30 Apr 2009 08:20:32 -0700 Thread-Topic: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping Thread-Index: AcnJRF4RJ71siZV8S1Gk0rrF4D+gOgAXzvFQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> In-Reply-To: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:19:18 -0000 T2theSwgSSd2ZSBmaW5pc2hlZCBnZW5lcmF0aW5nIHRoZSBuZXcgZHJhZnQgYW5kIGRpZmZpbmcg aXQuIE91ciBvbmx5IHJlbWFpbmluZyBvcGVuIGl0ZW0gaXMgdGhpcyBpc3N1ZS4NCg0KTGFzdCBu aWdodCBJIHByb3Bvc2VkIGRlZmluaW5nIHR3byBjYW5vbmljYWwgZm9ybXMgdG8gcmVzb2x2ZSB0 aGUgbXVkZGluZXNzIG9mICJTSE9VTEQiLiBJIG5vdyBoYXZlIGEgc2VwYXJhdGUgZWRpdG9yJ3Mg Y29weSBvZiB0aGUgZHJhZnQgd2l0aCBhIHByb3Bvc2VkIGVkaXQgdG8gYWNjb21wbGlzaCB0aGlz LiBDby1jaGFpciBndWlkYW5jZSBvbiB0aGlzIGlzc3VlIGlzIHZlcnkgbXVjaCBkZXNpcmVkLg0K DQpCZWxvdyBpcyBteSBwcm9wb3NlZCBlZGl0ZWQgdGV4dCBmb3Igc2VjdGlvbiA0LjUuIFN1Z2dl c3Rpb25zIGFuZCBmaXhlcyBhcmUgd2VsY29tZS4gSW4gcGFydGljdWxhciwgSSBoYXZlbid0IHNh aWQgYW55dGhpbmcgYWJvdXQgd2hlbiB0byB1c2Ugd2hpY2ggZm9ybS4NCg0KLS0NCjQuNS4gIENh bm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0KDQogICBTaW5jZSBhIHBhcnRpY3VsYXIg bGFuZ3VhZ2UgdGFnIGlzIHNvbWV0aW1lcyB1c2VkIGJ5IG1hbnkgcHJvY2Vzc2VzLA0KICAgbGFu Z3VhZ2UgdGFncyBTSE9VTEQgYWx3YXlzIGJlIGNyZWF0ZWQgb3IgZ2VuZXJhdGVkIGluIGEgY2Fu b25pY2FsDQogICBmb3JtLg0KDQogICBUaGVyZSBhcmUgdHdvIGNhbm9uaWNhbCBmb3JtcyBmb3Ig bGFuZ3VhZ2UgdGFncy4gIFRoZSAnZGVmYXVsdCcNCiAgIGNhbm9uaWNhbCBmb3JtIG1hcHMgZWFj aCAnZXh0bGFuZycgc3VidGFnIHRvIGl0cyBQcmVmZXJyZWQtVmFsdWUuDQogICBUaGUgJ2V4dGVu ZGVkJyBjYW5vbmljYWwgZm9ybSBpbmNsdWRlcyB0aGUgbWFjcm9sYW5ndWFnZSBwcmltYXJ5DQog ICBsYW5ndWFnZSBzdWJ0YWcgYmVmb3JlIGVsaWdpYmxlIChleHRlbmRlZCkgbGFuZ3VhZ2Ugc3Vi dGFncy4NCg0KICAgQSBsYW5ndWFnZSB0YWcgaXMgaW4gYSBjYW5vbmljYWwgZm9ybSB3aGVuOg0K DQogICAxLiAgVGhlIHRhZyBpcyB3ZWxsLWZvcm1lZCBhY2NvcmRpbmcgdGhlIHJ1bGVzIGluIFNl Y3Rpb24gMi4xIGFuZA0KICAgICAgIFNlY3Rpb24gMi4yLg0KDQogICAyLiAgUmVkdW5kYW50IG9y IGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUNCiAgICAgICBt YXBwaW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IChzZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVw bGFjZWQNCiAgICAgICB3aXRoIHRoZWlyIG1hcHBlZCB2YWx1ZS4gIFRoZXNlIGl0ZW1zIGVpdGhl ciBhcmUgZGVwcmVjYXRlZA0KICAgICAgIG1hcHBpbmdzIGNyZWF0ZWQgYmVmb3JlIHRoZSBhZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50IChzdWNoIGFzDQogICAgICAgdGhlIG1hcHBpbmcgb2YgIm5v LW55biIgdG8gIm5uIiBvciAiaS1rbGluZ29uIiB0byAidGxoIikgb3IgYXJlDQogICAgICAgdGhl IHJlc3VsdCBvZiBsYXRlciByZWdpc3RyYXRpb25zIG9yIGFkZGl0aW9ucyB0byB0aGlzIGRvY3Vt ZW50DQogICAgICAgKGZvciBleGFtcGxlLCAiemgtaGFra2EiIHdhcyBkZXByZWNhdGVkIGluIGZh dm9yIG9mIHRoZSBJU08gNjM5LTMNCiAgICAgICBjb2RlICdoYWsnIHdoZW4gdGhpcyBkb2N1bWVu dCB3YXMgYWRvcHRlZCkuICBUaGVzZSBtYXBwaW5ncw0KICAgICAgIFNIT1VMRCBiZSBkb25lIGJl Zm9yZSBhZGRpdGlvbmFsIHByb2Nlc3NpbmcsIHNpbmNlIHRoZXJlIGNhbiBiZQ0KICAgICAgIGFk ZGl0aW9uYWwgY2hhbmdlcyB0byBzdWJ0YWcgdmFsdWVzLiAgVGhlc2UgZmllbGQtYm9keSBvZiB0 aGUNCiAgICAgICBQcmVmZXJyZWQtVmFsdWUgZm9yIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFu dCB0YWdzIGlzIGFuDQogICAgICAgImV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIiAoW1JGQzQ2NDdd KSBhbmQgbWlnaHQgY29uc2lzdCBvZiBtb3JlDQogICAgICAgdGhhbiBvbmUgc3VidGFnLg0KDQog ICAzLiAgSW4gdGhlICdkZWZhdWx0JyBjYW5vbmljYWwgZm9ybSwgc3VidGFncyBvZiB0eXBlICdl eHRsYW5nJyBNVVNUDQogICAgICAgYmUgbWFwcGVkIHRvIHRoZWlyIFByZWZlcnJlZC1WYWx1ZS4g IFRoZSBmaWVsZC1ib2R5IG9mIHRoZQ0KICAgICAgIFByZWZlcnJlZC1WYWx1ZSBmb3IgZXh0bGFu Z3MgaXMgYW4gImV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIiwNCiAgICAgICB0eXBpY2FsbHkgYSBw cmltYXJ5IGxhbmd1YWdlIHN1YnRhZyAoaW4gYWxsIHN1Y2ggY2FzZXMsIHRoZQ0KICAgICAgIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHJlbW92ZWQpLiAgRm9yIGV4YW1wbGUsIHRoZSBzdWJ0 YWcNCiAgICAgICBzZXF1ZW5jZSAiemgtaGFrIiAoQ2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJl cGxhY2VkIHdpdGggdGhlIHRhZw0KICAgICAgICJoYWsiIChIYWtrYSkuDQoNCiAgIDQuICBJbiB0 aGUgJ2V4dGVuZGVkJyBjYW5vbmljYWwgZm9ybSwgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIHdp dGggYQ0KICAgICAgICdNYWNyb2xhbmd1YWdlJyBmaWVsZCB0aGF0IGFyZSBhbHNvIHJlZ2lzdGVy ZWQgYXMgJ2V4dGxhbmcnDQogICAgICAgc3VidGFncyBNVVNUIGJlIHJlcGxhY2VkIGJ5IHRoZWly IG1hY3JvbGFuZ3VhZ2UtZXh0bGFuZw0KICAgICAgIGNvbWJpbmF0aW9uLiAgRm9yIGV4YW1wbGUs IHRoZSBsYW5ndWFnZSB0YWcgImhhayIgKEhha2thKSBoYXMgYQ0KICAgICAgIE1hY3JvbGFuZ3Vh Z2Ugb2YgJ3poJyAoQ2hpbmVzZSkgYW5kIGFuIGV4aXN0aW5nICdleHRsYW5nJw0KICAgICAgIHJl Z2lzdHJhdGlvbi4gIFRoZSB0YWcgd291bGQgYmUgcmVwbGFjZWQgd2l0aCB0aGF0IHRhZyAiemgt aGFrIg0KICAgICAgIChDaGluZXNlLCBIYWtrYSkuDQoNCiAgIDUuICBPdGhlciBzdWJ0YWdzIHRo YXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1ZSBmaWVsZCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lz dHJ5IChzZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwZWQN CiAgICAgICB2YWx1ZS4gIE1vc3Qgb2YgdGhlc2UgYXJlIGVpdGhlciBSZWdpb24gc3VidGFncyB3 aGVyZSB0aGUgY291bnRyeQ0KICAgICAgIG5hbWUgb3IgZGVzaWduYXRpb24gaGFzIGNoYW5nZWQg b3IgY2xlcmljYWwgY29ycmVjdGlvbnMgdG8gSVNPDQogICAgICAgNjM5LTEuDQoNCiAgIDYuICBJ ZiBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2UgZXhpc3RzLCB0aGUgZXh0 ZW5zaW9uDQogICAgICAgc2VxdWVuY2VzIGFyZSBvcmRlcmVkIGludG8gY2FzZS1pbnNlbnNpdGl2 ZSBBU0NJSSBvcmRlciBieQ0KICAgICAgIHNpbmdsZXRvbiBzdWJ0YWcgKHRoYXQgaXMsIHRoZSBz dWJ0YWcgc2VxdWVuY2UgJy1hLWJhYmJsZScgY29tZXMNCiAgICAgICBiZWZvcmUgJy1iLXdhcmJs ZScpLg0KDQogICBFeGFtcGxlOiBUaGUgbGFuZ3VhZ2UgdGFnICJlbi1hLWFhYS1iLWNjYy1iYmIt eC14eXoiIGlzIGluIGNhbm9uaWNhbA0KICAgZm9ybSwgd2hpbGUgImVuLWItY2NjLWJiYi1hLWFh YS1YLXh5eiIgaXMgd2VsbC1mb3JtZWQgYW5kIHBvdGVudGlhbGx5DQogICB2YWxpZCAoZXh0ZW5z aW9ucyAnYScgYW5kICdiJyBhcmUgbm90IGRlZmluZWQgYXMgb2YgdGhlIHB1YmxpY2F0aW9uDQog ICBvZiB0aGlzIGRvY3VtZW50KSBidXQgbm90IGluIGNhbm9uaWNhbCBmb3JtICh0aGUgZXh0ZW5z aW9ucyBhcmUgbm90DQogICBpbiBhbHBoYWJldGljYWwgb3JkZXIpLg0KDQogICBFeGFtcGxlOiBB bHRob3VnaCB0aGUgdGFnICJlbi1CVSIgKEVuZ2xpc2ggYXMgdXNlZCBpbiBCdXJtYSkNCiAgIG1h aW50YWlucyBpdHMgdmFsaWRpdHksIHRoZSBsYW5ndWFnZSB0YWcgImVuLUJVIiBpcyBub3QgY2Fu b25pY2FsDQogICBiZWNhdXNlIHRoZSAnQlUnIHN1YnRhZyBoYXMgYSBjYW5vbmljYWwgbWFwcGlu ZyB0byAnTU0nIChNeWFubWFyKS4NCg0KICAgQ2Fub25pY2FsaXphdGlvbiBvZiBsYW5ndWFnZSB0 YWdzIGRvZXMgbm90IGltcGx5IGFueXRoaW5nIGFib3V0IHRoZQ0KICAgdXNlIG9mIHVwcGVyIG9y IGxvd2VyY2FzZSBsZXR0ZXJzIHdoZW4gcHJvY2Vzc2luZyBvciBjb21wYXJpbmcNCiAgIHN1YnRh Z3MgKGFuZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEpLiAgQWxsIGNvbXBhcmlzb25zIE1V U1QgYmUNCiAgIHBlcmZvcm1lZCBpbiBhIGNhc2UtaW5zZW5zaXRpdmUgbWFubmVyLg0KDQogICBX aGVuIHBlcmZvcm1pbmcgY2Fub25pY2FsaXphdGlvbiBvZiBsYW5ndWFnZSB0YWdzLCBwcm9jZXNz b3JzIE1BWQ0KICAgcmVndWxhcml6ZSB0aGUgY2FzZSBvZiB0aGUgc3VidGFncyAodGhhdCBpcywg dGhpcyBwcm9jZXNzIGlzDQogICBPUFRJT05BTCksIGZvbGxvd2luZyB0aGUgY2FzZSB1c2VkIGlu IHRoZSByZWdpc3RyeSAoc2VlDQogICBTZWN0aW9uIDIuMS4xKS4NCg0KICAgSWYgbW9yZSB0aGFu IG9uZSB2YXJpYW50IGFwcGVhcnMgd2l0aGluIGEgdGFnLCBwcm9jZXNzb3JzIE1BWSByZW9yZGVy DQogICB0aGUgdmFyaWFudHMgdG8gb2J0YWluIGJldHRlciBtYXRjaGluZyBiZWhhdmlvciBvciBt b3JlIGNvbnNpc3RlbnQNCiAgIHByZXNlbnRhdGlvbi4gIFJlb3JkZXJpbmcgb2YgdGhlIHZhcmlh bnRzIFNIT1VMRCBmb2xsb3cgdGhlDQogICByZWNvbW1lbmRhdGlvbnMgZm9yIHZhcmlhbnQgb3Jk ZXJpbmcgaW4gU2VjdGlvbiA0LjEuDQoNCiAgIElmIHRoZSBmaWVsZCAnRGVwcmVjYXRlZCcgYXBw ZWFycyBpbiBhIHJlZ2lzdHJ5IHJlY29yZCB3aXRob3V0IGFuDQogICBhY2NvbXBhbnlpbmcgJ1By ZWZlcnJlZC1WYWx1ZScgZmllbGQsIHRoZW4gdGhhdCB0YWcgb3Igc3VidGFnIGlzDQogICBkZXBy ZWNhdGVkIHdpdGhvdXQgYSByZXBsYWNlbWVudC4gIFRoZXNlIHZhbHVlcyBhcmUgY2Fub25pY2Fs IHdoZW4NCiAgIHRoZXkgYXBwZWFyIGluIGEgbGFuZ3VhZ2UgdGFnLiAgSG93ZXZlciwgdGFncyB0 aGF0IGluY2x1ZGUgdGhlc2UNCiAgIHZhbHVlcyBTSE9VTEQgTk9UIGJlIHNlbGVjdGVkIGJ5IHVz ZXJzIG9yIGdlbmVyYXRlZCBieQ0KICAgaW1wbGVtZW50YXRpb25zLg0KDQogICBBbiBleHRlbnNp b24gTVVTVCBkZWZpbmUgYW55IHJlbGF0aW9uc2hpcHMgdGhhdCBleGlzdCBiZXR3ZWVuIHRoZQ0K ICAgdmFyaW91cyBzdWJ0YWdzIGluIHRoZSBleHRlbnNpb24gYW5kIHRodXMgTUFZIGRlZmluZSBh biBhbHRlcm5hdGUNCiAgIGNhbm9uaWNhbGl6YXRpb24gc2NoZW1lIGZvciB0aGUgZXh0ZW5zaW9u J3Mgc3VidGFncy4gIEV4dGVuc2lvbnMgTUFZDQogICBkZWZpbmUgaG93IHRoZSBvcmRlciBvZiB0 aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncyBhcmUgaW50ZXJwcmV0ZWQuICBGb3INCiAgIGV4YW1wbGUs IGFuIGV4dGVuc2lvbiBjb3VsZCBkZWZpbmUgdGhhdCBpdHMgc3VidGFncyBhcmUgaW4gY2Fub25p Y2FsDQogICBvcmRlciB3aGVuIHRoZSBzdWJ0YWdzIGFyZSBwbGFjZWQgaW50byBBU0NJSSBvcmRl cjogdGhhdCBpcywgImVuLWEtDQogICBhYWEtYmJiLWNjYyIgaW5zdGVhZCBvZiAiZW4tYS1jY2Mt YmJiLWFhYSIuICBBbm90aGVyIGV4dGVuc2lvbiBtaWdodA0KICAgZGVmaW5lIHRoYXQgdGhlIG9y ZGVyIG9mIHRoZSBzdWJ0YWdzIGluZmx1ZW5jZXMgdGhlaXIgc2VtYW50aWMNCiAgIG1lYW5pbmcg KHNvIHRoYXQgImVuLWItY2NjLWJiYi1hYWEiIGhhcyBhIGRpZmZlcmVudCB2YWx1ZSBmcm9tICJl bi1iLQ0KICAgYWFhLWJiYi1jY2MiKS4gIEhvd2V2ZXIsIGV4dGVuc2lvbiBzcGVjaWZpY2F0aW9u cyBTSE9VTEQgYmUgZGVzaWduZWQNCiAgIHNvIHRoYXQgdGhleSBhcmUgdG9sZXJhbnQgb2YgdGhl IHR5cGljYWwgcHJvY2Vzc2VzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjcuDQotLQ0KDQpB ZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50 ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVy ZS4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9m IERvdWcgRXdlbGwNCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyOSwgMjAwOSA4OjMyIFBNDQo+ IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBUaWNrZXQgIzQ1 OiBBRCBJc3N1ZSAjMTI6IHJlYXNvbiBmb3IgU0hPVUxEIGluDQo+IDQuNSBleHRsYW5nIG1hcHBp bmcNCj4gDQo+IE1hcmsgRGF2aXMgPG1hcmsgYXQgbWFjY2hpYXRvIGRvdCBjb20+IHdyb3RlOg0K PiANCj4gPiBUaGUgY2hhbmdlcyBhcmUgbWFya2VkIGluIHllbGxvdy4NCj4gDQo+IE5vdCB1c2Vm dWwgd2hlbiByZWFkaW5nIHRoZSBwbGFpbi10ZXh0IGRpZ2VzdC4NCj4gDQo+ID4gQSBsYW5ndWFn ZSB0YWcgaXMgaW4gY2Fub25pY2FsIGZvcm0gd2hlbjoNCj4gPiAuLi4NCj4gPiAyLiAgSXQgaGFz IGJlZW4gY2Fub25pY2FsaXplZCBhY2NvcmRpbmcgdG8gdGhlIGZvbGxvd2luZyBwcm9jZXNzOg0K PiA+IC4uLg0KPiA+IDIuICBTdWJ0YWdzIG9mIHR5cGUgJ2V4dGxhbmcnIE1VU1QgYmUgbWFwcGVk IHRvIHRoZWlyIFByZWZlcnJlZC0NCj4gVmFsdWUuDQo+IA0KPiBBcyBBZGRpc29uIHBvaW50ZWQg b3V0LCB0aGUgZXhpc3Rpbmcgd29yZGluZyB3aXRoIFNIT1VMRCB3YXMgYQ0KPiBjb21wcm9taXNl LiAgVGhlIGJhdHRsZSBiZXR3ZWVuIGV4dGxhbmcgYW5kIG5vLWV4dGxhbmcgY2FtcHMgd2FzDQo+ IGxlbmd0aHkNCj4gYW5kIHBhaW5mdWwsIGFuZCB0aGlzIHdhcyB0aGUgd29yZGluZyB0aGUgV0cg ZmluYWxseSBhZ3JlZWQgdXBvbi4NCj4gSQ0KPiBvYmplY3QgdG8gdXNpbmcgdGhlIElFVEYgTGFz dCBDYWxsIHByb2Nlc3MgdG8gdW5kbyB0aGlzIGNvbXByb21pc2UNCj4gYW5kDQo+IHN3aW5nIHRo ZSB3b3JkaW5nIGJhY2sgaW4gZmF2b3Igb2YgdGhlIG5vLWV4dGxhbmcgc2lkZS4NCj4gDQo+IC0t DQo+IERvdWcgRXdlbGwgICogIFRob3JudG9uLCBDb2xvcmFkbywgVVNBICAqICBSRkMgNDY0NSAg KiAgVVROICMxNA0KPiBodHRwOi8vd3d3LmV3ZWxsaWMub3JnDQo+IGh0dHA6Ly93d3cxLmlldGYu b3JnL2h0bWwuY2hhcnRlcnMvbHRydS1jaGFydGVyLmh0bWwNCj4gaHR0cDovL3d3dy5hbHZlc3Ry YW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFnZXMgIMuGDQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWls aW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2x0cnUNCg== From cowan@ccil.org Thu Apr 30 08:32:59 2009 Return-Path: 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 2868928C18E for ; Thu, 30 Apr 2009 08:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 h7qOdR24wdFb for ; Thu, 30 Apr 2009 08:32:51 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 103CD28C2E9 for ; Thu, 30 Apr 2009 08:31:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LzYFZ-0000b3-Cx; Thu, 30 Apr 2009 11:32:37 -0400 Date: Thu, 30 Apr 2009 11:32:37 -0400 To: "Phillips, Addison" Message-ID: <20090430153237.GF15356@mercury.ccil.org> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:32:59 -0000 Phillips, Addison scripsit: > 3. In the 'default' canonical form, subtags of type 'extlang' MUST > 4. In the 'extended' canonical form, primary language subtags with a I propose the names "short" and "long" respectively. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Any day you get all five woodpeckers is a good day. --Elliotte Rusty Harold From addison@amazon.com Thu Apr 30 09:11:52 2009 Return-Path: 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 0D7173A69C2 for ; Thu, 30 Apr 2009 09:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 jsAk5X3VKrtn for ; Thu, 30 Apr 2009 09:11:51 -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 189C33A681D for ; Thu, 30 Apr 2009 09:11:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208";a="260478656" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 16:13:13 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3UGDDAV022484 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 16:13:13 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Thu, 30 Apr 2009 09:13:12 -0700 From: "Phillips, Addison" To: John Cowan Date: Thu, 30 Apr 2009 09:13:11 -0700 Thread-Topic: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping Thread-Index: AcnJqOWBsTZ5LZ8tS0y3dO4L1hGiyAABI6/Q Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE3414C@EX-SEA5-D.ant.amazon.com> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> <20090430153237.GF15356@mercury.ccil.org> In-Reply-To: <20090430153237.GF15356@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:11:52 -0000 KGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IpDQo+IA0KPiA+ICAgIDMuICBJbiB0aGUgJ2RlZmF1 bHQnIGNhbm9uaWNhbCBmb3JtLCBzdWJ0YWdzIG9mIHR5cGUgJ2V4dGxhbmcnDQo+IE1VU1QNCj4g PiAgICA0LiAgSW4gdGhlICdleHRlbmRlZCcgY2Fub25pY2FsIGZvcm0sIHByaW1hcnkgbGFuZ3Vh Z2Ugc3VidGFncw0KPiB3aXRoIGENCj4gDQo+IEkgcHJvcG9zZSB0aGUgbmFtZXMgInNob3J0IiBh bmQgImxvbmciIHJlc3BlY3RpdmVseS4NCg0KJ2V4dGVuZGVkJyBzZWVtcyBsaWtlIGEgbW9yZSBu YXR1cmFsIG5hbWUgZm9yIHRoZSBsYXR0ZXIgZm9ybS4gSSBhY2tub3dsZWRnZSB0aGF0IHRoZSBu YW1lICdkZWZhdWx0JyBpcyBwcmVqdWRpY2lhbCwgaW4gaXRzIHdheSwgYnV0IGl0IHdhcyB0aGUg cHJldmlvdXMgaW50ZW50IG9mICdTSE9VTEQnIGFuZCBpdCBpcyB0aGUgY2Fub25pY2FsIGZvcm0g dGhhdCB0aGUgcmVnaXN0cnkgaXMgb3B0aW1pemVkIGZvci4gSWYgd2UgZG9uJ3Qgd2FudCB0byBz YXkgdGhhdCBpdCdzIHRoZSBkZWZhdWx0LCB3ZSBjb3VsZCBwaWNrIGEgbmFtZSB0aGF0IGlzIHBh cnRpYWwgYW50b255bSBmb3IgJ2V4dGVuZGVkJywgc3VjaCBhcyAnY29tcGFjdCcsICdyZWd1bGFy Jywgb3IgKGhtbS4uLikgJ3Nob3J0Jy4gSG93IGFib3V0ICdzaG9ydCcgYW5kICdleHRlbmRlZCc/ DQoNCklmIHdlIGRvbid0IHNheSAnZGVmYXVsdCcgKG9yIGV2ZW4gaWYgd2UgZG8pLCBvdWdodG4n dCB3ZSB0byBoYXZlIHNvbWUgdGV4dCBleHBsYWluaW5nIHdoZW4gdG8gdXNlIHdoaWNoPw0KDQpB ZGRpc29uDQoNCj4gQW55IGRheSB5b3UgZ2V0IGFsbCBmaXZlIHdvb2RwZWNrZXJzIGlzIGEgZ29v ZCBkYXkuICAtLUVsbGlvdHRlDQo+IFJ1c3R5IEhhcm9sZA0KDQpBbGwgZml2ZSB3b29kcGVja2Vy cz8hPw0K From randy_presuhn@mindspring.com Thu Apr 30 09:37:09 2009 Return-Path: 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 C55B43A6E95 for ; Thu, 30 Apr 2009 09:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 phH5gq9K1us0 for ; Thu, 30 Apr 2009 09:37:09 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 0874928C293 for ; Thu, 30 Apr 2009 09:36:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rfYtH5F79YfSvzrLGWSYIy6cyilLoNYy3165zcTWDEj07il3B5looIC344GzAVym; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzZH8-0003Jz-Dl for ltru@ietf.org; Thu, 30 Apr 2009 12:38:18 -0400 Message-ID: <004001c9c9b2$7487fa80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A591@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 09:41:04 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69684867a0e080ebdc1832f6dba1666e0bad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #35, AD Issue #2: what is meant by "permanently reserved" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:37:09 -0000 Hi - As co-chair... Since there have been no objections to Addison's proposed replacement text, and it seems to address the AD's concern, I've included the resolution in the problem report http://trac.tools.ietf.org/wg/ltru/trac/ticket/35 and closed the issue. Randy ----- Original Message ----- > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Tuesday, April 28, 2009 9:11 PM > Subject: [Ltru] Ticket #35,AD Issue #2: what is meant by "permanently reserved" > > The AD opined: > > -- > [Unclear text] Clarification on what is meant by "permanently reserved" > here would be appreciated. > ("Permanently reserved" == "MUST NOT be registered, unless a future > version of this document changes that"?) > -- > > The text seems to indicate that additional extlangs are forever banned. I propose to make it clearer by changing this text: > > -- > That is, the second and third extended language subtag positions in a language tag are permanently reserved and tags that include subtags in that position are invalid. > -- > > ... to read... > > -- > That is, the second and third extended language subtag positions in a language tag are permanently reserved and tags that include those subtags in that position are, and will always remain, invalid. > -- > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru From randy_presuhn@mindspring.com Thu Apr 30 09:48:04 2009 Return-Path: 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 1599E3A6842 for ; Thu, 30 Apr 2009 09:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 YOxpcEawR9hG for ; Thu, 30 Apr 2009 09:48:03 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id DA0803A6885 for ; Thu, 30 Apr 2009 09:48:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dbyr5Bx0UXcBFvQAW3sWT4uGUOEkZ3j+sQynZ3UOgQU+8PGvyIYYMSfs9+z0Yawq; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzZRs-0002H7-43 for ltru@ietf.org; Thu, 30 Apr 2009 12:49:24 -0400 Message-ID: <004e01c9c9b4$01734e80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5A6@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 09:52:10 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69685d1e20113d200ae616431e2da9b16496350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #36: AD Issue #3: rules for UN M.49 codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:48:04 -0000 Hi - As a technical contributor... > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Tuesday, April 28, 2009 9:38 PM > Subject: [Ltru] Ticket #36: AD Issue #3: rules for UN M.49 codes > > The AD suggested: > > -- > Issue #3 from AD review - for details see > http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html > > 3). Section 2.2.4 says: > > F. All other UN numeric codes for countries or areas that do not > have an associated ISO 3166-1 alpha-2 code MUST NOT be > entered into the registry and MUST NOT be used to form > language tags. For more information about these codes, see > Section 3.4. > > And Section 3.4 says: > > 16. UN M.49 has codes for both countries and areas (such as '276' > for Germany) and geographical regions and sub-regions (such as > '150' for Europe). UN M.49 country or area codes for which > there is no corresponding ISO 3166-1 code SHOULD NOT be > > Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in > section 2.2.4. > I think you need to change one of 2 sections. > > registered, except as a surrogate for an ISO 3166-1 code that is > blocked from registration by an existing subtag. If such a code > becomes necessary, then the registration authority for ISO > 3166-1 SHOULD first be petitioned to assign a code to the > region. If the petition for a code assignment by ISO 3166-1 is > refused or not acted on in a timely manner, the registration > process described in Section 3.5 MAY then be used to register > the corresponding UN M.49 code. This way, UN M.49 codes remain > available as the value of last resort in cases where ISO 3166-1 > reassigns a deprecated value in the registry. > -- > > I believe the AD has a point here. Note that Rule F in 2.2.4 is not complete unto itself. The rules in that section for UN M.49 codes are (basically): > > - continents and subregions: registered > - economic and 'other' groupings: excluded > - codes associated with codes recycled by ISO 3166: registered > - codes otherwise associated with ISO 3166 codes: excluded > - code 830: permitted to be (but not currently) registered > - any other codes: excluded > > The rule #16 in section 3.4 is a restatement of one of the above rules (specifically, the fourth one). I recall that we added the text in rule #16 during this document's gestation. > > Proposed resolution: > > I propose that we change the text in section 2.2.4 to read: > > Other UN numeric codes for countries or areas that do not have an associated ISO 3166-1 alpha-2 code MAY be entered into the registry via the process described in , subject to the restrictions in , item #16. ... I disagree with the proposed resolution. A problem in the proposal is that the "SHOULD NOT" in 3.4 (16) would remain, and this "SHOULD NOT" is not what we intended, as I recall. We intended "MUST NOT ... except". The difference is important. A "SHOULD NOT" leaves it open to the deployer / implementer to come up with excuses for doing something. We intended that there should only be one possible excuse for doing it. Sooo.... I think it is sufficient to replace the "SHOULD NOT" in 3.4 (16) with "MUST NOT". This would address the AD's concern, and would be entirely in keeping with the intent of the passage. Randy From addison@amazon.com Thu Apr 30 09:55:14 2009 Return-Path: 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 E98003A7244 for ; Thu, 30 Apr 2009 09:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 u51JghJPD5Rl for ; Thu, 30 Apr 2009 09:55:14 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id EA6DF3A720B for ; Thu, 30 Apr 2009 09:55:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208";a="216345674" Received: from smtp-in-4104.sea5.amazon.com ([10.248.183.18]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 16:56:37 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-4104.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3UGuaAN014384 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 16:56:37 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Thu, 30 Apr 2009 09:56:36 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 09:56:35 -0700 Thread-Topic: [Ltru] Ticket #36: AD Issue #3: rules for UN M.49 codes Thread-Index: AcnJs6G2u+AKBEhjTkGLOUb6PvATXQAAEOHQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34258@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5A6@EX-SEA5-D.ant.amazon.com> <004e01c9c9b4$01734e80$6801a8c0@oemcomputer> In-Reply-To: <004e01c9c9b4$01734e80$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #36: AD Issue #3: rules for UN M.49 codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:55:15 -0000 SGksDQoNCihpbmRpdmlkdWFsbHkpDQoNClRoaXMgbWFrZXMgc2Vuc2UgdG8gbWUuDQoNCihhcyBl ZGl0b3IpDQoNCkkgaGF2ZSByZXZlcnRlZCB0aGUgdGV4dCBpbiAyLjIuNCBhbmQgY2hhbmdlZCBT SE9VTEQgTk9UIHRvIE1VU1QgTk9UIGluIHNlY3Rpb24gMy40Lg0KDQpBZGRpc29uDQoNCkFkZGlz b24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJbnRlcm5h dGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgUmFu ZHkgUHJlc3Vobg0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMDkgOTo1MiBBTQ0KPiBU bzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gVGlja2V0ICMzNjog QUQgSXNzdWUgIzM6IHJ1bGVzIGZvciBVTiBNLjQ5DQo+IGNvZGVzDQo+IA0KPiBIaSAtDQo+IA0K PiBBcyBhIHRlY2huaWNhbCBjb250cmlidXRvci4uLg0KPiANCj4gPiBGcm9tOiAiUGhpbGxpcHMs IEFkZGlzb24iIDxhZGRpc29uQGFtYXpvbi5jb20+DQo+ID4gVG86ICJMVFJVIFdvcmtpbmcgR3Jv dXAiIDxsdHJ1QGlldGYub3JnPg0KPiA+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI4LCAyMDA5IDk6 MzggUE0NCj4gPiBTdWJqZWN0OiBbTHRydV0gVGlja2V0ICMzNjogQUQgSXNzdWUgIzM6IHJ1bGVz IGZvciBVTiBNLjQ5IGNvZGVzDQo+ID4NCj4gDQo+ID4gVGhlIEFEIHN1Z2dlc3RlZDoNCj4gPg0K PiA+IC0tDQo+ID4gSXNzdWUgIzMgZnJvbSBBRCByZXZpZXcgLSBmb3IgZGV0YWlscyBzZWUNCj4g PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbHRydS9jdXJyZW50L21zZzEy Mzk5Lmh0bWwNCj4gPg0KPiA+IDMpLiBTZWN0aW9uIDIuMi40IHNheXM6DQo+ID4NCj4gPiAgICAg Ri4gQWxsIG90aGVyIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBvciBhcmVhcyB0aGF0 IGRvDQo+IG5vdA0KPiA+ICAgICBoYXZlIGFuIGFzc29jaWF0ZWQgSVNPIDMxNjYtMSBhbHBoYS0y IGNvZGUgTVVTVCBOT1QgYmUNCj4gPiAgICAgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSBhbmQg TVVTVCBOT1QgYmUgdXNlZCB0byBmb3JtDQo+ID4gICAgIGxhbmd1YWdlIHRhZ3MuIEZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IHRoZXNlIGNvZGVzLCBzZWUNCj4gPiAgICAgU2VjdGlvbiAzLjQu DQo+ID4NCj4gPiBBbmQgU2VjdGlvbiAzLjQgc2F5czoNCj4gPg0KPiA+ICAgICAxNi4gVU4gTS40 OSBoYXMgY29kZXMgZm9yIGJvdGggY291bnRyaWVzIGFuZCBhcmVhcyAoc3VjaCBhcw0KPiAnMjc2 Jw0KPiA+ICAgICBmb3IgR2VybWFueSkgYW5kIGdlb2dyYXBoaWNhbCByZWdpb25zIGFuZCBzdWIt cmVnaW9ucyAoc3VjaA0KPiBhcw0KPiA+ICAgICAnMTUwJyBmb3IgRXVyb3BlKS4gVU4gTS40OSBj b3VudHJ5IG9yIGFyZWEgY29kZXMgZm9yIHdoaWNoDQo+ID4gICAgIHRoZXJlIGlzIG5vIGNvcnJl c3BvbmRpbmcgSVNPIDMxNjYtMSBjb2RlIFNIT1VMRCBOT1QgYmUNCj4gPg0KPiA+IFVubGVzcyBJ IGFtIGNvbmZ1c2VkLCBJIHRoaW5rIHRoaXMgU0hPVUxEIE5PVCBjb250cmFkaWN0cyBNVVNUDQo+ IE5PVCBpbg0KPiA+IHNlY3Rpb24gMi4yLjQuDQo+ID4gSSB0aGluayB5b3UgbmVlZCB0byBjaGFu Z2Ugb25lIG9mIDIgc2VjdGlvbnMuDQo+ID4NCj4gPiAgICAgcmVnaXN0ZXJlZCwgZXhjZXB0IGFz IGEgc3Vycm9nYXRlIGZvciBhbiBJU08gMzE2Ni0xIGNvZGUgdGhhdA0KPiBpcw0KPiA+ICAgICBi bG9ja2VkIGZyb20gcmVnaXN0cmF0aW9uIGJ5IGFuIGV4aXN0aW5nIHN1YnRhZy4gSWYgc3VjaCBh DQo+IGNvZGUNCj4gPiAgICAgYmVjb21lcyBuZWNlc3NhcnksIHRoZW4gdGhlIHJlZ2lzdHJhdGlv biBhdXRob3JpdHkgZm9yIElTTw0KPiA+ICAgICAzMTY2LTEgU0hPVUxEIGZpcnN0IGJlIHBldGl0 aW9uZWQgdG8gYXNzaWduIGEgY29kZSB0byB0aGUNCj4gPiAgICAgcmVnaW9uLiBJZiB0aGUgcGV0 aXRpb24gZm9yIGEgY29kZSBhc3NpZ25tZW50IGJ5IElTTyAzMTY2LTENCj4gaXMNCj4gPiAgICAg cmVmdXNlZCBvciBub3QgYWN0ZWQgb24gaW4gYSB0aW1lbHkgbWFubmVyLCB0aGUgcmVnaXN0cmF0 aW9uDQo+ID4gICAgIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41IE1BWSB0aGVuIGJl IHVzZWQgdG8gcmVnaXN0ZXINCj4gPiAgICAgdGhlIGNvcnJlc3BvbmRpbmcgVU4gTS40OSBjb2Rl LiBUaGlzIHdheSwgVU4gTS40OSBjb2Rlcw0KPiByZW1haW4NCj4gPiAgICAgYXZhaWxhYmxlIGFz IHRoZSB2YWx1ZSBvZiBsYXN0IHJlc29ydCBpbiBjYXNlcyB3aGVyZSBJU08NCj4gMzE2Ni0xDQo+ ID4gICAgIHJlYXNzaWducyBhIGRlcHJlY2F0ZWQgdmFsdWUgaW4gdGhlIHJlZ2lzdHJ5Lg0KPiA+ IC0tDQo+ID4NCj4gPiBJIGJlbGlldmUgdGhlIEFEIGhhcyBhIHBvaW50IGhlcmUuIE5vdGUgdGhh dCBSdWxlIEYgaW4gMi4yLjQgaXMNCj4gbm90IGNvbXBsZXRlIHVudG8gaXRzZWxmLiBUaGUgcnVs ZXMgaW4gdGhhdCBzZWN0aW9uIGZvciBVTiBNLjQ5DQo+IGNvZGVzIGFyZSAoYmFzaWNhbGx5KToN Cj4gPg0KPiA+IC0gY29udGluZW50cyBhbmQgc3VicmVnaW9uczogcmVnaXN0ZXJlZA0KPiA+IC0g ZWNvbm9taWMgYW5kICdvdGhlcicgZ3JvdXBpbmdzOiBleGNsdWRlZA0KPiA+IC0gY29kZXMgYXNz b2NpYXRlZCB3aXRoIGNvZGVzIHJlY3ljbGVkIGJ5IElTTyAzMTY2OiByZWdpc3RlcmVkDQo+ID4g LSBjb2RlcyBvdGhlcndpc2UgYXNzb2NpYXRlZCB3aXRoIElTTyAzMTY2IGNvZGVzOiBleGNsdWRl ZA0KPiA+IC0gY29kZSA4MzA6IHBlcm1pdHRlZCB0byBiZSAoYnV0IG5vdCBjdXJyZW50bHkpIHJl Z2lzdGVyZWQNCj4gPiAtIGFueSBvdGhlciBjb2RlczogZXhjbHVkZWQNCj4gPg0KPiA+IFRoZSBy dWxlICMxNiBpbiBzZWN0aW9uIDMuNCBpcyBhIHJlc3RhdGVtZW50IG9mIG9uZSBvZiB0aGUgYWJv dmUNCj4gcnVsZXMgKHNwZWNpZmljYWxseSwgdGhlIGZvdXJ0aCBvbmUpLiBJIHJlY2FsbCB0aGF0 IHdlIGFkZGVkIHRoZQ0KPiB0ZXh0IGluIHJ1bGUgIzE2IGR1cmluZyB0aGlzIGRvY3VtZW50J3Mg Z2VzdGF0aW9uLg0KPiA+DQo+ID4gUHJvcG9zZWQgcmVzb2x1dGlvbjoNCj4gPg0KPiA+IEkgcHJv cG9zZSB0aGF0IHdlIGNoYW5nZSB0aGUgdGV4dCBpbiBzZWN0aW9uIDIuMi40IHRvIHJlYWQ6DQo+ ID4NCj4gPiA8dD5PdGhlciBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMg dGhhdCBkbyBub3QgaGF2ZQ0KPiBhbiBhc3NvY2lhdGVkIElTTyAzMTY2LTEgYWxwaGEtMiBjb2Rl IE1BWSBiZSBlbnRlcmVkIGludG8gdGhlDQo+IHJlZ2lzdHJ5IHZpYSB0aGUgcHJvY2VzcyBkZXNj cmliZWQgaW4gPHhyZWYNCj4gdGFyZ2V0PSJyZWdpc3RyYXRpb25Qcm9jIj48L3hyZWY+LCBzdWJq ZWN0IHRvIHRoZSByZXN0cmljdGlvbnMgaW4NCj4gPHhyZWYNCj4gdGFyZ2V0PSJpYW5hc3RhYmls aXR5Ij48L3hyZWY+LCBpdGVtICMxNi48L3Q+DQo+IC4uLg0KPiANCj4gSSBkaXNhZ3JlZSB3aXRo IHRoZSBwcm9wb3NlZCByZXNvbHV0aW9uLiAgQSBwcm9ibGVtIGluIHRoZSBwcm9wb3NhbA0KPiBp cyB0aGF0IHRoZSAiU0hPVUxEIE5PVCIgaW4gMy40ICgxNikgd291bGQgcmVtYWluLCBhbmQgdGhp cyAiU0hPVUxEDQo+IE5PVCIgaXMgbm90IHdoYXQgd2UgaW50ZW5kZWQsIGFzIEkgcmVjYWxsLiAg V2UgaW50ZW5kZWQgIk1VU1QNCj4gTk9UIC4uLiBleGNlcHQiLg0KPiBUaGUgZGlmZmVyZW5jZSBp cyBpbXBvcnRhbnQuICBBICJTSE9VTEQgTk9UIiBsZWF2ZXMgaXQgb3BlbiB0byB0aGUNCj4gZGVw bG95ZXIgLyBpbXBsZW1lbnRlciB0byBjb21lIHVwIHdpdGggZXhjdXNlcyBmb3IgZG9pbmcgc29t ZXRoaW5nLg0KPiBXZSBpbnRlbmRlZCB0aGF0IHRoZXJlIHNob3VsZCBvbmx5IGJlIG9uZSBwb3Nz aWJsZSBleGN1c2UgZm9yIGRvaW5nDQo+IGl0Lg0KPiANCj4gU29vby4uLi4NCj4gDQo+IEkgdGhp bmsgaXQgaXMgc3VmZmljaWVudCB0byByZXBsYWNlIHRoZSAiU0hPVUxEIE5PVCIgaW4gMy40ICgx NikNCj4gd2l0aA0KPiAiTVVTVCBOT1QiLiAgVGhpcyB3b3VsZCBhZGRyZXNzIHRoZSBBRCdzIGNv bmNlcm4sIGFuZCB3b3VsZCBiZQ0KPiBlbnRpcmVseSBpbiBrZWVwaW5nIHdpdGggdGhlIGludGVu dCBvZiB0aGUgcGFzc2FnZS4NCj4gDQo+IFJhbmR5DQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4g THRydUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0 cnUNCg== From randy_presuhn@mindspring.com Thu Apr 30 10:34:02 2009 Return-Path: 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 68FDB3A6E4D for ; Thu, 30 Apr 2009 10:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 c-+HeMdjBm6g for ; Thu, 30 Apr 2009 10:34:01 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id D64BA28C33A for ; Thu, 30 Apr 2009 10:32:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LeTo42+HEFjkP+tcJf0CfqenzCYWbVOnv0WqCmuOnMgVNjRTlcod7NoNFUuu756f; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lza9M-0006HD-NW for ltru@ietf.org; Thu, 30 Apr 2009 13:34:20 -0400 Message-ID: <006601c9c9ba$48c2dd40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5AA@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 10:35:26 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69683cfa085fa488c65a4b18a41518df302d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #37: AD Issue #4: delete last sentence in Section2.2.9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 17:34:02 -0000 Hi - As co-chair... > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Tuesday, April 28, 2009 9:42 PM > Subject: [Ltru] Ticket #37: AD Issue #4: delete last sentence in Section2.2.9 > The AD points out: > > -- > AD review issue #4 - for details see > http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html > > 4). In Section 2.2.9: > > Note well: although the 'Language-Tag' production appearing in this > document is functionally equivalent to the one in [RFC4646], it has > been changed to prevent certain errors in well-formedness arising > from the old 'grandfathered' production. This version of the ABNF is > RECOMMENDED as a replacement for the older version. > > (nit) I suggest deleting the last sentence, as it doesn't provide any > useful information to a reader (as the WG wants > draft-ietf-ltru-4646bis-21bis.txt to replace RFC 4646, it is clear that > the WG believes that the new ABNF is better). Also I don't think it uses > RFC 2119 keyword properly. > -- > > I think this is not necessary. We have had, as a user community, > a long-standing problem with stale references to BCP 47. We want > to help ensure that implementers and standardizers use the right ABNF. > It is well-known that many implementers rely excessively or even > exclusively on the ABNF to determine "what is right". Therefore, > it is useful to have some documentation explaining why this ABNF is better. > > Proposed resolution: no change ... Here's where we're at: The sentence in question reads: "This version of the ABNF is RECOMMENDED as a replacement for the older version." Mark Davis, AD Alexey Melnikov, and technical contributor Randy Presuhn have all written (April 11) in favor of deleting the sentence, on the grounds that it is an inappropriate use of the RFC 2119 keyword. Addision Phillips writes in favor of retaining the sentence, on the grounds that "it is useful to have some documentation explaining why this ABNF is better". It looks to me like there is a rough consensus in favor of deletion. If someone can offer a replacement that does not abuse RFC 2119 keywords and actually does explain why this ABNF is better, I think we could consider it, but I think the existing sentence fails to live up to Addison's rationale for retaining it. Randy From addison@amazon.com Thu Apr 30 10:38:30 2009 Return-Path: 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 C522B3A6829 for ; Thu, 30 Apr 2009 10:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 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 JuwIIcxC1idc for ; Thu, 30 Apr 2009 10:38:30 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id D72953A68AF for ; Thu, 30 Apr 2009 10:38:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,274,1238976000"; d="scan'208";a="216362050" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 17:39:50 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n3UHdnpf004169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 17:39:49 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Thu, 30 Apr 2009 10:39:49 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 10:39:46 -0700 Thread-Topic: [Ltru] Ticket #37: AD Issue #4: delete last sentence in Section2.2.9 Thread-Index: AcnJuhpxf2FOVr1ISEOkutv9a7EjZgAAC4UQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE3434E@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5AA@EX-SEA5-D.ant.amazon.com> <006601c9c9ba$48c2dd40$6801a8c0@oemcomputer> In-Reply-To: <006601c9c9ba$48c2dd40$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #37: AD Issue #4: delete last sentence in Section2.2.9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 17:38:30 -0000 KGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IpDQoNClBlcmhhcHM6DQoNCi0tDQpTcGVjaWZpY2F0 aW9ucyBTSE9VTEQgcmVwbGFjZSByZWZlcmVuY2VzIHRvIG9yIGNvcGllcyBvZiB0aGUgQUJORiBm cm9tIHByZXZpb3VzIHZlcnNpb25zIG9mIEJDUCA0NyB3aXRoIHRoaXMgdmVyc2lvbi4NCi0tDQoN CihhcyBlZGl0b3IpDQoNCkkgaGF2ZSBkZWxldGVkIHRoaXMgc2VudGVuY2UgZnJvbSB0aGUgZWRp dG9yJ3MgY29weSwgYmFzZWQgb24gdGhlIGN1cnJlbnQgY2hhaXIgY29uc2Vuc3VzLg0KDQpBZGRp c29uDQoNCkFkZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEy Ng0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJj aGl0ZWN0dXJlLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVo YWxmIE9mIFJhbmR5IFByZXN1aG4NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDEw OjM1IEFNDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBU aWNrZXQgIzM3OiBBRCBJc3N1ZSAjNDogZGVsZXRlIGxhc3Qgc2VudGVuY2UNCj4gaW4gU2VjdGlv bjIuMi45DQo+IA0KPiBIaSAtDQo+IA0KPiBBcyBjby1jaGFpci4uLg0KPiANCj4gPiBGcm9tOiAi UGhpbGxpcHMsIEFkZGlzb24iIDxhZGRpc29uQGFtYXpvbi5jb20+DQo+ID4gVG86ICJMVFJVIFdv cmtpbmcgR3JvdXAiIDxsdHJ1QGlldGYub3JnPg0KPiA+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI4 LCAyMDA5IDk6NDIgUE0NCj4gPiBTdWJqZWN0OiBbTHRydV0gVGlja2V0ICMzNzogQUQgSXNzdWUg IzQ6IGRlbGV0ZSBsYXN0IHNlbnRlbmNlIGluDQo+IFNlY3Rpb24yLjIuOQ0KPiANCj4gDQo+ID4g VGhlIEFEIHBvaW50cyBvdXQ6DQo+ID4NCj4gPiAtLQ0KPiA+IEFEIHJldmlldyBpc3N1ZSAjNCAt IGZvciBkZXRhaWxzIHNlZQ0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9sdHJ1L2N1cnJlbnQvbXNnMTIzOTkuaHRtbA0KPiA+DQo+ID4gNCkuIEluIFNlY3Rpb24gMi4y Ljk6DQo+ID4NCj4gPiAgICAgTm90ZSB3ZWxsOiBhbHRob3VnaCB0aGUgJ0xhbmd1YWdlLVRhZycg cHJvZHVjdGlvbiBhcHBlYXJpbmcNCj4gaW4gdGhpcw0KPiA+ICAgICBkb2N1bWVudCBpcyBmdW5j dGlvbmFsbHkgZXF1aXZhbGVudCB0byB0aGUgb25lIGluIFtSRkM0NjQ2XSwNCj4gaXQgaGFzDQo+ ID4gICAgIGJlZW4gY2hhbmdlZCB0byBwcmV2ZW50IGNlcnRhaW4gZXJyb3JzIGluIHdlbGwtZm9y bWVkbmVzcw0KPiBhcmlzaW5nDQo+ID4gICAgIGZyb20gdGhlIG9sZCAnZ3JhbmRmYXRoZXJlZCcg cHJvZHVjdGlvbi4gVGhpcyB2ZXJzaW9uIG9mIHRoZQ0KPiBBQk5GIGlzDQo+ID4gICAgIFJFQ09N TUVOREVEIGFzIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBvbGRlciB2ZXJzaW9uLg0KPiA+DQo+ID4g KG5pdCkgSSBzdWdnZXN0IGRlbGV0aW5nIHRoZSBsYXN0IHNlbnRlbmNlLCBhcyBpdCBkb2Vzbid0 IHByb3ZpZGUNCj4gYW55DQo+ID4gdXNlZnVsIGluZm9ybWF0aW9uIHRvIGEgcmVhZGVyIChhcyB0 aGUgV0cgd2FudHMNCj4gPiBkcmFmdC1pZXRmLWx0cnUtNDY0NmJpcy0yMWJpcy50eHQgdG8gcmVw bGFjZSBSRkMgNDY0NiwgaXQgaXMNCj4gY2xlYXIgdGhhdA0KPiA+IHRoZSBXRyBiZWxpZXZlcyB0 aGF0IHRoZSBuZXcgQUJORiBpcyBiZXR0ZXIpLiBBbHNvIEkgZG9uJ3QgdGhpbmsNCj4gaXQgdXNl cw0KPiA+IFJGQyAyMTE5IGtleXdvcmQgcHJvcGVybHkuDQo+ID4gLS0NCj4gPg0KPiA+IEkgdGhp bmsgdGhpcyBpcyBub3QgbmVjZXNzYXJ5LiBXZSBoYXZlIGhhZCwgYXMgYSB1c2VyIGNvbW11bml0 eSwNCj4gPiBhIGxvbmctc3RhbmRpbmcgcHJvYmxlbSB3aXRoIHN0YWxlIHJlZmVyZW5jZXMgdG8g QkNQIDQ3LiBXZSB3YW50DQo+ID4gdG8gaGVscCBlbnN1cmUgdGhhdCBpbXBsZW1lbnRlcnMgYW5k IHN0YW5kYXJkaXplcnMgdXNlIHRoZSByaWdodA0KPiBBQk5GLg0KPiA+IEl0IGlzIHdlbGwta25v d24gdGhhdCBtYW55IGltcGxlbWVudGVycyByZWx5IGV4Y2Vzc2l2ZWx5IG9yIGV2ZW4NCj4gPiBl eGNsdXNpdmVseSBvbiB0aGUgQUJORiB0byBkZXRlcm1pbmUgIndoYXQgaXMgcmlnaHQiLiBUaGVy ZWZvcmUsDQo+ID4gaXQgaXMgdXNlZnVsIHRvIGhhdmUgc29tZSBkb2N1bWVudGF0aW9uIGV4cGxh aW5pbmcgd2h5IHRoaXMgQUJORg0KPiBpcyBiZXR0ZXIuDQo+ID4NCj4gPiBQcm9wb3NlZCByZXNv bHV0aW9uOiBubyBjaGFuZ2UNCj4gLi4uDQo+IA0KPiBIZXJlJ3Mgd2hlcmUgd2UncmUgYXQ6DQo+ IA0KPiBUaGUgc2VudGVuY2UgaW4gcXVlc3Rpb24gcmVhZHM6DQo+ICJUaGlzIHZlcnNpb24gb2Yg dGhlIEFCTkYgaXMgUkVDT01NRU5ERUQgYXMgYSByZXBsYWNlbWVudCBmb3IgdGhlDQo+IG9sZGVy IHZlcnNpb24uIg0KPiANCj4gTWFyayBEYXZpcywgQUQgQWxleGV5IE1lbG5pa292LCBhbmQgdGVj aG5pY2FsIGNvbnRyaWJ1dG9yIFJhbmR5DQo+IFByZXN1aG4NCj4gaGF2ZSBhbGwgd3JpdHRlbiAo QXByaWwgMTEpIGluIGZhdm9yIG9mIGRlbGV0aW5nIHRoZSBzZW50ZW5jZSwgb24NCj4gdGhlIGdy b3VuZHMgdGhhdCBpdCBpcw0KPiBhbiBpbmFwcHJvcHJpYXRlIHVzZSBvZiB0aGUgUkZDIDIxMTkg a2V5d29yZC4gIEFkZGlzaW9uIFBoaWxsaXBzDQo+IHdyaXRlcyBpbg0KPiBmYXZvciBvZiByZXRh aW5pbmcgdGhlIHNlbnRlbmNlLCBvbiB0aGUgZ3JvdW5kcyB0aGF0ICJpdCBpcyB1c2VmdWwNCj4g dG8gaGF2ZSBzb21lDQo+IGRvY3VtZW50YXRpb24gZXhwbGFpbmluZyB3aHkgdGhpcyBBQk5GIGlz IGJldHRlciIuDQo+IA0KPiBJdCBsb29rcyB0byBtZSBsaWtlIHRoZXJlIGlzIGEgcm91Z2ggY29u c2Vuc3VzIGluIGZhdm9yIG9mIGRlbGV0aW9uLg0KPiBJZiBzb21lb25lDQo+IGNhbiBvZmZlciBh IHJlcGxhY2VtZW50IHRoYXQgZG9lcyBub3QgYWJ1c2UgUkZDIDIxMTkga2V5d29yZHMgYW5kDQo+ IGFjdHVhbGx5DQo+IGRvZXMgZXhwbGFpbiB3aHkgdGhpcyBBQk5GIGlzIGJldHRlciwgSSB0aGlu ayB3ZSBjb3VsZCBjb25zaWRlciBpdCwNCj4gYnV0IEkgdGhpbmsgdGhlDQo+IGV4aXN0aW5nIHNl bnRlbmNlIGZhaWxzIHRvIGxpdmUgdXAgdG8gQWRkaXNvbidzIHJhdGlvbmFsZSBmb3INCj4gcmV0 YWluaW5nIGl0Lg0KPiANCj4gUmFuZHkNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= From randy_presuhn@mindspring.com Thu Apr 30 11:44:59 2009 Return-Path: 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 EF9833A6FD1 for ; Thu, 30 Apr 2009 11:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 fsU+JL4HcsQh for ; Thu, 30 Apr 2009 11:44:58 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 22A833A6B66 for ; Thu, 30 Apr 2009 11:44:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hHG5100/3DxVEojuu4rfZAANQgMNw5X9L7pMEg7KTSMciLLgvKyhLXv6PaTLg9O8; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzbH2-0005Zw-GG for ltru@ietf.org; Thu, 30 Apr 2009 14:46:20 -0400 Message-ID: <002001c9c9c4$57d01f00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5AA@EX-SEA5-D.ant.amazon.com> <006601c9c9ba$48c2dd40$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FE3434E@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 11:49:07 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968dfccf2ab9bf5d345e6a0a870b16f3264350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #37: AD Issue #4: delete last sentence inSection2.2.9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 18:44:59 -0000 Hi - As co-chair: > From: "Phillips, Addison" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Thursday, April 30, 2009 10:39 AM > Subject: RE: [Ltru] Ticket #37: AD Issue #4: delete last sentence inSection2.2.9 > > (as individual contributor) > > Perhaps: > > -- > Specifications SHOULD replace references to or copies of the ABNF > from previous versions of BCP 47 with this version. > -- This has the same problem with respect to RFC 2119 keywords as the sentence it would replace. > > (as editor) > > I have deleted this sentence from the editor's copy, based on the current chair consensus. Ok. I've recorded the resolution and marked the issue closed - http://trac.tools.ietf.org/wg/ltru/trac/ticket/37 Randy From mark.edward.davis@gmail.com Thu Apr 30 11:50:13 2009 Return-Path: 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 B596F3A6D6F for ; Thu, 30 Apr 2009 11:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 9ylnKWJtRRFD for ; Thu, 30 Apr 2009 11:50:12 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id C03973A6E34 for ; Thu, 30 Apr 2009 11:50:12 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1578706wff.31 for ; Thu, 30 Apr 2009 11:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=5LEDeaC2b8M9TIY6QfgDu1S9z0A4sGhPUCc6cn/bCqI=; b=WVa+RNAnA1Ogi+jqy9XQmjK9Dq8H5fJZhwFM+vYq3zeKSqmHgaNfU7ckhcv0VNwCOZ EZ/b04U4CCKLHP0StmwNJ5Cm25XqfI6uUOyKfpnaEBkSWhulyQ4INHKOkrJGiy7Sqn0u 9DLqg1tJRw/bHuI4DXef/auUAgm5J93wmc3Kg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QUgXTh1aL4TlkEsGkz4z1dLJh7kaPueTyJdoCM8P6ni8MMkdFJSqbHSOuhc/pqoDCD BJC+t5JTxJkUxs41d9NVC+jCtirswmmd/ZTE1nMzjplRhk8OGlaKTiAyaaJHXv2YkVXo jfvB7u7HyZZ/aTQgK+CZFPOjNWX8e8//9Ga7w= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.158.2 with SMTP id k2mr540004wfo.245.1241117495974; Thu, 30 Apr 2009 11:51:35 -0700 (PDT) In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FE3414C@EX-SEA5-D.ant.amazon.com> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> <20090430153237.GF15356@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019FE3414C@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 11:51:35 -0700 X-Google-Sender-Auth: c9c7eb89dd997d8a Message-ID: <30b660a20904301151h51174b2dk9516fa71032cbe25@mail.gmail.com> From: Mark Davis To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=001636e1fd8278dcb70468ca2f9c Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 18:50:13 -0000 --001636e1fd8278dcb70468ca2f9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Default is fine; that preserves the sense of the SHOULD. I had a couple of other comments on the proposed text, will send separately. Mark On Thu, Apr 30, 2009 at 09:13, Phillips, Addison wrote: > (as individual contributor) > > > > > 3. In the 'default' canonical form, subtags of type 'extlang' > > MUST > > > 4. In the 'extended' canonical form, primary language subtags > > with a > > > > I propose the names "short" and "long" respectively. > > 'extended' seems like a more natural name for the latter form. I > acknowledge that the name 'default' is prejudicial, in its way, but it was > the previous intent of 'SHOULD' and it is the canonical form that the > registry is optimized for. If we don't want to say that it's the default, we > could pick a name that is partial antonym for 'extended', such as 'compact', > 'regular', or (hmm...) 'short'. How about 'short' and 'extended'? > > If we don't say 'default' (or even if we do), oughtn't we to have some text > explaining when to use which? > > Addison > > > Any day you get all five woodpeckers is a good day. --Elliotte > > Rusty Harold > > All five woodpeckers?!? > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e1fd8278dcb70468ca2f9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Default is fine; that preserves the sense of the SHOULD. I had a couple of = other comments on the proposed text, will send separately.

Mark


On Thu, Apr 30, 2009 at 09:13, Phillips,= Addison <addiso= n@amazon.com> wrote:
(as individual contributor)
>
> > =C2=A0 =C2=A03. =C2=A0In the 'default' canonical form, su= btags of type 'extlang'
> MUST
> > =C2=A0 =C2=A04. =C2=A0In the 'extended' canonical form, p= rimary language subtags
> with a
>
> I propose the names "short" and "long" respectivel= y.

'extended' seems like a more natural name for the latter form= . I acknowledge that the name 'default' is prejudicial, in its way,= but it was the previous intent of 'SHOULD' and it is the canonical= form that the registry is optimized for. If we don't want to say that = it's the default, we could pick a name that is partial antonym for '= ;extended', such as 'compact', 'regular', or (hmm...) &= #39;short'. How about 'short' and 'extended'?

If we don't say 'default' (or even if we do), oughtn't we t= o have some text explaining when to use which?

Addison

> Any day you get all five woodpeckers is a good day. =C2=A0--Elliotte > Rusty Harold

All five woodpeckers?!?
_________________________________________= ______
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e1fd8278dcb70468ca2f9c-- From mark.edward.davis@gmail.com Thu Apr 30 11:59:14 2009 Return-Path: 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 B0D663A6ABE for ; Thu, 30 Apr 2009 11:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 ABA+sXNGfSu7 for ; Thu, 30 Apr 2009 11:59:13 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 782353A6AA1 for ; Thu, 30 Apr 2009 11:59:13 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1582212wff.31 for ; Thu, 30 Apr 2009 12:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=jf9VPr7tXpZYs34Iq3QxC/+rV1BBelh9JTNiGOKNRKg=; b=lh6SVx2kcVxfbVuZqvGI72fBmfisJimTYiDV2+GK1zFpyqXQUKR38bkYiuWHa+7q9c gJy64t0TT4OpL/iMZRKjgFknX1vg+zR4IGU8sFS94IScTIqc7kKwJ1GijcZpCWtRxw0t 4t2KJvnkWJbdxoSzOCXO+cx3hDFOclT1s9vWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=tonn1d0h6bA/Lmo7/l2aPE5Sys04jHsq8/nHn1wFkzsUVKEJX98F/geYIwbc7Rgvc6 ZhBju0/Rh7binKEpaTG3BeW9tQJhZMnPP0Rv/U/BczGOWkbbsWwMwUMvUjY1g9Vq6mVg 9scQSBnttxi2ck18kRHSPljHjEile/+sdczdc= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.15.14 with SMTP id s14mr544611wfi.313.1241118036598; Thu, 30 Apr 2009 12:00:36 -0700 (PDT) In-Reply-To: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> Date: Thu, 30 Apr 2009 12:00:36 -0700 X-Google-Sender-Auth: 7a2abf2c72278789 Message-ID: <30b660a20904301200l25ad1950y64a5113d22875480@mail.gmail.com> From: Mark Davis To: Doug Ewell Content-Type: multipart/alternative; boundary=001636e1fbd1b221870468ca4f6c Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 18:59:14 -0000 --001636e1fbd1b221870468ca4f6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The changes are not an attempt to sway one way or another; it is to have comprehensible text. When you define what a term is, you can't say SHOULD. It is when you talk about the *usage* of that defined term that you can say SHOULD or MUST. The very nature of a canonicalization is that once you are done, the result= s erase differences where two forms are equivalent. If there is only a SHOULD= , then that doesn't work. We all agree that "cmn" and "zh-cmn" represent the same underlying entity, so any canonicalization has to go one way or the other. We can't have implemenation A canonicalize to and implemenation B canonicalize to , and implementation C canonicalize to . Yet having th= e SHOULD allows all of these. The SHOULD is in the wrong place. We need to have two form of canonicalization, and have the SHOULD be on * which* form you should use. I went part way in that direction, and Addison'= s extentions are go further. Mark ---------- Forwarded message ---------- From: Doug Ewell Date: Wed, Apr 29, 2009 at 20:32 Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping To: LTRU Working Group Mark Davis wrote: The changes are marked in yellow. > Not useful when reading the plain-text digest. A language tag is in canonical form when: > ... > 2. It has been canonicalized according to the following process: > ... > 2. Subtags of type 'extlang' MUST be mapped to their Preferred-Value. > As Addison pointed out, the existing wording with SHOULD was a compromise. The battle between extlang and no-extlang camps was lengthy and painful, and this was the wording the WG finally agreed upon. I object to using the IETF Last Call process to undo this compromise and swing the wording back i= n favor of the no-extlang side. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru --001636e1fbd1b221870468ca4f6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The changes are not an attempt to sway one way or another; it is to have co= mprehensible text.

When you define what a term is, you can't say= SHOULD. It is when you talk about the usage of that defined term th= at you can say SHOULD or MUST.

The very nature of a canonicalization is that once you are done, the re= sults erase differences where two forms are equivalent. If there is only a = SHOULD, then that doesn't work. We all agree that "cmn" and &= quot;zh-cmn" represent the same underlying entity, so any canonicaliza= tion has to go one way or the other. We can't have implemenation A cano= nicalize <ar-arb, zh-cmn, yue> to <arb, zh-cmn, yue> and implem= enation B canonicalize to <ar-arb, zh-cmn, yue>, and implementation C= canonicalize to <arb, zh, zh-yue>. Yet having the SHOULD allows all = of these. The SHOULD is in the wrong place.

We need to have two form of canonicalization, and have the SHOULD be on= which form you should use. I went part way in that direction, and A= ddison's extentions are go further.

Mark


---------- Forwarded message ----------<= br>From: Doug Ewell <= ;doug@ewellic.org= >
Date: Wed, Apr 29, 2009 at 20:32
Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extl= ang mapping
To: LTRU Working Group <ltru@ietf.org>


Mark Davis <mark= at macchiato dot com> wrote:

The changes are marked in yellow.

Not useful when reading the plain-text digest.

A language tag is in canonical form when:
...

2. =C2=A0It has been canonicalized according to the following process:
<= /div> ...

2. =C2=A0Subtags of type 'extlang' MUST be mapped to their Preferre= d-Value.

As Addison pointed out, the existing wording with SHOULD was a compromise. = =C2=A0The battle between extlang and no-extlang camps was lengthy and painf= ul, and this was the wording the WG finally agreed upon. =C2=A0I object to = using the IETF Last Call process to undo this compromise and swing the word= ing back in favor of the no-extlang side.

--
Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 4645 =C2= =A0* =C2=A0UTN #14
http://www.ewellic.org=
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages = =C2=A0=CB=86



_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e1fbd1b221870468ca4f6c-- From mark.edward.davis@gmail.com Thu Apr 30 12:16:40 2009 Return-Path: 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 7E0F33A67F7 for ; Thu, 30 Apr 2009 12:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 ZrFgs5KtOKlx for ; Thu, 30 Apr 2009 12:16:38 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id BAF343A6900 for ; Thu, 30 Apr 2009 12:15:48 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1588910wff.31 for ; Thu, 30 Apr 2009 12:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=VAXcSEY/p9PlLEx1H//OxRfAvBMemVQ2+aa/itx+L94=; b=W+AXtyfkSezxoe6seaRXT13pa0HJLXPvdQUGxieh4ryra6p8M445RzW7tlKM8hpKsr wWlN+1JCwcW9K6EK9zaFJyqXTRpwqtcrzqLpALNwVLqH60DWAa/nqG7qmezMqPBxxiLE LtgG7ZIV/Ej+Ex0QH43+n5TLQ5LAO4Cqogn1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=OdMFNlZzwKg+ISTBpu/CJ368ZbLBUdGulDCX1gy+YIM6ZrK65hP1RFgm5WRYBiBXzB 6o5ArVBLvV7i/5o2B9Nu/J5xuzvO8qzlrcs9Sff9ugVKVwfDesL0Cn0/wj4l6DTyY9d8 T9Vnz+okRR4weKxqOvOfgZKrp7q8VOfnOaXf4= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.101.17 with SMTP id y17mr555170wfb.69.1241119032042; Thu, 30 Apr 2009 12:17:12 -0700 (PDT) In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 12:17:12 -0700 X-Google-Sender-Auth: 37f1679e5e4e864c Message-ID: <30b660a20904301217k5c9dc539v566cbb0f2c5f3912@mail.gmail.com> From: Mark Davis To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=001636e9132d0764da0468ca8bd6 Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:16:40 -0000 --001636e9132d0764da0468ca8bd6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mark On Thu, Apr 30, 2009 at 08:20, Phillips, Addison wrote= : > Okay, I've finished generating the new draft and diffing it. Our only > remaining open item is this issue. > > Last night I proposed defining two canonical forms to resolve the muddine= ss > of "SHOULD". I now have a separate editor's copy of the draft with a > proposed edit to accomplish this. Co-chair guidance on this issue is very > much desired. > > Below is my proposed edited text for section 4.5. Suggestions and fixes a= re > welcome. In particular, I haven't said anything about when to use which > form. > > -- > 4.5. Canonicalization of Language Tags > > Since a particular language tag is sometimes used by many processes, > language tags SHOULD always be created or generated in a canonical > form. > > There are two canonical forms for language tags. The 'default' > canonical form maps each 'extlang' subtag to its Preferred-Value. > The 'extended' canonical form includes the macrolanguage primary > language subtag before eligible (extended) language subtags. I agree with these names. If we change the name of 'default' to anything else, we'd have to make an additional change to preserve the compromise SHOULD from the previous text, something like: The default canonical form SHOULD normally be used for canonicalization. The extended canonical form may be useful in environments where the presence of the macrolanguage is beneficial in matching or selection. > > A language tag is in a canonical form when: > > 1. The tag is well-formed according the rules in Section 2.1 and > Section 2.2. > This omits the significant consistency problem muddling defining a canonica= l form, and defining the process for canonicalizing. Please change the numbering/indent for 2-4 and add: 2. It has been canonicalized according to the following process: > > > 2. Redundant or grandfathered tags that have a Preferred-Value > mapping in the IANA registry (see Section 3.1) MUST be replaced > with their mapped value. These items either are deprecated > mappings created before the adoption of this document (such as > the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are > the result of later registrations or additions to this document > (for example, "zh-hakka" was deprecated in favor of the ISO 639-3 > code 'hak' when this document was adopted). These mappings > SHOULD be done before additional processing, since there can be > additional changes to subtag values. These field-body of the > Preferred-Value for grandfathered and redundant tags is an > "extended language range" ([RFC4647]) and might consist of more > than one subtag. > > 3. In the 'default' canonical form, subtags of type 'extlang' MUST > be mapped to their Preferred-Value. The field-body of the > Preferred-Value for extlangs is an "extended language range", > typically a primary language subtag (in all such cases, the > primary language subtag is removed). For example, the subtag > sequence "zh-hak" (Chinese, Hakka) would be replaced with the tag > "hak" (Hakka). > > 4. In the 'extended' canonical form, primary language subtags with a > 'Macrolanguage' field that are also registered as 'extlang' > subtags MUST be replaced by their macrolanguage-extlang > combination. For example, the language tag "hak" (Hakka) has a > Macrolanguage of 'zh' (Chinese) and an existing 'extlang' > registration. The tag would be replaced with that tag "zh-hak" > (Chinese, Hakka). > > 5. Other subtags that have a Preferred-Value field in the IANA > registry (see Section 3.1) MUST be replaced with their mapped > value. Most of these are either Region subtags where the country > name or designation has changed or clerical corrections to ISO > 639-1. > > 6. If more than one extension subtag sequence exists, the extension > sequences are ordered into case-insensitive ASCII order by > Please change "are ordered" to "MUST be ordered". This is not optional in exactly the same sense as all the other clauses are not optional. (That is, they must all be "are" or all be "MUST".) > singleton subtag (that is, the subtag sequence '-a-babble' comes > before '-b-warble'). > > Example: The language tag "en-a-aaa-b-ccc-bbb-x-xyz" is in canonical > form, while "en-b-ccc-bbb-a-aaa-X-xyz" is well-formed and potentially > valid (extensions 'a' and 'b' are not defined as of the publication > of this document) but not in canonical form (the extensions are not > in alphabetical order). > > Example: Although the tag "en-BU" (English as used in Burma) > maintains its validity, the language tag "en-BU" is not canonical > because the 'BU' subtag has a canonical mapping to 'MM' (Myanmar). > > Canonicalization of language tags does not imply anything about the > use of upper or lowercase letters when processing or comparing > subtags (and as described in Section 2.1). All comparisons MUST be > performed in a case-insensitive manner. > > When performing canonicalization of language tags, processors MAY > regularize the case of the subtags (that is, this process is > OPTIONAL), following the case used in the registry (see > Section 2.1.1). > > If more than one variant appears within a tag, processors MAY reorder > the variants to obtain better matching behavior or more consistent > presentation. Reordering of the variants SHOULD follow the > recommendations for variant ordering in Section 4.1. > > If the field 'Deprecated' appears in a registry record without an > accompanying 'Preferred-Value' field, then that tag or subtag is > deprecated without a replacement. These values are canonical when > they appear in a language tag. However, tags that include these > values SHOULD NOT be selected by users or generated by > implementations. > > An extension MUST define any relationships that exist between the > various subtags in the extension and thus MAY define an alternate > canonicalization scheme for the extension's subtags. Extensions MAY > define how the order of the extension's subtags are interpreted. For > example, an extension could define that its subtags are in canonical > order when the subtags are placed into ASCII order: that is, "en-a- > aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". Another extension might > define that the order of the subtags influences their semantic > meaning (so that "en-b-ccc-bbb-aaa" has a different value from "en-b- > aaa-bbb-ccc"). However, extension specifications SHOULD be designed > so that they are tolerant of the typical processes described in > Section 3.7. > -- > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > > Behalf Of Doug Ewell > > Sent: Wednesday, April 29, 2009 8:32 PM > > To: LTRU Working Group > > Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in > > 4.5 extlang mapping > > > > Mark Davis wrote: > > > > > The changes are marked in yellow. > > > > Not useful when reading the plain-text digest. > > > > > A language tag is in canonical form when: > > > ... > > > 2. It has been canonicalized according to the following process: > > > ... > > > 2. Subtags of type 'extlang' MUST be mapped to their Preferred- > > Value. > > > > As Addison pointed out, the existing wording with SHOULD was a > > compromise. The battle between extlang and no-extlang camps was > > lengthy > > and painful, and this was the wording the WG finally agreed upon. > > I > > object to using the IETF Last Call process to undo this compromise > > and > > swing the wording back in favor of the no-extlang side. > > > > -- > > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > > http://www.ewellic.org > > http://www1.ietf.org/html.charters/ltru-charter.html > > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e9132d0764da0468ca8bd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mark


On Thu, Apr 30, 2009 at 08:20, Phillips,= Addison <addiso= n@amazon.com> wrote:
Okay, I've finished generating the new draft and diffing it. Our only r= emaining open item is this issue.

Last night I proposed defining two canonical forms to resolve the muddiness= of "SHOULD". I now have a separate editor's copy of the draf= t with a proposed edit to accomplish this. Co-chair guidance on this issue = is very much desired.

Below is my proposed edited text for section 4.5. Suggestions and fixes are= welcome. In particular, I haven't said anything about when to use whic= h form.

--
4.5. =C2=A0Canonicalization of Language Tags

=C2=A0 Since a particular language tag is sometimes used by many pro= cesses,
=C2=A0 language tags SHOULD always be created or generated in a canonical<= br> =C2=A0 form.

=C2=A0 There are two canonical forms for language tags. =C2=A0The 'def= ault'
=C2=A0 canonical form maps each 'extlang' subtag to its Preferred-= Value.
=C2=A0 The 'extended' canonical form includes the macrolanguage pr= imary
=C2=A0 language subtag before eligible (extended) language subtags.

I agree with these names. If we change the name of 'defa= ult' to anything else, we'd have to make an additional change to pr= eserve the compromise SHOULD from the previous text, something like:

The default =
canonical form SHOULD normally be used for canonicalization. The extended c=
anonical form may be useful
in environments where the presence of the macrolanguage is beneficial in matching or selection.

<= br>
=C2=A0 A language tag is in a canonical form when:

=C2=A0 1. =C2=A0The tag is well-formed according the rules in Section 2.1 = and
=C2=A0 =C2=A0 =C2=A0 Section 2.2.

This omits th= e significant consistency problem muddling defining a canonical form, and d= efining the process for canonicalizing. Please change the numbering/indent = for 2-4 and add:

   2.  It ha=
s been canonicalized according to the following process:
=C2=A0=


=C2=A0 2. =C2=A0Redundant or grandfathered tags that have a Preferred-Valu= e
=C2=A0 =C2=A0 =C2=A0 mapping in the IANA registry (see Section 3.1) MUST b= e replaced
=C2=A0 =C2=A0 =C2=A0 with their mapped value. =C2=A0These items either are= deprecated
=C2=A0 =C2=A0 =C2=A0 mappings created before the adoption of this document= (such as
=C2=A0 =C2=A0 =C2=A0 the mapping of "no-nyn" to "nn" o= r "i-klingon" to "tlh") or are
=C2=A0 =C2=A0 =C2=A0 the result of later registrations or additions to thi= s document
=C2=A0 =C2=A0 =C2=A0 (for example, "zh-hakka" was deprecated in = favor of the ISO 639-3
=C2=A0 =C2=A0 =C2=A0 code 'hak' when this document was adopted). = =C2=A0These mappings
=C2=A0 =C2=A0 =C2=A0 SHOULD be done before additional processing, since th= ere can be
=C2=A0 =C2=A0 =C2=A0 additional changes to subtag values. =C2=A0These fiel= d-body of the
=C2=A0 =C2=A0 =C2=A0 Preferred-Value for grandfathered and redundant tags = is an
=C2=A0 =C2=A0 =C2=A0 "extended language range" ([RFC4647]) and m= ight consist of more
=C2=A0 =C2=A0 =C2=A0 than one subtag.

=C2=A0 3. =C2=A0In the 'default' canonical form, subtags of = type 'extlang' MUST
=C2=A0 =C2=A0 =C2=A0 be mapped to their Preferred-Value. =C2=A0The field-b= ody of the
=C2=A0 =C2=A0 =C2=A0 Preferred-Value for extlangs is an "extended lan= guage range",
=C2=A0 =C2=A0 =C2=A0 typically a primary language subtag (in all such case= s, the
=C2=A0 =C2=A0 =C2=A0 primary language subtag is removed). =C2=A0For exampl= e, the subtag
=C2=A0 =C2=A0 =C2=A0 sequence "zh-hak" (Chines= e, Hakka) would be replaced with the tag
=C2=A0 =C2=A0 =C2=A0 "hak" (Hakka).

=C2=A0 4. =C2=A0In the 'extended' canonical form, primary la= nguage subtags with a
=C2=A0 =C2=A0 =C2=A0 'Macrolanguage' field that are also registere= d as 'extlang'
=C2=A0 =C2=A0 =C2=A0 subtags MUST be replaced by their macrolanguage-extla= ng
=C2=A0 =C2=A0 =C2=A0 combination. =C2=A0For example, the language tag &quo= t;hak" (Hakka) has a
=C2=A0 =C2=A0 =C2=A0 Macrolanguage of 'zh' (Chinese) and an existi= ng 'extlang'
=C2=A0 =C2=A0 =C2=A0 registration. =C2=A0The tag would be replaced with th= at tag "zh-hak"
=C2=A0 =C2=A0 =C2=A0 (Chinese, Hakka).

=C2=A0 5. =C2=A0Other subtags that have a Preferred-Value field in the IAN= A
=C2=A0 =C2=A0 =C2=A0 registry (see Section 3.1) MUST be = replaced with their mapped
=C2=A0 =C2=A0 =C2=A0 value. =C2=A0Most of these are either Region subtags = where the country
=C2=A0 =C2=A0 =C2=A0 name or designation has changed or clerical correctio= ns to ISO
=C2=A0 =C2=A0 =C2=A0 639-1.

=C2=A0 6. =C2=A0If more than one extension subtag sequence exists, t= he extension=C2=A0

=C2=A0 =C2=A0 =C2=A0 sequences are ordered into case-ins= ensitive ASCII order by

Please change "are = ordered" to "MUST be ordered". This is not optional in exact= ly the same sense as all the other clauses are not optional. (That is, they= must all be "are" or all be "MUST".)


=C2=A0 =C2=A0 =C2=A0 singleton subtag (that is, the subtag sequence '-= a-babble' comes
=C2=A0 =C2=A0 =C2=A0 before '-b-warble').

=C2=A0 Example: The language tag "en-a-aaa-b-ccc-bbb-x-xyz"= ; is in canonical
=C2=A0 form, while "en-b-ccc-bbb-a-aaa-X-xyz" is well-formed and= potentially
=C2=A0 valid (extensions 'a' and 'b' are not defined as of= the publication
=C2=A0 of this document) but not in canonical form (the extensions are not=
=C2=A0 in alphabetical order).

=C2=A0 Example: Although the tag "en-BU" (English as used in Bur= ma)
=C2=A0 maintains its validity, the language tag "en-BU" is not c= anonical
=C2=A0 because the 'BU' subtag has a canonical mapping to 'MM&= #39; (Myanmar).

=C2=A0 Canonicalization of language tags does not imply anything about the=
=C2=A0 use of upper or lowercase letters when processing or comparing
=C2=A0 subtags (and as described in Section 2.1). =C2=A0All comparisons MU= ST be
=C2=A0 performed in a case-insensitive manner.

=C2=A0 When performing canonicalization of language tags, processors MAY =C2=A0 regularize the case of the subtags (that is, this process is
=C2=A0 OPTIONAL), following the case used in the registry (see
=C2=A0 Section 2.1.1).

=C2=A0 If more than one variant appears within a tag, processors MAY reord= er
=C2=A0 the variants to obtain better matching behavior or more consistent<= br> =C2=A0 presentation. =C2=A0Reordering of the variants SHOULD follow the =C2=A0 recommendations for variant ordering in Section 4.1.

=C2=A0 If the field 'Deprecated' appears in a registry record with= out an
=C2=A0 accompanying 'Preferred-Value' field, then that tag or subt= ag is
=C2=A0 deprecated without a replacement. =C2=A0These values are canonical = when
=C2=A0 they appear in a language tag. =C2=A0However, tags that include the= se
=C2=A0 values SHOULD NOT be selected by users or generated by
=C2=A0 implementations.

=C2=A0 An extension MUST define any relationships that exist between the =C2=A0 various subtags in the extension and thus MAY define an alternate =C2=A0 canonicalization scheme for the extension's subtags. =C2=A0Exte= nsions MAY
=C2=A0 define how the order of the extension's subtags are interpreted= . =C2=A0For
=C2=A0 example, an extension could define that its subtags are in canonica= l
=C2=A0 order when the subtags are placed into ASCII order: that is, "= en-a-
=C2=A0 aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". =C2=A0An= other extension might
=C2=A0 define that the order of the subtags influences their semantic
=C2=A0 meaning (so that "en-b-ccc-bbb-aaa" has a different value= from "en-b-
=C2=A0 aaa-bbb-ccc"). =C2=A0However, extension specifications SHOULD = be designed
=C2=A0 so that they are tolerant of the typical processes described in
=C2=A0 Section 3.7.
--

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On
> Behalf Of Doug Ewell
> Sent: Wednesday, April 29, 2009 8:32 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in
> 4.5 extlang mapping
>
> Mark Davis <mark at macchia= to dot com> wrote:
>
> > The changes are marked in yellow.
>
> Not useful when reading the plain-text digest.
>
> > A language tag is in canonical form when:
> > ...
> > 2. =C2=A0It has been canonicalized according to the following pro= cess:
> > ...
> > 2. =C2=A0Subtags of type 'extlang' MUST be mapped to thei= r Preferred-
> Value.
>
> As Addison pointed out, the existing wording with SHOULD was a
> compromise. =C2=A0The battle between extlang and no-extlang camps was<= br> > lengthy
> and painful, and this was the wording the WG finally agreed upon.
> I
> object to using the IETF Last Call process to undo this compromise
> and
> swing the wording back in favor of the no-extlang side.
>
> --
> Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 464= 5 =C2=A0* =C2=A0UTN #14
> http://www.ewelli= c.org
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages =C2=A0=CB=86
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e9132d0764da0468ca8bd6-- From randy_presuhn@mindspring.com Thu Apr 30 12:40:21 2009 Return-Path: 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 4833C3A6D84 for ; Thu, 30 Apr 2009 12:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 fBV8FQuyYRS6 for ; Thu, 30 Apr 2009 12:40:20 -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 9A96128C172 for ; Thu, 30 Apr 2009 12:40:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Mw9d7KIDn6/gWtN42UrQ6BXZZrMPqRarePHtobVHD/7HWmXvG4P1Tg/ZnKARY9aH; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lzc8Y-0005S9-Dy for ltru@ietf.org; Thu, 30 Apr 2009 15:41:38 -0400 Message-ID: <00b701c9c9cc$1093c1c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A588@EX-SEA5-D.ant.amazon.com><49F815E6.6040309@it.aoyama.ac.jp> <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A773@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 12:44: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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69682f54e0e45a0c4cc2aeda748919df5f3a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #38, AD issue #5: ABNF vs UTF-8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:40:21 -0000 Hi - As co-chair... I think we have a clear consensus that we want to clarify that the ABNF is in terms of characters, rather than bytes. Minor textual changes in several spots have been identified as necessary to make this clarification, and we'll trust the editor to figure out whether the text he proposed, the text Martin proposed, or a merger of the two makes most sense. So, I've closed http://trac.tools.ietf.org/wg/ltru/trac/ticket/38 Randy From randy_presuhn@mindspring.com Thu Apr 30 12:50:25 2009 Return-Path: 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 4EBBF3A6E12 for ; Thu, 30 Apr 2009 12:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 UuseSpBIseqE for ; Thu, 30 Apr 2009 12:50:24 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 78F3A3A6CA5 for ; Thu, 30 Apr 2009 12:50:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PnJh4PPcnufqljl0I3IM4b5tDFSzNRaqmJ4OZXoOiwm5/qqC7Il5fr88HMCZfYEU; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzcIN-0000Dg-FJ for ltru@ietf.org; Thu, 30 Apr 2009 15:51:47 -0400 Message-ID: <00c601c9c9cd$7c338680$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEDD@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 12:54:33 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968e747def60ee6737be50422661fbd6fbd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #39: AD Issues #6: field name occurance limit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:50:25 -0000 Hi - As co-chair... Seeing no objections to the proposed resolution, I've closed http://trac.tools.ietf.org/wg/ltru/trac/ticket/39 Randy ----- Original Message ----- > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Wednesday, April 29, 2009 3:54 PM > Subject: [Ltru] Ticket #39: AD Issues #6: field name occurance limit > > The AD suggests: > > -- > Comment #6 from the AD review - see > http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html > > 6). In Section 3.1.2: > > Field-names MUST occur no more > than once per record, with the exception of the 'Description', > 'Comments', and sometimes the 'Prefix' field. > > (nit) Suggestion to reword using MUST NOT. E.g.: > > Field-names MUST NOT occur more > than once per record, with the exception of the 'Description', > 'Comments', and sometimes the 'Prefix' field. > -- > > Proposed Resolution: made this change. > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru From randy_presuhn@mindspring.com Thu Apr 30 12:59:15 2009 Return-Path: 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 612923A6E12 for ; Thu, 30 Apr 2009 12:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 Gp-zJp6jakXG for ; Thu, 30 Apr 2009 12:59:14 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 9CBB73A6ABF for ; Thu, 30 Apr 2009 12:59:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VlnkJ8S9rP13Za06T7AIAlaAGJ46p9ReQW8cb8MSgy1hkdZJJYE+Bqn3LGmfjSwD; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzcQv-0003vZ-F1 for ltru@ietf.org; Thu, 30 Apr 2009 16:00:37 -0400 Message-ID: <00d901c9c9ce$b8739bc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A590@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 13:03:24 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968f9f23bacf161f72e9844a7f69d581dfe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #34, AD Issue #1: who scrutinizes primary subtags rejected by ISO 639/RA-JAC X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:59:15 -0000 Hi - > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Tuesday, April 28, 2009 9:07 PM > Subject: [Ltru] Ticket #34, AD Issue #1: who scrutinizes primary subtags rejected by ISO 639/RA-JAC ... As a technical contributor... I'd like to point out that I posted a much simpler solution, more directly addressing the AD comment, was posted on April 12th. Specifically: | Proposed text: | replace "scrutinized" with "scrutinized by the Language Subtag Reviewer | (see 3.2)" At this stage of the process, I think minimal textual changes are to be preferred. Randy From addison@amazon.com Thu Apr 30 13:07:42 2009 Return-Path: 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 E4BA23A6B02 for ; Thu, 30 Apr 2009 13:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 7e237Ib407me for ; Thu, 30 Apr 2009 13:07:39 -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 B4D0B3A67F7 for ; Thu, 30 Apr 2009 13:07:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="260593814" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 20:09:01 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3UK90nR018797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 20:09:01 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Thu, 30 Apr 2009 13:09:00 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 13:09:05 -0700 Thread-Topic: [Ltru] Ticket #34, AD Issue #1: who scrutinizes primary subtags rejected by ISO 639/RA-JAC Thread-Index: AcnJzleqshH+/wKWR8+1Kqaq3hB6QwAARw9g Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34583@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A590@EX-SEA5-D.ant.amazon.com> <00d901c9c9ce$b8739bc0$6801a8c0@oemcomputer> In-Reply-To: <00d901c9c9ce$b8739bc0$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #34, AD Issue #1: who scrutinizes primary subtags rejected by ISO 639/RA-JAC X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:07:43 -0000 KGFzIGVkaXRvcikNCg0KU291bmRzIGdvb2QuIE1hZGUgdGhpcyBjaGFuZ2UgaW4gcGxhY2Ugb2Yg bXkgcHJvcG9zZWQgcmVzb2x1dGlvbi4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFBoaWxsaXBzDQpH bG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Omx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIFJhbmR5IFByZXN1aG4NCj4g U2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDE6MDMgUE0NCj4gVG86IExUUlUgV29ya2lu ZyBHcm91cA0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIFRpY2tldCAjMzQsIEFEIElzc3VlICMxOiB3 aG8gc2NydXRpbml6ZXMNCj4gcHJpbWFyeSBzdWJ0YWdzIHJlamVjdGVkIGJ5IElTTyA2MzkvUkEt SkFDDQo+IA0KPiBIaSAtDQo+IA0KPiA+IEZyb206ICJQaGlsbGlwcywgQWRkaXNvbiIgPGFkZGlz b25AYW1hem9uLmNvbT4NCj4gPiBUbzogIkxUUlUgV29ya2luZyBHcm91cCIgPGx0cnVAaWV0Zi5v cmc+DQo+ID4gU2VudDogVHVlc2RheSwgQXByaWwgMjgsIDIwMDkgOTowNyBQTQ0KPiA+IFN1Ympl Y3Q6IFtMdHJ1XSBUaWNrZXQgIzM0LCBBRCBJc3N1ZSAjMTogd2hvIHNjcnV0aW5pemVzIHByaW1h cnkNCj4gc3VidGFncyByZWplY3RlZCBieSBJU08gNjM5L1JBLUpBQw0KPiAuLi4NCj4gDQo+IEFz IGEgdGVjaG5pY2FsIGNvbnRyaWJ1dG9yLi4uDQo+IA0KPiBJJ2QgbGlrZSB0byBwb2ludCBvdXQg dGhhdCBJIHBvc3RlZCBhIG11Y2ggc2ltcGxlciBzb2x1dGlvbiwgbW9yZQ0KPiBkaXJlY3RseSBh ZGRyZXNzaW5nDQo+IHRoZSBBRCBjb21tZW50LCB3YXMgcG9zdGVkIG9uIEFwcmlsIDEydGguIFNw ZWNpZmljYWxseToNCj4gDQo+IHwgUHJvcG9zZWQgdGV4dDoNCj4gfCByZXBsYWNlICJzY3J1dGlu aXplZCIgd2l0aCAic2NydXRpbml6ZWQgYnkgdGhlIExhbmd1YWdlIFN1YnRhZw0KPiBSZXZpZXdl cg0KPiB8IChzZWUgMy4yKSINCj4gDQo+IEF0IHRoaXMgc3RhZ2Ugb2YgdGhlIHByb2Nlc3MsIEkg dGhpbmsgbWluaW1hbCB0ZXh0dWFsIGNoYW5nZXMgYXJlDQo+IHRvIGJlIHByZWZlcnJlZC4NCj4g DQo+IFJhbmR5DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K From randy_presuhn@mindspring.com Thu Apr 30 13:11:41 2009 Return-Path: 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 2B5463A690F for ; Thu, 30 Apr 2009 13:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 pcvkCAnGp5TB for ; Thu, 30 Apr 2009 13:11:40 -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 ED80A3A6B72 for ; Thu, 30 Apr 2009 13:11:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oCPQ9BzoTnFDPskvT/O7qMICAffW+P+VttdOpbTqDICG8QkzgdgaL+U6oC48vd3q; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lzcca-0002hz-Ry for ltru@ietf.org; Thu, 30 Apr 2009 16:12:41 -0400 Message-ID: <00f001c9c9d0$6750d120$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A590@EX-SEA5-D.ant.amazon.com> <00d901c9c9ce$b8739bc0$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34583@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 13:15:27 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968a2ca2644cabd0d4a99ed7505dbeb0449350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #34, AD Issue #1: who scrutinizes primary subtags rejected by ISO 639/RA-JAC X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:11:41 -0000 Hi - As co-chair... > From: "Phillips, Addison" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Thursday, April 30, 2009 1:09 PM > Subject: RE: [Ltru] Ticket #34, AD Issue #1: who scrutinizes primary subtags rejected by ISO 639/RA-JAC > > (as editor) > > Sounds good. Made this change in place of my proposed resolution. ... Ok, since that text has been out for a long time, I've closed this ticket http://trac.tools.ietf.org/wg/ltru/trac/ticket/34 Randy From randy_presuhn@mindspring.com Thu Apr 30 13:21:59 2009 Return-Path: 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 698A33A69A2 for ; Thu, 30 Apr 2009 13:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 z2d8Wyr19imB for ; Thu, 30 Apr 2009 13:21:58 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id B23983A680E for ; Thu, 30 Apr 2009 13:21:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bTcufk5S9oIeDvnzOkTH86nxg3by7DUgCWvU+a0g/zAU56zdewf2+KhUmLMQg8r1; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lzcmr-0001HA-UO for ltru@ietf.org; Thu, 30 Apr 2009 16:23:18 -0400 Message-ID: <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 13:26:04 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69684b8ccca12c3135846b04d50d3d02a569350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:21:59 -0000 Hi - As a technical contributor... > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Tuesday, April 28, 2009 9:50 PM > Subject: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 > > The AD mentions: > > -- > Comment number 7 from the AD review at > http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html > > 7). In Section 3.4: > > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that > conflict with existing subtags of the associated type, including > subtags that are deprecated, MUST NOT be entered into the > registry. The following additional considerations apply to > subtag values that are reassigned: > > [...] > > F. For ISO 3166-1 codes, if there is no associated UN numeric > code, then the Language Subtag Reviewer SHALL petition the > UN to create one. If there is no response from the UN > within ninety days of the request being sent, the Language > Subtag Reviewer SHALL prepare a proposal for entering in the > IANA registry as soon as practical a registered variant > subtag as an alternate value for the new code. The form of > the registered variant subtag will be at the discretion of > the Language Subtag Reviewer and MUST conform to other > restrictions on variant subtags in this document. This > situation is very unlikely to ever occur. > > 16. UN M.49 has codes for both countries and areas (such as '276' > for Germany) and geographical regions and sub-regions (such as > '150' for Europe). UN M.49 country or area codes for which > there is no corresponding ISO 3166-1 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166-1 code that is > blocked from registration by an existing subtag. If such a code > becomes necessary, then the registration authority for ISO > 3166-1 SHOULD > > Why SHOULD is used here instead of SHALL? > Similar text in 15.F says SHALL, which is stronger. > Also, 15.F specifies expected response time (90 days), which is missing > below. Any reason why you don't want to specify deadline in this case? > > first be petitioned to assign a code to the > region. If the petition for a code assignment by ISO 3166-1 is > refused or not acted on in a timely manner, the registration > process described in Section 3.5 MAY then be used to register > the corresponding UN M.49 code. This way, UN M.49 codes remain > available as the value of last resort in cases where ISO 3166-1 > reassigns a deprecated value in the registry. > -- > > I think the cases are different. > > In the former case, BCP 47 requires a UN M.49 code to exist. In the extremely unlikely event that "we" are the first to notice that one hasn't been assigned, the LSR is obligated to ask for one. > > In the latter case (rule 16) we presume that someone is asking for a UN M.49 code that has no corresponding ISO 3166 code. This is not unheard of. It is merely exceptionally rare and typically a Bad Idea to register exceptionally (hence the recommendation to go to ISO, etc.). It isn't SHALL because we don't rely on the code for continued stable operation of the registry. > > Proposed resolution: no change. I disagree. The context is where a code has become necessary. We have a policy that essentially amounts to avoiding the numeric codes unless there is no alternative. No one has suggested any scenario where it might make sense to not petition the ISO 3166 registration authority. Maintaining the policy in an even-handed way suggests to me that we should indeed replace the sentence currently reading If such a code becomes necessary, then the registration authority for ISO 3166-1 SHOULD first be petitioned to assign a code to the region. with If such a code becomes necessary, then the registration authority for ISO 3166-1 SHALL first be petitioned to assign a code to the region. Randy From randy_presuhn@mindspring.com Thu Apr 30 13:38:04 2009 Return-Path: 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 626893A6C37 for ; Thu, 30 Apr 2009 13:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 1ppMHmzVaIKi for ; Thu, 30 Apr 2009 13:38:03 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 89E663A6A4E for ; Thu, 30 Apr 2009 13:38:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LNKhJucmAJ7fm5c8mh+SqevWpulw2LvY124jt6QGJXlQAhUFWenM6faAety421KQ; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lzd2U-0003ap-Ai for ltru@ietf.org; Thu, 30 Apr 2009 16:39:26 -0400 Message-ID: <015301c9c9d4$247b9b60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEE3@EX-SEA5-D.ant.amazon.com><20090429230325.GH7401@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AF3C@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 13:42: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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968be21f6d3dcf9c440ed11f3d7a2da670c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #41: AD Issue #8: section 3.5 SHOULD vs. MUST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:38:04 -0000 Hi - As co-chair... > From: "Phillips, Addison" > To: "John Cowan" > Cc: "LTRU Working Group" > Sent: Wednesday, April 29, 2009 4:21 PM > Subject: Re: [Ltru] Ticket #41: AD Issue #8: section 3.5 SHOULD vs. MUST ... There was already a lengthy (well, perhaps not length for *this* list) discussion of this issue on April 11 and 12. Having re-read that thread, and these more recent postings, I'm declaring rough consensus for "no change". HOWEVER, I'm leaving open the possibility of adding a clarification that the passage in question is talking about the original request submitted for review, and not the (potentially) resulting request forwarded to IANA. If you believe such an addition would be helpful, please make your proposals *now*. Randy From addison@amazon.com Thu Apr 30 13:45:13 2009 Return-Path: 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 086283A6CA5 for ; Thu, 30 Apr 2009 13:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 NVa96H1DcQfd for ; Thu, 30 Apr 2009 13:45:12 -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 2F4963A6767 for ; Thu, 30 Apr 2009 13:45:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="260610764" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 20:46:34 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3UKkXfX032015 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 20:46:34 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Thu, 30 Apr 2009 13:46:33 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 13:46:30 -0700 Thread-Topic: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 Thread-Index: AcnJ0YXEWaBpl0o+TE+JFv3kWGsE/AAADS8A Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE3464A@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> In-Reply-To: <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:45:13 -0000 PiAgICAgICBJZiBzdWNoIGEgY29kZSBiZWNvbWVzIG5lY2Vzc2FyeSwgdGhlbiB0aGUgcmVnaXN0 cmF0aW9uDQo+IGF1dGhvcml0eSBmb3IgSVNPDQo+ICAgICAgIDMxNjYtMSBTSEFMTCBmaXJzdCBi ZSBwZXRpdGlvbmVkIHRvIGFzc2lnbiBhIGNvZGUgdG8gdGhlDQo+IHJlZ2lvbi4gDQoNCihhcyBj b250cmlidXRvcikNCg0KSSBhZ3JlZSB3aXRoIHRoaXMgY2hhbmdlLg0KDQooYXMgZWRpdG9yKQ0K DQpJIGhhdmUgaW1wbGVtZW50ZWQgdGhpcyBjaGFuZ2UgaW4gbXkgY29weS4NCg0KQWRkaXNvbg0K DQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0K SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVj dHVyZS4NCg0KDQo= From randy_presuhn@mindspring.com Thu Apr 30 13:47:25 2009 Return-Path: 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 95EE03A6AA1 for ; Thu, 30 Apr 2009 13:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 WjWNb8RA67q2 for ; Thu, 30 Apr 2009 13:47:24 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id A773C3A6767 for ; Thu, 30 Apr 2009 13:47:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kK1EZbaMWSl1PV5fsjBlBmxUcfUsGpEJGtlEEQTja/MogvfwDgCekr2+WAiJ9YzK; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzdBX-0000GG-PE for ltru@ietf.org; Thu, 30 Apr 2009 16:48:48 -0400 Message-ID: <017401c9c9d5$73008240$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AF24@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 13:51:34 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968cdc64277b2b115a697af5340e2c56d54350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #42: AD Issue #9: confusing future tense X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:47:25 -0000 Hi - As co-chair: We'll procede with the note to the RFC editor. I've marked this issue closed. http://trac.tools.ietf.org/wg/ltru/trac/ticket/42 Randy ----- Original Message ----- > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Wednesday, April 29, 2009 4:18 PM > Subject: [Ltru] Ticket #42: AD Issue #9: confusing future tense > > The AD commented: > > -- > AD review comment #9 from > http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html > > 9). > > 3.8. Update of the Language Subtag Registry > > Upon adoption of this document the IANA Language Subtag Registry will > need an update so that it contains the complete set of subtags valid > in a language tag. This collection of subtags, along with a > description of the process used to create it, is described by > [draft-4645bis]. IANA will publish the updated version of the > registry described by this document using the instructions and > content of [draft-4645bis]. > > (nit) I think both 4645bis and 4646bis should be published at the same time. > If this happens, then use of future tense in the published RFC would be > confusing and will not match the reality. > > I suggest adding an RFC Editor note asking to fix this sentence. > > Once published by IANA, the maintenance > procedures, rules, and registration processes described in this > document will be available for new registrations or updates. > -- > > Proposed Resolution: > > Note that this is text only mildly modified from 4646. I inserted an RFC Editor note saying: > > RFC Editor: please modify this paragraph upon publication to reflect the fact that RFC 4645bis has also been published (past tense). > > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru From addison@amazon.com Thu Apr 30 13:52:17 2009 Return-Path: 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 8A21E3A6778 for ; Thu, 30 Apr 2009 13:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.593 X-Spam-Level: X-Spam-Status: No, score=-107.593 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 VftFKrGDx4xg for ; Thu, 30 Apr 2009 13:52:15 -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 ACF0C3A6857 for ; Thu, 30 Apr 2009 13:52:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208,217";a="260613589" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 20:53:36 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3UKrZlk007380 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 20:53:36 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Thu, 30 Apr 2009 13:53:35 -0700 From: "Phillips, Addison" To: Mark Davis Date: Thu, 30 Apr 2009 13:53:30 -0700 Thread-Topic: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping Thread-Index: AcnJyEkDB9SKnH+yTEaB61L2EkO64gAC4YzQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34677@EX-SEA5-D.ant.amazon.com> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> <30b660a20904301217k5c9dc539v566cbb0f2c5f3912@mail.gmail.com> In-Reply-To: <30b660a20904301217k5c9dc539v566cbb0f2c5f3912@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE34677EXSEA5Dantama_" MIME-Version: 1.0 Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:52:17 -0000 --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE34677EXSEA5Dantama_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx0aG91Z2ggSSBhZ3JlZSB3aXRoIHlvdXIgc2VudGltZW50cywgSSB0aGluayB3ZSBjYW4gYXZv aWQgc29tZSBhZGRpdGlvbmFsIHdvcmtpbmcgZ3JvdXAgYmxvb2RsZXR0aW5nIGJ5IGJlaW5nIGNh cmVmdWwgd2l0aCBvdXIgd29yZGluZyBjaG9pY2VzLiBJIHBhcnRpY3VsYXJseSBub3RlIHRoYXQg UkZDIDIxMTkga2V5d29yZHMsIHdoaWxlIGhhdmUgYSBub3JtYXRpdmUgd2VpZ2h0IHRvIHRoZW0s IGFyZSBub3QgdGhlIG9ubHkgd2F5IHRvIGJlIOKAnG5vcm1hdGl2ZeKAnSBpbiBhIHNwZWMuIFRo dXMsIEkgcHJvcG9zZSB0byB0YWtlIHlvdXIgc3VnZ2VzdGlvbjoNCg0KLS0NClRoZSBkZWZhdWx0 IGNhbm9uaWNhbCBmb3JtIFNIT1VMRCBub3JtYWxseSBiZSB1c2VkIGZvciBjYW5vbmljYWxpemF0 aW9uLiBUaGUgZXh0ZW5kZWQgY2Fub25pY2FsIGZvcm0gbWF5IGJlIHVzZWZ1bA0KaW4gZW52aXJv bm1lbnRzIHdoZXJlIHRoZSBwcmVzZW5jZSBvZiB0aGUgbWFjcm9sYW5ndWFnZSBpcyBiZW5lZmlj aWFsIGluIG1hdGNoaW5nIG9yIHNlbGVjdGlvbi4NCi0tDQoNCuKApiBidXQgbW9kaWZpZWQgdG8g cmVhZOKApg0KDQotLQ0KPHQ+Tm9ybWFsbHksIHRoZSAnZGVmYXVsdCcgY2Fub25pY2FsaXphdGlv biBpcyBwcmVmZXJyZWQuIEhvd2V2ZXIsIHRoZSAnZXh0ZW5kZWQnIGNhbm9uaWNhbCBmb3JtIGlz IHVzZWZ1bA0KaW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBwcmVzZW5jZSBvZiB0aGUgbWFjcm9s YW5ndWFnZSBpcyBiZW5lZmljaWFsIGluIG1hdGNoaW5nIG9yIHNlbGVjdGlvbiAoc2VlIDx4cmVm IHRhcmdldD0iY2hvaWNlVXNpbmdFeHRsYW5nIj48L3hyZWY+KS48L3Q+DQotLQ0KDQpJbiBpbmNv cnBvcmF0aW5nIHlvdXIgcHJvcG9zZWQgY2hhbmdlcywgSSBub3RpY2VkIHRoYXQgdGhlcmUgd2Fz IG5vIG5lZWQgZm9yIGRvdWJsZS0gb3IgdHJpcGxlLWxpc3QgZW1iZWRkaW5nLiBJIGFsc28gbm90 ZSB0aGF0LCBzaW5jZSB3ZSBhcmUgZGVzY3JpYmluZyBhIGNhbm9uaWNhbGl6YXRpb24gcHJvY2Vz cywgdXNpbmcgMjExOSBrZXl3b3JkcyBpc27igJl0IG5lY2Vzc2FyeS4gV2UgY2FuIGp1c3Qgc2F5 IOKAnGRvIFjigJ0uDQoNClRoZSByZXN1bHRpbmcgdGV4dCByZWFkcyBhczoNCg0KLS0NCkEgbGFu Z3VhZ2UgdGFnIGlzIGluIGEgY2Fub25pY2FsIGZvcm0gd2hlbiB0aGUgdGFnIGlzIHdlbGwtZm9y bWVkIGFjY29yZGluZyB0aGUgcnVsZXMgaW4gPHhyZWYgdGFyZ2V0PSJzeW50YXgiLz4gYW5kDQo8 eHJlZiB0YXJnZXQ9InNvdXJjZXMiLz4gYW5kIGl0IGhhcyBiZWVuIGNhbm9uaWNhbGl6ZWQgYXMg Zm9sbG93czoNCg0KIDxsaXN0IHN0eWxlPSJudW1iZXJzIj4NCg0KPHQ+UmVkdW5kYW50IG9yIGdy YW5kZmF0aGVyZWQgdGFncyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUgbWFwcGluZyBpbiB0 aGUgSUFOQSByZWdpc3RyeSAoc2VlIDx4cmVmIHRhcmdldD0iaWFuYWZvcm1hdCIvPikgYXJlIHJl cGxhY2VkIHdpdGggdGhlaXIgbWFwcGVkIHZhbHVlLiBUaGVzZSBpdGVtcyBhcmUgZWl0aGVyIGRl cHJlY2F0ZWQgbWFwcGluZ3MgY3JlYXRlZCBiZWZvcmUgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9j dW1lbnQgKHN1Y2ggYXMgdGhlIG1hcHBpbmcgb2YgIm5vLW55biIgdG8gIm5uIiBvciAiaS1rbGlu Z29uIiB0byAidGxoIikgb3IgYXJlIHRoZSByZXN1bHQgb2YgbGF0ZXIgcmVnaXN0cmF0aW9ucyBv ciBhZGRpdGlvbnMgdG8gdGhpcyBkb2N1bWVudCAoZm9yIGV4YW1wbGUsICJ6aC1oYWtrYSIgd2Fz IGRlcHJlY2F0ZWQgaW4gZmF2b3Igb2YgdGhlIElTTyA2MzktMyBjb2RlICdoYWsnIHdoZW4gdGhp cyBkb2N1bWVudCB3YXMgYWRvcHRlZCkuIFRoZXNlIG1hcHBpbmdzIE1VU1QgYmUgZG9uZSBiZWZv cmUgYWRkaXRpb25hbCBwcm9jZXNzaW5nLCBzaW5jZSB0aGVyZSBjYW4gYmUgYWRkaXRpb25hbCBj aGFuZ2VzIHRvIHN1YnRhZyB2YWx1ZXMuIFRoZXNlIGZpZWxkLWJvZHkgb2YgdGhlIFByZWZlcnJl ZC1WYWx1ZSBmb3IgZ3JhbmRmYXRoZXJlZCBhbmQgcmVkdW5kYW50IHRhZ3MgaXMgYW4gImV4dGVu ZGVkIGxhbmd1YWdlIHJhbmdlIiAoPHhyZWYgdGFyZ2V0PSJSRkM0NjQ3Ij48L3hyZWY+KSBhbmQg bWlnaHQgY29uc2lzdCBvZiBtb3JlIHRoYW4gb25lIHN1YnRhZy48L3Q+DQoNCjx0Pk9uZSBvZiB0 aGUgZm9sbG93aW5nIGNhbm9uaWNhbCBmb3JtcyBoYXMgYmVlbiBhcHBsaWVkOg0KDQo8bGlzdCBz dHlsZT0ibGV0dGVycyI+DQoNCjx0PkluIHRoZSAnZGVmYXVsdCcgY2Fub25pY2FsIGZvcm0sIHN1 YnRhZ3Mgb2YgdHlwZSAnZXh0bGFuZycgYXJlIG1hcHBlZCB0byB0aGVpciBQcmVmZXJyZWQtVmFs dWUuIFRoZSBmaWVsZC1ib2R5IG9mIHRoZSBQcmVmZXJyZWQtVmFsdWUgZm9yIGV4dGxhbmdzIGlz IGFuICJleHRlbmRlZCBsYW5ndWFnZSByYW5nZSIsIHR5cGljYWxseSBhIHByaW1hcnkgbGFuZ3Vh Z2Ugc3VidGFnIChpbiBhbGwgc3VjaCBjYXNlcywgdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFn IGlzIHJlbW92ZWQpLiBGb3IgZXhhbXBsZSwgdGhlIHN1YnRhZyBzZXF1ZW5jZSAiemgtaGFrIiAo Q2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJlcGxhY2VkIHdpdGggdGhlIHRhZyAiaGFrIiAoSGFr a2EpLjwvdD4NCg0KPHQ+SW4gdGhlICdleHRlbmRlZCcgY2Fub25pY2FsIGZvcm0sIHByaW1hcnkg bGFuZ3VhZ2Ugc3VidGFncyB3aXRoIGEgJ01hY3JvbGFuZ3VhZ2UnIGZpZWxkIHRoYXQgYXJlIGFs c28gcmVnaXN0ZXJlZCBhcyAnZXh0bGFuZycgc3VidGFncyBhcmUgcmVwbGFjZWQgYnkgdGhlaXIg bWFjcm9sYW5ndWFnZS1leHRsYW5nIGNvbWJpbmF0aW9uLiBGb3IgZXhhbXBsZSwgdGhlIGxhbmd1 YWdlIHRhZyAiaGFrIiAoSGFra2EpIGhhcyBhIE1hY3JvbGFuZ3VhZ2Ugb2YgJ3poJyAoQ2hpbmVz ZSkgYW5kIGFuIGV4aXN0aW5nICdleHRsYW5nJyByZWdpc3RyYXRpb24uIFRoZSB0YWcgd291bGQg YmUgcmVwbGFjZWQgd2l0aCB0aGF0IHRhZyAiemgtaGFrIiAoQ2hpbmVzZSwgSGFra2EpLjwvdD4N Cg0KPC9saXN0PjwvdD4NCg0KPHQ+T3RoZXIgc3VidGFncyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQt VmFsdWUgZmllbGQgaW4gdGhlIElBTkEgcmVnaXN0cnkgKHNlZSA8eHJlZiB0YXJnZXQ9ImlhbmFm b3JtYXQiLz4pIGhhdmUgYmVlbiByZXBsYWNlZCB3aXRoIHRoZWlyIG1hcHBlZCB2YWx1ZS4gTW9z dCBvZiB0aGVzZSBhcmUgZWl0aGVyIFJlZ2lvbiBzdWJ0YWdzIHdoZXJlIHRoZSBjb3VudHJ5IG5h bWUgb3IgZGVzaWduYXRpb24gaGFzIGNoYW5nZWQgb3IgY2xlcmljYWwgY29ycmVjdGlvbnMgdG8g SVNPIDYzOS0xLjwvdD4NCg0KPHQ+SWYgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24gc3VidGFnIHNl cXVlbmNlIGV4aXN0cywgdGhlIGV4dGVuc2lvbiBzZXF1ZW5jZXMgYXJlIG9yZGVyZWQgaW50byBj YXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVyIGJ5IHNpbmdsZXRvbiBzdWJ0YWcgKHRoYXQgaXMs IHRoZSBzdWJ0YWcgc2VxdWVuY2UgJy1hLWJhYmJsZScgY29tZXMgYmVmb3JlICctYi13YXJibGUn KS48L3Q+DQoNCjwvbGlzdD4NCi0tDQoNCkFkZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24g QXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0 dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KDQpGcm9tOiBtYXJrLmVkd2FyZC5kYXZpc0Bn bWFpbC5jb20gW21haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb21dIE9uIEJlaGFsZiBP ZiBNYXJrIERhdmlzDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMDkgMTI6MTcgUE0NClRv OiBQaGlsbGlwcywgQWRkaXNvbg0KQ2M6IERvdWcgRXdlbGw7IExUUlUgV29ya2luZyBHcm91cA0K U3ViamVjdDogUmU6IFtMdHJ1XSBUaWNrZXQgIzQ1OiBBRCBJc3N1ZSAjMTI6IHJlYXNvbiBmb3Ig U0hPVUxEIGluIDQuNSBleHRsYW5nIG1hcHBpbmcNCg0KDQpNYXJrDQoNCk9uIFRodSwgQXByIDMw LCAyMDA5IGF0IDA4OjIwLCBQaGlsbGlwcywgQWRkaXNvbiA8YWRkaXNvbkBhbWF6b24uY29tPG1h aWx0bzphZGRpc29uQGFtYXpvbi5jb20+PiB3cm90ZToNCk9rYXksIEkndmUgZmluaXNoZWQgZ2Vu ZXJhdGluZyB0aGUgbmV3IGRyYWZ0IGFuZCBkaWZmaW5nIGl0LiBPdXIgb25seSByZW1haW5pbmcg b3BlbiBpdGVtIGlzIHRoaXMgaXNzdWUuDQoNCkxhc3QgbmlnaHQgSSBwcm9wb3NlZCBkZWZpbmlu ZyB0d28gY2Fub25pY2FsIGZvcm1zIHRvIHJlc29sdmUgdGhlIG11ZGRpbmVzcyBvZiAiU0hPVUxE Ii4gSSBub3cgaGF2ZSBhIHNlcGFyYXRlIGVkaXRvcidzIGNvcHkgb2YgdGhlIGRyYWZ0IHdpdGgg YSBwcm9wb3NlZCBlZGl0IHRvIGFjY29tcGxpc2ggdGhpcy4gQ28tY2hhaXIgZ3VpZGFuY2Ugb24g dGhpcyBpc3N1ZSBpcyB2ZXJ5IG11Y2ggZGVzaXJlZC4NCg0KQmVsb3cgaXMgbXkgcHJvcG9zZWQg ZWRpdGVkIHRleHQgZm9yIHNlY3Rpb24gNC41LiBTdWdnZXN0aW9ucyBhbmQgZml4ZXMgYXJlIHdl bGNvbWUuIEluIHBhcnRpY3VsYXIsIEkgaGF2ZW4ndCBzYWlkIGFueXRoaW5nIGFib3V0IHdoZW4g dG8gdXNlIHdoaWNoIGZvcm0uDQoNCi0tDQo0LjUuICBDYW5vbmljYWxpemF0aW9uIG9mIExhbmd1 YWdlIFRhZ3MNCiAgU2luY2UgYSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHRhZyBpcyBzb21ldGltZXMg dXNlZCBieSBtYW55IHByb2Nlc3NlcywNCiAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWx3YXlzIGJl IGNyZWF0ZWQgb3IgZ2VuZXJhdGVkIGluIGEgY2Fub25pY2FsDQogIGZvcm0uDQoNCiAgVGhlcmUg YXJlIHR3byBjYW5vbmljYWwgZm9ybXMgZm9yIGxhbmd1YWdlIHRhZ3MuICBUaGUgJ2RlZmF1bHQn DQogIGNhbm9uaWNhbCBmb3JtIG1hcHMgZWFjaCAnZXh0bGFuZycgc3VidGFnIHRvIGl0cyBQcmVm ZXJyZWQtVmFsdWUuDQogIFRoZSAnZXh0ZW5kZWQnIGNhbm9uaWNhbCBmb3JtIGluY2x1ZGVzIHRo ZSBtYWNyb2xhbmd1YWdlIHByaW1hcnkNCiAgbGFuZ3VhZ2Ugc3VidGFnIGJlZm9yZSBlbGlnaWJs ZSAoZXh0ZW5kZWQpIGxhbmd1YWdlIHN1YnRhZ3MuDQoNCkkgYWdyZWUgd2l0aCB0aGVzZSBuYW1l cy4gSWYgd2UgY2hhbmdlIHRoZSBuYW1lIG9mICdkZWZhdWx0JyB0byBhbnl0aGluZyBlbHNlLCB3 ZSdkIGhhdmUgdG8gbWFrZSBhbiBhZGRpdGlvbmFsIGNoYW5nZSB0byBwcmVzZXJ2ZSB0aGUgY29t cHJvbWlzZSBTSE9VTEQgZnJvbSB0aGUgcHJldmlvdXMgdGV4dCwgc29tZXRoaW5nIGxpa2U6DQoN ClRoZSBkZWZhdWx0IGNhbm9uaWNhbCBmb3JtIFNIT1VMRCBub3JtYWxseSBiZSB1c2VkIGZvciBj YW5vbmljYWxpemF0aW9uLiBUaGUgZXh0ZW5kZWQgY2Fub25pY2FsIGZvcm0gbWF5IGJlIHVzZWZ1 bA0KDQppbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlIHByZXNlbmNlIG9mIHRoZSBtYWNyb2xhbmd1 YWdlIGlzIGJlbmVmaWNpYWwgaW4gbWF0Y2hpbmcgb3Igc2VsZWN0aW9uLg0KDQoNCg0KDQoNCg0K DQogIEEgbGFuZ3VhZ2UgdGFnIGlzIGluIGEgY2Fub25pY2FsIGZvcm0gd2hlbjoNCg0KICAxLiAg VGhlIHRhZyBpcyB3ZWxsLWZvcm1lZCBhY2NvcmRpbmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gMi4x IGFuZA0KICAgICAgU2VjdGlvbiAyLjIuDQoNClRoaXMgb21pdHMgdGhlIHNpZ25pZmljYW50IGNv bnNpc3RlbmN5IHByb2JsZW0gbXVkZGxpbmcgZGVmaW5pbmcgYSBjYW5vbmljYWwgZm9ybSwgYW5k IGRlZmluaW5nIHRoZSBwcm9jZXNzIGZvciBjYW5vbmljYWxpemluZy4gUGxlYXNlIGNoYW5nZSB0 aGUgbnVtYmVyaW5nL2luZGVudCBmb3IgMi00IGFuZCBhZGQ6DQoNCiAgIDIuICBJdCBoYXMgYmVl biBjYW5vbmljYWxpemVkIGFjY29yZGluZyB0byB0aGUgZm9sbG93aW5nIHByb2Nlc3M6DQoNCg0K DQogIDIuICBSZWR1bmRhbnQgb3IgZ3JhbmRmYXRoZXJlZCB0YWdzIHRoYXQgaGF2ZSBhIFByZWZl cnJlZC1WYWx1ZQ0KICAgICAgbWFwcGluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSAoc2VlIFNlY3Rp b24gMy4xKSBNVVNUIGJlIHJlcGxhY2VkDQogICAgICB3aXRoIHRoZWlyIG1hcHBlZCB2YWx1ZS4g IFRoZXNlIGl0ZW1zIGVpdGhlciBhcmUgZGVwcmVjYXRlZA0KICAgICAgbWFwcGluZ3MgY3JlYXRl ZCBiZWZvcmUgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKHN1Y2ggYXMNCiAgICAgIHRo ZSBtYXBwaW5nIG9mICJuby1ueW4iIHRvICJubiIgb3IgImkta2xpbmdvbiIgdG8gInRsaCIpIG9y IGFyZQ0KICAgICAgdGhlIHJlc3VsdCBvZiBsYXRlciByZWdpc3RyYXRpb25zIG9yIGFkZGl0aW9u cyB0byB0aGlzIGRvY3VtZW50DQogICAgICAoZm9yIGV4YW1wbGUsICJ6aC1oYWtrYSIgd2FzIGRl cHJlY2F0ZWQgaW4gZmF2b3Igb2YgdGhlIElTTyA2MzktMw0KICAgICAgY29kZSAnaGFrJyB3aGVu IHRoaXMgZG9jdW1lbnQgd2FzIGFkb3B0ZWQpLiAgVGhlc2UgbWFwcGluZ3MNCiAgICAgIFNIT1VM RCBiZSBkb25lIGJlZm9yZSBhZGRpdGlvbmFsIHByb2Nlc3NpbmcsIHNpbmNlIHRoZXJlIGNhbiBi ZQ0KICAgICAgYWRkaXRpb25hbCBjaGFuZ2VzIHRvIHN1YnRhZyB2YWx1ZXMuICBUaGVzZSBmaWVs ZC1ib2R5IG9mIHRoZQ0KICAgICAgUHJlZmVycmVkLVZhbHVlIGZvciBncmFuZGZhdGhlcmVkIGFu ZCByZWR1bmRhbnQgdGFncyBpcyBhbg0KICAgICAgImV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIiAo W1JGQzQ2NDddKSBhbmQgbWlnaHQgY29uc2lzdCBvZiBtb3JlDQogICAgICB0aGFuIG9uZSBzdWJ0 YWcuDQogIDMuICBJbiB0aGUgJ2RlZmF1bHQnIGNhbm9uaWNhbCBmb3JtLCBzdWJ0YWdzIG9mIHR5 cGUgJ2V4dGxhbmcnIE1VU1QNCiAgICAgIGJlIG1hcHBlZCB0byB0aGVpciBQcmVmZXJyZWQtVmFs dWUuICBUaGUgZmllbGQtYm9keSBvZiB0aGUNCiAgICAgIFByZWZlcnJlZC1WYWx1ZSBmb3IgZXh0 bGFuZ3MgaXMgYW4gImV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIiwNCiAgICAgIHR5cGljYWxseSBh IHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIChpbiBhbGwgc3VjaCBjYXNlcywgdGhlDQogICAgICBw cmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBpcyByZW1vdmVkKS4gIEZvciBleGFtcGxlLCB0aGUgc3Vi dGFnDQogICAgICBzZXF1ZW5jZSAiemgtaGFrIiAoQ2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJl cGxhY2VkIHdpdGggdGhlIHRhZw0KICAgICAgImhhayIgKEhha2thKS4NCiAgNC4gIEluIHRoZSAn ZXh0ZW5kZWQnIGNhbm9uaWNhbCBmb3JtLCBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3Mgd2l0aCBh DQogICAgICAnTWFjcm9sYW5ndWFnZScgZmllbGQgdGhhdCBhcmUgYWxzbyByZWdpc3RlcmVkIGFz ICdleHRsYW5nJw0KICAgICAgc3VidGFncyBNVVNUIGJlIHJlcGxhY2VkIGJ5IHRoZWlyIG1hY3Jv bGFuZ3VhZ2UtZXh0bGFuZw0KICAgICAgY29tYmluYXRpb24uICBGb3IgZXhhbXBsZSwgdGhlIGxh bmd1YWdlIHRhZyAiaGFrIiAoSGFra2EpIGhhcyBhDQogICAgICBNYWNyb2xhbmd1YWdlIG9mICd6 aCcgKENoaW5lc2UpIGFuZCBhbiBleGlzdGluZyAnZXh0bGFuZycNCiAgICAgIHJlZ2lzdHJhdGlv bi4gIFRoZSB0YWcgd291bGQgYmUgcmVwbGFjZWQgd2l0aCB0aGF0IHRhZyAiemgtaGFrIg0KICAg ICAgKENoaW5lc2UsIEhha2thKS4NCg0KICA1LiAgT3RoZXIgc3VidGFncyB0aGF0IGhhdmUgYSBQ cmVmZXJyZWQtVmFsdWUgZmllbGQgaW4gdGhlIElBTkENCiAgICAgIHJlZ2lzdHJ5IChzZWUgU2Vj dGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwZWQNCiAgICAgIHZhbHVl LiAgTW9zdCBvZiB0aGVzZSBhcmUgZWl0aGVyIFJlZ2lvbiBzdWJ0YWdzIHdoZXJlIHRoZSBjb3Vu dHJ5DQogICAgICBuYW1lIG9yIGRlc2lnbmF0aW9uIGhhcyBjaGFuZ2VkIG9yIGNsZXJpY2FsIGNv cnJlY3Rpb25zIHRvIElTTw0KICAgICAgNjM5LTEuDQogIDYuICBJZiBtb3JlIHRoYW4gb25lIGV4 dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2UgZXhpc3RzLCB0aGUgZXh0ZW5zaW9uDQoNCiAgICAgIHNl cXVlbmNlcyBhcmUgb3JkZXJlZCBpbnRvIGNhc2UtaW5zZW5zaXRpdmUgQVNDSUkgb3JkZXIgYnkN Cg0KUGxlYXNlIGNoYW5nZSAiYXJlIG9yZGVyZWQiIHRvICJNVVNUIGJlIG9yZGVyZWQiLiBUaGlz IGlzIG5vdCBvcHRpb25hbCBpbiBleGFjdGx5IHRoZSBzYW1lIHNlbnNlIGFzIGFsbCB0aGUgb3Ro ZXIgY2xhdXNlcyBhcmUgbm90IG9wdGlvbmFsLiAoVGhhdCBpcywgdGhleSBtdXN0IGFsbCBiZSAi YXJlIiBvciBhbGwgYmUgIk1VU1QiLikNCg0KICAgICAgc2luZ2xldG9uIHN1YnRhZyAodGhhdCBp cywgdGhlIHN1YnRhZyBzZXF1ZW5jZSAnLWEtYmFiYmxlJyBjb21lcw0KICAgICAgYmVmb3JlICct Yi13YXJibGUnKS4NCiAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAiZW4tYS1hYWEtYi1jY2Mt YmJiLXgteHl6IiBpcyBpbiBjYW5vbmljYWwNCiAgZm9ybSwgd2hpbGUgImVuLWItY2NjLWJiYi1h LWFhYS1YLXh5eiIgaXMgd2VsbC1mb3JtZWQgYW5kIHBvdGVudGlhbGx5DQogIHZhbGlkIChleHRl bnNpb25zICdhJyBhbmQgJ2InIGFyZSBub3QgZGVmaW5lZCBhcyBvZiB0aGUgcHVibGljYXRpb24N CiAgb2YgdGhpcyBkb2N1bWVudCkgYnV0IG5vdCBpbiBjYW5vbmljYWwgZm9ybSAodGhlIGV4dGVu c2lvbnMgYXJlIG5vdA0KICBpbiBhbHBoYWJldGljYWwgb3JkZXIpLg0KDQogIEV4YW1wbGU6IEFs dGhvdWdoIHRoZSB0YWcgImVuLUJVIiAoRW5nbGlzaCBhcyB1c2VkIGluIEJ1cm1hKQ0KICBtYWlu dGFpbnMgaXRzIHZhbGlkaXR5LCB0aGUgbGFuZ3VhZ2UgdGFnICJlbi1CVSIgaXMgbm90IGNhbm9u aWNhbA0KICBiZWNhdXNlIHRoZSAnQlUnIHN1YnRhZyBoYXMgYSBjYW5vbmljYWwgbWFwcGluZyB0 byAnTU0nIChNeWFubWFyKS4NCg0KICBDYW5vbmljYWxpemF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mg ZG9lcyBub3QgaW1wbHkgYW55dGhpbmcgYWJvdXQgdGhlDQogIHVzZSBvZiB1cHBlciBvciBsb3dl cmNhc2UgbGV0dGVycyB3aGVuIHByb2Nlc3Npbmcgb3IgY29tcGFyaW5nDQogIHN1YnRhZ3MgKGFu ZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEpLiAgQWxsIGNvbXBhcmlzb25zIE1VU1QgYmUN CiAgcGVyZm9ybWVkIGluIGEgY2FzZS1pbnNlbnNpdGl2ZSBtYW5uZXIuDQoNCiAgV2hlbiBwZXJm b3JtaW5nIGNhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncywgcHJvY2Vzc29ycyBNQVkN CiAgcmVndWxhcml6ZSB0aGUgY2FzZSBvZiB0aGUgc3VidGFncyAodGhhdCBpcywgdGhpcyBwcm9j ZXNzIGlzDQogIE9QVElPTkFMKSwgZm9sbG93aW5nIHRoZSBjYXNlIHVzZWQgaW4gdGhlIHJlZ2lz dHJ5IChzZWUNCiAgU2VjdGlvbiAyLjEuMSkuDQoNCiAgSWYgbW9yZSB0aGFuIG9uZSB2YXJpYW50 IGFwcGVhcnMgd2l0aGluIGEgdGFnLCBwcm9jZXNzb3JzIE1BWSByZW9yZGVyDQogIHRoZSB2YXJp YW50cyB0byBvYnRhaW4gYmV0dGVyIG1hdGNoaW5nIGJlaGF2aW9yIG9yIG1vcmUgY29uc2lzdGVu dA0KICBwcmVzZW50YXRpb24uICBSZW9yZGVyaW5nIG9mIHRoZSB2YXJpYW50cyBTSE9VTEQgZm9s bG93IHRoZQ0KICByZWNvbW1lbmRhdGlvbnMgZm9yIHZhcmlhbnQgb3JkZXJpbmcgaW4gU2VjdGlv biA0LjEuDQoNCiAgSWYgdGhlIGZpZWxkICdEZXByZWNhdGVkJyBhcHBlYXJzIGluIGEgcmVnaXN0 cnkgcmVjb3JkIHdpdGhvdXQgYW4NCiAgYWNjb21wYW55aW5nICdQcmVmZXJyZWQtVmFsdWUnIGZp ZWxkLCB0aGVuIHRoYXQgdGFnIG9yIHN1YnRhZyBpcw0KICBkZXByZWNhdGVkIHdpdGhvdXQgYSBy ZXBsYWNlbWVudC4gIFRoZXNlIHZhbHVlcyBhcmUgY2Fub25pY2FsIHdoZW4NCiAgdGhleSBhcHBl YXIgaW4gYSBsYW5ndWFnZSB0YWcuICBIb3dldmVyLCB0YWdzIHRoYXQgaW5jbHVkZSB0aGVzZQ0K ICB2YWx1ZXMgU0hPVUxEIE5PVCBiZSBzZWxlY3RlZCBieSB1c2VycyBvciBnZW5lcmF0ZWQgYnkN CiAgaW1wbGVtZW50YXRpb25zLg0KDQogIEFuIGV4dGVuc2lvbiBNVVNUIGRlZmluZSBhbnkgcmVs YXRpb25zaGlwcyB0aGF0IGV4aXN0IGJldHdlZW4gdGhlDQogIHZhcmlvdXMgc3VidGFncyBpbiB0 aGUgZXh0ZW5zaW9uIGFuZCB0aHVzIE1BWSBkZWZpbmUgYW4gYWx0ZXJuYXRlDQogIGNhbm9uaWNh bGl6YXRpb24gc2NoZW1lIGZvciB0aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncy4gIEV4dGVuc2lvbnMg TUFZDQogIGRlZmluZSBob3cgdGhlIG9yZGVyIG9mIHRoZSBleHRlbnNpb24ncyBzdWJ0YWdzIGFy ZSBpbnRlcnByZXRlZC4gIEZvcg0KICBleGFtcGxlLCBhbiBleHRlbnNpb24gY291bGQgZGVmaW5l IHRoYXQgaXRzIHN1YnRhZ3MgYXJlIGluIGNhbm9uaWNhbA0KICBvcmRlciB3aGVuIHRoZSBzdWJ0 YWdzIGFyZSBwbGFjZWQgaW50byBBU0NJSSBvcmRlcjogdGhhdCBpcywgImVuLWEtDQogIGFhYS1i YmItY2NjIiBpbnN0ZWFkIG9mICJlbi1hLWNjYy1iYmItYWFhIi4gIEFub3RoZXIgZXh0ZW5zaW9u IG1pZ2h0DQogIGRlZmluZSB0aGF0IHRoZSBvcmRlciBvZiB0aGUgc3VidGFncyBpbmZsdWVuY2Vz IHRoZWlyIHNlbWFudGljDQogIG1lYW5pbmcgKHNvIHRoYXQgImVuLWItY2NjLWJiYi1hYWEiIGhh cyBhIGRpZmZlcmVudCB2YWx1ZSBmcm9tICJlbi1iLQ0KICBhYWEtYmJiLWNjYyIpLiAgSG93ZXZl ciwgZXh0ZW5zaW9uIHNwZWNpZmljYXRpb25zIFNIT1VMRCBiZSBkZXNpZ25lZA0KICBzbyB0aGF0 IHRoZXkgYXJlIHRvbGVyYW50IG9mIHRoZSB0eXBpY2FsIHByb2Nlc3NlcyBkZXNjcmliZWQgaW4N CiAgU2VjdGlvbiAzLjcuDQotLQ0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFy Y2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVy ZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmx0cnUtYm91bmNlc0BpZXRm Lm9yZz4gW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmx0cnUtYm91bmNlc0Bp ZXRmLm9yZz5dIE9uDQo+IEJlaGFsZiBPZiBEb3VnIEV3ZWxsDQo+IFNlbnQ6IFdlZG5lc2RheSwg QXByaWwgMjksIDIwMDkgODozMiBQTQ0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1Ympl Y3Q6IFJlOiBbTHRydV0gVGlja2V0ICM0NTogQUQgSXNzdWUgIzEyOiByZWFzb24gZm9yIFNIT1VM RCBpbg0KPiA0LjUgZXh0bGFuZyBtYXBwaW5nDQo+DQo+IE1hcmsgRGF2aXMgPG1hcmsgYXQgbWFj Y2hpYXRvIGRvdCBjb20+IHdyb3RlOg0KPg0KPiA+IFRoZSBjaGFuZ2VzIGFyZSBtYXJrZWQgaW4g eWVsbG93Lg0KPg0KPiBOb3QgdXNlZnVsIHdoZW4gcmVhZGluZyB0aGUgcGxhaW4tdGV4dCBkaWdl c3QuDQo+DQo+ID4gQSBsYW5ndWFnZSB0YWcgaXMgaW4gY2Fub25pY2FsIGZvcm0gd2hlbjoNCj4g PiAuLi4NCj4gPiAyLiAgSXQgaGFzIGJlZW4gY2Fub25pY2FsaXplZCBhY2NvcmRpbmcgdG8gdGhl IGZvbGxvd2luZyBwcm9jZXNzOg0KPiA+IC4uLg0KPiA+IDIuICBTdWJ0YWdzIG9mIHR5cGUgJ2V4 dGxhbmcnIE1VU1QgYmUgbWFwcGVkIHRvIHRoZWlyIFByZWZlcnJlZC0NCj4gVmFsdWUuDQo+DQo+ IEFzIEFkZGlzb24gcG9pbnRlZCBvdXQsIHRoZSBleGlzdGluZyB3b3JkaW5nIHdpdGggU0hPVUxE IHdhcyBhDQo+IGNvbXByb21pc2UuICBUaGUgYmF0dGxlIGJldHdlZW4gZXh0bGFuZyBhbmQgbm8t ZXh0bGFuZyBjYW1wcyB3YXMNCj4gbGVuZ3RoeQ0KPiBhbmQgcGFpbmZ1bCwgYW5kIHRoaXMgd2Fz IHRoZSB3b3JkaW5nIHRoZSBXRyBmaW5hbGx5IGFncmVlZCB1cG9uLg0KPiBJDQo+IG9iamVjdCB0 byB1c2luZyB0aGUgSUVURiBMYXN0IENhbGwgcHJvY2VzcyB0byB1bmRvIHRoaXMgY29tcHJvbWlz ZQ0KPiBhbmQNCj4gc3dpbmcgdGhlIHdvcmRpbmcgYmFjayBpbiBmYXZvciBvZiB0aGUgbm8tZXh0 bGFuZyBzaWRlLg0KPg0KPiAtLQ0KPiBEb3VnIEV3ZWxsICAqICBUaG9ybnRvbiwgQ29sb3JhZG8s IFVTQSAgKiAgUkZDIDQ2NDUgICogIFVUTiAjMTQNCj4gaHR0cDovL3d3dy5ld2VsbGljLm9yZw0K PiBodHRwOi8vd3d3MS5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sDQo+ IGh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbGFuZ3VhZ2Vz ICDLhg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYub3JnPG1haWx0bzpMdHJ1QGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMdHJ1IG1haWxp bmcgbGlzdA0KTHRydUBpZXRmLm9yZzxtYWlsdG86THRydUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE34677EXSEA5Dantama_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDMgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlBNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAz IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQXJpYWwgVW5pY29k ZSBNUyI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBQTWlu Z0xpVSI7DQoJcGFub3NlLTE6MiAyIDMgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJMdWNpZGEgU2FucyBVbmljb2RlIjsNCglwYW5vc2UtMToyIDExIDYgMiAzIDUg NCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCiAv KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0K QHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0K LS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1w dXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzFGNDk3RCc+QWx0aG91Z2ggSSBhZ3JlZSB3aXRoIHlvdXIgc2VudGltZW50 cywgSSB0aGluayB3ZSBjYW4gYXZvaWQgc29tZQ0KYWRkaXRpb25hbCB3b3JraW5nIGdyb3VwIGJs b29kbGV0dGluZyBieSBiZWluZyBjYXJlZnVsIHdpdGggb3VyIHdvcmRpbmcNCmNob2ljZXMuIEkg cGFydGljdWxhcmx5IG5vdGUgdGhhdCBSRkMgMjExOSBrZXl3b3Jkcywgd2hpbGUgaGF2ZSBhIG5v cm1hdGl2ZQ0Kd2VpZ2h0IHRvIHRoZW0sIGFyZSBub3QgdGhlIG9ubHkgd2F5IHRvIGJlIOKAnG5v cm1hdGl2ZeKAnSBpbiBhIHNwZWMuIFRodXMsIEkgcHJvcG9zZQ0KdG8gdGFrZSB5b3VyIHN1Z2dl c3Rpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5UaGUg ZGVmYXVsdCBjYW5vbmljYWwgZm9ybSBTSE9VTEQgbm9ybWFsbHkgYmUgdXNlZCBmb3INCmNhbm9u aWNhbGl6YXRpb24uIFRoZSBleHRlbmRlZCBjYW5vbmljYWwgZm9ybSBtYXkgYmUgdXNlZnVsPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPmluIGVudmlyb25tZW50cyB3aGVyZSB0aGUgcHJlc2VuY2Ugb2YgdGhlIG1hY3Jv bGFuZ3VhZ2UgaXMNCmJlbmVmaWNpYWwgaW4gbWF0Y2hpbmcgb3Igc2VsZWN0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0 OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+4oCmIGJ1dCBtb2RpZmllZCB0 byByZWFk4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4m bHQ7dCZndDtOb3JtYWxseSwgdGhlICdkZWZhdWx0JyBjYW5vbmljYWxpemF0aW9uIGlzIHByZWZl cnJlZC4NCkhvd2V2ZXIsIHRoZSAnZXh0ZW5kZWQnIGNhbm9uaWNhbCBmb3JtIGlzIHVzZWZ1bDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xv cjojMUY0OTdEJz5pbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlIHByZXNlbmNlIG9mIHRoZSBtYWNy b2xhbmd1YWdlIGlzDQpiZW5lZmljaWFsIGluIG1hdGNoaW5nIG9yIHNlbGVjdGlvbiAoc2VlICZs dDt4cmVmDQp0YXJnZXQ9JnF1b3Q7Y2hvaWNlVXNpbmdFeHRsYW5nJnF1b3Q7Jmd0OyZsdDsveHJl ZiZndDspLiZsdDsvdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPkluIGluY29ycG9yYXRpbmcgeW91ciBwcm9wb3NlZCBjaGFuZ2VzLCBJIG5vdGljZWQg dGhhdCB0aGVyZSB3YXMNCm5vIG5lZWQgZm9yIGRvdWJsZS0gb3IgdHJpcGxlLWxpc3QgZW1iZWRk aW5nLiBJIGFsc28gbm90ZSB0aGF0LCBzaW5jZSB3ZSBhcmUNCmRlc2NyaWJpbmcgYSBjYW5vbmlj YWxpemF0aW9uIHByb2Nlc3MsIHVzaW5nIDIxMTkga2V5d29yZHMgaXNu4oCZdCBuZWNlc3Nhcnku IFdlDQpjYW4ganVzdCBzYXkg4oCcZG8gWOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPlRoZSByZXN1bHRpbmcgdGV4dCByZWFkcyBhczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkEgbGFuZ3VhZ2UgdGFnIGlzIGluIGEgY2Fub25pY2FsIGZv cm0gd2hlbiB0aGUgdGFnIGlzDQp3ZWxsLWZvcm1lZCBhY2NvcmRpbmcgdGhlIHJ1bGVzIGluICZs dDt4cmVmIHRhcmdldD0mcXVvdDtzeW50YXgmcXVvdDsvJmd0OyBhbmQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+Jmx0 O3hyZWYgdGFyZ2V0PSZxdW90O3NvdXJjZXMmcXVvdDsvJmd0OyBhbmQgaXQgaGFzIGJlZW4NCmNh bm9uaWNhbGl6ZWQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+wqAgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPsKgJmx0 O2xpc3Qgc3R5bGU9JnF1b3Q7bnVtYmVycyZxdW90OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+Jmx0O3QmZ3Q7UmVkdW5kYW50IG9yIGdyYW5kZmF0aGVy ZWQgdGFncyB0aGF0IGhhdmUgYQ0KUHJlZmVycmVkLVZhbHVlIG1hcHBpbmcgaW4gdGhlIElBTkEg cmVnaXN0cnkgKHNlZSAmbHQ7eHJlZg0KdGFyZ2V0PSZxdW90O2lhbmFmb3JtYXQmcXVvdDsvJmd0 OykgYXJlIHJlcGxhY2VkIHdpdGggdGhlaXIgbWFwcGVkIHZhbHVlLiBUaGVzZQ0KaXRlbXMgYXJl IGVpdGhlciBkZXByZWNhdGVkIG1hcHBpbmdzIGNyZWF0ZWQgYmVmb3JlIHRoZSBhZG9wdGlvbiBv ZiB0aGlzDQpkb2N1bWVudCAoc3VjaCBhcyB0aGUgbWFwcGluZyBvZiAmcXVvdDtuby1ueW4mcXVv dDsgdG8gJnF1b3Q7bm4mcXVvdDsgb3INCiZxdW90O2kta2xpbmdvbiZxdW90OyB0byAmcXVvdDt0 bGgmcXVvdDspIG9yIGFyZSB0aGUgcmVzdWx0IG9mIGxhdGVyDQpyZWdpc3RyYXRpb25zIG9yIGFk ZGl0aW9ucyB0byB0aGlzIGRvY3VtZW50IChmb3IgZXhhbXBsZSwgJnF1b3Q7emgtaGFra2EmcXVv dDsNCndhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTMgY29kZSAnaGFrJyB3 aGVuIHRoaXMgZG9jdW1lbnQgd2FzDQphZG9wdGVkKS4gVGhlc2UgbWFwcGluZ3MgTVVTVCBiZSBk b25lIGJlZm9yZSBhZGRpdGlvbmFsIHByb2Nlc3NpbmcsIHNpbmNlIHRoZXJlDQpjYW4gYmUgYWRk aXRpb25hbCBjaGFuZ2VzIHRvIHN1YnRhZyB2YWx1ZXMuIFRoZXNlIGZpZWxkLWJvZHkgb2YgdGhl DQpQcmVmZXJyZWQtVmFsdWUgZm9yIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFudCB0YWdzIGlz IGFuICZxdW90O2V4dGVuZGVkDQpsYW5ndWFnZSByYW5nZSZxdW90OyAoJmx0O3hyZWYgdGFyZ2V0 PSZxdW90O1JGQzQ2NDcmcXVvdDsmZ3Q7Jmx0Oy94cmVmJmd0OykgYW5kDQptaWdodCBjb25zaXN0 IG9mIG1vcmUgdGhhbiBvbmUgc3VidGFnLiZsdDsvdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPiZsdDt0Jmd0O09uZSBvZiB0aGUgZm9sbG93aW5nIGNhbm9uaWNhbCBmb3JtcyBo YXMgYmVlbiBhcHBsaWVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+Jmx0O2xpc3Qg c3R5bGU9JnF1b3Q7bGV0dGVycyZxdW90OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+wqAgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0Qn PiZsdDt0Jmd0O0luIHRoZSAnZGVmYXVsdCcgY2Fub25pY2FsIGZvcm0sIHN1YnRhZ3Mgb2YgdHlw ZQ0KJ2V4dGxhbmcnIGFyZSBtYXBwZWQgdG8gdGhlaXIgUHJlZmVycmVkLVZhbHVlLiBUaGUgZmll bGQtYm9keSBvZiB0aGUNClByZWZlcnJlZC1WYWx1ZSBmb3IgZXh0bGFuZ3MgaXMgYW4gJnF1b3Q7 ZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UmcXVvdDssDQp0eXBpY2FsbHkgYSBwcmltYXJ5IGxhbmd1 YWdlIHN1YnRhZyAoaW4gYWxsIHN1Y2ggY2FzZXMsIHRoZSBwcmltYXJ5IGxhbmd1YWdlDQpzdWJ0 YWcgaXMgcmVtb3ZlZCkuIEZvciBleGFtcGxlLCB0aGUgc3VidGFnIHNlcXVlbmNlICZxdW90O3po LWhhayZxdW90Ow0KKENoaW5lc2UsIEhha2thKSB3b3VsZCBiZSByZXBsYWNlZCB3aXRoIHRoZSB0 YWcgJnF1b3Q7aGFrJnF1b3Q7DQooSGFra2EpLiZsdDsvdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMxRjQ5N0QnPiZsdDt0Jmd0O0luIHRoZSAnZXh0ZW5kZWQnIGNhbm9uaWNhbCBmb3JtLCBw cmltYXJ5IGxhbmd1YWdlDQpzdWJ0YWdzIHdpdGggYSAnTWFjcm9sYW5ndWFnZScgZmllbGQgdGhh dCBhcmUgYWxzbyByZWdpc3RlcmVkIGFzICdleHRsYW5nJw0Kc3VidGFncyBhcmUgcmVwbGFjZWQg YnkgdGhlaXIgbWFjcm9sYW5ndWFnZS1leHRsYW5nIGNvbWJpbmF0aW9uLiBGb3IgZXhhbXBsZSwN CnRoZSBsYW5ndWFnZSB0YWcgJnF1b3Q7aGFrJnF1b3Q7IChIYWtrYSkgaGFzIGEgTWFjcm9sYW5n dWFnZSBvZiAnemgnIChDaGluZXNlKQ0KYW5kIGFuIGV4aXN0aW5nICdleHRsYW5nJyByZWdpc3Ry YXRpb24uIFRoZSB0YWcgd291bGQgYmUgcmVwbGFjZWQgd2l0aCB0aGF0IHRhZw0KJnF1b3Q7emgt aGFrJnF1b3Q7IChDaGluZXNlLCBIYWtrYSkuJmx0Oy90Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29s b3I6IzFGNDk3RCc+Jmx0Oy9saXN0Jmd0OyZsdDsvdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPiZsdDt0Jmd0O090aGVyIHN1YnRhZ3MgdGhhdCBoYXZlIGEgUHJlZmVycmVkLVZh bHVlIGZpZWxkIGluIHRoZQ0KSUFOQSByZWdpc3RyeSAoc2VlICZsdDt4cmVmIHRhcmdldD0mcXVv dDtpYW5hZm9ybWF0JnF1b3Q7LyZndDspIGhhdmUgYmVlbiByZXBsYWNlZA0Kd2l0aCB0aGVpciBt YXBwZWQgdmFsdWUuIE1vc3Qgb2YgdGhlc2UgYXJlIGVpdGhlciBSZWdpb24gc3VidGFncyB3aGVy ZSB0aGUNCmNvdW50cnkgbmFtZSBvciBkZXNpZ25hdGlvbiBoYXMgY2hhbmdlZCBvciBjbGVyaWNh bCBjb3JyZWN0aW9ucyB0byBJU08NCjYzOS0xLiZsdDsvdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMxRjQ5N0QnPiZsdDt0Jmd0O0lmIG1vcmUgdGhhbiBvbmUgZXh0ZW5zaW9uIHN1YnRhZyBz ZXF1ZW5jZSBleGlzdHMsIHRoZQ0KZXh0ZW5zaW9uIHNlcXVlbmNlcyBhcmUgb3JkZXJlZCBpbnRv IGNhc2UtaW5zZW5zaXRpdmUgQVNDSUkgb3JkZXIgYnkgc2luZ2xldG9uIHN1YnRhZw0KKHRoYXQg aXMsIHRoZSBzdWJ0YWcgc2VxdWVuY2UgJy1hLWJhYmJsZScgY29tZXMgYmVmb3JlICctYi13YXJi bGUnKS4mbHQ7L3QmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4mbHQ7L2xpc3Qm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN CmNvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Ikx1Y2lkYSBTYW5zIFVuaWNvZGUiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPkFkZGlzb24gUGhpbGxpcHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJMdWNpZGEg U2FucyBVbmljb2RlIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5HbG9iYWxpemF0aW9u IEFyY2hpdGVjdCAtLSBMYWIxMjY8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjkuMHB0 O2ZvbnQtZmFtaWx5OiJMdWNpZGEgU2FucyBVbmljb2RlIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiTHVjaWRhIFNhbnMgVW5pY29kZSIs InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseToiTHVjaWRhIFNhbnMgVW5pY29kZSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiJMdWNpZGEgU2FucyBVbmljb2RlIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MUY0OTdEJz5JdCBpcyBhbiBhcmNoaXRlY3R1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+DQptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb20gW21h aWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb21dIDxiPk9uIEJlaGFsZg0KT2YgPC9iPk1h cmsgRGF2aXM8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDEyOjE3 IFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsbGlwcywgQWRkaXNvbjxicj4NCjxiPkNjOjwvYj4gRG91 ZyBFd2VsbDsgTFRSVSBXb3JraW5nIEdyb3VwPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTHRy dV0gVGlja2V0ICM0NTogQUQgSXNzdWUgIzEyOiByZWFzb24gZm9yIFNIT1VMRCBpbiA0LjUNCmV4 dGxhbmcgbWFwcGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiciBjbGVhcj1hbGw+DQpNYXJr PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD5PbiBUaHUsIEFwciAzMCwgMjAwOSBhdCAwODoyMCwgUGhpbGxpcHMsIEFkZGlzb24gJmx0Ozxh DQpocmVmPSJtYWlsdG86YWRkaXNvbkBhbWF6b24uY29tIj5hZGRpc29uQGFtYXpvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPk9rYXksIEkn dmUgZmluaXNoZWQgZ2VuZXJhdGluZyB0aGUgbmV3IGRyYWZ0IGFuZCBkaWZmaW5nIGl0Lg0KT3Vy IG9ubHkgcmVtYWluaW5nIG9wZW4gaXRlbSBpcyB0aGlzIGlzc3VlLjxicj4NCjxicj4NCkxhc3Qg bmlnaHQgSSBwcm9wb3NlZCBkZWZpbmluZyB0d28gY2Fub25pY2FsIGZvcm1zIHRvIHJlc29sdmUg dGhlIG11ZGRpbmVzcyBvZg0KJnF1b3Q7U0hPVUxEJnF1b3Q7LiBJIG5vdyBoYXZlIGEgc2VwYXJh dGUgZWRpdG9yJ3MgY29weSBvZiB0aGUgZHJhZnQgd2l0aCBhDQpwcm9wb3NlZCBlZGl0IHRvIGFj Y29tcGxpc2ggdGhpcy4gQ28tY2hhaXIgZ3VpZGFuY2Ugb24gdGhpcyBpc3N1ZSBpcyB2ZXJ5IG11 Y2gNCmRlc2lyZWQuPGJyPg0KPGJyPg0KQmVsb3cgaXMgbXkgcHJvcG9zZWQgZWRpdGVkIHRleHQg Zm9yIHNlY3Rpb24gNC41LiBTdWdnZXN0aW9ucyBhbmQgZml4ZXMgYXJlDQp3ZWxjb21lLiBJbiBw YXJ0aWN1bGFyLCBJIGhhdmVuJ3Qgc2FpZCBhbnl0aGluZyBhYm91dCB3aGVuIHRvIHVzZSB3aGlj aCBmb3JtLjxicj4NCjxicj4NCi0tPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjQuNS4gJm5ic3A7Q2Fub25p Y2FsaXphdGlvbiBvZg0KTGFuZ3VhZ2UgVGFnczxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyBTaW5jZSBhIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgdGFn IGlzIHNvbWV0aW1lcyB1c2VkIGJ5DQptYW55IHByb2Nlc3Nlcyw8YnI+DQombmJzcDsgbGFuZ3Vh Z2UgdGFncyBTSE9VTEQgYWx3YXlzIGJlIGNyZWF0ZWQgb3IgZ2VuZXJhdGVkIGluIGEgY2Fub25p Y2FsPGJyPg0KJm5ic3A7IGZvcm0uPGJyPg0KPGJyPg0KJm5ic3A7IFRoZXJlIGFyZSB0d28gY2Fu b25pY2FsIGZvcm1zIGZvciBsYW5ndWFnZSB0YWdzLiAmbmJzcDtUaGUgJ2RlZmF1bHQnPGJyPg0K Jm5ic3A7IGNhbm9uaWNhbCBmb3JtIG1hcHMgZWFjaCAnZXh0bGFuZycgc3VidGFnIHRvIGl0cyBQ cmVmZXJyZWQtVmFsdWUuPGJyPg0KJm5ic3A7IFRoZSAnZXh0ZW5kZWQnIGNhbm9uaWNhbCBmb3Jt IGluY2x1ZGVzIHRoZSBtYWNyb2xhbmd1YWdlIHByaW1hcnk8YnI+DQombmJzcDsgbGFuZ3VhZ2Ug c3VidGFnIGJlZm9yZSBlbGlnaWJsZSAoZXh0ZW5kZWQpIGxhbmd1YWdlIHN1YnRhZ3MuPG86cD48 L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxicj4NCkkgYWdyZWUgd2l0aCB0aGVzZSBuYW1lcy4gSWYgd2UgY2hhbmdl IHRoZSBuYW1lIG9mICdkZWZhdWx0JyB0byBhbnl0aGluZyBlbHNlLA0Kd2UnZCBoYXZlIHRvIG1h a2UgYW4gYWRkaXRpb25hbCBjaGFuZ2UgdG8gcHJlc2VydmUgdGhlIGNvbXByb21pc2UgU0hPVUxE IGZyb20NCnRoZSBwcmV2aW91cyB0ZXh0LCBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvcD4N Cg0KPHByZT48c3BhbiBzdHlsZT0nYmFja2dyb3VuZDojRkZGRjY2Jz5UaGUgZGVmYXVsdCBjYW5v bmljYWwgZm9ybSBTSE9VTEQgbm9ybWFsbHkgYmUgdXNlZCBmb3IgY2Fub25pY2FsaXphdGlvbi4g VGhlIGV4dGVuZGVkIGNhbm9uaWNhbCBmb3JtIG1heSBiZSB1c2VmdWw8YnI+DQppbiBlbnZpcm9u bWVudHMgd2hlcmUgdGhlIHByZXNlbmNlIG9mIHRoZSBtYWNyb2xhbmd1YWdlIGlzIGJlbmVmaWNp YWwgaW4gbWF0Y2hpbmcgb3Igc2VsZWN0aW9uLjwvc3Bhbj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcHJlPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwv ZGl2Pg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0Ow0KbWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQo8YnI+DQom bmJzcDsgQSBsYW5ndWFnZSB0YWcgaXMgaW4gYSBjYW5vbmljYWwgZm9ybSB3aGVuOjxvOnA+PC9v OnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPg0KJm5ic3A7IDEuICZu YnNwO1RoZSB0YWcgaXMgd2VsbC1mb3JtZWQgYWNjb3JkaW5nIHRoZSBydWxlcyBpbiBTZWN0aW9u IDIuMSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBTZWN0aW9uIDIuMi48bzpwPjwvbzpw PjwvcD4NCg0KPC9kaXY+DQoNCjwvYmxvY2txdW90ZT4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0KVGhpcyBvbWl0cyB0aGUg c2lnbmlmaWNhbnQgY29uc2lzdGVuY3kgcHJvYmxlbSBtdWRkbGluZyBkZWZpbmluZyBhIGNhbm9u aWNhbA0KZm9ybSwgYW5kIGRlZmluaW5nIHRoZSBwcm9jZXNzIGZvciBjYW5vbmljYWxpemluZy4g UGxlYXNlIGNoYW5nZSB0aGUNCm51bWJlcmluZy9pbmRlbnQgZm9yIDItNCBhbmQgYWRkOjxvOnA+ PC9vOnA+PC9wPg0KDQo8cHJlPsKgwqAgPHNwYW4gc3R5bGU9J2JhY2tncm91bmQ6I0ZGRkY2Nic+ Mi7CoCBJdCBoYXMgYmVlbiBjYW5vbmljYWxpemVkIGFjY29yZGluZyB0byB0aGUgZm9sbG93aW5n IHByb2Nlc3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7DQptYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluJz4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0K PGJyPg0KJm5ic3A7IDIuICZuYnNwO1JlZHVuZGFudCBvciBncmFuZGZhdGhlcmVkIHRhZ3MgdGhh dCBoYXZlIGEgUHJlZmVycmVkLVZhbHVlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWFwcGlu ZyBpbiB0aGUgSUFOQSByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4xKSBNVVNUIGJlDQpyZXBsYWNl ZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpdGggdGhlaXIgbWFwcGVkIHZhbHVlLiAmbmJz cDtUaGVzZSBpdGVtcyBlaXRoZXIgYXJlDQpkZXByZWNhdGVkPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgbWFwcGluZ3MgY3JlYXRlZCBiZWZvcmUgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1l bnQNCihzdWNoIGFzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIG1hcHBpbmcgb2YgJnF1 b3Q7bm8tbnluJnF1b3Q7IHRvICZxdW90O25uJnF1b3Q7IG9yDQomcXVvdDtpLWtsaW5nb24mcXVv dDsgdG8gJnF1b3Q7dGxoJnF1b3Q7KSBvciBhcmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0 aGUgcmVzdWx0IG9mIGxhdGVyIHJlZ2lzdHJhdGlvbnMgb3IgYWRkaXRpb25zIHRvIHRoaXMNCmRv Y3VtZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgKGZvciBleGFtcGxlLCAmcXVvdDt6aC1o YWtrYSZxdW90OyB3YXMgZGVwcmVjYXRlZCBpbiBmYXZvcg0Kb2YgdGhlIElTTyA2MzktMzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvZGUgJ2hhaycgd2hlbiB0aGlzIGRvY3VtZW50IHdhcyBh ZG9wdGVkKS4gJm5ic3A7VGhlc2UNCm1hcHBpbmdzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg U0hPVUxEIGJlIGRvbmUgYmVmb3JlIGFkZGl0aW9uYWwgcHJvY2Vzc2luZywgc2luY2UgdGhlcmUN CmNhbiBiZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFkZGl0aW9uYWwgY2hhbmdlcyB0byBz dWJ0YWcgdmFsdWVzLiAmbmJzcDtUaGVzZQ0KZmllbGQtYm9keSBvZiB0aGU8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBQcmVmZXJyZWQtVmFsdWUgZm9yIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVu ZGFudCB0YWdzIGlzIGFuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7ZXh0ZW5kZWQg bGFuZ3VhZ2UgcmFuZ2UmcXVvdDsgKFtSRkM0NjQ3XSkgYW5kIG1pZ2h0DQpjb25zaXN0IG9mIG1v cmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGFuIG9uZSBzdWJ0YWcuPG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7IDMuICZuYnNwO0luIHRo ZSAnZGVmYXVsdCcgY2Fub25pY2FsIGZvcm0sIHN1YnRhZ3Mgb2YNCnR5cGUgJ2V4dGxhbmcnIE1V U1Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiZSBtYXBwZWQgdG8gdGhlaXIgUHJlZmVycmVk LVZhbHVlLiAmbmJzcDtUaGUgZmllbGQtYm9keQ0Kb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgUHJlZmVycmVkLVZhbHVlIGZvciBleHRsYW5ncyBpcyBhbiAmcXVvdDtleHRlbmRlZCBs YW5ndWFnZQ0KcmFuZ2UmcXVvdDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwaWNhbGx5 IGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgKGluIGFsbCBzdWNoIGNhc2VzLA0KdGhlPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaXMgcmVtb3ZlZCku ICZuYnNwO0ZvciBleGFtcGxlLA0KdGhlIHN1YnRhZzxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4mbmJzcDsg Jm5ic3A7ICZuYnNwOyBzZXF1ZW5jZQ0KJnF1b3Q7emgtaGFrJnF1b3Q7IChDaGluZXNlLCBIYWtr YSkgd291bGQgYmUgcmVwbGFjZWQgd2l0aCB0aGUgdGFnPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJnF1b3Q7aGFrJnF1b3Q7IChIYWtrYSkuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7IDQuICZuYnNwO0luIHRoZSAnZXh0ZW5kZWQnIGNhbm9u aWNhbCBmb3JtLCBwcmltYXJ5DQpsYW5ndWFnZSBzdWJ0YWdzIHdpdGggYTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICdNYWNyb2xhbmd1YWdlJyBmaWVsZCB0aGF0IGFyZSBhbHNvIHJlZ2lzdGVy ZWQgYXMNCidleHRsYW5nJzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1YnRhZ3MgTVVTVCBi ZSByZXBsYWNlZCBieSB0aGVpciBtYWNyb2xhbmd1YWdlLWV4dGxhbmc8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBjb21iaW5hdGlvbi4gJm5ic3A7Rm9yIGV4YW1wbGUsIHRoZSBsYW5ndWFnZSB0 YWcNCiZxdW90O2hhayZxdW90OyAoSGFra2EpIGhhcyBhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgTWFjcm9sYW5ndWFnZSBvZiAnemgnIChDaGluZXNlKSBhbmQgYW4gZXhpc3RpbmcgJ2V4dGxh bmcnPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVnaXN0cmF0aW9uLiAmbmJzcDtUaGUgdGFn IHdvdWxkIGJlIHJlcGxhY2VkIHdpdGggdGhhdA0KdGFnICZxdW90O3poLWhhayZxdW90Ozxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IChDaGluZXNlLCBIYWtrYSkuPGJyPg0KPGJyPg0KJm5ic3A7 IDUuICZuYnNwO090aGVyIHN1YnRhZ3MgdGhhdCBoYXZlIGEgUHJlZmVycmVkLVZhbHVlIGZpZWxk IGluIHRoZSBJQU5BPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlZ2lz dHJ5DQooc2VlIFNlY3Rpb24gMy4xKSBNVVNUIGJlIHJlcGxhY2VkIHdpdGggdGhlaXIgbWFwcGVk PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdmFsdWUuICZuYnNwO01vc3Qgb2YgdGhlc2UgYXJl IGVpdGhlciBSZWdpb24gc3VidGFncyB3aGVyZQ0KdGhlIGNvdW50cnk8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBuYW1lIG9yIGRlc2lnbmF0aW9uIGhhcyBjaGFuZ2VkIG9yIGNsZXJpY2FsIGNv cnJlY3Rpb25zIHRvDQpJU088YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyA2MzktMS48bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsgNi4gJm5ic3A7 SWYgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24gc3VidGFnIHNlcXVlbmNlDQpleGlzdHMsIHRoZSBl eHRlbnNpb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8YmxvY2tx dW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0Ow0KbWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHNlcXVlbmNlcyBh cmUgb3JkZXJlZCBpbnRvDQpjYXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVyIGJ5PG86cD48L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj4NClBsZWFzZSBjaGFuZ2Ug JnF1b3Q7YXJlIG9yZGVyZWQmcXVvdDsgdG8gJnF1b3Q7TVVTVCBiZSBvcmRlcmVkJnF1b3Q7LiBU aGlzIGlzDQpub3Qgb3B0aW9uYWwgaW4gZXhhY3RseSB0aGUgc2FtZSBzZW5zZSBhcyBhbGwgdGhl IG90aGVyIGNsYXVzZXMgYXJlIG5vdA0Kb3B0aW9uYWwuIChUaGF0IGlzLCB0aGV5IG11c3QgYWxs IGJlICZxdW90O2FyZSZxdW90OyBvciBhbGwgYmUNCiZxdW90O01VU1QmcXVvdDsuKTxvOnA+PC9v OnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDsNCm1h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4nPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBzaW5nbGV0b24gc3VidGFnICh0aGF0IGlzLCB0aGUgc3VidGFnIHNlcXVlbmNlICct YS1iYWJibGUnDQpjb21lczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlZm9yZSAnLWItd2Fy YmxlJykuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7IEV4YW1wbGU6IFRoZSBsYW5ndWFnZSB0YWcNCiZxdW90O2VuLWEtYWFhLWItY2NjLWJiYi14 LXh5eiZxdW90OyBpcyBpbiBjYW5vbmljYWw8YnI+DQombmJzcDsgZm9ybSwgd2hpbGUgJnF1b3Q7 ZW4tYi1jY2MtYmJiLWEtYWFhLVgteHl6JnF1b3Q7IGlzIHdlbGwtZm9ybWVkIGFuZA0KcG90ZW50 aWFsbHk8YnI+DQombmJzcDsgdmFsaWQgKGV4dGVuc2lvbnMgJ2EnIGFuZCAnYicgYXJlIG5vdCBk ZWZpbmVkIGFzIG9mIHRoZSBwdWJsaWNhdGlvbjxicj4NCiZuYnNwOyBvZiB0aGlzIGRvY3VtZW50 KSBidXQgbm90IGluIGNhbm9uaWNhbCBmb3JtICh0aGUgZXh0ZW5zaW9ucyBhcmUgbm90PGJyPg0K Jm5ic3A7IGluIGFscGhhYmV0aWNhbCBvcmRlcikuPGJyPg0KPGJyPg0KJm5ic3A7IEV4YW1wbGU6 IEFsdGhvdWdoIHRoZSB0YWcgJnF1b3Q7ZW4tQlUmcXVvdDsgKEVuZ2xpc2ggYXMgdXNlZCBpbiBC dXJtYSk8YnI+DQombmJzcDsgbWFpbnRhaW5zIGl0cyB2YWxpZGl0eSwgdGhlIGxhbmd1YWdlIHRh ZyAmcXVvdDtlbi1CVSZxdW90OyBpcyBub3QNCmNhbm9uaWNhbDxicj4NCiZuYnNwOyBiZWNhdXNl IHRoZSAnQlUnIHN1YnRhZyBoYXMgYSBjYW5vbmljYWwgbWFwcGluZyB0byAnTU0nIChNeWFubWFy KS48YnI+DQo8YnI+DQombmJzcDsgQ2Fub25pY2FsaXphdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGRv ZXMgbm90IGltcGx5IGFueXRoaW5nIGFib3V0IHRoZTxicj4NCiZuYnNwOyB1c2Ugb2YgdXBwZXIg b3IgbG93ZXJjYXNlIGxldHRlcnMgd2hlbiBwcm9jZXNzaW5nIG9yIGNvbXBhcmluZzxicj4NCiZu YnNwOyBzdWJ0YWdzIChhbmQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xKS4gJm5ic3A7QWxs IGNvbXBhcmlzb25zIE1VU1QgYmU8YnI+DQombmJzcDsgcGVyZm9ybWVkIGluIGEgY2FzZS1pbnNl bnNpdGl2ZSBtYW5uZXIuPGJyPg0KPGJyPg0KJm5ic3A7IFdoZW4gcGVyZm9ybWluZyBjYW5vbmlj YWxpemF0aW9uIG9mIGxhbmd1YWdlIHRhZ3MsIHByb2Nlc3NvcnMgTUFZPGJyPg0KJm5ic3A7IHJl Z3VsYXJpemUgdGhlIGNhc2Ugb2YgdGhlIHN1YnRhZ3MgKHRoYXQgaXMsIHRoaXMgcHJvY2VzcyBp czxicj4NCiZuYnNwOyBPUFRJT05BTCksIGZvbGxvd2luZyB0aGUgY2FzZSB1c2VkIGluIHRoZSBy ZWdpc3RyeSAoc2VlPGJyPg0KJm5ic3A7IFNlY3Rpb24gMi4xLjEpLjxicj4NCjxicj4NCiZuYnNw OyBJZiBtb3JlIHRoYW4gb25lIHZhcmlhbnQgYXBwZWFycyB3aXRoaW4gYSB0YWcsIHByb2Nlc3Nv cnMgTUFZIHJlb3JkZXI8YnI+DQombmJzcDsgdGhlIHZhcmlhbnRzIHRvIG9idGFpbiBiZXR0ZXIg bWF0Y2hpbmcgYmVoYXZpb3Igb3IgbW9yZSBjb25zaXN0ZW50PGJyPg0KJm5ic3A7IHByZXNlbnRh dGlvbi4gJm5ic3A7UmVvcmRlcmluZyBvZiB0aGUgdmFyaWFudHMgU0hPVUxEIGZvbGxvdyB0aGU8 YnI+DQombmJzcDsgcmVjb21tZW5kYXRpb25zIGZvciB2YXJpYW50IG9yZGVyaW5nIGluIFNlY3Rp b24gNC4xLjxicj4NCjxicj4NCiZuYnNwOyBJZiB0aGUgZmllbGQgJ0RlcHJlY2F0ZWQnIGFwcGVh cnMgaW4gYSByZWdpc3RyeSByZWNvcmQgd2l0aG91dCBhbjxicj4NCiZuYnNwOyBhY2NvbXBhbnlp bmcgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQsIHRoZW4gdGhhdCB0YWcgb3Igc3VidGFnIGlzPGJy Pg0KJm5ic3A7IGRlcHJlY2F0ZWQgd2l0aG91dCBhIHJlcGxhY2VtZW50LiAmbmJzcDtUaGVzZSB2 YWx1ZXMgYXJlIGNhbm9uaWNhbCB3aGVuPGJyPg0KJm5ic3A7IHRoZXkgYXBwZWFyIGluIGEgbGFu Z3VhZ2UgdGFnLiAmbmJzcDtIb3dldmVyLCB0YWdzIHRoYXQgaW5jbHVkZSB0aGVzZTxicj4NCiZu YnNwOyB2YWx1ZXMgU0hPVUxEIE5PVCBiZSBzZWxlY3RlZCBieSB1c2VycyBvciBnZW5lcmF0ZWQg Ynk8YnI+DQombmJzcDsgaW1wbGVtZW50YXRpb25zLjxicj4NCjxicj4NCiZuYnNwOyBBbiBleHRl bnNpb24gTVVTVCBkZWZpbmUgYW55IHJlbGF0aW9uc2hpcHMgdGhhdCBleGlzdCBiZXR3ZWVuIHRo ZTxicj4NCiZuYnNwOyB2YXJpb3VzIHN1YnRhZ3MgaW4gdGhlIGV4dGVuc2lvbiBhbmQgdGh1cyBN QVkgZGVmaW5lIGFuIGFsdGVybmF0ZTxicj4NCiZuYnNwOyBjYW5vbmljYWxpemF0aW9uIHNjaGVt ZSBmb3IgdGhlIGV4dGVuc2lvbidzIHN1YnRhZ3MuICZuYnNwO0V4dGVuc2lvbnMNCk1BWTxicj4N CiZuYnNwOyBkZWZpbmUgaG93IHRoZSBvcmRlciBvZiB0aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncyBh cmUgaW50ZXJwcmV0ZWQuDQombmJzcDtGb3I8YnI+DQombmJzcDsgZXhhbXBsZSwgYW4gZXh0ZW5z aW9uIGNvdWxkIGRlZmluZSB0aGF0IGl0cyBzdWJ0YWdzIGFyZSBpbiBjYW5vbmljYWw8YnI+DQom bmJzcDsgb3JkZXIgd2hlbiB0aGUgc3VidGFncyBhcmUgcGxhY2VkIGludG8gQVNDSUkgb3JkZXI6 IHRoYXQgaXMsICZxdW90O2VuLWEtPGJyPg0KJm5ic3A7IGFhYS1iYmItY2NjJnF1b3Q7IGluc3Rl YWQgb2YgJnF1b3Q7ZW4tYS1jY2MtYmJiLWFhYSZxdW90Oy4gJm5ic3A7QW5vdGhlcg0KZXh0ZW5z aW9uIG1pZ2h0PGJyPg0KJm5ic3A7IGRlZmluZSB0aGF0IHRoZSBvcmRlciBvZiB0aGUgc3VidGFn cyBpbmZsdWVuY2VzIHRoZWlyIHNlbWFudGljPGJyPg0KJm5ic3A7IG1lYW5pbmcgKHNvIHRoYXQg JnF1b3Q7ZW4tYi1jY2MtYmJiLWFhYSZxdW90OyBoYXMgYSBkaWZmZXJlbnQgdmFsdWUgZnJvbQ0K JnF1b3Q7ZW4tYi08YnI+DQombmJzcDsgYWFhLWJiYi1jY2MmcXVvdDspLiAmbmJzcDtIb3dldmVy LCBleHRlbnNpb24gc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGJlDQpkZXNpZ25lZDxicj4NCiZuYnNw OyBzbyB0aGF0IHRoZXkgYXJlIHRvbGVyYW50IG9mIHRoZSB0eXBpY2FsIHByb2Nlc3NlcyBkZXNj cmliZWQgaW48YnI+DQombmJzcDsgU2VjdGlvbiAzLjcuPGJyPg0KPHNwYW4gc3R5bGU9J2NvbG9y OiM4ODg4ODgnPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+DQpBZGRpc29uIFBoaWxs aXBzPGJyPg0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2PGJyPg0KPGJyPg0KSW50 ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS48YnI+DQpJdCBpcyBhbiBhcmNoaXRl Y3R1cmUuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZyI+bHRydS1ib3Vu Y2VzQGlldGYub3JnPC9hPg0KW21haWx0bzo8YSBocmVmPSJtYWlsdG86bHRydS1ib3VuY2VzQGll dGYub3JnIj5sdHJ1LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbjxicj4NCiZndDsgQmVoYWxmIE9m IERvdWcgRXdlbGw8YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMDkgODoz MiBQTTxicj4NCiZndDsgVG86IExUUlUgV29ya2luZyBHcm91cDxicj4NCiZndDsgU3ViamVjdDog UmU6IFtMdHJ1XSBUaWNrZXQgIzQ1OiBBRCBJc3N1ZSAjMTI6IHJlYXNvbiBmb3IgU0hPVUxEIGlu PGJyPg0KJmd0OyA0LjUgZXh0bGFuZyBtYXBwaW5nPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZndDsgTWFy ayBEYXZpcyAmbHQ7bWFyayBhdCBtYWNjaGlhdG8gZG90IGNvbSZndDsgd3JvdGU6PGJyPg0KJmd0 Ozxicj4NCiZndDsgJmd0OyBUaGUgY2hhbmdlcyBhcmUgbWFya2VkIGluIHllbGxvdy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBOb3QgdXNlZnVsIHdoZW4gcmVhZGluZyB0aGUgcGxhaW4tdGV4dCBkaWdl c3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBBIGxhbmd1YWdlIHRhZyBpcyBpbiBjYW5vbmlj YWwgZm9ybSB3aGVuOjxicj4NCiZndDsgJmd0OyAuLi48YnI+DQomZ3Q7ICZndDsgMi4gJm5ic3A7 SXQgaGFzIGJlZW4gY2Fub25pY2FsaXplZCBhY2NvcmRpbmcgdG8gdGhlIGZvbGxvd2luZw0KcHJv Y2Vzczo8YnI+DQomZ3Q7ICZndDsgLi4uPGJyPg0KJmd0OyAmZ3Q7IDIuICZuYnNwO1N1YnRhZ3Mg b2YgdHlwZSAnZXh0bGFuZycgTVVTVCBiZSBtYXBwZWQgdG8gdGhlaXIgUHJlZmVycmVkLTxicj4N CiZndDsgVmFsdWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgQWRkaXNvbiBwb2ludGVkIG91dCwg dGhlIGV4aXN0aW5nIHdvcmRpbmcgd2l0aCBTSE9VTEQgd2FzIGE8YnI+DQomZ3Q7IGNvbXByb21p c2UuICZuYnNwO1RoZSBiYXR0bGUgYmV0d2VlbiBleHRsYW5nIGFuZCBuby1leHRsYW5nIGNhbXBz IHdhczxicj4NCiZndDsgbGVuZ3RoeTxicj4NCiZndDsgYW5kIHBhaW5mdWwsIGFuZCB0aGlzIHdh cyB0aGUgd29yZGluZyB0aGUgV0cgZmluYWxseSBhZ3JlZWQgdXBvbi48YnI+DQomZ3Q7IEk8YnI+ DQomZ3Q7IG9iamVjdCB0byB1c2luZyB0aGUgSUVURiBMYXN0IENhbGwgcHJvY2VzcyB0byB1bmRv IHRoaXMgY29tcHJvbWlzZTxicj4NCiZndDsgYW5kPGJyPg0KJmd0OyBzd2luZyB0aGUgd29yZGlu ZyBiYWNrIGluIGZhdm9yIG9mIHRoZSBuby1leHRsYW5nIHNpZGUuPGJyPg0KJmd0Ozxicj4NCiZn dDsgLS08YnI+DQomZ3Q7IERvdWcgRXdlbGwgJm5ic3A7KiAmbmJzcDtUaG9ybnRvbiwgQ29sb3Jh ZG8sIFVTQSAmbmJzcDsqICZuYnNwO1JGQyA0NjQ1DQombmJzcDsqICZuYnNwO1VUTiAjMTQ8YnI+ DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuZXdlbGxpYy5vcmciIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3LmV3ZWxsaWMub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dzEu aWV0Zi5vcmcvaHRtbC5jaGFydGVycy9sdHJ1LWNoYXJ0ZXIuaHRtbCINCnRhcmdldD0iX2JsYW5r Ij5odHRwOi8vd3d3MS5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sPC9h Pjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlz dGluZm8vaWV0Zi1sYW5ndWFnZXMiDQp0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5hbHZlc3Ry YW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFnZXM8L2E+DQombmJzcDvLhjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgTHRydSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxh IGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PC9h Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KTHRydSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+ THRydUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2x0cnUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rp dj4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1s Pg0K --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE34677EXSEA5Dantama_-- From mark.edward.davis@gmail.com Thu Apr 30 13:52:37 2009 Return-Path: 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 3A3C33A6926 for ; Thu, 30 Apr 2009 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 oywsjcMhkdxI for ; Thu, 30 Apr 2009 13:52:35 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 8B8403A6F7E for ; Thu, 30 Apr 2009 13:52:35 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1619962wff.31 for ; Thu, 30 Apr 2009 13:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=x29G2ddYmW17lsaqzF286gehmTu23MjJhNzDUhqQcfk=; b=pnGG/vISHEfgxNDCVbrsp79zNSCoDWSoZPT9xwW5R0QWU128qkFE2IpZtI9/qtlmUo y3E/QE5fuwLFfukOsOQOjFGDo8TOYX+yDGoJkf9kfAVB16EqLQNUUNeSRaUubn6EGj1D 8dtr6IRV0acMSccTulT9QAU6F5jg5kFz8WylY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=dG6q/9IjJ3jI/NDvCacznp8KTqPM57tP5mXrOz98JXcrEnPh5LpN8Ta3l03LlYp0FV 1koF8tPds+v23jCuNMaGKTy9+/tpTSzC3fMcQilVqoa926+kbBEs56AaOcDPFbevYncB tUztk7CeXTQh/Wm9a9JHn0DdSa7ZvvPtjqvlw= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.14.6 with SMTP id r6mr659080wfi.135.1241124836769; Thu, 30 Apr 2009 13:53:56 -0700 (PDT) In-Reply-To: <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> Date: Thu, 30 Apr 2009 13:53:56 -0700 X-Google-Sender-Auth: 8d132c8ef87bc53f Message-ID: <30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> From: Mark Davis To: Randy Presuhn Content-Type: multipart/alternative; boundary=00504502c74f0481460468cbe5c6 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:52:37 -0000 --00504502c74f0481460468cbe5c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Randy, I agree with you on that text, but it isn't sufficient. Bear with me: This section is setting out requirements: "Assignments to the IANA Language Subtag Registry MUST follow the following stability rules:" The full text of this clause is the following (I inserted a paragraph break for clarity - we should do that in the text also). 16. UN M.49 has codes for both countries and areas (such as '276' for Germany) and geographical regions and sub-regions (such as '150' for Europe). UN M.49 country or area codes for which there is no corresponding ISO 3166-1 code SHOULD NOT be registered, except as a surrogate for an ISO 3166-1 code that is blocked from registration by an existing subtag. If such a code becomes necessary, then the registration authority for ISO 3166-1 SHOULD first be petitioned to assign a code to the region. If the petition for a code assignment by ISO 3166-1 is refused or not acted on in a timely manner, the registration process described in Section 3.5 MAY then be used to register the corresponding UN M.49 code. This way, UN M.49 codes remain available as the value of last resort in cases where ISO 3166-1 reassigns a deprecated value in the registry. The antecedant is "If such a code becomes necessary". If it *IS* necessary, then the first SHOULD needs to be a SHALL (as you say), but also the subsequent MAY needs to turn into a MUST. 2. The use of the passive for SHOULDs and MUSTs and MAYs and so on makes the fulfillment conditions pretty darned obscure. Jumping into a piece of text like this requires exegesis to puzzle out who is responsible for doing what. Based on the text, it appears that the subject of SHOULDs/MUSTs... for this section is normally "Amendments". That is the Amendments MUST (or SHOULD) do something. But in a few cases (like 15E), and in this particular case, because it is not talking about requirements on the amendments but on the LSR, then it should be the following. (Changes are distinguished by indentation, since yellow doesn't work for Doug.) Incorporating both changes: 16. UN M.49 has codes for both countries and areas (such as '276' for Germany) and geographical regions and sub-regions (such as '150' for Europe). UN M.49 country or area codes for which there is no corresponding ISO 3166-1 code SHOULD NOT be registered, except as a surrogate for an ISO 3166-1 code that is blocked from registration by an existing subtag. If such a code becomes necessary, then the Language Subtag Reviewer SHALL petition the registration authority for ISO 3166-1 to assign a code to the region. If the petition for a code assignment by ISO 3166-1 is refused or not acted on in a timely manner, the Language Subtag Reviewer SHALL use the registration process described in Section 3.5 to register the corresponding UN M.49 code. This way, UN M.49 codes remain available as the value of last resort in cases where ISO 3166-1 reassigns a deprecated value in the registry. Mark On Thu, Apr 30, 2009 at 13:26, Randy Presuhn wrote: > Hi - > > As a technical contributor... > > > From: "Phillips, Addison" > > To: "LTRU Working Group" > > Sent: Tuesday, April 28, 2009 9:50 PM > > Subject: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN > M.49 > > > > The AD mentions: > > > > -- > > Comment number 7 from the AD review at > > http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html > > > > 7). In Section 3.4: > > > > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that > > conflict with existing subtags of the associated type, including > > subtags that are deprecated, MUST NOT be entered into the > > registry. The following additional considerations apply to > > subtag values that are reassigned: > > > > [...] > > > > F. For ISO 3166-1 codes, if there is no associated UN numeric > > code, then the Language Subtag Reviewer SHALL petition the > > UN to create one. If there is no response from the UN > > within ninety days of the request being sent, the Language > > Subtag Reviewer SHALL prepare a proposal for entering in the > > IANA registry as soon as practical a registered variant > > subtag as an alternate value for the new code. The form of > > the registered variant subtag will be at the discretion of > > the Language Subtag Reviewer and MUST conform to other > > restrictions on variant subtags in this document. This > > situation is very unlikely to ever occur. > > > > 16. UN M.49 has codes for both countries and areas (such as '276' > > for Germany) and geographical regions and sub-regions (such as > > '150' for Europe). UN M.49 country or area codes for which > > there is no corresponding ISO 3166-1 code SHOULD NOT be > > registered, except as a surrogate for an ISO 3166-1 code that is > > blocked from registration by an existing subtag. If such a code > > becomes necessary, then the registration authority for ISO > > 3166-1 SHOULD > > > > Why SHOULD is used here instead of SHALL? > > Similar text in 15.F says SHALL, which is stronger. > > Also, 15.F specifies expected response time (90 days), which is missing > > below. Any reason why you don't want to specify deadline in this case? > > > > first be petitioned to assign a code to the > > region. If the petition for a code assignment by ISO 3166-1 is > > refused or not acted on in a timely manner, the registration > > process described in Section 3.5 MAY then be used to register > > the corresponding UN M.49 code. This way, UN M.49 codes remain > > available as the value of last resort in cases where ISO 3166-1 > > reassigns a deprecated value in the registry. > > -- > > > > I think the cases are different. > > > > In the former case, BCP 47 requires a UN M.49 code to exist. In the > extremely unlikely event that "we" are the first to notice > that one hasn't been assigned, the LSR is obligated to ask for one. > > > > In the latter case (rule 16) we presume that someone is asking for a UN > M.49 code that has no corresponding ISO 3166 code. This is > not unheard of. It is merely exceptionally rare and typically a Bad Idea to > register exceptionally (hence the recommendation to go > to ISO, etc.). It isn't SHALL because we don't rely on the code for > continued stable operation of the registry. > > > > Proposed resolution: no change. > > I disagree. The context is where a code has become necessary. We have > a policy that essentially amounts to avoiding the numeric codes unless > there > is no alternative. No one has suggested any scenario where it might make > sense to not petition the ISO 3166 registration authority. Maintaining the > policy in an even-handed way suggests to me that we should indeed replace > the sentence currently reading > > If such a code becomes necessary, then the registration authority for > ISO > 3166-1 SHOULD first be petitioned to assign a code to the region. > > with > > If such a code becomes necessary, then the registration authority for > ISO > 3166-1 SHALL first be petitioned to assign a code to the region. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --00504502c74f0481460468cbe5c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Randy, I agree with you on that text, but it isn't sufficient. Bear wit= h me:

This section is setting out requirements: "Assignments to= the IANA Language Subtag Registry MUST follow the following stability rules:"
The full text of this clause is the following (I inserted a paragraph= break for clarity - we should do that in the text also).

   16.  UN M.49 has codes for both countries and areas (such as '276=
9;
        for Germany) and geographical regions and sub-regions (such a=
s
        '150' for Europe).  UN M.49 country or area codes for =
which

        there is no corresponding ISO 3166-1 code SHOULD NOT be
        =
registered, except as a surrogate for an ISO 3166-1 code that is
       =
 blocked from registration by an existing subtag.  

        If such =
a code

        becomes necessary, then the registration authority for ISO
     =
   3166-1 SHOULD first be petitioned to assign a code to the
        reg=
ion.  If the petition for a code assignment by ISO 3166-1 is
        ref=
used or not acted on in a timely manner, the registration

        process described in Section 3.5 MAY then be used to registe=
r
        the corresponding UN M.49 code.  This way, UN M.49 codes remai=
n

        available as the value of last resort in cases where ISO 3166-1
=
        reassigns a deprecated value in the registry.
The anteceda= nt is "If such a code becomes necessary". If it IS necessa= ry, then the first SHOULD needs to be a SHALL (as you say), but also the su= bsequent MAY needs to turn into a MUST.

2. The use of the passive for SHOULDs and MUSTs and MAYs and so on make= s the fulfillment conditions pretty darned obscure. Jumping into a piece of= text like this requires exegesis to puzzle out who is responsible for doin= g what. Based on the text, it appears that the subject of SHOULDs/MUSTs... = for this section is normally "Amendments". That is the Amendments= MUST (or SHOULD) do something. But in a few cases (like 15E), and in this = particular case, because it is not talking about requirements on the amendm= ents but on the LSR, then it should be the following. (Changes are distingu= ished by indentation, since yellow doesn't work for Doug.)

Incorporating both changes:

   16.  UN M.49 has codes for both countries and are=
as (such as '276'
        for Germany) and geographical regions =
and sub-regions (such as
        '150' for Europe).  UN M.49 cou=
ntry or area codes for which

        there is no corresponding ISO 3166-1 code SHOULD NOT be
        =
registered, except as a surrogate for an ISO 3166-1 code that is
       =
 blocked from registration by an existing subtag.

        If such a =
code

        becomes necessary, then the 
Language Subtag Reviewer SHALL peti=
tion the registration authority for ISO
        3166-1
to assign a co=
de to the
        region.  If the petition for a code assignment by ISO =
3166-1 is

        refused or not acted on in a timely manner, the 
Language Subtag=
 Reviewer SHALL use the 
registration
        process described in Section 3.5 

        to register
        the corresponding UN M.49 code.  This way, U=
N M.49 codes remain
        available as the value of last resort in cas=
es where ISO 3166-1
        reassigns a deprecated value in the registry=
.


Mark


On Thu, Apr 30, 2009 at 13:26, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

As a technical contributor...

> From: "Phillips, Addison" <addison@amazon.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Tuesday, April 28, 2009 9:50 PM
> Subject: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. U= N M.49
>
> The AD mentions:
>
> --
> Comment number 7 from the AD review at
> http://www.ietf.org/mail-archive/web/ltru/current/m= sg12399.html
>
> 7). In Section 3.4:
>
> =C2=A0 =C2=A0 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 = that
> =C2=A0 =C2=A0 conflict with existing subtags of the associated type, i= ncluding
> =C2=A0 =C2=A0 subtags that are deprecated, MUST NOT be entered into th= e
> =C2=A0 =C2=A0 registry. The following additional considerations apply = to
> =C2=A0 =C2=A0 subtag values that are reassigned:
>
> =C2=A0 =C2=A0 [...]
>
> =C2=A0 =C2=A0 F. For ISO 3166-1 codes, if there is no associated UN nu= meric
> =C2=A0 =C2=A0 code, then the Language Subtag Reviewer SHALL petition t= he
> =C2=A0 =C2=A0 UN to create one. If there is no response from the UN > =C2=A0 =C2=A0 within ninety days of the request being sent, the Langua= ge
> =C2=A0 =C2=A0 Subtag Reviewer SHALL prepare a proposal for entering in= the
> =C2=A0 =C2=A0 IANA registry as soon as practical a registered variant<= br> > =C2=A0 =C2=A0 subtag as an alternate value for the new code. The form = of
> =C2=A0 =C2=A0 the registered variant subtag will be at the discretion = of
> =C2=A0 =C2=A0 the Language Subtag Reviewer and MUST conform to other > =C2=A0 =C2=A0 restrictions on variant subtags in this document. This > =C2=A0 =C2=A0 situation is very unlikely to ever occur.
>
> =C2=A0 =C2=A0 16. UN M.49 has codes for both countries and areas (such= as '276'
> =C2=A0 =C2=A0 for Germany) and geographical regions and sub-regions (s= uch as
> =C2=A0 =C2=A0 '150' for Europe). UN M.49 country or area codes= for which
> =C2=A0 =C2=A0 there is no corresponding ISO 3166-1 code SHOULD NOT be<= br> > =C2=A0 =C2=A0 registered, except as a surrogate for an ISO 3166-1 code= that is
> =C2=A0 =C2=A0 blocked from registration by an existing subtag. If such= a code
> =C2=A0 =C2=A0 becomes necessary, then the registration authority for I= SO
> =C2=A0 =C2=A0 3166-1 SHOULD
>
> Why SHOULD is used here instead of SHALL?
> Similar text in 15.F says SHALL, which is stronger.
> Also, 15.F specifies expected response time (90 days), which is missin= g
> below. Any reason why you don't want to specify deadline in this c= ase?
>
> =C2=A0 =C2=A0 first be petitioned to assign a code to the
> =C2=A0 =C2=A0 region. If the petition for a code assignment by ISO 316= 6-1 is
> =C2=A0 =C2=A0 refused or not acted on in a timely manner, the registra= tion
> =C2=A0 =C2=A0 process described in Section 3.5 MAY then be used to reg= ister
> =C2=A0 =C2=A0 the corresponding UN M.49 code. This way, UN M.49 codes = remain
> =C2=A0 =C2=A0 available as the value of last resort in cases where ISO= 3166-1
> =C2=A0 =C2=A0 reassigns a deprecated value in the registry.
> --
>
> I think the cases are different.
>
> In the former case, BCP 47 requires a UN M.49 code to exist. In the ex= tremely unlikely event that "we" are the first to notice
that one hasn't been assigned, the LSR is obligated to ask for one.
>
> In the latter case (rule 16) we presume that someone is asking for a U= N M.49 code that has no corresponding ISO 3166 code. This is
not unheard of. It is merely exceptionally rare and typically a Bad Idea to= register exceptionally (hence the recommendation to go
to ISO, etc.). It isn't SHALL because we don't rely on the code for= continued stable operation of the registry.
>
> Proposed resolution: no change.

I disagree. =C2=A0The context is where a code has become necess= ary. =C2=A0We have
a policy that essentially amounts to avoiding the numeric codes unless ther= e
is no alternative. =C2=A0No one has suggested any scenario where it might m= ake
sense to not petition the ISO 3166 registration authority. =C2=A0Maintainin= g the
policy in an even-handed way suggests to me that we should indeed replace the sentence currently reading

=C2=A0 =C2=A0 =C2=A0If such a code becomes necessary, then the registratio= n authority for ISO
=C2=A0 =C2=A0 =C2=A03166-1 SHOULD first be petitioned to assign a co= de to the region.

with

=C2=A0 =C2=A0 =C2=A0If such a code becomes necessary, then the registratio= n authority for ISO
=C2=A0 =C2=A0 =C2=A03166-1 SHALL first be petitioned to assign a cod= e to the region.

Randy


_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--00504502c74f0481460468cbe5c6-- From randy_presuhn@mindspring.com Thu Apr 30 13:54:13 2009 Return-Path: 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 E63153A6FA2 for ; Thu, 30 Apr 2009 13:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 6IXF+6rRraFP for ; Thu, 30 Apr 2009 13:54:13 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 00F363A6F9E for ; Thu, 30 Apr 2009 13:54:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qUau25fAV+CaFcCiKQNd1D4OG5SDTnwNcpR/hQlxho4BcAns7lNcN7ZvBxIw9Wpe; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzdI7-00018Z-Tj for ltru@ietf.org; Thu, 30 Apr 2009 16:55:36 -0400 Message-ID: <017f01c9c9d6$661c8820$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEA7@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 13:58:22 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69689dab77db62a9789454900d681e78ef48350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #44: AD Issue #11: informative reference to MIME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:54:14 -0000 Hi - As co-chair - The proposed solution seems to be in line with the AD request and earlier discussion (April 11-12) so we'll go with the added informative reference and mark this one "closed". http://trac.tools.ietf.org/wg/ltru/trac/ticket/44 Randy ----- Original Message ----- > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Wednesday, April 29, 2009 3:36 PM > Subject: [Ltru] Ticket #44: AD Issue #11: informative reference to MIME > > The AD suggests: > > -- > AD review comment #11 from > http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html > > 11). > > 4.2. Meaning of the Language Tag > > [...] > > o For information objects whose purpose is to provide alternatives, > the associated language tags could be regarded as a hint that the > content is provided in several languages and that one has to > inspect each of the alternatives in order to find its language or > languages. In this case, the presence of multiple tags might not > mean that one needs to be multi-lingual to get complete > understanding of the document. Example: MIME multipart/ > alternative. > > I think this needs an informative reference to MIME. > -- > > Simple enough. > > Proposed resolution: > > Inserted an informative reference to RFC 2046. > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru From addison@amazon.com Thu Apr 30 13:54:20 2009 Return-Path: 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 840AE3A6926 for ; Thu, 30 Apr 2009 13:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.62 X-Spam-Level: X-Spam-Status: No, score=-107.62 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, GB_I_LETTER=-2, 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 aEumYRKFWwbL for ; Thu, 30 Apr 2009 13:54:19 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 007B63A6FB9 for ; Thu, 30 Apr 2009 13:54:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="179276889" Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 20:55:41 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n3UKtedc025805 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 20:55:41 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Thu, 30 Apr 2009 13:55:31 -0700 From: "Phillips, Addison" To: Mark Davis Date: Thu, 30 Apr 2009 13:55:27 -0700 Thread-Topic: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping Thread-Index: AcnJyEkDB9SKnH+yTEaB61L2EkO64gADXXIg Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE3467C@EX-SEA5-D.ant.amazon.com> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> <30b660a20904301217k5c9dc539v566cbb0f2c5f3912@mail.gmail.com> In-Reply-To: <30b660a20904301217k5c9dc539v566cbb0f2c5f3912@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:54:20 -0000 T25lIGFkZGl0aW9uYWwgbm90ZTogcHVyc3VhbnQgdG8geW91ciBjb21tZW50IHRoYXQgcGVvcGxl IGVpdGhlciBNVVNUIG9yIE1VU1QgTk9UIGRvIHRoaW5ncyBpbiBjYW5vbmljYWxpemF0aW9uLCBJ IHRoaW5rIHdlIG5lZWQgdG8gbW9kaWZ5IHRoaXMgdGV4dDoNCg0KLS0NClRoZXNlIG1hcHBpbmdz DQogICAgICBTSE9VTEQgYmUgZG9uZSBiZWZvcmUgYWRkaXRpb25hbCBwcm9jZXNzaW5nLCBzaW5j ZSB0aGVyZSBjYW4gYmUNCiAgICAgIGFkZGl0aW9uYWwgY2hhbmdlcyB0byBzdWJ0YWcgdmFsdWVz LiANCi0tDQoNCi4uIGFuZCByZXF1aXJlIGl0IGFzIHRoZSBmaXJzdCBzdGVwLiBJdCBzaG91bGQg cmVhZDoNCg0KLS0NClRoZXNlIG1hcHBpbmdzIE1VU1QgYmUgZG9uZSBiZWZvcmUgYWRkaXRpb25h bCBwcm9jZXNzaW5nLCBzaW5jZSB0aGVyZSBjYW4gYmUgYWRkaXRpb25hbCBjaGFuZ2VzIHRvIHN1 YnRhZyB2YWx1ZXMuDQotLQ0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4N Ckl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KRnJvbTogbWFyay5lZHdhcmQuZGF2aXNAZ21haWwu Y29tIFttYWlsdG86bWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgTWFy ayBEYXZpcw0KU2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDEyOjE3IFBNDQpUbzogUGhp bGxpcHMsIEFkZGlzb24NCkNjOiBEb3VnIEV3ZWxsOyBMVFJVIFdvcmtpbmcgR3JvdXANClN1Ympl Y3Q6IFJlOiBbTHRydV0gVGlja2V0ICM0NTogQUQgSXNzdWUgIzEyOiByZWFzb24gZm9yIFNIT1VM RCBpbiA0LjUgZXh0bGFuZyBtYXBwaW5nDQoNCg0KTWFyaw0KDQpPbiBUaHUsIEFwciAzMCwgMjAw OSBhdCAwODoyMCwgUGhpbGxpcHMsIEFkZGlzb24gPGFkZGlzb25AYW1hem9uLmNvbT4gd3JvdGU6 DQpPa2F5LCBJJ3ZlIGZpbmlzaGVkIGdlbmVyYXRpbmcgdGhlIG5ldyBkcmFmdCBhbmQgZGlmZmlu ZyBpdC4gT3VyIG9ubHkgcmVtYWluaW5nIG9wZW4gaXRlbSBpcyB0aGlzIGlzc3VlLg0KDQpMYXN0 IG5pZ2h0IEkgcHJvcG9zZWQgZGVmaW5pbmcgdHdvIGNhbm9uaWNhbCBmb3JtcyB0byByZXNvbHZl IHRoZSBtdWRkaW5lc3Mgb2YgIlNIT1VMRCIuIEkgbm93IGhhdmUgYSBzZXBhcmF0ZSBlZGl0b3In cyBjb3B5IG9mIHRoZSBkcmFmdCB3aXRoIGEgcHJvcG9zZWQgZWRpdCB0byBhY2NvbXBsaXNoIHRo aXMuIENvLWNoYWlyIGd1aWRhbmNlIG9uIHRoaXMgaXNzdWUgaXMgdmVyeSBtdWNoIGRlc2lyZWQu DQoNCkJlbG93IGlzIG15IHByb3Bvc2VkIGVkaXRlZCB0ZXh0IGZvciBzZWN0aW9uIDQuNS4gU3Vn Z2VzdGlvbnMgYW5kIGZpeGVzIGFyZSB3ZWxjb21lLiBJbiBwYXJ0aWN1bGFyLCBJIGhhdmVuJ3Qg c2FpZCBhbnl0aGluZyBhYm91dCB3aGVuIHRvIHVzZSB3aGljaCBmb3JtLg0KDQotLQ0KNC41LiDC oENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0KwqAgU2luY2UgYSBwYXJ0aWN1bGFy IGxhbmd1YWdlIHRhZyBpcyBzb21ldGltZXMgdXNlZCBieSBtYW55IHByb2Nlc3NlcywNCsKgIGxh bmd1YWdlIHRhZ3MgU0hPVUxEIGFsd2F5cyBiZSBjcmVhdGVkIG9yIGdlbmVyYXRlZCBpbiBhIGNh bm9uaWNhbA0KwqAgZm9ybS4NCg0KwqAgVGhlcmUgYXJlIHR3byBjYW5vbmljYWwgZm9ybXMgZm9y IGxhbmd1YWdlIHRhZ3MuIMKgVGhlICdkZWZhdWx0Jw0KwqAgY2Fub25pY2FsIGZvcm0gbWFwcyBl YWNoICdleHRsYW5nJyBzdWJ0YWcgdG8gaXRzIFByZWZlcnJlZC1WYWx1ZS4NCsKgIFRoZSAnZXh0 ZW5kZWQnIGNhbm9uaWNhbCBmb3JtIGluY2x1ZGVzIHRoZSBtYWNyb2xhbmd1YWdlIHByaW1hcnkN CsKgIGxhbmd1YWdlIHN1YnRhZyBiZWZvcmUgZWxpZ2libGUgKGV4dGVuZGVkKSBsYW5ndWFnZSBz dWJ0YWdzLg0KDQpJIGFncmVlIHdpdGggdGhlc2UgbmFtZXMuIElmIHdlIGNoYW5nZSB0aGUgbmFt ZSBvZiAnZGVmYXVsdCcgdG8gYW55dGhpbmcgZWxzZSwgd2UnZCBoYXZlIHRvIG1ha2UgYW4gYWRk aXRpb25hbCBjaGFuZ2UgdG8gcHJlc2VydmUgdGhlIGNvbXByb21pc2UgU0hPVUxEIGZyb20gdGhl IHByZXZpb3VzIHRleHQsIHNvbWV0aGluZyBsaWtlOg0KVGhlIGRlZmF1bHQgY2Fub25pY2FsIGZv cm0gU0hPVUxEIG5vcm1hbGx5IGJlIHVzZWQgZm9yIGNhbm9uaWNhbGl6YXRpb24uIFRoZSBleHRl bmRlZCBjYW5vbmljYWwgZm9ybSBtYXkgYmUgdXNlZnVsDQppbiBlbnZpcm9ubWVudHMgd2hlcmUg dGhlIHByZXNlbmNlIG9mIHRoZSBtYWNyb2xhbmd1YWdlIGlzIGJlbmVmaWNpYWwgaW4gbWF0Y2hp bmcgb3Igc2VsZWN0aW9uLg0KDQoNCg0KDQrCoCBBIGxhbmd1YWdlIHRhZyBpcyBpbiBhIGNhbm9u aWNhbCBmb3JtIHdoZW46DQoNCsKgIDEuIMKgVGhlIHRhZyBpcyB3ZWxsLWZvcm1lZCBhY2NvcmRp bmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gMi4xIGFuZA0KwqAgwqAgwqAgU2VjdGlvbiAyLjIuDQoN ClRoaXMgb21pdHMgdGhlIHNpZ25pZmljYW50IGNvbnNpc3RlbmN5IHByb2JsZW0gbXVkZGxpbmcg ZGVmaW5pbmcgYSBjYW5vbmljYWwgZm9ybSwgYW5kIGRlZmluaW5nIHRoZSBwcm9jZXNzIGZvciBj YW5vbmljYWxpemluZy4gUGxlYXNlIGNoYW5nZSB0aGUgbnVtYmVyaW5nL2luZGVudCBmb3IgMi00 IGFuZCBhZGQ6DQogICAyLiAgSXQgaGFzIGJlZW4gY2Fub25pY2FsaXplZCBhY2NvcmRpbmcgdG8g dGhlIGZvbGxvd2luZyBwcm9jZXNzOg0KwqANCg0KDQrCoCAyLiDCoFJlZHVuZGFudCBvciBncmFu ZGZhdGhlcmVkIHRhZ3MgdGhhdCBoYXZlIGEgUHJlZmVycmVkLVZhbHVlDQrCoCDCoCDCoCBtYXBw aW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IChzZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFj ZWQNCsKgIMKgIMKgIHdpdGggdGhlaXIgbWFwcGVkIHZhbHVlLiDCoFRoZXNlIGl0ZW1zIGVpdGhl ciBhcmUgZGVwcmVjYXRlZA0KwqAgwqAgwqAgbWFwcGluZ3MgY3JlYXRlZCBiZWZvcmUgdGhlIGFk b3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKHN1Y2ggYXMNCsKgIMKgIMKgIHRoZSBtYXBwaW5nIG9m ICJuby1ueW4iIHRvICJubiIgb3IgImkta2xpbmdvbiIgdG8gInRsaCIpIG9yIGFyZQ0KwqAgwqAg wqAgdGhlIHJlc3VsdCBvZiBsYXRlciByZWdpc3RyYXRpb25zIG9yIGFkZGl0aW9ucyB0byB0aGlz IGRvY3VtZW50DQrCoCDCoCDCoCAoZm9yIGV4YW1wbGUsICJ6aC1oYWtrYSIgd2FzIGRlcHJlY2F0 ZWQgaW4gZmF2b3Igb2YgdGhlIElTTyA2MzktMw0KwqAgwqAgwqAgY29kZSAnaGFrJyB3aGVuIHRo aXMgZG9jdW1lbnQgd2FzIGFkb3B0ZWQpLiDCoFRoZXNlIG1hcHBpbmdzDQrCoCDCoCDCoCBTSE9V TEQgYmUgZG9uZSBiZWZvcmUgYWRkaXRpb25hbCBwcm9jZXNzaW5nLCBzaW5jZSB0aGVyZSBjYW4g YmUNCsKgIMKgIMKgIGFkZGl0aW9uYWwgY2hhbmdlcyB0byBzdWJ0YWcgdmFsdWVzLiDCoFRoZXNl IGZpZWxkLWJvZHkgb2YgdGhlDQrCoCDCoCDCoCBQcmVmZXJyZWQtVmFsdWUgZm9yIGdyYW5kZmF0 aGVyZWQgYW5kIHJlZHVuZGFudCB0YWdzIGlzIGFuDQrCoCDCoCDCoCAiZXh0ZW5kZWQgbGFuZ3Vh Z2UgcmFuZ2UiIChbUkZDNDY0N10pIGFuZCBtaWdodCBjb25zaXN0IG9mIG1vcmUNCsKgIMKgIMKg IHRoYW4gb25lIHN1YnRhZy4NCsKgIDMuIMKgSW4gdGhlICdkZWZhdWx0JyBjYW5vbmljYWwgZm9y bSwgc3VidGFncyBvZiB0eXBlICdleHRsYW5nJyBNVVNUDQrCoCDCoCDCoCBiZSBtYXBwZWQgdG8g dGhlaXIgUHJlZmVycmVkLVZhbHVlLiDCoFRoZSBmaWVsZC1ib2R5IG9mIHRoZQ0KwqAgwqAgwqAg UHJlZmVycmVkLVZhbHVlIGZvciBleHRsYW5ncyBpcyBhbiAiZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFu Z2UiLA0KwqAgwqAgwqAgdHlwaWNhbGx5IGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgKGluIGFs bCBzdWNoIGNhc2VzLCB0aGUNCsKgIMKgIMKgIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHJl bW92ZWQpLiDCoEZvciBleGFtcGxlLCB0aGUgc3VidGFnDQrCoCDCoCDCoCBzZXF1ZW5jZSAiemgt aGFrIiAoQ2hpbmVzZSwgSGFra2EpIHdvdWxkIGJlIHJlcGxhY2VkIHdpdGggdGhlIHRhZw0KwqAg wqAgwqAgImhhayIgKEhha2thKS4NCsKgIDQuIMKgSW4gdGhlICdleHRlbmRlZCcgY2Fub25pY2Fs IGZvcm0sIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyB3aXRoIGENCsKgIMKgIMKgICdNYWNyb2xh bmd1YWdlJyBmaWVsZCB0aGF0IGFyZSBhbHNvIHJlZ2lzdGVyZWQgYXMgJ2V4dGxhbmcnDQrCoCDC oCDCoCBzdWJ0YWdzIE1VU1QgYmUgcmVwbGFjZWQgYnkgdGhlaXIgbWFjcm9sYW5ndWFnZS1leHRs YW5nDQrCoCDCoCDCoCBjb21iaW5hdGlvbi4gwqBGb3IgZXhhbXBsZSwgdGhlIGxhbmd1YWdlIHRh ZyAiaGFrIiAoSGFra2EpIGhhcyBhDQrCoCDCoCDCoCBNYWNyb2xhbmd1YWdlIG9mICd6aCcgKENo aW5lc2UpIGFuZCBhbiBleGlzdGluZyAnZXh0bGFuZycNCsKgIMKgIMKgIHJlZ2lzdHJhdGlvbi4g wqBUaGUgdGFnIHdvdWxkIGJlIHJlcGxhY2VkIHdpdGggdGhhdCB0YWcgInpoLWhhayINCsKgIMKg IMKgIChDaGluZXNlLCBIYWtrYSkuDQoNCsKgIDUuIMKgT3RoZXIgc3VidGFncyB0aGF0IGhhdmUg YSBQcmVmZXJyZWQtVmFsdWUgZmllbGQgaW4gdGhlIElBTkENCsKgIMKgIMKgIHJlZ2lzdHJ5IChz ZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwZWQNCsKgIMKg IMKgIHZhbHVlLiDCoE1vc3Qgb2YgdGhlc2UgYXJlIGVpdGhlciBSZWdpb24gc3VidGFncyB3aGVy ZSB0aGUgY291bnRyeQ0KwqAgwqAgwqAgbmFtZSBvciBkZXNpZ25hdGlvbiBoYXMgY2hhbmdlZCBv ciBjbGVyaWNhbCBjb3JyZWN0aW9ucyB0byBJU08NCsKgIMKgIMKgIDYzOS0xLg0KwqAgNi4gwqBJ ZiBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2UgZXhpc3RzLCB0aGUgZXh0 ZW5zaW9uwqANCg0KwqAgwqAgwqAgc2VxdWVuY2VzIGFyZSBvcmRlcmVkIGludG8gY2FzZS1pbnNl bnNpdGl2ZSBBU0NJSSBvcmRlciBieQ0KDQpQbGVhc2UgY2hhbmdlICJhcmUgb3JkZXJlZCIgdG8g Ik1VU1QgYmUgb3JkZXJlZCIuIFRoaXMgaXMgbm90IG9wdGlvbmFsIGluIGV4YWN0bHkgdGhlIHNh bWUgc2Vuc2UgYXMgYWxsIHRoZSBvdGhlciBjbGF1c2VzIGFyZSBub3Qgb3B0aW9uYWwuIChUaGF0 IGlzLCB0aGV5IG11c3QgYWxsIGJlICJhcmUiIG9yIGFsbCBiZSAiTVVTVCIuKQ0KDQrCoCDCoCDC oCBzaW5nbGV0b24gc3VidGFnICh0aGF0IGlzLCB0aGUgc3VidGFnIHNlcXVlbmNlICctYS1iYWJi bGUnIGNvbWVzDQrCoCDCoCDCoCBiZWZvcmUgJy1iLXdhcmJsZScpLg0KwqAgRXhhbXBsZTogVGhl IGxhbmd1YWdlIHRhZyAiZW4tYS1hYWEtYi1jY2MtYmJiLXgteHl6IiBpcyBpbiBjYW5vbmljYWwN CsKgIGZvcm0sIHdoaWxlICJlbi1iLWNjYy1iYmItYS1hYWEtWC14eXoiIGlzIHdlbGwtZm9ybWVk IGFuZCBwb3RlbnRpYWxseQ0KwqAgdmFsaWQgKGV4dGVuc2lvbnMgJ2EnIGFuZCAnYicgYXJlIG5v dCBkZWZpbmVkIGFzIG9mIHRoZSBwdWJsaWNhdGlvbg0KwqAgb2YgdGhpcyBkb2N1bWVudCkgYnV0 IG5vdCBpbiBjYW5vbmljYWwgZm9ybSAodGhlIGV4dGVuc2lvbnMgYXJlIG5vdA0KwqAgaW4gYWxw aGFiZXRpY2FsIG9yZGVyKS4NCg0KwqAgRXhhbXBsZTogQWx0aG91Z2ggdGhlIHRhZyAiZW4tQlUi IChFbmdsaXNoIGFzIHVzZWQgaW4gQnVybWEpDQrCoCBtYWludGFpbnMgaXRzIHZhbGlkaXR5LCB0 aGUgbGFuZ3VhZ2UgdGFnICJlbi1CVSIgaXMgbm90IGNhbm9uaWNhbA0KwqAgYmVjYXVzZSB0aGUg J0JVJyBzdWJ0YWcgaGFzIGEgY2Fub25pY2FsIG1hcHBpbmcgdG8gJ01NJyAoTXlhbm1hcikuDQoN CsKgIENhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBkb2VzIG5vdCBpbXBseSBhbnl0 aGluZyBhYm91dCB0aGUNCsKgIHVzZSBvZiB1cHBlciBvciBsb3dlcmNhc2UgbGV0dGVycyB3aGVu IHByb2Nlc3Npbmcgb3IgY29tcGFyaW5nDQrCoCBzdWJ0YWdzIChhbmQgYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gMi4xKS4gwqBBbGwgY29tcGFyaXNvbnMgTVVTVCBiZQ0KwqAgcGVyZm9ybWVkIGlu IGEgY2FzZS1pbnNlbnNpdGl2ZSBtYW5uZXIuDQoNCsKgIFdoZW4gcGVyZm9ybWluZyBjYW5vbmlj YWxpemF0aW9uIG9mIGxhbmd1YWdlIHRhZ3MsIHByb2Nlc3NvcnMgTUFZDQrCoCByZWd1bGFyaXpl IHRoZSBjYXNlIG9mIHRoZSBzdWJ0YWdzICh0aGF0IGlzLCB0aGlzIHByb2Nlc3MgaXMNCsKgIE9Q VElPTkFMKSwgZm9sbG93aW5nIHRoZSBjYXNlIHVzZWQgaW4gdGhlIHJlZ2lzdHJ5IChzZWUNCsKg IFNlY3Rpb24gMi4xLjEpLg0KDQrCoCBJZiBtb3JlIHRoYW4gb25lIHZhcmlhbnQgYXBwZWFycyB3 aXRoaW4gYSB0YWcsIHByb2Nlc3NvcnMgTUFZIHJlb3JkZXINCsKgIHRoZSB2YXJpYW50cyB0byBv YnRhaW4gYmV0dGVyIG1hdGNoaW5nIGJlaGF2aW9yIG9yIG1vcmUgY29uc2lzdGVudA0KwqAgcHJl c2VudGF0aW9uLiDCoFJlb3JkZXJpbmcgb2YgdGhlIHZhcmlhbnRzIFNIT1VMRCBmb2xsb3cgdGhl DQrCoCByZWNvbW1lbmRhdGlvbnMgZm9yIHZhcmlhbnQgb3JkZXJpbmcgaW4gU2VjdGlvbiA0LjEu DQoNCsKgIElmIHRoZSBmaWVsZCAnRGVwcmVjYXRlZCcgYXBwZWFycyBpbiBhIHJlZ2lzdHJ5IHJl Y29yZCB3aXRob3V0IGFuDQrCoCBhY2NvbXBhbnlpbmcgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQs IHRoZW4gdGhhdCB0YWcgb3Igc3VidGFnIGlzDQrCoCBkZXByZWNhdGVkIHdpdGhvdXQgYSByZXBs YWNlbWVudC4gwqBUaGVzZSB2YWx1ZXMgYXJlIGNhbm9uaWNhbCB3aGVuDQrCoCB0aGV5IGFwcGVh ciBpbiBhIGxhbmd1YWdlIHRhZy4gwqBIb3dldmVyLCB0YWdzIHRoYXQgaW5jbHVkZSB0aGVzZQ0K wqAgdmFsdWVzIFNIT1VMRCBOT1QgYmUgc2VsZWN0ZWQgYnkgdXNlcnMgb3IgZ2VuZXJhdGVkIGJ5 DQrCoCBpbXBsZW1lbnRhdGlvbnMuDQoNCsKgIEFuIGV4dGVuc2lvbiBNVVNUIGRlZmluZSBhbnkg cmVsYXRpb25zaGlwcyB0aGF0IGV4aXN0IGJldHdlZW4gdGhlDQrCoCB2YXJpb3VzIHN1YnRhZ3Mg aW4gdGhlIGV4dGVuc2lvbiBhbmQgdGh1cyBNQVkgZGVmaW5lIGFuIGFsdGVybmF0ZQ0KwqAgY2Fu b25pY2FsaXphdGlvbiBzY2hlbWUgZm9yIHRoZSBleHRlbnNpb24ncyBzdWJ0YWdzLiDCoEV4dGVu c2lvbnMgTUFZDQrCoCBkZWZpbmUgaG93IHRoZSBvcmRlciBvZiB0aGUgZXh0ZW5zaW9uJ3Mgc3Vi dGFncyBhcmUgaW50ZXJwcmV0ZWQuIMKgRm9yDQrCoCBleGFtcGxlLCBhbiBleHRlbnNpb24gY291 bGQgZGVmaW5lIHRoYXQgaXRzIHN1YnRhZ3MgYXJlIGluIGNhbm9uaWNhbA0KwqAgb3JkZXIgd2hl biB0aGUgc3VidGFncyBhcmUgcGxhY2VkIGludG8gQVNDSUkgb3JkZXI6IHRoYXQgaXMsICJlbi1h LQ0KwqAgYWFhLWJiYi1jY2MiIGluc3RlYWQgb2YgImVuLWEtY2NjLWJiYi1hYWEiLiDCoEFub3Ro ZXIgZXh0ZW5zaW9uIG1pZ2h0DQrCoCBkZWZpbmUgdGhhdCB0aGUgb3JkZXIgb2YgdGhlIHN1YnRh Z3MgaW5mbHVlbmNlcyB0aGVpciBzZW1hbnRpYw0KwqAgbWVhbmluZyAoc28gdGhhdCAiZW4tYi1j Y2MtYmJiLWFhYSIgaGFzIGEgZGlmZmVyZW50IHZhbHVlIGZyb20gImVuLWItDQrCoCBhYWEtYmJi LWNjYyIpLiDCoEhvd2V2ZXIsIGV4dGVuc2lvbiBzcGVjaWZpY2F0aW9ucyBTSE9VTEQgYmUgZGVz aWduZWQNCsKgIHNvIHRoYXQgdGhleSBhcmUgdG9sZXJhbnQgb2YgdGhlIHR5cGljYWwgcHJvY2Vz c2VzIGRlc2NyaWJlZCBpbg0KwqAgU2VjdGlvbiAzLjcuDQotLQ0KDQpBZGRpc29uIFBoaWxsaXBz DQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRp b24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBEb3VnIEV3ZWxsDQo+IFNl bnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMDkgODozMiBQTQ0KPiBUbzogTFRSVSBXb3JraW5n IEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gVGlja2V0ICM0NTogQUQgSXNzdWUgIzEyOiBy ZWFzb24gZm9yIFNIT1VMRCBpbg0KPiA0LjUgZXh0bGFuZyBtYXBwaW5nDQo+DQo+IE1hcmsgRGF2 aXMgPG1hcmsgYXQgbWFjY2hpYXRvIGRvdCBjb20+IHdyb3RlOg0KPg0KPiA+IFRoZSBjaGFuZ2Vz IGFyZSBtYXJrZWQgaW4geWVsbG93Lg0KPg0KPiBOb3QgdXNlZnVsIHdoZW4gcmVhZGluZyB0aGUg cGxhaW4tdGV4dCBkaWdlc3QuDQo+DQo+ID4gQSBsYW5ndWFnZSB0YWcgaXMgaW4gY2Fub25pY2Fs IGZvcm0gd2hlbjoNCj4gPiAuLi4NCj4gPiAyLiDCoEl0IGhhcyBiZWVuIGNhbm9uaWNhbGl6ZWQg YWNjb3JkaW5nIHRvIHRoZSBmb2xsb3dpbmcgcHJvY2VzczoNCj4gPiAuLi4NCj4gPiAyLiDCoFN1 YnRhZ3Mgb2YgdHlwZSAnZXh0bGFuZycgTVVTVCBiZSBtYXBwZWQgdG8gdGhlaXIgUHJlZmVycmVk LQ0KPiBWYWx1ZS4NCj4NCj4gQXMgQWRkaXNvbiBwb2ludGVkIG91dCwgdGhlIGV4aXN0aW5nIHdv cmRpbmcgd2l0aCBTSE9VTEQgd2FzIGENCj4gY29tcHJvbWlzZS4gwqBUaGUgYmF0dGxlIGJldHdl ZW4gZXh0bGFuZyBhbmQgbm8tZXh0bGFuZyBjYW1wcyB3YXMNCj4gbGVuZ3RoeQ0KPiBhbmQgcGFp bmZ1bCwgYW5kIHRoaXMgd2FzIHRoZSB3b3JkaW5nIHRoZSBXRyBmaW5hbGx5IGFncmVlZCB1cG9u Lg0KPiBJDQo+IG9iamVjdCB0byB1c2luZyB0aGUgSUVURiBMYXN0IENhbGwgcHJvY2VzcyB0byB1 bmRvIHRoaXMgY29tcHJvbWlzZQ0KPiBhbmQNCj4gc3dpbmcgdGhlIHdvcmRpbmcgYmFjayBpbiBm YXZvciBvZiB0aGUgbm8tZXh0bGFuZyBzaWRlLg0KPg0KPiAtLQ0KPiBEb3VnIEV3ZWxsIMKgKiDC oFRob3JudG9uLCBDb2xvcmFkbywgVVNBIMKgKiDCoFJGQyA0NjQ1IMKgKiDCoFVUTiAjMTQNCj4g aHR0cDovL3d3dy5ld2VsbGljLm9yZw0KPiBodHRwOi8vd3d3MS5pZXRmLm9yZy9odG1sLmNoYXJ0 ZXJzL2x0cnUtY2hhcnRlci5odG1sDQo+IGh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFu L2xpc3RpbmZvL2lldGYtbGFuZ3VhZ2VzIMKgy4YNCj4NCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRy dUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMdHJ1IG1h aWxpbmcgbGlzdA0KTHRydUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sdHJ1DQoNCg== From mark.edward.davis@gmail.com Thu Apr 30 13:55:13 2009 Return-Path: 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 884413A6F8E for ; Thu, 30 Apr 2009 13:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=0.802, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 wDQ920LNLpAK for ; Thu, 30 Apr 2009 13:55:11 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 62FF53A6926 for ; Thu, 30 Apr 2009 13:55:11 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1359153rvb.49 for ; Thu, 30 Apr 2009 13:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=AxKfdDWC/l0imyjKuWzcug+AcaW1Vl4KNC1Eg7kMHAY=; b=FHcEbOnnMmP/Hktb9ccTYrxsmfFv9i5Xu0SNFazoALc4Ow2ZRaXLdIRT71+idIGLkR hNuc2iholNuJ4V9osK38BSxXsi/1i5Ai0azISSeYy5FwDEQ4lv7NqrAKKaN/ve6MfxSW rJQe0Tly87fIUY0GqUhXZtT9lQETJT3qY26rA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Bi2UAZ6gnkNalxJfP+V07UJK1nZ7xuWFUqZZnVmP4BV/Yd4DUHE5hvX2Epqf10iOAk Cwrxs8izFK9pILc+NPBkDBXit6N+Y/6Nn+etrr9c16MhsHEKJUcbhF2BQmgqRSHx0IsB z/4+o0iXCdtXwiml+c/f3BZ0qRUpxuFTThe38= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.44.11 with SMTP id r11mr568461wfr.240.1241124994739; Thu, 30 Apr 2009 13:56:34 -0700 (PDT) In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FE3467C@EX-SEA5-D.ant.amazon.com> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> <30b660a20904301217k5c9dc539v566cbb0f2c5f3912@mail.gmail.com> <4D25F22093241741BC1D0EEBC2DBB1DA019FE3467C@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 13:56:34 -0700 X-Google-Sender-Auth: 6e43f3a685ee469b Message-ID: <30b660a20904301356t373a59d1qb895d4defdce301@mail.gmail.com> From: Mark Davis To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=000e0cd311a26eefaa0468cbee9d Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:55:13 -0000 --000e0cd311a26eefaa0468cbee9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed, good catch. Mark On Thu, Apr 30, 2009 at 13:55, Phillips, Addison wrote= : > One additional note: pursuant to your comment that people either MUST or > MUST NOT do things in canonicalization, I think we need to modify this te= xt: > > -- > These mappings > SHOULD be done before additional processing, since there can be > additional changes to subtag values. > -- > > .. and require it as the first step. It should read: > > -- > These mappings MUST be done before additional processing, since there can > be additional changes to subtag values. > -- > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On > Behalf Of Mark Davis > Sent: Thursday, April 30, 2009 12:17 PM > To: Phillips, Addison > Cc: Doug Ewell; LTRU Working Group > Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 > extlang mapping > > > Mark > > On Thu, Apr 30, 2009 at 08:20, Phillips, Addison > wrote: > Okay, I've finished generating the new draft and diffing it. Our only > remaining open item is this issue. > > Last night I proposed defining two canonical forms to resolve the muddine= ss > of "SHOULD". I now have a separate editor's copy of the draft with a > proposed edit to accomplish this. Co-chair guidance on this issue is very > much desired. > > Below is my proposed edited text for section 4.5. Suggestions and fixes a= re > welcome. In particular, I haven't said anything about when to use which > form. > > -- > 4.5. Canonicalization of Language Tags > Since a particular language tag is sometimes used by many processes, > language tags SHOULD always be created or generated in a canonical > form. > > There are two canonical forms for language tags. The 'default' > canonical form maps each 'extlang' subtag to its Preferred-Value. > The 'extended' canonical form includes the macrolanguage primary > language subtag before eligible (extended) language subtags. > > I agree with these names. If we change the name of 'default' to anything > else, we'd have to make an additional change to preserve the compromise > SHOULD from the previous text, something like: > The default canonical form SHOULD normally be used for canonicalization. > The extended canonical form may be useful > in environments where the presence of the macrolanguage is beneficial in > matching or selection. > > > > > A language tag is in a canonical form when: > > 1. The tag is well-formed according the rules in Section 2.1 and > Section 2.2. > > This omits the significant consistency problem muddling defining a > canonical form, and defining the process for canonicalizing. Please chang= e > the numbering/indent for 2-4 and add: > 2. It has been canonicalized according to the following process: > > > > 2. Redundant or grandfathered tags that have a Preferred-Value > mapping in the IANA registry (see Section 3.1) MUST be replaced > with their mapped value. These items either are deprecated > mappings created before the adoption of this document (such as > the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are > the result of later registrations or additions to this document > (for example, "zh-hakka" was deprecated in favor of the ISO 639-3 > code 'hak' when this document was adopted). These mappings > SHOULD be done before additional processing, since there can be > additional changes to subtag values. These field-body of the > Preferred-Value for grandfathered and redundant tags is an > "extended language range" ([RFC4647]) and might consist of more > than one subtag. > 3. In the 'default' canonical form, subtags of type 'extlang' MUST > be mapped to their Preferred-Value. The field-body of the > Preferred-Value for extlangs is an "extended language range", > typically a primary language subtag (in all such cases, the > primary language subtag is removed). For example, the subtag > sequence "zh-hak" (Chinese, Hakka) would be replaced with the tag > "hak" (Hakka). > 4. In the 'extended' canonical form, primary language subtags with a > 'Macrolanguage' field that are also registered as 'extlang' > subtags MUST be replaced by their macrolanguage-extlang > combination. For example, the language tag "hak" (Hakka) has a > Macrolanguage of 'zh' (Chinese) and an existing 'extlang' > registration. The tag would be replaced with that tag "zh-hak" > (Chinese, Hakka). > > 5. Other subtags that have a Preferred-Value field in the IANA > registry (see Section 3.1) MUST be replaced with their mapped > value. Most of these are either Region subtags where the country > name or designation has changed or clerical corrections to ISO > 639-1. > 6. If more than one extension subtag sequence exists, the extension > > sequences are ordered into case-insensitive ASCII order by > > Please change "are ordered" to "MUST be ordered". This is not optional in > exactly the same sense as all the other clauses are not optional. (That i= s, > they must all be "are" or all be "MUST".) > > singleton subtag (that is, the subtag sequence '-a-babble' comes > before '-b-warble'). > Example: The language tag "en-a-aaa-b-ccc-bbb-x-xyz" is in canonical > form, while "en-b-ccc-bbb-a-aaa-X-xyz" is well-formed and potentially > valid (extensions 'a' and 'b' are not defined as of the publication > of this document) but not in canonical form (the extensions are not > in alphabetical order). > > Example: Although the tag "en-BU" (English as used in Burma) > maintains its validity, the language tag "en-BU" is not canonical > because the 'BU' subtag has a canonical mapping to 'MM' (Myanmar). > > Canonicalization of language tags does not imply anything about the > use of upper or lowercase letters when processing or comparing > subtags (and as described in Section 2.1). All comparisons MUST be > performed in a case-insensitive manner. > > When performing canonicalization of language tags, processors MAY > regularize the case of the subtags (that is, this process is > OPTIONAL), following the case used in the registry (see > Section 2.1.1). > > If more than one variant appears within a tag, processors MAY reorder > the variants to obtain better matching behavior or more consistent > presentation. Reordering of the variants SHOULD follow the > recommendations for variant ordering in Section 4.1. > > If the field 'Deprecated' appears in a registry record without an > accompanying 'Preferred-Value' field, then that tag or subtag is > deprecated without a replacement. These values are canonical when > they appear in a language tag. However, tags that include these > values SHOULD NOT be selected by users or generated by > implementations. > > An extension MUST define any relationships that exist between the > various subtags in the extension and thus MAY define an alternate > canonicalization scheme for the extension's subtags. Extensions MAY > define how the order of the extension's subtags are interpreted. For > example, an extension could define that its subtags are in canonical > order when the subtags are placed into ASCII order: that is, "en-a- > aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". Another extension might > define that the order of the subtags influences their semantic > meaning (so that "en-b-ccc-bbb-aaa" has a different value from "en-b- > aaa-bbb-ccc"). However, extension specifications SHOULD be designed > so that they are tolerant of the typical processes described in > Section 3.7. > -- > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > > Behalf Of Doug Ewell > > Sent: Wednesday, April 29, 2009 8:32 PM > > To: LTRU Working Group > > Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in > > 4.5 extlang mapping > > > > Mark Davis wrote: > > > > > The changes are marked in yellow. > > > > Not useful when reading the plain-text digest. > > > > > A language tag is in canonical form when: > > > ... > > > 2. It has been canonicalized according to the following process: > > > ... > > > 2. Subtags of type 'extlang' MUST be mapped to their Preferred- > > Value. > > > > As Addison pointed out, the existing wording with SHOULD was a > > compromise. The battle between extlang and no-extlang camps was > > lengthy > > and painful, and this was the wording the WG finally agreed upon. > > I > > object to using the IETF Last Call process to undo this compromise > > and > > swing the wording back in favor of the no-extlang side. > > > > -- > > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > > http://www.ewellic.org > > http://www1.ietf.org/html.charters/ltru-charter.html > > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > --000e0cd311a26eefaa0468cbee9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed, good catch.

Mark


On Thu, Apr 30, 2009 at 13:55, Phillips,= Addison <addiso= n@amazon.com> wrote:
One additional note: pursuant to your comment that people either MUST or MU= ST NOT do things in canonicalization, I think we need to modify this text:<= br>
--
These mappings
=C2=A0 =C2=A0 =C2=A0SHOULD be done before additional processing, since the= re can be
=C2=A0 =C2=A0 =C2=A0additional changes to subtag values.
--

.. and require it as the first step. It should read:

--
These mappings MUST be done before additional processing, since there can b= e additional changes to subtag values.
--

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark Davis
Sent: Thursday, April 30, 2009 12:17 PM
To: Phillips, Addison
Cc: Doug Ewell; LTRU Working Group
Subject: Re: [Ltru] Ticket #45: AD Issue = #12: reason for SHOULD in 4.5 extlang mapping


Mark

On Thu, Apr 30, 2009 at 08:20, Phillips, Addison <addison@amazon.com> wrote:
Okay, I've finished generating the new draft and diffing it. Our only r= emaining open item is this issue.

Last night I proposed defining two canonical forms to resolve the muddiness= of "SHOULD". I now have a separate editor's copy of the draf= t with a proposed edit to accomplish this. Co-chair guidance on this issue = is very much desired.

Below is my proposed edited text for section 4.5. Suggestions and fixes are= welcome. In particular, I haven't said anything about when to use whic= h form.

--
4.5. =C2=A0Canonicalization of Language Tags
=C2=A0 Since a particular language tag is sometimes used by many processes,=
=C2=A0 language tags SHOULD always be created or generated in a canonical =C2=A0 form.

=C2=A0 There are two canonical forms for language tags. =C2=A0The 'defa= ult'
=C2=A0 canonical form maps each 'extlang' subtag to its Preferred-V= alue.
=C2=A0 The 'extended' canonical form includes the macrolanguage pri= mary
=C2=A0 language subtag before eligible (extended) language subtags.

I agree with these names. If we change the name of 'default' to any= thing else, we'd have to make an additional change to preserve the comp= romise SHOULD from the previous text, something like:
The default canonical form SHOULD normally be used for canonicalization. Th= e extended canonical form may be useful
in environments where the presence of the macrolanguage is beneficial in ma= tching or selection.




=C2=A0 A language tag is in a canonical form when:

=C2=A0 1. =C2=A0The tag is well-formed according the rules in Section 2.1 a= nd
=C2=A0 =C2=A0 =C2=A0 Section 2.2.

This omits the significant consistency problem muddling defining a canonica= l form, and defining the process for canonicalizing. Please change the numb= ering/indent for 2-4 and add:
=C2=A0 2. =C2=A0It has been canonicalized according to the following proce= ss:
=C2=A0


=C2=A0 2. =C2=A0Redundant or grandfathered tags that have a Preferred-Value=
=C2=A0 =C2=A0 =C2=A0 mapping in the IANA registry (see Section 3.1) MUST be= replaced
=C2=A0 =C2=A0 =C2=A0 with their mapped value. =C2=A0These items either are = deprecated
=C2=A0 =C2=A0 =C2=A0 mappings created before the adoption of this document = (such as
=C2=A0 =C2=A0 =C2=A0 the mapping of "no-nyn" to "nn" or= "i-klingon" to "tlh") or are
=C2=A0 =C2=A0 =C2=A0 the result of later registrations or additions to this= document
=C2=A0 =C2=A0 =C2=A0 (for example, "zh-hakka" was deprecated in f= avor of the ISO 639-3
=C2=A0 =C2=A0 =C2=A0 code 'hak' when this document was adopted). = =C2=A0These mappings
=C2=A0 =C2=A0 =C2=A0 SHOULD be done before additional processing, since the= re can be
=C2=A0 =C2=A0 =C2=A0 additional changes to subtag values. =C2=A0These field= -body of the
=C2=A0 =C2=A0 =C2=A0 Preferred-Value for grandfathered and redundant tags i= s an
=C2=A0 =C2=A0 =C2=A0 "extended language range" ([RFC4647]) and mi= ght consist of more
=C2=A0 =C2=A0 =C2=A0 than one subtag.
=C2=A0 3. =C2=A0In the 'default' canonical form, subtags of type &#= 39;extlang' MUST
=C2=A0 =C2=A0 =C2=A0 be mapped to their Preferred-Value. =C2=A0The field-bo= dy of the
=C2=A0 =C2=A0 =C2=A0 Preferred-Value for extlangs is an "extended lang= uage range",
=C2=A0 =C2=A0 =C2=A0 typically a primary language subtag (in all such cases= , the
=C2=A0 =C2=A0 =C2=A0 primary language subtag is removed). =C2=A0For example= , the subtag
=C2=A0 =C2=A0 =C2=A0 sequence "zh-hak" (Chinese, Hakka) would be = replaced with the tag
=C2=A0 =C2=A0 =C2=A0 "hak" (Hakka).
=C2=A0 4. =C2=A0In the 'extended' canonical form, primary language = subtags with a
=C2=A0 =C2=A0 =C2=A0 'Macrolanguage' field that are also registered= as 'extlang'
=C2=A0 =C2=A0 =C2=A0 subtags MUST be replaced by their macrolanguage-extlan= g
=C2=A0 =C2=A0 =C2=A0 combination. =C2=A0For example, the language tag "= ;hak" (Hakka) has a
=C2=A0 =C2=A0 =C2=A0 Macrolanguage of 'zh' (Chinese) and an existin= g 'extlang'
=C2=A0 =C2=A0 =C2=A0 registration. =C2=A0The tag would be replaced with tha= t tag "zh-hak"
=C2=A0 =C2=A0 =C2=A0 (Chinese, Hakka).

=C2=A0 5. =C2=A0Other subtags that have a Preferred-Value field in the IANA=
=C2=A0 =C2=A0 =C2=A0 registry (see Section 3.1) MUST be replaced with their= mapped
=C2=A0 =C2=A0 =C2=A0 value. =C2=A0Most of these are either Region subtags w= here the country
=C2=A0 =C2=A0 =C2=A0 name or designation has changed or clerical correction= s to ISO
=C2=A0 =C2=A0 =C2=A0 639-1.
=C2=A0 6. =C2=A0If more than one extension subtag sequence exists, the exte= nsion=C2=A0

=C2=A0 =C2=A0 =C2=A0 sequences are ordered into case-insensitive ASCII orde= r by

Please change "are ordered" to "MUST be ordered". This = is not optional in exactly the same sense as all the other clauses are not = optional. (That is, they must all be "are" or all be "MUST&q= uot;.)

=C2=A0 =C2=A0 =C2=A0 singleton subtag (that is, the subtag sequence '-a= -babble' comes
=C2=A0 =C2=A0 =C2=A0 before '-b-warble').
=C2=A0 Example: The language tag "en-a-aaa-b-ccc-bbb-x-xyz" is in= canonical
=C2=A0 form, while "en-b-ccc-bbb-a-aaa-X-xyz" is well-formed and = potentially
=C2=A0 valid (extensions 'a' and 'b' are not defined as of = the publication
=C2=A0 of this document) but not in canonical form (the extensions are not<= br> =C2=A0 in alphabetical order).

=C2=A0 Example: Although the tag "en-BU" (English as used in Burm= a)
=C2=A0 maintains its validity, the language tag "en-BU" is not ca= nonical
=C2=A0 because the 'BU' subtag has a canonical mapping to 'MM&#= 39; (Myanmar).

=C2=A0 Canonicalization of language tags does not imply anything about the<= br> =C2=A0 use of upper or lowercase letters when processing or comparing
=C2=A0 subtags (and as described in Section 2.1). =C2=A0All comparisons MUS= T be
=C2=A0 performed in a case-insensitive manner.

=C2=A0 When performing canonicalization of language tags, processors MAY =C2=A0 regularize the case of the subtags (that is, this process is
=C2=A0 OPTIONAL), following the case used in the registry (see
=C2=A0 Section 2.1.1).

=C2=A0 If more than one variant appears within a tag, processors MAY reorde= r
=C2=A0 the variants to obtain better matching behavior or more consistent =C2=A0 presentation. =C2=A0Reordering of the variants SHOULD follow the
=C2=A0 recommendations for variant ordering in Section 4.1.

=C2=A0 If the field 'Deprecated' appears in a registry record witho= ut an
=C2=A0 accompanying 'Preferred-Value' field, then that tag or subta= g is
=C2=A0 deprecated without a replacement. =C2=A0These values are canonical w= hen
=C2=A0 they appear in a language tag. =C2=A0However, tags that include thes= e
=C2=A0 values SHOULD NOT be selected by users or generated by
=C2=A0 implementations.

=C2=A0 An extension MUST define any relationships that exist between the =C2=A0 various subtags in the extension and thus MAY define an alternate =C2=A0 canonicalization scheme for the extension's subtags. =C2=A0Exten= sions MAY
=C2=A0 define how the order of the extension's subtags are interpreted.= =C2=A0For
=C2=A0 example, an extension could define that its subtags are in canonical=
=C2=A0 order when the subtags are placed into ASCII order: that is, "e= n-a-
=C2=A0 aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". =C2=A0Ano= ther extension might
=C2=A0 define that the order of the subtags influences their semantic
=C2=A0 meaning (so that "en-b-ccc-bbb-aaa" has a different value = from "en-b-
=C2=A0 aaa-bbb-ccc"). =C2=A0However, extension specifications SHOULD b= e designed
=C2=A0 so that they are tolerant of the typical processes described in
=C2=A0 Section 3.7.
--

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On
> Behalf Of Doug Ewell
> Sent: Wednesday, April 29, 2009 8:32 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in
> 4.5 extlang mapping
>
> Mark Davis <mark at macchiato dot com> wrote:
>
> > The changes are marked in yellow.
>
> Not useful when reading the plain-text digest.
>
> > A language tag is in canonical form when:
> > ...
> > 2. =C2=A0It has been canonicalized according to the following pro= cess:
> > ...
> > 2. =C2=A0Subtags of type 'extlang' MUST be mapped to thei= r Preferred-
> Value.
>
> As Addison pointed out, the existing wording with SHOULD was a
> compromise. =C2=A0The battle between extlang and no-extlang camps was<= br> > lengthy
> and painful, and this was the wording the WG finally agreed upon.
> I
> object to using the IETF Last Call process to undo this compromise
> and
> swing the wording back in favor of the no-extlang side.
>
> --
> Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 464= 5 =C2=A0* =C2=A0UTN #14
> http://www.ewelli= c.org
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages =C2=A0=CB=86
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru


--000e0cd311a26eefaa0468cbee9d-- From randy_presuhn@mindspring.com Thu Apr 30 13:59:19 2009 Return-Path: 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 199FB3A6FE3 for ; Thu, 30 Apr 2009 13:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 wIMGgrh4baVa for ; Thu, 30 Apr 2009 13:59:18 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 333AE3A6FA2 for ; Thu, 30 Apr 2009 13:59:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OVnmeZm144xu+Kcbdy7PH+CJWrx/lj0ozuvOQDZDHNmN1y4a+LDxU/iLgQ/uuQXK; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzdN3-0003uy-1c for ltru@ietf.org; Thu, 30 Apr 2009 17:00:41 -0400 Message-ID: <018701c9c9d7$1c1a3140$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> <30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> Date: Thu, 30 Apr 2009 14:03:27 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968d4a5d8e9821ab19e0a4a2ec706070449350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:59:19 -0000 Hi - As a technical contributor... I agree with Mark's analysis, including the insertion of a paragraph break. (FWIW, "yellow" also doesn't work for me.) Randy > From: "Mark Davis" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Thursday, April 30, 2009 1:53 PM > Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 ... > Incorporating both changes: > > 16. UN M.49 has codes for both countries and areas (such as '276' > for Germany) and geographical regions and sub-regions (such as > '150' for Europe). UN M.49 country or area codes for which > there is no corresponding ISO 3166-1 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166-1 code that is > blocked from registration by an existing subtag. > > If such a code > becomes necessary, then the > Language Subtag Reviewer SHALL petition the registration authority for ISO > 3166-1 > to assign a code to the > region. If the petition for a code assignment by ISO 3166-1 is > refused or not acted on in a timely manner, the > Language Subtag Reviewer SHALL use the > registration > process described in Section 3.5 > > to register > the corresponding UN M.49 code. This way, UN M.49 codes remain > available as the value of last resort in cases where ISO 3166-1 > reassigns a deprecated value in the registry. > > > > Mark ... From addison@amazon.com Thu Apr 30 14:00:02 2009 Return-Path: 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 7684E3A6FA2 for ; Thu, 30 Apr 2009 14:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 j4pJxCp6se5D for ; Thu, 30 Apr 2009 14:00:01 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id 7ACC13A6FF4 for ; Thu, 30 Apr 2009 14:00:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208,217";a="216428347" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 21:01:22 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3UL1Mfq016942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 21:01:22 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Thu, 30 Apr 2009 14:01:22 -0700 From: "Phillips, Addison" To: Mark Davis , Randy Presuhn Date: Thu, 30 Apr 2009 14:01:19 -0700 Thread-Topic: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 Thread-Index: AcnJ1cwwYFyEkixSSEm9UzPWnFPOSQAAIQvQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34693@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> <30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> In-Reply-To: <30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE34693EXSEA5Dantama_" MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:00:02 -0000 --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE34693EXSEA5Dantama_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlIHBldGl0aW9uIGZvciBhIGNvZGUgYXNzaWdubWVudCBieSBJU08gMzE2Ni0xIGlzDQoN CiAgICAgICAgcmVmdXNlZCBvciBub3QgYWN0ZWQgb24gaW4gYSB0aW1lbHkgbWFubmVyLCB0aGUg cmVnaXN0cmF0aW9uDQoNCg0KDQoNCg0KICAgICAgICBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDMuNTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx0cnUtNDY0NmJp cy0yMSNzZWN0aW9uLTMuNT4gTUFZIHRoZW4gYmUgdXNlZCB0byByZWdpc3Rlcg0KDQogICAgICAg IHRoZSBjb3JyZXNwb25kaW5nIFVOIE0uNDkgY29kZS4gIFRoaXMgd2F5LCBVTiBNLjQ5IGNvZGVz IHJlbWFpbg0KDQoNCg0KDQoNCiAgICAgICAgYXZhaWxhYmxlIGFzIHRoZSB2YWx1ZSBvZiBsYXN0 IHJlc29ydCBpbiBjYXNlcyB3aGVyZSBJU08gMzE2Ni0xDQoNCiAgICAgICAgcmVhc3NpZ25zIGEg ZGVwcmVjYXRlZCB2YWx1ZSBpbiB0aGUgcmVnaXN0cnkuDQpUaGUgYW50ZWNlZGFudCBpcyAiSWYg c3VjaCBhIGNvZGUgYmVjb21lcyBuZWNlc3NhcnkiLiBJZiBpdCBJUyBuZWNlc3NhcnksIHRoZW4g dGhlIGZpcnN0IFNIT1VMRCBuZWVkcyB0byBiZSBhIFNIQUxMIChhcyB5b3Ugc2F5KSwgYnV0IGFs c28gdGhlIHN1YnNlcXVlbnQgTUFZIG5lZWRzIHRvIHR1cm4gaW50byBhIE1VU1QuDQoNCkFkZGlz b24+IEFjdHVhbGx5LCB3ZSBzaG91bGQgbXV0YXRlIHRoZSDigJxNQVnigJ0gdG8gYmUgYSByZWd1 bGFyIEVuZ2xpc2ggdmVyYiDigJxjYW7igJ0sIHdoaWNoIGlzIHRoZSBpbnRlbmRlZCBtZWFuaW5n LCBJIGJlbGlldmUuDQoNCg0KMi4gVGhlIHVzZSBvZiB0aGUgcGFzc2l2ZSBmb3IgU0hPVUxEcyBh bmQgTVVTVHMgYW5kIE1BWXMgYW5kIHNvIG9uIG1ha2VzIHRoZSBmdWxmaWxsbWVudCBjb25kaXRp b25zIHByZXR0eSBkYXJuZWQgb2JzY3VyZS4gSnVtcGluZyBpbnRvIGEgcGllY2Ugb2YgdGV4dCBs aWtlIHRoaXMgcmVxdWlyZXMgZXhlZ2VzaXMgdG8gcHV6emxlIG91dCB3aG8gaXMgcmVzcG9uc2li bGUgZm9yIGRvaW5nIHdoYXQuIEJhc2VkIG9uIHRoZSB0ZXh0LCBpdCBhcHBlYXJzIHRoYXQgdGhl IHN1YmplY3Qgb2YgU0hPVUxEcy9NVVNUcy4uLiBmb3IgdGhpcyBzZWN0aW9uIGlzIG5vcm1hbGx5 ICJBbWVuZG1lbnRzIi4gVGhhdCBpcyB0aGUgQW1lbmRtZW50cyBNVVNUIChvciBTSE9VTEQpIGRv IHNvbWV0aGluZy4gQnV0IGluIGEgZmV3IGNhc2VzIChsaWtlIDE1RSksIGFuZCBpbiB0aGlzIHBh cnRpY3VsYXIgY2FzZSwgYmVjYXVzZSBpdCBpcyBub3QgdGFsa2luZyBhYm91dCByZXF1aXJlbWVu dHMgb24gdGhlIGFtZW5kbWVudHMgYnV0IG9uIHRoZSBMU1IsIHRoZW4gaXQgc2hvdWxkIGJlIHRo ZSBmb2xsb3dpbmcuIChDaGFuZ2VzIGFyZSBkaXN0aW5ndWlzaGVkIGJ5IGluZGVudGF0aW9uLCBz aW5jZSB5ZWxsb3cgZG9lc24ndCB3b3JrIGZvciBEb3VnLikNCg0KQWRkaXNvbj4gVGhlIExTUiBj YW7igJl0IGJlIHJlcXVpcmVkIHRvIGRvIHRoaXMuIFRoZSBsaWtlbHkgY2FzZSB3b3VsZCBiZSBm b3Igc29tZSBwZXJzb24gd2hvIHdhbnRzL25lZWRzIGEgcmVnaW9uIGNvZGUgKGhlbmNlIHRoZSDi gJxuZWNlc3NpdHnigJ0pLiBJIHRoaW5rIG15IHNvbHV0aW9uIChhIHNpbXBsZSBvbmUgd29yZCBj aGFuZ2UgdG8g4oCYY2Fu4oCZKSBwbHVzIFJhbmR54oCZcyDigJxTSEFMTOKAnSBpcyBzdWZmaWNp ZW50Lg0KDQpBZGRpc29uDQo= --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE34693EXSEA5Dantama_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDMgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlBNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAz IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBQTWluZ0xpVSI7DQoJcGFub3NlLTE6MiAyIDMgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6 MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5TZWN0 aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K IDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFu Zz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxwcmU+SWYgdGhlIHBldGl0aW9uIGZvciBhIGNvZGUg YXNzaWdubWVudCBieSBJU08gMzE2Ni0xIGlzPGJyPg0KwqAgwqDCoMKgwqDCoMKgcmVmdXNlZCBv ciBub3QgYWN0ZWQgb24gaW4gYSB0aW1lbHkgbWFubmVyLCB0aGUgcmVnaXN0cmF0aW9uPGJyPg0K PGJyPg0KPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoMKgIHByb2Nlc3MgZGVzY3Jp YmVkIGluIDxhDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx0 cnUtNDY0NmJpcy0yMSNzZWN0aW9uLTMuNSI+U2VjdGlvbiAzLjU8L2E+IE1BWSB0aGVuIGJlIHVz ZWQgdG8gcmVnaXN0ZXI8YnI+DQrCoMKgwqDCoMKgwqDCoCB0aGUgY29ycmVzcG9uZGluZyBVTiBN LjQ5IGNvZGUuwqAgVGhpcyB3YXksIFVOIE0uNDkgY29kZXMgcmVtYWluPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoMKgIGF2YWlsYWJsZSBhcyB0aGUgdmFsdWUg b2YgbGFzdCByZXNvcnQgaW4gY2FzZXMgd2hlcmUgSVNPIDMxNjYtMTxicj4NCsKgwqDCoMKgwqDC oMKgIHJlYXNzaWducyBhIGRlcHJlY2F0ZWQgdmFsdWUgaW4gdGhlIHJlZ2lzdHJ5LjxvOnA+PC9v OnA+PC9wcmU+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPlRoZSBhbnRlY2VkYW50IGlzICZxdW90O0lmIHN1Y2gNCmEgY29kZSBiZWNvbWVzIG5lY2Vz c2FyeSZxdW90Oy4gSWYgaXQgPGI+SVM8L2I+IG5lY2Vzc2FyeSwgdGhlbiB0aGUgZmlyc3QNClNI T1VMRCBuZWVkcyB0byBiZSBhIFNIQUxMIChhcyB5b3Ugc2F5KSwgYnV0IGFsc28gdGhlIHN1YnNl cXVlbnQgTUFZIG5lZWRzIHRvDQp0dXJuIGludG8gYSBNVVNULjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0K Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BZGRpc29uJmd0OyBBY3R1 YWxseSwgd2UNCnNob3VsZCBtdXRhdGUgdGhlIOKAnE1BWeKAnSB0byBiZSBhIHJlZ3VsYXIgRW5n bGlzaCB2ZXJiIOKAnGNhbuKAnSwgd2hpY2ggaXMgdGhlIGludGVuZGVkDQptZWFuaW5nLCBJIGJl bGlldmUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0KPGJyPg0KMi4gVGhlIHVzZSBvZiB0aGUgcGFz c2l2ZSBmb3IgU0hPVUxEcyBhbmQgTVVTVHMgYW5kIE1BWXMgYW5kIHNvIG9uIG1ha2VzIHRoZQ0K ZnVsZmlsbG1lbnQgY29uZGl0aW9ucyBwcmV0dHkgZGFybmVkIG9ic2N1cmUuIEp1bXBpbmcgaW50 byBhIHBpZWNlIG9mIHRleHQgbGlrZQ0KdGhpcyByZXF1aXJlcyBleGVnZXNpcyB0byBwdXp6bGUg b3V0IHdobyBpcyByZXNwb25zaWJsZSBmb3IgZG9pbmcgd2hhdC4gQmFzZWQNCm9uIHRoZSB0ZXh0 LCBpdCBhcHBlYXJzIHRoYXQgdGhlIHN1YmplY3Qgb2YgU0hPVUxEcy9NVVNUcy4uLiBmb3IgdGhp cyBzZWN0aW9uDQppcyBub3JtYWxseSAmcXVvdDtBbWVuZG1lbnRzJnF1b3Q7LiBUaGF0IGlzIHRo ZSBBbWVuZG1lbnRzIE1VU1QgKG9yIFNIT1VMRCkgZG8NCnNvbWV0aGluZy4gQnV0IGluIGEgZmV3 IGNhc2VzIChsaWtlIDE1RSksIGFuZCBpbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgYmVjYXVzZQ0K aXQgaXMgbm90IHRhbGtpbmcgYWJvdXQgcmVxdWlyZW1lbnRzIG9uIHRoZSBhbWVuZG1lbnRzIGJ1 dCBvbiB0aGUgTFNSLCB0aGVuIGl0DQpzaG91bGQgYmUgdGhlIGZvbGxvd2luZy4gKENoYW5nZXMg YXJlIGRpc3Rpbmd1aXNoZWQgYnkgaW5kZW50YXRpb24sIHNpbmNlDQp5ZWxsb3cgZG9lc24ndCB3 b3JrIGZvciBEb3VnLik8c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+QWRkaXNvbiZndDsgVGhlIExTUiBjYW7igJl0IGJlDQpyZXF1aXJl ZCB0byBkbyB0aGlzLiBUaGUgbGlrZWx5IGNhc2Ugd291bGQgYmUgZm9yIHNvbWUgcGVyc29uIHdo byB3YW50cy9uZWVkcyBhDQpyZWdpb24gY29kZSAoaGVuY2UgdGhlIOKAnG5lY2Vzc2l0eeKAnSku IEkgdGhpbmsgbXkgc29sdXRpb24gKGEgc2ltcGxlIG9uZSB3b3JkDQpjaGFuZ2UgdG8g4oCYY2Fu 4oCZKSBwbHVzIFJhbmR54oCZcyDigJxTSEFMTOKAnSBpcyBzdWZmaWNpZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEy LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5BZGRp c29uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4N Cg0KPC9odG1sPg0K --_000_4D25F22093241741BC1D0EEBC2DBB1DA019FE34693EXSEA5Dantama_-- From addison@amazon.com Thu Apr 30 14:02:13 2009 Return-Path: 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 8A1363A6885 for ; Thu, 30 Apr 2009 14:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.645 X-Spam-Level: X-Spam-Status: No, score=-106.645 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 YAOJ82HQSgxQ for ; Thu, 30 Apr 2009 14:02:12 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id ED1CC3A6870 for ; Thu, 30 Apr 2009 14:02:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="179280573" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 21:03:34 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n3UL3Yoo027954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 21:03:34 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Thu, 30 Apr 2009 14:03:33 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 14:03:31 -0700 Thread-Topic: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 Thread-Index: AcnJ1rwv4gLml29dRX+8yk2RoLjYGQAAD5gg Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE3469A@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> <30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> <018701c9c9d7$1c1a3140$6801a8c0@oemcomputer> In-Reply-To: <018701c9c9d7$1c1a3140$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:02:13 -0000 KGFzIGVkaXRvcikNCg0KSSBoYXZlIGluc2VydGVkIHRoZSBwYXJhZ3JhcGggYnJlYWsuIEkgaGF2 ZSBub3QgaW1wbGVtZW50ZWQgb3RoZXIgY2hhbmdlcyB5ZXQsIHBlbmRpbmcgYSBjby1jaGFpciBk ZXRlcm1pbmF0aW9uIChzaW5jZSBJIGp1c3QgZml2ZSBzZWNvbmRzIGFnbyBzZW50IGFuIGVtYWls IHN1Z2dlc3Rpbmcgc29tZXRoaW5nIGRpZmZlcmVudCA6LSkgKS4gDQoNCkFkZGlzb24NCg0KQWRk aXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVy bmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUu DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBS YW5keSBQcmVzdWhuDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAzMCwgMjAwOSAyOjAzIFBNDQo+ IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBUaWNrZXQgIzQw OiBBRCBJc3N1ZSAjNzogc2VjdGlvbiAzLjQgb24gSVNPDQo+IDMxNjYgdnMuIFVOIE0uNDkNCj4g DQo+IEhpIC0NCj4gDQo+IEFzIGEgdGVjaG5pY2FsIGNvbnRyaWJ1dG9yLi4uDQo+IA0KPiBJIGFn cmVlIHdpdGggTWFyaydzIGFuYWx5c2lzLCBpbmNsdWRpbmcgdGhlIGluc2VydGlvbiBvZg0KPiBh IHBhcmFncmFwaCBicmVhay4gIChGV0lXLCAieWVsbG93IiBhbHNvIGRvZXNuJ3Qgd29yayBmb3Ig bWUuKQ0KPiANCj4gUmFuZHkNCj4gDQo+ID4gRnJvbTogIk1hcmsgRGF2aXMiIDxtYXJrQG1hY2No aWF0by5jb20+DQo+ID4gVG86ICJSYW5keSBQcmVzdWhuIiA8cmFuZHlfcHJlc3VobkBtaW5kc3By aW5nLmNvbT4NCj4gPiBDYzogIkxUUlUgV29ya2luZyBHcm91cCIgPGx0cnVAaWV0Zi5vcmc+DQo+ ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDE6NTMgUE0NCj4gPiBTdWJqZWN0OiBS ZTogW0x0cnVdIFRpY2tldCAjNDA6IEFEIElzc3VlICM3OiBzZWN0aW9uIDMuNCBvbiBJU08NCj4g MzE2NiB2cy4gVU4gTS40OQ0KPiAuLi4NCj4gPiBJbmNvcnBvcmF0aW5nIGJvdGggY2hhbmdlczoN Cj4gPg0KPiA+ICAgIDE2LiAgVU4gTS40OSBoYXMgY29kZXMgZm9yIGJvdGggY291bnRyaWVzIGFu ZCBhcmVhcyAoc3VjaCBhcw0KPiAnMjc2Jw0KPiA+ICAgICAgICAgZm9yIEdlcm1hbnkpIGFuZCBn ZW9ncmFwaGljYWwgcmVnaW9ucyBhbmQgc3ViLXJlZ2lvbnMNCj4gKHN1Y2ggYXMNCj4gPiAgICAg ICAgICcxNTAnIGZvciBFdXJvcGUpLiAgVU4gTS40OSBjb3VudHJ5IG9yIGFyZWEgY29kZXMgZm9y DQo+IHdoaWNoDQo+ID4gICAgICAgICB0aGVyZSBpcyBubyBjb3JyZXNwb25kaW5nIElTTyAzMTY2 LTEgY29kZSBTSE9VTEQgTk9UIGJlDQo+ID4gICAgICAgICByZWdpc3RlcmVkLCBleGNlcHQgYXMg YSBzdXJyb2dhdGUgZm9yIGFuIElTTyAzMTY2LTEgY29kZQ0KPiB0aGF0IGlzDQo+ID4gICAgICAg ICBibG9ja2VkIGZyb20gcmVnaXN0cmF0aW9uIGJ5IGFuIGV4aXN0aW5nIHN1YnRhZy4NCj4gPg0K PiA+ICAgICAgICAgSWYgc3VjaCBhIGNvZGUNCj4gPiAgICAgICAgIGJlY29tZXMgbmVjZXNzYXJ5 LCB0aGVuIHRoZQ0KPiA+IExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBTSEFMTCBwZXRpdGlvbiB0 aGUgcmVnaXN0cmF0aW9uDQo+IGF1dGhvcml0eSBmb3IgSVNPDQo+ID4gICAgICAgICAzMTY2LTEN Cj4gPiB0byBhc3NpZ24gYSBjb2RlIHRvIHRoZQ0KPiA+ICAgICAgICAgcmVnaW9uLiAgSWYgdGhl IHBldGl0aW9uIGZvciBhIGNvZGUgYXNzaWdubWVudCBieSBJU08NCj4gMzE2Ni0xIGlzDQo+ID4g ICAgICAgICByZWZ1c2VkIG9yIG5vdCBhY3RlZCBvbiBpbiBhIHRpbWVseSBtYW5uZXIsIHRoZQ0K PiA+IExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBTSEFMTCB1c2UgdGhlDQo+ID4gcmVnaXN0cmF0 aW9uDQo+ID4gICAgICAgICBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNQ0KPiA+IDxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx0cnUtNDY0NmJpcy0yMSNzZWN0 aW9uLQ0KPiAzLjU+DQo+ID4gICAgICAgICB0byByZWdpc3Rlcg0KPiA+ICAgICAgICAgdGhlIGNv cnJlc3BvbmRpbmcgVU4gTS40OSBjb2RlLiAgVGhpcyB3YXksIFVOIE0uNDkgY29kZXMNCj4gcmVt YWluDQo+ID4gICAgICAgICBhdmFpbGFibGUgYXMgdGhlIHZhbHVlIG9mIGxhc3QgcmVzb3J0IGlu IGNhc2VzIHdoZXJlIElTTw0KPiAzMTY2LTENCj4gPiAgICAgICAgIHJlYXNzaWducyBhIGRlcHJl Y2F0ZWQgdmFsdWUgaW4gdGhlIHJlZ2lzdHJ5Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IE1hcmsNCj4g Li4uDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K From randy_presuhn@mindspring.com Thu Apr 30 14:02:24 2009 Return-Path: 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 E9FA23A6767 for ; Thu, 30 Apr 2009 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 uWX5IL2N51sx for ; Thu, 30 Apr 2009 14:02:24 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 2F0A83A6CA5 for ; Thu, 30 Apr 2009 14:02:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VoBhzvXWZY5RWUtck72utdfZKAti/vGua7ZvOKUuQouw5hCoyGCVUsYg9M1Pprfe; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzdQ3-0002Hm-7h for ltru@ietf.org; Thu, 30 Apr 2009 17:03:47 -0400 Message-ID: <019201c9c9d7$8b26d7a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AEBD@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 14:06:33 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968de07551f778a4374b787662b380217ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #46: AD Issue #13: MAY->can in 4.6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:02:25 -0000 Hi - As co-chair... > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Wednesday, April 29, 2009 3:44 PM > Subject: [Ltru] Ticket #46: AD Issue #13: MAY->can in 4.6 ... > Proposed resolution: changed to 'can'. ... We seem to have solid agreement on this resolution, so I've closed the ticket. http://trac.tools.ietf.org/wg/ltru/trac/ticket/46 Randy From randy_presuhn@mindspring.com Thu Apr 30 14:09:30 2009 Return-Path: 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 BDB433A6870 for ; Thu, 30 Apr 2009 14:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 0TnOuxmUpmV8 for ; Thu, 30 Apr 2009 14:09:30 -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 06BA23A6FA0 for ; Thu, 30 Apr 2009 14:09:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lUiz46EkV3Jm9fOq9460uMsWbieomO1Nf31EK1SbKlMnhwVluudYgTNCfcMq9l+0; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzdWu-0001ks-Uq for ltru@ietf.org; Thu, 30 Apr 2009 17:10:53 -0400 Message-ID: <019d01c9c9d8$88836080$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com><00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer><30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> <018701c9c9d7$1c1a3140$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FE3469A@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 14:13:38 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69683c864694c95ea9cfa1d0fb02defea69c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UNM.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:09:30 -0000 Hi - > From: "Phillips, Addison" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Thursday, April 30, 2009 2:03 PM > Subject: RE: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UNM.49 > > (as editor) > > I have inserted the paragraph break. I have not implemented other changes yet, > pending a co-chair determination (since I just five seconds ago sent an email > suggesting something different :-) ). As co-chair... The rationales have been circulated. Let's have a post from the editor of just what he thinks the proposed text alternatives are, labeled (A), (B), etc., since there's been enough enough rapid-fire traffic to make it confusing. Randy From cowan@ccil.org Thu Apr 30 14:09:53 2009 Return-Path: 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 27E6A3A69C6 for ; Thu, 30 Apr 2009 14:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 Hyo3F1GcNsex for ; Thu, 30 Apr 2009 14:09:52 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 709173A6870 for ; Thu, 30 Apr 2009 14:09:52 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LzdXH-0001nl-12 for ltru@ietf.org; Thu, 30 Apr 2009 17:11:15 -0400 Date: Thu, 30 Apr 2009 17:11:15 -0400 To: ltru@ietf.org Message-ID: <20090430211114.GO7401@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Subject: [Ltru] It MUST and SHALL be preserved X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:09:53 -0000 Just to keep things simple, let's change all SHALLs to MUSTs. -- John Cowan cowan@ccil.org http://ccil.org/~cowan You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go! --Gandalf From randy_presuhn@mindspring.com Thu Apr 30 14:14:22 2009 Return-Path: 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 D1EE528C0D9 for ; Thu, 30 Apr 2009 14:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 B5DIE9Zpiet1 for ; Thu, 30 Apr 2009 14:14:22 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 0168C28C0F8 for ; Thu, 30 Apr 2009 14:14:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CXhDe4ty//kKZrRyUxQVOwS4IL1LaUebi230k+MbVDm6j0/UhfyP/ymauWu7WcPt; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lzdbc-00083Z-NS for ltru@ietf.org; Thu, 30 Apr 2009 17:15:44 -0400 Message-ID: <01a401c9c9d9$36c77fa0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AED3@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 14:18:31 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69681df9e46ae4ef2fb0fb7a7a0366f3e982350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #47: AD Issue #14: section 3.1.2 confusing text on replacement tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:14:22 -0000 Hi - As co-chair... > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Wednesday, April 29, 2009 3:53 PM > Subject: [Ltru] Ticket #47: AD Issue #14: section 3.1.2 confusing text on replacement tags ... > Proposed resolution: > > Changed the above text to read: > > -- > For fields of type 'extlang', 'grandfathered', or 'redundant', 'Preferred-Value' > contains an "extended language range" () > that is preferred for forming the language tag. That is, the preferred language > tag will contain, in order, each of the subtags that appears in the Preferred-Value; > additional fields can be included in a language tag as described elsewhere in this > document. > -- ... I think the proposed text addresses the AD's comment and is in line with the WG's intent, so I'm marking this item "closed" http://trac.tools.ietf.org/wg/ltru/trac/ticket/47 Randy From mark.edward.davis@gmail.com Thu Apr 30 14:14:40 2009 Return-Path: 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 963563A680E for ; Thu, 30 Apr 2009 14:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 R2dZ45-BaKmr for ; Thu, 30 Apr 2009 14:14:38 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id ED7913A685D for ; Thu, 30 Apr 2009 14:14:37 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1363771rvb.49 for ; Thu, 30 Apr 2009 14:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=G3b6j9GUkjrK7/6v7XwxC2dluyJ8T5MuVm7fyH+0LWg=; b=KenfUSxHDwIVTt4kLHVDafH7ImIhHL6hsbIWByP3Rg/u7mrhb0c2tZDrb4XPjas+c/ 5UIWOYXmkO2S0X4KFkRzCZCKe2wjzkmVpJMAyRAMZAG9LcT4gXuorMa5BN1tgN/of714 WDsKcERWQfTud1Hdiqh2RPc67ciJvuZkr65V8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=qjw+S7VFn8SrCc8LqsMRj2a4BIic0YV/rDLvhRhfxTZcPMRNRdGeCFcFW+ZuEgERq8 zCgx2HCdxqwRbr77DcYDqYcNvCSBzikoE7eZXz25JiYtpLk/CzbpF6fiul8Q9MXhwQTg ihwLmX4TlTESdO0byqBXwkvw6C0d1nmuEida0= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.12.14 with SMTP id 14mr603967wfl.63.1241126161102; Thu, 30 Apr 2009 14:16:01 -0700 (PDT) In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34677@EX-SEA5-D.ant.amazon.com> References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com> <30b660a20904301217k5c9dc539v566cbb0f2c5f3912@mail.gmail.com> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34677@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 14:16:01 -0700 X-Google-Sender-Auth: 66345ff3ecc839be Message-ID: <30b660a20904301416o5ccee387nce1025f20a1043a0@mail.gmail.com> From: Mark Davis To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=000e0cd2e2d2f439230468cc3393 Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:14:40 -0000 --000e0cd2e2d2f439230468cc3393 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable works for me; comments below. Mark On Thu, Apr 30, 2009 at 13:53, Phillips, Addison wrote= : > Although I agree with your sentiments, I think we can avoid some > additional working group bloodletting by being careful with our wording > choices. I particularly note that RFC 2119 keywords, while have a normati= ve > weight to them, are not the only way to be =E2=80=9Cnormative=E2=80=9D in= a spec. Thus, I > propose to take your suggestion: > > > > -- > > The default canonical form SHOULD normally be used for canonicalization. > The extended canonical form may be useful > > in environments where the presence of the macrolanguage is beneficial in > matching or selection. > > -- > > > > =E2=80=A6 but modified to read=E2=80=A6 > > > > -- > > Normally, the 'default' canonicalization is preferred. However, the > 'extended' canonical form is useful > > in environments where the presence of the macrolanguage is beneficial in > matching or selection (see ).<= /t> > I'm fine with that. My interest is not in further blood-letting, but rather just to preserve the consensus exactly as we have had it, but remove inconsistencies. > -- > > > > In incorporating your proposed changes, I noticed that there was no need > for double- or triple-list embedding. I also note that, since we are > describing a canonicalization process, using 2119 keywords isn=E2=80=99t = necessary. > We can just say =E2=80=9Cdo X=E2=80=9D. > > > > The resulting text reads as: > > > > -- > > A language tag is in a canonical form when the tag is well-formed accordi= ng > the rules in and > > and it has been canonicalized as follows: > > > > > That works also. I prefer definitions in this style. > > > > Redundant or grandfathered tags that have a Preferred-Value mapping in > the IANA registry (see ) are replaced with t= heir > mapped value. These items are either deprecated mappings created before t= he > adoption of this document (such as the mapping of "no-nyn" to "nn" or > "i-klingon" to "tlh") or are the result of later registrations or additio= ns > to this document (for example, "zh-hakka" was deprecated in favor of the = ISO > 639-3 code 'hak' when this document was adopted). These mappings MUST be > done before additional processing, since there can be additional changes = to > subtag values. These field-body of the Preferred-Value for grandfathered = and > redundant tags is an "extended language range" ( target=3D"RFC4647">) and might consist of more than one subtag. > > > > One of the following canonical forms has been applied: > > > > > > > > In the 'default' canonical form, subtags of type 'extlang' are mapped = to > their Preferred-Value. The field-body of the Preferred-Value for extlangs= is > an "extended language range", typically a primary language subtag (in all > such cases, the primary language subtag is removed). For example, the sub= tag > sequence "zh-hak" (Chinese, Hakka) would be replaced with the tag "hak" > (Hakka). > > > > In the 'extended' canonical form, primary language subtags with a > 'Macrolanguage' field that are also registered as 'extlang' subtags are > replaced by their macrolanguage-extlang combination. For example, the > language tag "hak" (Hakka) has a Macrolanguage of 'zh' (Chinese) and an > existing 'extlang' registration. The tag would be replaced with that tag > "zh-hak" (Chinese, Hakka). > > > > > > > > Other subtags that have a Preferred-Value field in the IANA registry > (see ) have been replaced with their mapped > value. Most of these are either Region subtags where the country name or > designation has changed or clerical corrections to ISO 639-1. > > > > If more than one extension subtag sequence exists, the extension > sequences are ordered into case-insensitive ASCII order by singleton subt= ag > (that is, the subtag sequence '-a-babble' comes before '-b-warble'). > > > > > > -- > > > > Addison Phillips > > Globalization Architect -- Lab126 > > > > Internationalization is not a feature. > > It is an architecture. > > > > *From:* mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] = *On > Behalf Of *Mark Davis > *Sent:* Thursday, April 30, 2009 12:17 PM > *To:* Phillips, Addison > *Cc:* Doug Ewell; LTRU Working Group > > *Subject:* Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5 > extlang mapping > > > > > Mark > > On Thu, Apr 30, 2009 at 08:20, Phillips, Addison > wrote: > > Okay, I've finished generating the new draft and diffing it. Our only > remaining open item is this issue. > > Last night I proposed defining two canonical forms to resolve the muddine= ss > of "SHOULD". I now have a separate editor's copy of the draft with a > proposed edit to accomplish this. Co-chair guidance on this issue is very > much desired. > > Below is my proposed edited text for section 4.5. Suggestions and fixes a= re > welcome. In particular, I haven't said anything about when to use which > form. > > -- > > 4.5. Canonicalization of Language Tags > > Since a particular language tag is sometimes used by many processes, > language tags SHOULD always be created or generated in a canonical > form. > > There are two canonical forms for language tags. The 'default' > canonical form maps each 'extlang' subtag to its Preferred-Value. > The 'extended' canonical form includes the macrolanguage primary > language subtag before eligible (extended) language subtags. > > > I agree with these names. If we change the name of 'default' to anything > else, we'd have to make an additional change to preserve the compromise > SHOULD from the previous text, something like: > > The default canonical form SHOULD normally be used for canonicalization. = The extended canonical form may be useful > > in environments where the presence of the macrolanguage is beneficial in = matching or selection. > > > > > > A language tag is in a canonical form when: > > > 1. The tag is well-formed according the rules in Section 2.1 and > Section 2.2. > > > This omits the significant consistency problem muddling defining a > canonical form, and defining the process for canonicalizing. Please chang= e > the numbering/indent for 2-4 and add: > > 2. It has been canonicalized according to the following process: > > > > > > 2. Redundant or grandfathered tags that have a Preferred-Value > mapping in the IANA registry (see Section 3.1) MUST be replaced > with their mapped value. These items either are deprecated > mappings created before the adoption of this document (such as > the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are > the result of later registrations or additions to this document > (for example, "zh-hakka" was deprecated in favor of the ISO 639-3 > code 'hak' when this document was adopted). These mappings > SHOULD be done before additional processing, since there can be > additional changes to subtag values. These field-body of the > Preferred-Value for grandfathered and redundant tags is an > "extended language range" ([RFC4647]) and might consist of more > than one subtag. > > 3. In the 'default' canonical form, subtags of type 'extlang' MUST > be mapped to their Preferred-Value. The field-body of the > Preferred-Value for extlangs is an "extended language range", > typically a primary language subtag (in all such cases, the > primary language subtag is removed). For example, the subtag > > sequence "zh-hak" (Chinese, Hakka) would be replaced with the tag > "hak" (Hakka). > > 4. In the 'extended' canonical form, primary language subtags with a > 'Macrolanguage' field that are also registered as 'extlang' > subtags MUST be replaced by their macrolanguage-extlang > combination. For example, the language tag "hak" (Hakka) has a > Macrolanguage of 'zh' (Chinese) and an existing 'extlang' > registration. The tag would be replaced with that tag "zh-hak" > (Chinese, Hakka). > > 5. Other subtags that have a Preferred-Value field in the IANA > > registry (see Section 3.1) MUST be replaced with their mapped > value. Most of these are either Region subtags where the country > name or designation has changed or clerical corrections to ISO > 639-1. > > 6. If more than one extension subtag sequence exists, the extension > > > > sequences are ordered into case-insensitive ASCII order by > > > Please change "are ordered" to "MUST be ordered". This is not optional in > exactly the same sense as all the other clauses are not optional. (That i= s, > they must all be "are" or all be "MUST".) > > > singleton subtag (that is, the subtag sequence '-a-babble' comes > before '-b-warble'). > > Example: The language tag "en-a-aaa-b-ccc-bbb-x-xyz" is in canonical > form, while "en-b-ccc-bbb-a-aaa-X-xyz" is well-formed and potentially > valid (extensions 'a' and 'b' are not defined as of the publication > of this document) but not in canonical form (the extensions are not > in alphabetical order). > > Example: Although the tag "en-BU" (English as used in Burma) > maintains its validity, the language tag "en-BU" is not canonical > because the 'BU' subtag has a canonical mapping to 'MM' (Myanmar). > > Canonicalization of language tags does not imply anything about the > use of upper or lowercase letters when processing or comparing > subtags (and as described in Section 2.1). All comparisons MUST be > performed in a case-insensitive manner. > > When performing canonicalization of language tags, processors MAY > regularize the case of the subtags (that is, this process is > OPTIONAL), following the case used in the registry (see > Section 2.1.1). > > If more than one variant appears within a tag, processors MAY reorder > the variants to obtain better matching behavior or more consistent > presentation. Reordering of the variants SHOULD follow the > recommendations for variant ordering in Section 4.1. > > If the field 'Deprecated' appears in a registry record without an > accompanying 'Preferred-Value' field, then that tag or subtag is > deprecated without a replacement. These values are canonical when > they appear in a language tag. However, tags that include these > values SHOULD NOT be selected by users or generated by > implementations. > > An extension MUST define any relationships that exist between the > various subtags in the extension and thus MAY define an alternate > canonicalization scheme for the extension's subtags. Extensions MAY > define how the order of the extension's subtags are interpreted. For > example, an extension could define that its subtags are in canonical > order when the subtags are placed into ASCII order: that is, "en-a- > aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". Another extension might > define that the order of the subtags influences their semantic > meaning (so that "en-b-ccc-bbb-aaa" has a different value from "en-b- > aaa-bbb-ccc"). However, extension specifications SHOULD be designed > so that they are tolerant of the typical processes described in > Section 3.7. > -- > > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > > Behalf Of Doug Ewell > > Sent: Wednesday, April 29, 2009 8:32 PM > > To: LTRU Working Group > > Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in > > 4.5 extlang mapping > > > > > Mark Davis wrote: > > > > > The changes are marked in yellow. > > > > Not useful when reading the plain-text digest. > > > > > A language tag is in canonical form when: > > > ... > > > 2. It has been canonicalized according to the following process: > > > ... > > > 2. Subtags of type 'extlang' MUST be mapped to their Preferred- > > Value. > > > > As Addison pointed out, the existing wording with SHOULD was a > > compromise. The battle between extlang and no-extlang camps was > > lengthy > > and painful, and this was the wording the WG finally agreed upon. > > I > > object to using the IETF Last Call process to undo this compromise > > and > > swing the wording back in favor of the no-extlang side. > > > > -- > > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > > http://www.ewellic.org > > http://www1.ietf.org/html.charters/ltru-charter.html > > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > > --000e0cd2e2d2f439230468cc3393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable works for me; comments below.

Mark


On Thu, Apr 30, 2009 at 13:53, Phillips,= Addison <addiso= n@amazon.com> wrote:

Although I agr= ee with your sentiments, I think we can avoid some additional working group bloodletting by being careful with our wording choices. I particularly note that RFC 2119 keywords, while have a normative weight to them, are not the only way to be =E2=80=9Cnormative=E2=80=9D in a= spec. Thus, I propose to take your suggestion:

=C2=A0<= /p>

--

<= div class=3D"im">

The default ca= nonical form SHOULD normally be used for canonicalization. The extended canonical form may be useful

in environment= s where the presence of the macrolanguage is beneficial in matching or selection.

--

=C2=A0<= /p>

=E2=80=A6 but = modified to read=E2=80=A6

=C2=A0<= /p>

--

<t>Norma= lly, the 'default' canonicalization is preferred. However, the 'extended' canonical form is useful

in environment= s where the presence of the macrolanguage is beneficial in matching or selection (see <xref target=3D"choiceUsingExtlang"></xref>).</t>=


I'm fine with that. My interest i= s not in further blood-letting, but rather just to preserve the consensus e= xactly as we have had it, but remove inconsistencies.

--

=C2=A0<= /p>

In incorporati= ng your proposed changes, I noticed that there was no need for double- or triple-list embedding. I also note that, since we ar= e describing a canonicalization process, using 2119 keywords isn=E2=80=99t ne= cessary. We can just say =E2=80=9Cdo X=E2=80=9D.

=C2=A0<= /p>

The resulting = text reads as:

=C2=A0<= /p>

--

A language tag= is in a canonical form when the tag is well-formed according the rules in <xref target=3D"syntax"/>= ; and

<xref targe= t=3D"sources"/> and it has been canonicalized as follows:

=C2=A0 =

=C2=A0<list= style=3D"numbers">

That works also. I prefer definitions in this style.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

<t>Redun= dant or grandfathered tags that have a Preferred-Value mapping in the IANA registry (see <xref target=3D"ianaformat"/>) are replaced with their mapped value.= These items are either deprecated mappings created before the adoption of this document (such as the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are the result of later registrations or additions to this document (for example, "zh-hakka&qu= ot; was deprecated in favor of the ISO 639-3 code 'hak' when this docum= ent was adopted). These mappings MUST be done before additional processing, since t= here can be additional changes to subtag values. These field-body of the Preferred-Value for grandfathered and redundant tags is an "extended language range" (<xref target=3D"RFC4647"></xref>= ;) and might consist of more than one subtag.</t>

=C2=A0<= /p>

<t>One o= f the following canonical forms has been applied:

=C2=A0<= /p>

<list style= =3D"letters">

=C2=A0 =

<t>In th= e 'default' canonical form, subtags of type 'extlang' are mapped to their Preferred-Value. The field-body of th= e Preferred-Value for extlangs is an "extended language range", typically a primary language subtag (in all such cases, the primary languag= e subtag is removed). For example, the subtag sequence "zh-hak" (Chinese, Hakka) would be replaced with the tag "hak" (Hakka).</t>

=C2=A0<= /p>

<t>In th= e 'extended' canonical form, primary language subtags with a 'Macrolanguage' field that are also registered as &#= 39;extlang' subtags are replaced by their macrolanguage-extlang combination. For exampl= e, the language tag "hak" (Hakka) has a Macrolanguage of 'zh'= ; (Chinese) and an existing 'extlang' registration. The tag would be replaced w= ith that tag "zh-hak" (Chinese, Hakka).</t>

=C2=A0<= /p>

</list>&= lt;/t>

=C2=A0<= /p>

<t>Other= subtags that have a Preferred-Value field in the IANA registry (see <xref target=3D"ianaformat"/>) have been= replaced with their mapped value. Most of these are either Region subtags where the country name or designation has changed or clerical corrections to ISO 639-1.</t>

=C2=A0<= /p>

<t>If mo= re than one extension subtag sequence exists, the extension sequences are ordered into case-insensitive ASCII order by single= ton subtag (that is, the subtag sequence '-a-babble' comes before '-b-warb= le').</t>

=C2=A0<= /p>

</list><= /span>

--

=C2=A0<= /p>

Addison Phillip= s

Globalization A= rchitect -- Lab126

=C2=A0

Internationaliz= ation is not a feature.

It is an archit= ecture.

=C2=A0<= /p>

From: mark.edwar= d.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark Davis


Sent: Thursday, April 30, 2009 12:17 PM
To: Phillips, Addison
Cc: Doug Ewell; LTRU Working Group

Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4= .5 extlang mapping

=C2=A0


Mark

On Thu, Apr 30, 2009 at 08:20, Phillips, Addison <addison@amazon.com> wrote:

Okay, I've finished generating the new draft and diffing it. Our only remaining open item is this issue.

Last night I proposed defining two canonical forms to resolve the muddiness= of "SHOULD". I now have a separate editor's copy of the draft wi= th a proposed edit to accomplish this. Co-chair guidance on this issue is very m= uch desired.

Below is my proposed edited text for section 4.5. Suggestions and fixes are welcome. In particular, I haven't said anything about when to use which= form.

--

4.5. =C2=A0Canonicalization of Language Tags

=C2=A0 Since a particular language tag is sometimes used by many processes,
=C2=A0 language tags SHOULD always be created or generated in a canonical =C2=A0 form.

=C2=A0 There are two canonical forms for language tags. =C2=A0The 'defa= ult'
=C2=A0 canonical form maps each 'extlang' subtag to its Preferred-V= alue.
=C2=A0 The 'extended' canonical form includes the macrolanguage pri= mary
=C2=A0 language subtag before eligible (extended) language subtags.


I agree with these names. If we change the name of 'default' to any= thing else, we'd have to make an additional change to preserve the compromise SHOUL= D from the previous text, something like:

The default canonical form S=
HOULD normally be used for canonicalization. The extended canonical form ma=
y be useful


in environments where the presence of the macrolanguage is beneficial in ma=
tching or selection.

=C2=A0



=C2=A0 A language tag is in a canonical form when:


=C2=A0 1. =C2=A0The tag is well-formed according the rules in Section 2.1 a= nd
=C2=A0 =C2=A0 =C2=A0 Section 2.2.


This omits the significant consistency problem muddling defining a canonica= l form, and defining the process for canonicalizing. Please change the numbering/indent for 2-4 and add:

=C2=A0=C2=A0 2.=C2=A0 It has=
 been canonicalized according to the following process:

=C2=A0



=C2=A0 2. =C2=A0Redundant or grandfathered tags that have a Preferred-Value=
=C2=A0 =C2=A0 =C2=A0 mapping in the IANA registry (see Section 3.1) MUST be replaced
=C2=A0 =C2=A0 =C2=A0 with their mapped value. =C2=A0These items either are deprecated
=C2=A0 =C2=A0 =C2=A0 mappings created before the adoption of this document (such as
=C2=A0 =C2=A0 =C2=A0 the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are
=C2=A0 =C2=A0 =C2=A0 the result of later registrations or additions to this document
=C2=A0 =C2=A0 =C2=A0 (for example, "zh-hakka" was deprecated in f= avor of the ISO 639-3
=C2=A0 =C2=A0 =C2=A0 code 'hak' when this document was adopted). = =C2=A0These mappings
=C2=A0 =C2=A0 =C2=A0 SHOULD be done before additional processing, since the= re can be
=C2=A0 =C2=A0 =C2=A0 additional changes to subtag values. =C2=A0These field-body of the
=C2=A0 =C2=A0 =C2=A0 Preferred-Value for grandfathered and redundant tags i= s an
=C2=A0 =C2=A0 =C2=A0 "extended language range" ([RFC4647]) and mi= ght consist of more
=C2=A0 =C2=A0 =C2=A0 than one subtag.

=C2=A0 3. =C2=A0In the 'default' canonical form, subtags of type 'extlang' MUST
=C2=A0 =C2=A0 =C2=A0 be mapped to their Preferred-Value. =C2=A0The field-bo= dy of the
=C2=A0 =C2=A0 =C2=A0 Preferred-Value for extlangs is an "extended lang= uage range",
=C2=A0 =C2=A0 =C2=A0 typically a primary language subtag (in all such cases= , the
=C2=A0 =C2=A0 =C2=A0 primary language subtag is removed). =C2=A0For example= , the subtag

=C2=A0 =C2=A0 =C2=A0 sequence "zh-hak" (Chinese, Hakka) would be replaced with the tag
=C2=A0 =C2=A0 =C2=A0 "hak" (Hakka).

=C2=A0 4. =C2=A0In the 'extended' canonical form, primary language subtags with a
=C2=A0 =C2=A0 =C2=A0 'Macrolanguage' field that are also registered= as 'extlang'
=C2=A0 =C2=A0 =C2=A0 subtags MUST be replaced by their macrolanguage-extlan= g
=C2=A0 =C2=A0 =C2=A0 combination. =C2=A0For example, the language tag "hak" (Hakka) has a
=C2=A0 =C2=A0 =C2=A0 Macrolanguage of 'zh' (Chinese) and an existin= g 'extlang'
=C2=A0 =C2=A0 =C2=A0 registration. =C2=A0The tag would be replaced with tha= t tag "zh-hak"
=C2=A0 =C2=A0 =C2=A0 (Chinese, Hakka).

=C2=A0 5. =C2=A0Other subtags that have a Preferred-Value field in the IANA=

=C2=A0 =C2=A0 =C2=A0 registry (see Section 3.1) MUST be replaced with their mapped
=C2=A0 =C2=A0 =C2=A0 value. =C2=A0Most of these are either Region subtags w= here the country
=C2=A0 =C2=A0 =C2=A0 name or designation has changed or clerical correction= s to ISO
=C2=A0 =C2=A0 =C2=A0 639-1.

=C2=A0 6. =C2=A0If more than one extension subtag sequence exists, the extension=C2=A0

=C2=A0

=C2=A0 =C2=A0 =C2=A0 sequences are ordered into case-insensitive ASCII order by


Please change "are ordered" to "MUST be ordered". This = is not optional in exactly the same sense as all the other clauses are not optional. (That is, they must all be "are" or all be "MUST".)


=C2=A0 =C2=A0 =C2=A0 singleton subtag (that is, the subtag sequence '-a= -babble' comes
=C2=A0 =C2=A0 =C2=A0 before '-b-warble').

=C2=A0 Example: The language tag "en-a-aaa-b-ccc-bbb-x-xyz" is in canonical
=C2=A0 form, while "en-b-ccc-bbb-a-aaa-X-xyz" is well-formed and potentially
=C2=A0 valid (extensions 'a' and 'b' are not defined as of = the publication
=C2=A0 of this document) but not in canonical form (the extensions are not<= br> =C2=A0 in alphabetical order).

=C2=A0 Example: Although the tag "en-BU" (English as used in Burm= a)
=C2=A0 maintains its validity, the language tag "en-BU" is not canonical
=C2=A0 because the 'BU' subtag has a canonical mapping to 'MM&#= 39; (Myanmar).

=C2=A0 Canonicalization of language tags does not imply anything about the<= br> =C2=A0 use of upper or lowercase letters when processing or comparing
=C2=A0 subtags (and as described in Section 2.1). =C2=A0All comparisons MUS= T be
=C2=A0 performed in a case-insensitive manner.

=C2=A0 When performing canonicalization of language tags, processors MAY =C2=A0 regularize the case of the subtags (that is, this process is
=C2=A0 OPTIONAL), following the case used in the registry (see
=C2=A0 Section 2.1.1).

=C2=A0 If more than one variant appears within a tag, processors MAY reorde= r
=C2=A0 the variants to obtain better matching behavior or more consistent =C2=A0 presentation. =C2=A0Reordering of the variants SHOULD follow the
=C2=A0 recommendations for variant ordering in Section 4.1.

=C2=A0 If the field 'Deprecated' appears in a registry record witho= ut an
=C2=A0 accompanying 'Preferred-Value' field, then that tag or subta= g is
=C2=A0 deprecated without a replacement. =C2=A0These values are canonical w= hen
=C2=A0 they appear in a language tag. =C2=A0However, tags that include thes= e
=C2=A0 values SHOULD NOT be selected by users or generated by
=C2=A0 implementations.

=C2=A0 An extension MUST define any relationships that exist between the =C2=A0 various subtags in the extension and thus MAY define an alternate =C2=A0 canonicalization scheme for the extension's subtags. =C2=A0Exten= sions MAY
=C2=A0 define how the order of the extension's subtags are interpreted. =C2=A0For
=C2=A0 example, an extension could define that its subtags are in canonical=
=C2=A0 order when the subtags are placed into ASCII order: that is, "e= n-a-
=C2=A0 aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". =C2=A0Ano= ther extension might
=C2=A0 define that the order of the subtags influences their semantic
=C2=A0 meaning (so that "en-b-ccc-bbb-aaa" has a different value = from "en-b-
=C2=A0 aaa-bbb-ccc"). =C2=A0However, extension specifications SHOULD b= e designed
=C2=A0 so that they are tolerant of the typical processes described in
=C2=A0 Section 3.7.
--


Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: ltru-= bounces@ietf.org [mailto:ltru-bou= nces@ietf.org] On
> Behalf Of Doug Ewell
> Sent: Wednesday, April 29, 2009 8:32 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in
> 4.5 extlang mapping
>

> Mark Davis <mark at macchiato dot com> wrote:
>
> > The changes are marked in yellow.
>
> Not useful when reading the plain-text digest.
>
> > A language tag is in canonical form when:
> > ...
> > 2. =C2=A0It has been canonicalized according to the following process:
> > ...
> > 2. =C2=A0Subtags of type 'extlang' MUST be mapped to thei= r Preferred-
> Value.
>
> As Addison pointed out, the existing wording with SHOULD was a
> compromise. =C2=A0The battle between extlang and no-extlang camps was<= br> > lengthy
> and painful, and this was the wording the WG finally agreed upon.
> I
> object to using the IETF Last Call process to undo this compromise
> and
> swing the wording back in favor of the no-extlang side.
>
> --
> Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 464= 5 =C2=A0* =C2=A0UTN #14
> http://www.ewelli= c.org
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages =C2=A0=CB=86
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

=C2=A0


--000e0cd2e2d2f439230468cc3393-- From addison@amazon.com Thu Apr 30 14:19:27 2009 Return-Path: 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 47B8F3A6767 for ; Thu, 30 Apr 2009 14:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.644 X-Spam-Level: X-Spam-Status: No, score=-106.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 TcrsKfactrzY for ; Thu, 30 Apr 2009 14:19:26 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 2D08D3A6CA5 for ; Thu, 30 Apr 2009 14:19:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="179289099" Received: from smtp-in-0201.sea3.amazon.com ([172.20.19.24]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 21:20:48 +0000 Received: from ex-hub-4103.ant.amazon.com (ex-hub-4103.sea5.amazon.com [10.248.163.24]) by smtp-in-0201.sea3.amazon.com (8.12.11/8.12.11) with ESMTP id n3ULKlNU007827 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 21:20:48 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4103.ant.amazon.com ([10.248.163.24]) with mapi; Thu, 30 Apr 2009 14:20:47 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 14:20:39 -0700 Thread-Topic: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UNM.49 Thread-Index: AcnJ2CuRmriVLXffQNyU2Pe9fksUYAAAEOTw Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE346D3@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com><00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer><30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> <018701c9c9d7$1c1a3140$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FE3469A@EX-SEA5-D.ant.amazon.com> <019d01c9c9d8$88836080$6801a8c0@oemcomputer> In-Reply-To: <019d01c9c9d8$88836080$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UNM.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:19:27 -0000 KGFzIGVkaXRvcikNCg0KSGVyZSBhcmUgdGhlIHByb3Bvc2VkIHRleHRzOg0KDQpBKSAoU0hPVUxE LT5TSEFMTCwgTUFZLT5jYW4pDQoNCjE2LiAgVU4gTS40OSBoYXMgY29kZXMgZm9yIGJvdGggJ2Nv dW50cmllcycgYW5kICdhcmVhcycgKHN1Y2ggYXMNCiAgICAgICAgJzI3NicgZm9yIEdlcm1hbnkp IGFuZCAnZ2VvZ3JhcGhpY2FsIHJlZ2lvbnMnIGFuZCAnc3ViLXJlZ2lvbnMnDQogICAgICAgIChz dWNoIGFzICcxNTAnIGZvciBFdXJvcGUpLiAgVU4gTS40OSAnY291bnRyeScgb3IgJ2FyZWEnIGNv ZGVzDQogICAgICAgIGZvciB3aGljaCB0aGVyZSBpcyBubyBjb3JyZXNwb25kaW5nIElTTyAzMTY2 LTEgY29kZSBNVVNUIE5PVCBiZQ0KICAgICAgICByZWdpc3RlcmVkLCBleGNlcHQgYXMgYSBzdXJy b2dhdGUgZm9yIGFuIElTTyAzMTY2LTEgY29kZSB0aGF0IGlzDQogICAgICAgIGJsb2NrZWQgZnJv bSByZWdpc3RyYXRpb24gYnkgYW4gZXhpc3Rpbmcgc3VidGFnLg0KDQogICAgICAgIElmIHN1Y2gg YSBjb2RlIGJlY29tZXMgbmVjZXNzYXJ5LCB0aGVuIHRoZSByZWdpc3RyYXRpb24NCiAgICAgICAg YXV0aG9yaXR5IGZvciBJU08gMzE2Ni0xIFNIQUxMIGZpcnN0IGJlIHBldGl0aW9uZWQgdG8gYXNz aWduIGENCiAgICAgICAgY29kZSB0byB0aGUgcmVnaW9uLiAgSWYgdGhlIHBldGl0aW9uIGZvciBh IGNvZGUgYXNzaWdubWVudCBieQ0KICAgICAgICBJU08gMzE2Ni0xIGlzIHJlZnVzZWQgb3Igbm90 IGFjdGVkIG9uIGluIGEgdGltZWx5IG1hbm5lciwgdGhlDQogICAgICAgIHJlZ2lzdHJhdGlvbiBw cm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNSBjYW4gdGhlbiBiZSB1c2VkDQogICAgICAg IHRvIHJlZ2lzdGVyIHRoZSBjb3JyZXNwb25kaW5nIFVOIE0uNDkgY29kZS4gIFRoaXMgd2F5LCBV TiBNLjQ5DQogICAgICAgIGNvZGVzIHJlbWFpbiBhdmFpbGFibGUgYXMgdGhlIHZhbHVlIG9mIGxh c3QgcmVzb3J0IGluIGNhc2VzDQogICAgICAgIHdoZXJlIElTTyAzMTY2LTEgcmVhc3NpZ25zIGEg ZGVwcmVjYXRlZCB2YWx1ZSBpbiB0aGUgcmVnaXN0cnkuDQoNCkIpIChTSE9VTEQtPlNIQUxMLCBN QVktPlNIQUxMLCBtYWtlIHRoZSBMU1IgZG8gaXQpDQoNCjE2LiAgVU4gTS40OSBoYXMgY29kZXMg Zm9yIGJvdGggJ2NvdW50cmllcycgYW5kICdhcmVhcycgKHN1Y2ggYXMNCiAgICAgICAgJzI3Nicg Zm9yIEdlcm1hbnkpIGFuZCAnZ2VvZ3JhcGhpY2FsIHJlZ2lvbnMnIGFuZCAnc3ViLXJlZ2lvbnMn DQogICAgICAgIChzdWNoIGFzICcxNTAnIGZvciBFdXJvcGUpLiAgVU4gTS40OSAnY291bnRyeScg b3IgJ2FyZWEnIGNvZGVzDQogICAgICAgIGZvciB3aGljaCB0aGVyZSBpcyBubyBjb3JyZXNwb25k aW5nIElTTyAzMTY2LTEgY29kZSBNVVNUIE5PVCBiZQ0KICAgICAgICByZWdpc3RlcmVkLCBleGNl cHQgYXMgYSBzdXJyb2dhdGUgZm9yIGFuIElTTyAzMTY2LTEgY29kZSB0aGF0IGlzDQogICAgICAg IGJsb2NrZWQgZnJvbSByZWdpc3RyYXRpb24gYnkgYW4gZXhpc3Rpbmcgc3VidGFnLg0KDQogICAg ICAgIElmIHN1Y2ggYSBjb2RlIGJlY29tZXMgbmVjZXNzYXJ5LCB0aGVuIHRoZSBMYW5ndWFnZSBT dWJ0YWcgUmV2aWV3ZXIgDQogICAgICAgIFNIQUxMIHBldGl0aW9uIHRoZSByZWdpc3RyYXRpb24g YXV0aG9yaXR5IGZvciBJU08NCiAgICAgICAgMzE2Ni0xIHRvIGFzc2lnbiBhIGNvZGUgdG8gdGhl IHJlZ2lvbi4gIElmIHRoZSBwZXRpdGlvbiBmb3IgYSANCiAgICAgICAgY29kZSBhc3NpZ25tZW50 IGJ5IElTTyAzMTY2LTEgaXMgcmVmdXNlZCBvciBub3QgYWN0ZWQgb24gaW4gYSANCiAgICAgICAg dGltZWx5IG1hbm5lciwgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBTSEFMTCB1c2UgdGhl DQogICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNSB0 byByZWdpc3Rlcg0KICAgICAgICB0aGUgY29ycmVzcG9uZGluZyBVTiBNLjQ5IGNvZGUuICBUaGlz IHdheSwgVU4gTS40OSBjb2RlcyByZW1haW4NCiAgICAgICAgYXZhaWxhYmxlIGFzIHRoZSB2YWx1 ZSBvZiBsYXN0IHJlc29ydCBpbiBjYXNlcyB3aGVyZSBJU08gMzE2Ni0xDQogICAgICAgIHJlYXNz aWducyBhIGRlcHJlY2F0ZWQgdmFsdWUgaW4gdGhlIHJlZ2lzdHJ5Lg0KDQpDKSAoaW5zZXJ0IHRo ZSBwYXJhIGJyZWFrIGJ1dCBvdGhlcndpc2UgZG8gbm90aGluZykNCg0KMTYuICBVTiBNLjQ5IGhh cyBjb2RlcyBmb3IgYm90aCAnY291bnRyaWVzJyBhbmQgJ2FyZWFzJyAoc3VjaCBhcw0KICAgICAg ICAnMjc2JyBmb3IgR2VybWFueSkgYW5kICdnZW9ncmFwaGljYWwgcmVnaW9ucycgYW5kICdzdWIt cmVnaW9ucycNCiAgICAgICAgKHN1Y2ggYXMgJzE1MCcgZm9yIEV1cm9wZSkuICBVTiBNLjQ5ICdj b3VudHJ5JyBvciAnYXJlYScgY29kZXMNCiAgICAgICAgZm9yIHdoaWNoIHRoZXJlIGlzIG5vIGNv cnJlc3BvbmRpbmcgSVNPIDMxNjYtMSBjb2RlIE1VU1QgTk9UIGJlDQogICAgICAgIHJlZ2lzdGVy ZWQsIGV4Y2VwdCBhcyBhIHN1cnJvZ2F0ZSBmb3IgYW4gSVNPIDMxNjYtMSBjb2RlIHRoYXQgaXMN CiAgICAgICAgYmxvY2tlZCBmcm9tIHJlZ2lzdHJhdGlvbiBieSBhbiBleGlzdGluZyBzdWJ0YWcu DQoNCiAgICAgICAgSWYgc3VjaCBhIGNvZGUgYmVjb21lcyBuZWNlc3NhcnksIHRoZW4gdGhlIHJl Z2lzdHJhdGlvbg0KICAgICAgICBhdXRob3JpdHkgZm9yIElTTyAzMTY2LTEgU0hPVUxEIGZpcnN0 IGJlIHBldGl0aW9uZWQgdG8gYXNzaWduIGENCiAgICAgICAgY29kZSB0byB0aGUgcmVnaW9uLiAg SWYgdGhlIHBldGl0aW9uIGZvciBhIGNvZGUgYXNzaWdubWVudCBieQ0KICAgICAgICBJU08gMzE2 Ni0xIGlzIHJlZnVzZWQgb3Igbm90IGFjdGVkIG9uIGluIGEgdGltZWx5IG1hbm5lciwgdGhlDQog ICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNSBNQVkg dGhlbiBiZSB1c2VkDQogICAgICAgIHRvIHJlZ2lzdGVyIHRoZSBjb3JyZXNwb25kaW5nIFVOIE0u NDkgY29kZS4gIFRoaXMgd2F5LCBVTiBNLjQ5DQogICAgICAgIGNvZGVzIHJlbWFpbiBhdmFpbGFi bGUgYXMgdGhlIHZhbHVlIG9mIGxhc3QgcmVzb3J0IGluIGNhc2VzDQogICAgICAgIHdoZXJlIElT TyAzMTY2LTEgcmVhc3NpZ25zIGEgZGVwcmVjYXRlZCB2YWx1ZSBpbiB0aGUgcmVnaXN0cnkuDQoN Cg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYN Cg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hp dGVjdHVyZS4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVo YWxmIE9mIFJhbmR5IFByZXN1aG4NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDI6 MTQgUE0NCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIFRp Y2tldCAjNDA6IEFEIElzc3VlICM3OiBzZWN0aW9uIDMuNCBvbiBJU08NCj4gMzE2NiB2cy4gVU5N LjQ5DQo+IA0KPiBIaSAtDQo+IA0KPiA+IEZyb206ICJQaGlsbGlwcywgQWRkaXNvbiIgPGFkZGlz b25AYW1hem9uLmNvbT4NCj4gPiBUbzogIlJhbmR5IFByZXN1aG4iIDxyYW5keV9wcmVzdWhuQG1p bmRzcHJpbmcuY29tPjsgIkxUUlUgV29ya2luZw0KPiBHcm91cCIgPGx0cnVAaWV0Zi5vcmc+DQo+ ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDI6MDMgUE0NCj4gPiBTdWJqZWN0OiBS RTogW0x0cnVdIFRpY2tldCAjNDA6IEFEIElzc3VlICM3OiBzZWN0aW9uIDMuNCBvbiBJU08NCj4g MzE2NiB2cy4gVU5NLjQ5DQo+ID4NCj4gPiAoYXMgZWRpdG9yKQ0KPiA+DQo+ID4gSSBoYXZlIGlu c2VydGVkIHRoZSBwYXJhZ3JhcGggYnJlYWsuIEkgaGF2ZSBub3QgaW1wbGVtZW50ZWQgb3RoZXIN Cj4gY2hhbmdlcyB5ZXQsDQo+ID4gcGVuZGluZyBhIGNvLWNoYWlyIGRldGVybWluYXRpb24gKHNp bmNlIEkganVzdCBmaXZlIHNlY29uZHMgYWdvDQo+IHNlbnQgYW4gZW1haWwNCj4gPiBzdWdnZXN0 aW5nIHNvbWV0aGluZyBkaWZmZXJlbnQgOi0pICkuDQo+IA0KPiBBcyBjby1jaGFpci4uLg0KPiAN Cj4gVGhlIHJhdGlvbmFsZXMgaGF2ZSBiZWVuIGNpcmN1bGF0ZWQuICBMZXQncyBoYXZlIGEgcG9z dCBmcm9tIHRoZQ0KPiBlZGl0b3Igb2YganVzdCB3aGF0IGhlIHRoaW5rcyB0aGUgcHJvcG9zZWQg dGV4dCBhbHRlcm5hdGl2ZXMgYXJlLA0KPiBsYWJlbGVkIChBKSwgKEIpLCBldGMuLCBzaW5jZSB0 aGVyZSdzIGJlZW4gZW5vdWdoIGVub3VnaCByYXBpZC1maXJlDQo+IHRyYWZmaWMgdG8gbWFrZSBp dCBjb25mdXNpbmcuDQo+IA0KPiBSYW5keQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== From mark.edward.davis@gmail.com Thu Apr 30 14:25:35 2009 Return-Path: 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 446383A6BA8 for ; Thu, 30 Apr 2009 14:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 P3WMvqcR-7cT for ; Thu, 30 Apr 2009 14:25:33 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id C40483A6857 for ; Thu, 30 Apr 2009 14:25:29 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1629900wff.31 for ; Thu, 30 Apr 2009 14:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=enrV9CWRvAcSOZqMzyvjmRfYppg6NOV4o4ZHp73QTUs=; b=nkeRl78qHM0fhThujJKgkw37+0XHxBpmzXU2WGRwVJu85NutWlGTeEksr5SSyq/S5T mDouei/eAyLY2H+q4uPPnU066BV3rgQsDjVlgTJ31i0LLSzLjDljQLoXnkpERRQ4P0OA 5A4/2OMol31o8lBZu2VerOoNjbhO9ptraqAAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=uEeNWO+Jn9bb4HpPzN3nC8TGq2hrPDMBOzprmtwpE23QsCURvjW79Y2tfyBhEum24P Ek/aNKa9DGub3+GOCMffUhfQX0ahy4DDbdSkhxa2Dwb1PmlmWtZqc3uf2XiFZoZoHboB wce5Na3QVVsqNMYsIbEGSeExIJ/AS4EGamlEk= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.15.14 with SMTP id s14mr581070wfi.313.1241126812992; Thu, 30 Apr 2009 14:26:52 -0700 (PDT) In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FE346D3@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> <30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> <018701c9c9d7$1c1a3140$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FE3469A@EX-SEA5-D.ant.amazon.com> <019d01c9c9d8$88836080$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FE346D3@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 14:26:52 -0700 X-Google-Sender-Auth: 01f84dd8e48a4d47 Message-ID: <30b660a20904301426r605c0fdfn1106ebe419b3afc5@mail.gmail.com> From: Mark Davis To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=001636e1fbd1cf43af0468cc5afc Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UNM.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:25:35 -0000 --001636e1fbd1cf43af0468cc5afc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks for spelling out the options. The old overall structure is: If X is necessary, the LSR SHOULD do Y, and if that doesn't work the LSR MAY do Z. Randy is pointing out that if X is necessary, then the SHOULD must be a MUST. By the same reasoning, the MAY must be a MUST -- because X is necessary. So if we accept Randy's change, we need to be consistent and use text B. The alternative is to do nothing (text C). But both text A and C are bizarre. If X *IS* necessary, then there is no reason not to direct the LSR to do the subsequent steps. And if X *is not* necessary, there is no reason to allow the LSR to do the subsequent steps. So the optionality needs to be out of the equation. Mark On Thu, Apr 30, 2009 at 14:20, Phillips, Addison wrote: > (as editor) > > Here are the proposed texts: > > A) (SHOULD->SHALL, MAY->can) > > 16. UN M.49 has codes for both 'countries' and 'areas' (such as > '276' for Germany) and 'geographical regions' and 'sub-regions' > (such as '150' for Europe). UN M.49 'country' or 'area' codes > for which there is no corresponding ISO 3166-1 code MUST NOT be > registered, except as a surrogate for an ISO 3166-1 code that is > blocked from registration by an existing subtag. > > If such a code becomes necessary, then the registration > authority for ISO 3166-1 SHALL first be petitioned to assign a > code to the region. If the petition for a code assignment by > ISO 3166-1 is refused or not acted on in a timely manner, the > registration process described in Section 3.5 can then be used > to register the corresponding UN M.49 code. This way, UN M.49 > codes remain available as the value of last resort in cases > where ISO 3166-1 reassigns a deprecated value in the registry. > > B) (SHOULD->SHALL, MAY->SHALL, make the LSR do it) > > 16. UN M.49 has codes for both 'countries' and 'areas' (such as > '276' for Germany) and 'geographical regions' and 'sub-regions' > (such as '150' for Europe). UN M.49 'country' or 'area' codes > for which there is no corresponding ISO 3166-1 code MUST NOT be > registered, except as a surrogate for an ISO 3166-1 code that is > blocked from registration by an existing subtag. > > If such a code becomes necessary, then the Language Subtag Reviewer > SHALL petition the registration authority for ISO > 3166-1 to assign a code to the region. If the petition for a > code assignment by ISO 3166-1 is refused or not acted on in a > timely manner, the Language Subtag Reviewer SHALL use the > registration process described in Section 3.5 to register > the corresponding UN M.49 code. This way, UN M.49 codes remain > available as the value of last resort in cases where ISO 3166-1 > reassigns a deprecated value in the registry. > > C) (insert the para break but otherwise do nothing) > > 16. UN M.49 has codes for both 'countries' and 'areas' (such as > '276' for Germany) and 'geographical regions' and 'sub-regions' > (such as '150' for Europe). UN M.49 'country' or 'area' codes > for which there is no corresponding ISO 3166-1 code MUST NOT be > registered, except as a surrogate for an ISO 3166-1 code that is > blocked from registration by an existing subtag. > > If such a code becomes necessary, then the registration > authority for ISO 3166-1 SHOULD first be petitioned to assign a > code to the region. If the petition for a code assignment by > ISO 3166-1 is refused or not acted on in a timely manner, the > registration process described in Section 3.5 MAY then be used > to register the corresponding UN M.49 code. This way, UN M.49 > codes remain available as the value of last resort in cases > where ISO 3166-1 reassigns a deprecated value in the registry. > > > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > > Behalf Of Randy Presuhn > > Sent: Thursday, April 30, 2009 2:14 PM > > To: LTRU Working Group > > Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO > > 3166 vs. UNM.49 > > > > Hi - > > > > > From: "Phillips, Addison" > > > To: "Randy Presuhn" ; "LTRU Working > > Group" > > > Sent: Thursday, April 30, 2009 2:03 PM > > > Subject: RE: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO > > 3166 vs. UNM.49 > > > > > > (as editor) > > > > > > I have inserted the paragraph break. I have not implemented other > > changes yet, > > > pending a co-chair determination (since I just five seconds ago > > sent an email > > > suggesting something different :-) ). > > > > As co-chair... > > > > The rationales have been circulated. Let's have a post from the > > editor of just what he thinks the proposed text alternatives are, > > labeled (A), (B), etc., since there's been enough enough rapid-fire > > traffic to make it confusing. > > > > Randy > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e1fbd1cf43af0468cc5afc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for spelling out the options. The old overall structure is:

If X is necessary, the LSR SHOULD do Y, and if that doesn't work the LS= R MAY do Z.

Randy is pointing out that if X is necessary, then the SHOULD must be a MUST. By the same reasoning, the MAY must be a MUST -- because X is necessary. So if we accept Randy's change, we need to be consistent and= use text B. The alternative is to do nothing (text C).

But both tex= t A and C are bizarre. If X *IS* necessary, then there is no reason not to = direct the LSR to do the subsequent steps. And if X *is not* necessary, the= re is no reason to allow the LSR to do the subsequent steps. So the optiona= lity needs to be out of the equation.

Mark


On Thu, Apr 30, 2009 at 14:20, Phillips,= Addison <addiso= n@amazon.com> wrote:
(as editor)

Here are the proposed texts:

A) (SHOULD->SHALL, MAY->can)

16. =C2=A0UN M.49 has codes for both 'countries' and 'areas'= ; (such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0'276' for Germany) and 'geographica= l regions' and 'sub-regions'
=C2=A0 =C2=A0 =C2=A0 =C2=A0(such as '150' for Europe). =C2=A0UN M.= 49 'country' or 'area' codes
=C2=A0 =C2=A0 =C2=A0 =C2=A0for which there is no corresponding ISO 3= 166-1 code MUST NOT be
=C2=A0 =C2=A0 =C2=A0 =C2=A0registered, except as a surro= gate for an ISO 3166-1 code that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0blocked from registration by an existing subtag= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0If such a code becomes necessary, then th= e registration
=C2=A0 =C2=A0 =C2=A0 =C2=A0authority for ISO 3166-1 SHALL first be petitio= ned to assign a
=C2=A0 =C2=A0 =C2=A0 =C2=A0code to the region. =C2=A0If = the petition for a code assignment by
=C2=A0 =C2=A0 =C2=A0 =C2=A0ISO 3166-1 is refused or not acted on in a time= ly manner, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0registration process described in Section= 3.5 can then be used
=C2=A0 =C2=A0 =C2=A0 =C2=A0to register the corresponding= UN M.49 code. =C2=A0This way, UN M.49
=C2=A0 =C2=A0 =C2=A0 =C2=A0codes remain available as the value of last res= ort in cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0where ISO 3166-1 reassigns a deprecated value i= n the registry.

B) (SHOULD->SHALL, MAY->SHALL, make the LSR do it)

16. =C2=A0UN M.49 has codes for both 'countries' and 'areas'= ; (such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0'276' for Germany) and 'geographica= l regions' and 'sub-regions'
=C2=A0 =C2=A0 =C2=A0 =C2=A0(such as '150' for Europe). =C2=A0UN M.= 49 'country' or 'area' codes
=C2=A0 =C2=A0 =C2=A0 =C2=A0for which there is no corresponding ISO 3= 166-1 code MUST NOT be
=C2=A0 =C2=A0 =C2=A0 =C2=A0registered, except as a surro= gate for an ISO 3166-1 code that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0blocked from registration by an existing subtag= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0If such a code becomes necessary, then the Lang= uage Subtag Reviewer
=C2=A0 =C2=A0 =C2=A0 =C2=A0SHALL petition the registration authority for I= SO
=C2=A0 =C2=A0 =C2=A0 =C2=A03166-1 to assign a code to the region. =C2=A0If= the petition for a
=C2=A0 =C2=A0 =C2=A0 =C2=A0code assignment by ISO 3166-1 is refused or not= acted on in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0timely manner, the Language Subtag Reviewer SHA= LL use the
=C2=A0 =C2=A0 =C2=A0 =C2=A0registration process described in Section= 3.5 to register
=C2=A0 =C2=A0 =C2=A0 =C2=A0the corresponding UN M.49 cod= e. =C2=A0This way, UN M.49 codes remain
=C2=A0 =C2=A0 =C2=A0 =C2=A0available as the value of last resort in cases = where ISO 3166-1
=C2=A0 =C2=A0 =C2=A0 =C2=A0reassigns a deprecated value in the registry.
C) (insert the para break but otherwise do nothing)

16. =C2=A0UN M.49 has codes for both 'countries' and 'areas'= ; (such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0'276' for Germany) and 'geographica= l regions' and 'sub-regions'
=C2=A0 =C2=A0 =C2=A0 =C2=A0(such as '150' for Europe). =C2=A0UN M.= 49 'country' or 'area' codes
=C2=A0 =C2=A0 =C2=A0 =C2=A0for which there is no corresponding ISO 3= 166-1 code MUST NOT be
=C2=A0 =C2=A0 =C2=A0 =C2=A0registered, except as a surro= gate for an ISO 3166-1 code that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0blocked from registration by an existing subtag= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0If such a code becomes necessary, then th= e registration
=C2=A0 =C2=A0 =C2=A0 =C2=A0authority for ISO 3166-1 SHOULD first be petiti= oned to assign a
=C2=A0 =C2=A0 =C2=A0 =C2=A0code to the region. =C2=A0If = the petition for a code assignment by
=C2=A0 =C2=A0 =C2=A0 =C2=A0ISO 3166-1 is refused or not acted on in a time= ly manner, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0registration process described in Section= 3.5 MAY then be used
=C2=A0 =C2=A0 =C2=A0 =C2=A0to register the corresponding= UN M.49 code. =C2=A0This way, UN M.49
=C2=A0 =C2=A0 =C2=A0 =C2=A0codes remain available as the value of last res= ort in cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0where ISO 3166-1 reassigns a deprecated value i= n the registry.



Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On
> Behalf Of Randy Presuhn
> Sent: Thursday, April 30, 2009 2:14 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Ticket #40= : AD Issue #7: section 3.4 on ISO
> 3166 vs. UNM.49
>
> Hi -
>
> > From: "Phillips, Addison" <addison@amazon.com>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>; "LTRU Working > Group" <ltru@ietf.org>=
> > Sent: Thursday, April 30, 2009 2:03 PM
> > Subject: RE: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO > 3166 vs. UNM.49
> >
> > (as editor)
> >
> > I have inserted the paragraph break. I have not implemented other=
> changes yet,
> > pending a co-chair determination (since I just five seconds ago > sent an email
> > suggesting something different :-) ).
>
> As co-chair...
>
> The rationales have been circulated. =C2=A0Let's have a post from = the
> editor of just what he thinks the proposed text alternatives are,
> labeled (A), (B), etc., since there's been enough enough rapid-fir= e
> traffic to make it confusing.
>
> Randy
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e1fbd1cf43af0468cc5afc-- From addison@amazon.com Thu Apr 30 14:26:40 2009 Return-Path: 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 18C693A6C58 for ; Thu, 30 Apr 2009 14:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.643 X-Spam-Level: X-Spam-Status: No, score=-106.643 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 13MlFvSbDsNp for ; Thu, 30 Apr 2009 14:26:39 -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 375E83A6F98 for ; Thu, 30 Apr 2009 14:26:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="260628814" Received: from smtp-in-0201.sea3.amazon.com ([172.20.19.24]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 21:27:24 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-0201.sea3.amazon.com (8.12.11/8.12.11) with ESMTP id n3ULRNRB014451 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 21:27:23 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Thu, 30 Apr 2009 14:27:23 -0700 From: "Phillips, Addison" To: "Phillips, Addison" , Mark Davis , Randy Presuhn Date: Thu, 30 Apr 2009 14:27:21 -0700 Thread-Topic: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 Thread-Index: AcnJ1cwwYFyEkixSSEm9UzPWnFPOSQAAIQvQAABvixA= Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE346F1@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com> <00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer> <30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com> <4D25F22093241741BC1D0EEBC2DBB1DA019FE34693@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34693@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:26:40 -0000 PiBUaGUgTFNSIGNhbuKAmXQgYmUgcmVxdWlyZWQgdG8gZG8gdGhpcy4gVGhlIGxpa2VseSANCj4g Y2FzZSB3b3VsZCBiZSBmb3Igc29tZSBwZXJzb24gd2hvIHdhbnRzL25lZWRzIGEgDQo+IHJlZ2lv biBjb2RlIChoZW5jZSB0aGUg4oCcbmVjZXNzaXR54oCdKS4gSSB0aGluayANCj4gbXkgc29sdXRp b24gKGEgc2ltcGxlIG9uZSB3b3JkIGNoYW5nZSB0byDigJhjYW7igJkpIA0KPiBwbHVzIFJhbmR5 4oCZcyDigJxTSEFMTOKAnSBpcyBzdWZmaWNpZW50Lg0KDQpJIHNob3VsZCBhZGQ6IHRoaXMgd291 bGQgYWxzbyBiZSBjb25zaXN0ZW50IHdpdGggb3VyIHBvbGljeSBvZiBhbGxvd2luZyBhbnlvbmUg dG8gcGVyZm9ybSBhIHJlZ2lzdHJhdGlvbiByZXF1ZXN0Lg0KDQpBZGRpc29uIFBoaWxsaXBzDQpH bG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KDQo= From randy_presuhn@mindspring.com Thu Apr 30 14:27:04 2009 Return-Path: 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 4907D3A6F6D for ; Thu, 30 Apr 2009 14:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 w8pnnpY2J8QC for ; Thu, 30 Apr 2009 14:27:03 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 939493A6BA8 for ; Thu, 30 Apr 2009 14:27:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CeW2Bo1u1e3OzNU+5wtO9UcLO3kTSTGBjw6xLpwvl2frVhq8P2sfu9xLvAmcUINv; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lzdnu-0005ZX-L5 for ltru@ietf.org; Thu, 30 Apr 2009 17:28:26 -0400 Message-ID: <01e301c9c9da$fcba6fa0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <657100D7317F4A2396B2BE40C3F17548@DGBP7M81><4D25F22093241741BC1D0EEBC2DBB1DA019FE34055@EX-SEA5-D.ant.amazon.com><20090430153237.GF15356@mercury.ccil.org><4D25F22093241741BC1D0EEBC2DBB1DA019FE3414C@EX-SEA5-D.ant.amazon.com> <30b660a20904301151h51174b2dk9516fa71032cbe25@mail.gmail.com> Date: Thu, 30 Apr 2009 14:31:12 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968d0f1e47c041e965e7ecfb8999a119dfd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in 4.5extlang mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:27:04 -0000 Hi - As co-chair... I'm concerned about the amount of textual change proposed in resultion of this item. Without prejudicing the merits of these changes, we should recall that the AD's comment merely asked for an explanation of the "SHOULD". I'm reluctant to declare consensus on a change this extensive without hearing from more working group participants, particularly since this was such a hotly contested portion of the specification. Randy From randy_presuhn@mindspring.com Thu Apr 30 14:36:40 2009 Return-Path: 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 51EAE3A6C4D for ; Thu, 30 Apr 2009 14:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 22l6vM2nDMuV for ; Thu, 30 Apr 2009 14:36:39 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 80A6B3A6CA5 for ; Thu, 30 Apr 2009 14:36:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=o8IIsRI/tnrrGfOksbX8CMS3gkuNGqLSlSTpuInnNUD0W2Q+XEnzt/IFMIu4ioxT; h=Received:Message-ID:From:To: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 [69.3.146.82] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lzdx9-0002s8-HD for ltru@ietf.org; Thu, 30 Apr 2009 17:37:59 -0400 Message-ID: <01f301c9c9dc$52371720$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 30 Apr 2009 14:40:45 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968ea898225d618a20dab2ad6cb0b66a5af350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: [Ltru] Issue summary X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:36:40 -0000 Hi - As co-chair... The list of open ltru issues is available at http://trac.tools.ietf.org/wg/ltru/trac/report/1 In brief: #31 change titles of ISO docs #36 AD #3 - rules for UN M.49 codes #40 AD #7 - section 3.4 on ISO 3166 vs UN M.49 #41 AD #8 - section 3.5 SHOULD vs MUST #43 AD #10 - section 5.1 vs 3.2 on File-Date value #45 AD #12 - reason for SHOULD in 4.5 (3) on extlang preferred value mappings 31 is open because I haven't seen confirmation that the edits are understood 36 is open waiting in case others would like to comment before closure 40 has multiple proposals for text change 41 is open waiting in case there are proposals for additional clarification 43 has a proposal, but I'd like to hear from folks whether they think this constitutes a technical change, and whether it sufficiently addresses the AD comments 45 has an extensive proposal, but I'd like to hear from others in the WG since this touches on what were contentious issues PLEASE respond to any of these on their respective threads! Randy From randy_presuhn@mindspring.com Thu Apr 30 14:40:16 2009 Return-Path: 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 3413E3A6C2C for ; Thu, 30 Apr 2009 14:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 SY+-Uw--Sac4 for ; Thu, 30 Apr 2009 14:40:15 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 6CC803A6AB3 for ; Thu, 30 Apr 2009 14:40:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nD9eo5WOL0J3E/Y2bl4C3kTNjxVhkc9CnSBgYs+fSht9TsFDi2O2V3iAPlT2jT00; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lze0g-0004dT-Av for ltru@ietf.org; Thu, 30 Apr 2009 17:41:38 -0400 Message-ID: <020001c9c9dc$d4b6aee0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com><00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer><30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com><018701c9c9d7$1c1a3140$6801a8c0@oemcomputer><4D25F22093241741BC1D0EEBC2DBB1DA019FE3469A@EX-SEA5-D.ant.amazon.com> <019d01c9c9d8$88836080$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FE346D3@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 14:44:24 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968b98693f39dcd444eee046aba378c3267350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs.UNM.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:40:16 -0000 Hi - As a technical contributor... > From: "Phillips, Addison" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Thursday, April 30, 2009 2:20 PM > Subject: RE: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs.UNM.49 ... > Here are the proposed texts: ... I prefer "B". Randy From addison@amazon.com Thu Apr 30 14:40:27 2009 Return-Path: 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 B46CB3A6AB3 for ; Thu, 30 Apr 2009 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.642 X-Spam-Level: X-Spam-Status: No, score=-106.642 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 YsmsiBXS7ds4 for ; Thu, 30 Apr 2009 14:40:27 -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 D78603A67CF for ; Thu, 30 Apr 2009 14:40:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="260634473" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 21:41:49 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3ULfmWW029714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 21:41:48 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Thu, 30 Apr 2009 14:41:48 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 14:41:46 -0700 Thread-Topic: [Ltru] Issue summary Thread-Index: AcnJ2/KjLsRRN4e4RMqEXNsD7yeRTQAAFYkg Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34730@EX-SEA5-D.ant.amazon.com> References: <01f301c9c9dc$52371720$6801a8c0@oemcomputer> In-Reply-To: <01f301c9c9dc$52371720$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Issue summary X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:40:27 -0000 KGFzIGVkaXRvcikNCg0KPiAzMSBpcyBvcGVuIGJlY2F1c2UgSSBoYXZlbid0IHNlZW4gY29uZmly bWF0aW9uIHRoYXQgdGhlIGVkaXRzIGFyZQ0KPiB1bmRlcnN0b29kDQoNCkkgaGF2ZSByZXF1ZXN0 ZWQgdGhhdCBEb3VnIHNlbmQgbWUgaGlzIFhNTCBzb3VyY2VzIHNvIHRoYXQgb3VycyBhcmUgaWRl bnRpY2FsLiBTaW5jZSBJIHVzZWQgaGlzIHByaXZhdGUgZW1haWwgYWRkcmVzcywgSSBleHBlY3Qg SSBtYXkgaGVhciBmcm9tIGhpbSB0aGlzIGV2ZW5pbmcgb3Igb3Zlcm5pZ2h0Lg0KDQpBZGRpc29u DQoNCkFkZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0K DQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0 ZWN0dXJlLg0KDQoNCg0K From addison@amazon.com Thu Apr 30 14:41:12 2009 Return-Path: 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 1A47E3A6AB3 for ; Thu, 30 Apr 2009 14:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.641 X-Spam-Level: X-Spam-Status: No, score=-106.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 ljcam2Xrj5tv for ; Thu, 30 Apr 2009 14:41:11 -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 CBDEE3A6CA5 for ; Thu, 30 Apr 2009 14:41:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="260634790" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 21:42:23 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id n3ULgMat009610 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 21:42:23 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Thu, 30 Apr 2009 14:42:22 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 14:42:19 -0700 Thread-Topic: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs.UNM.49 Thread-Index: AcnJ3HMnG/l0hHLDRSaey/hQ0rakZQAAArcg Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34731@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6A5B3@EX-SEA5-D.ant.amazon.com><00f701c9c9d1$e30b82a0$6801a8c0@oemcomputer><30b660a20904301353q6238f867l3b4e8644d1396625@mail.gmail.com><018701c9c9d7$1c1a3140$6801a8c0@oemcomputer><4D25F22093241741BC1D0EEBC2DBB1DA019FE3469A@EX-SEA5-D.ant.amazon.com> <019d01c9c9d8$88836080$6801a8c0@oemcomputer> <4D25F22093241741BC1D0EEBC2DBB1DA019FE346D3@EX-SEA5-D.ant.amazon.com> <020001c9c9dc$d4b6aee0$6801a8c0@oemcomputer> In-Reply-To: <020001c9c9dc$d4b6aee0$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs.UNM.49 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:41:12 -0000 KGFzIGNvbnRyaWJ1dG9yKQ0KDQpJIGhhdmUgbm8gb2JqZWN0aW9uIHRvIEIuDQoNCkFkZGlzb24N Cg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gTGFiMTI2DQoN CkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRl Y3R1cmUuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFs ZiBPZiBSYW5keSBQcmVzdWhuDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAzMCwgMjAwOSAyOjQ0 IFBNDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBUaWNr ZXQgIzQwOiBBRCBJc3N1ZSAjNzogc2VjdGlvbiAzLjQgb24gSVNPDQo+IDMxNjYgdnMuVU5NLjQ5 DQo+IA0KPiBIaSAtDQo+IA0KPiBBcyBhIHRlY2huaWNhbCBjb250cmlidXRvci4uLg0KPiANCj4g PiBGcm9tOiAiUGhpbGxpcHMsIEFkZGlzb24iIDxhZGRpc29uQGFtYXpvbi5jb20+DQo+ID4gVG86 ICJSYW5keSBQcmVzdWhuIiA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbT47ICJMVFJVIFdv cmtpbmcNCj4gR3JvdXAiIDxsdHJ1QGlldGYub3JnPg0KPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJp bCAzMCwgMjAwOSAyOjIwIFBNDQo+ID4gU3ViamVjdDogUkU6IFtMdHJ1XSBUaWNrZXQgIzQwOiBB RCBJc3N1ZSAjNzogc2VjdGlvbiAzLjQgb24gSVNPDQo+IDMxNjYgdnMuVU5NLjQ5DQo+IC4uLg0K PiA+IEhlcmUgYXJlIHRoZSBwcm9wb3NlZCB0ZXh0czoNCj4gLi4uDQo+IA0KPiBJIHByZWZlciAi QiIuDQo+IA0KPiBSYW5keQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== From randy_presuhn@mindspring.com Thu Apr 30 14:53:17 2009 Return-Path: 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 A43F63A6A18 for ; Thu, 30 Apr 2009 14:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 efIbnn9Z-c0d for ; Thu, 30 Apr 2009 14:53:16 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id D91593A6863 for ; Thu, 30 Apr 2009 14:53:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JAkWiFKb4X5kknSMGT+14BoQ3EWDTFJkUPUdgWTsJfutJuB/hh8Wt+gJIkteRdqZ; 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 [69.3.146.82] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzeDH-0000GE-R2 for ltru@ietf.org; Thu, 30 Apr 2009 17:54:40 -0400 Message-ID: <020b01c9c9de$a63fede0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AE8A@EX-SEA5-D.ant.amazon.com> Date: Thu, 30 Apr 2009 14:57:25 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69685d4a47ad21bade57ebed040c5aadc9af350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.82 Subject: Re: [Ltru] Ticket #43: AD Issue #10: File-Date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:53:17 -0000 Hi - As a technical contributor... > From: "Phillips, Addison" > To: "LTRU Working Group" > Sent: Wednesday, April 29, 2009 3:29 PM > Subject: [Ltru] Ticket #43: AD Issue #10: File-Date value ... > Proposed resolution: ... > The first record in the registry is always the "File-Date" record. > This record occurs only once in the file and contains a single field > whose field-name is "File-Date". The field-body of this record > contains the approval date of the most recent change to the registry, > making it possible to compare different versions of the registry. > The registry on the IANA website is > the most current. Versions with an older date than that one > are not up-to-date. ... I think the real problem here is that this text (for section 3.1.2) is an imperfect re-cap of the detailed description in section 5.1. Rathering than repeating or summarizing (with the risk of getting it wrong), might it be better to make a forward reference? Proposed text: The first record in the registry is always the "File-Date" record. This record occurs only once in the file and contains a single field whose field-name is "File-Date". The field-body of this record contains a date (see 5.1) making it possible to easily recognize different versions of the registry. I think this more directly addresses the AD comment. Randy From addison@amazon.com Thu Apr 30 15:02:50 2009 Return-Path: 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 C77C33A6E99 for ; Thu, 30 Apr 2009 15:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.64 X-Spam-Level: X-Spam-Status: No, score=-106.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 YIo2DA2FYL8B for ; Thu, 30 Apr 2009 15:02:49 -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 E5DAE28C197 for ; Thu, 30 Apr 2009 15:01:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="260643112" Received: from smtp-in-4103.sea5.amazon.com ([10.248.183.17]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 22:02:41 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-4103.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n3UM2eUJ019721 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 22:02:40 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Thu, 30 Apr 2009 15:02:40 -0700 From: "Phillips, Addison" To: Randy Presuhn , LTRU Working Group Date: Thu, 30 Apr 2009 15:02:38 -0700 Thread-Topic: [Ltru] Ticket #43: AD Issue #10: File-Date value Thread-Index: AcnJ3kVWbfkot8i5Q12evW/Da0Ux3QAAE/4Q Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019FE34785@EX-SEA5-D.ant.amazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA019FD6AE8A@EX-SEA5-D.ant.amazon.com> <020b01c9c9de$a63fede0$6801a8c0@oemcomputer> In-Reply-To: <020b01c9c9de$a63fede0$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] Ticket #43: AD Issue #10: File-Date value X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 22:02:50 -0000 KGFzIGNvbnRyaWJ1dG9yKQ0KDQpJIGFncmVlIHdpdGggdGhpcyBwcm9wb3NlZCBjaGFuZ2UuDQoN CihhcyBlZGl0b3IpDQoNCkkgaGF2ZSBpbnNlcnRlZCB0aGlzIHZlcnNpb24gb2YgdGhlIHRleHQu DQoNCkFkZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0K DQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0 ZWN0dXJlLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhh bGYgT2YgUmFuZHkgUHJlc3Vobg0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMDkgMjo1 NyBQTQ0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gVGlj a2V0ICM0MzogQUQgSXNzdWUgIzEwOiBGaWxlLURhdGUgdmFsdWUNCj4gDQo+IEhpIC0NCj4gDQo+ IEFzIGEgdGVjaG5pY2FsIGNvbnRyaWJ1dG9yLi4uDQo+IA0KPiA+IEZyb206ICJQaGlsbGlwcywg QWRkaXNvbiIgPGFkZGlzb25AYW1hem9uLmNvbT4NCj4gPiBUbzogIkxUUlUgV29ya2luZyBHcm91 cCIgPGx0cnVAaWV0Zi5vcmc+DQo+ID4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyOSwgMjAwOSAz OjI5IFBNDQo+ID4gU3ViamVjdDogW0x0cnVdIFRpY2tldCAjNDM6IEFEIElzc3VlICMxMDogRmls ZS1EYXRlIHZhbHVlDQo+IC4uLg0KPiA+IFByb3Bvc2VkIHJlc29sdXRpb246DQo+IC4uLg0KPiA+ IDx0PlRoZSBmaXJzdCByZWNvcmQgaW4gdGhlIHJlZ2lzdHJ5IGlzIGFsd2F5cyB0aGUgIkZpbGUt RGF0ZSINCj4gcmVjb3JkLg0KPiA+IFRoaXMgcmVjb3JkIG9jY3VycyBvbmx5IG9uY2UgaW4gdGhl IGZpbGUgYW5kIGNvbnRhaW5zIGEgc2luZ2xlDQo+IGZpZWxkDQo+ID4gd2hvc2UgZmllbGQtbmFt ZSBpcyAiRmlsZS1EYXRlIi4gVGhlIGZpZWxkLWJvZHkgb2YgdGhpcyByZWNvcmQNCj4gPiBjb250 YWlucyB0aGUgYXBwcm92YWwgZGF0ZSBvZiB0aGUgbW9zdCByZWNlbnQgY2hhbmdlIHRvIHRoZQ0K PiByZWdpc3RyeSwNCj4gPiBtYWtpbmcgaXQgcG9zc2libGUgdG8gY29tcGFyZSBkaWZmZXJlbnQg dmVyc2lvbnMgb2YgdGhlIHJlZ2lzdHJ5Lg0KPiA+ICBUaGUgcmVnaXN0cnkgb24gdGhlIElBTkEg d2Vic2l0ZSBpcw0KPiA+IHRoZSBtb3N0IGN1cnJlbnQuICAgVmVyc2lvbnMgd2l0aCBhbiBvbGRl ciBkYXRlIHRoYW4gdGhhdCBvbmUNCj4gPiBhcmUgbm90IHVwLXRvLWRhdGUuPC90Pg0KPiAuLi4N Cj4gDQo+IEkgdGhpbmsgdGhlIHJlYWwgcHJvYmxlbSBoZXJlIGlzIHRoYXQgdGhpcyB0ZXh0IChm b3Igc2VjdGlvbiAzLjEuMikNCj4gaXMNCj4gYW4gaW1wZXJmZWN0IHJlLWNhcCBvZiB0aGUgZGV0 YWlsZWQgZGVzY3JpcHRpb24gaW4gc2VjdGlvbiA1LjEuDQo+IFJhdGhlcmluZyB0aGFuIHJlcGVh dGluZyBvciBzdW1tYXJpemluZyAod2l0aCB0aGUgcmlzayBvZiBnZXR0aW5nDQo+IGl0IHdyb25n KSwgbWlnaHQgaXQgYmUgYmV0dGVyIHRvIG1ha2UgYSBmb3J3YXJkIHJlZmVyZW5jZT8NCj4gUHJv cG9zZWQgdGV4dDoNCj4gDQo+IDx0PlRoZSBmaXJzdCByZWNvcmQgaW4gdGhlIHJlZ2lzdHJ5IGlz IGFsd2F5cyB0aGUgIkZpbGUtRGF0ZSINCj4gcmVjb3JkLg0KPiBUaGlzIHJlY29yZCBvY2N1cnMg b25seSBvbmNlIGluIHRoZSBmaWxlIGFuZCBjb250YWlucyBhIHNpbmdsZQ0KPiBmaWVsZA0KPiB3 aG9zZSBmaWVsZC1uYW1lIGlzICJGaWxlLURhdGUiLiBUaGUgZmllbGQtYm9keSBvZiB0aGlzIHJl Y29yZA0KPiBjb250YWlucyBhIGRhdGUgKHNlZSA1LjEpIG1ha2luZyBpdCBwb3NzaWJsZSB0byBl YXNpbHkgcmVjb2duaXplDQo+IGRpZmZlcmVudCB2ZXJzaW9ucyBvZiB0aGUgcmVnaXN0cnkuDQo+ IA0KPiBJIHRoaW5rIHRoaXMgbW9yZSBkaXJlY3RseSBhZGRyZXNzZXMgdGhlIEFEIGNvbW1lbnQu DQo+IA0KPiBSYW5keQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== From randy_presuhn@mindspring.com Thu Apr 30 21:03:53 2009 Return-Path: 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 531B33A68E7 for ; Thu, 30 Apr 2009 21:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 EutMWs2Vzv28 for ; Thu, 30 Apr 2009 21:03:52 -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 94F813A68DA for ; Thu, 30 Apr 2009 21:03:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Z9o2a58UCmtWxPgqI1xvQsPmklofe1ZQ9Xzkj6hAyeYwM+NFo0nxHdnc3BX9w95R; 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 [66.167.206.221] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lzjzv-0001Cf-LY for ltru@ietf.org; Fri, 01 May 2009 00:05:15 -0400 Message-ID: <003d01c9ca12$67a294a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20090430211114.GO7401@mercury.ccil.org> Date: Thu, 30 Apr 2009 21:07:53 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968adf0a944c148e3d75b70f18f8b06faa2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.221 Subject: Re: [Ltru] It MUST and SHALL be preserved X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 04:03:53 -0000 Hi - > From: "John Cowan" > To: > Sent: Thursday, April 30, 2009 2:11 PM > Subject: [Ltru] It MUST and SHALL be preserved > > Just to keep things simple, let's change all SHALLs to MUSTs. As co chair: Let's not. The two have exactly the same effect from and RFC 2119 point of view. At this stage, we need to limit ourselves to addressing the AD review comments, stuff we agreed earlier to address (references), and show-stopper bugs that happen to pop up. Randy (who is known to be somewhat humor-impaired, in case this was meant in jest.) From cowan@ccil.org Thu Apr 30 22:22:34 2009 Return-Path: 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 3417E3A67B7 for ; Thu, 30 Apr 2009 22:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 NrXpT7b74VOL for ; Thu, 30 Apr 2009 22:22:33 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 758693A63EC for ; Thu, 30 Apr 2009 22:22:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LzlE3-00007X-MC; Fri, 01 May 2009 01:23:55 -0400 Date: Fri, 1 May 2009 01:23:55 -0400 To: Randy Presuhn Message-ID: <20090501052355.GG15356@mercury.ccil.org> References: <20090430211114.GO7401@mercury.ccil.org> <003d01c9ca12$67a294a0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003d01c9ca12$67a294a0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: ltru@ietf.org Subject: Re: [Ltru] It MUST and SHALL be preserved X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 05:22:34 -0000 Randy Presuhn scripsit: > Randy (who is known to be somewhat humor-impaired, in case this > was meant in jest.) Not in jest, but I suppose it *was* a bad idea at this stage. Never mind. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Female celebrity stalker, on a hot morning in Cairo: "Imagine, Colonel Lawrence, ninety-two already!" El Auruns's reply: "Many happy returns of the day!"