From ltru-bounces@ietf.org Thu Sep 01 02:29:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAiZW-0005mK-Rr; Thu, 01 Sep 2005 02:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAiZU-0005mF-52 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 02:29:12 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27681 for ; Thu, 1 Sep 2005 02:29:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050901062840.TROY12165.mta10.adelphia.net@DEWELL> for ; Thu, 1 Sep 2005 02:28:40 -0400 Message-ID: <001301c5aebe$5f1d4460$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <43160632.9000707@dial.pipex.com> Date: Wed, 31 Aug 2005 23:28: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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Elwyn Davies wrote: > One minor point that might be addressed if the draft is recycled for > any other reason is that several of the rules in Section 2 are > actually copied from the companion document. In other circumstances > this might be undesirable (double maintenance etc.) but given that > this draft is essentially a 'one shot' it doesn't much matter as long > as they have beeen copied correctly - which appears to be the case. > If the document is recycled it might be worth cross-referencing the > original rules in ltru-registry. > Items 3,4,5 map to s2.2.4 of ltru-registry > Items 7-11 map to s3.2 and s3.3 (Item 12). I leave it to the group and co-chairs to determine whether any changes should be made to draft-initial. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 03:11:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjE6-0007kx-T7; Thu, 01 Sep 2005 03:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjE5-0007kp-AK for ltru@megatron.ietf.org; Thu, 01 Sep 2005 03:11:09 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00801 for ; Thu, 1 Sep 2005 03:11:07 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EAjDd-0004Xv-4K for ltru@lists.ietf.org; Thu, 01 Sep 2005 09:10:41 +0200 Received: from c-180-161-8.hh.dial.de.ignite.net ([62.180.161.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 09:10:41 +0200 Received: from nobody by c-180-161-8.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 09:10:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 09:01:03 +0200 Organization: Lines: 10 Message-ID: <4316A72F.5FAB@xyzzy.claranet.de> References: <43160632.9000707@dial.pipex.com> <001301c5aebe$5f1d4460$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-8.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I leave it to the group and co-chairs to determine whether > any changes should be made to draft-initial. Hi, could you please forward the complete review (if Elwyn allows it of course) ? From what you've quoted I'm not sure what his real concern is. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 12:14:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAre7-0007Xs-Ix; Thu, 01 Sep 2005 12:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAre6-0007W8-Ug for ltru@megatron.ietf.org; Thu, 01 Sep 2005 12:10:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12866 for ; Thu, 1 Sep 2005 12:10:32 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EArg4-0003Ro-P5 for ltru@ietf.org; Thu, 01 Sep 2005 12:12:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 09:10:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] At least one prefix for variant (GenArt) Date: Thu, 1 Sep 2005 09:10:15 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91542@irvmbxw01.quest.com> Thread-Topic: [Ltru] At least one prefix for variant (GenArt) Thread-Index: AcWuohPuiN9PRRJfT+S+qB+oDMpfmAAa8sOA From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 16:10:15.0694 (UTC) FILETIME=[A3C5B2E0:01C5AF0F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > John Cowan wrote: >=20 > > | Variant registration requests are REQUIRED to include at > > | least one "Prefix" field in the registration form. > > > > Is it that what you're looking for ? Bye, Frank >=20 > I forgot about this. Do we really want to forbid variants that apply > to every language? "signed" would be a reasonable such candidate; > it can be applied to any spoken language to specify the (exact) > signed equivalent: thus en-signed would be a mapping from English > to signs. This is not the same as sign languages proper. >=20 [Addison Phillips]=20 We did debate this previously. The question was whether the community = could make judgments about generic subtags, either for acceptance or = application of them. Requiring at least one prefix effectively limits = variants to the description of particular language variations. There is a way to fix this without removing the requirement. Currently = the text in "Prefix" in S3.1 says: -- Prefix's field-value contains a language tag with which this subtag MAY = be used to form a new language tag, perhaps with other subtags as well. = This field MUST only appear in records whose 'Type' field-value is = 'variant' or 'extlang'. For example, the 'Prefix' for the variant = 'nedis' is 'sl', meaning that the tags "sl-nedis" and "sl-IT-nedis" = might be appropriate while the tag "is-nedis" is not. -- What it should actually say is "Prefix's field-value contains a language = RANGE". This is more correct (it is actually what it means) and also would allow = a generic subtag to be registered, using the generic language range "*". = It would also allow very specialized subtags. Consider: Subtag: hankaku Prefix: *-Kana The problem here, of course, is that "range" is a "matching" beast. Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 12:32:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EArz5-00053n-PE; Thu, 01 Sep 2005 12:32:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EArz3-000526-KD for ltru@megatron.ietf.org; Thu, 01 Sep 2005 12:32:13 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13677 for ; Thu, 1 Sep 2005 12:32:10 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050901163136.OQSL12299.mta13.adelphia.net@DEWELL> for ; Thu, 1 Sep 2005 12:31:36 -0400 Message-ID: <006c01c5af12$96fc0ca0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050901160952.TOEY6799.mta6.adelphia.net@megatron.ietf.org> Date: Thu, 1 Sep 2005 09:31:21 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> I leave it to the group and co-chairs to determine whether >> any changes should be made to draft-initial. > > Hi, could you please forward the complete review (if Elwyn > allows it of course) ? From what you've quoted I'm not sure > what his real concern is. http://www1.ietf.org/mail-archive/web/ltru/current/msg03523.html -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 12:58:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsOt-0003vt-RU; Thu, 01 Sep 2005 12:58:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsOs-0003vh-Iw for ltru@megatron.ietf.org; Thu, 01 Sep 2005 12:58:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14900 for ; Thu, 1 Sep 2005 12:58:51 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAsQo-0004z8-Nc for ltru@ietf.org; Thu, 01 Sep 2005 13:00:58 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j81GwV29003520; Thu, 1 Sep 2005 12:58:33 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 1 Sep 2005 12:58:24 -0400 Date: Thu, 1 Sep 2005 12:58:23 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] At least one prefix for variant (GenArt) Message-ID: <20050901165823.GB17084@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0CA91542@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CA91542@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > We did debate this previously. The question was whether the community > could make judgments about generic subtags, either for acceptance or > application of them. Requiring at least one prefix effectively limits > variants to the description of particular language variations. Indeed. > There is a way to fix this without removing the requirement. [snip] > The problem here, of course, is that "range" is a "matching" beast. I think that makes the cure worse than the disease. "Prefix: *" is just a verbose way of saying "no prefix required". I request (as part of Last Call) that this be reconsidered by the WG. Variants without prefixes may require heightened scrutiny by ietf-languages and the LSR, but I do not think they should be forbidden altogether. -- John Cowan jcowan@reutershealth.com At times of peril or dubitation, http://www.ccil.org/~cowan Perform swift circular ambulation, http://www.reutershealth.com With loud and high-pitched ululation. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 13:04:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsU0-0000Pd-Cn; Thu, 01 Sep 2005 13:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsTy-0000PY-Kq for ltru@megatron.ietf.org; Thu, 01 Sep 2005 13:04:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15247 for ; Thu, 1 Sep 2005 13:04:07 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAsVv-0005BA-Sx for ltru@ietf.org; Thu, 01 Sep 2005 13:06:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 10:03:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] At least one prefix for variant (GenArt) Date: Thu, 1 Sep 2005 10:03:52 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA9159B@irvmbxw01.quest.com> Thread-Topic: [Ltru] At least one prefix for variant (GenArt) Thread-Index: AcWvFnslbJ3EIFrGQ/+YeMRU9KQR8wAAEt9A From: "Addison Phillips" To: "John.Cowan" X-OriginalArrivalTime: 01 Sep 2005 17:03:53.0000 (UTC) FILETIME=[216FA280:01C5AF17] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Proposed: Change this: -- Prefix's field-value contains a language tag with which this subtag MAY = be used to form a new language tag, perhaps with other subtags as well. -- To read like this: -- Prefix's field-value contains a language tag with which this subtag MAY = be used to form a new language tag, perhaps with other subtags as well, = or the special tag "*", indicating that this subtag could be considered = appropriate with any combination of subtags. -- This neatly avoids the whole mess, while giving us the desired results. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John.Cowan [mailto:jcowan@reutershealth.com] > Sent: 2005?9?1? 9:58 > To: Addison Phillips > Cc: LTRU Working Group > Subject: Re: [Ltru] At least one prefix for variant (GenArt) >=20 > Addison Phillips scripsit: >=20 > > We did debate this previously. The question was whether the = community > > could make judgments about generic subtags, either for acceptance or > > application of them. Requiring at least one prefix effectively = limits > > variants to the description of particular language variations. >=20 > Indeed. >=20 > > There is a way to fix this without removing the requirement. >=20 > [snip] >=20 > > The problem here, of course, is that "range" is a "matching" beast. >=20 > I think that makes the cure worse than the disease. "Prefix: *" is = just a > verbose way of saying "no prefix required". >=20 > I request (as part of Last Call) that this be reconsidered by the WG. > Variants without prefixes may require heightened scrutiny by ietf- > languages > and the LSR, but I do not think they should be forbidden altogether. >=20 > -- > John Cowan jcowan@reutershealth.com > At times of peril or dubitation, http://www.ccil.org/~cowan > Perform swift circular ambulation, http://www.reutershealth.com > With loud and high-pitched ululation. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 13:11:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsbJ-00045K-4v; Thu, 01 Sep 2005 13:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsbG-00045B-38 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 13:11:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15476 for ; Thu, 1 Sep 2005 13:11:39 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAsdF-0005MQ-Ls for ltru@ietf.org; Thu, 01 Sep 2005 13:13:45 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j81HBV3O003576; Thu, 1 Sep 2005 13:11:31 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 1 Sep 2005 13:11:24 -0400 Date: Thu, 1 Sep 2005 13:11:24 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] At least one prefix for variant (GenArt) Message-ID: <20050901171123.GC17084@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0CA9159B@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CA9159B@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Change this: > > -- > Prefix's field-value contains a language tag with which this subtag MAY be used to form a new language tag, perhaps with other subtags as well. > -- > > To read like this: > > -- > Prefix's field-value contains a language tag with which this subtag MAY be used to form a new language tag, perhaps with other subtags as well, or the special tag "*", indicating that this subtag could be considered appropriate with any combination of subtags. > -- What's the argument against just allowing zero prefixes for variants? -- John Cowan www.reutershealth.com www.ccil.org/~cowan jcowan@reutershealth.com Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, The day and hour soon are coming / When all the IT folks say "Gosh!" It isn't from a clever lawsuit / That Windowsland will finally fall, But thousands writing open source code / Like mice who nibble through a wall. --The Linux-nationale by Greg Baker _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 13:21:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAskq-0000Fr-6E; Thu, 01 Sep 2005 13:21:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsko-0000DR-4t for ltru@megatron.ietf.org; Thu, 01 Sep 2005 13:21:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16061 for ; Thu, 1 Sep 2005 13:21:31 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAsmn-0005gn-Lh for ltru@ietf.org; Thu, 01 Sep 2005 13:23:37 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 10:21:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 10:21:13 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA915AC@irvmbxw01.quest.com> Thread-Topic: maintain registration records for every single subtag (gen-art #10) Thread-Index: AcWvGYbMjBJ3kBS5T5iHH+XVliY9Ng== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 17:21:21.0431 (UTC) FILETIME=[92598270:01C5AF19] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Elwyn Davies Subject: [Ltru] maintain registration records for every single subtag (gen-art #10) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0322750005==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0322750005== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjE6IHBhcmEgMSwgbGFzdCBzZW50ZW5jZTogIEdpdmVuIHRoYXQgKmFsbCogdGhlIGlu aXRpYWwgcmVjb3JkcyANCj4gPiBhcmUgaW4gdGhlIGluaXRpYWwgcmVnaXN0cnkgbG9hZCBSRkMs IG1haW50YWluaW5nIHJlZ2lzdHJhdGlvbiBmb3JtcyANCj4gPiBmb3IganVzdCB0aGUgUkZDMzA2 NiBzdWJzZXQgc2VlbXMgYSBsaXR0bGUgb2RkLiAgV2h5IG5vdCBhbGwgb3IgDQo+ID4gbm9uZSwg c2luY2UgcHJlc3VtYWJseSB0aGV5IGNhbiBiZSBjcmVhdGVkIGJ5IGFuIGF1dG9tYXRlZCBzY3Jp cHQ/DQo+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiANCj4gVGhlIFJGQyAzMDY2IHJlZ2lzdHJ5IGlz IG1haW50YWluZWQgaW4gcGVycGV0dWl0eSBhbmQgaXRzIGZvcm1hdCBpcyANCj4gZGlmZmVyZW50 IHRoYW4gdGhhdCBvZiB0aGUgZHJhZnQuIFRoYXQgcmVnaXN0cnkgaXMgbWFpbnRhaW5lZCBhcyBh biANCj4gb2Jzb2xldGUgcmVmZXJlbmNlIChpdCBqdXN0IHNlZW1lZCBwcnVkZW50IHRvIGRvIHNv KS4gR2VuZXJhdGluZyBtYW55IA0KPiByZWdpc3RyYXRpb24gZm9ybXMgZm9yIHRoZSBpbml0aWFs IHNldCwgaG93ZXZlciwgZG9lc24ndCBzZWVtIHRoYXQgdXNlZnVsLg0KDQpUaGUgcHJvcG9zYWwg aXMgdG8gZ2VuZXJhdGUgYm9ndXMgcmVnaXN0cmF0aW9uIGZvcm1zIGZvciBldmVyeSBzdWJ0YWcu IEkgYmVsaWV2ZSB0aGlzIGlzIGEgbWlzLXJlYWRpbmcgb2YgdGhlIG9yaWdpbmFsIGludGVudGlv biAod2hpY2ggd2FzIHRoYXQgdGhlIGV4aXN0aW5nIFJGQyAzMDY2IHJlZ2lzdHJ5IGJlIHByZXNl cnZlZCkuDQoNCkkgbm90ZSB0aGF0LCBhcyB3cml0dGVuLCB0aGUgSUFOQSBjb25zaWRlcmF0aW9u cyBkbyBub3QgcHJlc2VydmUgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtcyEgVGhlIGFwcHJvdmVkIHJl Y29yZCBpcyBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFuZCB0aGUgZm9ybSBpcyBhcHBhcmVu dGx5IGRpc2NhcmRlZC4gU2VjdGlvbiA1IHNheXMgdGhpcyBjbGVhcmx5IGFuZCBTZWN0aW9ucyAz LjIgYW5kIDMuNCBpbXBseSBpdCBzdHJvbmdseS4gVGhlIG9ubHkgcmVmZXJlbmNlIHRvIHRoZSBt YWludGVuYW5jZSBvZiByZWdpc3RyYXRpb24gZm9ybXMgaXMgdGhlIGNpdGVkIHNlbnRlbmNlIGlu IFNlY3Rpb24gMy4xLCBwYXJhIDEsIHdoaWNoIHNheXMgdGhhdCB0aGUgZm9ybXMgd2lsbCBiZSBw cmVzZXJ2ZWQuIFdlIHNob3VsZCBkZWNpZGUgd2hpY2ggb25lLg0KDQpQcm9wb3NlZCBTb2x1dGlv bjoNCg0KQ2hhbmdlIHRoZSBjaXRlZCBzZW50ZW5jZToNCg0KLS0NCldpdGggdGhlIGV4Y2VwdGlv biBvZiB0aGUgcmVnaXN0cmF0aW9uIGZvcm1zIGZvciBncmFuZGZhdGhlcmVkIGFuZCByZWR1bmRh bnQgdGFncywgbm8gcmVnaXN0cmF0aW9uIHJlY29yZHMgd2lsbCBiZSBtYWludGFpbmVkIGZvciB0 aGUgaW5pdGlhbCBzZXQgb2Ygc3VidGFncy4NCi0tDQoNClRvIHJlYWQ6DQoNCi0tDQpUaGUgZXhp c3RpbmcgcmVnaXN0cmF0aW9uIGZvcm1zIGZvciBSRkMgMzA2NiBncmFuZGZhdGhlcmVkIGFuZCBy ZWR1bmRhbnQgdGFncyB3aWxsIGJlIG1haW50YWluZWQgYXMgcGFydCBvZiB0aGUgb2Jzb2xldGUg UkZDIDMwNjYgcmVnaXN0cnkuIFRoZSByZW1haW5pbmcgc2V0IG9mIGluaXRpYWwgc3VidGFncyB3 aWxsIG5vdCBoYXZlIHJlZ2lzdHJhdGlvbiBmb3JtcyBjcmVhdGVkIGZvciB0aGVtLg0KLS0NCg0K QW5kIGNoYW5nZSB0aGlzIHNlbnRlbmNlIGluIFNlY3Rpb24gNToNCg0KLS0NCkZ1dHVyZSB3b3Jr IG9uIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgU0hBTEwgYmUgbGltaXRlZCB0byBpbnNl cnRpbmcgb3IgcmVwbGFjaW5nIHdob2xlIHJlY29yZHMgcHJlZm9ybWF0dGVkIGZvciBJQU5BIGJ5 IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4y IChNYWludGVuYW5jZSBvZiB0aGUgUmVnaXN0cnkpIG9mIHRoaXMgZG9jdW1lbnQuDQotLQ0KDQpU byByZWFkOg0KDQotLQ0KRnV0dXJlIHdvcmsgb24gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3Ry eSBTSEFMTCBiZSBsaW1pdGVkIHRvIGluc2VydGluZyBvciByZXBsYWNpbmcgd2hvbGUgcmVjb3Jk cyBwcmVmb3JtYXR0ZWQgZm9yIElBTkEgYnkgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIgKE1haW50ZW5hbmNlIG9mIHRoZSBSZWdpc3RyeSkg b2YgdGhpcyBkb2N1bWVudCBhbmQgYXJjaGl2aW5nIHRoZSBmb3J3YXJkZWQgcmVnaXN0cmF0aW9u IGZvcm0uDQotLQ0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVj dCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0MgSW50 ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9yZy9J bnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJ dCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= --===============0322750005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0322750005==-- From ltru-bounces@ietf.org Thu Sep 01 13:31:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsu9-0006Np-Ad; Thu, 01 Sep 2005 13:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsu6-0006Nh-K0 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 13:31:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16379 for ; Thu, 1 Sep 2005 13:31:06 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAsw3-0005vV-M6 for ltru@ietf.org; Thu, 01 Sep 2005 13:33:13 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 10:30:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 10:30:53 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA915BA@irvmbxw01.quest.com> Thread-Topic: numeric ranges in the registry (gen-art #11) Thread-Index: AcWvGuCRig+Firm6RoiO5i0A9XRylw== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 17:30:53.0913 (UTC) FILETIME=[E7935490:01C5AF1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Elwyn Davies Subject: [Ltru] numeric ranges in the registry (gen-art #11) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1884206966==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1884206966== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjE6IHBhcmEgYWZ0ZXIgQUJORjogTnVtZXJpYyByYW5nZXM/ICBUaGlzIHNlY3Rpb24g dGFsa3MgYWJvdXQgDQo+ID4gYWxwaGFiZXRpYyByYW5nZXMgc3VjaCBhcyBjLi5rLiAgSXMgdGhp cyBzdXBwb3NlZCB0byBjb3ZlciBudW1lcmljIA0KPiA+IHJhbmdlcyBhcyB3ZWxsPw0KPiBbQWRk aXNvbiBQaGlsbGlwc10NCj4gDQo+IFllcy4gSXQgaXMgYW4gb3ZlcnNpZ2h0IChzaW5jZSB0aGVy ZSBhcmUgbm8gbnVtZXJpYyByYW5nZXMgaW5pdGlhbGx5KS4NCg0KUHJvcG9zZWQgc29sdXRpb246 DQoNCkNoYW5nZSB0aGlzOg0KDQotLQ0KPHQ+VGhlIHNlcXVlbmNlICcuLicgKCV4MkUuMkUpIGlu IGEgZmllbGQtYm9keSBkZW5vdGVzIGEgcmFuZ2Ugb2YgdmFsdWVzLiBTdWNoIGEgcmFuZ2UgcmVw cmVzZW50cyBhbGwgDQogc3VidGFncyBvZiB0aGUgc2FtZSBsZW5ndGggdGhhdCBhcmUgYWxwaGFi ZXRpY2FsbHkgd2l0aGluIHRoYXQgcmFuZ2UsIA0KIGluY2x1ZGluZyB0aGUgdmFsdWVzIGV4cGxp Y2l0bHkgbWVudGlvbmVkLiBGb3IgZXhhbXBsZSAnYS4uYycgZGVub3RlcyB0aGUNCiB2YWx1ZXMg J2EnLCAnYicsIGFuZCAnYycuPC90Pg0KLS0NCg0KVG8gcmVhZDoNCg0KLS0NCjx0PlRoZSBzZXF1 ZW5jZSAnLi4nICgleDJFLjJFKSBpbiBhIGZpZWxkLWJvZHkgZGVub3RlcyBhIHJhbmdlIG9mIHZh bHVlcy4gU3VjaCBhIHJhbmdlIHJlcHJlc2VudHMgYWxsIA0KIHN1YnRhZ3Mgb2YgdGhlIHNhbWUg bGVuZ3RoIHRoYXQgYXJlIGluIGluIGFscGhhYmV0aWMgb3IgbnVtZXJpYyBvcmRlciB3aXRoaW4g dGhhdCByYW5nZSwgDQogaW5jbHVkaW5nIHRoZSB2YWx1ZXMgZXhwbGljaXRseSBtZW50aW9uZWQu IEZvciBleGFtcGxlICdhLi5jJyBkZW5vdGVzIHRoZQ0KIHZhbHVlcyAnYScsICdiJywgYW5kICdj JyBhbmQgJzExLi4xMycgZGVub3RlcyB0aGUgdmFsdWVzICcxMScsICcxMicsIGFuZCAnMTMnLjwv dD4NCi0tDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBB cmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwg VzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53 My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0 dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============1884206966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1884206966==-- From ltru-bounces@ietf.org Thu Sep 01 13:34:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsxK-0007fN-49; Thu, 01 Sep 2005 13:34:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsxG-0007ce-BO for ltru@megatron.ietf.org; Thu, 01 Sep 2005 13:34:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16490 for ; Thu, 1 Sep 2005 13:34:23 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAszF-00060J-Ss for ltru@ietf.org; Thu, 01 Sep 2005 13:36:30 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 10:34:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 10:34:07 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA915BB@irvmbxw01.quest.com> Thread-Topic: include 'grandfathered' ANBF in 'Tag' description (gen-art #12) Thread-Index: AcWvG1QpsxQBhbmhQv+ETj9jLfdy/w== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 17:34:07.0967 (UTC) FILETIME=[5B3D9EF0:01C5AF1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Elwyn Davies Subject: [Ltru] include 'grandfathered' ANBF in 'Tag' description (gen-art #12) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0599060238==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0599060238== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjE6IGRlZmluaXRpb24gb2YgJ1RhZycgZmllbGQ6IFByZXN1bWFibHkgdGhlIHN5bnRh eCBvZiBhIHRhZyBvZiANCj4gPiB0eXBlICdncmFuZGZhdGhlcmVkJyBpcyByZXN0cmljdGVkIHRv IHRoZSAnZ3JhbmRmYXRoZXJlZCcgZm9ybWF0IGZyb20gczIuMT8NCj4gPiAoTG9va2luZyBhdCB0 aGUgaW5pdGlhbCBzdGF0ZSBpdCBtYXkgd2VsbCBiZSkgR2l2ZW4gdGhhdCANCj4gPiBncmFuZGZh dGhlcmVkIGl0ZW1zIGFyZSBhbGwgaW4gdGhlIGluaXRpYWwgcmVnaXN0cnkgbG9hZCB0aGlzIGlz IHBlcmhhcHMgYWNhZGVtaWMuDQo+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiANCj4gVGFnIGFwcGxp ZXMgdG8gYm90aCBncmFuZGZhdGhlcmVkIGFuZCByZWR1bmRhbnQgdHlwZXMsIGFsdGhvdWdoIHRo ZSANCj4gQU5CRiBmb3IgJ2dyYW5kZmF0aGVyZWQnIHR1cm5zIG91dCB0byBkZXNjcmliZSBib3Ro IGFjY3VyYXRlbHkuDQoNClByb3Bvc2VkIHNvbHV0aW9uOg0KDQpUbyB0aGlzIGRlc2NyaXB0aW9u Og0KDQotLQ0KPHQ+VGFnJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBjb21wbGV0ZSBsYW5ndWFn ZSB0YWcuIFRoaXMgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBl JyBoYXMgb25lIG9mIHRoZXNlIHZhbHVlczogImdyYW5kZmF0aGVyZWQiIG9yICJyZWR1bmRhbnQi LjwvdD4NCi0tDQoNCkFkZCB0aGlzIHNlbnRlbmNlOg0KDQotLQ0KTm90ZSB0aGF0IHRoZSBmaWVs ZC12YWx1ZSB3aWxsIGZvbGxvdyB0aGUgJ2dyYW5kZmF0aGVyZWQnIHByb2R1Y3Rpb24gaW4gdGhl IEFCTkYgaW4gU2VjdGlvbiAyLjEuDQotLQ0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxp cHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5x dWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcg R3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6 YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg0K --===============0599060238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0599060238==-- From ltru-bounces@ietf.org Thu Sep 01 13:36:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAszd-0000OY-Q6; Thu, 01 Sep 2005 13:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAszb-0000OH-PX for ltru@megatron.ietf.org; Thu, 01 Sep 2005 13:36:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16586 for ; Thu, 1 Sep 2005 13:36:49 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAt1b-00065d-6g for ltru@ietf.org; Thu, 01 Sep 2005 13:38:55 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 10:36:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 10:36:39 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA915C2@irvmbxw01.quest.com> Thread-Topic: remove MUST from capitalization in registry requirements (gen-art #14) Thread-Index: AcWvG66jzjLIAMwgQzGjgWWG1Q3stw== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 17:36:39.0880 (UTC) FILETIME=[B5C9B480:01C5AF1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Elwyn Davies Subject: [Ltru] remove MUST from capitalization in registry requirements (gen-art #14) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2072972818==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2072972818== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjE6IHBhcmEgYWZ0ZXIgZGVmaW5pdGlvbiBvZiAnQWRkZWQnOiB0aGUgJ01VU1QnIHJl cXVpcmVtZW50IHRvIA0KPiA+IGZvbGxvdyB0aGUgY2FwaXRhbGl6YXRpb24gY29udmVudGlvbnMg b2YgdGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzIGluIA0KPiA+IHRoZSByZWdpc3RyeSBzZWVtcyBh IGxpdHRsZSBzdHJhbmdlIGdpdmVuIGVhcmxpZXIgdmlld3Mgb24gDQo+ID4gaW50ZXJwcmV0YXRp b24gb2YgY2FzZS4NCj4gW0FkZGlzb24gUGhpbGxpcHNdDQo+IA0KPiBUaGlzIGhhcyB0aGUgZWZm ZWN0IG9mIG1ha2luZyB0aGUgcmVnaXN0cnkgZm9sbG93IHRoZSBvcHRpb25hbCANCj4gY2Fub25p Y2FsaXphdGlvbiBydWxlcyBxdW90ZWQgZWFybGllciBhbmQgbWFraW5nIHRoZSByZWdpc3RyeSBt aXJyb3IgDQo+IHRoZSBJU08gc3RhbmRhcmRzIG1vcmUgY2xvc2VseS4gVGhlIGNhc2UgaW4gdGhl IHJlZ2lzdHJ5IGhhcyBubyBpbXBhY3QgDQo+IG9uIGludGVycHJldGF0aW9uIG9mIHRhZ3M6IHRo ZXNlIGFyZSBkZWZpbmVkIHRvIGJlIGNhc2UgaW5zZW5zaXRpdmUgYXMgDQo+IHlvdSBub3RlLCBi dXQgdGhlIGNvbW1vbiBwcmFjdGljZSBoYXMgYmVlbiB0byB1c2UgdGhlIElTTyBjYXNlIGZvcm1z Lg0KDQpQcm9wb3NlZCBTb2x1dGlvbjoNCg0KUmVqZWN0IHRoaXMgY2hhbmdlIGFzIG5vdGVkIGlu IHZhcmlvdXMgdGhyZWFkcy4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9i YWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29t DQoNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpo dHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlz IG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============2072972818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2072972818==-- From ltru-bounces@ietf.org Thu Sep 01 13:56:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtIM-0001SJ-1B; Thu, 01 Sep 2005 13:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtIJ-0001SE-Tp for ltru@megatron.ietf.org; Thu, 01 Sep 2005 13:56:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17225 for ; Thu, 1 Sep 2005 13:56:09 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtKJ-0006Z1-S0 for ltru@ietf.org; Thu, 01 Sep 2005 13:58:16 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 10:56:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 10:56:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA915DF@irvmbxw01.quest.com> Thread-Topic: give ABNF for Prefix (gen-art #15) Thread-Index: AcWvHmPAI9MyrfyLS4CLmwnqWAAafg== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 17:56:02.0503 (UTC) FILETIME=[6AC3E570:01C5AF1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Elwyn Davies Subject: [Ltru] give ABNF for Prefix (gen-art #15) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1726927989==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1726927989== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+DQo+ID4gczMuMTogZGVmaW5pdGlvbiBvZiAnUHJlZml4JzogSSB0aGluayBhIG1vcmUgZm9y bWFsIChBQk5GKSANCj4gPiBkZXNjcmlwdGlvbiBvZiB0aGUgcG9zc2libGUgdmFsdWVzIG1pZ2h0 IGhlbHAuIFByZXN1bWFibHkgYW4gDQo+ID4gJ2V4dGxhbmcnIGNhbiBoYXZlIGEgcHJpbWFyeSBs YW5ndWFnZSB0YWcgYW5kIHVwIHRvIDIgb3RoZXIgZXh0bGFuZ3MgDQo+ID4gYW5kIGEgJ3Zhcmlh bnQnIGNhbiBoYXZlIGEgY29tcGxldGUgbGFuZ3VhZ2UgKGluY2x1ZGluZyB1cCB0byAzIA0KPiA+ IGV4dGxhbmdzKWFuZCBwb3NzaWJseSBhIHNjcmlwdCBhbmQvb3IgYSByZWdpb24uDQo+IFtBZGRp c29uIFBoaWxsaXBzXQ0KPiANCj4gV291bGQgdGhhdCByZWFsbHkgYWRkIGFueXRoaW5nIHRvIHRo ZSBkb2N1bWVudD8gSXQgd291bGQgYmUgZWFzeSB0byANCj4gZG8sIHllcywgYnV0IEknbSBub3Qg c3VyZSB0aGF0IGl0IGlzIHVuY2xlYXIgYXMgd3JpdHRlbi4NCg0KUHJvcG9zZWQgU29sdXRpb246 DQoNCkFsdGhvdWdoIHRoaXMgd291bGQgYmUgZWFzeSBlbm91Z2ggdG8gZG8sIHRoZSBBQk5GIHdv dWxkIGJlIHNvbWV3aGF0IGNvbXBsZXggYW5kIHdvdWxkbid0IGFkZCwgSU1ITywgdG8gdGhlIGNv bnRlbnQgb2YgdGhlIGRvY3VtZW50LiBBIHJlZ2lzdHJhdGlvbiB0aGF0IHByb3Bvc2VkIGFuIGls bGVnYWwgUHJlZml4IHdvdWxkIGJlIGNhdWdodCBieSB0aGUgaWV0Zi1sYW5ndWFnZXMgbGlzdCAo dGhlcmUgYXJlIGF0IGxlYXN0IHNvbWUgaHVtYW5zIHN1YnNjcmliZWQgdG8gdGhhdCBsaXN0KSBh bmQgdGhlIG1lYW5pbmcgb2YgdGhlIHRleHQgaXMgcXVpdGUgY2xlYXIuDQoNCkkgcHJvcG9zZSB3 ZSByZWplY3QgdGhpcyBjb21tZW50Lg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNo YWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8v d3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBh IGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============1726927989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1726927989==-- From ltru-bounces@ietf.org Thu Sep 01 14:22:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAti7-0001dK-Ut; Thu, 01 Sep 2005 14:22:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAti5-0001c5-QF for ltru@megatron.ietf.org; Thu, 01 Sep 2005 14:22:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18585 for ; Thu, 1 Sep 2005 14:22:46 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtk2-0007Q7-Ry for ltru@ietf.org; Thu, 01 Sep 2005 14:24:54 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 11:22:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 11:22:32 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91612@irvmbxw01.quest.com> Thread-Topic: ungarble description of Preferred-Value (gen-art #16) Thread-Index: AcWvIhfBbr2JxwX5Ss+PIz33e/MiZw== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 18:22:33.0069 (UTC) FILETIME=[1ED101D0:01C5AF22] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Elwyn Davies Subject: [Ltru] ungarble description of Preferred-Value (gen-art #16) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1155171399==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1155171399== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjE6IGRpc2N1c3Npb24gb2YgJ1ByZWZlcnJlZC1WYWx1ZSc6ICAnLi4uU0hPVUxEIGJl IHByZWZlcnJlZCB3aGVuIA0KPiA+IHNlbGVjdGVkIGxhbmd1YWdlIHRhZ3MuJyAgYXBwZWFycyB0 byBiZSBnYXJibGVkLi4uIEkgYW0gbm90IHN1cmUgDQo+ID4gZXhhY3RseSB3aGF0IGlzIGludGVu ZGVkLg0KPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gDQo+IFRoZSB2YWx1ZSBpbiB0aGUgcmVjb3Jk IHRoYXQgY29udGFpbnMgYSAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBzaG91bGQgDQo+IGJlIHJl cGxhY2VkIHdpdGggdGhlIHZhbHVlIGluIHRoZSBQcmVmZXJyZWQtVmFsdWUuIFRoYXQgaXMsIA0K PiBQcmVmZXJyZWQtVmFsdWUgaXMgaG93IGEgc3VidGFnIGlzIGRlcHJlY2F0ZWQgaW4gZmF2b3Ig b2YgYSBkaWZmZXJlbnQgDQo+IHN1YnRhZy4gVGhlIGNhc2VzIHdoZXJlIHRoaXMgYXBwbGllcyBh cmUgdGhlbiBlbnVtZXJhdGVkLiBTb21lIHRleHR1YWwgDQo+IHR3ZWFraW5nIHRvIG1ha2UgdGhp cyBjbGVhcmVyIGlzIHByb2JhYmx5IGNhbGxlZCBmb3IuDQoNClByb3Bvc2VkIFNvbHV0aW9uOg0K DQpSZXBsYWNlIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6DQoNCi0tDQpUaGUgZmllbGQgJ1ByZWZl cnJlZC1WYWx1ZScgY29udGFpbnMgYSBtYXBwaW5nIGJldHdlZW4gdGhlIHJlY29yZCBpbiB3aGlj aCBpdCBhcHBlYXJzIGFuZCBhIHRhZyBvciBzdWJ0YWcgd2hpY2ggU0hPVUxEIGJlIHByZWZlcnJl ZCB3aGVuIHNlbGVjdGVkIGxhbmd1YWdlIHRhZ3MuIA0KLS0NCg0KV2l0aCB0aGVzZSBzZW50ZW5j ZXM6DQoNCi0tDQpUaGUgZmllbGQgJ1ByZWZlcnJlZC1WYWx1ZScgY29udGFpbnMgYSBtYXBwaW5n IGJldHdlZW4gdGhlIHJlY29yZCBpbiB3aGljaCBpdCBhcHBlYXJzIGFuZCBhbm90aGVyIHRhZyBv ciBzdWJ0YWcuIFRoZSB2YWx1ZSBpbiB0aGlzIGZpZWxkIGlzIFNUUk9OR0xZIFJFQ09NTUVOREVE IGFzIHRoZSBiZXN0IGNob2ljZSB0byByZXByZXNlbnQgdGhlIHZhbHVlIG9mIHRoaXMgcmVjb3Jk IHdoZW4gc2VsZWN0aW5nIGEgbGFuZ3VhZ2UgdGFnLg0KLS0NCg0KQWRkaXNvbg0KDQpBZGRpc29u IFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0 dHA6Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29y ZSBXb3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVy bmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUu IA0KDQoNCg== --===============1155171399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1155171399==-- From ltru-bounces@ietf.org Thu Sep 01 14:25:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtkK-0001yZ-30; Thu, 01 Sep 2005 14:25:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtkI-0001xZ-Go for ltru@megatron.ietf.org; Thu, 01 Sep 2005 14:25:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18655 for ; Thu, 1 Sep 2005 14:25:03 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtmI-0007UK-Dm for ltru@ietf.org; Thu, 01 Sep 2005 14:27:10 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 11:24:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 11:24:54 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91615@irvmbxw01.quest.com> Thread-Topic: case of the subtag in a registration (gen-art #16) Thread-Index: AcWvImyMDiygWMq8SFWElixWP5rgog== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 18:24:55.0147 (UTC) FILETIME=[738063B0:01C5AF22] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Elwyn Davies Subject: [Ltru] case of the subtag in a registration (gen-art #16) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0882631002==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0882631002== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjI6IGxhc3QgcGFyYTogIHRoZSByZXF1aXJlbWVudCB0byBnZXQgdGhlIGNhc2UgcGF0 dGVybiBvZiBhIA0KPiA+IGNlcnRhaW4gc3Vic2V0IG9mIHRhZ3MgcmlnaHQgc2VlbXMgYW4gdW5l Y2Vzc2FyeSBodXJkbGUgLSB0aGUgDQo+ID4gcmVnaXN0cnkgY2FuIGVuZm9yY2UgdGhpcyBpZiBp dCBzZWVtcyByZWFsbHkgZGVzaXJhYmxlLg0KPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gDQo+IFRo YXQgcmVxdWlyZW1lbnQgY291bGQgYmUgcmVsYXhlZCB0byBTSE9VTEQuDQoNClByb3Bvc2VkIFNv bHV0aW9uOg0KDQpDaGFuZ2UgdGhpcyBzZW50ZW5jZToNCg0KLS0NClZhbHVlcyBpbiB0aGUgJ1N1 YnRhZycgZmllbGQgTVVTVCBiZSBsb3dlcmNhc2UgZXhjZXB0IGFzIHByb3ZpZGVkIGZvciBpbiBT ZWN0aW9uIDMuMSAoRm9ybWF0IG9mIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSku DQotLQ0KDQpUbyByZWFkOg0KDQotLQ0KPHQ+QmVmb3JlIGZvcndhcmRpbmcgYSBuZXcgcmVnaXN0 cmF0aW9uIHRvIElBTkEsIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBlbnN1cmUg dGhhdCB2YWx1ZXMgaW4gdGhlICdTdWJ0YWcnIGZpZWxkIG1hdGNoIGNhc2UgYWNjb3JkaW5nIHRv IHRoZSBkZXNjcmlwdGlvbiBpbiA8eHJlZiB0YXJnZXQ9ImlhbmFmb3JtYXQiPjwveHJlZj4uPC90 Pg0KLS0NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1 ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIEludGVybmF0 aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcvSW50ZXJu YXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMg YW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============0882631002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0882631002==-- From ltru-bounces@ietf.org Thu Sep 01 14:30:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtpn-0004pB-Qd; Thu, 01 Sep 2005 14:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtpn-0004p3-9t for ltru@megatron.ietf.org; Thu, 01 Sep 2005 14:30:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19779 for ; Thu, 1 Sep 2005 14:30:44 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtrm-00080Q-IF for ltru@ietf.org; Thu, 01 Sep 2005 14:32:51 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 11:30:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 11:30:36 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA9161E@irvmbxw01.quest.com> Thread-Topic: what happens when GF tag and new registration with different meaning collide (gen-art #17) Thread-Index: AcWvIzgAD18smxU5RfWCYowGycBHDg== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 18:30:37.0083 (UTC) FILETIME=[3F4FAEB0:01C5AF23] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Elwyn Davies Subject: [Ltru] what happens when GF tag and new registration with different meaning collide (gen-art #17) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1965536427==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1965536427== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjM6IEl0ZW0gMTI6IElzIHRoZXJlIGFueSBjaGFuY2UgdGhhdCB0aGUgbWVhbmluZyBv ZiB0aGUgDQo+ID4gZ3JhbmRmYXRoZXJlZCB0YWcgYW5kIHRoZSAobGF0ZXIpIGNvbWJpbmF0aW9u IG9mIHZhbGlkIHN1YnRhZ3MgbWlnaHQgDQo+ID4gYmUgZGlmZmVyZW50PyAgSWYgc28gd2hhdCBz aG91bGQgaGFwcGVuPyAgVGhlIHJldmlld2VyIHNob3VsZCB0YWtlIGEgDQo+ID4gdmlldyBvbiB0 aGlzIEkgdGhpbmshICBTaG91bGQgdGhlcmUgYmUgc29tZSB3b3JkcyBvbiBob3cgdG8gcHJvY2Vz cyANCj4gPiBzdWNoIG92ZXJsYXBzIGluIHRoZSB2YWxpZGF0aW5nIHByb2Nlc3NvciBzZWN0aW9u Pw0KPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gDQo+IFRoZXJlIGlzIGEgdmVyeSBzbWFsbCBjaGFu Y2Ugb2YgdGhpcyBoYXBwZW5pbmcsIHNvIGl0IHNob3VsZCBiZSBkZWFsdCANCj4gd2l0aCBhcyBu b3RlZC4NCg0KUHJvcG9zZWQgU29sdXRpb246DQoNCkFkZCB0aGUgZm9sbG93aW5nIHRleHQgYWZ0 ZXIgdGhlIGJ1bGxldCBsaXN0IGluIFNlY3Rpb24gMy41IChQb3NzaWJpbGl0aWVzIGZvciBSZWdp c3RyYXRpb24pOg0KDQotLQ0KTm90ZTogU3VidGFncyBwcm9wb3NlZCBmb3IgcmVnaXN0cmF0aW9u IHRoYXQgd291bGQgY2F1c2UgYWxsIG9yIHBhcnQgb2YgYSBncmFuZGZhdGhlcmVkIHRhZyB0byBi ZWNvbWUgcmVkdW5kYW50IGJ1dCB3aG8ncyBtZWFuaW5nIGNvbmZsaWN0cyB3aXRoIG9yIGFsdGVy cyB0aGUgbWVhbmluZyBvZiB0aGUgZ3JhbmRmYXRoZXJlZCB0YWcgTVVTVCBiZSByZWplY3RlZC4N Ci0tDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNo aXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzND IEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5v cmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJl Lg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============1965536427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1965536427==-- From ltru-bounces@ietf.org Thu Sep 01 14:31:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtqe-0005Eg-D7; Thu, 01 Sep 2005 14:31:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtqb-00052G-EU for ltru@megatron.ietf.org; Thu, 01 Sep 2005 14:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19855 for ; Thu, 1 Sep 2005 14:31:33 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtsb-00081s-BD for ltru@ietf.org; Thu, 01 Sep 2005 14:33:41 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 01 Sep 2005 14:31:23 -0400 id 003685A1.431748FB.00004AF8 From: "Scott Hollenbeck" To: "'Addison Phillips'" , "'LTRU Working Group'" Subject: RE: [Ltru] ungarble description of Preferred-Value (gen-art #16) Date: Thu, 1 Sep 2005 14:31:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CA91612@irvmbxw01.quest.com> Thread-Index: AcWvIhfBbr2JxwX5Ss+PIz33e/MiZwAAMUWg Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Thursday, September 01, 2005 2:23 PM > To: LTRU Working Group > Cc: Elwyn Davies > Subject: [Ltru] ungarble description of Preferred-Value (gen-art #16) > > > > s3.1: discussion of 'Preferred-Value': '...SHOULD be > preferred when > > > selected language tags.' appears to be garbled... I am not sure > > > exactly what is intended. > > [Addison Phillips] > > > > The value in the record that contains a 'Preferred-Value' > field should > > be replaced with the value in the Preferred-Value. That is, > > Preferred-Value is how a subtag is deprecated in favor of a > different > > subtag. The cases where this applies are then enumerated. > Some textual > > tweaking to make this clearer is probably called for. > > Proposed Solution: > > Replace the following sentence: > > -- > The field 'Preferred-Value' contains a mapping between the > record in which it appears and a tag or subtag which SHOULD > be preferred when selected language tags. > -- > > With these sentences: > > -- > The field 'Preferred-Value' contains a mapping between the > record in which it appears and another tag or subtag. The > value in this field is STRONGLY RECOMMENDED as the best > choice to represent the value of this record when selecting a > language tag. While I understand the desire to emphasize "strongly" as "STRONGLY", "STRONGLY" isn't an RFC 2119 key word. It's not a good idea to make it look like one. "strongly" would be better. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 14:33:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtst-0006WV-O7; Thu, 01 Sep 2005 14:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtss-0006W0-CK for ltru@megatron.ietf.org; Thu, 01 Sep 2005 14:33:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20313 for ; Thu, 1 Sep 2005 14:33:55 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtuq-0008D5-0v for ltru@ietf.org; Thu, 01 Sep 2005 14:36:01 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 11:33:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 11:33:45 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91625@irvmbxw01.quest.com> Thread-Topic: personal comment: bad GF sentence in S3.2 Thread-Index: AcWvI6kJgXzmQVgNS0SA42fMOMKYqA== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 18:33:46.0444 (UTC) FILETIME=[B02DE0C0:01C5AF23] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ltru] personal comment: bad GF sentence in S3.2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0420022961==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0420022961== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBub3RpY2UgdGhhdCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGlzIG5vdyBmYWN0dWFsbHkgaW5j b3JyZWN0Og0KDQotLQ0KVGhlIGdyYW5kZmF0aGVyZWQgZW50cmllcyBhcmUgdGhvc2UgdGhhdCBj YW4gbmV2ZXIgYmUgbGVnYWwgdW5kZXIgdGhvc2Ugc2FtZSBwcm92aXNpb25zLg0KLS0NCg0KSSBw cm9wb3NlIHdlIGNoYW5nZSBpdCB0byBzYXk6DQoNCi0tDQpUaGUgZ3JhbmRmYXRoZXJlZCBlbnRy aWVzIGluY2x1ZGUgdGhvc2UgdGhhdCBjYW4gbmV2ZXIgYmUgbGVnYWwgdW5kZXIgdGhvc2Ugc2Ft ZSBwcm92aXNpb25zLg0KLS0NCg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9u IEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNoYWly LCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8vd3d3 LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZl YXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============0420022961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0420022961==-- From ltru-bounces@ietf.org Thu Sep 01 14:37:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtwW-0001Ei-Nz; Thu, 01 Sep 2005 14:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtwV-0001DE-9r for ltru@megatron.ietf.org; Thu, 01 Sep 2005 14:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21625 for ; Thu, 1 Sep 2005 14:37:39 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtyT-0000Gq-9W for ltru@ietf.org; Thu, 01 Sep 2005 14:39:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 11:37:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 11:37:31 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA9162C@irvmbxw01.quest.com> Thread-Topic: personal comment: another GF text problem Thread-Index: AcWvJC9zY/9ynvCkS+K+sTMgTBmxIw== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 18:37:31.0710 (UTC) FILETIME=[3672BDE0:01C5AF24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ltru] personal comment: another GF text problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0470266583==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0470266583== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBhbHNvIG5vdGljZSB0aGF0IHRoaXMgc2VudGVuY2U6DQoNCi0tDQpSZWNvcmRzIG9mIHR5cGUg J2dyYW5kZmF0aGVyZWQnIE1BWSBoYXZlIHRoZWlyIHR5cGUgY29udmVydGVkIHRvICdyZWR1bmRh bnQnOiBzZWUgU2VjdGlvbiAzLjcgKEluaXRpYWxpemF0aW9uIG9mIHRoZSBSZWdpc3RyaWVzKSBm b3IgbW9yZSBpbmZvcm1hdGlvbi4NCi0tDQoNClJlZmVycyB0byB0ZXh0IHRoYXQgaGFzIGJlZW4g cmVtb3ZlZCBmcm9tIFMzLjcuIEl0IGlzIG5vdyByZXByZXNlbnRlZCBieSBTMy4zLCBwb2ludCAx Mi4gSSBwcm9wb3NlIHdlIGNvcnJlY3QgdGhlIHRleHQgdG8gc2F5Og0KDQotLQ0KUmVjb3JkcyBv ZiB0eXBlICdncmFuZGZhdGhlcmVkJyBNQVkgaGF2ZSB0aGVpciB0eXBlIGNvbnZlcnRlZCB0byAn cmVkdW5kYW50Jzogc2VlIFNlY3Rpb24gMy4zLCBpdGVtICMxMiBmb3IgbW9yZSBpbmZvcm1hdGlv bi4gVGhlIGRlY2lzaW9uIG1ha2luZyBwcm9jZXNzIGFib3V0IHdoaWNoIHRhZ3Mgd2VyZSBncmFu ZGZhdGhlcmVkIGFuZCB3aGljaCB3ZXJlIG1hZGUgcmVkdW5kYW50IGlzIGRlc2NyaWJlZCBpbiBb ZHJhZnQtaW5pdGlhbF0uIA0KLS0NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlv biBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFp ciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3 dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBm ZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============0470266583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0470266583==-- From ltru-bounces@ietf.org Thu Sep 01 14:57:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuFj-0000Kj-8B; Thu, 01 Sep 2005 14:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuFh-00005h-Gl for ltru@megatron.ietf.org; Thu, 01 Sep 2005 14:57:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22850 for ; Thu, 1 Sep 2005 14:57:28 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAuHf-00010V-O5 for ltru@ietf.org; Thu, 01 Sep 2005 14:59:36 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 11:57:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 11:57:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB436CE@irvmbxw01.quest.com> Thread-Topic: make hypothetical nature of extlang registrations clear (gen-art #17) Thread-Index: AcWvJvJnXnMOpHw0QweTE9g1RgMZ1Q== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 18:57:17.0929 (UTC) FILETIME=[F97D6590:01C5AF26] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Elwyn Davies Subject: [Ltru] make hypothetical nature of extlang registrations clear (gen-art #17) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0251788031==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0251788031== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjQ6IHBhcmEgMiBhbmQgcGFyYSBuZXh0IGJ1dCBvbmUgYWZ0ZXIgRmlndXJlIDU6IEF0 IGZpcnN0IHNpZ2h0IA0KPiA+IHRoZXNlIHBhcmFzIGFwcGVhciB0byBjb25mbGljdD8gIHRoZSBz ZWNvbmQgb25lIGFwcGVhcnMgdG8gaW5kaWNhdGUgDQo+ID4gdGhhdCB0eXBlICdleHRsYW5nJyBz dWJ0YWdzIGNhbiBiZSByZWdpc3RlcmVkIGJ1dCB0aGV5IGFyZSBub3QgDQo+ID4gbWVudGlvbmVk IGluIHRoZSBmaXJzdCBvbmUuIFByZXN1bWFibHkgdGhpcyBpcyBiZWNhdXNlIGV4dGxhbmcgaXMg DQo+ID4gY3VycmVudGx5IHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLCBidXQgaXQgd291bGQgYmUg Z29vZCB0byBtZW50aW9uIA0KPiA+IHRoaXMgaW4gcGFyYSAyLiAgVGV4dCBzYXlpbmcgc29tZXRo aW5nIGxpa2UgJ2V4dGxhbmcgcmVjb3JkcyB3aWxsIA0KPiA+IGFsc28gYmUgYWJsZSB0byBiZSBy ZWdpc3RlcmVkIGJ5IHRoaXMgcHJvY2VzcyB3aGVuIHRoZXkgYXJlIGludHJvZHVjZWQnLg0KPiBb QWRkaXNvbiBQaGlsbGlwc10NCj4gDQo+IFRoZSBrZXkgd29yZCBpbiBwYXJhIDIgaXMgImluZGVw ZW5kZW50bHkiLiBUaGVyZSBhcmUgYWxzbyANCj4gcmVnaXN0cmF0aW9ucyB0aGF0IGNhbiBvY2N1 ciBkdWUgdG8gc3RhbmRhcmRzIGJvZHkgYWN0aXZpdHkgDQo+IChhc3NpZ25tZW50IG9mIGEgbmV3 IElTTw0KPiAzMTY2IGNvZGUsIGZvciBleGFtcGxlKS4NCj4gDQo+IEV4dGxhbmdzIGNhbm5vdCBj dXJyZW50bHkgYmUgcmVnaXN0ZXJlZCwgYXMgbm90ZWQgdGhleSBhcmUgcmVzZXJ2ZWQuDQo+IEhv d2V2ZXIsIHRoZSBydWxlcyBmb3IgZXh0bGFuZ3MgYXJlIHNwZWxsZWQgb3V0IHNvIHRoYXQgDQo+ IGltcGxlbWVudGF0aW9ucyBjYW4gdGFrZSB0aGVtIGludG8gYWNjb3VudC4gVGhlcmVmb3JlIGl0 IGlzIGltcG9ydGFudCANCj4gdG8gcG9pbnQgb3V0IHRoYXQgdGhleSBtdXN0IGhhdmUgYSBQcmVm aXggYWdhaW4gaGVyZS4gVGhlIGNvbmRpdGlvbmFsIA0KPiBuYXR1cmUgb2YgdGhlaXIgZXhpc3Rl bmNlIG1pZ2h0IGJlIGJldHRlciBtaXJyb3JlZCBieSB0aGUgd29yZGluZywgdGhvdWdoLg0KDQpQ cm9wb3NlZCBTb2x1dGlvbjoNCg0KQWx0aG91Z2ggbWFueSBwZW9wbGUgc2VlbSB0byBtaXNzIHRo ZSB3b3JkICJpbmRlcGVuZGVudGx5IiwgcGFyYTIgcmVhbGx5IGRvZXNuJ3QgbmVlZCB0byBiZSBt b2RpZmllZC4gSSBwcm9wb3NlIHdlIG1vZGlmeSB0aGlzIHNlbnRlbmNlOg0KDQotLQ0KVmFyaWFu dCBhbmQgZXh0bGFuZyBzdWJ0YWdzIGFyZSBhbHdheXMgcmVnaXN0ZXJlZCBmb3IgdXNlIHdpdGgg YSBwYXJ0aWN1bGFyIHJhbmdlIG9mIGxhbmd1YWdlIHRhZ3MuDQotLQ0KDQpUbyBzYXk6DQoNCi0t DQpWYXJpYW50IHN1YnRhZ3MgYXJlIGFsd2F5cyByZWdpc3RlcmVkIGZvciB1c2Ugd2l0aCBhIHBh cnRpY3VsYXIgcmFuZ2Ugb2YgbGFuZ3VhZ2UgdGFncy4NCi0tDQoNCkFuZCB0aGVuIGZvbGxvd2lu ZyB0aGF0IHBhcmFncmFwaCBhIG5ldyBwYXJhIHNheWluZzoNCg0KLS0NCjx0PkV4dGVuZGVkIGxh bmd1YWdlIHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9uLiBU aGVzZSBzdWJ0YWdzIHdpbGwgYmUgUkVRVUlSRUQgdG8gaW5jbHVkZSBleGFjdGx5IG9uZSAiUHJl Zml4IiBmaWVsZCBvbmNlIHRoZXkgYXJlIGFsbG93ZWQgZm9yIHJlZ2lzdHJhdGlvbi48L3Q+DQot LQ0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3Qg U29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25h bGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlv bmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBh cmNoaXRlY3R1cmUuIA0KDQoNCg== --===============0251788031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0251788031==-- From ltru-bounces@ietf.org Thu Sep 01 14:59:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuHH-0001F5-2f; Thu, 01 Sep 2005 14:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuHF-0001Ex-Iy for ltru@megatron.ietf.org; Thu, 01 Sep 2005 14:59:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22930 for ; Thu, 1 Sep 2005 14:59:06 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAuJF-00012q-UW for ltru@ietf.org; Thu, 01 Sep 2005 15:01:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 11:59:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] At least one prefix for variant (GenArt) Date: Thu, 1 Sep 2005 11:58:59 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB436D0@irvmbxw01.quest.com> Thread-Topic: [Ltru] At least one prefix for variant (GenArt) Thread-Index: AcWvFnslbJ3EIFrGQ/+YeMRU9KQR8wAAEt9AAAQSCtA= From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 18:59:00.0229 (UTC) FILETIME=[36772350:01C5AF27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Note: this is gen-art #18. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Addison Phillips > Sent: 2005?9?1? 10:04 > To: John.Cowan > Cc: LTRU Working Group > Subject: RE: [Ltru] At least one prefix for variant (GenArt) >=20 > Proposed: >=20 > Change this: >=20 > -- > Prefix's field-value contains a language tag with which this subtag = MAY be > used to form a new language tag, perhaps with other subtags as well. > -- >=20 > To read like this: >=20 > -- > Prefix's field-value contains a language tag with which this subtag = MAY be > used to form a new language tag, perhaps with other subtags as well, = or > the special tag "*", indicating that this subtag could be considered > appropriate with any combination of subtags. > -- >=20 > This neatly avoids the whole mess, while giving us the desired = results. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: John.Cowan [mailto:jcowan@reutershealth.com] > > Sent: 2005?9?1? 9:58 > > To: Addison Phillips > > Cc: LTRU Working Group > > Subject: Re: [Ltru] At least one prefix for variant (GenArt) > > > > Addison Phillips scripsit: > > > > > We did debate this previously. The question was whether the = community > > > could make judgments about generic subtags, either for acceptance = or > > > application of them. Requiring at least one prefix effectively = limits > > > variants to the description of particular language variations. > > > > Indeed. > > > > > There is a way to fix this without removing the requirement. > > > > [snip] > > > > > The problem here, of course, is that "range" is a "matching" = beast. > > > > I think that makes the cure worse than the disease. "Prefix: *" is = just > a > > verbose way of saying "no prefix required". > > > > I request (as part of Last Call) that this be reconsidered by the = WG. > > Variants without prefixes may require heightened scrutiny by ietf- > > languages > > and the LSR, but I do not think they should be forbidden altogether. > > > > -- > > John Cowan jcowan@reutershealth.com > > At times of peril or dubitation, http://www.ccil.org/~cowan > > Perform swift circular ambulation, = http://www.reutershealth.com > > With loud and high-pitched ululation. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 15:01:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuJM-000256-UV; Thu, 01 Sep 2005 15:01:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuJK-000250-SK for ltru@megatron.ietf.org; Thu, 01 Sep 2005 15:01:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23044 for ; Thu, 1 Sep 2005 15:01:15 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAuLL-00016u-Ao for ltru@ietf.org; Thu, 01 Sep 2005 15:03:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 12:01:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 12:01:08 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB436D6@irvmbxw01.quest.com> Thread-Topic: choice of subtags in multilingual documents (gen-art #19) Thread-Index: AcWvJ3yFe/LOGWWYRGKnKgdejXmLAA== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 19:01:09.0525 (UTC) FILETIME=[83882450:01C5AF27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Elwyn Davies Subject: [Ltru] choice of subtags in multilingual documents (gen-art #19) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0338962097==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0338962097== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHM0LjE6IEl0ZW0gMjogZXhhbXBsZTogSSBhbSBub3QgY2xlYXIgaG93IG9uZSB3b3VsZCBy ZXByZXNlbnQgdGhlIA0KPiA+IGNvbWJpbmF0aW9uIG9mIGxhdGluIGFuZCBicmFpbGxlIHNpbmNl IG9ubHkgb25lIHNjcmlwdCBzdWJ0YWcgc2VlbXMgDQo+ID4gdG8gYmUgYWxsb3dlZC4gIE1heWJl IHRoZXJlIGlzIGEgc3BlY2lhbCBzdWJ0YWcgZm9yIHRoZSBjb21iaW5hdGlvbj8gDQo+ID4gb3Ig aXMgaXQgaW50ZW5kZWQgdGhhdCBib3RoIGNvbXBsZXRlIHRhZ3MgYXJlIHVzZWQ/DQo+IFtBZGRp c29uIFBoaWxsaXBzXQ0KPiANCj4gSWYgcnVucyBvZiB0ZXh0IG1heSBiZSBtYXJrZWQgdXAgaW5k aXZpZHVhbGx5LCB0aGVuIHRoZXkgc2hvdWxkIGJlLg0KPiBPdGhlcndpc2UgdGhlIGxhbmd1YWdl IHRhZyBpbmRpY2F0ZXMgdGhlIGludGVuZGVkIGF1ZGllbmNlIG9mIHRoZSANCj4gY29udGVudCAo d2hpY2ggd2lsbCBiZSBvbmUgb3IgdGhlIG90aGVyKS4gWW91IGNvdWxkIGVxdWFsbHkgc2F5IHRo ZSANCj4gc2FtZSBvZiBhIGRvY3VtZW50IHRoYXQgbWl4ZXMgRW5nbGlzaCBhbmQgRnJlbmNoIG9y IGVuLVVTIGFuZCBlbi1HQi4NCj4gDQo+IFllcywgbXVsdGlsaW5ndWFsIGRvY3VtZW50cyAoYW5k IG5vdCBqdXN0IG11bHRpLXNjcmlwdCBkb2N1bWVudHMpIA0KPiBleGlzdCB3aGljaCBkbyBub3Qg aGF2ZSBhbnkgcGFydGljdWxhciBwcmltYXJ5IGxhbmd1YWdlIHRoYXQgaXMgDQo+ICJhYm92ZSIg dGhlIG90aGVycywgYnV0IHRoYXQgaXMgYSBsaW1pdGF0aW9uIG9mIHRoZSBoZWFkZXJzIG9yIG90 aGVyIA0KPiBtZXRhLWRhdGEgc3RydWN0dXJlcyB0aGF0IHVzZSBsYW5ndWFnZSB0YWdzLCBub3Qg dGhlIHRhZ3MgdGhlbXNlbHZlcy4gDQo+IFRhZ3MgaWRlbnRpZnkgb25lIGxhbmd1YWdlIHVuYW1i aWd1b3VzbHksIG5vdCBtdWx0aXBsZSBsYW5ndWFnZXMgb3IgDQo+IGxhbmd1YWdlIGZvcm1zIG1p eGVkIHRvZ2V0aGVyLiBUaGUgaGlnaGVyIGxldmVsIHByb3RvY29sIG11c3QgZGVhbCB3aXRoIHRo YXQuDQo+IA0KPiBTZWUgZm9yIGV4YW1wbGUgdGhlIHNlY3Rpb24gIlR3byB0eXBlcyBvZiBsYW5n dWFnZSBkZWNsYXJhdGlvbiIgaW46DQo+IA0KPiBodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlv bmFsL3R1dG9yaWFscy9sYW5ndWFnZS1kZWNsLw0KDQpQcm9wb3NhbCBSZXNvbHV0aW9uOg0KDQpJ IHRoaW5rIHdlIGNhbiByZWplY3QgdGhpcyBwYXJ0aWN1bGFyIGl0ZW0sIGFsdGhvdWdoIHdlIG1p Z2h0IGNvbnNpZGVyIG1vcmUgdHV0b3JpYWwgbWF0ZXJpYWwgb24gdGhpcyB0b3BpYyBpbiBTZWN0 aW9uIDQuMSAoQ2hvaWNlIG9mIExhbmd1YWdlIFRhZykuDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMN Ckdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVz dC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3Jv dXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6YXRp b24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg0K --===============0338962097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0338962097==-- From ltru-bounces@ietf.org Thu Sep 01 15:19:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAubB-0005Lf-Q6; Thu, 01 Sep 2005 15:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAub9-0005La-R7 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 15:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24934 for ; Thu, 1 Sep 2005 15:19:40 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAudA-0001id-G1 for ltru@ietf.org; Thu, 01 Sep 2005 15:21:48 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 12:19:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 12:19:34 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB436F7@irvmbxw01.quest.com> Thread-Topic: clarifying what a redundant tag is (gen-art #20) Thread-Index: AcWvKg8o0I7WfDykTjWVGjez1Pv99w== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 19:19:34.0721 (UTC) FILETIME=[1647AB10:01C5AF2A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Elwyn Davies Subject: [Ltru] clarifying what a redundant tag is (gen-art #20) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0608800881==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0608800881== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMyLjIuODogSW4gcmVhZGluZyB0aGUgZG9jdW1lbnQgZm9yIHRoZSBmaXJzdCB0aW1lLCBJ IGZvdW5kIHRoZSB1c2UgDQo+ID4gb2YgJ3JlZHVuZGFudCcgYXMgYSB0eXBlIHNsaWdodGx5IGNv bmZ1c2luZy4gIEl0IHdvdWxkIGhlbHAgdG8gDQo+ID4gY2xhcmlmeSB0aGluZ3MgaWYgdGV4dCB3 YXMgYWRkZWQgKHByb2JhYmx5IGluIHRoaXMgc2VjdGlvbikgdG8gdGhlIA0KPiA+IGVmZmVjdCB0 aGF0IHN1YnRhZ3MgdGhhdCBkb24ndCBjb21lIGZyb20gUkZDMzA2NiBidXQgZXZlbnR1YWxseSBi ZWNvbWUgJ3JlZHVuZGFudCcNCj4gPiBhcmUgTk9UIGhhbmRsZWQgYnkgdGhlIHVzZSBvZiB0aGUg J3JlZHVuZGFudCcgdHlwZSBidXQgYnkgbWFya2luZyANCj4gPiB0aGVtIGFzIGRlcHJlY2F0ZWQg YW5kIChtYXliZSkgYWRkaW5nIGEgUHJlZmVycmVkLVZhbHVlIGFzIGRlc2NyaWJlZCBpbiBzMy4x Lg0KPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gDQo+IFRoYXQgaXNuJ3QgY29ycmVjdC4gUmVkdW5k YW50IHRhZ3MgYXJlIHZhbHVlcyByZWdpc3RlcmVkIHVuZGVyIFJGQyANCj4gMzA2NiB0aGF0IGFy ZSBub3cgZGVmaW5lZCBieSAoc2VwYXJhdGUpIHN1YnRhZ3MgaW4gdGhlIHJlZ2lzdHJ5LiBGb3Ig DQo+IGV4YW1wbGUsIHRoZSB0YWcgInpoLUhhbnQiIGlzIG5vdyBkZWZpbmVkIGJ5IHRoZSBzdWJ0 YWdzICd6aCcgYW5kIA0KPiAnSGFudCcgYW5kIHRodXMgaXMgcmVkdW5kYW50LiBJdCBpcyBOT1Qg ZGVwcmVjYXRlZCBhbmQgbmV2ZXIgbWF5IGJlIGRlcHJlY2F0ZWQgYnkgcnVsZS4NCj4gVGhpcyBp cyBpbiBjb250cmFzdCB0byBncmFuZGZhdGhlcmVkIHZhbHVlcywgd2hpY2ggbWF5IHNvbWV0aW1l cyANCj4gYmVjb21lIHJlZHVuZGFudCAodGhlIG9ubHkgdGltZSBhIHplYnJhIGluIHRoaXMgem9v IG1heSBjaGFuZ2UgaXRzIA0KPiBzdHJpcGVzKSBvciBtYXkgYmUgZGVwcmVjYXRlZCwgYnV0IHdo aWNoIGFsd2F5cyBtYWludGFpbiB0aGVpciB2YWxpZGl0eS4NCj4gDQo+IFdoYXQncyBpbXBvcnRh bnQgdG8gbm90ZSBpcyB0aGF0IHJlZHVuZGFudCB0YWdzIGFyZSB2YWxpZC4NCg0KVW5sZXNzIG90 aGVyd2lzZSBub3RlZCBieSBhbiBlbWFpbCwgSSBhbSBpbmNvcnBvcmF0aW5nIEVsd3luJ3MgZWRp dG9yaWFsIGNvbW1lbnRzLiBUaGlzIG9uZSBzZWVtcyB0byByZXF1aXJlIGEgcmVzcG9uc2UuDQoN ClByb3Bvc2VkIFNvbHV0aW9uOg0KDQpBZGQgdGhlIGZvbGxvd2luZyBjbGFyaWZ5aW5nIHRleHQg dG8gU2VjdGlvbiAyLjIuOCAoUHJlZXhpc3RpbmcgUkZDIDMwNjYgUmVnaXN0cmF0aW9ucyk6DQoN Ci0tDQpHcmFuZGZhdGhlcmVkIHRhZ3MgY29udGFpbiBvbmUgb3IgbW9yZSBzdWJ0YWdzIHRoYXQg YXJlIG5vdCBkZWZpbmVkIGluIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgKHNlZSBbU2Vj dGlvbiAzXSkuIFJlZHVuZGFudCB0YWdzIGNvbnNpc3QgZW50aXJlbHkgb2Ygc3VidGFncyBkZWZp bmVkIGFib3ZlIGFuZCB3aG9zZSBpbmRlcGVuZGVudCByZWdpc3RyYXRpb24gaXMgc3VwZXJzZWRl ZCBieSB0aGlzIGRvY3VtZW50Lg0KLS0NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXph dGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpD aGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDov L3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3Qg YSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============0608800881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0608800881==-- From ltru-bounces@ietf.org Thu Sep 01 15:29:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAukU-0001S9-C8; Thu, 01 Sep 2005 15:29:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAukS-0001S4-4r for ltru@megatron.ietf.org; Thu, 01 Sep 2005 15:29:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25594 for ; Thu, 1 Sep 2005 15:29:16 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAumR-00020D-Lq for ltru@ietf.org; Thu, 01 Sep 2005 15:31:24 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 12:29:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 12:28:54 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB43709@irvmbxw01.quest.com> Thread-Topic: frowning on long texts (gen-art #21) Thread-Index: AcWvK10CRq0p1OLnSX+uAzaoUMKwhA== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 19:29:05.0326 (UTC) FILETIME=[6A6314E0:01C5AF2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Elwyn Davies Subject: [Ltru] frowning on long texts (gen-art #21) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0343843472==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0343843472== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjE6IGRpc2N1c3Npb24gb2YgQ29tbWVudCBmaWVsZDogcy9mcm93bmVkIG9uL3N0cm9u Z2x5IE5PVA0KPiBSRUNPTU1FTkRFRC8NCj4gW0FkZGlzb24gUGhpbGxpcHNdDQo+IA0KPiBJdCdz IG9rYXkgdG8gbWFrZSB0aGlzIG5vcm1hdGl2ZSwgYnV0IHRoZSBpZGVhIHdhcyB0byBnaXZlIGEg c2Vuc2Ugb2YgDQo+IHRoZSBsaWtlbHkgYmVoYXZpb3Igb2YgdGhlIGNvbW11bml0eS4gSXQgaXMg cG9zc2libGUgdGhhdCBhIGxvbmcgDQo+IHNjcmVlZCBtaWdodCBiZSBqdXN0aWZpZWQgZnJvbSB0 aW1lIHRvIHRpbWUuDQoNClByb3Bvc2VkIFNvbHV0aW9uOg0KDQpUaGlzIHBhcmFncmFwaCBjdXJy ZW50bHkgcmVhZHMgYXMgZm9sbG93czoNCi0tDQo8dD5UaGUgZmllbGQgJ0NvbW1lbnRzJyBNQVkg YXBwZWFyIG1vcmUgdGhhbiBvbmNlIHBlciByZWNvcmQuIFRoaXMgZmllbGQgTUFZIGJlIGluc2Vy dGVkIG9yIGNoYW5nZWQgdmlhIHRoZSByZWdpc3RyYXRpb24NCiAgIHByb2Nlc3MgYW5kIG5vIGd1 YXJhbnRlZSBvZiBzdGFiaWxpdHkgaXMgcHJvdmlkZWQuIFRoZSBjb250ZW50IG9mIHRoaXMgZmll bGQgaXMgbm90IHJlc3RyaWN0ZWQsIGV4Y2VwdCBieSB0aGUgbmVlZCB0byByZWdpc3RlciB0aGUg aW5mb3JtYXRpb24sIHRoZSBzdWl0YWJpbGl0eSBvZiB0aGUgcmVxdWVzdCwgYW5kIGJ5IHJlYXNv bmFibGUgcHJhY3RpY2FsIHNpemUgbGltaXRhdGlvbnMuIExvbmcgdGV4dHMgYWJvdXQgYSBwYXJ0 aWN1bGFyIHN1YnRhZyBhcmUgZnJvd25lZCB1cG9uLjwvdD4NCi0tDQoNCkkgdGhpbmsgdGhlIGxh c3Qgc2VudGVuY2UgaXMgcmVkdW5kYW50LCBzaW5jZSB0aGUgcHJldmlvdXMgcGhyYXNlIGlzICJy ZWFzb25hYmxlIHByYWN0aWNhbCBzaXplIGxpbWl0YXRpb25zIi4gVGhpcyBzZW50ZW5jZSB1c2Vk IHRvIHVzZSB0aGUgZXNvdGVyaWMgd29yZCAic2NyZWVkcyIgaW4gcGxhY2Ugb2YgdGhlIHdvcmQg InRleHRzIiB0byBpbmRpY2F0ZSB0aGUgKGFudGljaXBhdGVkKSBkaXNwbGVhc3VyZSBvZiB0aGUg Y29tbXVuaXR5Lg0KDQpJIHByb3Bvc2UgdGhhdCB3ZSBqdXN0IHJlbW92ZSB0aGUgc2VudGVuY2Uu DQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRl Y3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIElu dGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcv SW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0K SXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============0343843472== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0343843472==-- From ltru-bounces@ietf.org Thu Sep 01 16:05:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvJ8-0003L7-QN; Thu, 01 Sep 2005 16:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvJ7-0003L2-5F for ltru@megatron.ietf.org; Thu, 01 Sep 2005 16:05:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27476 for ; Thu, 1 Sep 2005 16:05:07 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAvL7-0003At-1n for ltru@ietf.org; Thu, 01 Sep 2005 16:07:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 13:04:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Sep 2005 13:04:52 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB43737@irvmbxw01.quest.com> Thread-Topic: updated editor's copy Thread-Index: AcWvMGNCx+J61j+7QEO1b5ZyaUIQfA== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 01 Sep 2005 20:04:52.0422 (UTC) FILETIME=[6A27EE60:01C5AF30] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] updated editor's copy X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1112409434==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1112409434== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U2luY2Ugd2UgaGF2ZSBhIG51bWJlciBvZiBwcm9wb3NlZCBjaGFuZ2VzLCBJIGhhdmUgdXBkYXRl ZCBhbiBlZGl0b3IncyBjb3B5IG9mIGRyYWZ0LTEzIGFuZCBwb3N0ZWQgaXQgb24gdGhlIGludGVy LWxvY2FsZSBzaXRlLCBhbG9uZyB3aXRoIGEgZGlmZiBmcm9tIGRyYWZ0LTEyLiBUaGlzIGluY2x1 ZGVzIGFsbCBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlcyB0byBkYXRlLg0KDQpodHRwOi8vd3d3Lmlu dGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LTEzLnR4dA0KaHR0cDov L3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0xMy5odG1s DQpodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5 LTEzLnhtbA0KDQpodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtcmVnaXN0cnkt MTItMTMtZGlmZi5odG1sDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFs aXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0K DQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0 cDovL3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBu b3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============1112409434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1112409434==-- From ltru-bounces@ietf.org Thu Sep 01 16:15:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvPY-0007Ch-Pq; Thu, 01 Sep 2005 16:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvPX-0007Bs-Q0 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 16:11:48 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27811 for ; Thu, 1 Sep 2005 16:11:45 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAvO4-0000sp-D8 for ltru@lists.ietf.org; Thu, 01 Sep 2005 22:10:16 +0200 Received: from c-180-160-241.hh.dial.de.ignite.net ([62.180.160.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:10:16 +0200 Received: from nobody by c-180-160-241.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:10:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 22:08:48 +0200 Organization: Lines: 14 Message-ID: <43175FD0.3232@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CA91542@irvmbxw01.quest.com> <20050901165823.GB17084@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-241.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: At least one prefix for variant (GenArt) #18 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John.Cowan wrote: > I request (as part of Last Call) that this be reconsidered > by the WG. You tested the idea of generic variants on the review list (among others -north, -east, -west, -south, and what I recall as -familiar, but that wasn't your proposal) The result of this discussion was "bad idea" (okay, I wasn't sure that it's necessarily bad, I said "utter dubious" for your old examples). Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 16:25:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvcK-0004ap-7y; Thu, 01 Sep 2005 16:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvcI-0004af-TM for ltru@megatron.ietf.org; Thu, 01 Sep 2005 16:24:59 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28200 for ; Thu, 1 Sep 2005 16:24:56 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAvaB-0003s6-8n for ltru@lists.ietf.org; Thu, 01 Sep 2005 22:22:47 +0200 Received: from c-180-160-241.hh.dial.de.ignite.net ([62.180.160.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:22:47 +0200 Received: from nobody by c-180-160-241.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:22:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 22:19:52 +0200 Organization: Lines: 13 Message-ID: <43176268.7338@xyzzy.claranet.de> References: <20050901160952.TOEY6799.mta6.adelphia.net@megatron.ietf.org> <006c01c5af12$96fc0ca0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-241.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > http://www1.ietf.org/mail-archive/web/ltru/current/msg03523.html Ouch... I had seen this but thought it's a dupe, stupid, thanks. In other words, your part is ready as far as Elwyn is concerned, fine. You've probably seen that something supported by you was approved on the review list: One more tag for the "redundant" section, and a corresponding "deprecated" "grandfathered" tag. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 16:33:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvk6-0000Fe-Fh; Thu, 01 Sep 2005 16:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvk4-0000FZ-8S for ltru@megatron.ietf.org; Thu, 01 Sep 2005 16:33:00 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28426 for ; Thu, 1 Sep 2005 16:32:58 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EAvi1-00063e-KT for ltru@lists.ietf.org; Thu, 01 Sep 2005 22:30:53 +0200 Received: from c-180-160-241.hh.dial.de.ignite.net ([62.180.160.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:30:53 +0200 Received: from nobody by c-180-160-241.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:30:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 22:24:07 +0200 Organization: Lines: 8 Message-ID: <43176367.1FE1@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CA915BA@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-241.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: numeric ranges in the registry (gen-art #11) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: [...] > subtags of the same length that are in in alphabetic or > numeric order within that range, including the values > explicitly mentioned. [...] ACK, good enough, bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 16:36:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvnh-0002mU-VM; Thu, 01 Sep 2005 16:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvng-0002mP-VJ for ltru@megatron.ietf.org; Thu, 01 Sep 2005 16:36:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28608 for ; Thu, 1 Sep 2005 16:36:43 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAvpf-000443-4j for ltru@ietf.org; Thu, 01 Sep 2005 16:38:50 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 13:36:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt Date: Thu, 1 Sep 2005 13:36:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB43762@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt Thread-Index: AcWvM5oU2C3locNcTzGaOUPUYLhZXgAAQBEg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 01 Sep 2005 20:36:25.0491 (UTC) FILETIME=[D2835630:01C5AF34] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Not true. Zh-cmn is NOT a valid 3066bis tag. It cannot be redundant currently. = However, "zh-guoyu" should have a Preferred-Value of "zh-cmn".=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Frank Ellermann > Sent: 2005?9?1? 13:20 > To: ltru@ietf.org > Subject: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt >=20 > Doug Ewell wrote: >=20 > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03523.html >=20 > Ouch... I had seen this but thought it's a dupe, stupid, thanks. >=20 > In other words, your part is ready as far as Elwyn is concerned, > fine. You've probably seen that something supported by you was > approved on the review list: One more tag for the "redundant" > section, and a corresponding "deprecated" "grandfathered" tag. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 16:40:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvrU-0003fT-Br; Thu, 01 Sep 2005 16:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvrO-0003dr-5d for ltru@megatron.ietf.org; Thu, 01 Sep 2005 16:40:38 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28781 for ; Thu, 1 Sep 2005 16:40:31 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAvpV-0007nj-AJ for ltru@lists.ietf.org; Thu, 01 Sep 2005 22:38:37 +0200 Received: from c-180-160-241.hh.dial.de.ignite.net ([62.180.160.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:38:37 +0200 Received: from nobody by c-180-160-241.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:38:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 22:37:22 +0200 Organization: Lines: 6 Message-ID: <43176682.7F90@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CB43709@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-241.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: frowning on long texts (gen-art #21) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I propose that we just remove the sentence. Yes. My bad because I didn't like your original "screeds" :-( _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 16:43:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvti-0005XJ-Ui; Thu, 01 Sep 2005 16:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvtg-0005XE-P4 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 16:42:56 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28880 for ; Thu, 1 Sep 2005 16:42:54 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EAvrc-0008KL-Mq for ltru@lists.ietf.org; Thu, 01 Sep 2005 22:40:48 +0200 Received: from c-180-160-241.hh.dial.de.ignite.net ([62.180.160.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:40:48 +0200 Received: from nobody by c-180-160-241.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:40:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 22:30:47 +0200 Organization: Lines: 9 Message-ID: <431764F7.4D3E@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CA915DF@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-241.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: give ABNF for Prefix (gen-art #15) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I propose we reject this comment. Yes, if we'd follow this direction we'd end up with my idea to specify a proper syntax for each field type, nobody liked this. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 16:54:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAw4e-0002s7-MH; Thu, 01 Sep 2005 16:54:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAw4d-0002qA-95 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 16:54:15 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29173 for ; Thu, 1 Sep 2005 16:54:12 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAw2N-0002Su-SJ for ltru@lists.ietf.org; Thu, 01 Sep 2005 22:51:56 +0200 Received: from c-180-160-241.hh.dial.de.ignite.net ([62.180.160.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:51:55 +0200 Received: from nobody by c-180-160-241.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 22:51:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 22:49:26 +0200 Organization: Lines: 13 Message-ID: <43176956.60AD@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CA91615@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-241.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: case of the subtag in a registration (gen-art #16) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Before forwarding a new registration to IANA, the Language > Subtag Reviewer MUST ensure that values in the 'Subtag' field > match case according to the description in target="ianaformat">. Nice. I also agree with anything else (modulo STRONGLY ;-) you said, but for John's "generic variants" I'm not convinced that it's a good idea. And IIRC all others on the review list were sure that it's wrong. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 17:03:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwD8-00062Q-3o; Thu, 01 Sep 2005 17:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwD2-000619-6J for ltru@megatron.ietf.org; Thu, 01 Sep 2005 17:03:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29485 for ; Thu, 1 Sep 2005 17:02:53 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAwF2-0004k9-4F for ltru@ietf.org; Thu, 01 Sep 2005 17:05:01 -0400 Received: from h-68-166-188-243.snvacaid.dynamic.covad.net ([68.166.188.243] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EAwCr-0002tO-00 for ltru@ietf.org; Thu, 01 Sep 2005 17:02:45 -0400 Message-ID: <019601c5af38$c8b10180$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0CA915DF@irvmbxw01.quest.com> <431764F7.4D3E@xyzzy.claranet.de> Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Thu, 1 Sep 2005 14:04:46 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Thursday, September 01, 2005 1:30 PM > Subject: [Ltru] Re: give ABNF for Prefix (gen-art #15) > > Addison Phillips wrote: > > > I propose we reject this comment. > > Yes, if we'd follow this direction we'd end up with my idea to > specify a proper syntax for each field type, nobody liked this. ... If an IESG member chooses to make this a "DISCUSS" comment, I'd like to be armed with a more persuasive rationale. At the very least, I'd like to be able to say *why* "nobody liked this". So far, Addison's rationale that the value added by the ABNF would not be commensurate with the additional complexity is better than "nobody liked this", but it still doesn't seem terribly persuasive. Could someone write up the ABNF needed to satisfy this specific comment, (not necessarily the more generalized issues of providing ABNF for all) so that we might better judge the extent to which it might obfuscate rather than enlighten? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 17:22:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwWE-00005S-Cz; Thu, 01 Sep 2005 17:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwWC-0008Rh-Vi for ltru@megatron.ietf.org; Thu, 01 Sep 2005 17:22:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00178 for ; Thu, 1 Sep 2005 17:22:42 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAwYD-0005KR-BV for ltru@ietf.org; Thu, 01 Sep 2005 17:24:50 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 14:22:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Thu, 1 Sep 2005 14:22:29 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB437AD@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) Thread-Index: AcWvOKD3suR2YozoSFG2fPBtXKu4HgAAYplQ From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 01 Sep 2005 21:22:30.0085 (UTC) FILETIME=[4256E750:01C5AF3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > Could someone write up the ABNF needed to satisfy this specific = comment, > (not necessarily the more generalized issues of providing ABNF for = all) so > that we might better judge the extent to which it might obfuscate = rather > than enlighten? Sure. Here it is: --- Prefix =3D Variant-prefix / Extlang-prefix Extlang-prefix =3D language *2("-" 3ALPHA) Variant-prefix =3D (language ["-" script] ["-" region] *("-" variant)) language =3D (2*3ALPHA [ extlang ]) ; shortest ISO 639 code / 4ALPHA ; reserved for future use / 5*8ALPHA ; registered language subtag extlang =3D *3("-" 3ALPHA) ; reserved for future use script =3D 4ALPHA ; ISO 15924 code region =3D 2ALPHA ; ISO 3166 code / 3DIGIT ; UN M.49 code variant =3D 5*8alphanum ; registered variants / (DIGIT 3alphanum) ;=20 alphanum =3D (ALPHA / DIGIT) ; letters and numbers --- Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: 2005?9?1? 14:05 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) >=20 > Hi - >=20 > > From: "Frank Ellermann" > > To: > > Sent: Thursday, September 01, 2005 1:30 PM > > Subject: [Ltru] Re: give ABNF for Prefix (gen-art #15) > > >=20 > > Addison Phillips wrote: > > > > > I propose we reject this comment. > > > > Yes, if we'd follow this direction we'd end up with my idea to > > specify a proper syntax for each field type, nobody liked this. > ... >=20 > If an IESG member chooses to make this a "DISCUSS" comment, I'd like > to be armed with a more persuasive rationale. At the very least, I'd = like > to > be able to say *why* "nobody liked this". So far, Addison's rationale > that > the value added by the ABNF would not be commensurate with the > additional complexity is better than "nobody liked this", but it still > doesn't seem terribly persuasive. >=20 > Could someone write up the ABNF needed to satisfy this specific = comment, > (not necessarily the more generalized issues of providing ABNF for = all) so > that we might better judge the extent to which it might obfuscate = rather > than enlighten? >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 17:45:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwrs-0003VG-BK; Thu, 01 Sep 2005 17:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwrq-0003V1-9r for ltru@megatron.ietf.org; Thu, 01 Sep 2005 17:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01038 for ; Thu, 1 Sep 2005 17:45:03 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAwtp-0005zQ-LU for ltru@ietf.org; Thu, 01 Sep 2005 17:47:12 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 14:44:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Thu, 1 Sep 2005 14:44:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB437CA@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) Thread-Index: AcWvOKD3suR2YozoSFG2fPBtXKu4HgAAYplQAACNQAA= From: "Addison Phillips" To: "Addison Phillips" , "Randy Presuhn" , X-OriginalArrivalTime: 01 Sep 2005 21:44:51.0321 (UTC) FILETIME=[61C74690:01C5AF3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Okay, I forgot to include my rationale for not doing this, now that I've = finally had to write the expletive thing. I don't believe that this greatly adds to the description, which is: -- Prefix's field-value contains a language tag with which this subtag MAY = be used to form a new language tag, perhaps with other subtags as well. = This field MUST only appear in records whose 'Type' field-value is = 'variant' or 'extlang'. For example, the 'Prefix' for the variant = 'nedis' is 'sl', meaning that the tags "sl-nedis" and "sl-IT-nedis" = might be appropriate while the tag "is-nedis" is not. -- The name "Prefix" itself conveys the point pretty well, and this text = and the accompanying example I think goes much farther than the ABNF in = making it clear what the Prefix is for. In fact, the ABNF has the opposite effect. People will look at it = instead of the text and perhaps get the wrong impression that ONLY the = subtags in the prefix may be used with the variant. I'll admit that the first sentence is syntax-challenged. We could try = clarifying it. Perhaps: -- The field-value of each Prefix field contains a language tag. This tag = represents a set of subtags that is RECOMMENDED for use (in combination = with other subtags as well) with this record's subtag when forming a = language tag. This field MUST only appear in records whose 'Type' = field-value is 'variant' or 'extlang'. For example, the 'Prefix' for the = variant 'nedis' is "sl", meaning that the tags "sl-nedis" and = "sl-IT-nedis" might be appropriate choices while the tag "is-nedis" is = not. -- Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Addison Phillips > Sent: 2005?9?1? 14:22 > To: Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) >=20 > > Could someone write up the ABNF needed to satisfy this specific = comment, > > (not necessarily the more generalized issues of providing ABNF for = all) > so > > that we might better judge the extent to which it might obfuscate = rather > > than enlighten? >=20 > Sure. Here it is: >=20 > --- >=20 > Prefix =3D Variant-prefix / Extlang-prefix >=20 > Extlang-prefix =3D language *2("-" 3ALPHA) >=20 > Variant-prefix =3D (language > ["-" script] > ["-" region] > *("-" variant)) >=20 > language =3D (2*3ALPHA [ extlang ]) ; shortest ISO 639 code > / 4ALPHA ; reserved for future use > / 5*8ALPHA ; registered language subtag >=20 > extlang =3D *3("-" 3ALPHA) ; reserved for future use >=20 > script =3D 4ALPHA ; ISO 15924 code >=20 > region =3D 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN M.49 code >=20 > variant =3D 5*8alphanum ; registered variants > / (DIGIT 3alphanum) ; >=20 >=20 > alphanum =3D (ALPHA / DIGIT) ; letters and numbers >=20 > --- >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > > Randy Presuhn > > Sent: 2005?9?1? 14:05 > > To: ltru@ietf.org > > Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) > > > > Hi - > > > > > From: "Frank Ellermann" > > > To: > > > Sent: Thursday, September 01, 2005 1:30 PM > > > Subject: [Ltru] Re: give ABNF for Prefix (gen-art #15) > > > > > > > > Addison Phillips wrote: > > > > > > > I propose we reject this comment. > > > > > > Yes, if we'd follow this direction we'd end up with my idea to > > > specify a proper syntax for each field type, nobody liked this. > > ... > > > > If an IESG member chooses to make this a "DISCUSS" comment, I'd like > > to be armed with a more persuasive rationale. At the very least, = I'd > like > > to > > be able to say *why* "nobody liked this". So far, Addison's = rationale > > that > > the value added by the ABNF would not be commensurate with the > > additional complexity is better than "nobody liked this", but it = still > > doesn't seem terribly persuasive. > > > > Could someone write up the ABNF needed to satisfy this specific = comment, > > (not necessarily the more generalized issues of providing ABNF for = all) > so > > that we might better judge the extent to which it might obfuscate = rather > > than enlighten? > > > > Randy > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 18:08:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAxEL-00056I-OT; Thu, 01 Sep 2005 18:08:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAxEK-00054E-0d for ltru@megatron.ietf.org; Thu, 01 Sep 2005 18:08:20 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02132 for ; Thu, 1 Sep 2005 18:08:16 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAx5F-0002Fg-SD for ltru@lists.ietf.org; Thu, 01 Sep 2005 23:58:57 +0200 Received: from c-180-160-241.hh.dial.de.ignite.net ([62.180.160.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 23:58:57 +0200 Received: from nobody by c-180-160-241.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 23:58:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 23:57:53 +0200 Organization: Lines: 33 Message-ID: <43177961.7B6D@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CA915DF@irvmbxw01.quest.com> <431764F7.4D3E@xyzzy.claranet.de> <019601c5af38$c8b10180$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-241.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: give ABNF for Prefix (gen-art #15) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > Could someone write up the ABNF needed to satisfy this > specific comment, (not necessarily the more generalized > issues of providing ABNF for all) so that we might better > judge the extent to which it might obfuscate rather > than enlighten? See Addison's answer. For the general "nobody liked this" see below. But that is really DEAD now. I only mentioned it because we already considered it, and it is apparently in the direction of what Elwyn missed. Bye, Frank registry = file-date *( "%%" CRLF record ) file-date = "File-Date:" 1*SP date CRLF ; first line record = 1*( field CRLF ) field = type / tag / timestamp / reference / explanation type = "Type:" 1*SP ( subtag-type / "grandfathered" ) subtag-type = "language" / "extlang" / "script" / "region" / "variant" tag = ( "Subtag:" / "Tag:" ) 1*SP value reference = ( "Canonical:" / "Suppress-Script:" / "Recommended-Prefix:" ) 1*SP value explanation = ( "Description:" / "Comments:" ) 1*SP text timestamp = ( "Added:" / "Deprecated:" ) 1*SP date date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; see RfC 3339 value = 1*( ALPHA / DIGIT / "-" ) ; note no WSP text = *( ASC-char / LWSP ) ; note folding WSP ASC-char = %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 UNI-char = "&#x" 2*6HEXDIG ";" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 18:46:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAxpL-0006gF-9z; Thu, 01 Sep 2005 18:46:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAxpJ-0006gA-N4 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 18:46:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04440 for ; Thu, 1 Sep 2005 18:46:31 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAxrL-0007jD-3o for ltru@ietf.org; Thu, 01 Sep 2005 18:48:40 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j81MkLVZ017309 for ; Thu, 1 Sep 2005 18:46:21 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j81MkLMR098574 for ; Thu, 1 Sep 2005 18:46:21 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j81MkBD9010066 for ; Thu, 1 Sep 2005 18:46:11 -0400 Received: from [127.0.0.1] (mark-davis.sanjose.ibm.com [9.43.213.128]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j81Mk9ER009782; Thu, 1 Sep 2005 18:46:10 -0400 Message-ID: <431784A6.9020207@icu-project.org> Date: Thu, 01 Sep 2005 15:45:58 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) References: <634978A7DF025A40BFEF33EB191E13BC0CB437AD@irvmbxw01.quest.com> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB437AD@irvmbxw01.quest.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org If we are updating the ABNF anyway, then I would suggest that we make the following additions, to allow for possible future use of subtags that are currently invalid. Mark Addison Phillips wrote: >>Could someone write up the ABNF needed to satisfy this specific comment, >>(not necessarily the more generalized issues of providing ABNF for all) so >>that we might better judge the extent to which it might obfuscate rather >>than enlighten? > > > Sure. Here it is: > > --- > > Prefix = Variant-prefix / Extlang-prefix > > Extlang-prefix = language *2("-" 3ALPHA) > > Variant-prefix = (language > ["-" script] > ["-" region] > *("-" variant)) > > language = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code > / 4ALPHA ; reserved for future use > / 5*8ALPHA ; registered language subtag > > extlang = *3("-" 3ALPHA) ; reserved for future use > > script = 4ALPHA ; ISO 15924 code / ALPHA 3alphanum ; reserved for future use > > region = 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN M.49 code / 2alphanum ; reserved for future use / DIGIT 2alphanum ; reserved for future use > > variant = 5*8alphanum ; registered variants > / (DIGIT 3alphanum) ; > > > alphanum = (ALPHA / DIGIT) ; letters and numbers > > --- > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > 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: 2005?9?1? 14:05 >>To: ltru@ietf.org >>Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) >> >>Hi - >> >> >>>From: "Frank Ellermann" >>>To: >>>Sent: Thursday, September 01, 2005 1:30 PM >>>Subject: [Ltru] Re: give ABNF for Prefix (gen-art #15) >>> >> >>>Addison Phillips wrote: >>> >>> >>>>I propose we reject this comment. >>> >>>Yes, if we'd follow this direction we'd end up with my idea to >>>specify a proper syntax for each field type, nobody liked this. >> >>... >> >>If an IESG member chooses to make this a "DISCUSS" comment, I'd like >>to be armed with a more persuasive rationale. At the very least, I'd like >>to >>be able to say *why* "nobody liked this". So far, Addison's rationale >>that >>the value added by the ABNF would not be commensurate with the >>additional complexity is better than "nobody liked this", but it still >>doesn't seem terribly persuasive. >> >>Could someone write up the ABNF needed to satisfy this specific comment, >>(not necessarily the more generalized issues of providing ABNF for all) so >>that we might better judge the extent to which it might obfuscate rather >>than enlighten? >> >>Randy >> >> >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 19:21:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAyNA-0004OJ-JB; Thu, 01 Sep 2005 19:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAyN4-0004LD-5f for ltru@megatron.ietf.org; Thu, 01 Sep 2005 19:21:26 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06211 for ; Thu, 1 Sep 2005 19:21:22 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050901232054.JTIX12299.mta13.adelphia.net@DEWELL> for ; Thu, 1 Sep 2005 19:20:54 -0400 Message-ID: <000801c5af4b$c36c7480$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050901204312.DTQ7546.mta2.adelphia.net@megatron.ietf.org> Date: Thu, 1 Sep 2005 16:20:36 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Zh-cmn is NOT a valid 3066bis tag. It cannot be redundant currently. > However, "zh-guoyu" should have a Preferred-Value of "zh-cmn". Based on the comment "It is understood that the 'guoyu' dialect tag will be deprecated" in http://www.alvestrand.no/pipermail/ietf-languages/2005-July/003532.html, I had already added a Preferred-Value of "zh-cmn" and a Deprecated date of 2005-07-15 to the entry for grandfathered tag "zh-guoyu", back in draft-initial-03. The group and co-chairs should decide whether this is correct, or whether the Deprecated date should actually be 2005-08-31 in accordance with http://www.alvestrand.no/pipermail/ietf-languages/2005-August/003568.html. (Note that the subtag in question is "guoyu", not "quoyu".) -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 19:23:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAyOc-0005mU-TE; Thu, 01 Sep 2005 19:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAyOb-0005mP-RP for ltru@megatron.ietf.org; Thu, 01 Sep 2005 19:23:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06291 for ; Thu, 1 Sep 2005 19:22:58 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAyQc-0000Mi-6A for ltru@ietf.org; Thu, 01 Sep 2005 19:25:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 16:22:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Thu, 1 Sep 2005 16:22:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB4382C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) Thread-Index: AcWvRv4ZAtmRM8T8RMaxwmoKNmbVvAAAQQKw From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 01 Sep 2005 23:22:41.0143 (UTC) FILETIME=[0C770870:01C5AF4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0703371392==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0703371392== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TWFyaywNCg0KVGhpcyBpcyBhIG5ldyBwaWVjZSBvZiBBQk5GIGZvciB0aGUgcHJlZml4IGZpZWxk IGluIHRoZSByZWdpc3RyeSBPTkxZLiBUaGVyZSBpcyBubyBzdWdnZXN0aW9uIHRoYXQgd2UnbGwg YmUgbW9kaWZ5aW5nIHRoZSBBQk5GIGZvciBsYW5ndWFnZSB0YWdzIHRoZW1zZWx2ZXMuIA0KDQpJ J20gZm91cnNxdWFyZSBhZ2FpbnN0IGluc2VydGluZyBBQk5GIGZvciBQcmVmaXguIA0KDQpUaGUg b3RoZXIgY2hhbmdlIEkgd291bGRuJ3Qgd2FudCB0byBpbnNlcnQgYXQgdGhpcyBsYXRlIGRhdGUg dW5sZXNzIHdlJ3JlIG1vZGlmeWluZyB0aGUgQUJORiBmb3Igc29tZSBvdGhlciBwdXJwb3NlLg0K DQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0 LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdv cmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0 IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQ0KPiBT ZW50OiAyMDA15bm0OeaciDHml6UgMTU6NDYNCj4gVG86IEFkZGlzb24gUGhpbGxpcHMNCj4gQ2M6 IFJhbmR5IFByZXN1aG47IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBSZTog Z2l2ZSBBQk5GIGZvciBQcmVmaXggKGdlbi1hcnQgIzE1KQ0KPiANCj4gSWYgd2UgYXJlIHVwZGF0 aW5nIHRoZSBBQk5GIGFueXdheSwgdGhlbiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB3ZSBtYWtlDQo+ IHRoZSBmb2xsb3dpbmcgYWRkaXRpb25zLCB0byBhbGxvdyBmb3IgcG9zc2libGUgZnV0dXJlIHVz ZSBvZiBzdWJ0YWdzDQo+IHRoYXQgYXJlIGN1cnJlbnRseSBpbnZhbGlkLg0KPiANCj4gTWFyaw0K PiANCj4gQWRkaXNvbiBQaGlsbGlwcyB3cm90ZToNCj4gPj5Db3VsZCBzb21lb25lIHdyaXRlIHVw IHRoZSBBQk5GIG5lZWRlZCB0byBzYXRpc2Z5IHRoaXMgc3BlY2lmaWMgY29tbWVudCwNCj4gPj4o bm90IG5lY2Vzc2FyaWx5IHRoZSBtb3JlIGdlbmVyYWxpemVkIGlzc3VlcyBvZiBwcm92aWRpbmcg QUJORiBmb3IgYWxsKQ0KPiBzbw0KPiA+PnRoYXQgd2UgbWlnaHQgYmV0dGVyIGp1ZGdlIHRoZSBl eHRlbnQgdG8gd2hpY2ggaXQgbWlnaHQgb2JmdXNjYXRlIHJhdGhlcg0KPiA+PnRoYW4gZW5saWdo dGVuPw0KPiA+DQo+ID4NCj4gPiBTdXJlLiBIZXJlIGl0IGlzOg0KPiA+DQo+ID4gLS0tDQo+ID4N Cj4gPiBQcmVmaXggICAgICAgPSBWYXJpYW50LXByZWZpeCAvIEV4dGxhbmctcHJlZml4DQo+ID4N Cj4gPiBFeHRsYW5nLXByZWZpeCA9IGxhbmd1YWdlICoyKCItIiAzQUxQSEEpDQo+ID4NCj4gPiBW YXJpYW50LXByZWZpeCA9IChsYW5ndWFnZQ0KPiA+ICAgICAgICAgICAgICAgICAgIFsiLSIgc2Ny aXB0XQ0KPiA+ICAgICAgICAgICAgICAgICAgIFsiLSIgcmVnaW9uXQ0KPiA+ICAgICAgICAgICAg ICAgICAgICooIi0iIHZhcmlhbnQpKQ0KPiA+DQo+ID4gbGFuZ3VhZ2UgICAgICA9ICgyKjNBTFBI QSBbIGV4dGxhbmcgXSkgOyBzaG9ydGVzdCBJU08gNjM5IGNvZGUNCj4gPiAgICAgICAgICAgICAg IC8gNEFMUEhBICAgICAgICAgICAgICAgICA7IHJlc2VydmVkIGZvciBmdXR1cmUgdXNlDQo+ID4g ICAgICAgICAgICAgICAvIDUqOEFMUEhBICAgICAgICAgICAgICAgOyByZWdpc3RlcmVkIGxhbmd1 YWdlIHN1YnRhZw0KPiA+DQo+ID4gZXh0bGFuZyAgICAgICA9ICozKCItIiAzQUxQSEEpICAgICAg ICAgOyByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZQ0KPiA+DQo+ID4gc2NyaXB0ICAgICAgICA9IDRB TFBIQSAgICAgICAgICAgICAgICAgOyBJU08gMTU5MjQgY29kZQ0KPiAgICAgICAgICAgICAgICAg IC8gQUxQSEEgM2FscGhhbnVtICAgICAgICA7IHJlc2VydmVkIGZvciBmdXR1cmUgdXNlDQo+ID4N Cj4gPiByZWdpb24gICAgICAgID0gMkFMUEhBICAgICAgICAgICAgICAgICA7IElTTyAzMTY2IGNv ZGUNCj4gPiAgICAgICAgICAgICAgIC8gM0RJR0lUICAgICAgICAgICAgICAgICA7IFVOIE0uNDkg Y29kZQ0KPiAgICAgICAgICAgICAgICAgIC8gMmFscGhhbnVtICAgICAgICAgICAgICA7IHJlc2Vy dmVkIGZvciBmdXR1cmUgdXNlDQo+ICAgICAgICAgICAgICAgICAgLyBESUdJVCAyYWxwaGFudW0g ICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UNCj4gPg0KPiA+IHZhcmlhbnQgICAgICAg PSA1KjhhbHBoYW51bSAgICAgICAgICAgIDsgcmVnaXN0ZXJlZCB2YXJpYW50cw0KPiA+ICAgICAg ICAgICAgICAgLyAoRElHSVQgM2FscGhhbnVtKSAgICAgIDsNCj4gPg0KPiA+DQo+ID4gYWxwaGFu dW0gICAgICA9IChBTFBIQSAvIERJR0lUKSAgICAgICA7IGxldHRlcnMgYW5kIG51bWJlcnMNCj4g Pg0KPiA+IC0tLQ0KPiA+DQo+ID4gQWRkaXNvbiBQLiBQaGlsbGlwcw0KPiA+IEdsb2JhbGl6YXRp b24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KPiA+IENoYWlyLCBXM0MgSW50ZXJuYXRpb25h bGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQo+ID4NCj4gPiBJbnRlcm5hdGlvbmFsaXphdGlv biBpcyBub3QgYSBmZWF0dXJlLg0KPiA+IEl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCj4gPg0KPiA+ DQo+ID4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj5Gcm9tOiBsdHJ1LWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+ PlJhbmR5IFByZXN1aG4NCj4gPj5TZW50OiAyMDA1Pzk/MT8gMTQ6MDUNCj4gPj5UbzogbHRydUBp ZXRmLm9yZw0KPiA+PlN1YmplY3Q6IFJlOiBbTHRydV0gUmU6IGdpdmUgQUJORiBmb3IgUHJlZml4 IChnZW4tYXJ0ICMxNSkNCj4gPj4NCj4gPj5IaSAtDQo+ID4+DQo+ID4+DQo+ID4+PkZyb206ICJG cmFuayBFbGxlcm1hbm4iIDxub2JvZHlAeHl6enkuY2xhcmFuZXQuZGU+DQo+ID4+PlRvOiA8bHRy dUBpZXRmLm9yZz4NCj4gPj4+U2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwMSwgMjAwNSAxOjMw IFBNDQo+ID4+PlN1YmplY3Q6IFtMdHJ1XSBSZTogZ2l2ZSBBQk5GIGZvciBQcmVmaXggKGdlbi1h cnQgIzE1KQ0KPiA+Pj4NCj4gPj4NCj4gPj4+QWRkaXNvbiBQaGlsbGlwcyB3cm90ZToNCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4+SSBwcm9wb3NlIHdlIHJlamVjdCB0aGlzIGNvbW1lbnQuDQo+ID4+Pg0K PiA+Pj5ZZXMsIGlmIHdlJ2QgZm9sbG93IHRoaXMgZGlyZWN0aW9uIHdlJ2QgZW5kIHVwIHdpdGgg bXkgaWRlYSB0bw0KPiA+Pj5zcGVjaWZ5IGEgcHJvcGVyIHN5bnRheCBmb3IgZWFjaCBmaWVsZCB0 eXBlLCBub2JvZHkgbGlrZWQgdGhpcy4NCj4gPj4NCj4gPj4uLi4NCj4gPj4NCj4gPj5JZiBhbiBJ RVNHIG1lbWJlciBjaG9vc2VzIHRvIG1ha2UgdGhpcyBhICJESVNDVVNTIiBjb21tZW50LCBJJ2Qg bGlrZQ0KPiA+PnRvIGJlIGFybWVkIHdpdGggYSBtb3JlIHBlcnN1YXNpdmUgcmF0aW9uYWxlLiAg QXQgdGhlIHZlcnkgbGVhc3QsIEknZA0KPiBsaWtlDQo+ID4+dG8NCj4gPj5iZSBhYmxlIHRvIHNh eSAqd2h5KiAibm9ib2R5IGxpa2VkIHRoaXMiLiAgU28gZmFyLCBBZGRpc29uJ3MgcmF0aW9uYWxl DQo+ID4+dGhhdA0KPiA+PnRoZSB2YWx1ZSBhZGRlZCBieSB0aGUgQUJORiB3b3VsZCBub3QgYmUg Y29tbWVuc3VyYXRlIHdpdGggdGhlDQo+ID4+YWRkaXRpb25hbCBjb21wbGV4aXR5IGlzIGJldHRl ciB0aGFuICJub2JvZHkgbGlrZWQgdGhpcyIsIGJ1dCBpdCBzdGlsbA0KPiA+PmRvZXNuJ3Qgc2Vl bSB0ZXJyaWJseSBwZXJzdWFzaXZlLg0KPiA+Pg0KPiA+PkNvdWxkIHNvbWVvbmUgd3JpdGUgdXAg dGhlIEFCTkYgbmVlZGVkIHRvIHNhdGlzZnkgdGhpcyBzcGVjaWZpYyBjb21tZW50LA0KPiA+Pihu b3QgbmVjZXNzYXJpbHkgdGhlIG1vcmUgZ2VuZXJhbGl6ZWQgaXNzdWVzIG9mIHByb3ZpZGluZyBB Qk5GIGZvciBhbGwpDQo+IHNvDQo+ID4+dGhhdCB3ZSBtaWdodCBiZXR0ZXIganVkZ2UgdGhlIGV4 dGVudCB0byB3aGljaCBpdCBtaWdodCBvYmZ1c2NhdGUgcmF0aGVyDQo+ID4+dGhhbiBlbmxpZ2h0 ZW4/DQo+ID4+DQo+ID4+UmFuZHkNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pkx0cnUgbWFpbGlu ZyBsaXN0DQo+ID4+THRydUBpZXRmLm9yZw0KPiA+Pmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2x0cnUNCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEx0cnUgbWFpbGluZyBsaXN0DQo+ID4g THRydUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2x0cnUNCj4gPg0KPiA+DQo+ID4NCg0KDQo= --===============0703371392== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0703371392==-- From ltru-bounces@ietf.org Thu Sep 01 20:02:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAz19-0006ec-IN; Thu, 01 Sep 2005 20:02:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAz17-0006be-U0 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 20:02:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07587 for ; Thu, 1 Sep 2005 20:02:46 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAz39-0001Qk-UB for ltru@ietf.org; Thu, 01 Sep 2005 20:04:57 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8202ZLd014004 for ; Thu, 1 Sep 2005 20:02:35 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8202ZMR098940 for ; Thu, 1 Sep 2005 20:02:35 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8202ZWV016768 for ; Thu, 1 Sep 2005 20:02:35 -0400 Received: from [127.0.0.1] (mark-davis.sanjose.ibm.com [9.43.213.128]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8202YQg016748; Thu, 1 Sep 2005 20:02:34 -0400 Message-ID: <43179699.3080300@icu-project.org> Date: Thu, 01 Sep 2005 17:02:33 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) References: <634978A7DF025A40BFEF33EB191E13BC0CB4382C@irvmbxw01.quest.com> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB4382C@irvmbxw01.quest.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id j8202ZLd014004 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > The other change I wouldn't want to insert at this late date unless=20 we're modifying the ABNF for some other purpose. I firmly agree; at this late date we shouldn't change anything material=20 in the document unless we have to make material changes anyway. My only=20 thought is that if we *do* have to make a material change, then it would=20 good to add this at the same time. Mark Addison Phillips wrote: > Mark, >=20 > This is a new piece of ABNF for the prefix field in the registry ONLY. = There is no suggestion that we'll be modifying the ABNF for language tags= themselves.=20 >=20 > I'm foursquare against inserting ABNF for Prefix.=20 >=20 > The other change I wouldn't want to insert at this late date unless we'= re modifying the ABNF for some other purpose. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture.=20 >=20 >=20 >>-----Original Message----- >>From: Mark Davis [mailto:mark.davis@icu-project.org] >>Sent: 2005=E5=B9=B49=E6=9C=881=E6=97=A5 15:46 >>To: Addison Phillips >>Cc: Randy Presuhn; ltru@ietf.org >>Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) >> >>If we are updating the ABNF anyway, then I would suggest that we make >>the following additions, to allow for possible future use of subtags >>that are currently invalid. >> >>Mark >> >>Addison Phillips wrote: >> >>>>Could someone write up the ABNF needed to satisfy this specific comme= nt, >>>>(not necessarily the more generalized issues of providing ABNF for al= l) >> >>so >> >>>>that we might better judge the extent to which it might obfuscate rat= her >>>>than enlighten? >>> >>> >>>Sure. Here it is: >>> >>>--- >>> >>>Prefix =3D Variant-prefix / Extlang-prefix >>> >>>Extlang-prefix =3D language *2("-" 3ALPHA) >>> >>>Variant-prefix =3D (language >>> ["-" script] >>> ["-" region] >>> *("-" variant)) >>> >>>language =3D (2*3ALPHA [ extlang ]) ; shortest ISO 639 code >>> / 4ALPHA ; reserved for future use >>> / 5*8ALPHA ; registered language subtag >>> >>>extlang =3D *3("-" 3ALPHA) ; reserved for future use >>> >>>script =3D 4ALPHA ; ISO 15924 code >> >> / ALPHA 3alphanum ; reserved for future use >> >>>region =3D 2ALPHA ; ISO 3166 code >>> / 3DIGIT ; UN M.49 code >> >> / 2alphanum ; reserved for future use >> / DIGIT 2alphanum ; reserved for future use >> >>>variant =3D 5*8alphanum ; registered variants >>> / (DIGIT 3alphanum) ; >>> >>> >>>alphanum =3D (ALPHA / DIGIT) ; letters and numbers >>> >>>--- >>> >>>Addison P. Phillips >>>Globalization Architect, Quest Software >>>Chair, W3C Internationalization Core Working Group >>> >>>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: 2005?9?1? 14:05 >>>>To: ltru@ietf.org >>>>Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) >>>> >>>>Hi - >>>> >>>> >>>> >>>>>From: "Frank Ellermann" >>>>>To: >>>>>Sent: Thursday, September 01, 2005 1:30 PM >>>>>Subject: [Ltru] Re: give ABNF for Prefix (gen-art #15) >>>>> >>>> >>>>>Addison Phillips wrote: >>>>> >>>>> >>>>> >>>>>>I propose we reject this comment. >>>>> >>>>>Yes, if we'd follow this direction we'd end up with my idea to >>>>>specify a proper syntax for each field type, nobody liked this. >>>> >>>>... >>>> >>>>If an IESG member chooses to make this a "DISCUSS" comment, I'd like >>>>to be armed with a more persuasive rationale. At the very least, I'd >> >>like >> >>>>to >>>>be able to say *why* "nobody liked this". So far, Addison's rational= e >>>>that >>>>the value added by the ABNF would not be commensurate with the >>>>additional complexity is better than "nobody liked this", but it stil= l >>>>doesn't seem terribly persuasive. >>>> >>>>Could someone write up the ABNF needed to satisfy this specific comme= nt, >>>>(not necessarily the more generalized issues of providing ABNF for al= l) >> >>so >> >>>>that we might better judge the extent to which it might obfuscate rat= her >>>>than enlighten? >>>> >>>>Randy >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Ltru mailing list >>>>Ltru@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ltru >>> >>> >>> >>>_______________________________________________ >>>Ltru mailing list >>>Ltru@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ltru >>> >>> >>> >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 01 23:36:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB2M3-0001F8-Fe; Thu, 01 Sep 2005 23:36:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB2M1-0001F0-97 for ltru@megatron.ietf.org; Thu, 01 Sep 2005 23:36:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26941 for ; Thu, 1 Sep 2005 23:36:32 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB2O3-0007lR-0B for ltru@ietf.org; Thu, 01 Sep 2005 23:38:44 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 20:36:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Thu, 1 Sep 2005 20:36:14 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB4387D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) Thread-Index: AcWva2Kc9701uJrpTCqLGlOPdBF2IAAA7iAQ From: "Addison Phillips" To: "r&d afrac" X-OriginalArrivalTime: 02 Sep 2005 03:36:14.0936 (UTC) FILETIME=[78979D80:01C5AF6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Jefsey: Do not write to me privately. >=20 > I suggest you correct the typo at the end of the first instance, > which makes it understandable. "is-nedis" while it should be = "sl-nedis"? No. Read the sentence. "is-nedis" is an example of an inappropriate tag. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: r&d afrac [mailto:rd@afrac.org] > Sent: 2005?9?1? 20:06 > To: Addison Phillips > Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) >=20 > On 23:44 01/09/2005, Addison Phillips said: > >Perhaps we should drop the second instance? >=20 > I suggest you correct the typo at the end of the first instance, > which makes it understandable. "is-nedis" while it should be = "sl-nedis"? > jfc >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 10:01:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBC6w-0000hi-4Q; Fri, 02 Sep 2005 10:01:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBC6u-0000dF-8r for ltru@megatron.ietf.org; Fri, 02 Sep 2005 10:01:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07490 for ; Fri, 2 Sep 2005 10:01:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBC91-000483-Mw for ltru@ietf.org; Fri, 02 Sep 2005 10:03:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EBC6p-0001Vk-GY; Fri, 02 Sep 2005 07:01:35 -0700 Message-Id: <6.2.3.4.2.20050902133604.04d06eb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 02 Sep 2005 16:01:31 +0200 To: "Addison Phillips" From: r&d afrac Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB4387D@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0CB4387D@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 05:36 02/09/2005, Addison Phillips wrote: > > I suggest you correct the typo at the end of the first instance, > > which makes it understandable. "is-nedis" while it should be "sl-nedis"? > >No. Read the sentence. "is-nedis" is an example of an inappropriate tag. Then if you suppress the second paragraph you quote, you do not have an example of appropriat tag. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 10:01:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBC6x-0000j3-Db; Fri, 02 Sep 2005 10:01:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBC6t-0000cf-Q3 for ltru@megatron.ietf.org; Fri, 02 Sep 2005 10:01:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07485 for ; Fri, 2 Sep 2005 10:01:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBC93-000487-3z for ltru@ietf.org; Fri, 02 Sep 2005 10:03:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EBC6q-0001Vk-KO; Fri, 02 Sep 2005 07:01:36 -0700 Message-Id: <6.2.3.4.2.20050902140654.04d97860@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 02 Sep 2005 14:21:49 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: At least one prefix for variant (GenArt) #18 In-Reply-To: <43175FD0.3232@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CA91542@irvmbxw01.quest.com> <20050901165823.GB17084@NYCMJCOWA2> <43175FD0.3232@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 22:08 01/09/2005, Frank Ellermann wrote: >John.Cowan wrote: > > I request (as part of Last Call) that this be reconsidered > > by the WG. > >You tested the idea of generic variants on the review list >(among others -north, -east, -west, -south, and what I recall > as -familiar, but that wasn't your proposal) > >The result of this discussion was "bad idea" (okay, I wasn't >sure that it's necessarily bad, I said "utter dubious" for >your old examples). John has no problem in using an x-tag. en-x-east. Happily there is no private use return singleton, like say "u-". We would have a "en-x-east-u-Latn-us" mess.... But he can have "en-Latn-us-x-east. I note that Mark wants to be able to support en-189-us? Would that be for voice subtags? Would be an interesting move. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 10:17:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCLl-0007tm-8s; Fri, 02 Sep 2005 10:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCLj-0007tg-Ra for ltru@megatron.ietf.org; Fri, 02 Sep 2005 10:16:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09053 for ; Fri, 2 Sep 2005 10:16:58 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBCNt-0004bH-Fz for ltru@ietf.org; Fri, 02 Sep 2005 10:19:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 07:16:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Fri, 2 Sep 2005 07:16:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB4396C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) Thread-Index: AcWvxy6JNJKope32RsKrSHbXxrO9uQAAISHA From: "Addison Phillips" To: "r&d afrac" X-OriginalArrivalTime: 02 Sep 2005 14:16:42.0550 (UTC) FILETIME=[F13C2D60:01C5AFC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > Then if you suppress the second paragraph you quote, you do not have > an example of appropriat tag. Huh? Here is the sentence you are talking about: -- For example, the 'Prefix' for the variant 'nedis' is "sl", meaning that = the tags "sl-nedis" and "sl-IT-nedis" might be appropriate choices while = the tag "is-nedis" is not. -- Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:00:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBD1Y-0003n7-JC; Fri, 02 Sep 2005 11:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBD1X-0003mb-5c for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12489 for ; Fri, 2 Sep 2005 11:00:09 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBD3h-0006Rv-70 for ltru@ietf.org; Fri, 02 Sep 2005 11:02:26 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EBD1U-0003Qv-0k; Fri, 02 Sep 2005 08:00:08 -0700 Message-Id: <6.2.3.4.2.20050902165215.034e83d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 02 Sep 2005 16:57:42 +0200 To: "Addison Phillips" From: r&d afrac Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB4396C@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0CB4396C@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 16:16 02/09/2005, Addison Phillips wrote: > > Then if you suppress the second paragraph you quote, you do not have > > an example of appropriat tag. > >Huh? Here is the sentence you are talking about: > >-- >For example, the 'Prefix' for the variant 'nedis' is "sl", meaning >that the tags "sl-nedis" and "sl-IT-nedis" might be appropriate >choices while the tag "is-nedis" is not. >-- You are correct. I was refering to the other redundant paragraph you want to remove. My confusion was dislexic: in reading both I felt more at ease with the other example and though of a typo in this one. Apologies. But you might want to use other prefixes than "sl" and "is" which may quick-read similar? jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:03:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBD4X-0005gD-IY; Fri, 02 Sep 2005 11:03:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBD4V-0005g2-Rj for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:03:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12612 for ; Fri, 2 Sep 2005 11:03:14 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBD6f-0006Xl-RH for ltru@ietf.org; Fri, 02 Sep 2005 11:05:31 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:03:05 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:03:04 -0700 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 Subject: RE: [Ltru] At least one prefix for variant (GenArt) Date: Fri, 2 Sep 2005 08:03:02 -0700 Message-ID: Thread-Topic: [Ltru] At least one prefix for variant (GenArt) thread-index: AcWvGIH9Sbk/Meg9QSqCZzC6AmqLEQAtm2cw From: "Peter Constable" To: X-OriginalArrivalTime: 02 Sep 2005 15:03:04.0785 (UTC) FILETIME=[6B938C10:01C5AFCF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > John.Cowan > > To read like this: > > > > -- > > Prefix's field-value contains a language tag with which this subtag MAY > be used to form a new language tag, perhaps with other subtags as well, or > the special tag "*", indicating that this subtag could be considered > appropriate with any combination of subtags. > > -- >=20 > What's the argument against just allowing zero prefixes for variants? If you want to allow a null field-value in the prefix field, wouldn't it make more sense to say that a prefix field is not required? Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:06:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBD7s-0007SK-4z; Fri, 02 Sep 2005 11:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBD7q-0007S5-0K for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:06:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12858 for ; Fri, 2 Sep 2005 11:06:40 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBD9z-0006gK-Ss for ltru@ietf.org; Fri, 02 Sep 2005 11:08:57 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:06:31 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:06:30 -0700 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 Subject: RE: [Ltru] Re: At least one prefix for variant (GenArt) #18 Date: Fri, 2 Sep 2005 08:06:27 -0700 Message-ID: Thread-Topic: [Ltru] Re: At least one prefix for variant (GenArt) #18 thread-index: AcWvMYiU550rbN1yRNuYeKpLuP8YRgAnhAGA From: "Peter Constable" To: X-OriginalArrivalTime: 02 Sep 2005 15:06:30.0737 (UTC) FILETIME=[E6555410:01C5AFCF] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Frank Ellermann > You tested the idea of generic variants on the review list > (among others -north, -east, -west, -south, and what I recall > as -familiar, but that wasn't your proposal) >=20 > The result of this discussion was "bad idea" (okay, I wasn't > sure that it's necessarily bad, I said "utter dubious" for > your old examples). I recall that his request for -north etc were opposed. I don't recall that generic variants were ruled out altogether, though. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:07:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBD8S-0007ta-Do; Fri, 02 Sep 2005 11:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBD8Q-0007qy-90 for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:07:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12886 for ; Fri, 2 Sep 2005 11:07:16 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDAa-0006hM-9h for ltru@ietf.org; Fri, 02 Sep 2005 11:09:33 -0400 X-Medic-Info: f85.43186aa3.0 vGOWyiE4tMEsi1Ab Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 4BE4E45E5 for ; Fri, 2 Sep 2005 17:07:15 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Fri, 2 Sep 2005 17:07:15 +0200 (CEST) Message-ID: <60927.83.248.26.202.1125673635.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB4396C@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0CB4396C@irvmbxw01.quest.com> Date: Fri, 2 Sep 2005 17:07:15 +0200 (CEST) Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) From: "Kent Karlsson" To: ltru@ietf.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -- > For example, the 'Prefix' for the variant 'nedis' is "sl", meaning that > the tags "sl-nedis" and "sl-IT-nedis" might be appropriate choices whil= e > the tag "is-nedis" is not. > -- It seems to me that this sentence conflates two issues: 1. Whether a tag is correctly formed or not (not just syntactically). 2. Whether a tag is appropriate for some particular data. Concentrating on the first issue, maybe the sentence should read (less confusingly): --- For example, the 'Prefix' for the variant 'nedis' is "sl", meaning that the tags "sl-nedis" and "sl-IT-nedis" are correctly formed tags while the tag "is-nedis" is not. --- /Kent K _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:20:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDKs-0005w1-Km; Fri, 02 Sep 2005 11:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDKr-0005uV-4j for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:20:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13287 for ; Fri, 2 Sep 2005 11:20:07 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDMz-00073Q-A1 for ltru@ietf.org; Fri, 02 Sep 2005 11:22:24 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:19:56 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:19:56 -0700 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 Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Fri, 2 Sep 2005 08:19:53 -0700 Message-ID: Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) thread-index: AcWvOKD3suR2YozoSFG2fPBtXKu4HgAAYplQAACNQAAAJUj8MA== From: "Peter Constable" To: X-OriginalArrivalTime: 02 Sep 2005 15:19:56.0434 (UTC) FILETIME=[C690EF20:01C5AFD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Addison Phillips > Okay, I forgot to include my rationale for not doing this, now that I've > finally had to write the expletive thing. >=20 > I don't believe that this greatly adds to the description I agree. It would mostly makes a long doc longer. The intent of the Prefix field is, IMO, already explained sufficiently clearly. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:25:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDQ3-00087H-QS; Fri, 02 Sep 2005 11:25:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDQ2-00086a-Bp for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:25:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13557 for ; Fri, 2 Sep 2005 11:25:28 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDSD-0007GW-Es for ltru@ietf.org; Fri, 02 Sep 2005 11:27:45 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:25:20 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:25:20 -0700 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 Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Fri, 2 Sep 2005 08:25:17 -0700 Message-ID: Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) thread-index: AcWvUb0bgUrSKEtgTSKx2ooyoZ7AbwAgCWuQ From: "Peter Constable" To: X-OriginalArrivalTime: 02 Sep 2005 15:25:21.0076 (UTC) FILETIME=[88115F40:01C5AFD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Mark Davis > > The other change I wouldn't want to insert at this late date unless > we're modifying the ABNF for some other purpose. >=20 >=20 > I firmly agree; at this late date we shouldn't change anything material > in the document unless we have to make material changes anyway. My only > thought is that if we *do* have to make a material change, then it would > good to add this at the same time. Add *what*, Mark? Add ABNF to specify what can go in Prefix fields? That would have no bearing whatsoever on the langtag ABNF. Please clarify. What material change do you perceive is already being made? Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:38:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDcQ-00052o-Hw; Fri, 02 Sep 2005 11:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDcN-00051a-7o for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:38:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14158 for ; Fri, 2 Sep 2005 11:38:13 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDeX-0007hK-Gq for ltru@ietf.org; Fri, 02 Sep 2005 11:40:30 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:38:04 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 08:38:04 -0700 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 Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Fri, 2 Sep 2005 08:38:01 -0700 Message-ID: Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) thread-index: AcWv0AfKRrtGEnTuRGqdO7BQHJnScAAA3Fng From: "Peter Constable" To: X-OriginalArrivalTime: 02 Sep 2005 15:38:04.0526 (UTC) FILETIME=[4F1E98E0:01C5AFD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Kent Karlsson > > For example, the 'Prefix' for the variant 'nedis' is "sl", meaning that > > the tags "sl-nedis" and "sl-IT-nedis" might be appropriate choices while > > the tag "is-nedis" is not. > > -- >=20 > It seems to me that this sentence conflates two issues: > 1. Whether a tag is correctly formed or not (not just syntactically). > 2. Whether a tag is appropriate for some particular data. >=20 > Concentrating on the first issue, maybe the sentence should read > (less confusingly): > --- > For example, the 'Prefix' for the variant 'nedis' is "sl", meaning that > the tags "sl-nedis" and "sl-IT-nedis" are correctly formed tags while > the tag "is-nedis" is not. This would make this a syntactic constraint. I'm not sure that's what's intended.=20 Note that for extlang, the draft states that the specified prefix MUST be used. Thus, if "cmn" has a specified prefix "zh", then "fr-cmn" is not correctly formed. In contrast, the draft states that the specified prefixes for a variant are those that would be suitable. It does not suggest that "is-nedis" is ill-formed; it just suggests that it's not semantically a good choice (similar to th-MX not being a good choice). So, this boils down to whether we want prefixes for variants to be constraints on syntactic well-formedness, or rather to be recommendations on appropriate semantic collocation. I vaguely recall that we discussed this and chose the latter. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:43:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDhS-00084w-5m; Fri, 02 Sep 2005 11:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDhQ-00082s-Oo for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:43:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14480 for ; Fri, 2 Sep 2005 11:43:26 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDjY-0007uv-TK for ltru@ietf.org; Fri, 02 Sep 2005 11:45:44 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 08:43:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Fri, 2 Sep 2005 08:43:07 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB439F6@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) Thread-Index: AcWv0AV68r3tHnIqRYKh2mdjr3yNFAABFJqw From: "Addison Phillips" To: "Kent Karlsson" , X-OriginalArrivalTime: 02 Sep 2005 15:43:07.0516 (UTC) FILETIME=[03B733C0:01C5AFD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > It seems to me that this sentence conflates two issues: > 1. Whether a tag is correctly formed or not (not just syntactically). > 2. Whether a tag is appropriate for some particular data. > > Concentrating on the first issue, maybe the sentence should read > (less confusingly): Actually, no. The meaning of the Prefix field is actually (2). That is, = the tag "zh-nedis" is "valid" and "well-formed", but is a poor choice. = That is, Prefix is non-normative for variants. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Kent Karlsson > Sent: 2005?9?2? 8:07 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) >=20 > > -- > > For example, the 'Prefix' for the variant 'nedis' is "sl", meaning = that > > the tags "sl-nedis" and "sl-IT-nedis" might be appropriate choices = while > > the tag "is-nedis" is not. > > -- >=20 > It seems to me that this sentence conflates two issues: > 1. Whether a tag is correctly formed or not (not just syntactically). > 2. Whether a tag is appropriate for some particular data. >=20 > Concentrating on the first issue, maybe the sentence should read > (less confusingly): > --- > For example, the 'Prefix' for the variant 'nedis' is "sl", meaning = that > the tags "sl-nedis" and "sl-IT-nedis" are correctly formed tags while > the tag "is-nedis" is not. > --- >=20 > /Kent K >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:54:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDrm-0005Vf-MQ; Fri, 02 Sep 2005 11:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDrl-0005VW-2M for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:54:09 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15041 for ; Fri, 2 Sep 2005 11:54:06 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EBDov-0007Be-2E for ltru@lists.ietf.org; Fri, 02 Sep 2005 17:51:13 +0200 Received: from c-134-89-36.hh.dial.de.ignite.net ([62.134.89.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Sep 2005 17:51:13 +0200 Received: from nobody by c-134-89-36.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Sep 2005 17:51:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 02 Sep 2005 17:48:10 +0200 Organization: Lines: 20 Message-ID: <4318743A.3856@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-36.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: At least one prefix for variant (GenArt) #18 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I recall that his request for -north etc were opposed. I > don't recall that generic variants were ruled out > altogether, though. The latter would be "our" (LTRU) job. The discussion on the revie list was an experiment from my POV, resulting in a REQUIRED in the last called draft. Let's assume that John likes the concept, and I think that it could be more harmful than useful. What's your idea, allow it with an explicit CAVEAT for the review list ? I'd really hate it if we get crappy generic variants like the infamous "presence locations" (bathroom, yacht, in bed, in bed alone, airport, airport toilet, etc.) Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:54:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDs5-0005X4-Rs; Fri, 02 Sep 2005 11:54:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDs5-0005WU-2u for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:54:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15050 for ; Fri, 2 Sep 2005 11:54:26 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDuF-0008Jz-Ij for ltru@ietf.org; Fri, 02 Sep 2005 11:56:44 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 08:54:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Fri, 2 Sep 2005 08:54:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB43A0A@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) Thread-Index: AcWv0AfKRrtGEnTuRGqdO7BQHJnScAAA3FngAABwrIA= From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 02 Sep 2005 15:54:18.0747 (UTC) FILETIME=[93CCECB0:01C5AFD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org >=20 > This would make this a syntactic constraint. I'm not sure that's = what's > intended. [Addison Phillips]=20 I'm quite sure that this was not intended. >=20 > Note that for extlang, the draft states that the specified prefix MUST > be used. Thus, if "cmn" has a specified prefix "zh", then "fr-cmn" is > not correctly formed. In contrast, the draft states that the specified > prefixes for a variant are those that would be suitable. It does not > suggest that "is-nedis" is ill-formed; it just suggests that it's not > semantically a good choice (similar to th-MX not being a good choice). [Addison Phillips]=20 Exactly so. This is an example of being parsimonious in what you = generate and promiscuous in what you accept. Making the prefix normative = would place an unnecessary burden on the accepting processor. >=20 > So, this boils down to whether we want prefixes for variants to be > constraints on syntactic well-formedness, or rather to be > recommendations on appropriate semantic collocation. I vaguely recall > that we discussed this and chose the latter. >=20 Yep. See for example roughly here: http://article.gmane.org/gmane.ietf.ltru/2082/match=3Dvariant+prefix+requ= ired Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 11:59:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDx0-0007WE-Fj; Fri, 02 Sep 2005 11:59:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDwy-0007W4-SS for ltru@megatron.ietf.org; Fri, 02 Sep 2005 11:59:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15263 for ; Fri, 2 Sep 2005 11:59:30 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDz8-0008Sk-7S for ltru@ietf.org; Fri, 02 Sep 2005 12:01:48 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j82FxG0b008993 for ; Fri, 2 Sep 2005 11:59:16 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j82FxGdm054690 for ; Fri, 2 Sep 2005 11:59:16 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j82FxGeX025102 for ; Fri, 2 Sep 2005 11:59:16 -0400 Received: from [127.0.0.1] (sig-9-48-125-182.mts.ibm.com [9.48.125.182]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j82Fx8Rq023395; Fri, 2 Sep 2005 11:59:10 -0400 Message-ID: <431876C1.90902@icu-project.org> Date: Fri, 02 Sep 2005 08:58:57 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > recommendations on appropriate semantic collocation. I vaguely recall > that we discussed this and chose the latter. I agree; it was definitely a recommendation for appropriate semantics, not a syntactic restriction. Mark Peter Constable wrote: >>From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf > > Of > >>Kent Karlsson > > > >>>For example, the 'Prefix' for the variant 'nedis' is "sl", meaning > > that > >>>the tags "sl-nedis" and "sl-IT-nedis" might be appropriate choices > > while > >>>the tag "is-nedis" is not. >>>-- >> >>It seems to me that this sentence conflates two issues: >>1. Whether a tag is correctly formed or not (not just syntactically). >>2. Whether a tag is appropriate for some particular data. >> >>Concentrating on the first issue, maybe the sentence should read >>(less confusingly): >>--- >>For example, the 'Prefix' for the variant 'nedis' is "sl", meaning > > that > >>the tags "sl-nedis" and "sl-IT-nedis" are correctly formed tags while >>the tag "is-nedis" is not. > > > This would make this a syntactic constraint. I'm not sure that's what's > intended. > > Note that for extlang, the draft states that the specified prefix MUST > be used. Thus, if "cmn" has a specified prefix "zh", then "fr-cmn" is > not correctly formed. In contrast, the draft states that the specified > prefixes for a variant are those that would be suitable. It does not > suggest that "is-nedis" is ill-formed; it just suggests that it's not > semantically a good choice (similar to th-MX not being a good choice). > > So, this boils down to whether we want prefixes for variants to be > constraints on syntactic well-formedness, or rather to be > recommendations on appropriate semantic collocation. I vaguely recall > that we discussed this and chose the latter. > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 12:01:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDys-0008EG-8Z; Fri, 02 Sep 2005 12:01:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDyq-0008Dp-LT for ltru@megatron.ietf.org; Fri, 02 Sep 2005 12:01:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15349 for ; Fri, 2 Sep 2005 12:01:26 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBE11-00005Q-6M for ltru@ietf.org; Fri, 02 Sep 2005 12:03:44 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j82G1IWF028215 for ; Fri, 2 Sep 2005 12:01:18 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j82G1IMj085300 for ; Fri, 2 Sep 2005 12:01:18 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j82G14ew000363 for ; Fri, 2 Sep 2005 12:01:05 -0400 Received: from [127.0.0.1] (sig-9-48-125-182.mts.ibm.com [9.48.125.182]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j82G0v5K031796; Fri, 2 Sep 2005 12:00:58 -0400 Message-ID: <4318772F.2000007@icu-project.org> Date: Fri, 02 Sep 2005 09:00:47 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Re: give ABNF for Prefix (gen-art #15) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Let me try to be clearer. If we are making no material changes to the document, only editorial fixes, then I don't suggest any changes. If we do make any material changes, then I would like to see the addition I suggested, to allow for future extensions. Mark Peter Constable wrote: >>From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf > > Of > >>Mark Davis > > > >> > The other change I wouldn't want to insert at this late date unless >>we're modifying the ABNF for some other purpose. >> >> >>I firmly agree; at this late date we shouldn't change anything > > material > >>in the document unless we have to make material changes anyway. My > > only > >>thought is that if we *do* have to make a material change, then it > > would > >>good to add this at the same time. > > > Add *what*, Mark? Add ABNF to specify what can go in Prefix fields? That > would have no bearing whatsoever on the langtag ABNF. Please clarify. > What material change do you perceive is already being made? > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 12:48:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBEii-0005DP-7M; Fri, 02 Sep 2005 12:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBEih-0005DK-2t for ltru@megatron.ietf.org; Fri, 02 Sep 2005 12:48:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17189 for ; Fri, 2 Sep 2005 12:48:48 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBEkr-0001gG-Vc for ltru@ietf.org; Fri, 02 Sep 2005 12:51:07 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j82GmaCG008747 for ; Fri, 2 Sep 2005 12:48:36 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j82Gmadm076930 for ; Fri, 2 Sep 2005 12:48:36 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j82GmZcK009099 for ; Fri, 2 Sep 2005 12:48:35 -0400 Received: from [127.0.0.1] (sig-9-48-125-182.mts.ibm.com [9.48.125.182]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j82GmTJ2008599; Fri, 2 Sep 2005 12:48:30 -0400 Message-ID: <4318825C.3030902@icu-project.org> Date: Fri, 02 Sep 2005 09:48:28 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: r&d afrac Subject: Re: [Ltru] Re: At least one prefix for variant (GenArt) #18 References: <634978A7DF025A40BFEF33EB191E13BC0CA91542@irvmbxw01.quest.com> <20050901165823.GB17084@NYCMJCOWA2> <43175FD0.3232@xyzzy.claranet.de> <6.2.3.4.2.20050902140654.04d97860@mail.afrac.org> In-Reply-To: <6.2.3.4.2.20050902140654.04d97860@mail.afrac.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > I note that Mark wants to be able to support en-189-us? Would that be > for voice subtags? Would be an interesting move. Incorrect. I was suggesting reserving certain subtags for future use as either scripts/orthographies or regions. But "en-189-us" doesn't match what I said; look at the ABNF: - scripts would always be 4 characters, and - regions would always be 2 or 3 characters. So your example is invalid under both the current proposal and under my suggested addition of reservations for the future, since your example has 2 region codes in a row. More realistic examples would be: el-Ply0-GR // Ply0 is an example of a possible future use, e.g. polytonic or en-PR0 // US2 is an example of a possible future use, e.g. a historic region like Prussia Frankly (or Ellermanly), regions are not that interesting, because variants are adjacent in the tags, and thus would have the right fallback behavior. However, script/orthographies are interesting, since they *can't* be replaced by variants in fallback; you get the wrong answer. Mark r&d afrac wrote: > At 22:08 01/09/2005, Frank Ellermann wrote: > >> John.Cowan wrote: >> > I request (as part of Last Call) that this be reconsidered >> > by the WG. >> >> You tested the idea of generic variants on the review list >> (among others -north, -east, -west, -south, and what I recall >> as -familiar, but that wasn't your proposal) >> >> The result of this discussion was "bad idea" (okay, I wasn't >> sure that it's necessarily bad, I said "utter dubious" for >> your old examples). > > > John has no problem in using an x-tag. > > en-x-east. > > Happily there is no private use return singleton, like say "u-". We > would have a "en-x-east-u-Latn-us" mess.... > But he can have "en-Latn-us-x-east. > > I note that Mark wants to be able to support en-189-us? Would that be > for voice subtags? Would be an interesting move. > jfc > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 16:48:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBIT0-0005vZ-1H; Fri, 02 Sep 2005 16:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBISu-0005r8-Mn for ltru@megatron.ietf.org; Fri, 02 Sep 2005 16:48:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01940 for ; Fri, 2 Sep 2005 16:48:46 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBIV7-0002ES-Jo for ltru@ietf.org; Fri, 02 Sep 2005 16:51:06 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j82KmYNo005683; Fri, 2 Sep 2005 16:48:34 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 2 Sep 2005 16:48:33 -0400 Date: Fri, 2 Sep 2005 16:48:33 -0400 From: "John.Cowan" To: Peter Constable Subject: Re: [Ltru] At least one prefix for variant (GenArt) Message-ID: <20050902204833.GB17400@NYCMJCOWA2> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > > What's the argument against just allowing zero prefixes for variants? > > If you want to allow a null field-value in the prefix field, wouldn't it > make more sense to say that a prefix field is not required? Actually, I meant "What's the argument against just allowing no 'Prefix:' fields in the definition of a variant?" (I can see how the collocation "zero prefix" would cause trouble here.) I agree that -north -south -east -west -old -middle -modern are problematic, but I don't think -signed is. Of course, one could enter an arbitrary prefix like "en" for -signed, since that would allow its use with any language subtag, but I don't think that's in accordance with the spirit of the thing. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan The known is finite, the unknown infinite; intellectually we stand on an islet in the midst of an illimitable ocean of inexplicability. Our business in every generation is to reclaim a little more land, to add something to the extent and the solidity of our possessions. --Thomas Henry Huxley _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 17:04:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBIhc-00057s-PZ; Fri, 02 Sep 2005 17:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBIha-00057k-Pu for ltru@megatron.ietf.org; Fri, 02 Sep 2005 17:03:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02629 for ; Fri, 2 Sep 2005 17:03:56 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBIjn-0002iV-VU for ltru@ietf.org; Fri, 02 Sep 2005 17:06:17 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j82L3m2s005735; Fri, 2 Sep 2005 17:03:48 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 2 Sep 2005 17:03:48 -0400 Date: Fri, 2 Sep 2005 17:03:48 -0400 From: "John.Cowan" To: Frank Ellermann Subject: Re: [Ltru] Re: At least one prefix for variant (GenArt) #18 Message-ID: <20050902210347.GC17400@NYCMJCOWA2> References: <4318743A.3856@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4318743A.3856@xyzzy.claranet.de> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Let's assume that John likes the concept, and I think that > it could be more harmful than useful. What's your idea, > allow it with an explicit CAVEAT for the review list ? That would be my idea too. > I'd really hate it if we get crappy generic variants like > the infamous "presence locations" (bathroom, yacht, in bed, > in bed alone, airport, airport toilet, etc.) So would I, but ietf-languages folk are sensible and cautious. (Except me.) -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com [T]here is a Darwinian explanation for the refusal to accept Darwin. Given the very pessimistic conclusions about moral purpose to which his theory drives us, and given the importance of a sense of moral purpose in helping us cope with life, a refusal to believe Darwin's theory may have important survival value. --Ian Johnston _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 17:22:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBIzb-00055b-FF; Fri, 02 Sep 2005 17:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBIzZ-00052D-SP for ltru@megatron.ietf.org; Fri, 02 Sep 2005 17:22:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03487 for ; Fri, 2 Sep 2005 17:22:29 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBJ1k-0003Jw-VN for ltru@ietf.org; Fri, 02 Sep 2005 17:24:50 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 14:22:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: At least one prefix for variant (GenArt) #18 Date: Fri, 2 Sep 2005 14:22:08 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB43BCA@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: At least one prefix for variant (GenArt) #18 Thread-Index: AcWwAgow1BDqvPFdQq+9mG15+EOKvwAAXLCQ From: "Addison Phillips" To: "John.Cowan" , "Frank Ellermann" X-OriginalArrivalTime: 02 Sep 2005 21:22:09.0559 (UTC) FILETIME=[6084A270:01C5B004] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org So we're saying: leave all other text alone and change this item in = Section 3.5: -- Variant subtags are always registered for use with a particular range of = language tags. For example, the subtag 'rozaj' is intended for use with = language tags that start with the primary language subtag "sl", since = Resian is a dialect of Slovenian. Thus the subtag 'rozaj' could be = included in tags such as "sl-Latn-rozaj" or "sl-IT-rozaj". This = information is stored in the "Prefix" field in the registry. Variant = registration requests are REQUIRED to include at least one "Prefix" = field in the registration form. -- To read like this (changes in /* */): -- Variant subtags are /*usually*/ registered for use with a particular = range of language tags. For example, the subtag 'rozaj' is intended for = use with language tags that start with the primary language subtag "sl", = since Resian is a dialect of Slovenian. Thus the subtag 'rozaj' /* would = be appropriate */ in tags such as "sl-Latn-rozaj" or "sl-IT-rozaj". This = information is stored in the "Prefix" field in the registry. Variant = registration requests /* SHOULD */ include at least one "Prefix" field = in the registration form. -- Note that the use of the normative SHOULD indicates a strong caveat is = in place, but it isn't a MUST and thus not an absolute prohibition. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > John.Cowan > Sent: 2005?9?2? 14:04 > To: Frank Ellermann > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: At least one prefix for variant (GenArt) #18 >=20 > Frank Ellermann scripsit: >=20 > > Let's assume that John likes the concept, and I think that > > it could be more harmful than useful. What's your idea, > > allow it with an explicit CAVEAT for the review list ? >=20 > That would be my idea too. >=20 > > I'd really hate it if we get crappy generic variants like > > the infamous "presence locations" (bathroom, yacht, in bed, > > in bed alone, airport, airport toilet, etc.) >=20 > So would I, but ietf-languages folk are sensible and cautious. > (Except me.) >=20 > -- > John Cowan www.ccil.org/~cowan www.reutershealth.com > jcowan@reutershealth.com > [T]here is a Darwinian explanation for the refusal to accept Darwin. > Given the very pessimistic conclusions about moral purpose to which = his > theory drives us, and given the importance of a sense of moral purpose > in helping us cope with life, a refusal to believe Darwin's theory may > have important survival value. --Ian Johnston >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 17:55:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBJVv-0001g8-Lu; Fri, 02 Sep 2005 17:55:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBJVu-0001g3-TU for ltru@megatron.ietf.org; Fri, 02 Sep 2005 17:55:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04757 for ; Fri, 2 Sep 2005 17:55:56 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBJY8-0004Io-Jd for ltru@ietf.org; Fri, 02 Sep 2005 17:58:17 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j82LtkfU005935; Fri, 2 Sep 2005 17:55:46 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 2 Sep 2005 17:55:46 -0400 Date: Fri, 2 Sep 2005 17:55:46 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] Re: At least one prefix for variant (GenArt) #18 Message-ID: <20050902215545.GB17700@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0CB43BCA@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB43BCA@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Variant subtags are /*usually*/ registered for use with a particular > range of language tags. For example, the subtag 'rozaj' is intended > for use with language tags that start with the primary language > subtag "sl", since Resian is a dialect of Slovenian. Thus the subtag > 'rozaj' /* would be appropriate */ in tags such as "sl-Latn-rozaj" or > "sl-IT-rozaj". This information is stored in the "Prefix" field in > the registry. Variant registration requests /* SHOULD */ include at > least one "Prefix" field in the registration form. +1 -- But that, he realized, was a foolish John Cowan thought; as no one knew better than he jcowan@reutershealth.com that the Wall had no other side. http://www.ccil.org/~cowan --Arthur C. Clarke, "The Wall of Darkness" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 18:29:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBK2F-0008UL-HO; Fri, 02 Sep 2005 18:29:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBK2D-0008UB-6P for ltru@megatron.ietf.org; Fri, 02 Sep 2005 18:29:21 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07481 for ; Fri, 2 Sep 2005 18:29:18 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EBJzU-0000DG-Ks for ltru@lists.ietf.org; Sat, 03 Sep 2005 00:26:32 +0200 Received: from 212.82.251.129 ([212.82.251.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Sep 2005 00:26:32 +0200 Received: from nobody by 212.82.251.129 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Sep 2005 00:26:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 03 Sep 2005 00:20:55 +0200 Organization: Lines: 6 Message-ID: <4318D047.1A91@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CB43BCA@irvmbxw01.quest.com> <20050902215545.GB17700@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.129 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: At least one prefix for variant (GenArt) #18 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John.Cowan wrote: > +1 Make that +2 ;-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 18:44:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKH2-0006YE-A1; Fri, 02 Sep 2005 18:44:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKGy-0006Qp-9Y for ltru@megatron.ietf.org; Fri, 02 Sep 2005 18:44:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08302 for ; Fri, 2 Sep 2005 18:44:33 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBKJC-0005oa-BA for ltru@ietf.org; Fri, 02 Sep 2005 18:46:55 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j82MiQ84031788 for ; Fri, 2 Sep 2005 18:44:26 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j82MiPdm097634 for ; Fri, 2 Sep 2005 18:44:25 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j82MiPsU017424 for ; Fri, 2 Sep 2005 18:44:25 -0400 Received: from [127.0.0.1] (sig-9-48-125-182.mts.ibm.com [9.48.125.182]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j82MiKpv017294; Fri, 2 Sep 2005 18:44:21 -0400 Message-ID: <4318D5C2.3050503@icu-project.org> Date: Fri, 02 Sep 2005 15:44:18 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John.Cowan" Subject: Re: [Ltru] Re: At least one prefix for variant (GenArt) #18 References: <634978A7DF025A40BFEF33EB191E13BC0CB43BCA@irvmbxw01.quest.com> <20050902215545.GB17700@NYCMJCOWA2> In-Reply-To: <20050902215545.GB17700@NYCMJCOWA2> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org +1 John.Cowan wrote: > Addison Phillips scripsit: > > >>Variant subtags are /*usually*/ registered for use with a particular >>range of language tags. For example, the subtag 'rozaj' is intended >>for use with language tags that start with the primary language >>subtag "sl", since Resian is a dialect of Slovenian. Thus the subtag >>'rozaj' /* would be appropriate */ in tags such as "sl-Latn-rozaj" or >>"sl-IT-rozaj". This information is stored in the "Prefix" field in >>the registry. Variant registration requests /* SHOULD */ include at >>least one "Prefix" field in the registration form. > > > +1 > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 23:11:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBORO-0000B2-SL; Fri, 02 Sep 2005 23:11:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBORN-0000AM-BB for ltru@megatron.ietf.org; Fri, 02 Sep 2005 23:11:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26106 for ; Fri, 2 Sep 2005 23:11:35 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBOTe-0007eS-JM for ltru@ietf.org; Fri, 02 Sep 2005 23:13:58 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:11:27 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:11:26 -0700 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 Subject: RE: [Ltru] Re: give ABNF for Prefix (gen-art #15) Date: Fri, 2 Sep 2005 20:11:31 -0700 Message-ID: Thread-Topic: [Ltru] Re: give ABNF for Prefix (gen-art #15) thread-index: AcWv17dAE0VcM0iPQwWVKhTJymJYuQAXO+hQ From: "Peter Constable" To: X-OriginalArrivalTime: 03 Sep 2005 03:11:26.0913 (UTC) FILETIME=[2C131310:01C5B035] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: Mark Davis [mailto:mark.davis@icu-project.org] > Let me try to be clearer. If we are making no material changes to the > document, only editorial fixes, then I don't suggest any changes. If we > do make any material changes, then I would like to see the addition I > suggested, to allow for future extensions. But AFAIK you didn't make a specific suggested. You responded to Addison's message saying "make the following additions", where the only following additions were the ABNF Addison drafted for Prefix -- which do not materially change any possible future extensions. Unless I've missed something, you still haven't been clear enough about what you propose for anyone to comment on. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 23:18:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOXY-0002Al-F6; Fri, 02 Sep 2005 23:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOXW-00026p-8P for ltru@megatron.ietf.org; Fri, 02 Sep 2005 23:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26502 for ; Fri, 2 Sep 2005 23:17:56 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBOZm-0007uu-LG for ltru@ietf.org; Fri, 02 Sep 2005 23:20:19 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:17:47 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:17:47 -0700 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 Subject: RE: [Ltru] Re: At least one prefix for variant (GenArt) #18 Date: Fri, 2 Sep 2005 20:17:51 -0700 Message-ID: Thread-Topic: [Ltru] Re: At least one prefix for variant (GenArt) #18 thread-index: AcWwEAujVQZA9A3WQAyOwfc178lXzgAJa1BQ From: "Peter Constable" To: X-OriginalArrivalTime: 03 Sep 2005 03:17:47.0303 (UTC) FILETIME=[0ECDFB70:01C5B036] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I'm OK with this in principle. One question: would it be clear if no prefix field is included that the intent is that the variant is generic and could be included with any prefix (as opposed to the requester simply forgot or didn't bother)? Peter Constable > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Mark Davis > Sent: Friday, September 02, 2005 3:44 PM > To: John.Cowan > Cc: Frank Ellermann; ltru@ietf.org > Subject: Re: [Ltru] Re: At least one prefix for variant (GenArt) #18 >=20 > +1 >=20 > John.Cowan wrote: > > Addison Phillips scripsit: > > > > > >>Variant subtags are /*usually*/ registered for use with a particular > >>range of language tags. For example, the subtag 'rozaj' is intended > >>for use with language tags that start with the primary language > >>subtag "sl", since Resian is a dialect of Slovenian. Thus the subtag > >>'rozaj' /* would be appropriate */ in tags such as "sl-Latn-rozaj" or > >>"sl-IT-rozaj". This information is stored in the "Prefix" field in > >>the registry. Variant registration requests /* SHOULD */ include at > >>least one "Prefix" field in the registration form. > > > > > > +1 > > >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 23:20:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOZg-00041F-9m; Fri, 02 Sep 2005 23:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOZe-00041A-3J for ltru@megatron.ietf.org; Fri, 02 Sep 2005 23:20:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26655 for ; Fri, 2 Sep 2005 23:20:07 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBObv-0007yo-Fi for ltru@ietf.org; Fri, 02 Sep 2005 23:22:31 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:20:00 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:20:00 -0700 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 Subject: RE: [Ltru] maintain registration records for every single subtag(gen-art #10) Date: Fri, 2 Sep 2005 20:20:04 -0700 Message-ID: Thread-Topic: [Ltru] maintain registration records for every single subtag(gen-art #10) thread-index: AcWvGYbMjBJ3kBS5T5iHH+XVliY9NgBHM3GA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 03 Sep 2005 03:20:00.0253 (UTC) FILETIME=[5E0C8AD0:01C5B036] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: Elwyn Davies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org +1 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Addison Phillips > Sent: Thursday, September 01, 2005 10:21 AM > To: LTRU Working Group > Cc: Elwyn Davies > Subject: [Ltru] maintain registration records for every single subtag(gen- > art #10) >=20 > > > s3.1: para 1, last sentence: Given that *all* the initial records > > > are in the initial registry load RFC, maintaining registration forms > > > for just the RFC3066 subset seems a little odd. Why not all or > > > none, since presumably they can be created by an automated script? > > [Addison Phillips] > > > > The RFC 3066 registry is maintained in perpetuity and its format is > > different than that of the draft. That registry is maintained as an > > obsolete reference (it just seemed prudent to do so). Generating many > > registration forms for the initial set, however, doesn't seem that > useful. >=20 > The proposal is to generate bogus registration forms for every subtag. I > believe this is a mis-reading of the original intention (which was that > the existing RFC 3066 registry be preserved). >=20 > I note that, as written, the IANA considerations do not preserve the > registration forms! The approved record is entered into the registry and > the form is apparently discarded. Section 5 says this clearly and Sections > 3.2 and 3.4 imply it strongly. The only reference to the maintenance of > registration forms is the cited sentence in Section 3.1, para 1, which > says that the forms will be preserved. We should decide which one. >=20 > Proposed Solution: >=20 > Change the cited sentence: >=20 > -- > With the exception of the registration forms for grandfathered and > redundant tags, no registration records will be maintained for the initial > set of subtags. > -- >=20 > To read: >=20 > -- > The existing registration forms for RFC 3066 grandfathered and redundant > tags will be maintained as part of the obsolete RFC 3066 registry. The > remaining set of initial subtags will not have registration forms created > for them. > -- >=20 > And change this sentence in Section 5: >=20 > -- > Future work on the Language Subtag Registry SHALL be limited to inserting > or replacing whole records preformatted for IANA by the Language Subtag > Reviewer as described in Section 3.2 (Maintenance of the Registry) of this > document. > -- >=20 > To read: >=20 > -- > Future work on the Language Subtag Registry SHALL be limited to inserting > or replacing whole records preformatted for IANA by the Language Subtag > Reviewer as described in Section 3.2 (Maintenance of the Registry) of this > document and archiving the forwarded registration form. > -- >=20 > Addison P. Phillips > Globalization Architect, Quest Software > http://www.quest.com >=20 > Chair, W3C Internationalization Core Working Group > http://www.w3.org/International >=20 > Internationalization is not a feature. > It is an architecture. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 23:28:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOhh-0007P1-Qi; Fri, 02 Sep 2005 23:28:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOhg-0007O6-0T for ltru@megatron.ietf.org; Fri, 02 Sep 2005 23:28:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27068 for ; Fri, 2 Sep 2005 23:28:25 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBOjv-0008DO-TN for ltru@ietf.org; Fri, 02 Sep 2005 23:30:49 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:28:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:28:16 -0700 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 Subject: RE: [Ltru] make hypothetical nature of extlang registrations clear(gen-art #17) Date: Fri, 2 Sep 2005 20:28:20 -0700 Message-ID: Thread-Topic: [Ltru] make hypothetical nature of extlang registrations clear(gen-art #17) thread-index: AcWvJvJnXnMOpHw0QweTE9g1RgMZ1QBEJCoQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 03 Sep 2005 03:28:16.0572 (UTC) FILETIME=[85E0CFC0:01C5B037] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: Elwyn Davies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org +1 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Addison Phillips > Sent: Thursday, September 01, 2005 11:57 AM > To: LTRU Working Group > Cc: Elwyn Davies > Subject: [Ltru] make hypothetical nature of extlang registrations > clear(gen-art #17) >=20 > > > s3.4: para 2 and para next but one after Figure 5: At first sight > > > these paras appear to conflict? the second one appears to indicate > > > that type 'extlang' subtags can be registered but they are not > > > mentioned in the first one. Presumably this is because extlang is > > > currently reserved for future use, but it would be good to mention > > > this in para 2. Text saying something like 'extlang records will > > > also be able to be registered by this process when they are > introduced'. > > [Addison Phillips] > > > > The key word in para 2 is "independently". There are also > > registrations that can occur due to standards body activity > > (assignment of a new ISO > > 3166 code, for example). > > > > Extlangs cannot currently be registered, as noted they are reserved. > > However, the rules for extlangs are spelled out so that > > implementations can take them into account. Therefore it is important > > to point out that they must have a Prefix again here. The conditional > > nature of their existence might be better mirrored by the wording, > though. >=20 > Proposed Solution: >=20 > Although many people seem to miss the word "independently", para2 really > doesn't need to be modified. I propose we modify this sentence: >=20 > -- > Variant and extlang subtags are always registered for use with a > particular range of language tags. > -- >=20 > To say: >=20 > -- > Variant subtags are always registered for use with a particular range of > language tags. > -- >=20 > And then following that paragraph a new para saying: >=20 > -- > Extended language subtags are reserved for future standardization. > These subtags will be REQUIRED to include exactly one "Prefix" field once > they are allowed for registration. > -- >=20 > Addison P. Phillips > Globalization Architect, Quest Software > http://www.quest.com >=20 > Chair, W3C Internationalization Core Working Group > http://www.w3.org/International >=20 > Internationalization is not a feature. > It is an architecture. >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 23:29:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOj4-0007eB-7I; Fri, 02 Sep 2005 23:29:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOj2-0007dB-Lo for ltru@megatron.ietf.org; Fri, 02 Sep 2005 23:29:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27109 for ; Fri, 2 Sep 2005 23:29:50 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBOlI-0008Gs-QY for ltru@ietf.org; Fri, 02 Sep 2005 23:32:14 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:29:41 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:29:41 -0700 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 Subject: RE: [Ltru] what happens when GF tag and new registration with differentmeaning collide (gen-art #17) Date: Fri, 2 Sep 2005 20:29:45 -0700 Message-ID: Thread-Topic: [Ltru] what happens when GF tag and new registration with differentmeaning collide (gen-art #17) thread-index: AcWvIzgAD18smxU5RfWCYowGycBHDgBFHvMA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 03 Sep 2005 03:29:41.0280 (UTC) FILETIME=[B85E3A00:01C5B037] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: Elwyn Davies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org +1 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Addison Phillips > Sent: Thursday, September 01, 2005 11:31 AM > To: LTRU Working Group > Cc: Elwyn Davies > Subject: [Ltru] what happens when GF tag and new registration with > differentmeaning collide (gen-art #17) >=20 > > > s3.3: Item 12: Is there any chance that the meaning of the > > > grandfathered tag and the (later) combination of valid subtags might > > > be different? If so what should happen? The reviewer should take a > > > view on this I think! Should there be some words on how to process > > > such overlaps in the validating processor section? > > [Addison Phillips] > > > > There is a very small chance of this happening, so it should be dealt > > with as noted. >=20 > Proposed Solution: >=20 > Add the following text after the bullet list in Section 3.5 (Possibilities > for Registration): >=20 > -- > Note: Subtags proposed for registration that would cause all or part of a > grandfathered tag to become redundant but who's meaning conflicts with or > alters the meaning of the grandfathered tag MUST be rejected. > -- >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > http://www.quest.com >=20 > Chair, W3C Internationalization Core Working Group > http://www.w3.org/International >=20 > Internationalization is not a feature. > It is an architecture. >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 02 23:35:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOoF-0002Ym-BE; Fri, 02 Sep 2005 23:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOoD-0002Yh-1G for ltru@megatron.ietf.org; Fri, 02 Sep 2005 23:35:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27260 for ; Fri, 2 Sep 2005 23:35:10 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBOqU-0008NS-2r for ltru@ietf.org; Fri, 02 Sep 2005 23:37:34 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:35:02 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Sep 2005 20:35:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Sep 2005 20:35:07 -0700 Message-ID: Thread-Topic: proposed changes in response to GenArt comments thread-index: AcWwOHqK78y0Zay1Qg+CzlA9PyWC9g== From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 03 Sep 2005 03:35:02.0997 (UTC) FILETIME=[78205850:01C5B038] X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [Ltru] proposed changes in response to GenArt comments X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1327206669==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1327206669== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5B038.77ED89D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B038.77ED89D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There have been so many separate issues I've lost track of which I've specifically commented on. I believe I have no problem with any of the dispositions proposed by Addison unless I have explicitly indicated otherwise. =20 =20 =20 Peter Constable ------_=_NextPart_001_01C5B038.77ED89D8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There have been so many separate issues I’ve = lost track of which I’ve specifically commented on. I believe I have no problem with any of the dispositions proposed by Addison unless I have explicitly indicated = otherwise.

 

 

 

Peter Constable

------_=_NextPart_001_01C5B038.77ED89D8-- --===============1327206669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1327206669==-- From ltru-bounces@ietf.org Fri Sep 02 23:57:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBP9o-00039H-Vm; Fri, 02 Sep 2005 23:57:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBP9m-00038i-T9 for ltru@megatron.ietf.org; Fri, 02 Sep 2005 23:57:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27921 for ; Fri, 2 Sep 2005 23:57:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBPC3-0000VH-Cg for ltru@ietf.org; Fri, 02 Sep 2005 23:59:52 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EBP9f-0001x0-Sa; Fri, 02 Sep 2005 20:57:24 -0700 Message-Id: <6.2.3.4.2.20050903010528.05df5d60@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 03 Sep 2005 05:57:17 +0200 To: Mark Davis From: r&d afrac Subject: Re: [Ltru] Re: At least one prefix for variant (GenArt) #18 In-Reply-To: <4318825C.3030902@icu-project.org> References: <634978A7DF025A40BFEF33EB191E13BC0CA91542@irvmbxw01.quest.com> <20050901165823.GB17084@NYCMJCOWA2> <43175FD0.3232@xyzzy.claranet.de> <6.2.3.4.2.20050902140654.04d97860@mail.afrac.org> <4318825C.3030902@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 18:48 02/09/2005, Mark Davis wrote: > > I note that Mark wants to be able to support en-189-us? Would that be > > for voice subtags? Would be an interesting move. > >Incorrect. I was suggesting reserving certain subtags for future use >as either scripts/orthographies or regions. But "en-189-us" doesn't >match what I said; look at the ABNF: >- scripts would always be 4 characters, and >- regions would always be 2 or 3 characters. Dear Mark, correct. I misread the proposition. >So your example is invalid under both the current proposal and under >my suggested addition of reservations for the future, since your >example has 2 region codes in a row. >More realistic examples would be: > >el-Ply0-GR // Ply0 is an example of a possible future use, e.g. polytonic >or >en-PR0 // US2 is an example of a possible future use, e.g. a >historic region like Prussia > >Frankly (or Ellermanly), regions are not that interesting, because >variants are adjacent in the tags, and thus would have the right >fallback behavior. >However, script/orthographies are interesting, since they *can't* be >replaced by variants in fallback; you get the wrong answer. So, you still do not want to document the multimodal aspects? This keeps the draft in the ISO 639 script oriented "mood" I would say? Up to now Addison and you responded quickly to protect the ABNF against my propositions. It lead to a far better clarity than in Dec last, and reduced the risks of conflicts with the URI-tags. Does that mean that you abandon us the voice/sign/icon.. documentation? I have no problem with that, but our MPEG liaison would like to know. Take care. jfc jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 20:44:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECRZN-00046L-2V; Mon, 05 Sep 2005 20:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECRZL-00046D-GH for ltru@megatron.ietf.org; Mon, 05 Sep 2005 20:44:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12574 for ; Mon, 5 Sep 2005 20:44:09 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECRcC-0003kY-4u for ltru@ietf.org; Mon, 05 Sep 2005 20:47:09 -0400 Received: from h-64-105-137-222.snvacaid.dynamic.covad.net ([64.105.137.222] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECRZD-0005qQ-00 for ltru@ietf.org; Mon, 05 Sep 2005 20:44:04 -0400 Message-ID: <016101c5b27c$5ff66800$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050901204312.DTQ7546.mta2.adelphia.net@megatron.ietf.org> <000801c5af4b$c36c7480$030aa8c0@DEWELL> Date: Mon, 5 Sep 2005 17:46:06 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ltru] [psg.com #1131] IETF/LC update entry for zh-guoyu X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - (note that this has been given an issue tracker number) > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Thursday, September 01, 2005 4:20 PM > Subject: [Ltru] Re: Gen-art review: draft-ietf-ltru-initial-04.txt > > Addison Phillips wrote: > > > Zh-cmn is NOT a valid 3066bis tag. It cannot be redundant currently. > > However, "zh-guoyu" should have a Preferred-Value of "zh-cmn". > > Based on the comment "It is understood that the 'guoyu' dialect tag will > be deprecated" in > http://www.alvestrand.no/pipermail/ietf-languages/2005-July/003532.html, > I had already added a Preferred-Value of "zh-cmn" and a Deprecated date > of 2005-07-15 to the entry for grandfathered tag "zh-guoyu", back in > draft-initial-03. > > The group and co-chairs should decide whether this is correct, or > whether the Deprecated date should actually be 2005-08-31 in accordance > with > http://www.alvestrand.no/pipermail/ietf-languages/2005-August/003568.html. > (Note that the subtag in question is "guoyu", not "quoyu".) ... So far, I haven't seen anything like a consensus on what to do with this item. If there is no consensus to change, then the decision about what (if anything) to do to zh-guoyu will be left for ietf-languages@iana.org to decide after the new registry goes into effect, whenever that might be. For now, I'll leave this open, but if no rough consensus emerges, it will be marked "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 20:56:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECRlG-0005Uj-AZ; Mon, 05 Sep 2005 20:56:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECRlE-0005Ue-6Z for ltru@megatron.ietf.org; Mon, 05 Sep 2005 20:56:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12850 for ; Mon, 5 Sep 2005 20:56:26 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECRo6-0003xc-EH for ltru@ietf.org; Mon, 05 Sep 2005 20:59:26 -0400 Received: from h-64-105-137-222.snvacaid.dynamic.covad.net ([64.105.137.222] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECRlC-0001vY-00 for ltru@ietf.org; Mon, 05 Sep 2005 20:56:26 -0400 Message-ID: <016801c5b27e$1db12820$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Mon, 5 Sep 2005 17:58:37 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] [psg.com #1130] IETF/LC remove rules in section 2 duplicated from registry draft X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - Regarding the initial registry... > Issue raised in Gen-ART review, see message > http://www1.ietf.org/mail-archive/web/ltru/current/msg03523.html > However, it is not raised as a critical issue, but as a minor > comment. As a technical contributor, I looked at what it would take to eliminate the redundancy by replacing the text with cross-references to the registry draft. It seems to me that the result was less clear than what is currently there, and, as the reviewer notes, this is a one-shot document, so maintenane isn't reall an issue. Consequently, though I started out thinking we should try to accommodate this comment, I've come around to thinking we should reject it. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 21:10:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECRz8-0007Fh-7I; Mon, 05 Sep 2005 21:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECRz7-0007FN-4H for ltru@megatron.ietf.org; Mon, 05 Sep 2005 21:10:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13321 for ; Mon, 5 Sep 2005 21:10:46 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECS1y-0004E2-UK for ltru@ietf.org; Mon, 05 Sep 2005 21:13:47 -0400 Received: from h-64-105-137-222.snvacaid.dynamic.covad.net ([64.105.137.222] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECRz1-0005Cv-00 for ltru@ietf.org; Mon, 05 Sep 2005 21:10:43 -0400 Message-ID: <01a001c5b280$1d199120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 5 Sep 2005 18:12:55 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ltru] issues numbered [psg.com #1107] to [psg.com #1129] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - I've added the Gen-ART review comments to the issue tracker, as well as a few others that have come along on the registry draft. I'll be adding more later, but I wanted to get this summary out. As much as was practical, I've retained the subject lines used in discussion so far, though in the cases like 16 and 17 where the same number was used for two issues, I've added an "a" and a "b". Don't blame me for the long subject lines! :-) I haven't seen a "6" or a "13", so I haven't created tickets for them. Please note that it's the RT number that's most helpful to me in tracking these. To view the issues, go to https://rt.psg.com/ (user and password "ietf") [psg.com #1107] IETF/LC Transition rules (gen-art 1) [psg.com #1108] IETF/LC Recall of the LSR (gen-art 2) [psg.com #1109] IETF/LC case canonicalization in registry (gen-art 3) [psg.com #1110] IETF/LC define the LSR (gen-art 4) [psg.com #1111] IETF/LC documenting the update load (gen-art 5) [psg.com #1112] IETF/LC various casing issues (gen-art 7) [psg.com #1113] IETF/LC UN economic groupings (gen-art 8) [psg.com #1114] IETF/LC define the LSR (gen-art 9) [psg.com #1115] IETF/LC numeric ranges in the registry (gen-art 11) [psg.com #1116] IETF/LC maintain registration records for every single subtag (gen-art 10) [psg.com #1117] IETF/LC include 'grandfathered' ANBF in 'Tag' description (gen-art 12) [psg.com #1118] IETF/LC remove MUST from capitalization in registry requirements (gen-art 14) [psg.com #1119] IETF/LC give ABNF for Prefix (gen-art 15) [psg.com #1120] IETF/LC ungarble description of Preferred-Value (gen-art 16a) [psg.com #1121] IETF/LC case of the subtag in a registration (gen-art 16b) [psg.com #1122] IETF/LC what happens when GF tag and new registration with different meaning collide (gen-art 17a) [psg.com #1123] IETF/LC make hypothetical nature of extlang registrations clear (gen-art 17b) [psg.com #1124] IETF/LC At least one prefix for variant [psg.com #1125] IETF/LC bad GF sentence in S3.2 [psg.com #1126] IETF/LC another GF text problem [psg.com #1127] IETF/LC choice of subtags in multilingual documents (gen-art 19) [psg.com #1128] IETF/LC clarifying what a redundant tag is (gen-art 20) [psg.com #1129] IETF/LC frowning on long texts (gen-art #21) Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 22:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECTYM-000396-5Q; Mon, 05 Sep 2005 22:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECTYL-000391-F0 for ltru@megatron.ietf.org; Mon, 05 Sep 2005 22:51:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17293 for ; Mon, 5 Sep 2005 22:51:14 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECTbC-0006R6-4O for ltru@ietf.org; Mon, 05 Sep 2005 22:54:16 -0400 Received: from h-64-105-137-222.snvacaid.dynamic.covad.net ([64.105.137.222] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECTY9-0003II-00 for ltru@ietf.org; Mon, 05 Sep 2005 22:51:05 -0400 Message-ID: <005201c5b28e$209baaa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0CA91352@irvmbxw01.quest.com> Date: Mon, 5 Sep 2005 19:53:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Ltru] Re: [psg.com #1110] IETF/LC define the LSR (gen-art 4) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - writing as a technical contributor... > From: "Addison Phillips" > To: "Addison Phillips" ; "LTRU Working Group" > Cc: "Elwyn Davies" > Sent: Wednesday, August 31, 2005 4:12 PM > Subject: RE: [Ltru] define the LSR (gen-art #4) > > Here is an initial proposed test for this section. > > -- >
> > The Language Subtag Reviewer is appointed by the IESG to moderate > the ietf-languages mailing list, respond to requests for registration, > and perform the other registry maintenance duties described in > . Only the Language Subtag Reviewer > is permitted to request IANA to change, update or add records to > the Language Subtag Registry. > > The performance or decisions of the Language Subtag Reviewer MAY > be appealed to the IESG under the same rules as other IETF decisions > (see ). The IESG can reverse or overturn > the decision of the Language Subtag Reviewer, provide guidance, or > take other appropriate actions. > >
So far so good, but I suggest that this would be an appropriate place to add words to directly address issue "[psg.com #1108] IETF/LC Recall of the LSR (gen-art 2)". I'll make a proposal in that thread. > -- > > There are many references to the LSR elsewhere in the document. > Should I try to collect these items up? I don't think that would be helpful. Pointers from all those to this new section would not be particularly helpful. I think the thrust of the comment was that there should be one place that summarizes the duties of the LTR. > It would mark a substantial change in the text, since many of > these items are part of the textual flow. For now I think this isn't > necessary; that I only need add references to the new Section 3.2 > (above) in each referencing section. ... I don't think that would be particularly helpful. What is being asked for is a summary. You've proposed one that is in my opinion adequate. Whether that summary is sufficiently detailed to satisfy the comment is a question for Elwyn. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 22:57:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECTei-00040b-5O; Mon, 05 Sep 2005 22:57:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECTeh-0003yP-84 for ltru@megatron.ietf.org; Mon, 05 Sep 2005 22:57:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17488 for ; Mon, 5 Sep 2005 22:57:48 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECTha-0006Zy-Iw for ltru@ietf.org; Mon, 05 Sep 2005 23:00:50 -0400 Received: from h-64-105-137-222.snvacaid.dynamic.covad.net ([64.105.137.222] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECTee-0004T8-00 for ltru@ietf.org; Mon, 05 Sep 2005 22:57:48 -0400 Message-ID: <006601c5b28f$12c51320$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0CA912C3@irvmbxw01.quest.com> <20050831211150.GN14448@NYCMJCOWA2> Date: Mon, 5 Sep 2005 20:00:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Re: [psg.com #1108] IETF/LC Recall of the LSR (gen-art 2) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John.Cowan" > To: "Addison Phillips" > Cc: "Elwyn Davies" ; "LTRU Working Group" > Sent: Wednesday, August 31, 2005 2:11 PM > Subject: Re: [Ltru] Recall of the LSR (gen-art #2) ... > The above strategy seems right to me. The IESG giveth and the IESG taketh > away, and the appeal is unto them. ... So, to the text already proposed for issue "[psg.com #1110] IETF/LC define the LSR (gen-art 4)", where the propoasal currently says "The Language Subtag Reviewer is appointed by the IESG" in order to address this comment, I suggest ammending that text to read something like: "The Language Subtag Reviewer is appointed by the IESG for an indefinite term, subject to removal or replacement at the IESG's discretion," Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 23:12:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECTsp-0005pR-VB; Mon, 05 Sep 2005 23:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECTso-0005pL-Un for ltru@megatron.ietf.org; Mon, 05 Sep 2005 23:12:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17847 for ; Mon, 5 Sep 2005 23:12:23 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECTvh-0006qD-NF for ltru@ietf.org; Mon, 05 Sep 2005 23:15:25 -0400 Received: from h-64-105-137-222.snvacaid.dynamic.covad.net ([64.105.137.222] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECTsm-0007Et-00 for ltru@ietf.org; Mon, 05 Sep 2005 23:12:25 -0400 Message-ID: <007c01c5b291$1ce997c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0CA912BE@irvmbxw01.quest.com> Date: Mon, 5 Sep 2005 20:14:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art 1) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Addison Phillips" > To: "LTRU Working Group" > Cc: "Elwyn Davies" > Sent: Wednesday, August 31, 2005 1:53 PM > Subject: [Ltru] Transition rules (gen-art #1) ... > Proposed resolution: looks good to me, with minor comments inline below... > To clear the interregnum problem, I propose inserting the following > text in Section 3.7 (insertion marked with >>> and <<<): > > -- > Registrations that are in process under the rules defined in > when this document is adopted > MAY be completed under the former rules, at the discretion > of the Language Tag Reviewer >>> (as described in target="RFC3066">). Until the IESG officially appoints > a Language Subtag Reviewer, the existing Language Tag Reviewer > will serve as the Language Subtag Reviewer. <<< will -> SHALL > -- > > To address the timing problem I propose inserting the following text in Section 3.7 as shown: > > -- > Upon adoption of this document an initial version of the > Language Subtag Registry containing the various subtags initially > valid in a language tag is necessary. This collection of subtags, > along with a description of the process used to create it, is > described by . >>> IANA > will publish the new registry as described in that document, at will -> SHALL replace "as described in" with "content provided by" to remove ambiguity (The IANA considerations section already says this, so I'm not sure this is really needed.) > which point the maintenance rules and registration processes > described in this document will be available for new registrations > or updates. <<< > -- ... Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 23:37:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUH4-0000a7-0y; Mon, 05 Sep 2005 23:37:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUH1-0000Zl-5q for ltru@megatron.ietf.org; Mon, 05 Sep 2005 23:37:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19054 for ; Mon, 5 Sep 2005 23:37:24 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECUJt-0007LN-JT for ltru@ietf.org; Mon, 05 Sep 2005 23:40:26 -0400 Received: from h-68-165-2-21.snvacaid.dynamic.covad.net ([68.165.2.21] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECUGx-0002Bd-00 for ltru@ietf.org; Mon, 05 Sep 2005 23:37:24 -0400 Message-ID: <000001c5b294$95535ea0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0CA912D6@irvmbxw01.quest.com> Date: Mon, 5 Sep 2005 20:32:19 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Ltru] Re:[psg.com #1109] IETF/LC case canonicalization in registry (gen-art 3) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor ... Agree with the substance, minor suggestions on the words used... > From: "Addison Phillips" > To: "LTRU Working Group" > Cc: "Elwyn Davies" > Sent: Wednesday, August 31, 2005 2:04 PM > Subject: [Ltru] case canonicalization in registry (gen-art #3) > > > > Irritant: > > > Early in the document it is specifically set out that language tags > > > are case insensitive and should be normally represented in lower case. > > [Addison Phillips] > > > > This is NOT correct. It actually says: > > > > -- > > However, in the tags defined by this document, the uppercase US-ASCII > > letters in the range 'A' through 'Z' are considered equivalent and > > mapped directly to their US-ASCII lowercase equivalents in the range > > 'a' through 'z'. Thus the tag "mn-Cyrl-MN" is not distinct from > > "MN-cYRL-mn" or "mN- cYrL-Mn" (or any other combination) and each of > > these variations conveys the same meaning: Mongolian written in the > > Cyrillic script as used in Mongolia. > > -- > > > > The document goes to great lengths to say that case distinctions must > > not be considered when processing language tags. However, the > > canonical form follows the ISO standards: this practice has long > > standing in the community at large and is enshrined in Section 4.4 > > ("Canonicalization of Language Tags") thusly: > > > > -- > > 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. Note that this > > corresponds to the following casing rules: uppercase all non-initial > > two-letter subtags; titlecase all non-initial four-letter subtags; lowercase everything else. > > -- > > > > > However, because the corresponding ISO documents use title case for > > > script codes and upper case for region codes, this representation > > > has been used in the normative text (ss 2.2.3 and 2.2.4) and > > > registrations of these codes MUST use this representation (s3.2). > > > This struck me as unecessary bureaucracy for registrants. It would > > > seem to me enough to RECOMMEND that the registry conform to the case > > > patterns and otherwise allow users and registrants whatever case they choose. > > [Addison Phillips] > > > > This bureaucracy only applies to independently registered values > > (variants), in practice, and isn't binding on those. The underlying > > ISO standards, when mirrored, won't be an issue, since their > > assignments will already come in the canonical format. > > Proposed solution to lack of clarity about case: > > Insert into Section 2.1 the following additional paragraph following the one about case: > > -- > Although case distinctions do not carry meaning in language tags, > consistent formatting and presentation of the tags will aid users. > The format of the tags and subtags in the registry SHOULD be considered > the recommended format. Suggest: The format for tags and subtags used in the registry is RECOMMENDED. > This format corresponds to uppercasing all non-initial two-letter subtags > and titlecasing all non-initial four-letter subtags. Suggest: In this format, all non-initial two-letter subtags are uppercase, all non-initial four-letter subtags are titlecase, and all others are lowercase. (Did I get it right? Since the new text (below) requires the LSR to adjust Subtag fields according to this rule, it should be exhaustive, otherwise an inappropriate upper- or titlecase could get through.) > -- > > Proposed solution to the bureaucracy issue (for registrants): > > Change this text: > > -- > Values in the 'Subtag' field MUST be lowercase except as > provided for in . > -- > > To read thusly: > > -- > Before forwarding a new registration to IANA, the Language > Subtag Review MUST ensure that values in the 'Subtag' field > match case according to the description in . > -- ... Suggest: Before forwarding registrations to IANA, the Language Subtag Review MUST ensure that 'Subtag' field values are in the format described in . (When I read "match case" I had to puzzle a bit before I could figure out what was intended.) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 23:37:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUHR-0000dt-53; Mon, 05 Sep 2005 23:37:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUHP-0000dN-P0 for ltru@megatron.ietf.org; Mon, 05 Sep 2005 23:37:52 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19088 for ; Mon, 5 Sep 2005 23:37:48 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ECUGI-0002RA-78 for ltru@lists.ietf.org; Tue, 06 Sep 2005 05:36:42 +0200 Received: from c-180-160-25.hh.dial.de.ignite.net ([62.180.160.25]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Sep 2005 05:36:42 +0200 Received: from nobody by c-180-160-25.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Sep 2005 05:36:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 06 Sep 2005 05:35:01 +0200 Organization: Lines: 33 Message-ID: <431D0E65.7294@xyzzy.claranet.de> References: <20050901204312.DTQ7546.mta2.adelphia.net@megatron.ietf.org> <000801c5af4b$c36c7480$030aa8c0@DEWELL> <016101c5b27c$5ff66800$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-25.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > So far, I haven't seen anything like a consensus on what to > do with this item. Sorry, I forgot to send an explicit ACK to Addison's correction of what I said (zh-cmn is not yet redundant, maybe it will be in 3066ter). But Doug's position (zh-guoyu deprecated, preferred zh-cmn) is AFAIK what "we" have done in similar cases, reflect all changes in all sources (incl. IANA) up to "date B": 2005-07-15 | It is understood that the "guoyu" dialect tag will be | deprecated. This is a formal application for use of the | replacement tag "cmn". This is intended to describe the same | Mandarin Chinese dialect that was previously described with | the "-guoyu" extension. Formally the old zh-guoyu entry should be updated to reflect this (like i-klingon), at least in the single file registry... ...but unfortunately they didn't. Stating how it's supposed to be in the initial 3066bis registry is the fastest way to fix this error. It's not controversional (ignoring nonsense about any Sony vs. MS "stewardship" for these tags of course). Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 05 23:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUPe-0001tf-Nw; Mon, 05 Sep 2005 23:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUPc-0001tW-ME for ltru@megatron.ietf.org; Mon, 05 Sep 2005 23:46:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19592 for ; Mon, 5 Sep 2005 23:46:13 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECUSQ-0007YJ-WB for ltru@ietf.org; Mon, 05 Sep 2005 23:49:16 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Sep 2005 20:45:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu Date: Mon, 5 Sep 2005 20:45:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB43D3A@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu Thread-Index: AcWylKAy3HyDZtuCSQ+dyvxfU9DzTgAANK7w From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 06 Sep 2005 03:45:58.0068 (UTC) FILETIME=[7DD17F40:01C5B295] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org +1 Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Frank Ellermann > Sent: 2005?9?5? 20:35 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu >=20 > Randy Presuhn wrote: >=20 > > So far, I haven't seen anything like a consensus on what to > > do with this item. >=20 > Sorry, I forgot to send an explicit ACK to Addison's correction > of what I said (zh-cmn is not yet redundant, maybe it will be > in 3066ter). >=20 > But Doug's position (zh-guoyu deprecated, preferred zh-cmn) is > AFAIK what "we" have done in similar cases, reflect all changes > in all sources (incl. IANA) up to "date B": >=20 > 2005-07-15 >=20 > | It is understood that the "guoyu" dialect tag will be > | deprecated. This is a formal application for use of the > | replacement tag "cmn". This is intended to describe the same > | Mandarin Chinese dialect that was previously described with > | the "-guoyu" extension. >=20 > Formally the old zh-guoyu entry should be updated to reflect > this (like i-klingon), at least in the single file registry... >=20 > >=20 > ...but unfortunately they didn't. Stating how it's supposed > to be in the initial 3066bis registry is the fastest way to > fix this error. It's not controversional (ignoring nonsense > about any Sony vs. MS "stewardship" for these tags of course). >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 00:05:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUhu-000486-Mb; Tue, 06 Sep 2005 00:05:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUht-00046o-06 for ltru@megatron.ietf.org; Tue, 06 Sep 2005 00:05:13 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20172 for ; Tue, 6 Sep 2005 00:05:09 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ECUhd-0006Kr-VZ for ltru@lists.ietf.org; Tue, 06 Sep 2005 06:04:58 +0200 Received: from c-180-160-25.hh.dial.de.ignite.net ([62.180.160.25]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Sep 2005 06:04:57 +0200 Received: from nobody by c-180-160-25.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Sep 2005 06:04:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 06 Sep 2005 05:56:34 +0200 Organization: Lines: 22 Message-ID: <431D1372.4435@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CA912BE@irvmbxw01.quest.com> <007c01c5b291$1ce997c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-25.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #1107] IETF/LC Transition rules (gen-art 1) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> the existing Language Tag Reviewer will serve as the >> Language Subtag Reviewer. > will -> SHALL Maybe he's not interested, we can only ask him, not force him. How about "the existing LTR serves as the LSR" ? >> IANA will publish the new registry as described in that >> document, at > will -> SHALL Okay, here it's clearly their duty, but I prefer "publishes" if "will publish" isn't good enough. That could be also a bad case of DEnglish on my side - thou shalt not abuse 2119- keywords to impose a particular method. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 00:16:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUsl-0005L2-6I; Tue, 06 Sep 2005 00:16:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUsj-0005Ku-3B for ltru@megatron.ietf.org; Tue, 06 Sep 2005 00:16:25 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20456 for ; Tue, 6 Sep 2005 00:16:21 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050906041553.BILC27017.mta11.adelphia.net@DEWELL> for ; Tue, 6 Sep 2005 00:15:53 -0400 Message-ID: <005701c5b299$7adef660$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050906034719.HHP23403.edge4.adelphia.net@megatron.ietf.org> Date: Mon, 5 Sep 2005 21:14:30 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > So far, I haven't seen anything like a consensus on what to do with > this item. If there is no consensus to change, then the decision about > what (if anything) to do to zh-guoyu will be left for > ietf-languages@iana.org to decide after the new registry goes into > effect, whenever that might be. > > For now, I'll leave this open, but if no rough consensus emerges, it > will be marked "rejected". I don't understand whether this means I am supposed to leave draft-initial-04 alone, with zh-guoyu deprecated in favor of zh-cmn, or create a new draft-05, with this change from July undone. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 06:42:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECau5-0006D8-6p; Tue, 06 Sep 2005 06:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECau2-0006Cd-GG for ltru@megatron.ietf.org; Tue, 06 Sep 2005 06:42:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19162 for ; Tue, 6 Sep 2005 06:42:04 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECawu-0000nT-Og for ltru@ietf.org; Tue, 06 Sep 2005 06:45:10 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1ECatp-0003zE-Ui; Tue, 06 Sep 2005 03:41:58 -0700 Message-Id: <6.2.3.4.2.20050906114032.04987180@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 06 Sep 2005 12:13:13 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1108] IETF/LC Recall of the LSR (gen-art 2) In-Reply-To: <006601c5b28f$12c51320$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0CA912C3@irvmbxw01.quest.com> <20050831211150.GN14448@NYCMJCOWA2> <006601c5b28f$12c51320$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The credibility of this Draft is based upon the credibility of this reviewer, of the associated mailing list and the ability for anyone to register langtags. This is not insured by the Draft. 1. there should not be a single reviewer, but a multi-competence committee with voted suggestions to IANA. How someone can have enough typographer, publisher, developer, networker expertise to be accepted as an authoritative reference by his peers, world-wide? For example, the current single person in charge made clear enough that he did not and did not wanted to know about software development. This only underlines the misunderstanding of the Draft, being undefined language oriented instead of real life multilingual network oriented. ISO/TC37 vs IETF. The reviewers should be elected (or confirmed) by the members of the mailing list and the IANA. To make sure we do not face a situation like today, the reviewers should be designated for one year and confirmed. This would give them more authority and decrease the risks of conflicts. 2. the same remark applied on modes. 3. as long as the list will stay an ietf-languages@alvestrand.no it will continue underlining an abnormal situation. If it becomes a languages@iana.org list documented in the welcome page of http://languages.inia.org the situation will change. But I suppose that many of you have more experience than me in writing by-laws, administering organisations, dealing with opposing government officials ... jfc At 05:00 06/09/2005, Randy Presuhn wrote: >Hi - > >As a technical contributor... > > > From: "John.Cowan" > > To: "Addison Phillips" > > Cc: "Elwyn Davies" ; "LTRU Working Group" > > > Sent: Wednesday, August 31, 2005 2:11 PM > > Subject: Re: [Ltru] Recall of the LSR (gen-art #2) >... > > The above strategy seems right to me. The IESG giveth and the IESG taketh > > away, and the appeal is unto them. >... > >So, to the text already proposed for issue "[psg.com #1110] IETF/LC define >the LSR (gen-art 4)", where the propoasal currently says > >"The Language Subtag Reviewer is appointed by the IESG" > >in order to address this comment, I suggest ammending that text to read >something like: > >"The Language Subtag Reviewer is appointed by the IESG for >an indefinite term, subject to removal or replacement at the IESG's >discretion," > >Randy > > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 06:44:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECavs-0006WX-Rx; Tue, 06 Sep 2005 06:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECavr-0006WG-MI; Tue, 06 Sep 2005 06:44:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19274; Tue, 6 Sep 2005 06:44:01 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECayo-0000ry-Bq; Tue, 06 Sep 2005 06:47:07 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ECavn-0001Zy-8z; Tue, 06 Sep 2005 06:43:59 -0400 Date: Tue, 06 Sep 2005 06:43:59 -0400 From: John C Klensin To: iesg@ietf.org Message-ID: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, ietf@ietf.org Subject: [Ltru] Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Comments on draft-ietf-ltru-registry and draft-ietf-ltru-initial and, secondarily, on draft-ietf-ltru-matching... Summary: These documents represent good work, and the community should be grateful to have them. However, I believe they, and the still-incomplete "matching" one, have conclusively demonstrated that the expectations of the WG Charter were unreasonable and inappropriate. When the documents are examined as an IETF product, rather than on the assumption that the charter represents perfect foresight, it is clear that the documents should not be handled as BCPs but as Proposed Standards, with an applicability statement and/or profile to follow. The reasoning behind this conclusion is explained below. --------------- These specifications are a nice piece of work and the model specified is quite elegant. It appears to me to meet the goals of permitting a high degree of specificity when needed while providing a plausible mechanism for preserving stability across changes in underlying documents. Having tried, mostly unsuccessfully, to track the WG's work, I believe that the IETF community owes those who have actively participated and contributed great thanks. However, the documents that they have produced should not be approved as one or more BCPs, nor, in their present form, as replacements for RFC 3066 / BCP 47. An alternate suggestion that does not require significant work beyond that specified in the charter is outlined below. (1) BCPs or Proposed Standards The WG Charter calls for the production of BCPs. Like all provisions of WG Charters, the requirements that the community specifies and agrees to must be treated as tentative: if the best work the WG can produce, consistent with the general goals of the charter, are not acceptable as the charter specifies, the community must have the ability to change categories or, in the worst cases, refer the WG products back to the WG for further work under a new set of charter specifications. Fortunately, I do not believe that worst case applies here: the documents that were last-called appear to be quite appropriate; it is only how they are classified and applied that appears to be at issue. RFC 3066 (and 1766) were arguably just a mechanism for tying a few existing (and tested) specs together, using a review and registration procedure. As such, they were at least marginally inside the category and usage for which BCPs are appropriate. LTRU-registration, by contrast, is designed to operate without registration of full tags: the role of the reviewer, and of IANA, is to register subtag entitites from which tags can be constructed. It also provides for a highly distributed registry, with different maintainers for different subtags or groups of subtags. Neither the IETF community, nor the IANA, has any experience with doing things that way. Given the importance of this registry, and the dependencies upon the preceeding 3066 registry, that combination of conditions -- a more complex architecture, registration of components rather than full tags, and lack of community experience with the approach -- adds up to an extremely strong argument for treating these documents as Proposed Standards, and then letting them advance along the standards track as experience accumulates, rather than approving them as a single-stage BCP. (2) Matching rules and the replacement of RFC3066/ BCP47 RFC 3066 essentially specifies its own set of matching rules: for matching purposes, tags are treated as atomic and two tags match or they do not. Both the "registry" document and some of the discussion leading up to it pointed out the flaws in that approach, particularly tags that are equivalent but do not match because extra information is supplied. However, the material in Sections 4.1 and 4.2 of the LTRU specification does not provide an adequate replaceent for Section 2.3 of RFC 3066. The latter is considerably more normative and specific (even if naive in retrospect). By contrast, the material in the LTRU registry document gives much more general guidance, but not the level of specific instructions needed to promote interoperability. Hence, a _replacement_ for RFC 3066 as BCP 47 requires not only the registry specification but a set of matching rules (perhaps those to be specified in draft-ietf-ltru-matching, but see below). (3) Interoperability issues Until and unless a protocol or specification is tested in practice, interoperability is no better than an hypothesis. That is one reason, perhaps the major reason, why we have a multiple-stage standards process. It is also much of the reason why the IETF has traditionally tried to avoid complex protocols with many options. As Marshall Rose elegantly wrote in RFC 1425, Experience with many protocols has shown that: protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity. Viewed as a protocol the LTRU model is option-laden. Much as I dislike going down the path of profiles, it appears to me that, if we are going to keep interoperability paramount, the general guidance about choices of tags in Section 4 of the registry document must be supplemented by application-specific profiles, developed from use cases, that include both tagging and matching rules if we are going to support interoperability and avoid many of the operational problems with 3066 that stimulated the LTRU work. (4) What should be done. I have become convinced that, rather than approving these documents as a BCP, we should... (i) put the registry document on the standards track, as a proposed standard. While this step, and the next one, should not be done without agreement from the WG, they do not require any additional work on the WG's part. While changes from would-be standards track to informational or experimental are more common, such changes of designation after Last Call are clearly within the IESG's scope. (ii) either put the initialization draft on the standards track with it or publish it as informational and use the downref procedure, (iii) define a profiling mechanism for what should actually be done to effectively and interoperably use this registry. This step, and the one that follows, is an additional task for the WG. But the WG's work is, IMO, not complete until it is done: mechanisms for how to put something into a registry are always much easier than determinations of how entities, once registered, are to be used in an effective and interoperable way. For the IETF, the latter has always been key... to the point that it is implicit in every WG charter. (iv) acknowledge that only a profile, and not the registry doc, can replace 3066, and that such a profile must combine rules for registry use and specific matching rules. Such a profile is inherently dependent on the matching rules and only a document (or set of documents) that specifies both registration and matching can appropriately become a new version of BCP 47. (v) put the matching doc on the standards track when it is considered ready, with only the profiles (if that) showing up as BCPs. As with (i) and (ii), this does not intrinsically require more work from the WG. -------------------------- Some nit-picking (easily fixed): The documents make reference to the "record-jar" format. I believe the text in ltru-registry is sufficient to define the portion of that spec that is relevant, justifying the editor's choice to list [record-jar] an an information reference. If that is correct, the fact that the format specification is self-contained in this spec should be made _very_ explicit in both the "registry" and the "initial" document. Indeed, the "record-jar" reference might best be eliminated from the latter document as a distraction. If it were not, I believe that we should obtain permission from Eric Raymond and if necessary Addison-Wesley, to reproduce the relevant material in an RFC: a dependency on a moderately expensive book that could go out of print as part of the definition for an IANA registry should be acceptable to neither the IETF nor to the IANA. And, incidentally, the reference given is incomplete. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 16:19:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjvB-0000PN-Sj; Tue, 06 Sep 2005 16:19:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjv9-0000P1-Q5; Tue, 06 Sep 2005 16:19:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23988; Tue, 6 Sep 2005 16:19:54 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECjy9-0000w2-T8; Tue, 06 Sep 2005 16:23:04 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ECjv1-0004Kv-Qv; Tue, 06 Sep 2005 16:19:47 -0400 Date: Tue, 06 Sep 2005 16:19:47 -0400 From: John C Klensin To: Sam Hartman Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On Tuesday, 06 September, 2005 15:14 -0400 Sam Hartman wrote: > John, what does it mean to put a registry document on the > standards track? In particular, how do you get multiple > implementations of a registry? One is reminded of the story of Eeyore's birthday party. Registering things --putting them into a registry so that they can be retrieved and examined using whatever key was used to put them there-- is always easy and, as you point out, untestable. But it is also almost never the point: the point is whether the right information is being placed in the registry to support the relevant applications and whether those applications can use the information in a way that promotes interoperability. With regard to that driving issue, it is certainly possible to have multiple implementations of matching rules. It is certainly possible to examine, in practice, different uses of the tagging system to determine whether its mechanisms are sufficient and, if sufficient, whether they meet some "minimum necessary" criteria or represent serious overkill and/or redundancy. With apologies to Spencer, let me turn your question around and ask how something can be identified as a "Best Common Practice" when * when it has not been practiced at all, * when there is no evidence that it is "best" (even if one agrees that no better options are on the table or even that none are likely to be searched out and found unless, someone, this approach is shown to fail as RFC 3066 was shown to fail), and * it certainly isn't "common" in the "widely disseminated and used" sense of that term. Things would be better if we had "PP" (proposed practice), "AGI" (apparently good idea), or "WTOSITD" (well thought-out shot in the dark), or "NRtBTWNW" (no reason to believe this will not work) categories. But we don't. And the model and mechanisms associated with Proposed Standard, when applied to the use cases rather than the registry itself, much more nearly meet application needs and community expectations than identifying a document like that as a BCP. john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 16:59:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkXE-0002Ei-QY; Tue, 06 Sep 2005 16:59:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkHA-0006Zo-W6; Tue, 06 Sep 2005 16:42:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27110; Tue, 6 Sep 2005 16:42:39 -0400 (EDT) Received: from [207.152.136.138] (helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECkKA-0001vU-Ew; Tue, 06 Sep 2005 16:45:49 -0400 Received: from [162.84.74.222] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12385723; Tue, 06 Sep 2005 16:42:23 -0400 Message-Id: <6.2.1.2.0.20050906164115.02f89ea8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 06 Sep 2005 16:42:19 -0400 To: Sam Hartman From: "Joel M. Halpern" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Tue, 06 Sep 2005 16:59:15 -0400 Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This document defines structure and meaning for labels, as well as the procedure for registering parts of that structure. As such, the structure is "bits on the wire" and is subject to interoperability concerns. Yours, Joel M. Halpern At 03:14 PM 9/6/2005, Sam Hartman wrote: >John, what does it mean to put a registry document on the standards >track? In particular, how do you get multiple implementations of a >registry? > >--Sam > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 16:59:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkXO-0002Hl-1b; Tue, 06 Sep 2005 16:59:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECitc-0000k5-FN; Tue, 06 Sep 2005 15:14:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15096; Tue, 6 Sep 2005 15:14:14 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECiwc-00065I-PL; Tue, 06 Sep 2005 15:17:23 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 35FF2E0049; Tue, 6 Sep 2005 15:14:09 -0400 (EDT) To: John C Klensin References: From: Sam Hartman Date: Tue, 06 Sep 2005 15:14:09 -0400 In-Reply-To: (John C. Klensin's message of "Tue, 06 Sep 2005 06:43:59 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Tue, 06 Sep 2005 16:59:25 -0400 Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John, what does it mean to put a registry document on the standards track? In particular, how do you get multiple implementations of a registry? --Sam _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 19:21:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmkP-0002B5-3e; Tue, 06 Sep 2005 19:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmkO-0002Aj-91 for ltru@megatron.ietf.org; Tue, 06 Sep 2005 19:21:00 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15089 for ; Tue, 6 Sep 2005 19:20:56 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1ECmk7-0001B0-7S for ltru@lists.ietf.org; Wed, 07 Sep 2005 01:20:43 +0200 Received: from c-180-160-19.hh.dial.de.ignite.net ([62.180.160.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Sep 2005 01:20:43 +0200 Received: from nobody by c-180-160-19.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Sep 2005 01:20:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 07 Sep 2005 01:10:49 +0200 Organization: Lines: 57 Message-ID: <431E21F9.A87@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-19.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin wrote: > (ii) either put the initialization draft on the standards > track with it or publish it as informational and use the > downref procedure, That's a formal point: The initial registry is too long to put it in the IANA considerations of the main document, and it will be soon obsolete. Therefore it had to be a separate document. Because the WG wanted a proper last call also for this part it was published as I-D. Same idea as for e.g. RfC 4021 - a part of the header field registry defined in RfC 3864. Apparently RfC 4021 is "standards track", but "informational" for the initial registry is also possible. I don't get the need for "downref" in this case, the reference to the initial registry in the main document _is_ only informational. Do "informational" RfCs created by a WG get a "last call" ? I'm not sure what the last paragraph in 2026 4.2.3 means. Something's odd with the procedures here, I'd be surprised if RfC 4021 would be promoted on stadards track, it's only a (now already obsolete) snapshot of a part of a registry. > The documents make reference to the "record-jar" format. I > believe the text in ltru-registry is sufficient to define > the portion of that spec that is relevant Yes, the defined format is "inspired by" record-jar, it does not claim to be the real thing. E.g. it doesn't have arbitrary comment lines, OTOH it defines a way to encode Unicode by the known &#x????; sequences for u+????. > a dependency on a moderately expensive book that could go out > of print as part of the definition for an IANA registry No, it's also only informational for those interested in "the real thing" instead of what's used for the registry and future extension registries. > incidentally, the reference given is incomplete. Yes, the draft author knows already how to add the proper ISBN with xml2rfc, "easily fixed" as you said. Not referencing the original idea at all would be wrong. But the reference in the initial registry draft is in fact unnecessary. Think of it as some kind of "informational credits" in the main document. We also considered a pure 2822-like format with CRLF CRLF as a record separator, but the WG preferred CRLF "%%" CRLF, that's all - no copyright traps and no necessity to buy the book (e.g. I don't have it). Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 20:25:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnku-0002pl-Ne; Tue, 06 Sep 2005 20:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnkt-0002pX-I6 for ltru@megatron.ietf.org; Tue, 06 Sep 2005 20:25:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17528 for ; Tue, 6 Sep 2005 20:25:34 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECnnw-0002XT-RH for ltru@ietf.org; Tue, 06 Sep 2005 20:28:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 17:25:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1108] IETF/LC Recall of the LSR (gen-art 2) Date: Tue, 6 Sep 2005 17:25:19 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB4418F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1108] IETF/LC Recall of the LSR (gen-art 2) Thread-Index: AcWyjvRg6vaLkrdiSPaxdAvg4WmflAAs4nmw From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 07 Sep 2005 00:25:19.0426 (UTC) FILETIME=[A0A44220:01C5B342] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Okay. Here's the revised text:
The Language Subtag Reviewer is appointed by the IESG for an = indefinite term, subject to removal or replacement at the IESG's = discretion. The Language Subtag Reviewer moderates the ietf-languages = mailing list, responds to requests for registration, and performs the = other registry maintenance duties described in . Only the Language Subtag Reviewer is = permitted to request IANA to change, update or add records to the = Language Subtag Registry. The performance or decisions of the Language Subtag Reviewer MAY be = appealed to the IESG under the same rules as other IETF decisions (see = ). The IESG can reverse or overturn the = decision of the Language Subtag Reviewer, provide guidance, or take = other appropriate actions.
Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: 2005?9?5? 20:00 > To: LTRU Working Group > Subject: [Ltru] Re: [psg.com #1108] IETF/LC Recall of the LSR (gen-art = 2) >=20 > Hi - >=20 > As a technical contributor... >=20 > > From: "John.Cowan" > > To: "Addison Phillips" > > Cc: "Elwyn Davies" ; "LTRU Working Group" > > > Sent: Wednesday, August 31, 2005 2:11 PM > > Subject: Re: [Ltru] Recall of the LSR (gen-art #2) > ... > > The above strategy seems right to me. The IESG giveth and the IESG > taketh > > away, and the appeal is unto them. > ... >=20 > So, to the text already proposed for issue "[psg.com #1110] IETF/LC = define > the LSR (gen-art 4)", where the propoasal currently says >=20 > "The Language Subtag Reviewer is appointed by the IESG" >=20 > in order to address this comment, I suggest ammending that text to = read > something like: >=20 > "The Language Subtag Reviewer is appointed by the IESG for > an indefinite term, subject to removal or replacement at the IESG's > discretion," >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 20:33:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnsg-0004CZ-W9; Tue, 06 Sep 2005 20:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnsg-0004CU-2C for ltru@megatron.ietf.org; Tue, 06 Sep 2005 20:33:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17870 for ; Tue, 6 Sep 2005 20:33:36 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECnvk-0002j4-I6 for ltru@ietf.org; Tue, 06 Sep 2005 20:36:48 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 17:33:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art 1) Date: Tue, 6 Sep 2005 17:33:27 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB4419F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art 1) Thread-Index: AcWykWvd5oJpnqeRRLCEZ7/OYaWyHAAsjpaQ From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 07 Sep 2005 00:33:28.0114 (UTC) FILETIME=[C3EC2120:01C5B343] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Your suggestions required some extra wordsmithing. Here is what I came = up with: -- Upon adoption of this document an initial version of the Language = Subtag Registry containing the various subtags initially valid in a = language tag is necessary. This collection of subtags, along with a = description of the process used to create it, is described by . IANA SHALL publish the initial = version of the registry described by this document from the content of = . Once published by IANA, the = maintenance procedures, rules and registration processes described in = this document will be available for new registrations or updates. -- Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: 2005?9?5? 20:14 > To: LTRU Working Group > Subject: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art = 1) >=20 > Hi - >=20 > As a technical contributor... >=20 > > From: "Addison Phillips" > > To: "LTRU Working Group" > > Cc: "Elwyn Davies" > > Sent: Wednesday, August 31, 2005 1:53 PM > > Subject: [Ltru] Transition rules (gen-art #1) > ... > > Proposed resolution: >=20 > looks good to me, with minor comments inline below... >=20 > > To clear the interregnum problem, I propose inserting the following > > text in Section 3.7 (insertion marked with >>> and <<<): > > > > -- > > Registrations that are in process under the rules defined in > > when this document is adopted > > MAY be completed under the former rules, at the discretion > > of the Language Tag Reviewer >>> (as described in > target=3D"RFC3066">). Until the IESG officially appoints > > a Language Subtag Reviewer, the existing Language Tag Reviewer > > will serve as the Language Subtag Reviewer. <<< >=20 > will -> SHALL >=20 > > -- > > > > To address the timing problem I propose inserting the following text = in > Section 3.7 as shown: > > > > -- > > Upon adoption of this document an initial version of the > > Language Subtag Registry containing the various subtags initially > > valid in a language tag is necessary. This collection of subtags, > > along with a description of the process used to create it, is > > described by . >>> IANA > > will publish the new registry as described in that document, at >=20 > will -> SHALL > replace "as described in" with "content provided by" to remove = ambiguity > (The IANA considerations section already says this, so I'm not sure = this > is really needed.) >=20 > > which point the maintenance rules and registration processes > > described in this document will be available for new registrations > > or updates. <<< > > -- > ... >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 20:40:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnyv-0006Z4-Am; Tue, 06 Sep 2005 20:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnyt-0006Yu-NO for ltru@megatron.ietf.org; Tue, 06 Sep 2005 20:40:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18079 for ; Tue, 6 Sep 2005 20:40:02 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECo1y-0002qB-0u for ltru@ietf.org; Tue, 06 Sep 2005 20:43:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 17:39:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re:[psg.com #1109] IETF/LC case canonicalization in registry(gen-art 3) Date: Tue, 6 Sep 2005 17:39:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB441A7@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re:[psg.com #1109] IETF/LC case canonicalization in registry(gen-art 3) Thread-Index: AcWylHIPw6ZsEAjWTQiQB+xKDl9sVwAr34QA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 07 Sep 2005 00:39:51.0134 (UTC) FILETIME=[A83857E0:01C5B344] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > Suggest: The format for tags and subtags used in the registry is > RECOMMENDED. Okay. > Suggest: >=20 > In this format, all non-initial two-letter subtags are uppercase, > all non-initial four-letter subtags are titlecase, and all others > are lowercase. Okay. > (Did I get it right? Since the new text (below) requires the LSR to > adjust Subtag fields according to this rule, it should be exhaustive, > otherwise an inappropriate upper- or titlecase could get through.) Yes, you did. It is exhaustive. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: 2005?9?5? 20:32 > To: LTRU Working Group > Subject: [Ltru] Re:[psg.com #1109] IETF/LC case canonicalization in > registry(gen-art 3) >=20 > Hi - >=20 > As a technical contributor ... >=20 > Agree with the substance, minor suggestions on the words used... >=20 > > From: "Addison Phillips" > > To: "LTRU Working Group" > > Cc: "Elwyn Davies" > > Sent: Wednesday, August 31, 2005 2:04 PM > > Subject: [Ltru] case canonicalization in registry (gen-art #3) > > > > > > Irritant: > > > > Early in the document it is specifically set out that language = tags > > > > are case insensitive and should be normally represented in lower > case. > > > [Addison Phillips] > > > > > > This is NOT correct. It actually says: > > > > > > -- > > > However, in the tags defined by this document, the uppercase = US-ASCII > > > letters in the range 'A' through 'Z' are considered equivalent and > > > mapped directly to their US-ASCII lowercase equivalents in the = range > > > 'a' through 'z'. Thus the tag "mn-Cyrl-MN" is not distinct from > > > "MN-cYRL-mn" or "mN- cYrL-Mn" (or any other combination) and each = of > > > these variations conveys the same meaning: Mongolian written in = the > > > Cyrillic script as used in Mongolia. > > > -- > > > > > > The document goes to great lengths to say that case distinctions = must > > > not be considered when processing language tags. However, the > > > canonical form follows the ISO standards: this practice has long > > > standing in the community at large and is enshrined in Section 4.4 > > > ("Canonicalization of Language Tags") thusly: > > > > > > -- > > > 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. Note that this > > > corresponds to the following casing rules: uppercase all = non-initial > > > two-letter subtags; titlecase all non-initial four-letter subtags; > lowercase everything else. > > > -- > > > > > > > However, because the corresponding ISO documents use title case = for > > > > script codes and upper case for region codes, this = representation > > > > has been used in the normative text (ss 2.2.3 and 2.2.4) and > > > > registrations of these codes MUST use this representation = (s3.2). > > > > This struck me as unecessary bureaucracy for registrants. It = would > > > > seem to me enough to RECOMMEND that the registry conform to the = case > > > > patterns and otherwise allow users and registrants whatever case > they choose. > > > [Addison Phillips] > > > > > > This bureaucracy only applies to independently registered values > > > (variants), in practice, and isn't binding on those. The = underlying > > > ISO standards, when mirrored, won't be an issue, since their > > > assignments will already come in the canonical format. > > > > Proposed solution to lack of clarity about case: > > > > Insert into Section 2.1 the following additional paragraph following = the > one about case: > > > > -- > > Although case distinctions do not carry meaning in language tags, > > consistent formatting and presentation of the tags will aid users. > > The format of the tags and subtags in the registry SHOULD be = considered > > the recommended format. >=20 > Suggest: The format for tags and subtags used in the registry is > RECOMMENDED. >=20 > > This format corresponds to uppercasing all non-initial two-letter > subtags > > and titlecasing all non-initial four-letter subtags. >=20 > Suggest: >=20 > In this format, all non-initial two-letter subtags are uppercase, > all non-initial four-letter subtags are titlecase, and all others > are lowercase. > (Did I get it right? Since the new text (below) requires the LSR to > adjust Subtag fields according to this rule, it should be exhaustive, > otherwise an inappropriate upper- or titlecase could get through.) >=20 > > -- > > > > Proposed solution to the bureaucracy issue (for registrants): > > > > Change this text: > > > > -- > > Values in the 'Subtag' field MUST be lowercase except as > > provided for in . > > -- > > > > To read thusly: > > > > -- > > Before forwarding a new registration to IANA, the Language > > Subtag Review MUST ensure that values in the 'Subtag' field > > match case according to the description in target=3D"ianaformat">. > > -- > ... >=20 > Suggest: > Before forwarding registrations to IANA, the Language > Subtag Review MUST ensure that 'Subtag' field values > are in the format described in . >=20 > (When I read "match case" I had to puzzle a bit before I could > figure out what was intended.) >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 20:50:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECo9N-0008VR-Jb; Tue, 06 Sep 2005 20:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECo9M-0008VH-7g for ltru@megatron.ietf.org; Tue, 06 Sep 2005 20:50:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18303 for ; Tue, 6 Sep 2005 20:50:50 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-lon.bigfish.com ([213.206.137.197] helo=mail14-lon-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECoCQ-00032H-EY for ltru@ietf.org; Tue, 06 Sep 2005 20:54:03 -0400 Received: from mail14-lon.bigfish.com (localhost.localdomain [127.0.0.1]) by mail14-lon-R.bigfish.com (Postfix) with ESMTP id 7B4F44ADBEC; Wed, 7 Sep 2005 00:50:33 +0000 (UTC) X-BigFish: VP Received: by mail14-lon (MessageSwitch) id 1126054233384842_26399; Wed, 7 Sep 2005 00:50:33 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail14-lon.bigfish.com (Postfix) with ESMTP id 1266049BD58; Wed, 7 Sep 2005 00:50:33 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005090617591155:66084 ; Tue, 6 Sep 2005 17:59:11 -0700 To: "Addison Phillips" , ltru@ietf.org Subject: RE: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art 1) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Tue, 6 Sep 2005 17:47:24 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 09/06/2005 17:47:26, Serialize complete at 09/06/2005 17:47:26, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 09/06/2005 05:59:11 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 09/06/2005 05:59:12 PM, Serialize complete at 09/06/2005 05:59:12 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0169797528==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0169797528== Content-Type: multipart/alternative; boundary="=_alternative 00049F8888257075_=" This is a multipart message in MIME format. --=_alternative 00049F8888257075_= Content-Type: text/plain; charset="us-ascii" You wrote: >Upon adoption of this document an initial version of the Language Subtag Registry containing the various subtags initially valid in a language tag is necessary. Is this better? "Adoption of this document necessitates the creation of a Language Subtag Registry containing the various valid subtags in a language tag." (It seemed like "initial" and "initially" were redundant in the paragraph and the sentence. Seems like the most important point is the necessary existence of the subtag registry and the ongoing process to maintain it.) - Karen Broome "Addison Phillips" Sent by: ltru-bounces@ietf.org 09/06/2005 05:33 PM To: "Randy Presuhn" , "LTRU Working Group" cc: Subject: RE: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art 1) Your suggestions required some extra wordsmithing. Here is what I came up with: -- Upon adoption of this document an initial version of the Language Subtag Registry containing the various subtags initially valid in a language tag is necessary. This collection of subtags, along with a description of the process used to create it, is described by . IANA SHALL publish the initial version of the registry described by this document from the content of . Once published by IANA, the maintenance procedures, rules and registration processes described in this document will be available for new registrations or updates. -- Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group 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: 2005?9?5? 20:14 > To: LTRU Working Group > Subject: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art 1) > > Hi - > > As a technical contributor... > > > From: "Addison Phillips" > > To: "LTRU Working Group" > > Cc: "Elwyn Davies" > > Sent: Wednesday, August 31, 2005 1:53 PM > > Subject: [Ltru] Transition rules (gen-art #1) > ... > > Proposed resolution: > > looks good to me, with minor comments inline below... > > > To clear the interregnum problem, I propose inserting the following > > text in Section 3.7 (insertion marked with >>> and <<<): > > > > -- > > Registrations that are in process under the rules defined in > > when this document is adopted > > MAY be completed under the former rules, at the discretion > > of the Language Tag Reviewer >>> (as described in > target="RFC3066">). Until the IESG officially appoints > > a Language Subtag Reviewer, the existing Language Tag Reviewer > > will serve as the Language Subtag Reviewer. <<< > > will -> SHALL > > > -- > > > > To address the timing problem I propose inserting the following text in > Section 3.7 as shown: > > > > -- > > Upon adoption of this document an initial version of the > > Language Subtag Registry containing the various subtags initially > > valid in a language tag is necessary. This collection of subtags, > > along with a description of the process used to create it, is > > described by . >>> IANA > > will publish the new registry as described in that document, at > > will -> SHALL > replace "as described in" with "content provided by" to remove ambiguity > (The IANA considerations section already says this, so I'm not sure this > is really needed.) > > > which point the maintenance rules and registration processes > > described in this document will be available for new registrations > > or updates. <<< > > -- > ... > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 00049F8888257075_= Content-Type: text/html; charset="us-ascii"
You wrote:

>Upon adoption of this document an initial version of the Language Subtag Registry containing the various subtags initially valid in a language tag is necessary.

Is this better?

"Adoption of this document necessitates the creation of a Language Subtag Registry containing the various valid subtags in a language tag."

(It seemed like "initial" and "initially" were redundant in the paragraph and the sentence. Seems like the most important point is the necessary existence of the subtag registry and the ongoing process to maintain it.)


- Karen Broome




"Addison Phillips" <addison.phillips@quest.com>
Sent by: ltru-bounces@ietf.org

09/06/2005 05:33 PM

       
        To:        "Randy Presuhn" <randy_presuhn@mindspring.com>, "LTRU Working Group" <ltru@ietf.org>
        cc:        
        Subject:        RE: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art 1)



Your suggestions required some extra wordsmithing. Here is what I came up with:

--
<t>Upon adoption of this document an initial version of the Language Subtag Registry containing the various subtags initially valid in a language tag is necessary. This collection of subtags, along with a description of the process used to create it, is described by <xref target="initial-registry"></xref>. IANA SHALL publish the initial version of the registry described by this document from the content of <xref target="initial-registry"></xref>. Once published by IANA, the maintenance procedures, rules and registration processes described in this document will be available for new registrations or updates.</t>
--

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

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: 2005?9?5? 20:14
> To: LTRU Working Group
> Subject: [Ltru] Re:[psg.com #1107] IETF/LC Transition rules (gen-art 1)
>
> Hi -
>
> As a technical contributor...
>
> > From: "Addison Phillips" <addison.phillips@quest.com>
> > To: "LTRU Working Group" <ltru@ietf.org>
> > Cc: "Elwyn Davies" <elwynd@dial.pipex.com>
> > Sent: Wednesday, August 31, 2005 1:53 PM
> > Subject: [Ltru] Transition rules (gen-art #1)
> ...
> > Proposed resolution:
>
> looks good to me, with minor comments inline below...
>
> > To clear the interregnum problem, I propose inserting the following
> > text in Section 3.7 (insertion marked with >>> and <<<):
> >
> > --
> > Registrations that are in process under the rules defined in
> > <xref target="RFC3066"></xref> when this document is adopted
> >   MAY be completed under the former rules, at the discretion
> > of the Language Tag Reviewer >>> (as described in <xref
> > target="RFC3066"></xref>). Until the IESG officially appoints
> > a Language Subtag Reviewer, the existing Language Tag Reviewer
> > will serve as the Language Subtag Reviewer. <<<
>
> will -> SHALL
>
> > --
> >
> > To address the timing problem I propose inserting the following text in
> Section 3.7 as shown:
> >
> > --
> > Upon adoption of this document an initial version of the
> > Language Subtag Registry containing the various subtags initially
> > valid in a language tag is necessary. This collection of subtags,
> > along with a description of the process used to create it, is
> > described by <xref target="initial-registry"></xref>. >>> IANA
> > will publish the new registry as described in that document, at
>
> will -> SHALL
> replace "as described in" with "content provided by" to remove ambiguity
> (The IANA considerations section already says this, so I'm not sure this
> is really needed.)
>
> > which point the maintenance rules and registration processes
> > described in this document will be available for new registrations
> > or updates. <<<
> > --
> ...
>
> Randy
>
>
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru


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

--=_alternative 00049F8888257075_=-- --===============0169797528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0169797528==-- From ltru-bounces@ietf.org Tue Sep 06 22:44:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECpvI-0007S9-PL; Tue, 06 Sep 2005 22:44:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECpvG-0007Rq-Eu for ltru@megatron.ietf.org; Tue, 06 Sep 2005 22:44:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22620 for ; Tue, 6 Sep 2005 22:44:24 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECpyK-0005U7-5P for ltru@ietf.org; Tue, 06 Sep 2005 22:47:38 -0400 Received: from h-68-166-37-198.snvacaid.dynamic.covad.net ([68.166.37.198] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECpv5-0006uX-00 for ltru@ietf.org; Tue, 06 Sep 2005 22:44:15 -0400 Message-ID: <000001c5b356$56782180$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050906034719.HHP23403.edge4.adelphia.net@megatron.ietf.org> <005701c5b299$7adef660$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu Date: Mon, 5 Sep 2005 23:15:51 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, September 05, 2005 9:14 PM > Subject: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu > > Randy Presuhn wrote: > > > So far, I haven't seen anything like a consensus on what to do with > > this item. If there is no consensus to change, then the decision about > > what (if anything) to do to zh-guoyu will be left for > > ietf-languages@iana.org to decide after the new registry goes into > > effect, whenever that might be. > > > > For now, I'll leave this open, but if no rough consensus emerges, it > > will be marked "rejected". > > I don't understand whether this means I am supposed to leave > draft-initial-04 alone, with zh-guoyu deprecated in favor of zh-cmn, or > create a new draft-05, with this change from July undone. ... At this time, definitely *NOT* create a draft-05. We won't do submit any updates until after we've handled any DISCUSS items that come back from the IESG. All these items from IETF last call being discussed for both drafts will need to be "batched", and merged / cycled with edits resulting from IESG feedback when the time comes. At this point it's important to keep churn to a minimum. As for the specific text in the zh-guoyu entry, there's an issue because messages posted to the list seem to indicate that some change is needed. Just what that change should be isn't clear to me. For example, one message says "However, "zh-guoyu" should have a Preferred-Value of "zh-cmn"", which is what I see in draft -04, so I'm not sure what folks want to change. That's why there's an issue. Unless there is consensus to make a change, the "default" has to be to keep things as they are in -04. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 22:44:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECpvJ-0007SX-1X; Tue, 06 Sep 2005 22:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECpvH-0007Ry-Bh for ltru@megatron.ietf.org; Tue, 06 Sep 2005 22:44:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22623 for ; Tue, 6 Sep 2005 22:44:25 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECpyK-0005UA-5L for ltru@ietf.org; Tue, 06 Sep 2005 22:47:39 -0400 Received: from h-68-166-37-198.snvacaid.dynamic.covad.net ([68.166.37.198] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ECpv6-0006uX-00 for ltru@ietf.org; Tue, 06 Sep 2005 22:44:16 -0400 Message-ID: <000101c5b356$56bb4500$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0CA912BE@irvmbxw01.quest.com><007c01c5b291$1ce997c0$7f1afea9@oemcomputer> <431D1372.4435@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #1107] IETF/LC Transition rules (gen-art 1) Date: Mon, 5 Sep 2005 23:30:58 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - as a technical contributor... > From: "Frank Ellermann" > To: > Sent: Monday, September 05, 2005 8:56 PM > Subject: [Ltru] Re: [psg.com #1107] IETF/LC Transition rules (gen-art 1) > > Randy Presuhn wrote: > > >> the existing Language Tag Reviewer will serve as the > >> Language Subtag Reviewer. > > > will -> SHALL > > Maybe he's not interested, we can only ask him, not force > him. How about "the existing LTR serves as the LSR" ? Ok with me, or just leave it as originally proposed. We're really just retitling the job. I'm happy to leave this to the editors. > >> IANA will publish the new registry as described in that > >> document, at > > > will -> SHALL > > Okay, here it's clearly their duty, but I prefer "publishes" > if "will publish" isn't good enough. That could be also a > bad case of DEnglish on my side - thou shalt not abuse 2119- > keywords to impose a particular method. ... :-) Unfortunately, "publishes" won't work. (and yes, this is indeed one of those places where English and German diverge.) I can live with "will", since it is grammatically correct and the most native speakers would ascribe the correct sense to the word in this context. The only advantage of "SHALL" is that it eliminates the posibility of (contrived) mis-reading "will". I'm happy to leave this to the editors as well. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 06 22:58:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECq94-0002Q1-Kj; Tue, 06 Sep 2005 22:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECq92-0002Pw-Tf for ltru@megatron.ietf.org; Tue, 06 Sep 2005 22:58:40 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23299 for ; Tue, 6 Sep 2005 22:58:38 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050907025809.OOAZ24716.mta9.adelphia.net@DEWELL> for ; Tue, 6 Sep 2005 22:58:09 -0400 Message-ID: <008d01c5b357$e3c6a420$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050906160627.LEDU25026.edge5.adelphia.net@megatron.ietf.org> Date: Tue, 6 Sep 2005 19:57:29 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I wrote: > Randy Presuhn wrote: > >> So far, I haven't seen anything like a consensus on what to do with >> this item. If there is no consensus to change, then the decision >> about what (if anything) to do to zh-guoyu will be left for >> ietf-languages@iana.org to decide after the new registry goes into >> effect, whenever that might be. >> >> For now, I'll leave this open, but if no rough consensus emerges, it >> will be marked "rejected". > > I don't understand whether this means I am supposed to leave > draft-initial-04 alone, with zh-guoyu deprecated in favor of zh-cmn, > or create a new draft-05, with this change from July undone. I goofed. After re-reading what I had originally written, it appears the real question is whether to leave the "Deprecated" date of zh-guoyu alone or change it to 2005-08-30, not to undo the deprecation. (Good.) I assume "rejected" means the date would be left alone. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 02:51:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECtmN-0002Uz-Qn; Wed, 07 Sep 2005 02:51:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECtmJ-0002UE-2D; Wed, 07 Sep 2005 02:51:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00762; Wed, 7 Sep 2005 02:51:26 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECtpQ-0002vS-If; Wed, 07 Sep 2005 02:54:41 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ECtmH-0006q4-6z; Wed, 07 Sep 2005 02:51:25 -0400 Date: Wed, 07 Sep 2005 02:51:25 -0400 From: John C Klensin To: Frank Ellermann , ietf@ietf.org, iesg@ietf.org Message-ID: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On Wednesday, 07 September, 2005 01:10 +0200 Frank Ellermann wrote: > John C Klensin wrote: > >> (ii) either put the initialization draft on the standards >> track with it or publish it as informational and use the >> downref procedure, > > That's a formal point: The initial registry is too long to > put it in the IANA considerations of the main document, and > it will be soon obsolete. Therefore it had to be a separate > document. > > Because the WG wanted a proper last call also for this part > it was published as I-D. Same idea as for e.g. RfC 4021 - a > part of the header field registry defined in RfC 3864. > > Apparently RfC 4021 is "standards track", but "informational" > for the initial registry is also possible. I don't get the > need for "downref" in this case, the reference to the initial > registry in the main document _is_ only informational. That wasn't clear from the text, but I may not have read closely enough. See below. > Do "informational" RfCs created by a WG get a "last call" ? > I'm not sure what the last paragraph in 2026 4.2.3 means. Independent of what that paragraph means, it is common for anything that is presented by the WG to IESG for comment to get a last call within the WG; I can't imagine a WG chair doing otherwise. Whether WG informational documents are then Last Called to the IETF is up to the IESG and relevant ADs. There is no requirement that it be done, but it generally is done if the AD concludes that the document is likely to be either consequential or controversial. > Something's odd with the procedures here, I'd be surprised > if RfC 4021 would be promoted on stadards track, it's only > a (now already obsolete) snapshot of a part of a registry. Personal opinion: What should be done in cases like this is to structure the I-D so that it clearly differentiates between: (i) The specification, rationale, and other contextual information for the initial registry contents, and (ii) The actual listing of the registry initialization and that the specification provide for some way of distinguishing between initial registry entries and subsequent ones by examining the registry (this could be as simple as the specification of a particular date. Then an instruction to the RFC Editor could be included in the I-D asking that they not publish the initialization document until the entries have been made in the IANA registry and then that the list of entries be dropped and replaced with a pointer paragraph and reference. That would lead to an RFC that was clearly informational and fairly short, saving everyone long-term problems. For draft-ietf-ltru-initial, that would mean retention of sections 1, 2, and 4-7 into the RFC but the replacement of section three with, e.g., "3. The initial contents of the registry as specified in this document are those entries in the IANA registry [IANA-registry] with a field-name of "Added" and a value of "2005-07-10". Note that [ltru-registry, Section 3.1] requires that an "Added" field appear in each registration record and that its Section 3.3(1) specifies that field must not be changed after registration." Then you are done. Presto, clearly informational document, historical information retained in the registry (which is where, IMO, it belongs), no chance of anyone ignoring the instructions in the third paragraph of Section 1 that the initialization list in the RFC is not the registry, and an RFC that runs around ten pages rather than 118. I think that would be a win all around. But, again, just my opinion. >> The documents make reference to the "record-jar" format. I >> believe the text in ltru-registry is sufficient to define >> the portion of that spec that is relevant > > Yes, the defined format is "inspired by" record-jar, it does > not claim to be the real thing. E.g. it doesn't have arbitrary > comment lines, OTOH it defines a way to encode Unicode by the > known &#x????; sequences for u+????. > >> a dependency on a moderately expensive book that could go out >> of print as part of the definition for an IANA registry > > No, it's also only informational for those interested in "the > real thing" instead of what's used for the registry and future > extension registries. I would recommend that, as an editorial matter, use of phrases like "inspired by" or "derived from" would clear up a lot of confusion before it starts, making it clear that the book is not needed. For example, the beginning of the second paragraph of 3.1 might read 'The registry will be in a text file format that is fully specified below. This format was inspired by the "record-jar" format [record-jar].' But, again, this is purely an editorial matter as far as I'm concerned. >> incidentally, the reference given is incomplete. > > Yes, the draft author knows already how to add the proper ISBN > with xml2rfc, "easily fixed" as you said. Not referencing the > original idea at all would be wrong. But the reference in the > initial registry draft is in fact unnecessary. Think of it as > some kind of "informational credits" in the main document. > We also considered a pure 2822-like format with CRLF CRLF as a > record separator, but the WG preferred CRLF "%%" CRLF, that's > all - no copyright traps and no necessity to buy the book (e.g. > I don't have it). Not a decision on which I'd ever be inclined to second-guess a considered WG decision. john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 10:17:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0jf-00030M-Vi; Wed, 07 Sep 2005 10:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0ja-0002zt-OU; Wed, 07 Sep 2005 10:17:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22283; Wed, 7 Sep 2005 10:17:05 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED0ml-0006tp-FP; Wed, 07 Sep 2005 10:20:24 -0400 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050907141651.JNPI24716.mta9.adelphia.net@DEWELL>; Wed, 7 Sep 2005 10:16:51 -0400 Message-ID: <00c201c5b3b6$526074c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "John C Klensin" , "Frank Ellermann" , , References: Date: Wed, 7 Sep 2005 07:13: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-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin wrote: > Then an instruction to the RFC Editor could be included in the > I-D asking that they not publish the initialization document > until the entries have been made in the IANA registry and then > that the list of entries be dropped and replaced with a pointer > paragraph and reference. That would lead to an RFC that was > clearly informational and fairly short, saving everyone > long-term problems. The whole purpose of draft-initial is to serve as the vehicle by which the initial registry contents are transmitted to IANA. That was what the co-chairs and group thought best. There would be no need for a separate initialization document otherwise. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 11:06:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1VN-0004k6-UR; Wed, 07 Sep 2005 11:06:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1VM-0004ip-2P; Wed, 07 Sep 2005 11:06:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25096; Wed, 7 Sep 2005 11:06:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED1YU-0008EH-VM; Wed, 07 Sep 2005 11:09:46 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1ED1VD-0002up-SZ; Wed, 07 Sep 2005 08:06:20 -0700 Message-Id: <6.2.3.4.2.20050907163334.037cfb00@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 07 Sep 2005 17:06:09 +0200 To: "Doug Ewell" , "John C Klensin" , "Frank Ellermann" , From: r&d afrac Subject: Re: [Ltru] Re: Last call comments on LTRU registry and initialization documents In-Reply-To: <00c201c5b3b6$526074c0$030aa8c0@DEWELL> References: <00c201c5b3b6$526074c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John, the problem we face here is a lack of knowledge of what the users are supposed to expect from the data in this draft. The amount of data is important, and there is no distribution strategy documented (except on the mailing list as: "as Unicode"). This is rather concerning since we are confronted here to a situation which could be similar to the Host.txt situation in the early 80s. And to a IANA political situation comparable to the DNS governance. To limit the risk of IANA overload, with the need of a foreign distribution system which would control the MultiLingual Internet, and to preserve the control of IETF over the langroot, I suggested an ill taylored but probably operationnally adequate solution. The langroot file (Doug Ewell documents here) would be maintained as a Draft and updated every months. Drafts have a well established distribution system and I do not think that an application developper will come and read a Draft at each machine boot. This way the langroot disemination would be easily hierarchical (ISP, users, etc) and the pressure on the main server would be far lower (requests once a month, rather than once a day). As the langroot develops there will most probably be a mission creep and calls for ietf-languages@lavestrand.no playing for languages a role similar to ICANN for names, with a similar IANA split of responsibilities. I think this would be politically not-acceptable. I would prefer to avoid a future conflict and a balkanisation motivation in cancelling the ietf-languages@alvestrand.no mailing list and in transfering its role to the WG-ltru, so the task stays in line with IETF evolution and protocols requirements, and under its IESG (IAB reviewed) Charter. jfc At 16:13 07/09/2005, Doug Ewell wrote: >John C Klensin wrote: > > > Then an instruction to the RFC Editor could be included in the > > I-D asking that they not publish the initialization document > > until the entries have been made in the IANA registry and then > > that the list of entries be dropped and replaced with a pointer > > paragraph and reference. That would lead to an RFC that was > > clearly informational and fairly short, saving everyone > > long-term problems. > >The whole purpose of draft-initial is to serve as the vehicle by which >the initial registry contents are transmitted to IANA. That was what >the co-chairs and group thought best. There would be no need for a >separate initialization document otherwise. > >-- >Doug Ewell >Fullerton, California >http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 14:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4ZU-0006dW-JF; Wed, 07 Sep 2005 14:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECtdv-0000JL-Na; Wed, 07 Sep 2005 02:42:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00344; Wed, 7 Sep 2005 02:42:46 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECth2-0002jL-OT; Wed, 07 Sep 2005 02:46:01 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ECtdo-0006n3-LG; Wed, 07 Sep 2005 02:42:40 -0400 Date: Wed, 07 Sep 2005 02:42:40 -0400 From: John C Klensin To: Frank Ellermann , ietf@ietf.org, iesg@ietf.org Message-ID: <2F875E30AD5B4FC0D549B8EE@scan.jck.com> In-Reply-To: <431E21F9.A87@xyzzy.claranet.de> References: <431E21F9.A87@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Sep 2005 14:22:55 -0400 Cc: ltru@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On Wednesday, 07 September, 2005 01:10 +0200 Frank Ellermann wrote: > John C Klensin wrote: > >> (ii) either put the initialization draft on the standards >> track with it or publish it as informational and use the >> downref procedure, > > That's a formal point: The initial registry is too long to > put it in the IANA considerations of the main document, and > it will be soon obsolete. Therefore it had to be a separate > document. > > Because the WG wanted a proper last call also for this part > it was published as I-D. Same idea as for e.g. RfC 4021 - a > part of the header field registry defined in RfC 3864. > > Apparently RfC 4021 is "standards track", but "informational" > for the initial registry is also possible. I don't get the > need for "downref" in this case, the reference to the initial > registry in the main document _is_ only informational. That wasn't clear from the text, but I may not have read closely enough. See below. > Do "informational" RfCs created by a WG get a "last call" ? > I'm not sure what the last paragraph in 2026 4.2.3 means. Independent of what that paragraph means, it is common for anything that is presented by the WG to IESG for comment to get a last call within the WG; I can't imagine a WG chair doing otherwise. Whether WG informational documents are then Last Called to the IETF is up to the IESG and relevant ADs. There is no requirement that it be done, but it generally is done if the AD concludes that the document is likely to be either consequential or controversial. > Something's odd with the procedures here, I'd be surprised > if RfC 4021 would be promoted on stadards track, it's only > a (now already obsolete) snapshot of a part of a registry. Personal opinion: What should be done in cases like this is to structure the I-D so that it clearly differentiates between: (i) The specification, rationale, and other contextual information for the initial registry contents, and (ii) The actual listing of the registry initialization and that the specification provide for some way of distinguishing between initial registry entries and subsequent ones by examining the registry (this could be as simple as the specification of a particular date. Then an instruction to the RFC Editor could be included in the I-D asking that they not publish the initialization document until the entries have been made in the IANA registry and then that the list of entries be dropped and replaced with a pointer paragraph and reference. That would lead to an RFC that was clearly informational and fairly short, saving everyone long-term problems. For draft-ietf-ltru-initial, that would mean retention of sections 1, 2, and 4-7 into the RFC but the replacement of section three with, e.g., "3. The initial contents of the registry as specified in this document are those entries in the IANA registry [IANA-registry] with a field-name of "Added" and a value of "2005-07-10". Note that [ltru-registry, Section 3.1] requires that an "Added" field appear in each registration record and that its Section 3.3(1) specifies that field must not be changed after registration." Then you are done. Presto, clearly informational document, historical information retained in the registry (which is where, IMO, it belongs), no chance of anyone ignoring the instructions in the third paragraph of Section 1 that the initialization list in the RFC is not the registry, and an RFC that runs around ten pages rather than 118. I think that would be a win all around. But, again, just my opinion. >> The documents make reference to the "record-jar" format. I >> believe the text in ltru-registry is sufficient to define >> the portion of that spec that is relevant > > Yes, the defined format is "inspired by" record-jar, it does > not claim to be the real thing. E.g. it doesn't have arbitrary > comment lines, OTOH it defines a way to encode Unicode by the > known &#x????; sequences for u+????. > >> a dependency on a moderately expensive book that could go out >> of print as part of the definition for an IANA registry > > No, it's also only informational for those interested in "the > real thing" instead of what's used for the registry and future > extension registries. I would recommend that, as an editorial matter, use of phrases like "inspired by" or "derived from" would clear up a lot of confusion before it starts, making it clear that the book is not needed. For example, the beginning of the second paragraph of 3.1 might read 'The registry will be in a text file format that is fully specified below. This format was inspired by the "record-jar" format [record-jar].' But, again, this is purely an editorial matter as far as I'm concerned. >> incidentally, the reference given is incomplete. > > Yes, the draft author knows already how to add the proper ISBN > with xml2rfc, "easily fixed" as you said. Not referencing the > original idea at all would be wrong. But the reference in the > initial registry draft is in fact unnecessary. Think of it as > some kind of "informational credits" in the main document. > We also considered a pure 2822-like format with CRLF CRLF as a > record separator, but the WG preferred CRLF "%%" CRLF, that's > all - no copyright traps and no necessity to buy the book (e.g. > I don't have it). Not a decision on which I'd ever be inclined to second-guess a considered WG decision. john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 14:22:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4ZU-0006du-UC; Wed, 07 Sep 2005 14:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED31o-0005tI-5v; Wed, 07 Sep 2005 12:44:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01211; Wed, 7 Sep 2005 12:44:01 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED34z-00035B-FF; Wed, 07 Sep 2005 12:47:23 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 58CD7160009; Tue, 6 Sep 2005 17:22:20 -0400 (EDT) To: John C Klensin References: From: Sam Hartman Date: Tue, 06 Sep 2005 17:22:20 -0400 In-Reply-To: (John C. Klensin's message of "Tue, 06 Sep 2005 16:19:47 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.4 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Wed, 07 Sep 2005 14:22:55 -0400 Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org >>>>> "John" == John C Klensin writes: John> --On Tuesday, 06 September, 2005 15:14 -0400 Sam Hartman John> wrote: >> John, what does it mean to put a registry document on the >> standards track? In particular, how do you get multiple >> implementations of a registry? John> One is reminded of the story of Eeyore's birthday party. John> Registering things --putting them into a registry so that John> they can be retrieved and examined using whatever key was John> used to put them there-- is always easy and, as you point John> out, untestable. But it is also almost never the point: the John> point is whether the right information is being placed in John> the registry to support the relevant applications and John> whether those applications can use the information in a way John> that promotes interoperability. John> With regard to that driving issue, it is certainly possible John> to have multiple implementations of matching rules. It is John> certainly possible to examine, in practice, different uses John> of the tagging system to determine whether its mechanisms John> are sufficient and, if sufficient, whether they meet some John> "minimum necessary" criteria or represent serious overkill John> and/or redundancy. It is possible to do many things. I was hoping that I could get you to make a concrete proposal for how you see this document advancing if we put it on the standards track. Personally I think your comments are valuable even if you don't make such a proposal,but I think they would be more valuable if you or someone holding the same position would make it very clear what it would mean for this document to be on the standards track. My question is not motivated by a lack of imagination about what that could mean but rather all too many options I can think of. Here are some questions it seems like the IETF community would need to answer in order to implement your proposed categorization: 1) What happens to the existing registry with these documents on the standards track but not BCPs? 2) How do we advance these documents on the standards track? In addition, it might be advisable for the IETF community to consider the question of what happens if we find this is not the right approach; that question is not required to implement your proposed reclassification but it seems advisable to consider. Let me throw something out to answer the questions I posed. We could keep the existing 3066 registry as the BCP registry and create a new registry for these documents. We could advance these documents when any single using protocol advances. Presumably that would mean that these documents could not advance until some protocol that normatively references them advances; that's probably OK. Clearly these are not the only answers to the questions I posed--I'm not even sure if they are good answers. They are presented only to illustrate that it is possible to answer the questions without huge effort. That in turn suggests to me at least that I'm not establishing an unreasonable requirement by asking the questions be answered. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 14:38:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4o5-0001rn-F1; Wed, 07 Sep 2005 14:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED083-0002gm-BI; Wed, 07 Sep 2005 09:38:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19779; Wed, 7 Sep 2005 09:38:17 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED0BC-0005uO-Lc; Wed, 07 Sep 2005 09:41:37 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1ED07g-000122-KI; Wed, 07 Sep 2005 06:37:57 -0700 Message-Id: <6.2.3.4.2.20050907112337.0475e1b0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 07 Sep 2005 15:37:46 +0200 To: John C Klensin , Sam Hartman From: "JFC (Jefsey) Morfin" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-Mailman-Approved-At: Wed, 07 Sep 2005 14:38:00 -0400 Cc: ltru@ietf.org, iesg@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 22:19 06/09/2005, John C Klensin wrote: > * when there is no evidence that it is "best" (even if > one agrees that no better options are on the table or > even that none are likely to be searched out and found > unless, someone, this approach is shown to fail as RFC > 3066 was shown to fail), and John, you can say that! There are four propositions. The Draft is the least network oriented, but has its place for catalogs, library organisation, related menus, and e-commerce contracts. It should have been a WTO, W3C, LDAP, MPEG proposition, but it supports a consistent content-database-computer management system (HTML, XML, CLDR [some Locale standardisation attempt]). The problem is simply that it would constrain human relations and cultural life support protocols to its locale "internationalisation" conceptual level, and miss key networked communication aspects. A two minutes consideration of the difference between the way Shakespeare wrote a page and the way you store, distribute and read it today, may give you some hints about the difference between what the Draft wants to do and what the IETF needs. The Draft drastically extends the basic error of the lose RFC 3066 (rigidifying orthogonal language/country information) and wants to see it enforced and made universal. A content container should at least document if the language description is from the author, to the reader or for the protocol. It should the document seven properties (language, mode, community, referent, context, style, media) and the property description version. Your own Words program just does that. Each of these elements may include many sub-elements. There are three other propositions than status-quo: A. the current Draft using of ISO 639-1, 2, 3 and additional ISO codes. That proposition is based upon the SIL list of 7500 documented languages. It is supported by Peter Constable (on the list), author of ISO 639-3. B. Linguasphere (planned to be ISO 639-6). It identifies 20.000 community language 4 letters not reusable codes and is built as ISO 11179 compliant for far more information. They fully replace langtags when no legal aspect is involved. They are planned to be discussed when an ISO standard. It is supported by Debbie Garside (on the list) and Dr. David Dalby. C. the "grassroots approach". The approach is to accept in a network and multilingual way everything existing and to relate it to an "ISO 11179" compatible system. Still at basic thinking and experimental stage. This is part of a generalised DRS (distributed registries system) to include every network/local/user registry (including langtag). The URI-tags seem to fully support the network aspects, the IRI-tags the multilingual concept. It obviously support the two systems above which can be its defaults. I accepted to spend time on the representation of industrial, political and users interests in that area. There is no "better" solution. There are more adequate solutions in specific situations (A and B can be defaults of C). Each helping the other to better define itself. However the A proponents think their proposition must be exclusive. They wanted a counter-proposition of mine so the "best" might "win". Their ad-hominems were their way to exclude a "competition". Their non-technical mails on the IETF main list fully exposed that strategy. The text proposed in December was not acceptable. The currently proposed text still appears as an "industrial and commercial Trojan Horse" with risks of commercial, political and technical confusion. But its authors have trimmed enough their ABNF "against me" to block "C" leaks there and threfore a lot of confusion. Yet, we have still have no support of non-script mode and three sources of conflicts: - charset of a document vs script. - script of a document in a politically oriented (privacy/racial violation) tag. - lingual community information - what may imply a conflicting language, script and charset - may conflict with langtags. My proposition is: 1. to reduce the charset/script conflicts in defining the Internet meaning of a script (equivalent to ccTLD IDN tables). No big deal, since the tables are already published by Unicode. 2. to define the relation between ccTLDs and langtags "regions" - probably one sentence to be approved by IANA, ICANN and the ccTLD community. 3. to include the IRI-tags into the Draft, through the multilingual (numeric) "0-" hook, so we support different but not alternative descriptions. I was opposed over ISO 11179. It seems this has changed since the August ISO meeting. I can only rejoice. IMHO the DRS issue is far more complex than ISO 11179 and should be addressed separately (may be after some experience has been gained with the IRI-langtags?) jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 15:19:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5Sf-0003rf-05; Wed, 07 Sep 2005 15:19:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5Sd-0003rU-7J; Wed, 07 Sep 2005 15:19:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10814; Wed, 7 Sep 2005 15:19:51 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED5Vp-0007gs-Be; Wed, 07 Sep 2005 15:23:13 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 12:19:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call comments on LTRU registry and initialization documents Date: Wed, 7 Sep 2005 12:19:37 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CB444CF@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last call comments on LTRU registry and initialization documents Thread-Index: AcWy0FTU0m2OWYitSHqzrQVP5pgC1QA/IC1w From: "Addison Phillips" To: "John C Klensin" , X-OriginalArrivalTime: 07 Sep 2005 19:19:38.0400 (UTC) FILETIME=[16F38A00:01C5B3E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > Comments on draft-ietf-ltru-registry and > draft-ietf-ltru-initial and, secondarily, on > draft-ietf-ltru-matching... I've thought a lot about the excellent analysis and comments in John = Klensin's message. My perception is that we have a divergent view of the = structure and significance of the LTRU draft(s).=20 Although superficially the drafts are very different than the RFC 3066 = that they seek to replace, in fact the structure is very similar. The = drafts are attempting to fill certain gaps unaddressed by RFC 3066 for = implementers or for tag choice by and the requirements on "content = authors" (people who choose tags or ranges). Here are my basic thoughts in response to those comments: 1. All tags valid under the drafts would have been valid or valid to = register under RFC 3066. This is a key point. The tag grammar proposed = is intended to be highly compatible not just with RFC 3066 but also with = existing implementation. It is expressed as greater restriction on what = may be registered. This provides more regularity in tags, although tags = themselves are not greatly changed. A subtag registry is, in effect, a = different way of expressing what is already in place.=20 2. The fact that it *always* narrows the potential subtags that could be = registered *in the future*, but has no effect on any tags or subtags = already extant means that (from an RFC 3066 implementation perspective) = the range of tags actually seen in the wild will be more limited than it = might have been. Commentators on this thread have implied that it is an = entirely new protocol, but I think that goes too far: it is the same = protocol with greater rigor on what may go where.=20 3. The various rules and guidelines set down in the draft provide a more = rigorous registration process based on the experience of operating = ietf-languages for the seven or so years. This could be seen to make it = the "best current practice" for registering language tags or their = components. The switch to subtags was chosen to spare the community = immense numbers of registrations of various subtag variations (examples = from the current registry: two German orthographic subtags, eight = registrations; two Chinese script subtags, *twelve* registrations).=20 4. The creation of a registry simplifies the work incumbent on = implementers or content authors, since they no longer have to refer to = (under RFC 3066) four separate tag-or-subtag repositories and then = synthesize the rules in RFC 3066 for choosing between certain = overlapping subtags (for example ISO 639-1/-2). The fact that there is a = registry doesn't change the fact that "somewhere" there is a list of = subtags that may be validly combined into tags. 5. There is a perfectly good matching scheme loosely described in RFC = 3066. This scheme is enshrined in numerous places, including RFC 3282 = (which, you'll note, also "Obsoletes: 1766", an example with 3066 of two = RFCs obsolescing the same BCP on separate days over a year apart). The = additional forms of matching described by the matching draft are = interesting and may be useful in a variety of applications = (draft-matching gives some examples). But they are unnecessary to the = specific task of updating RFC 3066. Applications of language tags in the = future may wish to choose one or another of the other schemes from = draft-matching to produce more interesting results. But such additional = schemes are not necessary to the task of updating RFC 3066. If the community feels that matching is so important that draft-registry = must deal with it directly, my suggestion would be to take Section 2.5 = verbatim from RFC 3066 and include it in draft-registry. This preserves = the vital reference to language-ranges. It should be noted that RFC 3066 = nowhere provides an explicit treatise on matching. Both it and = draft-registry were written for compatibility with known matching = schemes. Success or failure of the draft should necessarily be measured = by its interoperability with existing matching protocols. My belief is = that there is high interoperability, since the matching scheme is quite = basic and the rules governing tag choice gave careful consideration to = the problem of script subtags.=20 6. The tag forms used in the draft are, in fact, being registered and = adopted. I note that Google this morning returns 41,600 hits for = "zh-Hant" as a piece of content. Many of these appear to be valid usages = as language tags---script subtags in the wild--rather than just mentions = of the registration. Thus the draft merely recognizes the "reality on = the ground" with regard to language tags. It does so by reorganizing how = tags are registered to make the scheme more manageable. 7. The choice between STD and BCP tracks is really a toss-up. There are = very good arguments on both sides. The creation and management of a = registry does not lend itself to STD, but the creation and testing of = implementations does not lend itself to BCP. My thought here is that one = can view the draft entirely through the lens of existing RFC 3066 = implementers: these documents represent a set of BCPs related to various = aspects of registering, choosing, and implementing language tags. New = implementations may be different as a result of the improvements made = (certain kinds of assumptions can be made about a 3066bis tag that = cannot be made about a 3066 tag). All such implementations will be = recognizably implementations of RFC 3066, though, and to the benefit of = all concerned (IMHO) they represent the best current thinking on the = manner in which to identify languages on the Internet (given our legacy = considerations). JCK wrote in part: -- These specifications are a nice piece of work and the model specified is = quite elegant. It appears to me to meet the goals of permitting a high = degree of specificity when needed while providing a plausible mechanism = for preserving stability across changes in underlying documents. Having = tried, mostly unsuccessfully, to track the WG's work, I believe that the = IETF community owes those who have actively participated and contributed = great thanks. =20 -- As a participant in this effort, I have to say that it has been a = remarkable and exhausting effort. I certainly hope that LTRU has, in = fact, achieved its goals and hope too that, after a lot of work, we can = move forward to a recognizable conclusion to these efforts. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 19:18:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED9BI-0001cz-OI; Wed, 07 Sep 2005 19:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED9BG-0001cR-TG for ltru@megatron.ietf.org; Wed, 07 Sep 2005 19:18:15 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00224 for ; Wed, 7 Sep 2005 19:18:11 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ED99t-00026V-D7 for ltru@lists.ietf.org; Thu, 08 Sep 2005 01:16:49 +0200 Received: from c-134-88-165.hh.dial.de.ignite.net ([62.134.88.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Sep 2005 01:16:49 +0200 Received: from nobody by c-134-88-165.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Sep 2005 01:16:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 08 Sep 2005 01:11:52 +0200 Organization: Lines: 98 Message-ID: <431F73B8.3806@xyzzy.claranet.de> References: <431E21F9.A87@xyzzy.claranet.de> <2F875E30AD5B4FC0D549B8EE@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-165.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin wrote: >> I'm not sure what the last paragraph in 2026 4.2.3 means. > Independent of what that paragraph means, it is common for > anything that is presented by the WG to IESG for comment to > get a last call within the WG; I can't imagine a WG chair > doing otherwise. Yes, we've done this. The problem with the initial registry is that it's easy to miss something - it's derived from six different sources, among others the "old" 3066 registry. For some details it's possible to fix potential bugs later (using the registration / review procedure of the main document). But generally it's intentionally impossible to get rid of a registered tag, they are persistent: "deprecate" is allowed, but not "removal". Therefore it's important to find any bug now in the "IETF last call", later would be too late. > Whether WG informational documents are then Last Called to > the IETF is up to the IESG and relevant ADs. There is no > requirement that it be done, but it generally is done Okay, that's the desired effect in this case, the status (PS, informational, or other ways to send it to IANA) is secondary. [...] > that the specification provide for some way of distinguishing > between initial registry entries and subsequent ones by > examining the registry That's possible, there are "Added" / "Deprecated" timestamps. > an instruction to the RFC Editor could be included in the > I-D asking that they not publish the initialization document > until the entries have been made in the IANA registry That should be also clear, there are "IANA considerations" in both documents, and it makes no sense to publish them as RfC without first creating the actual registry (as defined by the initialization document). In other words, we artificially squeezed the initial registry into an I-D to get the desired "IETF last call", and IANA has to remove these artifacts (intro, boilerplate, page headers) again resulting in the proper registry. > For draft-ietf-ltru-initial, that would mean retention of > sections 1, 2, and 4-7 into the RFC but the replacement of > section three 1, 2, and 4..7 are only a "content-transfer-encoding" for the purpose of getting 3 via "IETF last call" to IANA. And as a side-effect there will be also a RfC documenting "the making of the initial registry" - in theory it could be also archived as "historic RfC" after IANA created the real registry. > Then you are done. Presto, clearly informational document, > historical information retained in the registry (which is > where, IMO, it belongs), no chance of anyone ignoring the > instructions in the third paragraph of Section 1 that the > initialization list in the RFC is not the registry, and an > RFC that runs around ten pages rather than 118. Splitting it is IMHO less convincing - your idea assumes that chapter 3 already exists as new IANA registry, but that's not yet the case. Some hen and egg situation, and if there's an informal way to create IANA registries on probation (subject to a future "IETF last call") the WG didn't know it. The chapters 1, 2, 4..7 are also interesting without 3, but OTOH the same info is also available in the LTRU list archive, it's not strictly necessary to keep it as separate RfC apart from chapter 3 (= the beef, about 100 pages). [record-jar] > For example, the beginning of the second paragraph of 3.1 > might read > 'The registry will be in a text file format that is > fully specified below. This format was inspired by the > "record-jar" format [record-jar].' > But, again, this is purely an editorial matter as far as I'm > concerned. It's fine, I like it, then fix the [record-jar] reference, and it should be clear that is fully specified in the main document, with the book only "for info" and as "credits". Bye, Frank P.S. for Randy: Can we get a ticket for this editorial issue ? It's about 1 - no [record-jar] in "initial", 2 - "inspired by" in "registry", and 3 - add ISBN + publisher to the reference. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 19:27:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED9KQ-0004Zp-Gj; Wed, 07 Sep 2005 19:27:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED9KN-0004W5-1C; Wed, 07 Sep 2005 19:27:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00674; Wed, 7 Sep 2005 19:27:36 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED9Nd-000869-EM; Wed, 07 Sep 2005 19:31:01 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1ED9K6-0003sP-UY; Wed, 07 Sep 2005 16:27:36 -0700 Message-Id: <6.2.3.4.2.20050907230530.0484d360@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 08 Sep 2005 01:27:11 +0200 To: "Addison Phillips" , "John C Klensin" , From: r&d afrac Subject: RE: [Ltru] Last call comments on LTRU registry and initialization documents In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB444CF@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0CB444CF@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Dear John, I would like we all pay attention to what Addison says. I fully agree with him, and I thank him to be honest and at last so clear. He perfectly defines his target. What the IESG is to decide is: - if this target is or not an unbearable source of permanent contention, confirming to the Internet balkanisation engaged by the IDNA - if this target is or not a cleaning of the RFC 3066 errors (the first one being a far too limited and tight vision of language identification) - if this target permits or not to complete the RFC 3066 limitations in using the Draft as a default for a general IRI-langtags solution. At 21:19 07/09/2005, Addison Phillips wrote: > > Comments on draft-ietf-ltru-registry and > > draft-ietf-ltru-initial and, secondarily, on > > draft-ietf-ltru-matching... >I've thought a lot about the excellent analysis and comments in John >Klensin's message. My perception is that we have a divergent view of >the structure and significance of the LTRU draft(s). > >Although superficially the drafts are very different than the RFC >3066 that they seek to replace, in fact the structure is very >similar. The drafts are attempting to fill certain gaps unaddressed >by RFC 3066 for implementers or for tag choice by and the >requirements on "content authors" (people who choose tags or ranges). Correct. The Draft tries to make RFC 3066 tighter. To fill certain gaps. Not to fill any of the needs RFC 3066 does not address. >Here are my basic thoughts in response to those comments: > >1. All tags valid under the drafts would have been valid or valid to >register under RFC 3066. This is a key point. No one knows where this targets comes from. RFC 3066 logic has three problems: - the loose ABNF. This leads to confusion. The Draft addresses this. Still imperfectly, but the progress is real. - the lack of modal description. There is an embryonic _addition_ of script support - however conflicting with charset - an exclusivity resulting from its BCP status, excluding all the much needed other propositions. This is not addressed but reinforced. >The tag grammar proposed is intended to be highly compatible not >just with RFC 3066 but also with existing implementation. It is >expressed as greater restriction on what may be registered. This >provides more regularity in tags, although tags themselves are not >greatly changed. A subtag registry is, in effect, a different way of >expressing what is already in place. This proposition does not stand. What is already implemented is by nature RFC 3066 conformant, i.e. more loose - or RFC 3066 not conformant and this is not considered. RFC 3066 permits private use (x-). x-tags exist and may conflict in case of interconnection: this problem has been addressed with the URI-tags RFC: "x-private.space:tags". The Draft opposes that RFC. >2. The fact that it *always* narrows the potential subtags that >could be registered *in the future*, but has no effect on any tags >or subtags already extant means that (from an RFC 3066 >implementation perspective) the range of tags actually seen in the >wild will be more limited than it might have been. Commentators on >this thread have implied that it is an entirely new protocol, but I >think that goes too far: it is the same protocol with greater rigor >on what may go where. It is not a new protocol. This is a progressive reduction of the capacity of description of languages. While the world needs to enlarge this description. This intended narrowing will each time start a contention with the "narrowed" language or culture. Let imagine that each "narrowed" person joins the IETF to protest ... and explains the competition and control reasons implied. I suspect the ietf-languages@alvestrand.no mailing list will also need a new server. May be a good way for IETF to reach out new cultures? >3. The various rules and guidelines set down in the draft provide a >more rigorous registration process based on the experience of >operating ietf-languages for the seven or so years. This could be >seen to make it the "best current practice" for registering language >tags or their components. The switch to subtags was chosen to spare >the community immense numbers of registrations of various subtag >variations (examples from the current registry: two German >orthographic subtags, eight registrations; two Chinese script >subtags, *twelve* registrations). This more rigorous process is simple: - if you want to register a new script subtag you must first ask ISO. This is Unicode, Michael Everson. - if ISO says "no", you will have to ask Michael Everson, ietf-languages@alvestrand.no I have nothing against this. But it must be clear to everyone that this is what the Draft proposes the IESG to impose, through a BCP, to the internet global community, to the printing industry world wide. Is there someone to believe that we will not immediately face a few alt-langroots? The problem is that they will support ISO 639-1-2 small lists (current draft-registry) due to the size and the most common need. This will be a huge set-back by small languages and developing world and regional cultures. >4. The creation of a registry simplifies the work incumbent on >implementers or content authors, since they no longer have to refer >to (under RFC 3066) four separate tag-or-subtag repositories and >then synthesize the rules in RFC 3066 for choosing between certain >overlapping subtags (for example ISO 639-1/-2). The fact that there >is a registry doesn't change the fact that "somewhere" there is a >list of subtags that may be validly combined into tags. This is true. But this does not address the desire of people wanting to use the "engl" ISO 639-6-to-be code as an equivalent langtag to "en-latn-uk". Or people wanting to use the comon French "franglish" for my "en-latn-fr". >5. There is a perfectly good matching scheme loosely described in >RFC 3066. This scheme is enshrined in numerous places, including RFC >3282 (which, you'll note, also "Obsoletes: 1766", an example with >3066 of two RFCs obsolescing the same BCP on separate days over a year apart). Please do not underline the endemic inappropriate management of lingual issues by the IETF! The main interest of RFC 3282 is that is standard track and do not use langtags. Not every RFC becomes a standard, but BCPs "standardize practices" (RFC 2026.5). >The additional forms of matching described by the matching draft are >interesting and may be useful in a variety of applications >(draft-matching gives some examples). But they are unnecessary to >the specific task of updating RFC 3066. Applications of language >tags in the future may wish to choose one or another of the other >schemes from draft-matching to produce more interesting results. But >such additional schemes are not necessary to the task of updating RFC 3066. Correct. This is why there is a need for: - a multilingual internet framework dealing with language negotiation procedures (not only match or ... English, as documented) - adequate documents for each proposed format and its filtering. >If the community feels that matching is so important that >draft-registry must deal with it directly, my suggestion would be to >take Section 2.5 verbatim from RFC 3066 and include it in >draft-registry. This preserves the vital reference to language-ranges. Good idea! But the Draft ABNF should then be associated with its filtering strategy in the second draft. >It should be noted that RFC 3066 nowhere provides an explicit >treatise on matching. Both it and draft-registry were written for >compatibility with known matching schemes. Success or failure of the >draft should necessarily be measured by its interoperability with >existing matching protocols. My belief is that there is high >interoperability, since the matching scheme is quite basic and the >rules governing tag choice gave careful consideration to the problem >of script subtags. > >6. The tag forms used in the draft are, in fact, being registered >and adopted. I note that Google this morning returns 41,600 hits for >"zh-Hant" as a piece of content. Many of these appear to be valid >usages as language tags---script subtags in the wild--rather than >just mentions of the registration. Thus the draft merely recognizes >the "reality on the ground" with regard to language tags. It does so >by reorganizing how tags are registered to make the scheme more manageable. This is the most worrying part. RFC 3066 is currently not really enforced. I will not dwell on the Chinese case, a sensible case. I will only note that today an RFC 3066 loosely used langtag gives 41,600 associated URLs. Delivering language, cultural, indirectly racial information, on their authors, then on their readers _even_if_they_do_not_want_it_. This privacy violation is the worst problem created (and partly documented by RFC 3066: we all know its nickname among human right people). This privacy violation is far more dangerous than cookies and spam. Everyone knows about the French law used against Yahoo!. Should the Draft be accepted without a user protection possibility, it is likely that several legal actions will be undertaken in different countries which will lead to the blocking of the pages with a language tag when not approved by the user. Or may be to the blocking of the registry. We are in a real world. >7. The choice between STD and BCP tracks is really a toss-up. There >are very good arguments on both sides. The creation and management >of a registry does not lend itself to STD, but the creation and >testing of implementations does not lend itself to BCP. My thought >here is that one can view the draft entirely through the lens of >existing RFC 3066 implementers: these documents represent a set of >BCPs related to various aspects of registering, choosing, and >implementing language tags. New implementations may be different as >a result of the improvements made (certain kinds of assumptions can >be made about a 3066bis tag that cannot be made about a 3066 tag). >All such implementations will be recognizably implementations of RFC >3066, though, and to the benefit of all concerned (IMHO) they >represent the best current thinking on the manner in which to >identify languages on the Internet (given our legacy considerations). The question is simply: "is this Draft to standardise _now_ or in the future from obtained experience". >As a participant in this effort, I have to say that it has been a >remarkable and exhausting effort. I certainly hope that LTRU has, in >fact, achieved its goals and hope too that, after a lot of work, we >can move forward to a recognizable conclusion to these efforts. This Draft can be: - a remarkable exclusion effort, pushing aside/outside of the Internet 70% of the world population. - a good solution for e-commerce and the root of the Multilingual Internet if including IRI-tags into a common language identification solution. This will depending on the IAB final decision if one has to come to appeals. I hope that all this effort will pay back with the second solution and that we may quickly find in common a solution to the racial/cultural disclosure issue. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 07 19:59:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED9oj-00036P-KJ; Wed, 07 Sep 2005 19:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED9oh-00035q-0k; Wed, 07 Sep 2005 19:59:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01737; Wed, 7 Sep 2005 19:58:57 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED9rw-0000LI-Ge; Wed, 07 Sep 2005 20:02:21 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ED9oT-000Auu-6i; Wed, 07 Sep 2005 19:58:45 -0400 Date: Wed, 07 Sep 2005 19:58:45 -0400 From: John C Klensin To: Sam Hartman Message-ID: <02BD58E66D8134A92F365882@scan.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On Tuesday, 06 September, 2005 17:22 -0400 Sam Hartman wrote: > It is possible to do many things. I was hoping that I could > get you to make a concrete proposal for how you see this > document advancing if we put it on the standards track. Sorry, I may have misunderstood. Also, to some extent, I thought I answered this question in my initial note, but may not have been clear enough about it. And I deliberately avoided too much detail as possibly not appropriate to a Last Call comment. > Personally I think your comments are valuable even if you > don't make such a proposal,but I think they would be more > valuable if you or someone holding the same position would > make it very clear what it would mean for this document to be > on the standards track. My question is not motivated by a > lack of imagination about what that could mean but rather all > too many options I can think of. Well, I think that the decisions here should be made, or at least proposed and supported, by the WG and not by one of us. I, too, can imagine many options. Let me suggest answers to your questions below with the understanding that the WG may have better answers, and then comment further if that appears to be needed. > Here are some questions it seems like the IETF community would > need to answer in order to implement your proposed > categorization: > > 1) What happens to the existing registry with these documents > on the standards track but not BCPs? Same thing that happens if they are adopted as BCPs. Or not. The current documents propose to obsolete one registry and replace it with another. It is at least as appropriate to do that in a standards-track document as it is with a BCP. Alternately, what I have anticipated (and intended my notes to suggest) is that draft-ltru-registry and draft-ltru-matching (and maybe some other things) end up on the standards track and be supplemented by applicability statements that identify the contexts in which they should be used and with which options. I would hope that the number of them would be quite small, but one could easily imagine an "LTRU matching options for use with MIME and HTML" and an "LTRU matching options for use with XML in i18n contexts" that might show some differences. Or not. In the most general of cases, such documents might reference the new registry and old (bit-identical and handwaving) matching rules or the old registry and new matching rules. As Addison points out, the entries permitted by the new registry concept are sufficiently compatible with the entries in the old registry that the above fine distinctions would probably not be necessary. If so, any and all applicability statements would apply to the new registry. One could separately direct IANA to stop accepting registrations in the old registry. And that is the most practical and plausible definition of deprecating/ obsoleting a registry: no protocols or applicability statements utilize it and IANA does not accept new entries into it. To simply say "don't use that one any more, use this one", is an appeal to authority, not a demonstration that the old one is, in fact, obsolete and superceded. My problem with LTRU-registry (and LTRU-matching) in this regard is that they mix up "specify a better registry and matching model" with "get rid of 3066". At present, it is unproven whether, in practice, the subtag registration model of LTRU-registry, combined with LTRU-matching, is a sufficient replacement for all of the uses to which 3066 may be put. We need to remember that we have no way to know whether we have an inclusive list of all of those uses. It is much safer, in the environment in which we find ourselves, to write an A/S ("profile" to all intents and purposes) that _replicates_ the tagging model and matching rules of 3066, excluding all of the new subtag types that LTRU-registry permits, but that references the new registry and not the old one, and let _it_ replace 3066. Then one writes one or more additional A/S documents that specify different applicability of the new registry with LTRU-matching and let it complement or update the 3066-compatible A/S as appropriate. > 2) How do we advance these documents on the standards track? My apologies, but this is going to be a bit long because I think we have gotten into a philosophical and procedural tangle (through no fault of the LTRU WG). We turn the question around, perhaps taking a trip back to when BCPs actually represented "common practices" or even before we had BCPs. Our colleagues at, e.g., ISO and the ITU, have sometimes gone into the business of making lists: establishing registries of things so that numbers or codes could be assigned to them and standardized, independent of the actual applications to which those lists might be put. Such lists can be evaluated on internal quality (sometimes objectively, sometimes not), but it is usually assumed to be unfair to evaluate them on their success in supporting particular applications and types of applications. Ultimately, a criticism of the relationship between the list and some application is rejected on the basis that the relevant committee or process just assigns code points -- interpretation of those code points with regard to any particular real-world problem is is out of the committee's scope. Those efforts are often extremely worthwhile and extend across broad classes of work --efforts related to character sets, scripts, languages, and even country code identifiers are a tiny fraction of the whole. Even when I complain about the "we just assign code points" attitude, I recognize its validity and importance. _However_, as far as I can remember, the IETF has never intentionally gone into that business. Instead, we create registries in support of particular protocols or sets of protocols. The success or failure of the "foo" registry is not evaluated on how many foos we can put in to it, or its comprehensiveness relative to some external foo-list, but on whether it does the job that the foo-protocol (and maybe foo1, foo2, etc.), requires. Normally, we don't even write a "create the baz registry" document. Instead, we write a "baz protocol specification" document and include a more or less long section that instructs IANA to create the registry, what to put in it, and how. We may make those registry/IANA specifications into separate documents for a long series of good reasons, one of which is "useful for several protocols, including some we don't know about", but the evaluation criteria should not change: a success evaluation is based primarily on the success of the protocols that use the registry and its contents and the degree to which the registry supports interoperability among implementations of those protocols. Of course, if someone could demonstrate that the registration and maintenance procedures, as specified, don't work, that would also be a bar to advancement on the standards track, just as demonstrated inability to exercise IPR provisions would be, but it should not be our primary focus. That still leaves an issue that, if we have a base registry specification that is not linked to applications of the registry by either inclusion in the application specification or by strict dependency (one application, one registry), but by a collection of A/S, just how much of the registry needs to be used and in what way to justify advancing the specification. That isn't exactly a new issue, nor is it exclusive to registry specifications. My personal recommendation is that the WG should develop a recommendation on the subject -- either as part of the registry and matching specifications or as part of one or more of the A/S documents -- that we Last Call those provisions, and, assuming community support, we accept that definition and move on. The only requirement I would, personally, apply would be that the recommendation include demonstrated utility and interoperability support for at least one A/S and application. But other rules are possible and I think such requirements are best discussed in the WG and at Last Call, not turned into attempts at developing general rules. > In addition, it might be advisable for the IETF community to > consider the question of what happens if we find this is not > the right approach; that question is not required to implement > your proposed reclassification but it seems advisable to > consider. I agree. See "footnote" below. But I suggest that it has already been demonstrated that handling complex non-protocol documents that have protocol (on the wire) implications by identifying them as BCPs, even if there is no operational experience with either the documents or any associated protocols, is broken and causes other problems. So I think that, like it or not, we have sort of a zero-base problem here: my approach may or may not be the optimal one. But the status quo has already proven inadequate so the alternative is "third proposal" not "keep doing what we have been doing". Also, we do have experience with the approach I'm suggesting with less extensive registries: it occurs every time a registry is created by an "IANA Considerations" section in a standards-track document. Unlike the BCP approach, we have some running-code-like evidence that approach works, at least in those contexts. > Let me throw something out to answer the questions I posed. > We could keep the existing 3066 registry as the BCP registry > and create a new registry for these documents. We could > advance these documents when any single using protocol > advances. Presumably that would mean that these documents > could not advance until some protocol that normatively > references them advances; that's probably OK. Clearly these > are not the only answers to the questions I posed--I'm not > even sure if they are good answers. They are presented only > to illustrate that it is possible to answer the questions > without huge effort. That in turn suggests to me at least > that I'm not establishing an unreasonable requirement by > asking the questions be answered. Yes. And although I deliberately did not address this more specific possible answer in writing the text above, you will note that my strawman suggestion, including the suggested requirement for at least one application to demonstrate usability and functionality, and yours are consistent and compatible. best, john Footnote: those who are reading this and also following newtrk should probably think about one of the implications of where I, and possibly Sam, are headed. If we are going to stay with a multiple-stage standards process, it might be useful to modify the "advancement" rules in 2026 to provide that a document being considered for Proposed Standard (or any other given maturity level) may optionally include an explicit "conditions for advancement" section. That section could be evaluated by the community on Last Call (and earlier) to replace the more general conditions (and handwaving) in 2026 for that particular document or collection of documents. If approved, it wouldn't quite be binding on the community in terms of advancement of the document if those conditions were met: the advancement request would still need an IETF Last Call and "experience shows that we got those criteria wrong" could be an argument against automatic acceptance/ advancement. But it would give us a much better way to deal with peculiar and edge cases than saying "whoops, don't see how the make the 2026 standards track rules apply exactly, so let's make this a BCP". And it would mesh nicely with some of the ideas Larry and others seem to be proposing about implementation reports. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 08 00:39:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDECF-0002lY-87; Thu, 08 Sep 2005 00:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDECD-0002lM-CO; Thu, 08 Sep 2005 00:39:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14134; Thu, 8 Sep 2005 00:39:30 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDEFV-0007Cy-Ce; Thu, 08 Sep 2005 00:42:58 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EDEBv-000BuL-5n; Thu, 08 Sep 2005 00:39:15 -0400 Date: Thu, 08 Sep 2005 00:39:15 -0400 From: John C Klensin To: "JFC (Jefsey) Morfin" , Sam Hartman Message-ID: In-Reply-To: <6.2.3.4.2.20050907112337.0475e1b0@mail.jefsey.com> References: <6.2.3.4.2.20050907112337.0475e1b0@mail.jefsey.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, iesg@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Jefsey, Somewhat against my better judgment, I want to respond to a few of your remarks in the context of what I said and meant and what I think the LTRU work, as a collection of IETF documents and an IETF/IANA registry, sets out to do. --On Wednesday, 07 September, 2005 15:37 +0200 "JFC (Jefsey) Morfin" wrote: > At 22:19 06/09/2005, John C Klensin wrote: >> * when there is no evidence that it is "best" (even if >> one agrees that no better options are on the table or >> even that none are likely to be searched out and found >> unless, someone, this approach is shown to fail as RFC >> 3066 was shown to fail), and > > John, > you can say that! > > There are four propositions. The Draft is the least network > oriented, but has its place for catalogs, library > organisation, related menus, and e-commerce contracts. It > should have been a WTO, W3C, LDAP, MPEG proposition, but it > supports a consistent content-database-computer management > system (HTML, XML, CLDR [some Locale standardisation > attempt]). The problem is simply that it would constrain human > relations and cultural life support protocols to its locale > "internationalisation" conceptual level, and miss key > networked communication aspects. I believe that you are getting several different issues badly intermixed, confusing your readers and possibly even yourself. Well, I think there may be more than four "propositions", if I understand what you intend by that term, but let me return to that question below. It seems to me that the draft is nothing more or less than a way to structure elements of several different base systems into a very general language/ script/ location identification system. Those base systems have UN, ISO, and UTC origins. To the extent to which you find reasons to disagree with what those bodies have put in their standards and registries and how they have structured those registries, it seems to me that you should be taking it up with them, in their contexts. A second issue is why those particular base systems have been chosen rather than others that would accomplish the same purposes. While the WG has better reasons (some of which are identified in the LTRU-registry draft), the bottom line is that no other systems exist that are global in character, accepted internationally by recognized bodies, and generally plausible. You, or for that matter I, might well imagine that a better-optimized job could be done for one or more of them if an effort were initiated under different assumptions, but to sit around waiting for such an effort to materialize or reach agreement would delay the real work of internationalization that we both believe are important. Of course, I, and the WG, could have missed something: if you sincerely believe that there is a better alternative to one of those base systems -- an alternative that exists, is global in scope, is generally recognized by some appropriate international body, and that is generally available-- please identify it and the reasons why you think it is superior. A third issue relates to the difference between breaking things into categories in order to make lists and the codes, names, or labels that are assigned to those categories. The making of the lists is what the relevant based standards are all about. It is typically a difficult task, but it is one for which IETF cannot and should not take responsibility (as I hope I have explained above). But the assignment of codes/ names/ labels to those categories is largely arbitrary. There can be good reasons for preferring one system over another, especially in the environment of particular assumed applications (or "propositions"), and I need to assume that the UN, ISO, and UTC have made rational choices. But substituting a different set of codes doesn't change the semantics of the underlying base system. So, if you are looking for a different set of codings/ names --I don't think you are, but I can't be sure-- I think you need a really clear and compelling argument for why the existing ones are generally inappropriate and a clear and easily-realized proposal for generating a substitute list of codes and mappings. > A two minutes consideration of the difference between the way > Shakespeare wrote a page and the way you store, distribute and > read it today, may give you some hints about the difference > between what the Draft wants to do and what the IETF needs. > The Draft drastically extends the basic error of the lose RFC > 3066 (rigidifying orthogonal language/country information) and > wants to see it enforced and made universal. I see no statement in the draft that would justify the claim of wanting or expecting "enforcement". What I think I do see is a wide range of applications that might reasonably take advantage of some language and/or script and/or locality and/or "other things" coding and identification system. I imagine the range to be broader than the examples you list as "propositions". I am quite certain, philosophically rather than analytically and with examples, that the registration system and matching rules, as proposed, are too specific or overspecified for some plausible uses. I am equally certain that they are insufficiently specific for some other uses that might be imagined. But that is precisely what voluntary standards are all about. No one I know is really trying to mandate use of the technique specified in these documents and, if there is someone, he or she is delusional. I believe that the IETF should be specific, _for protocols and other work within IETF's scope_, about whether the LTRU work should be used and how it should be used. If you have other applications that could use this work, and the work is appropriate, that is great: use it with everyone's blessings. If you have applications (or propositions) for which this work is just wrong, then go do something else, I assume again with everyone's blessings. > A content container should at least document if the language > description is from the author, to the reader or for the > protocol. It should the document seven properties (language, > mode, community, referent, context, style, media) and the > property description version. Your own Words program just does > that. Each of these elements may include many sub-elements. Ok. The LTRU group, presumably with some specific IETF applications in mind, including (correctly or not) those supported by RFC 3066, concluded either that the level of specificity you ask for above was not necessary or that it was impractical. For the purposes for which you presumably want this, you have two choices, both of which appear to me, in my ignorance, to be completely plausible. The first it to completely forget about this IETF effort and do your own thing, building on either the LTRU spec or the base documents that determine the subtags as you think appropriate. No one will stop you and, if anyone tries, I recommend that you ignore them and get on with your work. The second option is to construct an applicability statement of your own, one that specifies the applications or propositions that are relevant, the elements of the LTRU registry you want to use (if any), the sources of other elements and how they are used, and so on. Whether you should try to put that applicability statement through the IETF depends on what the application area / proposition is all about: if the IETF is not representative of the community you see yourself serving, or authoritative about its needs, it seems to me that IETF involvement would add little value and probably be very frustrating for all concerned. > There are three other propositions than status-quo: > > A. the current Draft using of ISO 639-1, 2, 3 and additional > ISO codes. That proposition is based upon the SIL list of 7500 > documented languages. It is supported by Peter Constable (on > the list), author of ISO 639-3. Ok. If this has appropriate applications other than those covered by the LTRU documents, create an appropriate applicability statement. If necessary, propose a standards track document and appropriate IANA registry, but I would assume that the ISO 639 registries would be sufficient. > B. Linguasphere (planned to be ISO 639-6). It identifies > 20.000 community language 4 letters not reusable codes and is > built as ISO 11179 compliant for far more information. They > fully replace langtags when no legal aspect is involved. They > are planned to be discussed when an ISO standard. It is > supported by Debbie Garside (on the list) and Dr. David Dalby. See above comments about not-yet-complete proposals. If this were to be adopted as an ISO 639 component, the comments above would apply exactly. In the interim, unless you are prepared to argue that 3066 is adequate, without fixing the problems that LTRU addresses, until the above work is complete and accepted, and adequate for _all_ IETF-related language-tagging purposes, it seems to me that you should get out of the way of those purposes and applications. > C. the "grassroots approach". The approach is to accept in a > network and multilingual way everything existing and to relate > it to an "ISO 11179" compatible system. Still at basic > thinking and experimental stage. This is part of a generalised > DRS (distributed registries system) to include every > network/local/user registry (including langtag). The URI-tags > seem to fully support the network aspects, the IRI-tags the > multilingual concept. It obviously support the two systems > above which can be its defaults. I accepted to spend time on > the representation of industrial, political and users > interests in that area. See above about systems that are not yet complete and, from what I understand of this work, not yet really started. > There is no "better" solution. There are more adequate > solutions in specific situations (A and B can be defaults of > C). Each helping the other to better define itself. However > the A proponents think their proposition must be exclusive. > They wanted a counter-proposition of mine so the "best" might > "win". Their ad-hominems were their way to exclude a > "competition". Their non-technical mails on the IETF main list > fully exposed that strategy. I don't think so. While I think they and I disagree about many things, I have generally found them willing to listen and to accept constructive input. There really is a place, in the engineering context in which we find ourselves, for deciding that, in the presence of a demonstrated problem, a proposal that actually exists, and that is structured on top of base documents that actually exist, must be accepted in preference to work that has not yet completed and ideas that are still being formulated -- at least for an identified set of problems and applications for which it can be demonstrated to be the solution. My proposal to recast the registry and matching documents into Proposed Standards supplemented by one or more Applicability Statements should make it more clear that other applications, with their own Applicability Statements and scopes, can be expected and, if they have different needs, should be able to utilize approaches designed to meet those needs. I believe that approach is structurally and procedurally correct. But I also believe it will not help solve the issues you are trying to raise and the applications you are trying to accommodate, if only because your message, intentionally or not, is "just wait until a series of incomplete ideas, some of the barely germinated, can fully mature and be considered". That just is not a reasonable request given a number of activities, applications, and protocols that need to move forward. > The text proposed in December was not acceptable. The > currently proposed text still appears as an "industrial and > commercial Trojan Horse" with risks of commercial, political > and technical confusion. But its authors have trimmed enough > their ABNF "against me" to block "C" leaks there and threfore > a lot of confusion. Yet, we have still have no support of > non-script mode and three sources of conflicts: > > - charset of a document vs script. > - script of a document in a politically oriented > (privacy/racial violation) tag. > - lingual community information - what may imply a conflicting > language, script and charset - may conflict with langtags. Once again, if you have applications or situations in which these needs are particularly important and for which the LTRU documents do not appear responsive, either * Start work on an applicability statement or profile that will make the LTRU tagging system meet your needs for those applications. But, if you want that applicability statement discussed in the IETF, please don't waste anyone's time by discussing it before you have an Internet-Draft posted. * Ignore LTRU entirely, design your own system, and see if you can get it into the marketplace well and extensively enough to drive LTRU out, either generally or in whatever niches you think are most important. Remember that, if the LTRU is as inadequate as you believe, it will disappear on its own, with no need for you to push it along. > My proposition is: > > 1. to reduce the charset/script conflicts in defining the > Internet meaning of a script (equivalent to ccTLD IDN tables). > No big deal, since the tables are already published by Unicode. ccTLD IDN tables are, to all intents and purposes, just lists of characters bound to TLD-registry-specific names or keywords. If you really see something important and useful that needs to be done, generate an applicability statement. See above about posting I-Ds, however, and also see below about ccTLDs, ICANN, etc. > 2. to define the relation between ccTLDs and langtags > "regions" - probably one sentence to be approved by IANA, > ICANN and the ccTLD community. IANA does not make policy, and hence doesn't approve anything. If you have a specific proposal to make in this area, please make it to and at ICANN -- not an IETF problem no matter how much you might wish otherwise. > > 3. to include the IRI-tags into the Draft, through the > multilingual (numeric) "0-" hook, so we support different but > not alternative descriptions. Applicability statement and profile. See comments above. And note that, as far as I know, you are the only advocate within the IETF for the "0- hook". That is not what we normally are referring to when we talk about the evidence of strong community support needed to produce something as an IETF specification or standard. > I was opposed over ISO 11179. It seems this has changed since > the August ISO meeting. I can only rejoice. IMHO the DRS issue > is far more complex than ISO 11179 and should be addressed > separately (may be after some experience has been gained with > the IRI-langtags?) Perhaps this is a discussion you should be having with the relevant ISO TC or SC? john > > jfc > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 08 12:16:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDP2Q-0005KG-K6; Thu, 08 Sep 2005 12:14:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDP2O-0005K7-Ci; Thu, 08 Sep 2005 12:14:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00848; Thu, 8 Sep 2005 12:14:04 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDP5l-0000LV-8E; Thu, 08 Sep 2005 12:17:39 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EDP25-0003Y9-G6; Thu, 08 Sep 2005 09:13:50 -0700 Message-Id: <6.2.3.4.2.20050908104236.035d4e00@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 08 Sep 2005 18:13:38 +0200 To: John C Klensin , Sam Hartman From: r&d afrac Subject: Re: [Ltru] Re: Last call comments on LTRU registry and initialization documents In-Reply-To: References: <6.2.3.4.2.20050907112337.0475e1b0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e4e7b084ad5ab70bec6636d1707b49c1 Cc: ltru@ietf.org, iesg@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 06:39 08/09/2005, John C Klensin wrote: >Jefsey, >Somewhat against my better judgment, I want to respond to a few >of your remarks in the context of what I said and meant and what >I think the LTRU work, as a collection of IETF documents and an >IETF/IANA registry, sets out to do. Dear John, Since you ask I will respond in detail. With two liminary remarks: - what should be discussed is not what you or I may _think_ , but what this collection of proposed document may lead to or block. Technically, operationally, politically, economically, culturally. - obviously I would drop most of the points I rise here if the document became a standard proposition instead of a BCP and/or if the "0-" was supported. That position did not change of a iota since mid-december, but was improved by the IESG registration of the URI-tags RFC and by the Draft ABNF clarifications obtained at the WG-ltru. >I believe that you are getting several different issues badly >intermixed, confusing your readers and possibly even yourself. By what they address, by the exclusive they claim, the langtags are a key part of an internationalisation of the Internet. I oppose internationalisation of Internet as inadequate. It consists in permitting the use of languages by "end users" (an unknown concept to IETF), under constraints such as those described by Addison, as optional add-on to the ASCII Internet, with English as a default of these options. We technically and politically experimented what this vision leads to in the IDNA case. I support a Multilingual Internet providing a multilateral, multimodal, multitechnology convergent networking architecture for the world digital ecosystem, on an equal linguistic research, standardisation, development and usage basis. By nature that Internet is "multi" when the legacy Internet is "mono". The point is simple: "internationalisation will NOT address the multilingual demand and the further vernacularisation needs". To cope with multilingualism and with many other necessities we need to turn architectural parameters from "mono" to "multi". The single TCP/IP protocol suite, the single end to end interoperability, the single RIR addressing system, the single ICANN naming system, the single IANA clearing house, the single English language, the single ASCII set, etc. cannot deliver the expected (or already used) answers. All over embryonic "multi" are pouring (NATs, P2P, alt-roots, PADs, now mDNS and co, blackboxes, etc.) I know IAB guidance is missing. I know there is no model. I know the changes "intermix" everything. I know opposing pro status quo commercial interests are powerful. I know Governments are demanding and clumsy. I know the Internet geeks never changed technology yet. I know the Internet is nearly a billion people wide. But hiding the problem and trying to squeeze a global architectural revamp in the narrowing (patching?) of an inadequate RFC, IS confusing. The urgent need is to think hard, to understand and test in what directions a "multi-Internet" may go and to permit, document and accompany a smooth transition. Multilingualism is one of the main aspects, so it can be used for real life testing at low risk.This is what I tried: - having investigated and tested some of the trends of this evolution, in line with ICANN suggestions, and other involved leading entities. - using the WG-ltru opposition for "mono-Internet" ABNF reducing confusion risks (and possibilities) - as well described by Addison. - introducing a "multi-Internet" approach permitting a smooth transition based on a mechanism already accepted as an RFC (URI-tags - that should need to be documented as IRI-tags). >Well, I think there may be more than four "propositions", if I >understand what you intend by that term, but let me return to >that question below. Great! Why not to introduce them? are they already supported by an RFC? Anyway, they all are blocked by the Draft ABNF. Unless we use "0-", "1-" etc. for each of them? >It seems to me that the draft is nothing more or less than a way >to structure elements of several different base systems into a >very general language/ script/ location identification system. "seems" is imprecise. It is or it is not. In fact it is not. - it does not want to be "a way", but the internet standard practice. Here is the blocking point. - you know better than to say it is a "general language/script/location identification system"!. It is a very restrictive limited in scope coding system, correlating ISO codes in a way ISO has not accepted, impeaching other correlations which might be more adequate and complete, competing instead of cooperating, supporting no other modal information than an imprecise (*) script code and an inadequate "location" (**) identification. (*) ISO 15924 is only a list of one hundred codes which can be associated to a script concept. More indications on the meaning are needed. If Charset is Latin and the langtag says "Cyrl" how will the page print? (**) "location" is not the meaning of RFC 1591, the only place in the Internet documents where the concerned codes are used up to now. Jon Postel considered local internet communities' authority. This document not. Other times, other ways. >Those base systems have UN, ISO, and UTC origins. To the extent >to which you find reasons to disagree with what those bodies >have put in their standards and registries and how they have >structured those registries, it seems to me that you should be >taking it up with them, in their contexts. ??? !!! Had you followed the debate of this WG-ltru you would know I have been denied the quote of the very terms and restrictions these authorities use when publishing the used data. These data are NOT used in the way they are intended to. This does not mean that they cannot, but that an appropriate language is to be provided to document it. The WG shown that such a language might lead to technical conflicts and alight other lacks. Why not the Editor simply include the appropriate legal mentions? Why not to consider the current debate over ISO 639-4 (ISO 639 guide lines). Why not to quote and consider ISO 639-4, 5, 6 drafts, the same as this Draft is part of the ISO 639 debate and annexes. I am surprised by what could be considered as a cross-contribution loop. I am also surprised by your suggestion: would IETF documents have to be discussed at ISO? All the more than I made clear enough that I share in common interests efforts. And that I accepted to dedicate time to the lack of concern of the WG-ltru for language networking issues. I did not think appropriate to involve other people in the WG-ltru rough waters. One academic friend tried very politely - he is at the origin of the "0-" proposition. He was named a "troll". Do not be afraid if I am the one to tell the reality in here (you saw competition wants to expel me for that), I always said I represent users interests. My architectural vision is user-centric, so I cannot do otherwise. But this does not mean than I am alone :-) and only involved in here. But a job had to be done: to expose a wrong approach. This is now made. It only means that I am very respectful of the IETF ways and that I think that it is still the best entity to document the "multi-Internet". But if the IESG/IETF/IAB says "no" at the end of the day, this will obviously not stop the multilingual global NGN to develop without them. But I would be sad. >A second issue is why those particular base systems have been >chosen rather than others that would accomplish the same >purposes. While the WG has better reasons (some of which are >identified in the LTRU-registry draft), the bottom line is that >no other systems exist that are global in character, accepted >internationally by recognized bodies, and generally plausible. As I documented it, this comment is out of scope. 1. the problem is not with the use of these code, the problem is with the way they are used. 2. this problem would not be a big problem if a PS (an inadequate tagging would confuse and cost the world because of its initial sponsors, but would soon fade away). The problem is with the BCP nature of the document which leaves no choice: accept or balkanise (you document this further on). 3. I leave you the responsibility of your review of existing propositions. My opposition is only to avoid a general balkanisation. But after all, may be I am a fool and there might be some advantages. And you seem to advocate it... >You, or for that matter I, might well imagine that a >better-optimized job could be done for one or more of them if an >effort were initiated under different assumptions, but to sit >around waiting for such an effort to materialize or reach >agreement would delay the real work of internationalization that >we both believe are important. What do you mean by "to sit around waiting"? when our such effort is only delayed by the Draft time wasting. This is necessary because this is a pure _commercial_ exclusion effort. Do you think that financial aspects are not involved? I never hidden I was also supported by industrial interests fighting and fought by industrial interests. Harald Alvestrand and Peter Constable fully documented that central motivation. I will not betray some of my opponents, but no one should be fooled: this debate is worth "a lot of money for industry". This is something we all agree, we only disagree for who - some consider they lost what other consider they saved. I strongly _oppose_ this kind of interference in the IETF. This absurd attempt to commercial exclusive, on "mono-Internet" pseudo technical interest grounds, have made us all to lose a full year (except getting a cleaner ABNF for that proposition and an RFC to support the URI-tags solution). Our common target is stability, surety, security, innovation capability in supported end to end interoperability and serviced brain to brain interintelligibility whatever the person, the computer, the location, the language. This byte and language oriented pervasiveness cannot be supported by what you call "internationalisation" (I would call lower layer localisation). You say it yourself when you say that the "real work of internationalisation" is ahead. If the Draft is accepted without the "0-" hook for IRI-tags that work will be a no-starter. The proposition is painting on old rust. That we both want the painting. But believing we can keep the rust and get a proper painting is illusory and a waste of time. But, we may proceed step by step. Not remove all the rust and repaint everywhere at the same time. Let start with the IRI-langtags. Let get experience (not only for multilingualisation) and let build on it. What is the danger? If I am wrong, it will simply not fly and no commercial interest will have been hurt. But if I am right we will have protected the Internet unity. > Of course, I, and the WG, could >have missed something: if you sincerely believe that there is a >better alternative to one of those base systems -- an >alternative that exists, is global in scope, is generally >recognized by some appropriate international body, and that is >generally available-- please identify it and the reasons why you >think it is superior. I can only repeat: 1. I sincerely believe there always is a better alternative than exclusion 2. I sincerely believe that inclusiveness is by nature global in scope 3. I submit that the proven experience of a product like Words documenting more elements than the tag is to consider 4. I cannot leak IPR but I am sincerely sure that the "mono-Internet" exclusive Draft ABNF preventing "0-" is a _major_ mistake. etc. and I will always say that NO solution is superior to any others, but that specific solutions can be more appropriate in specific cases and that is dumb stupid to exclude them on short-sighted commercial grounds or technical limitations. Technical limitations are made to be addressed. >A third issue relates to the difference between breaking things >into categories in order to make lists and the codes, names, or >labels that are assigned to those categories. The making of the >lists is what the relevant based standards are all about. It is >typically a difficult task, but it is one for which IETF cannot >and should not take responsibility (as I hope I have explained >above). I am not sure about what you want to say here. This Draft is about IETF taking that kind of responsibility. Unless you intend to say the IETF delegates the ietf-languages@alvestrand.no responsibility of feeding the IANA, in an equivalent way it delegated the names and numbers responsibility to ICANN? > But the assignment of codes/ names/ labels to those >categories is largely arbitrary. There can be good reasons for >preferring one system over another, especially in the >environment of particular assumed applications (or >"propositions"), and I need to assume that the UN, ISO, and UTC >have made rational choices. I am not sure about what you wants to say here either, nor why you want to keep quoting the UTC? What are the UN and ISO to do with this? The rational is not with them, but with this Draft to use their codes for needs which were no part of their rational. Please pick ISO 639-4 draft and tell me among the examples of usage of ISO 639 where ISO 639-4 alludes to networking. Please tell me in which way the table of codes related to the name of countries may be easily correlated with human language dissemination? With human language censoring may be .... ??? > But substituting a different set of >codes doesn't change the semantics of the underlying base >system. So, if you are looking for a different set of codings/ >names --I don't think you are, but I can't be sure-- I think you >need a really clear and compelling argument for why the existing >ones are generally inappropriate and a clear and easily-realized >proposal for generating a substitute list of codes and mappings. John investigating the same erroneous issues will lead to nowhere. - this Draft does not respond an IETF Charter but pursues a business strategy - in so doing it tries to use the IESG and IANA to exclude competition - this results from reasons well identified by IAB in RFC 3869. With the very provisions discussed by IAB that such a motivations do not preclude partial good. But must be replaced by non-commercial funding. This is exactly what I am: non profit and building public projects. I happen to know better about the risks involved because that business strategy wants to commercially lock a market that (with many others of influence, this debate also helped to gather) I want to keep free for longer term common and commercial interests. The magnitude of the economical, political, technical, legal and societal involved interests and the probable consequences on the control of the Internet (due to the load on the IANA and the complexity of the involved information - and competition) is such that, should the Draft be approved without supporting the IRI-langtags space it would either be not applied (leading to delays and confusion) or be opposed in a way which would probably balkanise and disband the Internet as we know it. I only try to prevent this from happening. I may very poor at that, I would then apologise and call for help. But, opposing me if I am right is burying the Internet or transferring its control (what I believe is attempted). > > A two minutes consideration of the difference between the way > > Shakespeare wrote a page and the way you store, distribute and > > read it today, may give you some hints about the difference > > between what the Draft wants to do and what the IETF needs. > > The Draft drastically extends the basic error of the lose RFC > > 3066 (rigidifying orthogonal language/country information) and > > wants to see it enforced and made universal. > >I see no statement in the draft that would justify the claim of >wanting or expecting "enforcement". What I think I do see is a >wide range of applications that might reasonably take advantage >of some language and/or script and/or locality and/or "other >things" coding and identification system. I imagine the range >to be broader than the examples you list as "propositions". I >am quite certain, philosophically rather than analytically and >with examples, that the registration system and matching rules, >as proposed, are too specific or overspecified for some >plausible uses. I am equally certain that they are >insufficiently specific for some other uses that might be >imagined. > >But that is precisely what voluntary standards are all about. >No one I know is really trying to mandate use of the technique >specified in these documents and, if there is someone, he or she >is delusional. What are you talking about? This document is the updated of BCP 47 Internet standardized practice. >I believe that the IETF should be specific, _for >protocols and other work within IETF's scope_, about whether the >LTRU work should be used and how it should be used. If you have >other applications that could use this work, John, many people have applications this work is to prevent the use !!! I do not understand all this. Or you did not read the ABNF? No one can de facto introduce a global proposition. - either it must be part of a future revision of a document which wants to be a narrowing of RFC 3066 - or it must use subtags shorter or equal to 8 alphanum, without possibility to use "-:=?/" etc. So no URI-tags are permitted. - or it is a language, script, region it must be accepted by ietf-languages@alvestrand.no - if it is vocal, style, dictionary, contextual, cultural, etc. etc. this is not supported. >and the work is appropriate, that is great: use it with everyone's >blessings. If you have applications (or propositions) for which this work >is just wrong, then go do something else, I assume again with >everyone's blessings. I am not sure you mean by do something else? Would it be like "If someone sleeps with your wife, don't worry go do sleep with someone else?" Many do _not_ and will _not_ want to be dependent on this Draft. Period. There are only two solutions. Either the langtag can adopt formats they can tune or they will be blocked. Just understand that langtags may be more dangerous than spam or cookies. So at last users must be entitled to control them and to use them far more cleverly than the default way the Draft proposes !!! Opposing this is certainly being sure to kill a few people. We all know that. Just to support very very short sighted non realistic commercial dreams. > > A content container should at least document if the language > > description is from the author, to the reader or for the > > protocol. It should the document seven properties (language, > > mode, community, referent, context, style, media) and the > > property description version. Your own Words program just does > > that. Each of these elements may include many sub-elements. > >Ok. The LTRU group, presumably with some specific IETF >applications in mind, including (correctly or not) those >supported by RFC 3066, concluded either that the level of >specificity you ask for above was not necessary or that it was >impractical. "presumably": you are incorrect in that assumption. BTW "some specific application" would justify options. I wish some IETF applications would have been considered :-) DNS, OPES, Java, etc. have been denied to me. >For the purposes for which you presumably want >this, you have two choices, both of which appear to me, in my >ignorance, to be completely plausible. The first it to >completely forget about this IETF effort and do your own thing, >building on either the LTRU spec or the base documents that >determine the subtags as you think appropriate. No one will >stop you and, if anyone tries, I recommend that you ignore them >and get on with your work. This is what I want to prevent. This is no problem. But the name is balkanisation. Do you support it? It makes a large difference to me if we have a BCP or a PS. >The second option is to construct an applicability statement of >your own, one that specifies the applications or propositions >that are relevant, the elements of the LTRU registry you want to >use (if any), the sources of other elements and how they are >used, and so on. Whether you should try to put that >applicability statement through the IETF depends on what the >application area / proposition is all about: if the IETF is not >representative of the community you see yourself serving, or >authoritative about its needs, it seems to me that IETF >involvement would add little value and probably be very >frustrating for all concerned. I wish the IESG to decide that. I maintain that common interest is that the Internet documentation stays with the IETF. Or at least that the IETF stays as a common focal point. Obviously if the IESG decides (and IAB confirms) to exclude the "multi-Internet" starting with the Multilingual Internet, I will certainly consider your suggestion. But still with great care. Rome was not built in one day, but was burnt in one night. We should be very careful at that; The actual issue is the control of the IANA registry. There are three possibilities: 1. the IANA is an exclusive source of langtags. 2. the IANA is one of the sources of the langtags as the IRI-langtags are added to the Draft ABNF through the "0-" sequence. 3. the IANA is no more the Internet central clearing house because of the distribution of registries. In the first case, the ietf-languages@alvestrand.no mailing list will become unmanageable and the whole process will be blocked. Leading to a decision of authoritative transfer. I then support a transfer to the GAC if the WSIS has not taken over. In the second case, things will continue as per today. There will most probably a problem of overload of the IANA and legal issues over the nature of the langtags. This will only speed up the need to transition to the third solution. The third case is the eventual solution for a distributed network. It still calls for a lot of thinking, experience and work. But can be implemented rather quickly now on a test basis with multilingual priority. This however represents serious dangers due to the commercial competition and political aspects it would exacerbate. > > There are three other propositions than status-quo: > > > > A. the current Draft using of ISO 639-1, 2, 3 and additional > > ISO codes. That proposition is based upon the SIL list of 7500 > > documented languages. It is supported by Peter Constable (on > > the list), author of ISO 639-3. > >Ok. If this has appropriate applications other than those >covered by the LTRU documents, create an appropriate >applicability statement. If necessary, propose a standards >track document and appropriate IANA registry, but I would assume >that the ISO 639 registries would be sufficient. ??? This application has the e-commerce, etc. applications it is designed for. I trust Addison to know what he wants (however he documented he does represent W3C positions). > > B. Linguasphere (planned to be ISO 639-6). It identifies > > 20.000 community language 4 letters not reusable codes and is > > built as ISO 11179 compliant for far more information. They > > fully replace langtags when no legal aspect is involved. They > > are planned to be discussed when an ISO standard. It is > > supported by Debbie Garside (on the list) and Dr. David Dalby. > >See above comments about not-yet-complete proposals. If this >were to be adopted as an ISO 639 component, the comments above >would apply exactly. In the interim, unless you are prepared to >argue that 3066 is adequate, without fixing the problems that >LTRU addresses, until the above work is complete and accepted, >and adequate for _all_ IETF-related language-tagging purposes, >it seems to me that you should get out of the way of those >purposes and applications. This solution is an open source retained solution. This solution is appropriate in part to many needs. I am sorry but your "adequate for _all_IETF-related language-tagging purpose" is a "mono-Internet" de facto deprecated thinking. As far as I am concerned the Draft addresses none of the RFC 3066 lacks. It only prevents more applications to use it: this is very positive as it clarifies the situation. ISO 639-6 has as much interest for IETF as the Draft has interest for ISO 639-4. Except that ISO 639-6 reflects a common practice the Draft does not represent. SIL and Linguasphere are two widely used universally accepted lists. SIL is private and limited to a single list. Linguasphere is much more complete and ISO 11179 compliant. But they are professionally/marketingly of equivalent excellence. The reason why Linguasphere is more appealing in terms of use, is that the Draft does not uses SIL (ISO 639-3) but a progressive mix of ISO 639-1 and ISO 639-2 (the ISO scheduling of -3 and -6 are only a few months apart). The current thinking of the WG-ltru, if I understand it correctly is a confuse usage of ISO 639-6 in an appropriate way as a complement of ISO 639-1, 2, 3 and 5. It is likely that routines supporting ISO 639-6 codes in an open source manner will be available long before the Draft support of ISO 639-3 ..... > > C. the "grassroots approach". The approach is to accept in a > > network and multilingual way everything existing and to relate > > it to an "ISO 11179" compatible system. Still at basic > > thinking and experimental stage. This is part of a generalised > > DRS (distributed registries system) to include every > > network/local/user registry (including langtag). The URI-tags > > seem to fully support the network aspects, the IRI-tags the > > multilingual concept. It obviously support the two systems > > above which can be its defaults. I accepted to spend time on > > the representation of industrial, political and users > > interests in that area. > >See above about systems that are not yet complete and, from what >I understand of this work, not yet really started. ???? Do not confuse achievement and started. There are millenaries that languages have a name. The commercial attempt to standardise the printing industry and library classification is not the first, and hopefully not the last one. You probably confuse IRI-langtags which are only a documentation to internationally work - probably this falls; and the DRS work which has been engaged 2 years ago as an incorporated R&D non-profit effort involving various industrial, private, public, etc. French and foreign interests. But that work is certainly important (see end). > > There is no "better" solution. There are more adequate > > solutions in specific situations (A and B can be defaults of > > C). Each helping the other to better define itself. However > > the A proponents think their proposition must be exclusive. > > They wanted a counter-proposition of mine so the "best" might > > "win". Their ad-hominems were their way to exclude a > > "competition". Their non-technical mails on the IETF main list > > fully exposed that strategy. > >I don't think so. While I think they and I disagree about many >things, I have generally found them willing to listen and to >accept constructive input. There really is a place, in the >engineering context in which we find ourselves, for deciding >that, in the presence of a demonstrated problem, a proposal that >actually exists, and that is structured on top of base documents >that actually exist, must be accepted in preference to work that >has not yet completed and ideas that are still being formulated >-- at least for an identified set of problems and applications >for which it can be demonstrated to be the solution. We fully agree. This is why I am sad at the RFC 3869 documented motivations many see there and the RFC 3774 documented problems we feel we meet. There is a very simple way to turn us wrong on this two points: to accept the "0-" to show the intent is not a registry exclusive and that all existing propositions are considered; and to make the Draft an SP, to show there was no to intent of exclusion of other propositions. > My >proposal to recast the registry and matching documents into >Proposed Standards supplemented by one or more Applicability >Statements should make it more clear that other applications, >with their own Applicability Statements and scopes, can be >expected and, if they have different needs, should be able to >utilize approaches designed to meet those needs. > >I believe that approach is structurally and procedurally >correct. I agree. The entire issue is here. Even well commercially supported an inadequate proposition will eventually fade away. > But I also believe it will not help solve the issues >you are trying to raise and the applications you are trying to >accommodate, if only because your message, intentionally or not, >is "just wait until a series of incomplete ideas, some of the >barely germinated, can fully mature and be considered". That >just is not a reasonable request given a number of activities, >applications, and protocols that need to move forward. This is _absolutely_not_ what I have asked for !!! 1) I have documented to the contrary how existing development were ready to adapt to avoid confusion with the Draft. 2) we generalised our experience and other commercial applications we cannot discuss as not being part of them have agreed to use the existing URI-tags approved RFC. This is the end of it. Except that we will now extend to IRI-tags and have to document an extension. > > The text proposed in December was not acceptable. The > > currently proposed text still appears as an "industrial and > > commercial Trojan Horse" with risks of commercial, political > > and technical confusion. But its authors have trimmed enough > > their ABNF "against me" to block "C" leaks there and threfore > > a lot of confusion. Yet, we have still have no support of > > non-script mode and three sources of conflicts: > > > > - charset of a document vs script. > > - script of a document in a politically oriented > > (privacy/racial violation) tag. > > - lingual community information - what may imply a conflicting > > language, script and charset - may conflict with langtags. > >Once again, if you have applications or situations in which >these needs are particularly important and for which the LTRU >documents do not appear responsive, either > >* Start work on an applicability statement or profile that will >make the LTRU tagging system meet your needs for those >applications. But, if you want that applicability statement >discussed in the IETF, please don't waste anyone's time by >discussing it before you have an Internet-Draft posted. Once again. This is not what I want. I want to prevent that all those the draft is designed to prevent to do so, do it independently, rising a hell of confusion. But if you think it is better, I will consider your advise to balkanise the Internet. >* Ignore LTRU entirely, design your own system, and see if you >can get it into the marketplace well and extensively enough to >drive LTRU out, either generally or in whatever niches you think >are most important. Remember that, if the LTRU is as inadequate >as you believe, it will disappear on its own, with no need for >you to push it along. This is true. But in the meanwhile it will have caused serious harm. Also, the Draft in a serious number of case is a very interesting default, now the ABNFis clean and possible pretensions reduced. Also, I prefer good compromise now than exclusion. Love your enemies says the Gospel. > > My proposition is: > > > > 1. to reduce the charset/script conflicts in defining the > > Internet meaning of a script (equivalent to ccTLD IDN tables). > > No big deal, since the tables are already published by Unicode. > >ccTLD IDN tables are, to all intents and purposes, just lists of >characters bound to TLD-registry-specific names or keywords. If >you really see something important and useful that needs to be >done, generate an applicability statement. See above about >posting I-Ds, however, and also see below about ccTLDs, ICANN, >etc. Thank you. But, I am sorry, you do not address the technical issue. > > 2. to define the relation between ccTLDs and langtags > > "regions" - probably one sentence to be approved by IANA, > > ICANN and the ccTLD community. > >IANA does not make policy, and hence doesn't approve anything. >If you have a specific proposal to make in this area, please >make it to and at ICANN -- not an IETF problem no matter how >much you might wish otherwise. Sorry again, you do not address the technical issue. The IETF understanding of ISO 3166 is documented by RFC 1591. Not also in the Draft. > > 3. to include the IRI-tags into the Draft, through the > > multilingual (numeric) "0-" hook, so we support different but > > not alternative descriptions. > >Applicability statement and profile. See comments above. And >note that, as far as I know, you are the only advocate within >the IETF for the "0- hook? That is not what we normally are >referring to when we talk about the evidence of strong community >support needed to produce something as an IETF specification or >standard. I do not think you need to be many to support common sense propositions. But if this was needed we could. Is that so necessary? I respect the IETF enough not to play that game. But I am sure than if you consider it seriously, you would support it yourself. > > I was opposed over ISO 11179. It seems this has changed since > > the August ISO meeting. I can only rejoice. IMHO the DRS issue > > is far more complex than ISO 11179 and should be addressed > > separately (may be after some experience has been gained with > > the IRI-langtags?) > >Perhaps this is a discussion you should be having with the >relevant ISO TC or SC? ??? I have no objection that the Internet architecture is discussed at TC32 (or TC37), but I am surprised that _you_ would suggest it. Anyway do not be afraid we did not wait for the suggestion. Take care. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 11:07:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDkTs-0000vL-C9; Fri, 09 Sep 2005 11:07:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDkTr-0000vA-DR; Fri, 09 Sep 2005 11:07:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08951; Fri, 9 Sep 2005 11:07:53 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDkXR-0004ga-TW; Fri, 09 Sep 2005 11:11:39 -0400 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050909150741.YVRL24716.mta9.adelphia.net@DEWELL>; Fri, 9 Sep 2005 11:07:41 -0400 Message-ID: <013101c5b550$313fc0c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "John C Klensin" , "Sam Hartman" References: <02BD58E66D8134A92F365882@scan.jck.com> Date: Fri, 9 Sep 2005 08:07:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin wrote: > The success or failure of the "foo" registry is > not evaluated on how many foos we can put in to it, or its > comprehensiveness relative to some external foo-list, but on > whether it does the job that the foo-protocol (and maybe foo1, > foo2, etc.), requires. Normally, we don't even write a "create > the baz registry" document. Instead, we write a "baz protocol > specification" document and include a more or less long section > that instructs IANA to create the registry, what to put in it, > and how. So, do you propose that we withdraw the specification of the initial registry contents, all 963 tags and subtags, and replace it with a set of instructions to IAN on how they can duplicate our work? And cross our fingers that they get it right, or prepare to go through item-languages for any correctible errors or omissions they may introduce, and live with the uncorrectable errors? Just wondering. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 11:21:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDkh5-0003qX-EB; Fri, 09 Sep 2005 11:21:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDkh3-0003qM-Ei; Fri, 09 Sep 2005 11:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09646; Fri, 9 Sep 2005 11:21:31 -0400 (EDT) Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDkkd-00051a-UC; Fri, 09 Sep 2005 11:25:17 -0400 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050909152122.DLYF12299.mta13.adelphia.net@DEWELL>; Fri, 9 Sep 2005 11:21:22 -0400 Message-ID: <013a01c5b552$09f4a1a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "John C Klensin" , "Sam Hartman" References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> Date: Fri, 9 Sep 2005 08:20: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-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Sorry, Spell Checkers Gone Wild. > So, do you propose that we withdraw the specification of the initial > registry contents, all 963 tags and subtags, and replace it with a set > of instructions to IAN on how they can duplicate our work? And cross s/IAN/IANA/ > our fingers that they get it right, or prepare to go through > item-languages for any correctible errors or omissions they may s/Item/ietf/ s/correctible/correctable/ > introduce, and live with the uncorrectable errors? Just wondering. I don't know why my spell checker corrected "uncorrectible" to "uncorrectable" but left "correctible" uncorrected. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 11:48:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDl6f-0000nu-NM; Fri, 09 Sep 2005 11:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDl6e-0000ng-2S; Fri, 09 Sep 2005 11:48:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10803; Fri, 9 Sep 2005 11:47:56 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDlAC-0005hJ-46; Fri, 09 Sep 2005 11:51:42 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EDl6V-000JFw-2z; Fri, 09 Sep 2005 11:47:51 -0400 Date: Fri, 09 Sep 2005 11:47:50 -0400 From: John C Klensin To: Doug Ewell , Sam Hartman Message-ID: In-Reply-To: <013101c5b550$313fc0c0$030aa8c0@DEWELL> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On Friday, 09 September, 2005 08:07 -0700 Doug Ewell wrote: > John C Klensin wrote: > >> The success or failure of the "foo" registry is >> not evaluated on how many foos we can put in to it, or its >> comprehensiveness relative to some external foo-list, but on >> whether it does the job that the foo-protocol (and maybe foo1, >> foo2, etc.), requires. Normally, we don't even write a >> "create the baz registry" document. Instead, we write a "baz >> protocol specification" document and include a more or less >> long section that instructs IANA to create the registry, what >> to put in it, and how. > > So, do you propose that we withdraw the specification of the > initial registry contents, all 963 tags and subtags, and > replace it with a set of instructions to IAN on how they can > duplicate our work? And cross our fingers that they get it > right, or prepare to go through item-languages for any > correctible errors or omissions they may introduce, and live > with the uncorrectable errors? Just wondering. No, no. And I don't understand how you could read that into anything I wrote. But let me try to spell that comment out in different language, just to be sure that we both understand what I was suggesting: (i) Internet-Drafts and RFCs are different creatures. It is perfectly acceptable, indeed common, to have text in I-Ds that no one intends to see in a final RFC. (ii) The IESG can instruct IANA to form a registry and initialize it with any set of instructions that are clear enough for IANA to follow accurately. Those instructions can be in an RFC, in an I-D, in a formal IESG note to IANA, or, in principle, written on the back of an envelope. It is usually assumed that mechanisms that are public and leave tracks are better than those that don't, but even that is not a requirement. So, all I was suggesting wrt the text of the "initial" document is that, when the IESG concluded that it had reached community consensus, two things should happen: (1) The IESG instructs IANA to create the registry, populating it with the elements as instructed in the Internet-Draft and using the formats specified there and in the "registry" I-D. (2) The document is passed to the RFC Editor for publication, but with a note indicating that the 100 or so pages of subtags should be dropped and replaced by a paragraph that explains how the initial subtags, as specified by the WG process, can be identified from the registry itself. I _strongly_ prefer that the relevant paragraph be constructed and approved by the WG itself, rather than being made up by one or more IESG members; I assume the IESG would feel the same way. For whatever it is worth, this gets you a registry created on the timeframe of a protocol action, not a wait until an RFC is about to be published (it is not the only way to accomplish that, of course). It gets a RFC that is 100 or so pages shorter and that eliminates any chance of the contents of the RFC being confused with the contents of the registry itself (something that the I-D explicitly warns against). All other things being equal, a dozen-page RFC is likely to be finished and posted more quickly than a 117 page one. Since the usual practices of the RFC Editor would not permit the publication of one of these documents before the other (if you don't know/ understand why, it is worth your asking), what holds up one document, holds up both and "faster" is clearly in the interest of the WG and the community. How you get from there to "withdraw... replace ...instructions to duplicate work..." is unfathomable to me, but it certainly was not what I was suggesting. That suggestion was just about streamlining with a more efficient and appropriate way to implement what are, as far as I can tell, _exactly_ the same set of actions. Unless I've missed something, it ought to be problematic only if, somehow, the WG believes that there is "credit" for an RFC in proportion to its page count. That belief would be, AFIK, pretty novel around the IETF. john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 12:16:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlYc-00078X-QS; Fri, 09 Sep 2005 12:16:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlYb-00078G-Un; Fri, 09 Sep 2005 12:16:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12231; Fri, 9 Sep 2005 12:16:51 -0400 (EDT) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDlcC-0006Up-OI; Fri, 09 Sep 2005 12:20:38 -0400 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050909161638.EYKA27017.mta11.adelphia.net@DEWELL>; Fri, 9 Sep 2005 12:16:38 -0400 Message-ID: <01a201c5b559$9fb84e60$030aa8c0@DEWELL> From: "Doug Ewell" To: "John C Klensin" References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> Date: Fri, 9 Sep 2005 09:14:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin wrote: > (i) Internet-Drafts and RFCs are different creatures. > It is perfectly acceptable, indeed common, to have text > in I-Ds that no one intends to see in a final RFC. Understood. The WG decided that the initial-registry I-D should be an RFC, for various reasons. > So, all I was suggesting wrt the text of the "initial" document > is that, when the IESG concluded that it had reached community > consensus, two things should happen: > > (1) The IESG instructs IANA to create the registry, > populating it with the elements as instructed in the > Internet-Draft and using the formats specified there > and in the "registry" I-D. > > (2) The document is passed to the RFC Editor for > publication, but with a note indicating that the 100 or > so pages of subtags should be dropped and replaced by a > paragraph that explains how the initial subtags, as > specified by the WG process, can be identified from the > registry itself. I _strongly_ prefer that the relevant > paragraph be constructed and approved by the WG itself, > rather than being made up by one or more IESG members; I > assume the IESG would feel the same way. That makes sense to me. Other members of the WG, and in particular the chairs, have orders of magnitude more experience with this sort of thing than I do, and so I can't speak to whether it makes sense to them. > How you get from there to "withdraw... replace ...instructions > to duplicate work..." is unfathomable to me, but it certainly > was not what I was suggesting. I apparently misread this passage, which you wrote and I quoted: | Normally, we don't even write a "create | the baz registry" document. Instead, we write a "baz protocol | specification" document and include a more or less long section | that instructs IANA to create the registry, what to put in it, | and how. I am delighted that my interpretation was wrong. > Unless I've missed > something, it ought to be problematic only if, somehow, the WG > believes that there is "credit" for an RFC in proportion to its > page count. That belief would be, AFIK, pretty novel around the > IETF. That was definitely not my intent, nor that of anyone else in the WG. Indeed, I pointed out that if LTRU is ever revised to incorporate subtags based on ISO 639-3 codes, the additional registry information would occupy 740 pages, and suggested that this amount of material might be inappropriate to publish as an RFC or even an I-D. A 118-page draft consisting almost entirely of a code list certainly shouldn't impress anyone by its length, any more than a 1,000-page phone book. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 12:17:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlZ7-0007Ro-I0; Fri, 09 Sep 2005 12:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlZ6-0007R3-0I for ltru@megatron.ietf.org; Fri, 09 Sep 2005 12:17:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12297 for ; Fri, 9 Sep 2005 12:17:21 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDlcg-0006Va-VO for ltru@ietf.org; Fri, 09 Sep 2005 12:21:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 09:17:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments Date: Fri, 9 Sep 2005 09:17:02 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CC4913C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments Thread-Index: AcW1UJMDQAFlpY3gRsWie2vzayLNTwACGziQ From: "Addison Phillips" To: "Doug Ewell" X-OriginalArrivalTime: 09 Sep 2005 16:17:03.0736 (UTC) FILETIME=[EA49F780:01C5B559] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1122988148==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1122988148== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QWN0dWFsbHksIEkgYmVsaWV2ZSBoZSBzdWdnZXN0ZWQgdGhhdCBJQU5BIGdldCB0aGUgbWF0ZXJp YWwgZnJvbSB0aGUgZHJhZnQgYW5kIHRoZW4gdGhlIFJGQyBFZGl0b3IgcmVtb3ZlIHRoZSAiYmVl ZiIgKHRoZSByZWdpc3RyeSBjb3B5KSBhbmQgaW5zZXJ0IHRoZSB0ZXh0IGhlIHByb3Bvc2VkLiBO b3QgeW91OiB0aGUgUkZDIEVkaXRvciwgKmFmdGVyKiBJQU5BIGhhcyBnb3QgdGhlIHJlZ2lzdHJ5 Lg0KDQpUaGlzIHRocmVhZCBzdHJpa2VzIG1lIGFzIGlycmVsZXZhbnQuIFdlIGhhdmUgYSBwcm90 b3R5cGUgcmVnaXN0cnksIHdoaWNoIGlzIGEgbmVjZXNzYXJ5IGRlbGl2ZXJhYmxlLiBXaGF0IHRo ZSBSRkMgRWRpdG9yIGRvZXMgbGF0ZXIgaXMgbm90IG91ciBwcm9ibGVtOiB3ZSdsbCBiZSBsb29r aW5nIGF0IHRoZSBJQU5BIHJlZ2lzdHJ5IGJ5IHRoZW4uDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQ LiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFp ciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5h dGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiAN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBEb3Vn IEV3ZWxsDQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDA5LCAyMDA1IDg6MDcgQU0NCj4gVG86 IEpvaG4gQyBLbGVuc2luOyBTYW0gSGFydG1hbg0KPiBDYzogbHRydUBpZXRmLm9yZzsgaWVzZ0Bp ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbTHRydV0gUmU6IExhc3QgY2FsbCBj b21tZW50cyBvbiBMVFJVIHJlZ2lzdHJ5IGFuZA0KPiBpbml0aWFsaXphdGlvbmRvY3VtZW50cw0K PiANCj4gSm9obiBDIEtsZW5zaW4gPGpvaG4gZGFzaCBpZXRmIGF0IGpjayBkb3QgY29tPiB3cm90 ZToNCj4gDQo+ID4gVGhlIHN1Y2Nlc3Mgb3IgZmFpbHVyZSBvZiB0aGUgImZvbyIgcmVnaXN0cnkg aXMNCj4gPiBub3QgZXZhbHVhdGVkIG9uIGhvdyBtYW55IGZvb3Mgd2UgY2FuIHB1dCBpbiB0byBp dCwgb3IgaXRzDQo+ID4gY29tcHJlaGVuc2l2ZW5lc3MgcmVsYXRpdmUgdG8gc29tZSBleHRlcm5h bCBmb28tbGlzdCwgYnV0IG9uDQo+ID4gd2hldGhlciBpdCBkb2VzIHRoZSBqb2IgdGhhdCB0aGUg Zm9vLXByb3RvY29sIChhbmQgbWF5YmUgZm9vMSwNCj4gPiBmb28yLCBldGMuKSwgcmVxdWlyZXMu ICBOb3JtYWxseSwgd2UgZG9uJ3QgZXZlbiB3cml0ZSBhICJjcmVhdGUNCj4gPiB0aGUgYmF6IHJl Z2lzdHJ5IiBkb2N1bWVudC4gIEluc3RlYWQsIHdlIHdyaXRlIGEgImJheiBwcm90b2NvbA0KPiA+ IHNwZWNpZmljYXRpb24iIGRvY3VtZW50IGFuZCBpbmNsdWRlIGEgbW9yZSBvciBsZXNzIGxvbmcg c2VjdGlvbg0KPiA+IHRoYXQgaW5zdHJ1Y3RzIElBTkEgdG8gY3JlYXRlIHRoZSByZWdpc3RyeSwg d2hhdCB0byBwdXQgaW4gaXQsDQo+ID4gYW5kIGhvdy4NCj4gDQo+IFNvLCBkbyB5b3UgcHJvcG9z ZSB0aGF0IHdlIHdpdGhkcmF3IHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsDQo+IHJl Z2lzdHJ5IGNvbnRlbnRzLCBhbGwgOTYzIHRhZ3MgYW5kIHN1YnRhZ3MsIGFuZCByZXBsYWNlIGl0 IHdpdGggYSBzZXQNCj4gb2YgaW5zdHJ1Y3Rpb25zIHRvIElBTiBvbiBob3cgdGhleSBjYW4gZHVw bGljYXRlIG91ciB3b3JrPyAgQW5kIGNyb3NzDQo+IG91ciBmaW5nZXJzIHRoYXQgdGhleSBnZXQg aXQgcmlnaHQsIG9yIHByZXBhcmUgdG8gZ28gdGhyb3VnaA0KPiBpdGVtLWxhbmd1YWdlcyBmb3Ig YW55IGNvcnJlY3RpYmxlIGVycm9ycyBvciBvbWlzc2lvbnMgdGhleSBtYXkNCj4gaW50cm9kdWNl LCBhbmQgbGl2ZSB3aXRoIHRoZSB1bmNvcnJlY3RhYmxlIGVycm9ycz8gIEp1c3Qgd29uZGVyaW5n Lg0KPiANCj4gLS0NCj4gRG91ZyBFd2VsbA0KPiBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gaHR0 cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlz dA0KPiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2x0cnUNCg0K --===============1122988148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1122988148==-- From ltru-bounces@ietf.org Fri Sep 09 12:32:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlnM-0002u0-4d; Fri, 09 Sep 2005 12:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlnL-0002ts-Dv; Fri, 09 Sep 2005 12:32:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13015; Fri, 9 Sep 2005 12:32:04 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDlqv-0006rw-O9; Fri, 09 Sep 2005 12:35:52 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EDln3-0006ne-Ry; Fri, 09 Sep 2005 09:31:50 -0700 Message-Id: <6.2.3.4.2.20050909171544.03e925e0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 09 Sep 2005 18:31:47 +0200 To: "Doug Ewell" , "John C Klensin" , "Sam Hartman" From: r&d afrac In-Reply-To: <013101c5b550$313fc0c0$030aa8c0@DEWELL> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@ietf.org, iesg@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The problem with your Draft is that you do not include the 3 letters version of the 2 letter version as a correlative information between ISO 639-2 and ISO 639-3 tables. I do not think should be left to the Editor. Otherwise your Draft seems no problem. But I suppose that IESG would need a formal OK from Michael Everson since he is charge of ietf-languages@alvestrand.no. jfc At 17:07 09/09/2005, Doug Ewell wrote: >John C Klensin wrote: > > > The success or failure of the "foo" registry is > > not evaluated on how many foos we can put in to it, or its > > comprehensiveness relative to some external foo-list, but on > > whether it does the job that the foo-protocol (and maybe foo1, > > foo2, etc.), requires. Normally, we don't even write a "create > > the baz registry" document. Instead, we write a "baz protocol > > specification" document and include a more or less long section > > that instructs IANA to create the registry, what to put in it, > > and how. > >So, do you propose that we withdraw the specification of the initial >registry contents, all 963 tags and subtags, and replace it with a set >of instructions to IAN on how they can duplicate our work? And cross >our fingers that they get it right, or prepare to go through >item-languages for any correctible errors or omissions they may >introduce, and live with the uncorrectable errors? Just wondering. > >-- >Doug Ewell >Fullerton, California >http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 12:42:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlxN-0004xl-HB; Fri, 09 Sep 2005 12:42:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlxM-0004xa-5r; Fri, 09 Sep 2005 12:42:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13336; Fri, 9 Sep 2005 12:42:25 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDm0x-00074V-HZ; Fri, 09 Sep 2005 12:46:12 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 09:42:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Last call comments on LTRU registry and initialization documents Date: Fri, 9 Sep 2005 09:42:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CC49168@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Last call comments on LTRU registry and initialization documents Thread-Index: AcW1XC0T8y5gnWkKTnif3FHxqBpwrAAABeHQ From: "Addison Phillips" To: "r&d afrac" X-OriginalArrivalTime: 09 Sep 2005 16:42:17.0882 (UTC) FILETIME=[70CA4FA0:01C5B55D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org, iesg@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The draft does not include any of the overlapping codes on purpose. This = is conformant with both RFC 3066 Section 2.2 and draft-registry Section = 2.2.1, which both mandate that, where ISO 639-1 (alpha2) and ISO 639-2 = (alpha3) codes exist, only the ISO 639-1 codes be used. The registry = contains only subtags that are valid in language tags. I know I'm going to regret asking, but why would the IESG need approval = from Michael Everson to tell IANA to publish a registry? They appoint = him, after all. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > r&d afrac > Sent: Friday, September 09, 2005 9:32 AM > To: Doug Ewell; John C Klensin; Sam Hartman > Cc: ltru@ietf.org; iesg@ietf.org > Subject: [Ltru] Re: Last call comments on LTRU registry and = initialization > documents >=20 > The problem with your Draft is that you do not include the 3 letters > version of the 2 letter version as a correlative information between > ISO 639-2 and ISO 639-3 tables. I do not think should be left to the > Editor. Otherwise your Draft seems no problem. But I suppose that > IESG would need a formal OK from Michael Everson since he is charge > of ietf-languages@alvestrand.no. > jfc >=20 > At 17:07 09/09/2005, Doug Ewell wrote: > >John C Klensin wrote: > > > > > The success or failure of the "foo" registry is > > > not evaluated on how many foos we can put in to it, or its > > > comprehensiveness relative to some external foo-list, but on > > > whether it does the job that the foo-protocol (and maybe foo1, > > > foo2, etc.), requires. Normally, we don't even write a "create > > > the baz registry" document. Instead, we write a "baz protocol > > > specification" document and include a more or less long section > > > that instructs IANA to create the registry, what to put in it, > > > and how. > > > >So, do you propose that we withdraw the specification of the initial > >registry contents, all 963 tags and subtags, and replace it with a = set > >of instructions to IAN on how they can duplicate our work? And cross > >our fingers that they get it right, or prepare to go through > >item-languages for any correctible errors or omissions they may > >introduce, and live with the uncorrectable errors? Just wondering. > > > >-- > >Doug Ewell > >Fullerton, California > >http://users.adelphia.net/~dewell/ > > > > > > > >_______________________________________________ > >Ietf mailing list > >Ietf@ietf.org > >https://www1.ietf.org/mailman/listinfo/ietf >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 12:51:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDm6P-0006a9-Pd; Fri, 09 Sep 2005 12:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDm6O-0006Zw-Ru; Fri, 09 Sep 2005 12:51:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14202; Fri, 9 Sep 2005 12:51:45 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDm9y-0007QF-67; Fri, 09 Sep 2005 12:55:33 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Sep 2005 09:51:36 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Sep 2005 09:51:35 -0700 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 Subject: RE: [Ltru] Re: Last call comments on LTRU registry and initialization documents Date: Fri, 9 Sep 2005 09:51:32 -0700 Message-ID: Thread-Topic: [Ltru] Re: Last call comments on LTRU registry and initialization documents thread-index: AcW1XC7Bbi6sJ3ztS8+/VlKB7AgTVgAAeipw From: "Peter Constable" To: , X-OriginalArrivalTime: 09 Sep 2005 16:51:35.0616 (UTC) FILETIME=[BD39C400:01C5B55E] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of r&d afrac > The problem with your Draft is that you do not include the 3 letters > version of the 2 letter version as a correlative information between > ISO 639-2 and ISO 639-3 tables. I do not think should be left to the > Editor. I think it is out of scope for this registry to document equivalences between alternate standardized codes, whether that be equivalences between the 639-1 alpha-2 code and the 639-2 alpha-3 code, the 3166-1 alpha-2 code and the 3166-1 alpha-3 code, or whatever. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 14:17:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDnOu-0003ac-5H; Fri, 09 Sep 2005 14:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDnOr-0003ZY-2D; Fri, 09 Sep 2005 14:14:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20126; Fri, 9 Sep 2005 14:14:55 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDnST-0001ot-4e; Fri, 09 Sep 2005 14:18:42 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EDnOj-000Jio-VK; Fri, 09 Sep 2005 14:14:50 -0400 Date: Fri, 09 Sep 2005 14:14:49 -0400 From: John C Klensin To: Addison Phillips , iesg@ietf.org Subject: RE: [Ltru] Last call comments on LTRU registry and initialization documents Message-ID: In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB444CF@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0CB444CF@irvmbxw01.q uest.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On Wednesday, 07 September, 2005 12:19 -0700 Addison Phillips wrote: >> Comments on draft-ietf-ltru-registry and >> draft-ietf-ltru-initial and, secondarily, on >> draft-ietf-ltru-matching... > > I've thought a lot about the excellent analysis and comments > in John Klensin's message. My perception is that we have a > divergent view of the structure and significance of the LTRU > draft(s). First, my thanks for the obviously careful reading and thought. We may indeed have divergent views, although, after reading your notes I believe that, in practical terms, we are pretty close together. > Although superficially the drafts are very different than the > RFC 3066 that they seek to replace, in fact the structure is > very similar. The drafts are attempting to fill certain gaps > unaddressed by RFC 3066 for implementers or for tag choice by > and the requirements on "content authors" (people who choose > tags or ranges). > > Here are my basic thoughts in response to those comments: > > 1. All tags valid under the drafts would have been valid or > valid to register under RFC 3066. This is a key point. The tag > grammar proposed is intended to be highly compatible not just > with RFC 3066 but also with existing implementation. It is > expressed as greater restriction on what may be registered. > This provides more regularity in tags, although tags > themselves are not greatly changed. A subtag registry is, in > effect, a different way of expressing what is already in > place. I understand this, and think I understood it before. There is a difference, however, and its expresses itself, I believe, in two ways. (i) The 3066 model requires some process for every tag that is to be used. That is very bad in some ways, as the documents and your notes correctly point out. On the other hand, it tends to keep the number of tags that are in use down. Given more general IETF experience --which may not be applicable to this particular situation -- a smaller number of tags in uses tends toward better and more widespread interoperability. (ii) The idea of using a registry of components (in this case subtags) that can be mixed and matched at the implementer's discretion, albeit according to specific rules, is somewhat untested in the IETF and the Internet applications community. The closest equivalents involve protocols with a small set of options that are presumed to be orthogonal. In those cases, we typically apply rather strict rules to be sure that each of the possible combinations are tested and shown to interoperate; combinations that are not or cannot be demonstrated to interoperate are dropped from the standard at higher maturity levels. Clearly, that level of testing is not possible or appropriate here, but that level of innovation does justify requiring some operational demonstration of impact on interoperabilty, rather than stamping "BCP" on the document and hoping that everything will work out. > 2. The fact that it *always* narrows the potential subtags > that could be registered *in the future*, but has no effect on > any tags or subtags already extant means that (from an RFC > 3066 implementation perspective) the range of tags actually > seen in the wild will be more limited than it might have been. > Commentators on this thread have implied that it is an > entirely new protocol, but I think that goes too far: it is > the same protocol with greater rigor on what may go where. While I completely agree with your final sentence, it is possible to reach a different conclusion (or, more accurately, pose a different hypothesis) about the first. One could equally claim that the discretion accorded the tag reviewer, working with the IANA and under IESG supervision, would keep the number of tags registered, and hence in the wild, lower in practice than the number permitted as the crossproduct of subtag registrations. I am aware of the flaws in that argument, including a tradition "if you can't get it registered easily enough, just use what you want" in other parts of the community. As a trivial and silly counterexample to the "fewer actual tags in use" hypothesis, I would expect any competent reviewer under 3066 to look askance at a request to register en-Hang or en-Hant while, as I understand it, the fact that the three subtage "en", "Hang", and "Hant" appear in the registry makes those combinations valid under the LTRU model. What would prevent their appearance in the wild is that it would take someone who was either stupid or perverse to want to use them (casual readers, see the Aside below -- Addison clearly does not need it). But "stupid or perverse" is not a rarity around the Internet. Moreover, someone who was seriously security-paranoid might wonder whether these perverse combinations could be a way to code (not cypher, but code) secret/private messages. It seems to me that the risk there, while small, is greater than in 3066 and it is not called out in the security analysis (not that I'm sure it should be: as Sam and Russ are painfully aware, I'm very concerned about stopping rules in requirements for threat analyses and presentations). Aside on the example above (LTRU participants can skip unless they want to check my logic): "en-Hang" and "en-Hant" would imply writing English in Korean Hangul or Traditional Chinese characters respectively. In addition to those not exactly being common cases, it is not clear that they are feasible. Since most Chinese characters cannot be used in an unambiguous phonetic way, one would presumably need a rather specific profile, presumably expressed as a variant or extension, to make things work (and even then, it would be strange). Hangul is problematic in a different way. Unlike Chinese characters, it is definitely phonetic. But because it is rather carefully designed and structured around the needs of Korean, it is not clear to me, in my ignorance, that it could be used to represent the full range of English phonemes and syllables with reasonable accuracy. Contrast these two examples with, e.g., en-Cryl (English written in Cyrillic characters) or en-Arab (English written in Arabic characters). Those might be strange or even perverse, and they might be used to conceal the content of text from a casual reader/observer, but they would "work" perfectly well if read out loud, using conventions no more extreme (and probably less so) than some alternate spelling systems that use Roman-based characters but whose advocates claim are more consistent and easier than the normal spelling patterns. > 3. The various rules and guidelines set down in the draft > provide a more rigorous registration process based on the > experience of operating ietf-languages for the seven or so > years. This could be seen to make it the "best current > practice" for registering language tags or their components. > The switch to subtags was chosen to spare the community > immense numbers of registrations of various subtag variations > (examples from the current registry: two German orthographic > subtags, eight registrations; two Chinese script subtags, > *twelve* registrations). In case I haven't made it clear enough in previous notes, I _like_ this system and the ideas behind it. I think "Suppress-script" is a particularly nice idea given the weaknesses we agree are present in the 3066 model. I just think we need to move with caution into somewhat uncharted territory, doing so in a way that permits and encourages us to apply more specific guidance for particular applications than the general guidance of Section 4 of "Registry" (not that I find anything in that section to disagree with). > 4. The creation of a registry simplifies the work incumbent on > implementers or content authors, since they no longer have to > refer to (under RFC 3066) four separate tag-or-subtag > repositories and then synthesize the rules in RFC 3066 for > choosing between certain overlapping subtags (for example ISO > 639-1/-2). The fact that there is a registry doesn't change > the fact that "somewhere" there is a list of subtags that may > be validly combined into tags. See above. > 5. There is a perfectly good matching scheme loosely described > in RFC 3066. This scheme is enshrined in numerous places, > including RFC 3282 (which, you'll note, also "Obsoletes: > 1766", an example with 3066 of two RFCs obsolescing the same > BCP on separate days over a year apart). The additional forms > of matching described by the matching draft are interesting > and may be useful in a variety of applications (draft-matching > gives some examples). But they are unnecessary to the specific > task of updating RFC 3066. Applications of language tags in > the future may wish to choose one or another of the other > schemes from draft-matching to produce more interesting > results. But such additional schemes are not necessary to the > task of updating RFC 3066. > > If the community feels that matching is so important that > draft-registry must deal with it directly, my suggestion would > be to take Section 2.5 verbatim from RFC 3066 and include it > in draft-registry. This preserves the vital reference to > language-ranges. It should be noted that RFC 3066 nowhere > provides an explicit treatise on matching. Both it and > draft-registry were written for compatibility with known > matching schemes. Success or failure of the draft should > necessarily be measured by its interoperability with existing > matching protocols. My belief is that there is high > interoperability, since the matching scheme is quite basic and > the rules governing tag choice gave careful consideration to > the problem of script subtags. My personal bias about how to do this, based on IETF experience and some idiosyncrasies of the RFC series (notably the exceeding bluntness of the "Updates" and "Obsoletes" instruments), is to tell applications that they need to pick (i) the registry, as defined by an RFC and an IANA entity. I'd hope there would be only one, but Sam's suggestion may have some value, (ii) a matching rule, as defined by an appropriate RFC or text in the RFC defining/specifying the application, and optionally, (iii) some application-specific additional rules or constraints, specified in the RFC defining/specifying the application. Now, if we were having this discussion in, e.g., a JTC1 context, I'd probably have a different bias. But, in the IETF/RFC one, I'm led to believe that "separate matching rule documents" makes (ii) much cleaner than having it be "...by an appropriate RFC, or Section XY of [ltru-registry], or text in the RFC ...". I'm especially drawn in that direction because I'm not enamored of the 3066 matching rules and would prefer that it not become a permanent default. And RFC numbers are not a scarce resource. But, all of that said, the ultimate semantics of "extra section of LTRU-registry that specifies the 3066 matching rules" are the same as those of "extra RFC that makes the 3066 matching rules explicit". The essence of my earlier comment was only that this was a loose end that needed tying off if one wanted to claim that 3066 was obsolete. That requirement would be satisfied by either of these semantically-equivalent approaches. Which one to pick is, IMO, a strategic decision to be made in the context of the broad needs and practices of the IETF, and hence by the IESG with whatever mechanism it chooses to obtain community input, rather than by a single WG. > 6. The tag forms used in the draft are, in fact, being > registered and adopted. I note that Google this morning > returns 41,600 hits for "zh-Hant" as a piece of content. Many > of these appear to be valid usages as language tags---script > subtags in the wild--rather than just mentions of the > registration. Thus the draft merely recognizes the "reality on > the ground" with regard to language tags. It does so by > reorganizing how tags are registered to make the scheme more > manageable. This is great. But all it means today is that, were this on the standards track, it would be pretty easy to get it to Draft under the general criteria that Sam and I have outlined. > 7. The choice between STD and BCP tracks is really a toss-up. > There are very good arguments on both sides. The creation and > management of a registry does not lend itself to STD, but the > creation and testing of implementations does not lend itself > to BCP. My thought here is that one can view the draft > entirely through the lens of existing RFC 3066 implementers: > these documents represent a set of BCPs related to various > aspects of registering, choosing, and implementing language > tags. New implementations may be different as a result of the > improvements made (certain kinds of assumptions can be made > about a 3066bis tag that cannot be made about a 3066 tag). All > such implementations will be recognizably implementations of > RFC 3066, though, and to the benefit of all concerned (IMHO) > they represent the best current thinking on the manner in > which to identify languages on the Internet (given our legacy > considerations). We agree about the "toss-up" part. It is also true that LTRU was told to develop a BCP and responded by recommending a BCP. No one can blame the WG for following those instructions. I come down on the standards track side because of two things. First, as I have noted before, we rarely create registries as an end in themselves. The second issue is a more basic property of the IETF: while we describe our decision process in terms of "rough consensus and running code", I have come to realize that there should be a background chant of "interoperability, interoperability, interoperability" every time it is said. An interoperability lens causes me to consider 3066 to have been a marginal case for BCP and the LTRU documents to be over some "I know it when I see it" line. As I indicated in my recent note to Doug, none of my suggestions or comments require, or even suggest, any fundamental changes to the recommendations of the WG or, for the most part, even to its documents. They mostly have to do with procedures, processing models, and a bit of loose-end-tying-up, but those are issues at a rather different level. regards, john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 15:28:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDoYT-0006LF-RB; Fri, 09 Sep 2005 15:28:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDoYR-0006JG-Lx for ltru@megatron.ietf.org; Fri, 09 Sep 2005 15:28:56 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25637 for ; Fri, 9 Sep 2005 15:28:53 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EDoWn-0003Pa-3r for ltru@lists.ietf.org; Fri, 09 Sep 2005 21:27:13 +0200 Received: from c-180-161-41.hh.dial.de.ignite.net ([62.180.161.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 21:27:13 +0200 Received: from nobody by c-180-161-41.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 21:27:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 09 Sep 2005 21:25:55 +0200 Organization: Lines: 7 Message-ID: <4321E1C3.AEB@xyzzy.claranet.de> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> <013a01c5b552$09f4a1a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-41.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > don't know why my spell checker corrected "uncorrectible" > to "uncorrectable" but left "correctible" uncorrected. Did you test en-AQ-1996 ? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 16:16:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDpGw-0005YZ-Lx; Fri, 09 Sep 2005 16:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDpGu-0005YF-4o for ltru@megatron.ietf.org; Fri, 09 Sep 2005 16:14:52 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03486 for ; Fri, 9 Sep 2005 16:14:49 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EDpDp-000638-Ow for ltru@lists.ietf.org; Fri, 09 Sep 2005 22:11:41 +0200 Received: from c-180-161-41.hh.dial.de.ignite.net ([62.180.161.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 22:11:41 +0200 Received: from nobody by c-180-161-41.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 22:11:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 09 Sep 2005 22:07:11 +0200 Organization: Lines: 61 Message-ID: <4321EB6F.1571@xyzzy.claranet.de> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-41.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin wrote: > (i) Internet-Drafts and RFCs are different creatures. > It is perfectly acceptable, indeed common, to have text > in I-Ds that no one intends to see in a final RFC. I-D not intended to be an RFC was clear, but we missed the critical "text *_in_* an I-D" trick / how-to / option... > (ii) The IESG can instruct IANA to form a registry ...in conjunction with this shortcut. > Those instructions can be in an RFC, in an I-D, in a formal > IESG note to IANA, or, in principle, written on the > back of an envelope. Okay, that's better - at least for the future 3066ter with several thousands of ISO 639-3 language subtags. > The document is passed to the RFC Editor for publication, > but with a note indicating that the 100 or so pages of > subtags should be dropped and replaced by a paragraph that > explains how the initial subtags, as specified by the WG > process, can be identified from the registry itself. Makes sense, and that text could be "informational". > I _strongly_ prefer that the relevant paragraph be > constructed and approved by the WG itself, rather than > being made up by one or more IESG members; I assume the > IESG would feel the same way. You obviously have a working "threat analysis" for these procedural details, where the threats cover hypothetical cases like "IESG screws up" or "somebody cries 'appeal'" ;-) > a RFC that is 100 or so pages shorter and that eliminates > any chance of the contents of the RFC being confused with > the contents of the registry itself (something that the > I-D explicitly warns against). Okay, I knew that it's possible to have notes to the RfC- editor in an I-D (e.g. instructions to remove the document history), but I didn't know that it's also possible to have similar notes _to_ the IESG (unlike _from_ the IESG). > unfathomable to me Authors feel like fathers, easily upset if you'd propose to "do" something with their baby that's strictly impossible ;-) > if, somehow, the WG believes that there is "credit" for an > RFC in proportion to its page count. That belief would be, > AFIK, pretty novel around the IETF. It's far too short for the Guiness book as the longest RfC, so that wasn't our intention. RfC 2801 could be the record. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 17:05:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDq3f-00067k-SX; Fri, 09 Sep 2005 17:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDq3e-000679-1y for ltru@megatron.ietf.org; Fri, 09 Sep 2005 17:05:14 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09845 for ; Fri, 9 Sep 2005 17:05:10 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EDq3M-00022H-4O for ltru@lists.ietf.org; Fri, 09 Sep 2005 23:04:56 +0200 Received: from c-180-161-41.hh.dial.de.ignite.net ([62.180.161.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 23:04:56 +0200 Received: from nobody by c-180-161-41.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 23:04:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 09 Sep 2005 23:01:56 +0200 Organization: Lines: 26 Message-ID: <4321F844.6DA1@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CC4913C@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-41.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > This thread strikes me as irrelevant. Minimally it's one working model for 3066ter. > What the RFC Editor does later is not our problem I'm not sure about that. If we adopt John's proposal chapter 3 in "initial" could be moved to an appendix A, with a note to replace it before publication (= after the creation of the registry) by "X", where "X" is essentially the URL of the registry. > we'll be looking at the IANA registry by then. In theory. In practice what I have on my box as path I:\DOKU\RFC\*.txt is a CD ROM with RfCs and similar texts up to RfC 3195. With John's proposal we'd be sure that the initial registry doesn't make it into any "RfC collections" reflecting a then obsolete state of the real thing. IMO John's procedural idea is better. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 17:09:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDq7f-0007QH-4d; Fri, 09 Sep 2005 17:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDq7b-0007Lk-7w for ltru@megatron.ietf.org; Fri, 09 Sep 2005 17:09:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10008 for ; Fri, 9 Sep 2005 17:09:16 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDqBC-0001YE-U0 for ltru@ietf.org; Fri, 09 Sep 2005 17:13:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 14:08:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments Date: Fri, 9 Sep 2005 14:08:58 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CC4936E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments Thread-Index: AcW1gkQ6Kj1ADqcZTjKGhIHPwSRzSwAAEGUg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 09 Sep 2005 21:08:58.0535 (UTC) FILETIME=[B1EC3370:01C5B582] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > IMO John's procedural idea is better. I agree. I was merely trying to make the point that Doug need not = rewrite his draft. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 17:15:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDqDm-00018R-Ch; Fri, 09 Sep 2005 17:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDqDi-00017Z-7j; Fri, 09 Sep 2005 17:15:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10397; Fri, 9 Sep 2005 17:15:35 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDqHL-0001kj-R6; Fri, 09 Sep 2005 17:19:25 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 14:15:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call comments on LTRU registry and initialization documents Date: Fri, 9 Sep 2005 14:15:26 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CC49377@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last call comments on LTRU registry and initialization documents Thread-Index: AcW1amLrqkkcnJLySOKVf3n7VeC5AAACu/wg From: "Addison Phillips" To: "John C Klensin" , X-OriginalArrivalTime: 09 Sep 2005 21:15:26.0719 (UTC) FILETIME=[994C60F0:01C5B583] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi John, Thanks for your note back. First I'll respond to a trivial item and = then, separately, to the STD/BCP question. You wrote: > (ii) > The idea of using a registry of components (in this case > subtags) that can be mixed and matched at the implementer's > discretion, albeit according to specific rules, is somewhat > untested in the IETF and the Internet applications community. Perhaps true in most respects, but not with regard to RFC 3066! RFC 3066 allows specific tag registration, yes, but it also includes a = generative syntax (albeit not identified formally as such). Thus the concern you have about people doing subtag mix-and-match = already exists in RFC 3066 (as I'm sure you're aware) and the community = has ample experience with that. Here are some perfectly valid RFC 3066 = tags that are silly or at least dubious and also not registered: tlh-AQ (Klingon as used in the Antarctic) it-SG (Italian as used in Singapore) zh-CO (Chinese as used in Columbia) ang-TL (Old English as used in Timor Leste) cs-CS (Czech as used in Serbia and Montenegro) So... RFC 3066 has already tested the idea thoroughly and we are just = dancing in the margins (he says, squinting VERY hard to ignore obvious = questions of order of magnitude).=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 17:53:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDqo0-0002OX-95; Fri, 09 Sep 2005 17:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDqnz-0002OS-86 for ltru@megatron.ietf.org; Fri, 09 Sep 2005 17:53:07 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11759 for ; Fri, 9 Sep 2005 17:53:04 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050909215235.ZFJX12299.mta13.adelphia.net@DEWELL> for ; Fri, 9 Sep 2005 17:52:35 -0400 Message-ID: <023201c5b588$858cbce0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 9 Sep 2005 14:50:39 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Last call comments on LTRU registry and initialization documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> don't know why my spell checker corrected "uncorrectible" >> to "uncorrectable" but left "correctible" uncorrected. > > Did you test en-AQ-1996 ? My spell checker said: Huh? My RFC 3066bis tag validator said: Well-formed: (green light) Tag is well-formed Valid: (yellow light) Tag is valid but contains non-preferred subtags or non-recommended combinations Subtag 1: en Language subtag: English (registered 2005-08-16) Subtag 2: AQ Region subtag: Antarctica (registered 2005-08-16) Subtag 3: 1996 Variant subtag: German orthography of 1996 (registered 2005-08-16) Recommended prefix is de Or course, the dates are wrong because nothing is truly "registered" yet. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 18:47:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDreX-0007cu-QS; Fri, 09 Sep 2005 18:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDreW-0007ce-Aw; Fri, 09 Sep 2005 18:47:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15028; Fri, 9 Sep 2005 18:47:21 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDri9-0003hx-Mk; Fri, 09 Sep 2005 18:51:12 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Sep 2005 15:47:10 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Sep 2005 15:47:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call comments on LTRU registry andinitialization documents Date: Fri, 9 Sep 2005 15:47:08 -0700 Message-ID: Thread-Topic: [Ltru] Last call comments on LTRU registry andinitialization documents thread-index: AcW1aqJnWJ6b5W75RlK3kD5u7bZDYwAJDT0Q From: "Peter Constable" To: , , X-OriginalArrivalTime: 09 Sep 2005 22:47:10.0057 (UTC) FILETIME=[698B1D90:01C5B590] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of John C > Klensin > Aside on the example above (LTRU participants can skip > unless they want to check my logic): "en-Hang" and > "en-Hant" would imply writing English in Korean Hangul > or Traditional Chinese characters respectively. In > addition to those not exactly being common cases, it is > not clear that they are feasible... > Hangul is problematic in a different way. > Unlike Chinese characters, it is definitely phonetic. > But because it is rather carefully designed and > structured around the needs of Korean, it is not clear > to me, in my ignorance, that it could be used to > represent the full range of English phonemes and > syllables with reasonable accuracy. Actually, that's not quite true. There are Korean linguists who have = promoted the idea that Hangul script can be adapted for use for general = phonemic transcription of languages. Thus, it is plausible that a user = might have English data written with Hangul script. This really is no different from the da-CO kinds of examples: they are = not particularly useful because there is no actual variant of the given = language associated with the given country, but only coincidentally, and = in principle the state of affairs in human demographics could well = change such as such a variant does actually exist. Just as there is no = limit to what region a given language can be spoken by a significant = population (given sufficient mobility), in principle there is no limit = to what script can be used to write a given language (given sufficient = ingenuity).=20 The *only* difference for these cases in RFC 3066 is that generative use = without requiring registration is sanctioned for country IDs =FDbut not = for script IDs. And that is not so by explicit design; is resulted = simply because we weren't yet sure how script IDs should be integrated = into the tags and the fact that ISO 15924 wasn't yet published. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 21:31:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDuCw-0008J7-Mn; Fri, 09 Sep 2005 21:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDuCw-0008Iz-2p for ltru@megatron.ietf.org; Fri, 09 Sep 2005 21:31:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26023 for ; Fri, 9 Sep 2005 21:31:04 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDuGc-0000RU-6R for ltru@ietf.org; Fri, 09 Sep 2005 21:34:55 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8A1Uo5i017916; Fri, 9 Sep 2005 21:30:50 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 9 Sep 2005 21:30:38 -0400 Date: Fri, 9 Sep 2005 21:30:38 -0400 From: "John.Cowan" To: ietf-languages@iana.org, ltru@ietf.org Message-ID: <20050910013022.GE7608@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] [iana-prot-param@icann.org: [rt.icann.org #3687] FW: I approve the deprecation of zh-guoyu (Mandarin Chinese) (language-tags)(Completed)] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org ----- Forwarded message from Michelle Cotton via RT ----- Date: Fri, 9 Sep 2005 12:45:33 -0700 (PDT) Subject: [rt.icann.org #3687] FW: I approve the deprecation of zh-guoyu (Mandarin Chinese) (language-tags)(Completed) From: "Michelle Cotton via RT" To: cowan@ccil.org Dear John, This message is to confirm that we have marked zh-guoyu as DEPRECATED. See: http://www.iana.org/assignments/lang-tags/zh-guoyu http://www.iana.org/assignments/language-tags If there are any changes to the contact information, please let us know by sending an e-mail to iana@iana.org. Michelle Cotton IANA ----- End forwarded message ----- -- Go, and never darken my towels again! John Cowan --Rufus T. Firefly www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 22:12:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDurH-0001Ct-P9; Fri, 09 Sep 2005 22:12:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDurD-000136-5L; Fri, 09 Sep 2005 22:12:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27051; Fri, 9 Sep 2005 22:12:41 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDuuu-0001Ap-Jk; Fri, 09 Sep 2005 22:16:32 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8A2CXvS018069; Fri, 9 Sep 2005 22:12:33 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 9 Sep 2005 22:12:21 -0400 Date: Fri, 9 Sep 2005 22:12:21 -0400 From: "John.Cowan" To: John C Klensin Subject: Re: [Ltru] Last call comments on LTRU registry and initialization documents Message-ID: <20050910021221.GJ7608@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0CB444CF@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin scripsit: > (i) The 3066 model requires some process for every tag > that is to be used. Actually it doesn't; you can combine any of the 400-odd 639-1/639-2 language codes with any of the 200-odd 3166-1 country codes. The existing opportunities for nonsense are already immense, if that's where you want to go. However, in practice people who use silly tags like nv-dk (Danish Navajo) hurt only themselves, as no one will have any process to do anything useful with nv-dk content. > The closest equivalents involve protocols with a small set of > options that are presumed to be orthogonal. Language tags, however, are not a protocol. > Moreover, someone who was seriously security-paranoid > might wonder whether these perverse combinations could be a way > to code (not cypher, but code) secret/private messages. That could already be done with the 80,000 existing possibilities under RFC 3066. -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com [T]here is a Darwinian explanation for the refusal to accept Darwin. Given the very pessimistic conclusions about moral purpose to which his theory drives us, and given the importance of a sense of moral purpose in helping us cope with life, a refusal to believe Darwin's theory may have important survival value. --Ian Johnston _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 22:16:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDuvB-000218-8q; Fri, 09 Sep 2005 22:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDuv3-0001yk-7S; Fri, 09 Sep 2005 22:16:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27164; Fri, 9 Sep 2005 22:16:39 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDuyg-0001Gf-N9; Fri, 09 Sep 2005 22:20:27 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8A2GR64018084; Fri, 9 Sep 2005 22:16:27 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 9 Sep 2005 22:16:16 -0400 Date: Fri, 9 Sep 2005 22:16:16 -0400 From: "John.Cowan" To: John C Klensin Subject: Re: [Ltru] Re: Last call comments on LTRU registry and initialization documents Message-ID: <20050910021615.GK7608@NYCMJCOWA2> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin scripsit: > So, all I was suggesting wrt the text of the "initial" document > is that, when the IESG concluded that it had reached community > consensus, two things should happen: > > (1) The IESG instructs IANA to create the registry, > populating it with the elements as instructed in the > Internet-Draft and using the formats specified there > and in the "registry" I-D. I think that's what we had in mind. > (2) The document is passed to the RFC Editor for > publication, It's not clear to me what the point of publishing it as an RFC is, and in fact if an explicit decision to that effect has been made, it went past me entirely. IMHO after initial-registry has served its purpose, it should be allowed to time out and die. -- So that's the tune they play on John Cowan their fascist banjos, is it? jcowan@reutershealth.com --Great-Souled Sam http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 22:18:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDux5-0002WB-CX; Fri, 09 Sep 2005 22:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDux3-0002Vx-VZ; Fri, 09 Sep 2005 22:18:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27284; Fri, 9 Sep 2005 22:18:41 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDv0i-0001KC-6i; Fri, 09 Sep 2005 22:22:33 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 19:18:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments Date: Fri, 9 Sep 2005 19:18:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CC4942E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments Thread-Index: AcW1rcrGLqpNm9bVQ5GaEmi1sOJS2QAABXVw From: "Addison Phillips" To: "John.Cowan" , "John C Klensin" X-OriginalArrivalTime: 10 Sep 2005 02:18:24.0966 (UTC) FILETIME=[EC60BE60:01C5B5AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org, iesg@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org +1 Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > John.Cowan > Sent: Friday, September 09, 2005 7:16 PM > To: John C Klensin > Cc: ltru@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Ltru] Re: Last call comments on LTRU registry and > initializationdocuments >=20 > John C Klensin scripsit: >=20 > > So, all I was suggesting wrt the text of the "initial" document > > is that, when the IESG concluded that it had reached community > > consensus, two things should happen: > > > > (1) The IESG instructs IANA to create the registry, > > populating it with the elements as instructed in the > > Internet-Draft and using the formats specified there > > and in the "registry" I-D. >=20 > I think that's what we had in mind. >=20 > > (2) The document is passed to the RFC Editor for > > publication, >=20 > It's not clear to me what the point of publishing it as an RFC is, > and in fact if an explicit decision to that effect has been made, > it went past me entirely. >=20 > IMHO after initial-registry has served its purpose, it should be > allowed to time out and die. >=20 > -- > So that's the tune they play on John Cowan > their fascist banjos, is it? = jcowan@reutershealth.com > --Great-Souled Sam = http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 22:18:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDuxH-0002aF-Ny; Fri, 09 Sep 2005 22:18:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDuxG-0002Ze-0s; Fri, 09 Sep 2005 22:18:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27298; Fri, 9 Sep 2005 22:18:55 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDv0w-0001L4-Fk; Fri, 09 Sep 2005 22:22:47 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EDux8-0003Lm-LA; Fri, 09 Sep 2005 19:18:51 -0700 Message-Id: <6.2.3.4.2.20050910034359.0446fa40@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 10 Sep 2005 03:50:07 +0200 To: "Peter Constable" , , From: r&d afrac Subject: RE: [Ltru] Re: Last call comments on LTRU registry and initialization documents In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 18:51 09/09/2005, Peter Constable wrote: > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf >Of r&d afrac > > The problem with your Draft is that you do not include the 3 letters > > version of the 2 letter version as a correlative information between > > ISO 639-2 and ISO 639-3 tables. I do not think should be left to the > > Editor. > >I think it is out of scope for this registry to document equivalences >between alternate standardized codes, whether that be equivalences >between the 639-1 alpha-2 code and the 639-2 alpha-3 code, the 3166-1 >alpha-2 code and the 3166-1 alpha-3 code, or whatever. As indicated to Addison, this will give additional interest to my own document. Thank you. However, I hope you will change your mind, as about ISO 11179. If this was an incitation to create an alt-registry: I would submit an appropriate Draft. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 09 22:47:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDvPA-0002r9-Jx; Fri, 09 Sep 2005 22:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDvP9-0002qu-0w; Fri, 09 Sep 2005 22:47:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29352; Fri, 9 Sep 2005 22:47:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDvSp-00026v-P9; Fri, 09 Sep 2005 22:51:37 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EDvP6-00078D-HZ; Fri, 09 Sep 2005 19:47:44 -0700 Message-Id: <6.2.3.4.2.20050910044532.03c0aca0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 10 Sep 2005 04:47:42 +0200 To: "Addison Phillips" From: r&d afrac Subject: RE: [Ltru] Re: Last call comments on LTRU registry and initialization documents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ltru@ietf.org, iesg@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 18:42 09/09/2005, Addison Phillips wrote: >The draft does not include any of the overlapping codes on purpose. >This is conformant with both RFC 3066 Section 2.2 and draft-registry >Section 2.2.1, which both mandate that, where ISO 639-1 (alpha2) and >ISO 639-2 (alpha3) codes exist, only the ISO 639-1 codes be used. >The registry contains only subtags that are valid in language tags. This is not what I ask. I say that the registered subtags should mention their standardised equivalence in other ISO tables. The proposed information is of no help when my application already uses an ISO 639-2 (or ISO 639-3) since I have no indication to convert it. However, if you do not provide it, we will provide it : it will make some advertising to our langroot. >I know I'm going to regret asking, but why would the IESG need >approval from Michael Everson to tell IANA to publish a registry? >They appoint him, after all. I am afraid you might know many things wrong. The IESG needs approval from Michael _because_ they appointed him to that end. Unless you want to fire him? The Charter explicitely says: "This working group will not take over the existing review function of the ietf-languages list. The ietf-languages list will continue to review tags according to RFC 3066 until the first document produced by the WG is approved by the IESG for publication as an RFC. Then it will review according to whatever procedures the first document specifies." 1) your Draft says that a batch registration is to be made. This is part of the new procedures: the Charters say it is to be reviewed. 2) Michael will review subtags the same as today, there is no special difference between what is in the Draft and what he is to approve. 2) only Michael has been appointed by the IESG to be "IETF authoritative" about the rightness of the Draft. How can we know otherwise he has no legitimate IETF opposition or there is no error since he is not on this list (he said it). Actually I am wrong: the whole Draft should be reviewed by ietf-languages@alvestrand.no and _then_ Michael should approve it. How do you want them to work on something they did not agree. To make sure Michael is consulted, is also a simple polite courtesy for us jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 10 00:02:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDwZt-00049G-Pi; Sat, 10 Sep 2005 00:02:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDwZr-000498-Ip; Sat, 10 Sep 2005 00:02:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01607; Sat, 10 Sep 2005 00:02:52 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDwdY-0003iT-Pi; Sat, 10 Sep 2005 00:06:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 21:02:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Last call comments on LTRU registry andinitialization documents Date: Fri, 9 Sep 2005 21:02:37 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CC49438@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Last call comments on LTRU registry andinitialization documents Thread-Index: AcW1rhr6yRncedu4Q7e2wFZrz9mZBQADb/WA From: "Addison Phillips" To: "r&d afrac" , "Peter Constable" , , X-OriginalArrivalTime: 10 Sep 2005 04:02:38.0545 (UTC) FILETIME=[7BCD2C10:01C5B5BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org JFC, You asked why the registry didn't include the alpha3 values: my mistake, = as I obviously assumed you meant that the alpha3 values should be = included as actual data. You didn't mention them as descriptive = information. The draft includes a mechanism for any individual to = register descriptive information or comments. Personally, I don't think = the information necessary, since ISO 639-2 MA/RA maintains a perfectly = good reference for that. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 10 03:20:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDzfN-0001Nt-Hc; Sat, 10 Sep 2005 03:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDzcK-0000Yb-1l; Sat, 10 Sep 2005 03:17:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04157; Sat, 10 Sep 2005 01:36:50 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDy6S-0005cf-Qk; Sat, 10 Sep 2005 01:40:43 -0400 Received: from h-68-166-188-218.snvacaid.dynamic.covad.net ([68.166.188.218] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EDy2Z-0001qD-00; Sat, 10 Sep 2005 01:36:40 -0400 Message-ID: <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <02BD58E66D8134A92F365882@scan.jck.com><013101c5b550$313fc0c0$030aa8c0@DEWELL> <20050910021615.GK7608@NYCMJCOWA2> Subject: Re: [Ltru] Re: Last call comments on LTRU registry and initialization documents (issue #878) Date: Fri, 9 Sep 2005 22:38:55 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: iesg@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "John.Cowan" > To: "John C Klensin" > Cc: ; ; > Sent: Friday, September 09, 2005 7:16 PM > Subject: Re: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments > > John C Klensin scripsit: > > > So, all I was suggesting wrt the text of the "initial" document > > is that, when the IESG concluded that it had reached community > > consensus, two things should happen: > > > > (1) The IESG instructs IANA to create the registry, > > populating it with the elements as instructed in the > > Internet-Draft and using the formats specified there > > and in the "registry" I-D. > > I think that's what we had in mind. > > > (2) The document is passed to the RFC Editor for > > publication, > > It's not clear to me what the point of publishing it as an RFC is, > and in fact if an explicit decision to that effect has been made, > it went past me entirely. > > IMHO after initial-registry has served its purpose, it should be > allowed to time out and die. ... (As ltru co-chair) Those who follow the ltru WG mailing list closely will recall that there were two distinct issues recorded in the issue tracker: (at https://rt.psg.com/ user and password are "ietf") #875 should initial registry contents be made into an internet-draft? #878 should the initial registry contents i-d be published as an RFC? There was a rough consensus in support of #875, but the discussion of #878 was inconclusive. We asked our AD whether he had any preference with respect to #878, and he indicated a preference for publication as an (informational) RFC. That is how we got to where we are today. The decision on #875 (initial registry as i-d) has in retrospect proven to be a good one, in my personal opinion. Regarding issue #878, I think we've all looked at it as just a matter of how to work the process to get the right stuff into the registry. The working group has been quite clear in wanting to ensure that the initial registry is not mistaken for the registry itself, and was never enthusiastic about publishing it as an RFC. Consequently, I do not think that it would be a big problem if the IESG were to tell the ltru WG that we don't need to publish the initial registry i-d as an RFC, or if the WG, reconsidering issue #878 as a result of the IETF last call comments were to reach a consensus to withdraw the publication request, as long as we have some assurance that the registry will be end up with the right stuff. Sure, we would have wasted a lot of energy getting the initial registry i-d RFC-ready, but the important thing is to initialize the registry. Process is a tool, not an end in itself, and the result we are interested in is getting the updated registry going, not publishing a history of its initialization, as interesting as that might be. The only problem I see is that the registry draft, http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt, currently references the initial registry i-d in multiple places; we'd need someone to provide the correct incantation to make the right thing happen. I can hardly imagine that a document (whether BCP or some kind of Standard-to-be) would be permitted to reference (even informatively) an i-d never intended for publication. Please send suggested text. Although my personal preference would be to publish the i-d http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt as an Informational RFC, ideally marked "Historic" from the first day it appears, I do not object to non-RFC alternatives that let us accomplish the initialization, as long as we keep the initialization data out of any container that would cause it to be mistaken for the registry itself. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 10 20:04:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEFKW-0008UW-SY; Sat, 10 Sep 2005 20:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEFKV-0008U2-7c; Sat, 10 Sep 2005 20:04:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25474; Sat, 10 Sep 2005 20:04:17 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEFON-0002Gl-9T; Sat, 10 Sep 2005 20:08:20 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EEFKL-000OwT-Hi; Sat, 10 Sep 2005 20:04:09 -0400 Date: Sat, 10 Sep 2005 20:04:09 -0400 From: John C Klensin To: Randy Presuhn , ltru@ietf.org Subject: The LTRU initialization document (was: Re: [Ltru] Re: Last call comments on LTRU registry and initialization documents (issue #878)) Message-ID: <3420D2009FB39F5A23C2B5DE@scan.jck.com> In-Reply-To: <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> <20050910021615.GK7608@NYCMJCOWA2> <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On Friday, 09 September, 2005 22:38 -0700 Randy Presuhn wrote: >... >> > (2) The document is passed to the RFC Editor for >> > publication, >> >> It's not clear to me what the point of publishing it as an >> RFC is, and in fact if an explicit decision to that effect >> has been made, it went past me entirely. >> >> IMHO after initial-registry has served its purpose, it should >> be allowed to time out and die. > ... > > (As ltru co-chair) > > Those who follow the ltru WG mailing list closely will recall > that there were two distinct issues recorded in the issue > tracker: (at https://rt.psg.com/ user and password are "ietf") > #875 should initial registry contents be made into an > internet-draft? #878 should the initial registry contents i-d > be published as an RFC? > > There was a rough consensus in support of #875, but the > discussion of #878 was inconclusive. We asked our AD whether > he had any preference with respect to #878, and he indicated a > preference for publication as an (informational) RFC. > > That is how we got to where we are today. > > The decision on #875 (initial registry as i-d) has in > retrospect proven to be a good one, in my personal opinion. > > Regarding issue #878, I think we've all looked at it as just a > matter of how to work the process to get the right stuff into > the registry. The working group has been quite clear in > wanting to ensure that the initial registry is not mistaken > for the registry itself, and was never enthusiastic about > publishing it as an RFC. > > Consequently, I do not think that it would be a big problem if > the IESG were to tell the ltru WG that we don't need to > publish the initial registry i-d as an RFC, or if the WG, > reconsidering issue #878 as a result of the IETF last call > comments were to reach a consensus to withdraw the publication > request, as long as we have some assurance that the registry > will be end up with the right stuff. > > Sure, we would have wasted a lot of energy getting the initial > registry i-d RFC-ready, but the important thing is to > initialize the registry. Process is a tool, not an end in > itself, and the result we are interested in is getting the > updated registry going, not publishing a history of its > initialization, as interesting as that might be. Extremely violent agreement. > The only problem I see is that the registry draft, > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-1 > 2.txt, currently references the initial registry i-d in > multiple places; we'd need someone to provide the correct > incantation to make the right thing happen. I can hardly > imagine that a document (whether BCP or some kind of > Standard-to-be) would be permitted to reference (even > informatively) an i-d never intended for publication. Please > send suggested text. > > Although my personal preference would be to publish the i-d > http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04 > .txt as an Informational RFC, ideally marked "Historic" from > the first day it appears, I do not object to non-RFC > alternatives that let us accomplish the initialization, as > long as we keep the initialization data out of any container > that would cause it to be mistaken for the registry itself. Well, that pair of issues is exactly what I was concerned about and suggesting fixing, despite Doug's strong reaction to a suggestion I didn't intend to make. Specifically: If a document is published in the RFC series that lists elements of a registry, it will, inevitably, be used as a reference instead of the registry. Disclaimers in the document (as now exist) will help with that a bit. The word "historic" in the RFC Index will help with that a bit. But it will still be referenced by someone, somewhere, as an "official" RFC and an easy-to-obtain list. At the same time, there is useful, albeit mostly-historical, information in the initialization document that I would personally prefer not get lost. And that referencing issue is a pain in the neck, although not a huge one. So, very specific suggestion: (1) Get the registry created and initialized, exactly as specified in the "initial" document at -02. I think that is a no-brainer and we all seem to be agreeing about it. (2) Issue, and send to the RFC Editor for Informational publication, a version of draft-ietf-ltru-initial that replaces the contents of Section 3 ("Initial Registry Contents") with a pointer to the registry itself and, if desired, a hint as to how the initial elements can be identified, for historical purposes, in the registry. Leave the rest of it alone. It contains useful text and some information that should not be lost (such as the omitted code element list). Just to be orderly, remove the "don't pretend this is the registry" statements/warnings from the abstract and the end of Section 1. This prevents anyone from referencing the RFC form of the initialization document as the registry far more effectively than any warnings or labels -- there will be nothing there to reference. It saves time patching references to the initialization document because the initialization document will exist as an RFC and even have the same section numbering. It saves worrying about whether there is important historical information in the initialization document that would need to be moved somewhere else if that document were dropped, and where to move it. The WG and IESG should do what they think best, but this really seems pretty obvious to me. Of course, none of the above has anything to do, one way or the other, with my concerns about BCP versus Standards Track, replacement of 3066 without doing something specific about the matching rule question, applications-specific profiles, and so on. Whatever the right answers to those concerns are, they are not as obvious, at least to me. john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 10 20:35:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEFog-0007n7-Mg; Sat, 10 Sep 2005 20:35:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEFof-0007ms-Hv; Sat, 10 Sep 2005 20:35:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26381; Sat, 10 Sep 2005 20:35:27 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEFsY-0002q7-GW; Sat, 10 Sep 2005 20:39:30 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EEFnm-0007kK-8u; Sat, 10 Sep 2005 17:34:34 -0700 Message-Id: <6.2.3.4.2.20050910103755.03d13230@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 11 Sep 2005 02:34:19 +0200 To: "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] Re: Last call comments on LTRU registry and initialization documents (issue #878) In-Reply-To: <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> <20050910021615.GK7608@NYCMJCOWA2> <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: iesg@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org We eventually reach the mission assigned by the Charter: the real IANA registry. And we considering some of the key points: 1. is the directory to be published as an RFC? 2. is it or not to document the subtags ISO aliases? 3. is it to respect the Charter and the IESG authority in being reviewed by ietf-languages@alvestrand.no and approved by its IESG designated reviewer? 4. what is its expected growth? Should it be contained in size? Is it informative or normative? 5. what is its practical purpose, in term of user applications? How is it expected to be used? 6. what is its dissemination system? 7. who is going to insure that this system is sure, secure, stable and who will bear the cost of it? I am opposed that my approach is not in operations (cf. John): AFRAC's role is to consider the various propositions and to test the most appropriate ones for its own mission of a reference center. From this (a) we know the main Draft proposition is very limited and dangerous, (b) we know there are others possible propositions, with their own con and pros (Addison explained he had one), (c) we observe they should be correctly be supported by IRI-tags with RFC 3066 bis as a default with no other change than to add one sentence: "0- introduces an URI/IRI tag which conforms RFC [URI-tags]"]). Going further without first a consensus on the target of the WG (addressing user needs like ours vs. imposing on us an unique limited solution) would only create confusion. Competition, as begged from us by Addison, between standardisers and users is never good. Now these simple, practical questions are put in front of the IESG. IESG will turn me right or wrong. If they can think of a way to deliver, with non limited and non constrained internationalisation options, along with the proposed registry: no one will be more happy than me. Otherwise the Internet standard process still gives chances to a thinking maturation process, through IETF/IAB and external appeals. To help that thinking we may have to stabilise and deploy a grassroots project. But I am afraid then to trigger other projects by industry leaders and Govs. They will see there a way to block a Internet possible control and a way to obtain parts of it. But the constant disregard of our needs as a user of the deliverable may eventually push us to do that. 1. is it to be published as an RFC? As an RFC it is the same base for all the common reference centers, existing and to come, IANA or not. It preserves a point of consensus. It permits RFC "bis", "ter" etc. to accompany ISO, usage and RFC 3066nths evolution. 2. is it or not to document the subtags ISO aliases? No to do so would underline the motivation of exclusiveness. This would only add to confusion: users will see that registry as an hybrid registry, randomly (on their opinion) using variable format elements from ISO 639-1,2,3,5,6, from ISO 3166 and UN, from its own, with no documented relation with the ISO codes they use in their other applications. Search engines and Gov systems will align on ISO 11179 works and on ISO 639-4 guidelines. In defending for ever the RFC 3066 errors, instead of correcting them progressively, what do we want to do? This is IETF, not a WTO arbitration. 3. is to respect the Charter and the IESG authority in being approved by ietf-languages@alvestrand.no and its reviewer I documented the need and the courtesy to have Michael Everson and ietf-languages@alvestrand.no to review and approve the soundness and the consistency of the proposed registry content. It also underline the script orientation of the Draft. 4. what is its expected growth? Should it be contained in size? Is it informative or normative? John documented the IETF/RFC's related difficulties if the parameter registry goes large (I do not know if there is another registry which can expand to 40.000 items?). 5. what is its practical purpose, in term of user applications? How is it expected to be used? This point is still pending. 6. what is its dissemination system? This point is still pending - it will result from the above.The only indication I got so far is "like Unicode". I indicated the system we advocate. 7. who is going to insure that this system is sustained and who will bear the cost if it? I know this is not a main IETF concern. I submit it is because the IANAI registries are usually not that size and do not risk to be accessed by the XML applications by billions? jfc At 07:38 10/09/2005, Randy Presuhn wrote: >Hi - > > > From: "John.Cowan" > > To: "John C Klensin" > > Cc: ; ; > > Sent: Friday, September 09, 2005 7:16 PM > > Subject: Re: [Ltru] Re: Last call comments on LTRU registry and > initializationdocuments > > > > John C Klensin scripsit: > > > > > So, all I was suggesting wrt the text of the "initial" document > > > is that, when the IESG concluded that it had reached community > > > consensus, two things should happen: > > > > > > (1) The IESG instructs IANA to create the registry, > > > populating it with the elements as instructed in the > > > Internet-Draft and using the formats specified there > > > and in the "registry" I-D. > > > > I think that's what we had in mind. > > > > > (2) The document is passed to the RFC Editor for > > > publication, > > > > It's not clear to me what the point of publishing it as an RFC is, > > and in fact if an explicit decision to that effect has been made, > > it went past me entirely. > > > > IMHO after initial-registry has served its purpose, it should be > > allowed to time out and die. >... > >(As ltru co-chair) > >Those who follow the ltru WG mailing list closely will recall that >there were two distinct issues recorded in the issue tracker: >(at https://rt.psg.com/ user and password are "ietf") >#875 should initial registry contents be made into an internet-draft? >#878 should the initial registry contents i-d be published as an RFC? > >There was a rough consensus in support of #875, but the discussion >of #878 was inconclusive. We asked our AD whether he had any >preference with respect to #878, and he indicated a preference for >publication as an (informational) RFC. > >That is how we got to where we are today. > >The decision on #875 (initial registry as i-d) has in retrospect proven >to be a good one, in my personal opinion. > >Regarding issue #878, I think we've all looked at it as just a matter of how >to work the process to get the right stuff into the registry. The working >group has been quite clear in wanting to ensure that the initial registry >is not mistaken for the registry itself, and was never enthusiastic about >publishing it as an RFC. > >Consequently, I do not think that it would be a big problem if the >IESG were to tell the ltru WG that we don't need to publish the initial >registry i-d as an RFC, or if the WG, reconsidering issue #878 as a >result of the IETF last call comments were to reach a consensus to >withdraw the publication request, as long as we have some assurance >that the registry will be end up with the right stuff. > >Sure, we would have wasted a lot of energy getting the initial registry i-d >RFC-ready, but the important thing is to initialize the registry. Process >is a tool, not an end in itself, and the result we are interested in is >getting the updated registry going, not publishing a history of its >initialization, as interesting as that might be. > >The only problem I see is that the registry draft, >http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt, >currently references the initial registry i-d in multiple places; we'd need >someone to provide the correct incantation to make the right thing >happen. I can hardly imagine that a document (whether BCP >or some kind of Standard-to-be) would be permitted to reference >(even informatively) an i-d never intended for publication. >Please send suggested text. > >Although my personal preference would be to publish the i-d >http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt >as an Informational RFC, ideally marked "Historic" from >the first day it appears, I do not object to non-RFC alternatives >that let us accomplish the initialization, as long as we keep the >initialization data out of any container that would cause it to be >mistaken for the registry itself. > >Randy, ltru co-chair > > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 10 21:18:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEGUd-00018Q-JF; Sat, 10 Sep 2005 21:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEGUc-000172-5E; Sat, 10 Sep 2005 21:18:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27632; Sat, 10 Sep 2005 21:18:43 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEGYQ-0003ZE-IE; Sat, 10 Sep 2005 21:22:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 10 Sep 2005 13:30:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call comments on LTRU registry and initialization documents Date: Sat, 10 Sep 2005 13:30:34 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CC49466@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last call comments on LTRU registry and initialization documents Thread-Index: AcW1amLrqkkcnJLySOKVf3n7VeC5AAA2VLBA From: "Addison Phillips" To: "John C Klensin" , X-OriginalArrivalTime: 10 Sep 2005 20:30:39.0781 (UTC) FILETIME=[822BED50:01C5B646] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The problem I have with going to the STD track has nothing to do with = the process of progressing as a standard. The IESG will decide which = track to go down and either track suits me fine... provided... Draft-registry is actually, despite the appearance of being very = different, very much a particular profile of RFC 3066. Its grammar could = be pasted into RFC 3066 with no ill effect, since all generative or = registered tags extant today follow it. The creation of a central = registry to mirror the many external standards (and rules for choosing = among them) also has no deleterious effect on implementations because = the registry accurately mirrors the rules for tag choice in RFC 3066. There are two problems, though, that must be solved if we are to go down = the STD path. 1. Is draft-registry "Obsoletes: 3066"? Many standards, protocols, and formats reference something called "RFC = 3066 or its successor". Thus the question of whether draft-registry is = 3066's successor is important to those standards, protocols, and = formats. I have no problem with BCP 47 being replaced with STD xyz, but = everyone will be curious about what to do if we have both BCP 47 and STD = xyz. 2. When does the registry replace the existing IANA registry? I don't see how the two language tag registration schemes can coexist = peacefully. Even if draft-registry is not RFC 3066's successor, there = has to be some consideration for interoperability between the two. Thus, I think that, if we go down the STD track for whatever reason, = these two questions need to be clarified quickly and clearly so that = implementers and content taggers can made good, informed choices. I look forward to the IESG's deliberations. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: Friday, September 09, 2005 11:15 AM > To: Addison Phillips; iesg@ietf.org > Cc: ltru@ietf.org; ietf@ietf.org > Subject: RE: [Ltru] Last call comments on LTRU registry and = initialization > documents >=20 >=20 >=20 > --On Wednesday, 07 September, 2005 12:19 -0700 Addison Phillips > wrote: >=20 > >> Comments on draft-ietf-ltru-registry and > >> draft-ietf-ltru-initial and, secondarily, on > >> draft-ietf-ltru-matching... > > > > I've thought a lot about the excellent analysis and comments > > in John Klensin's message. My perception is that we have a > > divergent view of the structure and significance of the LTRU > > draft(s). >=20 > First, my thanks for the obviously careful reading and thought. > We may indeed have divergent views, although, after reading your > notes I believe that, in practical terms, we are pretty close > together. > ...... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 10 22:33:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEHf7-00034r-Vd; Sat, 10 Sep 2005 22:33:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEHf5-00032z-JX for ltru@megatron.ietf.org; Sat, 10 Sep 2005 22:33:44 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00394 for ; Sat, 10 Sep 2005 22:33:28 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EEHdk-0004Km-Az for ltru@lists.ietf.org; Sun, 11 Sep 2005 04:32:20 +0200 Received: from c-134-88-33.hh.dial.de.ignite.net ([62.134.88.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2005 04:32:20 +0200 Received: from nobody by c-134-88-33.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2005 04:32:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 11 Sep 2005 04:22:25 +0200 Organization: Lines: 40 Message-ID: <432394E1.5999@xyzzy.claranet.de> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> <20050910021615.GK7608@NYCMJCOWA2> <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> <3420D2009FB39F5A23C2B5DE@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-33.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: [Ltru] Re: The LTRU initialization document X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin wrote: [ltru-initial] > The WG and IESG should do what they think best, but this > really seems pretty obvious to me. Yes, it's _now_ obvious, but it wasn't before you started this thread. So keeping the rest of "ltru-initial" as an informational or historic RfC might also help others when they look for a "how-to". > none of the above has anything to do, one way or the > other, with my concerns about BCP versus Standards Track That puzzle is for the IESG, I hope that they find a better answer than "toss a coin". On the technical side I'd like to see a way to communicate the "intended status" in an I-D with xml2rfc (not only for Bruce's reviews). And I hope that splitting the BCP series into "techno" vs. "meta" (or similar) shows up in a future carpenter-procdoc-roadmap-01. [applications-specific profiles] > Whatever the right answers to those concerns are, they are > not as obvious, at least to me. For that part all I found as potential candidates is "never use script subtags" (e.g. audio) and "always use a script" (= intentionally violating several SHOULDs in conjunction with Suppress-Script). If that's really all it's obvious, no additional profile-headaches necessary at the moment. It's possible to add this later if some future extension registry offers more exciting choices than to script or not to script. Maybe we could mention this in a note about the extension registries. Also as a hint for the future DS^W3066ter. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 11 03:27:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEMFq-000288-TF; Sun, 11 Sep 2005 03:27:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEMFl-00026h-LD; Sun, 11 Sep 2005 03:27:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22682; Sun, 11 Sep 2005 03:27:43 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEMJZ-0001gq-7y; Sun, 11 Sep 2005 03:31:50 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EEMFW-000Px9-FU; Sun, 11 Sep 2005 03:27:38 -0400 Date: Sun, 11 Sep 2005 03:27:38 -0400 From: John C Klensin To: Frank Ellermann , ietf@ietf.org Message-ID: <77AAF63860A1726F496DCB4B@scan.jck.com> In-Reply-To: <432394E1.5999@xyzzy.claranet.de> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> <20050910021615.GK7608@NYCMJCOWA2> <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> <3420D2009FB39F5A23C2B5DE@scan.jck.com> <432394E1.5999@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: The LTRU initialization document X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On Sunday, 11 September, 2005 04:22 +0200 Frank Ellermann wrote: > John C Klensin wrote: > > [ltru-initial] >> The WG and IESG should do what they think best, but this >> really seems pretty obvious to me. > > Yes, it's _now_ obvious, but it wasn't before you started > this thread. So keeping the rest of "ltru-initial" as an > informational or historic RfC might also help others when > they look for a "how-to". I think so. >> none of the above has anything to do, one way or the >> other, with my concerns about BCP versus Standards Track > > That puzzle is for the IESG, I hope that they find a better > answer than "toss a coin". On the technical side I'd like > to see a way to communicate the "intended status" in an I-D > with xml2rfc (not only for Bruce's reviews). And I hope > that splitting the BCP series into "techno" vs. "meta" (or > similar) shows up in a future carpenter-procdoc-roadmap-01. Two observations: (1) In a situation like this, if the community leaves the IESG to make this sort of decision without significant community input, then the community deserves whatever the IESG does, including coin-tossing. If people care, they should say so clearly enough that the IESG's role is to interpret community input, not to make things up because no one (besides some soreheads like me) is saying anything. FWIW, that split in the BCP series is already covered in draft-ietf-newtrk-repurposing-isd. > [applications-specific profiles] >> Whatever the right answers to those concerns are, they are >> not as obvious, at least to me. > > For that part all I found as potential candidates is "never > use script subtags" (e.g. audio) and "always use a script" > (= intentionally violating several SHOULDs in conjunction > with Suppress-Script). If that's really all it's obvious, > no additional profile-headaches necessary at the moment. Perhaps my imagination is worse than yours, but I can easily imagine "numeric country codes prohibited" or "alpha-2 country codes prohibited" (note that matching the two requires large tables that are not, as far as I know, freely available for free and that change). I can also imagine "script required" or "region, if present, ignored" or a number of other variations and profiles. > It's possible to add this later if some future extension > registry offers more exciting choices than to script or > not to script. > > Maybe we could mention this in a note about the extension > registries. Also as a hint for the future DS^W3066ter. "Add later" is much more plausible, at least formally, with a Proposed Standard than it is with a BCP. The notion of replacing a BCP with a new BCP that says something different is always going to be dicey unless there has been an actual and obvious change in common behavior. john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 11 08:18:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEQmc-0003lE-MX; Sun, 11 Sep 2005 08:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEQmH-0003jW-5O for ltru@megatron.ietf.org; Sun, 11 Sep 2005 08:18:05 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00010 for ; Sun, 11 Sep 2005 08:17:23 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EEQkA-0006W8-M6 for ltru@lists.ietf.org; Sun, 11 Sep 2005 14:15:35 +0200 Received: from c-180-160-102.hh.dial.de.ignite.net ([62.180.160.102]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2005 14:15:34 +0200 Received: from nobody by c-180-160-102.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2005 14:15:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 11 Sep 2005 14:05:01 +0200 Organization: Lines: 109 Message-ID: <43241D6D.6BCD@xyzzy.claranet.de> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> <20050910021615.GK7608@NYCMJCOWA2> <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> <3420D2009FB39F5A23C2B5DE@scan.jck.com> <432394E1.5999@xyzzy.claranet.de> <77AAF63860A1726F496DCB4B@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-102.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: [Ltru] Re: The LTRU initialization document X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John C Klensin wrote: > In a situation like this, if the community leaves the IESG to > make this sort of decision without significant community > input, then the community deserves whatever the IESG does, > including coin-tossing. If people care, they should say so > clearly enough that the IESG's role is to interpret community > input, not to make things up because no one (besides some > soreheads like me) is saying anything. It's not that nobody but you said anything about it, in fact it's the only case of a potential "rough consensus" not covered by a half dozen LTRU tickets. What Addison said is IMHO correct, 3066bis must replace 3066, they can't coexist. One of the main design goals was backwards compatiility. Any solution designed to exist in parallel with 3066 would be completely different, because it's not forced to be backwards compatible. For starters there won't be a kludge like "Suppress-Script" in that hypothetical solution. Most probably we agree so far, and then the question of BCP vs. standards track is among other things a matter of taste. It's apparently a "feature" of 2026 that the IESG decides about the status - in the usual sense of "your feature is my bug (and v.v.)", so all we can do is offer some opinions. If you'd press the WG for some kind of consensus about this I'd bet that you'd get "BCP with an option for the IESG to say PS", exactly as Scott (= the AD, the Proto-shepherd avoided that issue) stated it. With some more or less convincing reasons. And finally it's not up to the author / WG / Chair / community to decide about the status. Unfortunately in the case of some individual submissions, this "experimental" loophole to bypass a proper "IETF last call" as seen for SPF and SID was "wrong" (a 2234bis "wrong", so that's as bad as 32 ordinary wrongs :-) But for ltru-registry there was a "last call", and I think the IESG knows that some (not only you) prefer PS instead of BCP for 3066bis - under the conditions listed by Addison. > FWIW, that split in the BCP series is already covered in > draft-ietf-newtrk-repurposing-isd. Thanks for info, added to my "I-D collection" - admittedly I'm lost in this one-step / two-step / add-XML-step netwrk-maze. > Perhaps my imagination is worse than yours, but I can easily > imagine "numeric country codes prohibited" or "alpha-2 > country codes prohibited" (note that matching the two > requires large tables that are not, as far as I know, freely > available for free and that change). In that case your imagination is worse tha mine. The _actual_ lists are freely available, e.g. the alpha-2 country codes: http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html?printable=true#AA It's unnecessary to match these lists. All details about the registration of region codes are specified in 3066bis. Forward, sideward, backward, 3166 screws up, 3166 out of sync with UN, everything, we discussed this for months. It was the reason why I was interested in this WG. It makes no sense to exclude all numeric country codes, that's the "escape hatch" if 3166 is forced to reuse an aplha-2 code (examples: GE, SK, CS), because 3066bis tags are persistent (unlike 3066 tags). Maybe you could exclude the UN "macro-regions" (~ continents), you could as well exclude some languages or scripts, or all variants. If you do so, fine, but that doesn't affect the registry. There's one thing where getting _free_ lists could be tricky: old region codes. OTOH precisely that issue is addressed by the registry with its persistent subtags, you don't need any old UN or 3166-lists to determine what 3066bis subtags mean (unlike 3066 tags). > I can also imagine "script required" or "region, if present, > ignored" or a number of other variations and profiles. Yes, the first case was also in my shorter list. If you take language + script + region as three "dimensions", then the language is required (using the langtag registry in other contexts could be a bad plan, it's not designed to be a say region registry, and for a script registry you can also use the ISO standard). That leaves two dimensions where you could say "ignored" or "required". Better don't consider "variant" as an independent fourth dimension, it's not, generally it has a "Prefix". All in all you'd get about four potential "profiles": I-I, I-R, R-I, and R-R (I = ignored. R = required). The concept of regions in 3066 and 3066bis is so clumsy that I can't imagine any serious case of R. That reduces the profiles to I-I + R-I (= my "to script or not to script"), or maybe I-I, R-I, I-?, and R-I (? = region allowed). >> Maybe we could mention this in a note about the extension >> registries. Also as a hint for the future DS^W3066ter. > "Add later" is much more plausible, at least formally, with > a Proposed Standard than it is with a BCP. Add Jefsey and we're three. and that's not much, bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 11 09:19:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EERje-0003ZA-7G; Sun, 11 Sep 2005 09:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EERjc-0003YO-Fl for ltru@megatron.ietf.org; Sun, 11 Sep 2005 09:19:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02886 for ; Sun, 11 Sep 2005 09:18:52 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EERnR-0004LY-2N for ltru@ietf.org; Sun, 11 Sep 2005 09:23:02 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EERjM-0005U6-TJ for ltru@ietf.org; Sun, 11 Sep 2005 06:18:49 -0700 Message-Id: <6.2.3.4.2.20050911145548.047f75e0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 11 Sep 2005 15:17:34 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] a question I received X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1424346484==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1424346484== Content-Type: multipart/alternative; boundary="=====================_49689790==.ALT" --=====================_49689790==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I received the following from a WG Member (I rephrase it by netiquette, because it might disclose the author): "http://news.bbc.co.uk/2/hi/uk_news/magazine/4172085.stm Do you know if there is another non-English mother tongue Member with litterary accademic background in this WG?" I never asked. jfc --=====================_49689790==.ALT Content-Type: text/html; charset="us-ascii" I received the following from a WG Member (I rephrase it by netiquette, because it might disclose the author):

" http://news.bbc.co.uk/2/hi/uk_news/magazine/4172085.stm
Do you know if there is another non-English mother tongue Member with litterary accademic background in this WG?"
I never asked.

jfc




--=====================_49689790==.ALT-- --===============1424346484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1424346484==-- From ltru-bounces@ietf.org Sun Sep 11 09:19:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EERjl-0003aM-8b; Sun, 11 Sep 2005 09:19:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EERjc-0003YP-Fk for ltru@megatron.ietf.org; Sun, 11 Sep 2005 09:19:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02887 for ; Sun, 11 Sep 2005 09:18:52 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EERnR-0004LX-2R for ltru@ietf.org; Sun, 11 Sep 2005 09:23:02 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EERjL-0005U6-Uo; Sun, 11 Sep 2005 06:18:48 -0700 Message-Id: <6.2.3.4.2.20050911144508.047be0f0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 11 Sep 2005 14:55:26 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: The LTRU initialization document In-Reply-To: <43241D6D.6BCD@xyzzy.claranet.de> References: <02BD58E66D8134A92F365882@scan.jck.com> <013101c5b550$313fc0c0$030aa8c0@DEWELL> <20050910021615.GK7608@NYCMJCOWA2> <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer> <3420D2009FB39F5A23C2B5DE@scan.jck.com> <432394E1.5999@xyzzy.claranet.de> <77AAF63860A1726F496DCB4B@scan.jck.com> <43241D6D.6BCD@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 14:05 11/09/2005, Frank Ellermann wrote: >Any solution designed to exist in parallel with 3066 would be >completely different, because it's not forced to be backwards compatible. This is uncorrect. There is a total confusion between backward compatibility and conformance. Any new format including the RFC 3066 format will be backward compatible. The Draft demands for ever new releases to stay compatible only with RFC 3066, and invents new constraints to that end. I note that this "backward compatibility" which excludes the support of most of user needs, includes the introduction of the support of "scripts" , interestingly enough a word not even used by RFC 3066. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 11 12:01:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEUGW-0004rm-6G; Sun, 11 Sep 2005 12:01:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEUGK-0004pC-6I; Sun, 11 Sep 2005 12:01:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10645; Sun, 11 Sep 2005 12:00:25 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEUJo-0007g3-4I; Sun, 11 Sep 2005 12:04:37 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j8BG06aS009763; Sun, 11 Sep 2005 09:00:06 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 11 Sep 2005 09:00:13 -0700 Message-ID: From: "McDonald, Ira" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: The LTRU initialization document Date: Sun, 11 Sep 2005 09:00:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org]On Behalf Of > Frank Ellermann > Sent: Sunday, September 11, 2005 8:05 AM > To: ltru@ietf.org > Cc: ietf@ietf.org > Subject: [Ltru] Re: The LTRU initialization document > > > John C Klensin wrote: > > > In a situation like this, if the community leaves the IESG to > > make this sort of decision without significant community > > input, then the community deserves whatever the IESG does, > > including coin-tossing. If people care, they should say so > > clearly enough that the IESG's role is to interpret community > > input, not to make things up because no one (besides some > > soreheads like me) is saying anything. > > It's not that nobody but you said anything about it, in fact > it's the only case of a potential "rough consensus" not covered > by a half dozen LTRU tickets. > > What Addison said is IMHO correct, 3066bis must replace 3066, > they can't coexist. One of the main design goals was backwards > compatiility. Any solution designed to exist in parallel with > 3066 would be completely different, because it's not forced to > be backwards compatible. For starters there won't be a kludge > like "Suppress-Script" in that hypothetical solution. > Just for the record. Suppress-Script is NOT a kludge. It is the only basis on which RFC3066bis is acceptable at all to the wider community. And there is no such thing as a possibility that RFC3066 and RFC3066bis could exist in parallel. All XML applications and all web services applications currently depend on RFC3066 for the syntax and semantics of 'language tags'. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 11 22:09:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEdkw-0004Du-98; Sun, 11 Sep 2005 22:09:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEdku-0004Db-JZ for ltru@megatron.ietf.org; Sun, 11 Sep 2005 22:09:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05384 for ; Sun, 11 Sep 2005 22:09:08 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEdoy-0003eO-PC for ltru@ietf.org; Sun, 11 Sep 2005 22:13:26 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EEdkh-0006Gk-9K; Sun, 11 Sep 2005 19:08:59 -0700 Message-Id: <6.2.3.4.2.20050912011545.05340ea0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 12 Sep 2005 04:08:53 +0200 To: ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] a question I received Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I am asked what this has to do with the Draft. I just try different ways and help to explain why the langtags defined by the Draft are not end to end. Two key informations are not in the proposed format (referent and context) nor is the date for comparison with registry. Many other sub-informations are also not transported from the author's end to the reader's end. If the WG standadisers do not see it, users do. Users are most probably more literary oriented people (authors, sales, newsmen, artists and site designers, etc.), trained/informed by people of some education, probably not using English (they less need langtags). Having another user (not what Peter Constable calls an "end user") sharing with me the need to use langtags in a heavy and delayed applications, could be a real help for me to document why the Draft does not deliver what _we_ (users) need and expect. Non-English mother tongue literary academics are the typical "affected parties" (like me and my organisation) the Internet standard process (RFC 2026/1.2 is quoted here) wants to consider the needs, within the framework of the widespread community consensus, and to serve with specifications of high quality in spite of the difficulty of evaluating the utility of particular specifications for an Internet community (where English is a minority language: 61.6% of the Internet users do not speak English). The WG takes users needs as an opposition, and wants to impose on us/them a commercial scheme we do not trust and which does fit the bill. Before addressing our needs ourselves as suggested by John, I make a last try. If I review the proposed deliverable as one of its future users and along the RFC 2066/1.2 criteria: - of technical excellence: the ABNF is improved, the "0-", we need to support all what the ABNF does not provide, is still missing. - with a prior implementation and testing. We cannot test: a simple reading shows that it does not provide our needed 5 elements. - with clear, concise, and easily understood documentation. hmmm. A long text to impeach the resolution of our needs. - with openness and fairness - IMO that part is not achieved yet! - and timeliness. I am sorry but all this is overdue when compared to market's needs and expectations. This is why we need to stop disputing the details of a now cleaner but low interest ABNF (if it is not much used it is not because it was poorly defined. It was because it is a provider's solution and it does not fit the users needs. The provider's end has the missing elements it cannot transport to the receiver's end. The langtag protocol is only of use when the information it does not transport is not considered. jfc >On 15:17 11/09/2005, r&d afrac said: >>I received the following from a WG Member (I rephrase it by >>netiquette, because it might disclose the author): >> >>" http://news.bbc.co.uk/2/hi/uk_news/magazine/4172085.stm >>Do you know if there is another non-English mother tongue Member >>with litterary accademic background in this WG?" >>I never asked. >> >>jfc >> >> >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 12 11:04:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEprG-0005yS-1I; Mon, 12 Sep 2005 11:04:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEprB-0005wr-MF; Mon, 12 Sep 2005 11:04:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24148; Mon, 12 Sep 2005 11:04:17 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEpvD-0006I4-ND; Mon, 12 Sep 2005 11:08:41 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 08:04:05 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 08:04:04 -0700 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, 12 Sep 2005 08:04:04 -0700 Message-ID: Thread-Topic: RFC 3066 bis Libraries list thread-index: AcW3jU7aAH9cka/1T1iFUmwzfM0TCgAHRkFg From: "Peter Constable" To: X-OriginalArrivalTime: 12 Sep 2005 15:04:04.0990 (UTC) FILETIME=[379799E0:01C5B7AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org Subject: [Ltru] RE: RFC 3066 bis Libraries list X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Dear Peter, > whatever the way you want to say it, these libraries have now to meet > new specs they had not to meet before. I cannot say whether every existing software library written to conform to RFC 3066 *has to* meet new specs. Certainly there will some, perhaps many, that would be benefit from revision to the new specs.=20 If that was your intent, it would have been clearer to me had you asked people to identify libraries they feel should be revised if the new spec is adopted.=20 Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 12 23:46:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF1kH-0005Mb-Of; Mon, 12 Sep 2005 23:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmVw-0002j0-8r; Mon, 12 Sep 2005 07:30:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11777; Mon, 12 Sep 2005 07:30:08 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEmZu-0000MU-Q1; Mon, 12 Sep 2005 07:34:29 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EEmVZ-0007EO-JZ; Mon, 12 Sep 2005 04:29:57 -0700 Message-Id: <6.2.3.4.2.20050912112700.05348ca0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 12 Sep 2005 13:29:51 +0200 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Mon, 12 Sep 2005 23:18:27 -0400 Cc: ltru@ietf.org Subject: [Ltru] RE: RFC 3066 bis Libraries list X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 06:38 12/09/2005, Peter Constable wrote: > > From: "JFC (Jefsey) Morfin" > > RFC 3066 Bis imposes new constraints on the existing language tags > > software libraries. Dear Peter, whatever the way you want to say it, these libraries have now to meet new specs they had not to meet before. I do not know if you already developed some piece of software, but this means there will be more lines of codes in RFC 3066 bis librairies and more possible bugs. Please do not confuse constraints of accuracy and quality on the libraries, constraints on the langtags, and constraints on the users who would be now to accomodate for ever a non end to end non-interoperable (except may-be in e-commerce) security leaking system. Before approving a "BCP", and the whole IETF in not opposing the Draft must investigate the supposed existing running code. To show make sure that users are (will be) supported correctly. This concerns for example the _added_ information (scripts), the way they address "x-tags" private use, the filtering and negociatioin performed, or langtags such as qac-qark-aa, etc. They must also know what are the other libraries they could use. This is this much needed review I plan since the WG-ltru neither considered it, nor considered describing library validation tests. IMHO it is more positive than biaised considerations over RFC 3683. RFC 2026 talks about the need to consider the interests of all the affected parties and of openness and fairness: I try to consider and support them all in an open and fair practical way, hence the reason of my call on this list, so every library can be quoted. As the most knowledgeable and the leading person IRT that project, you should help me and provide a list of all the librairies you know. The same about the authors? Or is there a problem I miss? jfc >We need to be more careful in describing the proposed revision to RFC >3066 (aka RFC 3066 bis) wrt exiting libraries that conform to RFC 3066: >every tag valid under the terms of RFC 3066 bis will be recognized by an >existing library written to conform to RFC 3066. Not every tag that >*could* be recognized by such a library would be valid under RFC 3066 >bis, but every tag actually valid today under RFC 3066 is also valid >under RFC 3066 bis. > > >The draft was written with careful attention to ensuring compatibility >with existing libraries written to support RFC 3066. The draft can be >said to impose new constraints that existing libraries would not impose; >I don't see how it could be said that the draft imposes new constraints >on those libraries. > >Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 13 03:49:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF5Xi-0002hY-4P; Tue, 13 Sep 2005 03:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExlq-0006xw-EJ; Mon, 12 Sep 2005 19:31:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08575; Mon, 12 Sep 2005 19:31:27 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EExq7-0001ES-8i; Mon, 12 Sep 2005 19:35:56 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EExlf-0001S3-Ep; Mon, 12 Sep 2005 16:31:19 -0700 Message-Id: <6.2.3.4.2.20050912204409.04c785c0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 12 Sep 2005 21:30:49 +0200 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] RE: RFC 3066 bis Libraries list In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Mon, 12 Sep 2005 23:18:27 -0400 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 17:04 12/09/2005, Peter Constable wrote: > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > Dear Peter, > > whatever the way you want to say it, these libraries have now to meet > > new specs they had not to meet before. > >I cannot say whether every existing software library written to conform >to RFC 3066 *has to* meet new specs. Certainly there will some, perhaps >many, that would be benefit from revision to the new specs. Dear Peter, The target is end to end interoperability between users/processes of non-English language. Users of every library MUST know to which extent the library they use fits the job or not, which alternative they can use. They should have a verification procedure to check their libraries depending on what they want. They should know how their software behaves when analysing specific langtag. For example, _some_ documentation is given by http://library.n0i.net/programming/perl/ac_tive/lib/I18N/LangTags/List.html. It is not strictly complying with any of the RFCs, nor giving the source code. That kind of information is a minimum. >If that was your intent, it would have been clearer to me had you asked >people to identify libraries they feel should be revised if the new spec >is adopted. You think some should escape the check? I do not know. I was expecting from you, from the authors, from the members of the WG-ltru, the list of all the libraries you know (URLs). You say they cannot support the users needs I presented, neither my big initial request to support to additional subtags (referent and context) nor even to support RFC documented URI-tags (a hook of a dedicated library?) jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 13 15:33:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWs-0004xX-UL; Tue, 13 Sep 2005 15:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFCwi-0001gD-A6 for ltru@megatron.ietf.org; Tue, 13 Sep 2005 11:43:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27795 for ; Tue, 13 Sep 2005 11:43:28 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFD0u-0005R5-Nl for ltru@ietf.org; Tue, 13 Sep 2005 11:48:05 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8DFhGud005507 for ; Tue, 13 Sep 2005 11:43:17 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 13 Sep 2005 11:43:16 -0400 Date: Tue, 13 Sep 2005 11:43:16 -0400 From: "John.Cowan" To: ltru@ietf.org Subject: RE: [Ltru] Last call comments on LTRU registry andinitialization documents Message-ID: <20050913154316.GE768@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > This really is no different from the da-CO kinds of examples: they are > not particularly useful because there is no actual variant of the given > language associated with the given country, but only coincidentally, > and in principle the state of affairs in human demographics could well > change such as such a variant does actually exist. Just so. Who knows? Someday the Dine may walk in beauty in the apple fields of Fyn or beneath the modern buildings of Copenhagen. Stranger things have happened. -- It was impossible to inveigle John Cowan Georg Wilhelm Friedrich Hegel http://www.ccil.org/~cowan Into offering the slightest apology http://www.reutershealth.com For his Phenomenology. --W. H. Auden, from "People" (1953) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 13 15:35:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGYZ-0005uH-5k; Tue, 13 Sep 2005 15:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFG5B-0008SQ-9A for ltru@megatron.ietf.org; Tue, 13 Sep 2005 15:04:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06596 for ; Tue, 13 Sep 2005 15:04:22 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFG9M-0001kk-1Q for ltru@ietf.org; Tue, 13 Sep 2005 15:09:01 -0400 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EFG4i-0001Ol-TP; Tue, 13 Sep 2005 12:04:14 -0700 Message-Id: <6.2.3.4.2.20050913112741.050305a0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 13 Sep 2005 21:04:01 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: iesg@iesg.org Subject: [Ltru] Versailles meeting X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org FYI, the face to face meeting in Versailles I announced in my June 22nd, 2005 mail has been hold today. I had also invited those of the WG-ltru wanting to attend (copy of my mail after Addison's "troll" welcome to Dr. Charles). It was also attended by some conference calls. Here is the central part of the report. This meeting only represents its participants not their organisations. 1. examination of the impossibility of a generalised end to end interoperability in using WG-ltru proposed langtags due to necessary information not being conveyed from author to reader (referent, context, date of the registry version). 2. consideration of the now publicly known competition of major stakeholders' groups over a de facto exclusive on "langtag" management. The different motivations (printing industry global problems, OS area control, IANA control, racial/cultural profiling, shaping the world, etc.) have been discussed. General agreement is that only a user-centric open architecture Multilingual Internet can address this situation and prevent the Internet balkanisation the "internationalisation", and its resulting commercial confusion, leads back to. 3. analysis of the Draft authors' and Peter Constable's "langtag" concept. The conclusion was that unfortunately: - this vision is foreign to networking. - this vision is foreign to multilingualism and not even fully "internationalised". - there is little hope of an improvement in a near future since the number of contributors is extremely low and none of the really concerned stakeholders (non-koine mother tongue literary and cultural academics, artists, searcher, authors, trainers, etc.. related industries and consumers from every country) is involved or informed. 4. commendation of JFC Morfin, for his WG-ltru endeavor to obtain a far clearer Draft than in December and for publicly exposing the commercial interests behind the Draft, and of those who contributed in gaining the interest or support of Governments, organisations or coporations. 5. consensus to proceed according to June 22nd's agreement (JFC's mail): - the prepared langroot file should be put online. It should progressively document the five elements currently analysed as needed by end to end interoperability and brain to brain interintelligibility: language, mode, community, referent and context. - to pursue the effort of the participants towards an independent entity assuming an open registration service until it may become a IANA open process. AFRAC will temporarily assume project leadership (JFCM abstained on this very last point) - to develop the registry management and necessary presentation tools. - to organise a http://langroot.org access engine based upon the langroot and - to support its specialised replication for ISO 11179 compliant projects - to use it together with the AFRAC experimentation as a part of the common DRS (distributed registry system) R&D work. - to maintain a documentation of that effort via the IETF, and other SDOs and international entities, informational Drafts and documents (rough consensus: two participants opposing that IETF is neither multicultural nor competent in multilateral areas). - to support the equal lingual opportunity declaration proposed by the NICSO (http://nicso.org/equilang.pdf) - to help the missing technical competence and R&D in networking language issues, in participating (in spite of scarce resources) into the various standardisation processes, but in trying to discourage "culturally civic" reactions. Agreement is the need is for education, not for grouped activism. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 20 14:39:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHn1f-0006nA-V0; Tue, 20 Sep 2005 14:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmhy-00014m-Rm for ltru@megatron.ietf.org; Tue, 20 Sep 2005 14:19:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20616 for ; Tue, 20 Sep 2005 14:19:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHmnp-0005dn-TX for ltru@ietf.org; Tue, 20 Sep 2005 14:25:15 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHmhr-000NKO-R8 for ltru@ietf.org; Tue, 20 Sep 2005 18:19:03 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #892 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Tue, 20 Sep 2005 18:19:03 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Tue, 20 Sep 2005 14:39:30 -0400 Subject: [Ltru] [psg.com #892] [Comment] instructions for IANA if registry becomes "too large" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org https://rt.psg.com:443/Ticket/Display.html?id=892 This is a comment. It is not sent to the Requestor(s): During IETF last call, message http://www1.ietf.org/mail-archive/web/ltru/current/msg03473.html rehashes the earlier claims. No support given for re-opening the issue, so status remains rejected. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 20 22:25:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHuIx-0002Fr-Ao; Tue, 20 Sep 2005 22:25:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHuIw-0002FA-K9 for ltru@megatron.ietf.org; Tue, 20 Sep 2005 22:25:50 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21042 for ; Tue, 20 Sep 2005 22:25:47 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050921022518.KLIS10221.mta13.adelphia.net@DEWELL>; Tue, 20 Sep 2005 22:25:18 -0400 Message-ID: <004101c5be53$af0db000$030aa8c0@DEWELL> From: "Doug Ewell" To: , "LTRU Working Group" References: <20050920161203.7770E258080@eikenes.alvestrand.no> Date: Tue, 20 Sep 2005 19:25:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA21042 Cc: Subject: [Ltru] Re: New ISO 639 item: Aromanian; Arumanian; Macedo-Romanian [; Macedo-Romanian] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org H=C3=A5vard Hjulstad wrote on ietf-languages: > The ISO 639 Registration Authorities' Joint Advisory Committee (JAC) > has decided to include in the ISO 639-2 table (alpha-3): > > Identifier: rup > English name: Aromanian; Arumanian; Macedo-Romanian; Macedo-Romanian > French name: aroumain; mac=C3=A9do-roumain > Indigenous name: arm=C3=A2neashti In accordance with section 2, item 2 of draft-ietf-ltru-initial-04, this needs to be added to the initial registry. H=C3=A5vard has already been asked about the duplication of "Macedo-Romanian." -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 01:48:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHxSx-0000hj-Km; Wed, 21 Sep 2005 01:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHxSw-0000hH-NP for ltru@megatron.ietf.org; Wed, 21 Sep 2005 01:48:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29551 for ; Wed, 21 Sep 2005 01:48:21 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHxYr-0006ZN-Hs for ltru@ietf.org; Wed, 21 Sep 2005 01:54:32 -0400 Received: from h-68-166-188-14.snvacaid.dynamic.covad.net ([68.166.188.14] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EHxSn-0002WK-00 for ltru@ietf.org; Wed, 21 Sep 2005 01:48:13 -0400 Message-ID: <008901c5be70$6eb075c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050920161203.7770E258080@eikenes.alvestrand.no> <004101c5be53$af0db000$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: New ISO 639 item: Aromanian; Arumanian; Macedo-Romanian [; Macedo-Romanian] Date: Tue, 20 Sep 2005 22:50:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - Unless there are violent objections, the editor should fold this change in (sans duplicate Macedo-Romanian) along with any others queued up. Randy, ltru co-chair -------------------------------------- From: "Doug Ewell" To: ; "LTRU Working Group" Sent: Tuesday, September 20, 2005 7:25 PM Subject: [Ltru] Re: New ISO 639 item: Aromanian; Arumanian; Macedo-Romanian [;Macedo-Romanian] Håvard Hjulstad wrote on ietf-languages: > The ISO 639 Registration Authorities' Joint Advisory Committee (JAC) > has decided to include in the ISO 639-2 table (alpha-3): > > Identifier: rup > English name: Aromanian; Arumanian; Macedo-Romanian; Macedo-Romanian > French name: aroumain; macédo-roumain > Indigenous name: armâneashti In accordance with section 2, item 2 of draft-ietf-ltru-initial-04, this needs to be added to the initial registry. Håvard has already been asked about the duplication of "Macedo-Romanian." -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 02:16:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHxpo-0000eg-Ac; Wed, 21 Sep 2005 02:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHxpm-0000dk-Dg for ltru@megatron.ietf.org; Wed, 21 Sep 2005 02:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12090 for ; Wed, 21 Sep 2005 02:11:57 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHxvj-0007D7-VI for ltru@ietf.org; Wed, 21 Sep 2005 02:18:09 -0400 Received: from h-68-166-188-14.snvacaid.dynamic.covad.net ([68.166.188.14] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EHxpj-0006FQ-00 for ltru@ietf.org; Wed, 21 Sep 2005 02:11:55 -0400 Message-ID: <00c501c5be73$bddb27a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <016801c5b27e$1db12820$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1130] IETF/LC remove rules in section 2 duplicated from registry draft Date: Tue, 20 Sep 2005 23:14:34 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - Since there hss been no further comment since I, as a technical contributor, suggested rejecting this item, I have, as WG co-chair, marked it "rejected". Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 03:05:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHyfX-0007sj-HW; Wed, 21 Sep 2005 03:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHyfV-0007qt-2V for ltru@megatron.ietf.org; Wed, 21 Sep 2005 03:05:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01379 for ; Wed, 21 Sep 2005 03:05:23 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHylT-000088-Lk for ltru@ietf.org; Wed, 21 Sep 2005 03:11:35 -0400 Received: from h-68-166-188-14.snvacaid.dynamic.covad.net ([68.166.188.14] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EHyfK-00070y-00 for ltru@ietf.org; Wed, 21 Sep 2005 03:05:15 -0400 Message-ID: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Wed, 21 Sep 2005 00:06:57 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - After carefully reviewing the extensive postings on the question of how to procede with the registry draft and the initial registry, here is how I'd like to procede, followed by a brief rationale for this recommendation. Modulo the edits already agreed: On the initial registry, I think there is rough consensus to: 1) recommend publication as an Informational RFC 2) add a note to the RFC editor at the beginning of section 3, requesting that the rest of that section be deleted, and replaced with a note saying where the current registry is to be found (or a pointer to the registry RFC, which in turn says where the registry is) On the registry document, I do not see a clear consensus, so my own judgment colors this proposed recommendation to the IESG: 1) recommend publication as BCP 2) obsoletes 3066. The pain with splitting out the matching stuff is similar with what we've gone through with RFC 1213 being exploded into a zillion pieces. If it's necessary to hold publication until the matching document is ready, I think that's a worthwhile tradeoff to avoid any ambiguity that would result from an "Updates 3066". Looking ahead, I believe we are where we always were with respect to the matching document: 1) recommending Proposed Standard when it is ready. 2) obsoletes 3066. (see above) Brief rationale: Several alternatives were presented, each with pros and cons. Ultimately, I found the arguments unpersuasive that this document could, at least in part, be considered a protocol specification. Though the BCP designation is a bit of a catch-all, it still appears to be the best fit, is in keeping with what we were instructed to produce, and would result in the least disruption when specifications that currently reference 3066 or 1766 are updated, particularly in view of the pains the WG has taken to maintain syntactic compatibility. When one looks at the specifications that reference 1766 and 3066, for example RFC 2640 or 2070, they often provide their own ABNF or other description of language tag syntax in that protocol. We've already decided to move matching into a separate, standards-track document. Negotiation is clearly application protocol specific, and is not covered by either the registry or matching drafts. Consequently, when I look at the references to the predecessor specifications, I'm left with a clear sense that what's being referenced is not a protocol specification, but rather the registry description, which,in order to describe registry operation, had to spell out some syntactic constraints. Now I'm not claiming that I've been able to review every reference everywhere, but I've seen enough to be reasonably confident of a pattern. I conclude that the document is a registry document, and that the syntax specification is for the operation of the registry, and does not constitute a protocol specification any more than any other formal registry specification would. Now, I'm not going to ask whether we're all happy with this recommendation, but is this at least something we can live with, recognizing that the IESG will probably have its own views as well? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 05:29:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI0vB-0003av-5G; Wed, 21 Sep 2005 05:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI0v9-0003ai-KD for ltru@megatron.ietf.org; Wed, 21 Sep 2005 05:29:43 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07806 for ; Wed, 21 Sep 2005 05:29:41 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EI0sh-0007mO-9V for ltru@lists.ietf.org; Wed, 21 Sep 2005 11:27:11 +0200 Received: from c-180-160-124.hh.dial.de.ignite.net ([62.180.160.124]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 11:27:11 +0200 Received: from nobody by c-180-160-124.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 11:27:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 21 Sep 2005 11:20:46 +0200 Organization: Lines: 26 Message-ID: <433125EE.105D@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-124.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #892] [Comment] instructions for IANA if registry becomes "too large" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org rt+ltru-registry@rt.psg.com wrote: > https://rt.psg.com:443/Ticket/Display.html?id=892 I was unable to access this https server for weeks - it apparently does not more support my browser (SSL3). If it's about the size of a future 3066ter registry then we disussed this already several times - the same strategy proposed by John K for 3066bis initial should also work for a future 3066ter bulk update... > No support given for re-opening the issue, so > status remains rejected. ...indeed. And for the unrelated zh-guoyu issue see: http://permalink.gmane.org/gmane.ietf.languages/1695 http://permalink.gmane.org/gmane.ietf.languages/1696 If somebody wants to "update" this deprecation from 2005-07-15 to 2005-08-31 I've no problem with it - and the new (mis)behaviour of the ticket system is far more interesting from my POV. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 06:06:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI1UH-0004Lo-Ac; Wed, 21 Sep 2005 06:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI1UF-0004I4-V7 for ltru@megatron.ietf.org; Wed, 21 Sep 2005 06:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09266 for ; Wed, 21 Sep 2005 06:05:57 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI1aE-0004sq-Dn for ltru@ietf.org; Wed, 21 Sep 2005 06:12:12 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j8LA5Lu29580; Wed, 21 Sep 2005 19:05:21 +0900 (JST) Received: from nodnsquery(133.2.210.1) by scmse1.scbb.aoyama.ac.jp via csmap id 5cbd3ea6_2a87_11da_9238_0030482533a1_630; Wed, 21 Sep 2005 19:06:22 +0900 (JST) Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j8LA3MxW006343; Wed, 21 Sep 2005 19:04:45 +0900 Message-Id: <6.0.0.20.2.20050921185948.0944a3a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 21 Sep 2005 19:01:18 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? In-Reply-To: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 16:06 05/09/21, Randy Presuhn wrote: >Now, I'm not going to ask whether we're all happy with this recommendation, >but is this at least something we can live with, recognizing that the IESG >will probably have its own views as well? [personal opinion] I can not only live with this recommendation, I believe it's the best proposal we can make, for many reasons. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 07:55:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3Ch-0008Ta-9u; Wed, 21 Sep 2005 07:55:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3Cg-0008TV-Oz for ltru@megatron.ietf.org; Wed, 21 Sep 2005 07:55:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14051 for ; Wed, 21 Sep 2005 07:55:58 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI3Ih-0007cI-EE for ltru@ietf.org; Wed, 21 Sep 2005 08:02:12 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8LBta9c028361; Wed, 21 Sep 2005 07:55:36 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 21 Sep 2005 07:55:36 -0400 Date: Wed, 21 Sep 2005 07:55:36 -0400 From: "John.Cowan" To: Doug Ewell Subject: Re: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu Message-ID: <20050921115536.GB9188@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0CDF5DC5@irvmbxw01.quest.com> <007d01c5be6f$5043e000$7f1afea9@oemcomputer> <008901c5be75$472b5380$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008901c5be75$472b5380$030aa8c0@DEWELL> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > 2. It would probably be about 0.1% more correct to change the date of > deprecation for zh-guoyu to either 2005-08-30, the date proposed by John > Cowan on his registration form, or 2005-09-09, the date that IANA > informed John that his request had been approved. However, this is a > really, really minor detail that has no practical impact on anything, > and should not get in the way of moving the drafts along. I don't care > which decision is made here. I think we should leave the draft alone, for two reasons: 1) Because the issue is, as Doug says, of no practical import; 2) So as not to suggest that there was a period of time, however brief, when there was no undeprecated code for the largest (individual) language in the world. -- Newbies always ask: John Cowan "Elements or attributes? http://www.ccil.org/~cowan Which will serve me best?" http://www.reutershealth.com Those who know roar like lions; jcowan@reutershealth.com Wise hackers smile like tigers. --a tanka, or extended haiku _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 07:58:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3F8-0000xR-5F; Wed, 21 Sep 2005 07:58:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3F6-0000vi-Dj for ltru@megatron.ietf.org; Wed, 21 Sep 2005 07:58:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14251 for ; Wed, 21 Sep 2005 07:58:27 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI3L7-0007io-1a for ltru@ietf.org; Wed, 21 Sep 2005 08:04:42 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8LBwIXK028454; Wed, 21 Sep 2005 07:58:18 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 21 Sep 2005 07:58:18 -0400 Date: Wed, 21 Sep 2005 07:58:17 -0400 From: "John.Cowan" To: Randy Presuhn Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? Message-ID: <20050921115817.GC9188@NYCMJCOWA2> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > After carefully reviewing the extensive postings on the question > of how to procede with the registry draft and the initial registry, > here is how I'd like to procede, followed by a brief rationale for > this recommendation. [snip] > particularly in view of the pains the WG has taken to maintain > syntactic compatibility. And semantic compatibility as well: the interpretation of every existing tag remains the same. -- Take two turkeys, one goose, four John Cowan cabbages, but no duck, and mix them http://www.ccil.org/~cowan together. After one taste, you'll duck jcowan@reutershealth.com soup the rest of your life. http://www.reutershealth.com --Groucho _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 08:03:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3KQ-0002Do-Dx; Wed, 21 Sep 2005 08:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3KQ-0002Dj-0Z for ltru@megatron.ietf.org; Wed, 21 Sep 2005 08:03:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14739 for ; Wed, 21 Sep 2005 08:03:57 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI3QQ-0007tE-Ot for ltru@ietf.org; Wed, 21 Sep 2005 08:10:12 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8LC3l0w028505; Wed, 21 Sep 2005 08:03:47 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 21 Sep 2005 08:03:47 -0400 Date: Wed, 21 Sep 2005 08:03:47 -0400 From: "John.Cowan" To: Randy Presuhn Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? Message-ID: <20050921120347.GD9188@NYCMJCOWA2> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> <20050921115817.GC9188@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921115817.GC9188@NYCMJCOWA2> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John.Cowan scripsit: > Randy Presuhn scripsit: > > > After carefully reviewing the extensive postings on the question > > of how to procede with the registry draft and the initial registry, > > here is how I'd like to procede, followed by a brief rationale for > > this recommendation. > > [snip] Arrgh. I meant to insert "+1" somewhere in there. -- The Imperials are decadent, 300 pound John Cowan free-range chickens (except they have http://www.reutershealth.com teeth, arms instead of wings, and http://www.ccil.org/~cowan dinosaurlike tails). --Elyse Grasso _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 10:53:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5yR-0004Xh-HZ; Wed, 21 Sep 2005 10:53:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5yQ-0004Xc-EE for ltru@megatron.ietf.org; Wed, 21 Sep 2005 10:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25679 for ; Wed, 21 Sep 2005 10:53:24 -0400 (EDT) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI64S-0004Ik-HM for ltru@ietf.org; Wed, 21 Sep 2005 10:59:41 -0400 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050921145310.IZFV12165.mta10.adelphia.net@DEWELL>; Wed, 21 Sep 2005 10:53:10 -0400 Message-ID: <00c101c5bebc$08dc1fa0$030aa8c0@DEWELL> From: "Doug Ewell" To: "Brian E Carpenter" References: <20050920161203.7770E258080@eikenes.alvestrand.no> <004101c5be53$af0db000$030aa8c0@DEWELL> <43316C03.9040603@zurich.ibm.com> Date: Wed, 21 Sep 2005 07:52:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: [Ltru] Re: New ISO 639 item: Aromanian; Arumanian; Macedo-Romanian [; Macedo-Romanian] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Brian E Carpenter wrote: > This seems a bit detailed for the IETF main list Sorry for the breach. The document to which I was proposing a change is in IETF Last Call, and that being the case, I thought it would have been inappropriate to mention the proposed change only on the WG list. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 11:00:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI655-0005ol-AV; Wed, 21 Sep 2005 11:00:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI653-0005oV-6w for ltru@megatron.ietf.org; Wed, 21 Sep 2005 11:00:17 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26274 for ; Wed, 21 Sep 2005 11:00:14 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050921145945.JJYG12165.mta10.adelphia.net@DEWELL>; Wed, 21 Sep 2005 10:59:45 -0400 Message-ID: <00cf01c5bebc$f56cbb40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0CDF5DC5@irvmbxw01.quest.com> <007d01c5be6f$5043e000$7f1afea9@oemcomputer> <008901c5be75$472b5380$030aa8c0@DEWELL> <20050921115536.GB9188@NYCMJCOWA2> Subject: Re: [Ltru] Re: [psg.com #1131] IETF/LC update entry for zh-guoyu Date: Wed, 21 Sep 2005 07:58:41 -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 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John.Cowan wrote: > I think we should leave the draft alone, for two reasons: > ... > 2) So as not to suggest that there was a period of time, however > brief, when there was no undeprecated code for the largest > (individual) language in the world. Actually, I think the situation is the opposite. The proposal was to leave the Added date of zh-cmn at 2005-07-15, but move the Deprecated date of zh-guoyu to something later. During the resulting interval, there would have been TWO undeprecated codes for Mandarin Chinese, not zero. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 11:58:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6yv-0006eh-AS; Wed, 21 Sep 2005 11:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6yu-0006eV-Nk for ltru@megatron.ietf.org; Wed, 21 Sep 2005 11:58:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00900 for ; Wed, 21 Sep 2005 11:57:52 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI74q-0006aU-LO for ltru@ietf.org; Wed, 21 Sep 2005 12:04:11 -0400 Received: from alvmbxw02.prod.quest.corp ([10.1.0.209]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 08:57:39 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by alvmbxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 08:57:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? Date: Wed, 21 Sep 2005 08:54:37 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? thread-index: AcW+euHou9AfwoMZT9iEMOT35jjMRwASMDxA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 21 Sep 2005 15:57:38.0226 (UTC) FILETIME=[308C4120:01C5BEC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org +1 in general, but... I'm.... confused. Are you recommending that draft-registry be published as a BCP but not = "Obsoletes: 3066" until the matching draft is in some advanced state? Or = are you recommending that draft-registry be published as BCP and = immediately Obsoletes: 3066, with the matching draft to follow? If the former, wouldn't we have a potentially long interregnum period = where both registries are operated (to the confusion of everyone)? If = so, I again note the example I cited in the Last Call of RFC 3282 (both = it and RFC 3066 obsolete 1766, but on different days and for different = purposes). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: Wednesday, September 21, 2005 12:07 AM > To: LTRU Working Group > Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? >=20 > Hi - >=20 > After carefully reviewing the extensive postings on the question > of how to procede with the registry draft and the initial registry, > here is how I'd like to procede, followed by a brief rationale for > this recommendation. >=20 > Modulo the edits already agreed: >=20 > On the initial registry, I think there is rough consensus to: > 1) recommend publication as an Informational RFC > 2) add a note to the RFC editor at the beginning of > section 3, requesting that the rest of that section > be deleted, and replaced with a note saying where the > current registry is to be found (or a pointer to > the registry RFC, which in turn says where the registry is) >=20 > On the registry document, I do not see a clear consensus, so my own > judgment colors this proposed recommendation to the IESG: > 1) recommend publication as BCP > 2) obsoletes 3066. The pain with splitting out the matching > stuff is similar with what we've gone through with RFC 1213 > being exploded into a zillion pieces. If it's necessary > to hold publication until the matching document is ready, I = think > that's a worthwhile tradeoff to avoid any ambiguity that > would result from an "Updates 3066". >=20 > Looking ahead, I believe we are where we always were with respect > to the matching document: > 1) recommending Proposed Standard when it is ready. > 2) obsoletes 3066. (see above) >=20 > Brief rationale: > Several alternatives were presented, each with pros and cons. > Ultimately, I found the arguments unpersuasive that this document > could, at least in part, be considered a protocol specification. > Though the BCP designation is a bit of a catch-all, it still > appears to be the best fit, is in keeping with what we were > instructed to produce, and would result in the least disruption > when specifications that currently reference 3066 or 1766 are updated, > particularly in view of the pains the WG has taken to maintain > syntactic compatibility. >=20 > When one looks at the specifications that reference 1766 and 3066, > for example RFC 2640 or 2070, they often provide their own > ABNF or other description of language tag syntax in that protocol. > We've already decided to move matching into a separate, = standards-track > document. Negotiation is clearly application protocol specific, and > is not covered by either the registry or matching drafts. = Consequently, > when I look at the references to the predecessor specifications, > I'm left with a clear sense that what's being referenced is not a > protocol specification, but rather the registry description, which,in > order to describe registry operation, had to spell out some syntactic > constraints. Now I'm not claiming that I've been able to review every > reference everywhere, but I've seen enough to be reasonably confident > of a pattern. I conclude that the document is a registry document, = and > that the syntax specification is for the operation of the registry, > and does not constitute a protocol specification any more than any = other > formal registry specification would. >=20 > Now, I'm not going to ask whether we're all happy with this = recommendation, > but is this at least something we can live with, recognizing that the = IESG > will probably have its own views as well? >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 12:32:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7Vy-0000r3-Aj; Wed, 21 Sep 2005 12:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5S6-0003Kf-Fl for ltru@megatron.ietf.org; Wed, 21 Sep 2005 10:20:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23665 for ; Wed, 21 Sep 2005 10:20:00 -0400 (EDT) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI5Y6-0003Rq-TL for ltru@ietf.org; Wed, 21 Sep 2005 10:26:17 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j8LEJoea125472 for ; Wed, 21 Sep 2005 14:19:50 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8LEJohE224146 for ; Wed, 21 Sep 2005 15:19:50 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j8LEJnED013733 for ; Wed, 21 Sep 2005 15:19:50 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j8LEJnU1013730; Wed, 21 Sep 2005 15:19:49 +0100 Received: from zurich.ibm.com (sig-9-146-223-194.de.ibm.com [9.146.223.194]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA66710; Wed, 21 Sep 2005 16:19:48 +0200 Message-ID: <43316C03.9040603@zurich.ibm.com> Date: Wed, 21 Sep 2005 16:19:47 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Doug Ewell References: <20050920161203.7770E258080@eikenes.alvestrand.no> <004101c5be53$af0db000$030aa8c0@DEWELL> In-Reply-To: <004101c5be53$af0db000$030aa8c0@DEWELL> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.uk.ibm.com id j8LEJoea125472 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 21 Sep 2005 12:32:08 -0400 Cc: LTRU Working Group Subject: [Ltru] Re: New ISO 639 item: Aromanian; Arumanian; Macedo-Romanian [; Macedo-Romanian] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This seems a bit detailed for the IETF main list Brian Doug Ewell wrote: > H=C3=A5vard Hjulstad wrote on ietf-languages: >=20 >=20 >>The ISO 639 Registration Authorities' Joint Advisory Committee (JAC) >>has decided to include in the ISO 639-2 table (alpha-3): >> >>Identifier: rup >>English name: Aromanian; Arumanian; Macedo-Romanian; Macedo-Romanian >>French name: aroumain; mac=C3=A9do-roumain >>Indigenous name: arm=C3=A2neashti >=20 >=20 > In accordance with section 2, item 2 of draft-ietf-ltru-initial-04, thi= s > needs to be added to the initial registry. >=20 > H=C3=A5vard has already been asked about the duplication of > "Macedo-Romanian." >=20 > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 12:32:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7Wa-0000un-Sc; Wed, 21 Sep 2005 12:32:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI59z-0006Uw-KM for ltru@megatron.ietf.org; Wed, 21 Sep 2005 10:01:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21698 for ; Wed, 21 Sep 2005 10:01:18 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI5G1-0002uS-OZ for ltru@ietf.org; Wed, 21 Sep 2005 10:07:34 -0400 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EI59q-00047B-0J; Wed, 21 Sep 2005 07:01:10 -0700 Message-Id: <6.2.3.4.2.20050921111121.03cc46d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 21 Sep 2005 16:01:03 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: Délégué Général Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? In-Reply-To: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 X-Mailman-Approved-At: Wed, 21 Sep 2005 12:32:48 -0400 Cc: iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 09:06 21/09/2005, Randy Presuhn wrote: >Now, I'm not going to ask whether we're all happy with this >recommendation, but is this at least something we can live with, >recognizing that the IESG will probably have its own views as well? Dear Randy (and Martin), I appreciate the thinking effort, but I am afraid this is not a solution we all can live with. But not for the reasons you discuss. RFC 1766, 3066 etc. express a constant and consistent policy documented by Harald Alvestrand which is referred to as "internationalisation". As such it acceptable to say that "internationalisation" is a part of the Internet standard process and can be described by a BCP. But the WG-ltru charter identifies that the usage of RFC 3066 is inadequate, calls corrections and gives some hints. Let consider BCP 47. It identifies a need (language identification), a way to address it (tagging), a lose description of how to do it (protocol), how to support it (registry), how to use it (filtering). There are three possible problem diagnosis I think of: 1. RFC 3066 only proposes a limited support of internationalisation (less than 92 registrations in 10.5 years). Let expand it. 2. RFC 3066 is correct but it is incomplete so we have to better work on it. 3. RFC 3066 addresses internationalisation but if internationalisation participates into it it is not what the user eventually need, so let comprehend and address the whole problem. The problem is that commercial/strategic interests/inclinations made you decide diagnosis 2 exclusive. The prescription should therefore be exclusive and final. The wording/ABNF takes care of the exclusive, the BCP nature of the immediate standard. I think the three diagnosis are true. 1. RFC 3066 does not address all the Internet language related needs. A simple proof is the ".cat" lgTLD. 2. in extending the documentation of the RFC 3066 different aspects, one breaks the BCP nature and equilibrium. The same as filtering is PS, the same the ABNF is a PS protocol: it carries registry supported information to be used to manage an interchange (and to be used by a PS filtering). That it can also be used in document classification and in search engines (creating security risks for the users),does not change that language tags are male plugs to fit female plugs which are filters. Their purpose is to carry network information: aside of SMTP From, To; Subject, there are Language: Script: Region:. There is no problem in removing the ABNF - and possibly the registry management, or adding ways the Internet standard process is to consider the language aspects, the way IAB guidance is necessary for a few points, etc... . This keeps defining the Multilingual Internet as BCP 47. 3. where we really oppose is that the constrained RFC 3066 approach does not scale. Real world analysis shows there are three demanded architectural layers. Question is probably to understand which ones are part of the IETF scope. But they must not be denied services. - (1) end to end interoperability. This is internationalisation (or localisation). CLDR assumes it is based upon language/script/country. I am not convinced: there are many other localisation needs. But we agree it concerns the computer end and infrastructure. - (2) brain to brain interintelligibility. This is what we call multilingualisation. This means to address networked languages as spoken, written, sung, signed, etc. languages are considered (however it is probably much more complex). As brain to brain information exchange protocols. It considers a person knowing external rules (referent) exchanging with another one knowing (not necessarily sharing) the same referent. - (3) mind to mind inculturation (culture sharing). This is what we can call vernacularisation. This means to support the networked exchanges of people sharing a same context. The WG-ltru proposed is a layer violation. As every layer violation it is not easily perceived when at default. The layer 1 refers to locales (what the systems MUST share to interoperate). Layer 2 calls for a referent to be documented (what two unknown persons are to use to understand each others). Layer 3 calls for a context to be documented (what the other person MUST understand to be in full empathy). The internet default is "manufacturers English-Latn-US legal/technical usage". The proposition adds the "locale". In a nutshell: what Unicode wants to document. This means that the resulting system is adequate to support legal/technical applications in any language. Legal here includes: contracts, e-commerce forms, etc.. Technical here includes classifications, programming, e-mail, etc. This is why the proposed WG-ltru Draft: 1. is adequate for the legal/technical area in the limited XML perspective. This is why the first thing I asked was to define the area of application and let discuss how to enlarge it. 2. can be made adequate though the "0-" extension which is an existing solution able to address all the other needs even if not always in an elegant manner. This is why - seeing that we have wasted enough time in not identifying diagnosis 3 (Harald's strategy is correct at its level, support of the upper layers is to be organised) - the Versailles meeting has engaged in an entirely different approach which consists in documenting an ISO 11179 compliant logical model, able to accept the current propositions as its value domains. The problem will be to relate them through a metamodel (we named the "langroot" but which might extend to the whole Internet ontology). The problem is not simple as ISO 11179 only considers a "flat" model (metadata/data) while a decentralised system like the Internet necessarily calls on the notion of "paradata" and of information addresses. It also calls on a management insuring the unicity of datas in a given context. Something we know well with the DNS pollution. It also calls in the way to register and disseminate the information. At this stage the langroot refers around 7800 items, bridges the DNS. But its structure is not stabilised at all. We should however publish a copy soon and deploy a documentation site, in line with the time schedule I announced in May. Once we see how it stabilises, withinSO and other SSDOs we will issue a Draft. May be in November. Good luck with your position. Unless you add the "0-" half-line and permit Martin to live in peace, it will be appealed and challenged everywhere. I do not think it is your target. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 12:32:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7Wb-0000vF-3c; Wed, 21 Sep 2005 12:32:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI64g-0005jo-Cf for ltru@megatron.ietf.org; Wed, 21 Sep 2005 10:59:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26246 for ; Wed, 21 Sep 2005 10:59:52 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI6Ai-0004Zz-9r for ltru@ietf.org; Wed, 21 Sep 2005 11:06:09 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8LExhOI135366 for ; Wed, 21 Sep 2005 14:59:43 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8LExhxI155270 for ; Wed, 21 Sep 2005 16:59:43 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8LExhu0024920 for ; Wed, 21 Sep 2005 16:59:43 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8LExgXF024894; Wed, 21 Sep 2005 16:59:42 +0200 Received: from zurich.ibm.com (sig-9-146-223-194.de.ibm.com [9.146.223.194]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA36028; Wed, 21 Sep 2005 16:59:41 +0200 Message-ID: <4331755C.8030008@zurich.ibm.com> Date: Wed, 21 Sep 2005 16:59:40 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Doug Ewell References: <20050920161203.7770E258080@eikenes.alvestrand.no> <004101c5be53$af0db000$030aa8c0@DEWELL> <43316C03.9040603@zurich.ibm.com> <00c101c5bebc$08dc1fa0$030aa8c0@DEWELL> In-Reply-To: <00c101c5bebc$08dc1fa0$030aa8c0@DEWELL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 21 Sep 2005 12:32:47 -0400 Cc: LTRU Working Group Subject: [Ltru] Re: New ISO 639 item: Aromanian; Arumanian; Macedo-Romanian [; Macedo-Romanian] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Brian E Carpenter wrote: > > >>This seems a bit detailed for the IETF main list > > > Sorry for the breach. The document to which I was proposing a change is > in IETF Last Call, and that being the case, I thought it would have been > inappropriate to mention the proposed change only on the WG list. Oh, I see, though I suppose this sort of update is routine. Brian _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 12:54:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7rA-0006a9-IE; Wed, 21 Sep 2005 12:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7r8-0006Zr-4s for ltru@megatron.ietf.org; Wed, 21 Sep 2005 12:54:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04383 for ; Wed, 21 Sep 2005 12:53:58 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI7x8-0008Jd-29 for ltru@ietf.org; Wed, 21 Sep 2005 13:00:17 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI7qt-0007Aa-00 for ltru@ietf.org; Wed, 21 Sep 2005 12:53:47 -0400 Message-ID: <000401c5becd$6899a500$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <433125EE.105D@xyzzy.claranet.de> Date: Wed, 21 Sep 2005 09:56:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] Trouble ticket problems? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Frank - > From: "Frank Ellermann" > To: > Sent: Wednesday, September 21, 2005 2:20 AM > Subject: [Ltru] Re: [psg.com #892] [Comment] instructions for IANA if registry becomes "too large" ... > and the new (mis)behaviour of the ticket system is > far more interesting from my POV. ... What do you see as misbehaviour? I've had no problem accessing https://rt.psg.com/ using Mozilla Firefox and Microsoft Internet Explorer. My browsers claim there is a problem with the CA root for the security certificate, but that appears to be a comment on the set of companies I choose to trust, rather than the site itself. This tracker is used by several working groups as well as the MIB doctors. It's in the inventory of working group tools listed at http://tools.ietf.org/inventory/wg-tools If you think we (the IETF) should find a replacement, that's really beyond the scope of this list, and I suggest taking the discussion to https://www1.ietf.org/mailman/listinfo/tools-discuss Everyone: AND PLEASE, IF YOU'RE GOING TO POST ON MULTIPLE TOPICS, PLEASE USE SEPARATE MESSAGES WITH APPROPRIATE SUBJECT LINES, PLEASE! Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 12:59:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7wG-00006U-S5; Wed, 21 Sep 2005 12:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7wC-00006P-OV for ltru@megatron.ietf.org; Wed, 21 Sep 2005 12:59:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04601 for ; Wed, 21 Sep 2005 12:59:14 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI82F-0008SU-Tv for ltru@ietf.org; Wed, 21 Sep 2005 13:05:33 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 21 Sep 2005 12:59:05 -0400 id 0037035D.43319159.00002ECA From: "Scott Hollenbeck" To: "'Brian E Carpenter'" , "'Doug Ewell'" Subject: RE: [Ltru] Re: New ISO 639 item: Aromanian; Arumanian; Macedo-Romanian [; Macedo-Romanian] Date: Wed, 21 Sep 2005 12:59:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4331755C.8030008@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcW+zTjFGxtQuWJJQVi1Maa1KtUOdAAADn2w Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Wednesday, September 21, 2005 11:00 AM > To: Doug Ewell > Cc: LTRU Working Group > Subject: [Ltru] Re: New ISO 639 item: Aromanian; Arumanian; > Macedo-Romanian [;Macedo-Romanian] > > Doug Ewell wrote: > > Brian E Carpenter wrote: > > > > > >>This seems a bit detailed for the IETF main list > > > > > > Sorry for the breach. The document to which I was > proposing a change is > > in IETF Last Call, and that being the case, I thought it > would have been > > inappropriate to mention the proposed change only on the WG list. > > Oh, I see, though I suppose this sort of update is routine. The IETF last call ended on 6 September: http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01496.html -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 13:09:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI85z-0003Da-KH; Wed, 21 Sep 2005 13:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI85y-0003DM-5t for ltru@megatron.ietf.org; Wed, 21 Sep 2005 13:09:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05224 for ; Wed, 21 Sep 2005 13:09:19 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8C1-0000IG-Av for ltru@ietf.org; Wed, 21 Sep 2005 13:15:38 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8LH93IX002340 for ; Wed, 21 Sep 2005 13:09:03 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8LH938D093396 for ; Wed, 21 Sep 2005 13:09:03 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8LH8qD6000950 for ; Wed, 21 Sep 2005 13:08:53 -0400 Received: from [127.0.0.1] (dyn9052067117.cupertino.ibm.com [9.52.67.117]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8LH8oOC032604; Wed, 21 Sep 2005 13:08:52 -0400 Message-ID: <43319397.5080202@icu-project.org> Date: Wed, 21 Sep 2005 10:08:39 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> <6.0.0.20.2.20050921185948.0944a3a0@localhost> In-Reply-To: <6.0.0.20.2.20050921185948.0944a3a0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I assume Martin is speaking to Randy's text below. And I agree with Martin. > Looking ahead, I believe we are where we always were with respect > to the matching document: > 1) recommending Proposed Standard when it is ready. > 2) obsoletes 3066. (see above) Martin Duerst wrote: > At 16:06 05/09/21, Randy Presuhn wrote: > > >Now, I'm not going to ask whether we're all happy with this > recommendation, > >but is this at least something we can live with, recognizing that the > IESG > >will probably have its own views as well? > > [personal opinion] > > I can not only live with this recommendation, I believe > it's the best proposal we can make, for many reasons. > > Regards, Martin. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 13:14:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8At-00040u-Vd; Wed, 21 Sep 2005 13:14:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8As-00040j-2i for ltru@megatron.ietf.org; Wed, 21 Sep 2005 13:14:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05369 for ; Wed, 21 Sep 2005 13:14:23 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8Gs-0000PI-8L for ltru@ietf.org; Wed, 21 Sep 2005 13:20:42 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI8Aj-0005qx-00 for ltru@ietf.org; Wed, 21 Sep 2005 13:14:17 -0400 Message-ID: <002301c5bed0$474f9500$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? Date: Wed, 21 Sep 2005 10:17:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Wednesday, September 21, 2005 8:54 AM > Subject: RE: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? > > +1 in general, but... > > I'm.... confused. > > Are you recommending that draft-registry be published as a BCP but not > "Obsoletes: 3066" until the matching draft is in some advanced state? No. > Or are you recommending that draft-registry be published as BCP and > immediately Obsoletes: 3066, with the matching draft to follow? Not exactly. If the IESG would accept this, this would be my preference. Otherwise, I believe it would be acceptable to defer publication of the BCP until the matching draft was a Proposed Standard. It's slated to be done in October, and there is currently only one open issue on that document. If folks think there is more work to be done there (and I suspect there is) they'd better start working on it. (In a different thread.) > If the former, wouldn't we have a potentially long interregnum period > where both registries are operated (to the confusion of everyone)? That's why I would NOT make such a recommendation. That is why I consider it important to make it totally clear that 3066 is Obsoleted, and not merely Updated. > If so, I again note the example I cited in the Last Call of RFC 3282 > (both it and RFC 3066 obsolete 1766, but on different days and for > different purposes). ... This supports my preference for "Obsoletes: 3066" on publication. This is issue #1134 in https://rt.psg.com/ (user/password "ietf") Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 13:22:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8IS-0005nM-2y; Wed, 21 Sep 2005 13:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8IQ-0005lr-3O for ltru@megatron.ietf.org; Wed, 21 Sep 2005 13:22:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05912 for ; Wed, 21 Sep 2005 13:22:06 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8OO-0000ed-RJ for ltru@ietf.org; Wed, 21 Sep 2005 13:28:26 -0400 Received: from irvmbxw02.prod.quest.corp ([10.1.2.203]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 10:21:49 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvmbxw02.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Sep 2005 10:21:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? Date: Wed, 21 Sep 2005 10:21:38 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? thread-index: AcW+0HmgTIvKSWobTDSSqAqRzj0r1wAAFbUg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 21 Sep 2005 17:21:48.0970 (UTC) FILETIME=[F306A0A0:01C5BED0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Thanks. Then you have a wholehearted +1 from me on this course of = action. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: Wednesday, September 21, 2005 10:17 AM > To: LTRU Working Group > Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than = BCP? >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Randy Presuhn" ; "LTRU Working = Group" > > > Sent: Wednesday, September 21, 2005 8:54 AM > > Subject: RE: [Ltru] Re: [psg.com #1135] IETF/LC something other than = BCP? > > >=20 > > +1 in general, but... > > > > I'm.... confused. > > > > Are you recommending that draft-registry be published as a BCP but = not > > "Obsoletes: 3066" until the matching draft is in some advanced = state? >=20 > No. >=20 > > Or are you recommending that draft-registry be published as BCP and > > immediately Obsoletes: 3066, with the matching draft to follow? >=20 > Not exactly. > If the IESG would accept this, this would be my preference. >=20 > Otherwise, I believe it would be acceptable to defer publication > of the BCP until the matching draft was a Proposed Standard. > It's slated to be done in October, and there is currently only one > open issue on that document. If folks think there is more work > to be done there (and I suspect there is) they'd better start working > on it. (In a different thread.) >=20 > > If the former, wouldn't we have a potentially long interregnum = period > > where both registries are operated (to the confusion of everyone)? >=20 > That's why I would NOT make such a recommendation. > That is why I consider it important to make it totally clear that > 3066 is Obsoleted, and not merely Updated. >=20 > > If so, I again note the example I cited in the Last Call of RFC 3282 > > (both it and RFC 3066 obsolete 1766, but on different days and for > > different purposes). > ... >=20 > This supports my preference for "Obsoletes: 3066" on publication. > This is issue #1134 in https://rt.psg.com/ (user/password "ietf") >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 13:39:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8Z7-0004Za-8z; Wed, 21 Sep 2005 13:39:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8Z5-0004ZV-RU for ltru@megatron.ietf.org; Wed, 21 Sep 2005 13:39:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07069 for ; Wed, 21 Sep 2005 13:39:26 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8f5-0001Dp-8q for ltru@ietf.org; Wed, 21 Sep 2005 13:45:43 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI8Ys-0006QD-00 for ltru@ietf.org; Wed, 21 Sep 2005 13:39:15 -0400 Message-ID: <004201c5bed3$c45663a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0CDF5DC5@irvmbxw01.quest.com><007d01c5be6f$5043e000$7f1afea9@oemcomputer><008901c5be75$472b5380$030aa8c0@DEWELL><20050921115536.GB9188@NYCMJCOWA2> <00cf01c5bebc$f56cbb40$030aa8c0@DEWELL> Subject: Re: [Ltru] [psg.com #1131] IETF/LC update entry for zh-guoyu Date: Wed, 21 Sep 2005 10:41:58 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt says: %% Type: grandfathered Tag: zh-guoyu Description: Mandarin or Standard Chinese Added: 1999-12-18 Preferred-Value: zh-cmn Deprecated: 2005-07-15 %% Since there appears to be no agreement on a specific change, I'm marking this item "rejected". If you believe further discussion is needed, PLEASE supply the EXACT replacement text you would propose. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 13:41:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8bF-0004sF-Ut; Wed, 21 Sep 2005 13:41:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8bE-0004s7-SX for ltru@megatron.ietf.org; Wed, 21 Sep 2005 13:41:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07148 for ; Wed, 21 Sep 2005 13:41:40 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8hG-0001Gy-Gx for ltru@ietf.org; Wed, 21 Sep 2005 13:47:57 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8LHfS5w029957; Wed, 21 Sep 2005 13:41:28 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 21 Sep 2005 13:41:27 -0400 Date: Wed, 21 Sep 2005 13:41:27 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? Message-ID: <20050921174127.GK3956@NYCMJCOWA2> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Thanks. Then you have a wholehearted +1 from me on this course of action. Ditto. -- And it was said that ever after, if any John Cowan man looked in that Stone, unless he had a jcowan@reutershealth.com great strength of will to turn it to other www.ccil.org/~cowan purpose, he saw only two aged hands withering www.reutershealth.com in flame. --"The Pyre of Denethor" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 13:58:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8rI-0001R1-B5; Wed, 21 Sep 2005 13:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8rG-0001Ql-JV for ltru@megatron.ietf.org; Wed, 21 Sep 2005 13:58:15 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07919 for ; Wed, 21 Sep 2005 13:58:12 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EI8oZ-0001gg-AN for ltru@lists.ietf.org; Wed, 21 Sep 2005 19:55:27 +0200 Received: from c-180-160-65.hh.dial.de.ignite.net ([62.180.160.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 19:55:27 +0200 Received: from nobody by c-180-160-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 19:55:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 21 Sep 2005 19:53:37 +0200 Organization: Lines: 20 Message-ID: <43319E21.E98@xyzzy.claranet.de> References: <433125EE.105D@xyzzy.claranet.de> <000401c5becd$6899a500$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Trouble ticket problems? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > What do you see as misbehaviour? "Does not work anymore with my browser" without a hint why. > My browsers claim there is a problem with the CA root Yes, it uses its own certificate, apparently new (July 11), I can accept it, but later the connection dies. > If you think we (the IETF) should find a replacement, > that's really beyond the scope of this list Fixing it as it was before could be good enough - but as long as it works for you it's not really important (the draft tracker would be a different story) Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 14:20:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9CO-0008OT-O9; Wed, 21 Sep 2005 14:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9CM-0008KP-P7; Wed, 21 Sep 2005 14:20:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08988; Wed, 21 Sep 2005 14:20:01 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9IQ-0002G1-5K; Wed, 21 Sep 2005 14:26:19 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI9CE-0002eL-00; Wed, 21 Sep 2005 14:19:54 -0400 Message-ID: <007b01c5bed9$71a756e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 21 Sep 2005 11:22:36 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ietf@ietf.org, iesg@ietf.org Subject: [Ltru] Summary of IETF last call issues on ltru registry drafts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - I'd like to thank everyone who took the time to review http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt and http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt We appreciate the thoughtful comments and discussion. The IETF last call comments touched on several issues the working group had previously discussed, as well as bringing up some new ones. I'd like to single out the GenART reviewer, Elwyn Davies, for particularly helpful comments, and John Klensin for the BCP discussion. The WG agreed to several changes to the drafts. For the most part, these were clarifications or correction of omissions that were readily agreed. There were, in my assessment, no substantive changes. The most difficult discussion was the question of whether the plan to recommend the registry description document for BCP, with the initial registry contents published as an informational RFC. The working group's plan for the registry description document remains the same, but we accepted the suggestion to include in the initial registry document a note to the RFC editor requestion the removal of the content from section 3. What would remain of this informational document would be the description of how the initial registry was generated and other historical background, but nothing that could be mistaken for the registry itself would remain. The new issues entered into the issue tracker at https://rt.psg.com/ (user and password are ietf) are: 1107 IETF/LC Transition rules (gen-art 1) resolved 1108 IETF/LC Recall of the LSR (gen-art 2) resolved 1109 IETF/LC case canonicalization in registry (gen-art 3) resolved 1110 IETF/LC define the LSR (gen-art 4) resolved 1111 IETF/LC documenting the update load (gen-art 5) rejected 1112 IETF/LC various casing issues (gen-art 7) rejected 1113 IETF/LC UN economic groupings (gen-art 8) rejected 1114 IETF/LC define the LSR (gen-art 9) resolved 1115 IETF/LC numeric ranges in the registry (gen-art 11) resolved 1116 IETF/LC maintain registration records for every single subtag (gen-art 10) resolved 1117 IETF/LC include 'grandfathered' ANBF in 'Tag' description (gen-art 12) resolved 1118 IETF/LC remove MUST from capitalization in registry requirements (gen-art 14) rejected 1119 IETF/LC give ABNF for Prefix (gen-art 15) rejected 1120 IETF/LC ungarble description of Preferred-Value (gen-art 16a) resolved 1121 IETF/LC case of the subtag in a registration (gen-art 16b) 1122 IETF/LC what happens when GF tag and new registration with different meaning collide (gen-art 17a) resolved 1123 IETF/LC make hypothetical nature of extlang registrations clear (gen-art 17b) resolved 1124 IETF/LC At least one prefix for variant (gen-art 18) resolved 1125 IETF/LC bad GF sentence in S3.2 resolved 1126 IETF/LC another GF text problem resolved 1127 IETF/LC choice of subtags in multilingual documents (gen-art 19) rejected 1128 IETF/LC clarifying what a redundant tag is (gen-art 20) resolved 1129 IETF/LC frowning on long texts (gen-art #21) resolved 1130 IETF/LC remove rules in section 2 duplicated from registry draft rejected 1131 IETF/LC update entry for zh-guoyu rejected 1135 IETF/LC something other than BCP? resolved 1136 IETF/LC add singleton for tag URIs rejected I'm note including here the (rather lengthy) list of issues that the WG had already discussed. There was not WG support for the re-opening of those issues, as no new considerations or concerns were introduced. I'm hereby asking the editors of the two documents to submit revised i-ds incorporating the agreed changes, along with any incidental editorial items they might have found. If they feel the need to run any specific wordings past the WG, they should feel free to do so. Thanks again to all who have spent so much time and energy on this effort. Randy Presuhn, ltru co-chair & document shepherd _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 14:25:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9HU-0000ys-16; Wed, 21 Sep 2005 14:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9HS-0000yn-Up for ltru@megatron.ietf.org; Wed, 21 Sep 2005 14:25:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09298 for ; Wed, 21 Sep 2005 14:25:17 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9NU-0002Pm-EK for ltru@ietf.org; Wed, 21 Sep 2005 14:31:35 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI9HK-0004N2-00 for ltru@ietf.org; Wed, 21 Sep 2005 14:25:10 -0400 Message-ID: <008701c5beda$2ef9d4c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <433125EE.105D@xyzzy.claranet.de><000401c5becd$6899a500$7f1afea9@oemcomputer> <43319E21.E98@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Trouble ticket problems? Date: Wed, 21 Sep 2005 11:27:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Frank - I think your issue really should be brought to the attention of https://www1.ietf.org/mailman/listinfo/tools-discuss I don't have sufficient knowledge or expertise to make your case there, but you might be able to alert them to the problem you've encountered in a way that would enable someone there to take action. Randy > From: "Frank Ellermann" > To: > Sent: Wednesday, September 21, 2005 10:53 AM > Subject: [Ltru] Re: Trouble ticket problems? > > Randy Presuhn wrote: > > > What do you see as misbehaviour? > > "Does not work anymore with my browser" without a hint why. > > > My browsers claim there is a problem with the CA root > > Yes, it uses its own certificate, apparently new (July 11), > I can accept it, but later the connection dies. > > > If you think we (the IETF) should find a replacement, > > that's really beyond the scope of this list > > Fixing it as it was before could be good enough - but as > long as it works for you it's not really important (the > draft tracker would be a different story) > > Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 14:31:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9N3-0002so-Ni; Wed, 21 Sep 2005 14:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9N2-0002se-K3 for ltru@megatron.ietf.org; Wed, 21 Sep 2005 14:31:04 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09512 for ; Wed, 21 Sep 2005 14:31:02 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EI9LF-0004Fi-VI for ltru@lists.ietf.org; Wed, 21 Sep 2005 20:29:13 +0200 Received: from c-180-160-65.hh.dial.de.ignite.net ([62.180.160.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 20:29:13 +0200 Received: from nobody by c-180-160-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 20:29:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 21 Sep 2005 20:25:57 +0200 Organization: Lines: 34 Message-ID: <4331A5B5.3302@xyzzy.claranet.de> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > On the initial registry, I think there is rough consensus to: > 1) recommend publication as an Informational RFC > 2) add a note to the RFC editor at the beginning of > section 3, requesting that the rest of that section > be deleted, and replaced with a note saying where the > current registry is to be found (or a pointer to > the registry RFC, which in turn says where the registry > is) Apparently there's a new language tag "rup", and so the state "waiting for AD go-ahead" substate "revised ID needed" could be used to 1) add "rup", 2) move chapter 3 to appendix A, 3) fix ToC reflecting this, 4) add a dummy link to the registry, 5) add a RfC-editor note to remove appendix A and to fix this dummy link as soon as the real IANA registry is available. John also proposed to get rid of the [record-jar] reference in this informational RfC. > 2) obsoletes 3066. [...] > 2) obsoletes 3066. (see above) Above all "obsoletes 3066"... > I'm not going to ask whether we're all happy with this > recommendation, ...the form apparently forces the AD to recommend a status. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 14:36:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9Sg-0005Ib-AH; Wed, 21 Sep 2005 14:36:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9Sf-0005I5-Ra for ltru@megatron.ietf.org; Wed, 21 Sep 2005 14:36:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10457 for ; Wed, 21 Sep 2005 14:36:49 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9Yf-0002u0-S1 for ltru@ietf.org; Wed, 21 Sep 2005 14:43:08 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI9SW-00006R-00 for ltru@ietf.org; Wed, 21 Sep 2005 14:36:44 -0400 Message-ID: <009f01c5bedb$ccda48e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> <4331A5B5.3302@xyzzy.claranet.de> Date: Wed, 21 Sep 2005 11:39:28 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Add rup? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - (Note new subject.) > From: "Frank Ellermann" > To: > Sent: Wednesday, September 21, 2005 11:25 AM > Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? ... > Apparently there's a new language tag "rup", and so the state > "waiting for AD go-ahead" substate "revised ID needed" could > be used to 1) add "rup" ... Yes. Doug is already aware of this. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 14:40:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9WA-0006Lx-ED; Wed, 21 Sep 2005 14:40:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9W8-0006KA-OP for ltru@megatron.ietf.org; Wed, 21 Sep 2005 14:40:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10656 for ; Wed, 21 Sep 2005 14:40:23 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9c6-00030K-64 for ltru@ietf.org; Wed, 21 Sep 2005 14:46:42 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI9Vz-0001C2-00 for ltru@ietf.org; Wed, 21 Sep 2005 14:40:19 -0400 Message-ID: <00a401c5bedc$4d054240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> <4331A5B5.3302@xyzzy.claranet.de> Date: Wed, 21 Sep 2005 11:43:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] Move chapter 3 of initial registry? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Wednesday, September 21, 2005 11:25 AM > Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? ... > and so the state > "waiting for AD go-ahead" substate "revised ID needed" could > be used to ... > 2) move chapter 3 to appendix A, 3) > fix ToC reflecting this, ... As a technical contributor, I'd strongly suggest that we not engage in reorganization at this time, and that we limit the change to the absolute minimum needed to accomodate the comment. Let's avoid complicating things for ourselves and our editors. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 14:43:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9Ys-00075a-9m; Wed, 21 Sep 2005 14:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9Yq-00075S-Fg for ltru@megatron.ietf.org; Wed, 21 Sep 2005 14:43:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10834 for ; Wed, 21 Sep 2005 14:43:14 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9et-00036R-SD for ltru@ietf.org; Wed, 21 Sep 2005 14:49:33 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI9Yh-00024A-00 for ltru@ietf.org; Wed, 21 Sep 2005 14:43:07 -0400 Message-ID: <00a901c5bedc$b132b4a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> <4331A5B5.3302@xyzzy.claranet.de> Date: Wed, 21 Sep 2005 11:45:51 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] Note to RFC editor in initial registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Wednesday, September 21, 2005 11:25 AM > Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? ... > and so the state > "waiting for AD go-ahead" substate "revised ID needed" could > be used to ... > 4) add a dummy link to the registry, > 5) add a RfC-editor note to remove appendix A and to fix this > dummy link as soon as the real IANA registry is available. ... Let's see what Doug proposes for the note. I'd personally prefer a reference to the registry draft, rather than putting an URL into the note in the initial registry draft. That would leave fewer opportunities for error in AUTH48. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 14:49:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9f3-0000w2-0i; Wed, 21 Sep 2005 14:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9f1-0000vx-IA for ltru@megatron.ietf.org; Wed, 21 Sep 2005 14:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11045 for ; Wed, 21 Sep 2005 14:49:37 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9l5-0003EU-5T for ltru@ietf.org; Wed, 21 Sep 2005 14:55:56 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI9ey-0004JS-00 for ltru@ietf.org; Wed, 21 Sep 2005 14:49:36 -0400 Message-ID: <00c401c5bedd$98b0ca60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer><4331A5B5.3302@xyzzy.claranet.de> <00a901c5bedc$b132b4a0$7f1afea9@oemcomputer> Subject: Re: [Ltru] Note to RFC editor in initial registry Date: Wed, 21 Sep 2005 11:52:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - By the way, John Klensin proposed that the note be something like "3. The initial contents of the registry as specified in this document are those entries in the IANA registry [IANA-registry] with a field-name of "Added" and a value of "2005-07-10". Note that [ltru-registry, Section 3.1] requires that an "Added" field appear in each registration record and that its Section 3.3(1) specifies that field must not be changed after registration." Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 14:56:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9ls-0002dK-Tm; Wed, 21 Sep 2005 14:56:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9lr-0002YQ-IV for ltru@megatron.ietf.org; Wed, 21 Sep 2005 14:56:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11350 for ; Wed, 21 Sep 2005 14:56:39 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9rs-0003Or-9F for ltru@ietf.org; Wed, 21 Sep 2005 15:02:57 -0400 Received: from h-68-166-188-165.snvacaid.dynamic.covad.net ([68.166.188.165] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EI9la-0006G3-00 for ltru@ietf.org; Wed, 21 Sep 2005 14:56:26 -0400 Message-ID: <00c901c5bede$8cc0f440$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> <4331A5B5.3302@xyzzy.claranet.de> Date: Wed, 21 Sep 2005 11:59:09 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ltru] record jar reference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Wednesday, September 21, 2005 11:25 AM > Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? ... > John also proposed to get rid of the [record-jar] reference > in this informational RfC. ... Well, the discussion as I read it lead to John saying (about the registry document): | I would recommend that, as an editorial matter, use of phrases | like "inspired by" or "derived from" would clear up a lot of | confusion before it starts, making it clear that the book is not | needed. For example, the beginning of the second paragraph of | 3.1 might read | | 'The registry will be in a text file format that is | fully specified below. This format was inspired by the | "record-jar" format [record-jar].' I think analogous editorial tweaks in the two places where the format is mentioned in the initial registry draft are less drastic than the changes needed if we eliminated the reference entirely. As I read your posts on the topic, it seemed you were arguing that giving credit to the originators of the format that inspired this one was the right thing to do. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 15:44:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAVi-0006xD-Id; Wed, 21 Sep 2005 15:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAVg-0006w4-Mh for ltru@megatron.ietf.org; Wed, 21 Sep 2005 15:44:05 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15045 for ; Wed, 21 Sep 2005 15:44:02 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EIATH-0008Uu-QB for ltru@lists.ietf.org; Wed, 21 Sep 2005 21:41:35 +0200 Received: from c-180-160-65.hh.dial.de.ignite.net ([62.180.160.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 21:41:35 +0200 Received: from nobody by c-180-160-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 21:41:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 21 Sep 2005 21:35:47 +0200 Organization: Lines: 24 Message-ID: <4331B613.3384@xyzzy.claranet.de> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> <4331A5B5.3302@xyzzy.claranet.de> <009f01c5bedb$ccda48e0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Add rup? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> 1) add "rup" > Yes. Doug is already aware of this. Sure, but I guess that Doug prefers to know that "we" (TINW) are also aware of this, with these mad IETFers - one constantly changing his name, others seriously debating BCP vs. STD, the IETF Chair trying to clean his list from everything he's not really interested in, an AD proposing to upper-case all "may" and "must", a WG Chair screaming about his "subjects", the IANA allegedly unable to add 2+2 as long as the result is 5, strange conspiracies of typesetters (time to admit it, my father was a typesetter), somebody checking ISO and UN Web pages for obscure entities like "830" or the colour of GG, despite of a WG Chair saying that it's the name of a cow, a dangerous period of about six weeks where numerous zh-cmn pages missed the opportunity to stick to zh-guoyu, a mysterious invasion of BU by NH - so yes, I fear for this author it's more like a mad ETF than an IETF, and he's happy if "we" explicitly agree on something. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 16:19:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAyy-0002ao-J0; Wed, 21 Sep 2005 16:14:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAyw-0002aY-Sn for ltru@megatron.ietf.org; Wed, 21 Sep 2005 16:14:19 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22270 for ; Wed, 21 Sep 2005 16:14:16 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EIAxv-0003CY-5I for ltru@lists.ietf.org; Wed, 21 Sep 2005 22:13:15 +0200 Received: from c-180-160-65.hh.dial.de.ignite.net ([62.180.160.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 22:13:15 +0200 Received: from nobody by c-180-160-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 22:13:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 21 Sep 2005 21:58:27 +0200 Organization: Lines: 23 Message-ID: <4331BB63.772F@xyzzy.claranet.de> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer><4331A5B5.3302@xyzzy.claranet.de> <00a901c5bedc$b132b4a0$7f1afea9@oemcomputer> <00c401c5bedd$98b0ca60$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Note to RFC editor in initial registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > By the way, John Klensin proposed that the note be something > like > "3. The initial contents of the registry as specified > in this document are those entries in the IANA registry > [IANA-registry] ^^^^^^^^^^^^^^^ That beast in the references is what I called "URL". In the "registry draft" it's only given in prose, not as a reference: | All approved registration forms are available online in the | directory http://www.iana.org/numbers.html under "languages". | The new registry MUST be listed under "Language Tags" at | , replacing the existing | registrations defined by [RFC3066]. In the "initial draft" [IANA registry] would be a reference, with the complete URL given in the references. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 16:20:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIB5P-0006c0-Pe; Wed, 21 Sep 2005 16:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIB5P-0006bZ-4E for ltru@megatron.ietf.org; Wed, 21 Sep 2005 16:20:59 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24597 for ; Wed, 21 Sep 2005 16:20:56 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EIB5F-00064n-Bx for ltru@lists.ietf.org; Wed, 21 Sep 2005 22:20:49 +0200 Received: from c-180-160-65.hh.dial.de.ignite.net ([62.180.160.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 22:20:49 +0200 Received: from nobody by c-180-160-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 22:20:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 21 Sep 2005 22:10:54 +0200 Organization: Lines: 14 Message-ID: <4331BE4E.7215@xyzzy.claranet.de> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> <4331A5B5.3302@xyzzy.claranet.de> <00c901c5bede$8cc0f440$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: record jar reference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > I think analogous editorial tweaks in the two places where > the format is mentioned in the initial registry draft are > less drastic Yes, that's also ok. At the moment the "editor's copy" of draft 13 still doesn't have a proper reference with ISBN and publisher (seriesInfo) for [record-jar]. Bye, Frank See _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 18:45:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIDLE-0006lL-WD; Wed, 21 Sep 2005 18:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIDLB-0006lB-D2 for ltru@megatron.ietf.org; Wed, 21 Sep 2005 18:45:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07805 for ; Wed, 21 Sep 2005 18:45:22 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIDRI-0005J1-94 for ltru@ietf.org; Wed, 21 Sep 2005 18:51:44 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EIDL5-0003nq-IS for ltru@ietf.org; Wed, 21 Sep 2005 15:45:19 -0700 Message-Id: <6.2.3.4.2.20050921111121.03cc46d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 22 Sep 2005 00:45:12 +0200 To: "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP? In-Reply-To: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> References: <014601c5be7b$2e7e2140$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [this mail was sent using a non approve mailbox to the list, iesg and randy - I send it back to the list] At 09:06 21/09/2005, Randy Presuhn wrote: >Now, I'm not going to ask whether we're all happy with this >recommendation, but is this at least something we can live with, >recognizing that the IESG will probably have its own views as well? Dear Randy (and Martin), I appreciate the thinking effort, but I am afraid this is not a solution we all can live with. But not for the reasons you discuss. RFC 1766, 3066 etc. express a constant and consistent policy documented by Harald Alvestrand which is referred to as "internationalisation". As such it acceptable to say that "internationalisation" is a part of the Internet standard process and can be described by a BCP. But the WG-ltru charter identifies that the usage of RFC 3066 is inadequate, calls corrections and gives some hints. Let consider BCP 47. It identifies a need (language identification), a way to address it (tagging), a lose description of how to do it (protocol), how to support it (registry), how to use it (filtering). There are three possible problem diagnosis I think of: 1. RFC 3066 only proposes a limited support of internationalisation (less than 92 registrations in 10.5 years). Let expand it. 2. RFC 3066 is correct but it is incomplete so we have to better work on it. 3. RFC 3066 addresses internationalisation but if internationalisation participates into it it is not what the user eventually need, so let comprehend and address the whole problem. The problem is that commercial/strategic interests/inclinations made you decide diagnosis 2 exclusive. The prescription should therefore be exclusive and final. The wording/ABNF takes care of the exclusive, the BCP nature of the immediate standard. I think the three diagnosis are true. 1. RFC 3066 does not address all the Internet language related needs. A simple proof is the ".cat" lgTLD. 2. in extending the documentation of the RFC 3066 different aspects, one breaks the BCP nature and equilibrium. The same as filtering is PS, the same the ABNF is a PS protocol: it carries registry supported information to be used to manage an interchange (and to be used by a PS filtering). That it can also be used in document classification and in search engines (creating security risks for the users),does not change that language tags are male plugs to fit female plugs which are filters. Their purpose is to carry network information: aside of SMTP From, To; Subject, there are Language: Script: Region:. There is no problem in removing the ABNF - and possibly the registry management, or adding ways the Internet standard process is to consider the language aspects, the way IAB guidance is necessary for a few points, etc... . This keeps defining the Multilingual Internet as BCP 47. 3. where we really oppose is that the constrained RFC 3066 approach does not scale. Real world analysis shows there are three demanded architectural layers. Question is probably to understand which ones are part of the IETF scope. But they must not be denied services. - (1) end to end interoperability. This is internationalisation (or localisation). CLDR assumes it is based upon language/script/country. I am not convinced: there are many other localisation needs. But we agree it concerns the computer end and infrastructure. - (2) brain to brain interintelligibility. This is what we call multilingualisation. This means to address networked languages as spoken, written, sung, signed, etc. languages are considered (however it is probably much more complex). As brain to brain information exchange protocols. It considers a person knowing external rules (referent) exchanging with another one knowing (not necessarily sharing) the same referent. - (3) mind to mind inculturation (culture sharing). This is what we can call vernacularisation. This means to support the networked exchanges of people sharing a same context. The WG-ltru proposed is a layer violation. As every layer violation it is not easily perceived when at default. The layer 1 refers to locales (what the systems MUST share to interoperate). Layer 2 calls for a referent to be documented (what two unknown persons are to use to understand each others). Layer 3 calls for a context to be documented (what the other person MUST understand to be in full empathy). The internet default is "manufacturers English-Latn-US legal/technical usage". The proposition adds the "locale". In a nutshell: what Unicode wants to document. This means that the resulting system is adequate to support legal/technical applications in any language. Legal here includes: contracts, e-commerce forms, etc.. Technical here includes classifications, programming, e-mail, etc. This is why the proposed WG-ltru Draft: 1. is adequate for the legal/technical area in the limited XML perspective. This is why the first thing I asked was to define the area of application and let discuss how to enlarge it. 2. can be made adequate though the "0-" extension which is an existing solution able to address all the other needs even if not always in an elegant manner. This is why - seeing that we have wasted enough time in not identifying diagnosis 3 (Harald's strategy is correct at its level, support of the upper layers is to be organised) - the Versailles meeting has engaged in an entirely different approach which consists in documenting an ISO 11179 compliant logical model, able to accept the current propositions as its value domains. The problem will be to relate them through a metamodel (we named the "langroot" but which might extend to the whole Internet ontology). The problem is not simple as ISO 11179 only considers a "flat" model (metadata/data) while a decentralised system like the Internet necessarily calls on the notion of "paradata" and of information addresses. It also calls on a management insuring the unicity of datas in a given context. Something we know well with the DNS pollution. It also calls in the way to register and disseminate the information. At this stage the langroot refers around 7800 items, bridges the DNS. But its structure is not stabilised at all. We should however publish a copy soon and deploy a documentation site, in line with the time schedule I announced in May. Once we see how it stabilises, withinSO and other SSDOs we will issue a Draft. May be in November. Good luck with your position. Unless you add the "0-" half-line and permit Martin to live in peace, it will be appealed and challenged everywhere. I do not think it is your target. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 19:34:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIE74-0004pr-Tx; Wed, 21 Sep 2005 19:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIE74-0004pB-3V for ltru@megatron.ietf.org; Wed, 21 Sep 2005 19:34:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10045 for ; Wed, 21 Sep 2005 19:34:51 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIEDA-0006Sm-OP for ltru@ietf.org; Wed, 21 Sep 2005 19:41:14 -0400 Received: from alvmbxw02.prod.quest.corp ([10.1.0.209]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 16:34:37 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by alvmbxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 16:34:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: record jar reference Date: Wed, 21 Sep 2005 16:34:25 -0700 Message-ID: Thread-Topic: [Ltru] Re: record jar reference thread-index: AcW+6nFz+sf9aPK+RcKDeqtBzA3r/wAGm4iw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 21 Sep 2005 23:34:36.0304 (UTC) FILETIME=[06FEF100:01C5BF05] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The editor's editor's copy does, but I haven't posted it yet :-). I'm still making sure that Randy's brain and mine are in sync, then I'll = post (with diffs). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Frank Ellermann > Sent: 2005?9?21? 13:11 > To: ltru@ietf.org > Subject: [Ltru] Re: record jar reference >=20 > Randy Presuhn wrote: >=20 > > I think analogous editorial tweaks in the two places where > > the format is mentioned in the initial registry draft are > > less drastic >=20 > Yes, that's also ok. At the moment the "editor's copy" of > draft 13 still doesn't have a proper reference with ISBN > and publisher (seriesInfo) for [record-jar]. >=20 > Bye, Frank >=20 > See >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 19:54:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIEQK-000211-Tc; Wed, 21 Sep 2005 19:54:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIEQJ-00020t-22 for ltru@megatron.ietf.org; Wed, 21 Sep 2005 19:54:47 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10823 for ; Wed, 21 Sep 2005 19:54:45 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EIEP3-0005N9-Pc for ltru@lists.ietf.org; Thu, 22 Sep 2005 01:53:29 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Sep 2005 01:53:29 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Sep 2005 01:53:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 22 Sep 2005 01:52:03 +0200 Organization: Lines: 16 Message-ID: <4331F223.4B4B@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: record jar reference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I'm still making sure that Randy's brain and mine are in > sync, then I'll post (with diffs). You probably are, "minimal changes" sounds like a good plan. One point where it could go wrong is if "initial" would point to "registry" for the real registry, while "registry" still points to "initial" for the same thing. And I somehow expect that the UN pages will delete 830 and/or 3166-1 will list GG+JE+IM precisely five minutes before the end of your "AUTH48". Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Sep 21 20:07:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIEcG-00045U-ME; Wed, 21 Sep 2005 20:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIEcE-00043x-L1 for ltru@megatron.ietf.org; Wed, 21 Sep 2005 20:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11361 for ; Wed, 21 Sep 2005 20:07:05 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIEiL-00074T-DW for ltru@ietf.org; Wed, 21 Sep 2005 20:13:26 -0400 Received: from IRVPFXW01.prod.quest.corp ([10.1.2.202]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 17:06:49 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by IRVPFXW01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Sep 2005 17:06:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: record jar reference Date: Wed, 21 Sep 2005 17:06:38 -0700 Message-ID: Thread-Topic: [Ltru] Re: record jar reference thread-index: AcW/B+w9osX1hNBaT5iy89PhDb5WjgAAOFCA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 22 Sep 2005 00:06:49.0406 (UTC) FILETIME=[8736E5E0:01C5BF09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Here is the change I put in for this in the body of the text: -- The registry is in a modified record-jar format text file . Lines are limited to 72 characters, = including all whitespace. Records are separated by lines containing only the sequence "%%" = (%x25.25). -- I changed it to read: -- The registry is in the text format described below. This format was = based on the record-jar format described in . Each line of text is limited to 72 characters, including all = whitespace. Records are separated by lines containing only the sequence = "%%" (%x25.25). -- Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Frank Ellermann > Sent: 2005?9?21? 16:52 > To: ltru@ietf.org > Subject: [Ltru] Re: record jar reference >=20 > Addison Phillips wrote: >=20 > > I'm still making sure that Randy's brain and mine are in > > sync, then I'll post (with diffs). >=20 > You probably are, "minimal changes" sounds like a good plan. >=20 > One point where it could go wrong is if "initial" would point > to "registry" for the real registry, while "registry" still > points to "initial" for the same thing. >=20 > And I somehow expect that the UN pages will delete 830 and/or > 3166-1 will list GG+JE+IM precisely five minutes before the > end of your "AUTH48". > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 22 16:08:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIXMa-0005vV-U4; Thu, 22 Sep 2005 16:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIXMa-0005u1-3a for ltru@megatron.ietf.org; Thu, 22 Sep 2005 16:08:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23639 for ; Thu, 22 Sep 2005 16:08:07 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIXSn-0003aw-Ac for ltru@ietf.org; Thu, 22 Sep 2005 16:14:39 -0400 Received: from IRVPFXW01.prod.quest.corp ([10.1.2.202]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 13:07:51 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by IRVPFXW01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Sep 2005 13:07:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Summary of IETF last call issues on ltru registry drafts Date: Thu, 22 Sep 2005 13:07:40 -0700 Message-ID: Thread-Topic: [Ltru] Summary of IETF last call issues on ltru registry drafts thread-index: AcW+2hMmYJtaV2RpTN6Q1a+rfMfZIwA1lfeg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 22 Sep 2005 20:07:51.0280 (UTC) FILETIME=[4F703F00:01C5BFB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The new version is posted on my personal website based on the list of = items below. There is an rfcdiff there and idnits has run cleanly. The URIs are: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-13.txt http://www.inter-locale.com/ID/draft-ietf-ltru-registry-13.html http://www.inter-locale.com/ID/draft-ietf-ltru-registry-13.xml http://www.inter-locale.com/ID/draft-registry-12-13-diff.html I am submitting this document to the I-D editor under separate cover now = too. Best Regards, Addison (for the editors) Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: 2005?9?21? 11:23 > To: LTRU Working Group > Cc: ietf@ietf.org; iesg@ietf.org > Subject: [Ltru] Summary of IETF last call issues on ltru registry = drafts >=20 > Hi - >=20 > I'd like to thank everyone who took the time to review > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt = and > http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt >=20 > We appreciate the thoughtful comments and discussion. > The IETF last call comments touched on several issues > the working group had previously discussed, as well as > bringing up some new ones. I'd like to single out the > GenART reviewer, Elwyn Davies, for particularly helpful > comments, and John Klensin for the BCP discussion. >=20 > The WG agreed to several changes to the drafts. For the > most part, these were clarifications or correction of omissions > that were readily agreed. There were, in my assessment, no > substantive changes. The most difficult discussion was > the question of whether the plan to recommend the registry > description document for BCP, with the initial registry contents > published as an informational RFC. The working group's > plan for the registry description document remains the same, > but we accepted the suggestion to include in the initial registry > document a note to the RFC editor requestion the removal of > the content from section 3. What would remain of this informational > document would be the description of how the initial registry was > generated and other historical background, but nothing that could > be mistaken for the registry itself would remain. >=20 > The new issues entered into the issue tracker at > https://rt.psg.com/ (user and password are ietf) are: >=20 > 1107 IETF/LC Transition rules (gen-art 1) resolved > 1108 IETF/LC Recall of the LSR (gen-art 2) resolved > 1109 IETF/LC case canonicalization in registry (gen-art 3) resolved > 1110 IETF/LC define the LSR (gen-art 4) resolved > 1111 IETF/LC documenting the update load (gen-art 5) rejected > 1112 IETF/LC various casing issues (gen-art 7) rejected > 1113 IETF/LC UN economic groupings (gen-art 8) rejected > 1114 IETF/LC define the LSR (gen-art 9) resolved > 1115 IETF/LC numeric ranges in the registry (gen-art 11) resolved > 1116 IETF/LC maintain registration records for every single subtag = (gen- > art 10) resolved > 1117 IETF/LC include 'grandfathered' ANBF in 'Tag' description = (gen-art 12) > resolved > 1118 IETF/LC remove MUST from capitalization in registry requirements > (gen-art 14) rejected > 1119 IETF/LC give ABNF for Prefix (gen-art 15) rejected > 1120 IETF/LC ungarble description of Preferred-Value (gen-art 16a) > resolved > 1121 IETF/LC case of the subtag in a registration (gen-art 16b) > 1122 IETF/LC what happens when GF tag and new registration with = different > meaning collide (gen-art 17a) resolved > 1123 IETF/LC make hypothetical nature of extlang registrations clear = (gen- > art 17b) resolved > 1124 IETF/LC At least one prefix for variant (gen-art 18) resolved > 1125 IETF/LC bad GF sentence in S3.2 resolved > 1126 IETF/LC another GF text problem resolved > 1127 IETF/LC choice of subtags in multilingual documents (gen-art 19) > rejected > 1128 IETF/LC clarifying what a redundant tag is (gen-art 20) resolved > 1129 IETF/LC frowning on long texts (gen-art #21) resolved > 1130 IETF/LC remove rules in section 2 duplicated from registry draft > rejected > 1131 IETF/LC update entry for zh-guoyu rejected > 1135 IETF/LC something other than BCP? resolved > 1136 IETF/LC add singleton for tag URIs rejected >=20 > I'm note including here the (rather lengthy) list of issues that the = WG > had > already discussed. There was not WG support for the re-opening of > those issues, as no new considerations or concerns were introduced. >=20 > I'm hereby asking the editors of the two documents to submit revised = i-ds > incorporating the agreed changes, along with any incidental editorial > items > they might have found. If they feel the need to run any specific = wordings > past the WG, they should feel free to do so. >=20 > Thanks again to all who have spent so much time and energy on this = effort. >=20 > Randy Presuhn, ltru co-chair & document shepherd >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 22 16:09:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIXO6-00063n-DS; Thu, 22 Sep 2005 16:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIXO4-00063b-58; Thu, 22 Sep 2005 16:09:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23681; Thu, 22 Sep 2005 16:09:29 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIXU6-0003cb-OV; Thu, 22 Sep 2005 16:16:02 -0400 Received: from irvmbxw02.prod.quest.corp ([10.1.2.203]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 13:09:18 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvmbxw02.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Sep 2005 13:09:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5BFB1.830D9848" Date: Thu, 22 Sep 2005 13:09:06 -0700 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-13 of IETF LTRU Registry... thread-index: AcW/sXw/IzA+RjTtSEuT4IibMDOPQQ== From: "Addison Phillips" To: X-OriginalArrivalTime: 22 Sep 2005 20:09:18.0336 (UTC) FILETIME=[8353F000:01C5BFB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb937148515b9cd42d759b9d078630d5 Cc: LTRU Working Group Subject: [Ltru] draft-13 of IETF LTRU Registry... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BFB1.830D9848 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGluIHRleHQgZm9ybWF0IGRyYWZ0 LWlldGYtbHRydS1yZWdpc3RyeS0xMy4NCg0KRm9yIHRoZSBlZGl0b3JzLA0KDQpBZGRpc29uDQoN CkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0 d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXph dGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwN Cg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hp dGVjdHVyZS4gDQoNCg== ------_=_NextPart_001_01C5BFB1.830D9848 Content-Type: text/plain; name="draft-ietf-ltru-registry-13.txt" Content-Description: draft-ietf-ltru-registry-13.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-13.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCk9ic29sZXRlczogMzA2NiAo aWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K RXhwaXJlczogTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjIsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTMNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBNYXJjaCAyNiwgMjAwNi4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmln aHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4NCg0KQWJzdHJhY3QNCg0KICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHN0cnVjdHVyZSwgY29udGVudCwgY29uc3RydWN0aW9u LCBhbmQNCiAgIHNlbWFudGljcyBvZiBsYW5ndWFnZSB0YWdzIGZvciB1c2UgaW4gY2FzZXMgd2hl cmUgaXQgaXMgZGVzaXJhYmxlIHRvDQogICBpbmRpY2F0ZSB0aGUgbGFuZ3VhZ2UgdXNlZCBpbiBh biBpbmZvcm1hdGlvbiBvYmplY3QuICBJdCBhbHNvDQogICBkZXNjcmliZXMgaG93IHRvIHJlZ2lz dGVyIHZhbHVlcyBmb3IgdXNlIGluIGxhbmd1YWdlIHRhZ3MgYW5kIHRoZQ0KICAgY3JlYXRpb24g b2YgdXNlciBkZWZpbmVkIGV4dGVuc2lvbnMgZm9yIHByaXZhdGUgaW50ZXJjaGFuZ2UuDQoNCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAg ICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQpUYWJsZSBvZiBD b250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIuICBUaGUgTGFuZ3VhZ2UgVGFnIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgICAyLjEgICBT eW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA0DQogICAgIDIuMiAgIExhbmd1YWdlIFN1YnRhZyBTb3VyY2VzIGFuZCBJbnRlcnByZXRhdGlv biAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgICAyLjIuMSAgIFByaW1hcnkgTGFuZ3VhZ2UgU3Vi dGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAgIDIuMi4yICAgRXh0 ZW5kZWQgTGFuZ3VhZ2UgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQog ICAgICAgMi4yLjMgICBTY3JpcHQgU3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTANCiAgICAgICAyLjIuNCAgIFJlZ2lvbiBTdWJ0YWcgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICAgIDIuMi41ICAgVmFyaWFudCBT dWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICAgICAg Mi4yLjYgICBFeHRlbnNpb24gU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTQNCiAgICAgICAyLjIuNyAgIFByaXZhdGUgVXNlIFN1YnRhZ3MgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQ0KICAgICAgIDIuMi44ICAgUHJlLUV4aXN0aW5nIFJG QyAzMDY2IFJlZ2lzdHJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQogICAgICAgMi4yLjkg ICBDbGFzc2VzIG9mIENvbmZvcm1hbmNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTYNCiAgIDMuICBSZWdpc3RyeSBGb3JtYXQgYW5kIE1haW50ZW5hbmNlICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICAzLjEgICBGb3JtYXQgb2YgdGhlIElBTkEgTGFuZ3Vh Z2UgU3VidGFnIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIDE4DQogICAgIDMuMiAgIExhbmd1YWdl IFN1YnRhZyBSZXZpZXdlciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMNCiAg ICAgMy4zICAgTWFpbnRlbmFuY2Ugb2YgdGhlIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyNA0KICAgICAzLjQgICBTdGFiaWxpdHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRy aWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DQogICAgIDMuNSAgIFJlZ2lzdHJhdGlvbiBQ cm9jZWR1cmUgZm9yIFN1YnRhZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCiAgICAgMy42 ICAgUG9zc2liaWxpdGllcyBmb3IgUmVnaXN0cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAzMQ0KICAgICAzLjcgICBFeHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIFJlZ2lzdHJ5IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMzDQogICAgIDMuOCAgIEluaXRpYWxpemF0aW9uIG9mIHRo ZSBSZWdpc3RyaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYNCiAgIDQuICBGb3JtYXRp b24gYW5kIFByb2Nlc3Npbmcgb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAz OA0KICAgICA0LjEgICBDaG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDM4DQogICAgIDQuMiAgIE1lYW5pbmcgb2YgdGhlIExhbmd1YWdlIFRh ZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDANCiAgICAgNC4zICAgTGVuZ3RoIENv bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MQ0KICAg ICAgIDQuMy4xICAgV29ya2luZyB3aXRoIExpbWl0ZWQgQnVmZmVyIFNpemVzICAuIC4gLiAuIC4g LiAuIC4gLiAuIDQxDQogICAgICAgNC4zLjIgICBUcnVuY2F0aW9uIG9mIExhbmd1YWdlIFRhZ3Mg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDMNCiAgICAgNC40ICAgQ2Fub25pY2FsaXphdGlv biBvZiBMYW5ndWFnZSBUYWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Mw0KICAgICA0LjUg ICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4g LiAuIDQ1DQogICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDcNCiAgICAgNS4xICAgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lz dHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Nw0KICAgICA1LjIgICBFeHRl bnNpb25zIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ4 DQogICA2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNDkNCiAgIDcuICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25zIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MA0KICAgOC4gIENoYW5nZXMgZnJvbSBS RkMgMzA2NiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUxDQogICA5 LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNTQNCiAgICAgOS4xICAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NA0KICAgICA5LjIgICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1DQogICAgICAgQXV0 aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNTYNCiAgIEEuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1Nw0KICAgQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3Mg KEluZm9ybWF0aXZlKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU4DQogICAgICAgSW50ZWxsZWN0 dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gNjEN Cg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAy MDA2ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KMS4g IEludHJvZHVjdGlvbg0KDQogICBIdW1hbiBiZWluZ3Mgb24gb3VyIHBsYW5ldCBoYXZlLCBwYXN0 IGFuZCBwcmVzZW50LCB1c2VkIGEgbnVtYmVyIG9mDQogICBsYW5ndWFnZXMuICBUaGVyZSBhcmUg bWFueSByZWFzb25zIHdoeSBvbmUgd291bGQgd2FudCB0byBpZGVudGlmeSB0aGUNCiAgIGxhbmd1 YWdlIHVzZWQgd2hlbiBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3JtYXRpb24uDQoNCiAg IEEgdXNlcidzIGxhbmd1YWdlIHByZWZlcmVuY2VzIG9mdGVuIG5lZWQgdG8gYmUgaWRlbnRpZmll ZCBzbyB0aGF0DQogICBhcHByb3ByaWF0ZSBwcm9jZXNzaW5nIGNhbiBiZSBhcHBsaWVkLiAgRm9y IGV4YW1wbGUsIHRoZSB1c2VyJ3MNCiAgIGxhbmd1YWdlIHByZWZlcmVuY2VzIGluIGEgV2ViIGJy b3dzZXIgY2FuIGJlIHVzZWQgdG8gc2VsZWN0IFdlYiBwYWdlcw0KICAgYXBwcm9wcmlhdGVseS4g IExhbmd1YWdlIHByZWZlcmVuY2VzIGNhbiBhbHNvIGJlIHVzZWQgdG8gc2VsZWN0IGFtb25nDQog ICB0b29scyAoc3VjaCBhcyBkaWN0aW9uYXJpZXMpIHRvIGFzc2lzdCBpbiB0aGUgcHJvY2Vzc2lu ZyBvcg0KICAgdW5kZXJzdGFuZGluZyBvZiBjb250ZW50IGluIGRpZmZlcmVudCBsYW5ndWFnZXMu DQoNCiAgIEluIGFkZGl0aW9uLCBrbm93bGVkZ2UgYWJvdXQgdGhlIHBhcnRpY3VsYXIgbGFuZ3Vh Z2UgdXNlZCBieSBzb21lDQogICBwaWVjZSBvZiBpbmZvcm1hdGlvbiBjb250ZW50IG1pZ2h0IGJl IHVzZWZ1bCBvciBldmVuIHJlcXVpcmVkIGJ5IHNvbWUNCiAgIHR5cGVzIG9mIHByb2Nlc3Npbmc7 IGZvciBleGFtcGxlIHNwZWxsLWNoZWNraW5nLCBjb21wdXRlci1zeW50aGVzaXplZA0KICAgc3Bl ZWNoLCBCcmFpbGxlIHRyYW5zY3JpcHRpb24sIG9yIGhpZ2gtcXVhbGl0eSBwcmludCByZW5kZXJp bmdzLg0KDQogICBPbmUgbWVhbnMgb2YgaW5kaWNhdGluZyB0aGUgbGFuZ3VhZ2UgdXNlZCBpcyBi eSBsYWJlbGluZyB0aGUNCiAgIGluZm9ybWF0aW9uIGNvbnRlbnQgd2l0aCBhbiBpZGVudGlmaWVy IG9yICJ0YWciLiAgVGhlc2UgdGFncyBjYW4gYmUNCiAgIHVzZWQgdG8gc3BlY2lmeSB1c2VyIHBy ZWZlcmVuY2VzIHdoZW4gc2VsZWN0aW5nIGluZm9ybWF0aW9uIGNvbnRlbnQsDQogICBvciBmb3Ig bGFiZWxpbmcgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIG9mIGNvbnRlbnQgYW5kIGFzc29jaWF0ZWQN CiAgIHJlc291cmNlcy4NCg0KICAgVGFncyBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZGljYXRlIGFk ZGl0aW9uYWwgbGFuZ3VhZ2UgYXR0cmlidXRlcyBvZg0KICAgY29udGVudC4gIEZvciBleGFtcGxl LCBpbmRpY2F0aW5nIHNwZWNpZmljIGluZm9ybWF0aW9uIGFib3V0IHRoZQ0KICAgZGlhbGVjdCwg d3JpdGluZyBzeXN0ZW0sIG9yIG9ydGhvZ3JhcGh5IHVzZWQgaW4gYSBkb2N1bWVudCBvcg0KICAg cmVzb3VyY2UgbWF5IGVuYWJsZSB0aGUgdXNlciB0byBvYnRhaW4gaW5mb3JtYXRpb24gaW4gYSBm b3JtIHRoYXQNCiAgIHRoZXkgY2FuIHVuZGVyc3RhbmQsIG9yIGltcG9ydGFudCBpbiBwcm9jZXNz aW5nIG9yIHJlbmRlcmluZyB0aGUNCiAgIGdpdmVuIGNvbnRlbnQgaW50byBhbiBhcHByb3ByaWF0 ZSBmb3JtIG9yIHN0eWxlLg0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHBhcnRpY3Vs YXIgaWRlbnRpZmllciBtZWNoYW5pc20gKHRoZQ0KICAgbGFuZ3VhZ2UgdGFnKSBhbmQgYSByZWdp c3RyYXRpb24gZnVuY3Rpb24gZm9yIHZhbHVlcyB0byBiZSB1c2VkIHRvDQogICBmb3JtIHRhZ3Mu ICBJdCBhbHNvIGRlZmluZXMgYSBtZWNoYW5pc20gZm9yIHByaXZhdGUgdXNlIHZhbHVlcyBhbmQN CiAgIGZ1dHVyZSBleHRlbnNpb24uDQoNCiAgIFRoaXMgZG9jdW1lbnQgcmVwbGFjZXMgW1JGQzMw NjZdLCB3aGljaCByZXBsYWNlZCBbUkZDMTc2Nl0uICBGb3IgYQ0KICAgbGlzdCBvZiBjaGFuZ2Vz IGluIHRoaXMgZG9jdW1lbnQsIHNlZSBTZWN0aW9uIDguDQoNCiAgIFRoZSBrZXl3b3JkcyAiTVVT VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gW1JGQzIxMTldLg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg IEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2Vw dGVtYmVyIDIwMDUNCg0KDQoyLiAgVGhlIExhbmd1YWdlIFRhZw0KDQogICBMYW5ndWFnZSB0YWdz IGFyZSB1c2VkIHRvIGhlbHAgaWRlbnRpZnkgbGFuZ3VhZ2VzLCB3aGV0aGVyIHNwb2tlbiwNCiAg IHdyaXR0ZW4sIHNpZ25lZCwgb3Igb3RoZXJ3aXNlIHNpZ25hbGVkLCBmb3IgdGhlIHB1cnBvc2Ug b2YNCiAgIGNvbW11bmljYXRpb24uICBUaGlzIGluY2x1ZGVzIGNvbnN0cnVjdGVkIGFuZCBhcnRp ZmljaWFsIGxhbmd1YWdlcywNCiAgIGJ1dCBleGNsdWRlcyBsYW5ndWFnZXMgbm90IGludGVuZGVk IHByaW1hcmlseSBmb3IgaHVtYW4NCiAgIGNvbW11bmljYXRpb24sIHN1Y2ggYXMgcHJvZ3JhbW1p bmcgbGFuZ3VhZ2VzLg0KDQoyLjEgIFN5bnRheA0KDQogICBUaGUgbGFuZ3VhZ2UgdGFnIGlzIGNv bXBvc2VkIG9mIG9uZSBvciBtb3JlIHBhcnRzIG9yICJzdWJ0YWdzIi4gIEVhY2gNCiAgIHN1YnRh ZyBjb25zaXN0cyBvZiBhIHNlcXVlbmNlIG9mIGFscGhhLW51bWVyaWMgY2hhcmFjdGVycy4gIFN1 YnRhZ3MNCiAgIGFyZSBkaXN0aW5ndWlzaGVkIGFuZCBzZXBhcmF0ZWQgZnJvbSBvbmUgYW5vdGhl ciBieSBhIGh5cGhlbiAoIi0iLA0KICAgQUJORiBbUkZDMjIzNGJpc10gJXgyRCkuICBBIGxhbmd1 YWdlIHRhZyBjb25zaXN0cyBvZiBhICJwcmltYXJ5DQogICBsYW5ndWFnZSIgc3VidGFnIGFuZCBh IChwb3NzaWJseSBlbXB0eSkgc2VyaWVzIG9mIHN1YnNlcXVlbnQgc3VidGFncywNCiAgIGVhY2gg b2Ygd2hpY2ggcmVmaW5lcyBvciBuYXJyb3dzIHRoZSByYW5nZSBvZiBsYW5ndWFnZSBpZGVudGlm aWVkIGJ5DQogICB0aGUgb3ZlcmFsbCB0YWcuDQoNCiAgIFVzdWFsbHksIGVhY2ggdHlwZSBvZiBz dWJ0YWcgaXMgZGlzdGluZ3Vpc2hlZCBieSBsZW5ndGgsIHBvc2l0aW9uIGluDQogICB0aGUgdGFn LCBhbmQgY29udGVudDogc3VidGFncyBjYW4gYmUgcmVjb2duaXplZCBzb2xlbHkgYnkgdGhlc2UN CiAgIGZlYXR1cmVzLiAgVGhlIG9ubHkgZXhjZXB0aW9uIHRvIHRoaXMgaXMgYSBmaXhlZCBsaXN0 IG9mDQogICBncmFuZGZhdGhlcmVkIHRhZ3MgcmVnaXN0ZXJlZCB1bmRlciBSRkMgMzA2NiBbUkZD MzA2Nl0uICBUaGlzIG1ha2VzDQogICBpdCBwb3NzaWJsZSB0byBjb25zdHJ1Y3QgYSBwYXJzZXIg dGhhdCBjYW4gZXh0cmFjdCBhbmQgYXNzaWduIHNvbWUNCiAgIHNlbWFudGljIGluZm9ybWF0aW9u IHRvIHRoZSBzdWJ0YWdzLCBldmVuIGlmIHRoZSBzcGVjaWZpYyBzdWJ0YWcNCiAgIHZhbHVlcyBh cmUgbm90IHJlY29nbml6ZWQuICBUaHVzIGEgcGFyc2VyIG5lZWQgbm90IGhhdmUgYW4gdXAtdG8t ZGF0ZQ0KICAgY29weSAob3IgYW55IGNvcHkgYXQgYWxsKSBvZiB0aGUgc3VidGFnIHJlZ2lzdHJ5 IHRvIHBlcmZvcm0gbW9zdA0KICAgc2VhcmNoaW5nIGFuZCBtYXRjaGluZyBvcGVyYXRpb25zLg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgIFtQ YWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBUaGUgc3ludGF4IG9mIHRoZSBsYW5n dWFnZSB0YWcgaW4gQUJORiBbUkZDMjIzNGJpc10gaXM6DQoNCiAgIExhbmd1YWdlLVRhZyAgPSBs YW5ndGFnDQogICAgICAgICAgICAgICAgIC8gcHJpdmF0ZXVzZSAgICAgICAgICAgICA7IHByaXZh dGUgdXNlIHRhZw0KICAgICAgICAgICAgICAgICAvIGdyYW5kZmF0aGVyZWQgICAgICAgICAgOyBn cmFuZGZhdGhlcmVkIHJlZ2lzdHJhdGlvbnMNCg0KICAgbGFuZ3RhZyAgICAgICA9IChsYW5ndWFn ZQ0KICAgICAgICAgICAgICAgICAgICBbIi0iIHNjcmlwdF0NCiAgICAgICAgICAgICAgICAgICAg WyItIiByZWdpb25dDQogICAgICAgICAgICAgICAgICAgICooIi0iIHZhcmlhbnQpDQogICAgICAg ICAgICAgICAgICAgICooIi0iIGV4dGVuc2lvbikNCiAgICAgICAgICAgICAgICAgICAgWyItIiBw cml2YXRldXNlXSkNCg0KICAgbGFuZ3VhZ2UgICAgICA9ICgyKjNBTFBIQSBbIGV4dGxhbmcgXSkg OyBzaG9ydGVzdCBJU08gNjM5IGNvZGUNCiAgICAgICAgICAgICAgICAgLyA0QUxQSEEgICAgICAg ICAgICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UNCiAgICAgICAgICAgICAgICAgLyA1 KjhBTFBIQSAgICAgICAgICAgICAgIDsgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcNCg0KICAg ZXh0bGFuZyAgICAgICA9ICozKCItIiAzQUxQSEEpICAgICAgICAgOyByZXNlcnZlZCBmb3IgZnV0 dXJlIHVzZQ0KDQogICBzY3JpcHQgICAgICAgID0gNEFMUEhBICAgICAgICAgICAgICAgICA7IElT TyAxNTkyNCBjb2RlDQoNCiAgIHJlZ2lvbiAgICAgICAgPSAyQUxQSEEgICAgICAgICAgICAgICAg IDsgSVNPIDMxNjYgY29kZQ0KICAgICAgICAgICAgICAgICAvIDNESUdJVCAgICAgICAgICAgICAg ICAgOyBVTiBNLjQ5IGNvZGUNCg0KICAgdmFyaWFudCAgICAgICA9IDUqOGFscGhhbnVtICAgICAg ICAgICAgOyByZWdpc3RlcmVkIHZhcmlhbnRzDQogICAgICAgICAgICAgICAgIC8gKERJR0lUIDNh bHBoYW51bSkNCg0KICAgZXh0ZW5zaW9uICAgICA9IHNpbmdsZXRvbiAxKigiLSIgKDIqOGFscGhh bnVtKSkNCg0KICAgc2luZ2xldG9uICAgICA9ICV4NDEtNTcgLyAleDU5LTVBIC8gJXg2MS03NyAv ICV4NzktN0EgLyBESUdJVA0KICAgICAgICAgICAgICAgICA7ICJhIi0idyIgLyAieSItInoiIC8g IkEiLSJXIiAvICJZIi0iWiIgLyAiMCItIjkiDQogICAgICAgICAgICAgICAgIDsgU2luZ2xlIGxl dHRlcnM6IHgvWCBpcyByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1c2UNCg0KICAgcHJpdmF0ZXVzZSAg ICA9ICgieCIvIlgiKSAxKigiLSIgKDEqOGFscGhhbnVtKSkNCg0KICAgZ3JhbmRmYXRoZXJlZCA9 IDEqM0FMUEhBIDEqMigiLSIgKDIqOGFscGhhbnVtKSkNCiAgICAgICAgICAgICAgICAgICA7IGdy YW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9uDQogICAgICAgICAgICAgICAgICAgOyBOb3RlOiBpIGlz IHRoZSBvbmx5IHNpbmdsZXRvbg0KICAgICAgICAgICAgICAgICAgIDsgdGhhdCBzdGFydHMgYSBn cmFuZGZhdGhlcmVkIHRhZw0KDQogICBhbHBoYW51bSAgICAgID0gKEFMUEhBIC8gRElHSVQpICAg ICAgIDsgbGV0dGVycyBhbmQgbnVtYmVycw0KDQogICAgICAgICAgICAgICAgICAgICAgICBGaWd1 cmUgMTogTGFuZ3VhZ2UgVGFnIEFCTkYNCg0KICAgTm90ZTogVGhlcmUgaXMgYSBzdWJ0bGV0eSBp biB0aGUgQUJORiBmb3IgJ3ZhcmlhbnQnOiB2YXJpYW50cw0KICAgc3RhcnRpbmcgd2l0aCBhIGRp Z2l0IE1BWSBiZSBmb3VyIGNoYXJhY3RlcnMgbG9uZywgd2hpbGUgdGhvc2UNCiAgIHN0YXJ0aW5n IHdpdGggYSBsZXR0ZXIgTVVTVCBiZSBhdCBsZWFzdCBmaXZlIGNoYXJhY3RlcnMgbG9uZy4NCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAg ICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBBbGwgc3Vi dGFncyBoYXZlIGEgbWF4aW11bSBsZW5ndGggb2YgZWlnaHQgY2hhcmFjdGVycyBhbmQgd2hpdGVz cGFjZQ0KICAgaXMgbm90IHBlcm1pdHRlZCBpbiBhIGxhbmd1YWdlIHRhZy4gIEZvciBleGFtcGxl cyBvZiBsYW5ndWFnZSB0YWdzLA0KICAgc2VlIEFwcGVuZGl4IEIuDQoNCiAgIE5vdGUgdGhhdCBh bHRob3VnaCBbUkZDMjIzNGJpc10gcmVmZXJzIHRvIG9jdGV0cywgdGhlIGxhbmd1YWdlIHRhZ3MN CiAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBzZXF1ZW5jZXMgb2YgY2hhcmFjdGVy cyBmcm9tIHRoZSBVUy0NCiAgIEFTQ0lJIFtJU082NDZdIHJlcGVydG9pcmUuICBMYW5ndWFnZSB0 YWdzIE1BWSBiZSB1c2VkIGluIGRvY3VtZW50cw0KICAgYW5kIGFwcGxpY2F0aW9ucyB0aGF0IHVz ZSBvdGhlciBlbmNvZGluZ3MsIHNvIGxvbmcgYXMgdGhlc2UgZW5jb21wYXNzDQogICB0aGUgVVMt QVNDSUkgcmVwZXJ0b2lyZS4gIEFuIGV4YW1wbGUgb2YgdGhpcyB3b3VsZCBiZSBhbiBYTUwgZG9j dW1lbnQNCiAgIHRoYXQgdXNlcyB0aGUgVVRGLTE2TEUgW1JGQzI3ODFdIGVuY29kaW5nIG9mIFtV bmljb2RlXS4NCg0KICAgVGhlIHRhZ3MgYW5kIHRoZWlyIHN1YnRhZ3MsIGluY2x1ZGluZyBwcml2 YXRlIHVzZSBhbmQgZXh0ZW5zaW9ucywgYXJlDQogICB0byBiZSB0cmVhdGVkIGFzIGNhc2UgaW5z ZW5zaXRpdmU6IHRoZXJlIGV4aXN0IGNvbnZlbnRpb25zIGZvciB0aGUNCiAgIGNhcGl0YWxpemF0 aW9uIG9mIHNvbWUgb2YgdGhlIHN1YnRhZ3MsIGJ1dCB0aGVzZSBNVVNUIE5PVCBiZSB0YWtlbiB0 bw0KICAgY2FycnkgbWVhbmluZy4NCg0KICAgRm9yIGV4YW1wbGU6DQoNCiAgIG8gIFtJU082Mzkt MV0gcmVjb21tZW5kcyB0aGF0IGxhbmd1YWdlIGNvZGVzIGJlIHdyaXR0ZW4gaW4gbG93ZXIgY2Fz ZQ0KICAgICAgKCdtbicgTW9uZ29saWFuKS4NCg0KICAgbyAgW0lTTzMxNjYtMV0gcmVjb21tZW5k cyB0aGF0IGNvdW50cnkgY29kZXMgYmUgY2FwaXRhbGl6ZWQgKCdNTicNCiAgICAgIE1vbmdvbGlh KS4NCg0KICAgbyAgW0lTTzE1OTI0XSByZWNvbW1lbmRzIHRoYXQgc2NyaXB0IGNvZGVzIHVzZSBs b3dlciBjYXNlIHdpdGggdGhlDQogICAgICBpbml0aWFsIGxldHRlciBjYXBpdGFsaXplZCAoJ0N5 cmwnIEN5cmlsbGljKS4NCg0KICAgSG93ZXZlciwgaW4gdGhlIHRhZ3MgZGVmaW5lZCBieSB0aGlz IGRvY3VtZW50LCB0aGUgdXBwZXJjYXNlIFVTLUFTQ0lJDQogICBsZXR0ZXJzIGluIHRoZSByYW5n ZSAnQScgdGhyb3VnaCAnWicgYXJlIGNvbnNpZGVyZWQgZXF1aXZhbGVudCBhbmQNCiAgIG1hcHBl ZCBkaXJlY3RseSB0byB0aGVpciBVUy1BU0NJSSBsb3dlcmNhc2UgZXF1aXZhbGVudHMgaW4gdGhl IHJhbmdlDQogICAnYScgdGhyb3VnaCAneicuICBUaHVzIHRoZSB0YWcgIm1uLUN5cmwtTU4iIGlz IG5vdCBkaXN0aW5jdCBmcm9tICJNTi0NCiAgIGNZUkwtbW4iIG9yICJtTi1jWXJMLU1uIiAob3Ig YW55IG90aGVyIGNvbWJpbmF0aW9uKSBhbmQgZWFjaCBvZiB0aGVzZQ0KICAgdmFyaWF0aW9ucyBj b252ZXlzIHRoZSBzYW1lIG1lYW5pbmc6IE1vbmdvbGlhbiB3cml0dGVuIGluIHRoZQ0KICAgQ3ly aWxsaWMgc2NyaXB0IGFzIHVzZWQgaW4gTW9uZ29saWEuDQoNCiAgIEFsdGhvdWdoIGNhc2UgZGlz dGluY3Rpb25zIGRvIG5vdCBjYXJyeSBtZWFuaW5nIGluIGxhbmd1YWdlIHRhZ3MsDQogICBjb25z aXN0ZW50IGZvcm1hdHRpbmcgYW5kIHByZXNlbnRhdGlvbiBvZiB0aGUgdGFncyB3aWxsIGFpZCB1 c2Vycy4NCiAgIFRoZSBmb3JtYXQgb2YgdGhlIHRhZ3MgYW5kIHN1YnRhZ3MgaW4gdGhlIHJlZ2lz dHJ5IGlzIFJFQ09NTUVOREVELg0KICAgSW4gdGhpcyBmb3JtYXQsIGFsbCBub24taW5pdGlhbCB0 d28tbGV0dGVyIHN1YnRhZ3MgYXJlIHVwcGVyY2FzZSwgYWxsDQogICBub24taW5pdGlhbCBmb3Vy LWxldHRlciBzdWJ0YWdzIGFyZSB0aXRsZWNhc2UsIGFuZCBhbGwgb3RoZXIgc3VidGFncw0KICAg YXJlIGxvd2VyY2FzZS4NCg0KMi4yICBMYW5ndWFnZSBTdWJ0YWcgU291cmNlcyBhbmQgSW50ZXJw cmV0YXRpb24NCg0KICAgVGhlIG5hbWVzcGFjZSBvZiBsYW5ndWFnZSB0YWdzIGFuZCB0aGVpciBz dWJ0YWdzIGlzIGFkbWluaXN0ZXJlZCBieQ0KICAgdGhlIEludGVybmV0IEFzc2lnbmVkIE51bWJl cnMgQXV0aG9yaXR5IChJQU5BKSBbUkZDMjg2MF0gYWNjb3JkaW5nIHRvDQogICB0aGUgcnVsZXMg aW4gU2VjdGlvbiA1IG9mIHRoaXMgZG9jdW1lbnQuICBUaGUgTGFuZ3VhZ2UgU3VidGFnDQogICBS ZWdpc3RyeSBtYWludGFpbmVkIGJ5IElBTkEgaXMgdGhlIHNvdXJjZSBmb3IgdmFsaWQgc3VidGFn czogb3RoZXINCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2 LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0K ICAgc3RhbmRhcmRzIHJlZmVyZW5jZWQgaW4gdGhpcyBzZWN0aW9uIHByb3ZpZGUgdGhlIHNvdXJj ZSBtYXRlcmlhbCBmb3INCiAgIHRoYXQgcmVnaXN0cnkuDQoNCiAgIFRlcm1pbm9sb2d5IGluIHRo aXMgc2VjdGlvbjoNCg0KICAgbyAgVGFnIG9yIHRhZ3MgcmVmZXJzIHRvIGEgY29tcGxldGUgbGFu Z3VhZ2UgdGFnLCBzdWNoIGFzDQogICAgICAiZnItTGF0bi1DQSIuICBFeGFtcGxlcyBvZiB0YWdz IGluIHRoaXMgZG9jdW1lbnQgYXJlIGVuY2xvc2VkIGluDQogICAgICBkb3VibGUtcXVvdGVzICgi ZW4tVVMiKS4NCg0KICAgbyAgU3VidGFnIHJlZmVycyB0byBhIHNwZWNpZmljIHNlY3Rpb24gb2Yg YSB0YWcsIGRlbGltaXRlZCBieSBoeXBoZW4sDQogICAgICBzdWNoIGFzIHRoZSBzdWJ0YWcgJ0xh dG4nIGluICJmci1MYXRuLUNBIi4gIEV4YW1wbGVzIG9mIHN1YnRhZ3MgaW4NCiAgICAgIHRoaXMg ZG9jdW1lbnQgYXJlIGVuY2xvc2VkIGluIHNpbmdsZSBxdW90ZXMgKCdMYXRuJykuDQoNCiAgIG8g IENvZGUgb3IgY29kZXMgcmVmZXJzIHRvIHZhbHVlcyBkZWZpbmVkIGluIGV4dGVybmFsIHN0YW5k YXJkcyAoYW5kDQogICAgICB3aGljaCBhcmUgdXNlZCBhcyBzdWJ0YWdzIGluIHRoaXMgZG9jdW1l bnQpLiAgRm9yIGV4YW1wbGUsICdMYXRuJw0KICAgICAgaXMgYW4gW0lTTzE1OTI0XSBzY3JpcHQg Y29kZSB3aGljaCB3YXMgdXNlZCB0byBkZWZpbmUgdGhlICdMYXRuJw0KICAgICAgc2NyaXB0IHN1 YnRhZyBmb3IgdXNlIGluIGEgbGFuZ3VhZ2UgdGFnLiAgRXhhbXBsZXMgb2YgY29kZXMgaW4NCiAg ICAgIHRoaXMgZG9jdW1lbnQgYXJlIGVuY2xvc2VkIGluIHNpbmdsZSBxdW90ZXMgKCdlbicsICdM YXRuJykuDQoNCiAgIFRoZSBkZWZpbml0aW9ucyBpbiB0aGlzIHNlY3Rpb24gYXBwbHkgdG8gdGhl IHZhcmlvdXMgc3VidGFncyB3aXRoaW4NCiAgIHRoZSBsYW5ndWFnZSB0YWdzIGRlZmluZWQgYnkg dGhpcyBkb2N1bWVudCwgZXhjZXB0aW5nIHRob3NlDQogICAiZ3JhbmRmYXRoZXJlZCIgdGFncyBk ZWZpbmVkIGluIFNlY3Rpb24gMi4yLjguDQoNCiAgIExhbmd1YWdlIHRhZ3MgYXJlIGRlc2lnbmVk IHNvIHRoYXQgZWFjaCBzdWJ0YWcgdHlwZSBoYXMgdW5pcXVlIGxlbmd0aA0KICAgYW5kIGNvbnRl bnQgcmVzdHJpY3Rpb25zLiAgVGhlc2UgbWFrZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgc3VidGFn J3MNCiAgIHR5cGUgcG9zc2libGUsIGV2ZW4gaWYgdGhlIGNvbnRlbnQgb2YgdGhlIHN1YnRhZyBp dHNlbGYgaXMNCiAgIHVucmVjb2duaXplZC4gIFRoaXMgYWxsb3dzIHRhZ3MgdG8gYmUgcGFyc2Vk IGFuZCBwcm9jZXNzZWQgd2l0aG91dA0KICAgcmVmZXJlbmNlIHRvIHRoZSBsYXRlc3QgdmVyc2lv biBvZiB0aGUgdW5kZXJseWluZyBzdGFuZGFyZHMgb3IgdGhlDQogICBJQU5BIHJlZ2lzdHJ5IGFu ZCBtYWtlcyB0aGUgYXNzb2NpYXRlZCBleGNlcHRpb24gaGFuZGxpbmcgd2hlbg0KICAgcGFyc2lu ZyB0YWdzIHNpbXBsZXIuDQoNCiAgIFN1YnRhZ3MgaW4gdGhlIElBTkEgcmVnaXN0cnkgdGhhdCBk byBub3QgY29tZSBmcm9tIGFuIHVuZGVybHlpbmcNCiAgIHN0YW5kYXJkIGNhbiBvbmx5IGFwcGVh ciBpbiBzcGVjaWZpYyBwb3NpdGlvbnMgaW4gYSB0YWcuDQogICBTcGVjaWZpY2FsbHksIHRoZXkg Y2FuIG9ubHkgb2NjdXIgYXMgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIG9yIGFzDQogICB2YXJp YW50IHN1YnRhZ3MuDQoNCiAgIE5vdGUgdGhhdCBzZXF1ZW5jZXMgb2YgcHJpdmF0ZSB1c2UgYW5k IGV4dGVuc2lvbiBzdWJ0YWdzIE1VU1Qgb2NjdXINCiAgIGF0IHRoZSBlbmQgb2YgdGhlIHNlcXVl bmNlIG9mIHN1YnRhZ3MgYW5kIE1VU1QgTk9UIGJlIGludGVyc3BlcnNlZA0KICAgd2l0aCBzdWJ0 YWdzIGRlZmluZWQgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIFNpbmdsZSBsZXR0 ZXIgYW5kIGRpZ2l0IHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBjdXJyZW50IG9yIGZ1dHVyZQ0K ICAgdXNlLiAgVGhlc2UgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGN1cnJlbnQgdXNlczoNCg0KICAg byAgVGhlIHNpbmdsZSBsZXR0ZXIgc3VidGFnICd4JyBpcyByZXNlcnZlZCB0byBpbnRyb2R1Y2Ug YSBzZXF1ZW5jZQ0KICAgICAgb2YgcHJpdmF0ZSB1c2Ugc3VidGFncy4gIFRoZSBpbnRlcnByZXRh dGlvbiBvZiBhbnkgcHJpdmF0ZSB1c2UNCiAgICAgIHN1YnRhZ3MgaXMgZGVmaW5lZCBzb2xlbHkg YnkgcHJpdmF0ZSBhZ3JlZW1lbnQgYW5kIGlzIG5vdCBkZWZpbmVkDQogICAgICBieSB0aGUgcnVs ZXMgaW4gdGhpcyBzZWN0aW9uIG9yIGluIGFueSBzdGFuZGFyZCBvciByZWdpc3RyeQ0KICAgICAg ZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg IEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2Vw dGVtYmVyIDIwMDUNCg0KDQogICBvICBBbGwgb3RoZXIgc2luZ2xlIGxldHRlciBzdWJ0YWdzIGFy ZSByZXNlcnZlZCB0byBpbnRyb2R1Y2UNCiAgICAgIHN0YW5kYXJkaXplZCBleHRlbnNpb24gc3Vi dGFnIHNlcXVlbmNlcyBhcyBkZXNjcmliZWQgaW4NCiAgICAgIFNlY3Rpb24gMy43Lg0KDQogICBU aGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29tZSBncmFuZGZhdGhlcmVk IHRhZ3MsIHN1Y2gNCiAgIGFzICJpLWVub2NoaWFuIiwgd2hlcmUgaXQgYWx3YXlzIGFwcGVhcnMg aW4gdGhlIGZpcnN0IHBvc2l0aW9uIGFuZA0KICAgY2Fubm90IGJlIGNvbmZ1c2VkIHdpdGggYW4g ZXh0ZW5zaW9uLg0KDQoyLjIuMSAgUHJpbWFyeSBMYW5ndWFnZSBTdWJ0YWcNCg0KICAgVGhlIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHRoZSBmaXJzdCBzdWJ0YWcgaW4gYSBsYW5ndWFnZSB0 YWcNCiAgICh3aXRoIHRoZSBleGNlcHRpb24gb2YgcHJpdmF0ZSB1c2UgYW5kIGNlcnRhaW4gZ3Jh bmRmYXRoZXJlZCB0YWdzKQ0KICAgYW5kIGNhbm5vdCBiZSBvbWl0dGVkLiAgVGhlIGZvbGxvd2lu ZyBydWxlcyBhcHBseSB0byB0aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAx LiAgQWxsIHR3byBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3VidGFncyB3ZXJlIGRlZmluZWQgaW4gdGhl IElBTkENCiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5k IGluIHRoZSBzdGFuZGFyZCBJU08NCiAgICAgICA2MzkgUGFydCAxLCAiSVNPIDYzOS0xOjIwMDIs IENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YNCiAgICAgICBuYW1lcyBvZiBsYW5ndWFn ZXMgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiIFtJU082MzktMV0sIG9yIHVzaW5nDQogICAgICAg YXNzaWdubWVudHMgc3Vic2VxdWVudGx5IG1hZGUgYnkgdGhlIElTTyA2MzkgUGFydCAxIG1haW50 ZW5hbmNlDQogICAgICAgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVz Lg0KDQogICAyLiAgQWxsIHRocmVlIGNoYXJhY3RlciBsYW5ndWFnZSBzdWJ0YWdzIHdlcmUgZGVm aW5lZCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0aGUgYXNzaWdu bWVudHMgZm91bmQgaW4gSVNPIDYzOSBQYXJ0IDIsDQogICAgICAgIklTTyA2MzktMjoxOTk4IC0g Q29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZg0KICAgICAgIGxhbmd1YWdl cyAtLSBQYXJ0IDI6IEFscGhhLTMgY29kZSAtIGVkaXRpb24gMSIgW0lTTzYzOS0yXSwgb3INCiAg ICAgICBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDYzOSBQYXJ0IDIg bWFpbnRlbmFuY2UNCiAgICAgICBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBi b2RpZXMuDQoNCiAgIDMuICBUaGUgc3VidGFncyBpbiB0aGUgcmFuZ2UgJ3FhYScgdGhyb3VnaCAn cXR6JyBhcmUgcmVzZXJ2ZWQgZm9yDQogICAgICAgcHJpdmF0ZSB1c2UgaW4gbGFuZ3VhZ2UgdGFn cy4gIFRoZXNlIHN1YnRhZ3MgY29ycmVzcG9uZCB0byBjb2Rlcw0KICAgICAgIHJlc2VydmVkIGJ5 IElTTyA2MzktMiBmb3IgcHJpdmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZA0KICAg ICAgIGZvciBub24tcmVnaXN0ZXJlZCBwcmltYXJ5LWxhbmd1YWdlIHN1YnRhZ3MgKGluc3RlYWQg b2YgdXNpbmcNCiAgICAgICBwcml2YXRlIHVzZSBzdWJ0YWdzIGZvbGxvd2luZyAneC0nKS4gIFBs ZWFzZSByZWZlciB0byBTZWN0aW9uIDQuNQ0KICAgICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIG9u IHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgIDQuICBBbGwgZm91ciBjaGFyYWN0ZXIgbGFuZ3Vh Z2Ugc3VidGFncyBhcmUgcmVzZXJ2ZWQgZm9yIHBvc3NpYmxlDQogICAgICAgZnV0dXJlIHN0YW5k YXJkaXphdGlvbi4NCg0KICAgNS4gIEFsbCBsYW5ndWFnZSBzdWJ0YWdzIG9mIDUgdG8gOCBjaGFy YWN0ZXJzIGluIGxlbmd0aCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IHdlcmUgZGVmaW5l ZCB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGluIFNlY3Rpb24gMy41DQogICAgICAgYW5k IE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnLiAgQXQgdGhl IHRpbWUNCiAgICAgICB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCB0aGVyZSB3ZXJlIG5vIGV4 YW1wbGVzIG9mIHRoaXMga2luZCBvZg0KICAgICAgIHN1YnRhZyBhbmQgZnV0dXJlIHJlZ2lzdHJh dGlvbnMgb2YgdGhpcyB0eXBlIHdpbGwgYmUgZGlzY291cmFnZWQ6DQogICAgICAgcHJpbWFyeSBs YW5ndWFnZXMgYXJlIHN0cm9uZ2x5IFJFQ09NTUVOREVEIGZvciByZWdpc3RyYXRpb24gd2l0aA0K ICAgICAgIElTTyA2MzkgYW5kIHByb3Bvc2FscyByZWplY3RlZCBieSBJU08gNjM5L1JBIHdpbGwg YmUgY2xvc2VseQ0KICAgICAgIHNjcnV0aW5pemVkIGJlZm9yZSB0aGV5IGFyZSByZWdpc3RlcmVk IHdpdGggSUFOQS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFy Y2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUN Cg0KDQogICA2LiAgVGhlIHNpbmdsZSBjaGFyYWN0ZXIgc3VidGFnICd4JyBhcyB0aGUgcHJpbWFy eSBzdWJ0YWcgaW5kaWNhdGVzDQogICAgICAgdGhhdCB0aGUgbGFuZ3VhZ2UgdGFnIGNvbnNpc3Rz IHNvbGVseSBvZiBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMNCiAgICAgICBkZWZpbmVkIGJ5IHBy aXZhdGUgYWdyZWVtZW50LiAgRm9yIGV4YW1wbGUsIGluIHRoZSB0YWcgIngtZnItQ0giLA0KICAg ICAgIHRoZSBzdWJ0YWdzICdmcicgYW5kICdDSCcgU0hPVUxEIE5PVCBiZSB0YWtlbiB0byByZXBy ZXNlbnQgdGhlDQogICAgICAgRnJlbmNoIGxhbmd1YWdlIG9yIHRoZSBjb3VudHJ5IG9mIFN3aXR6 ZXJsYW5kIChvciBhbnkgb3RoZXIgdmFsdWUNCiAgICAgICBpbiB0aGUgSUFOQSByZWdpc3RyeSkg dW5sZXNzIHRoZXJlIGlzIGEgcHJpdmF0ZSBhZ3JlZW1lbnQgaW4NCiAgICAgICBwbGFjZSB0byBk byBzby4gIFNlZSBTZWN0aW9uIDQuNS4NCg0KICAgNy4gIFRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1 YnRhZyAnaScgaXMgdXNlZCBieSBzb21lIGdyYW5kZmF0aGVyZWQNCiAgICAgICB0YWdzIChzZWUg U2VjdGlvbiAyLjIuOCkgc3VjaCBhcyAiaS1rbGluZ29uIiBhbmQgImktYm5uIi4gIChPdGhlcg0K ICAgICAgIGdyYW5kZmF0aGVyZWQgdGFncyBoYXZlIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcg aW4gdGhlaXIgZmlyc3QNCiAgICAgICBwb3NpdGlvbikNCg0KICAgOC4gIE90aGVyIHZhbHVlcyBN VVNUIE5PVCBiZSBhc3NpZ25lZCB0byB0aGUgcHJpbWFyeSBzdWJ0YWcgZXhjZXB0IGJ5DQogICAg ICAgcmV2aXNpb24gb3IgdXBkYXRlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5vdGU6IEZvciBs YW5ndWFnZXMgdGhhdCBoYXZlIGJvdGggYW4gSVNPIDYzOS0xIHR3byBjaGFyYWN0ZXIgY29kZQ0K ICAgYW5kIGFuIElTTyA2MzktMiB0aHJlZSBjaGFyYWN0ZXIgY29kZSwgb25seSB0aGUgSVNPIDYz OS0xIHR3bw0KICAgY2hhcmFjdGVyIGNvZGUgaXMgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3Ry eS4NCg0KICAgTm90ZTogRm9yIGxhbmd1YWdlcyB0aGF0IGhhdmUgbm8gSVNPIDYzOS0xIHR3byBj aGFyYWN0ZXIgY29kZSBhbmQgZm9yDQogICB3aGljaCB0aGUgSVNPIDYzOS0yL1QgKFRlcm1pbm9s b2d5KSBjb2RlIGFuZCB0aGUgSVNPIDYzOS0yL0INCiAgIChCaWJsaW9ncmFwaGljKSBjb2RlcyBk aWZmZXIsIG9ubHkgdGhlIFRlcm1pbm9sb2d5IGNvZGUgaXMgZGVmaW5lZCBpbg0KICAgdGhlIElB TkEgcmVnaXN0cnkuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCBhbGwN CiAgIGxhbmd1YWdlcyB0aGF0IGhhZCBib3RoIGtpbmRzIG9mIHRocmVlIGNoYXJhY3RlciBjb2Rl IHdlcmUgYWxzbw0KICAgYXNzaWduZWQgYSB0d28gY2hhcmFjdGVyIGNvZGU7IGl0IGlzIG5vdCBl eHBlY3RlZCB0aGF0IGZ1dHVyZQ0KICAgYXNzaWdubWVudHMgb2YgdGhpcyBuYXR1cmUgd2lsbCBv Y2N1ci4NCg0KICAgTm90ZTogVG8gYXZvaWQgcHJvYmxlbXMgd2l0aCB2ZXJzaW9uaW5nIGFuZCBz dWJ0YWcgY2hvaWNlIGFzDQogICBleHBlcmllbmNlZCBkdXJpbmcgdGhlIHRyYW5zaXRpb24gYmV0 d2VlbiBSRkMgMTc2NiBhbmQgUkZDIDMwNjYsIGFzDQogICB3ZWxsIGFzIHRoZSBjYW5vbmljYWwg bmF0dXJlIG9mIHN1YnRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50LCB0aGUNCiAgIElTTyA2 MzkgUmVnaXN0cmF0aW9uIEF1dGhvcml0eSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWUgKElTTyA2 MzkvDQogICBSQS1KQUMpIGhhcyBpbmNsdWRlZCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiBb aXNvNjM5LnByaW5jaXBsZXNdOg0KDQogICAiQSBsYW5ndWFnZSBjb2RlIGFscmVhZHkgaW4gSVNP IDYzOS0yIGF0IHRoZSBwb2ludCBvZiBmcmVlemluZyBJU08NCiAgIDYzOS0xIHNoYWxsIG5vdCBs YXRlciBiZSBhZGRlZCB0byBJU08gNjM5LTEuICBUaGlzIGlzIHRvIGVuc3VyZQ0KICAgY29uc2lz dGVuY3kgaW4gdXNhZ2Ugb3ZlciB0aW1lLCBzaW5jZSB1c2VycyBhcmUgZGlyZWN0ZWQgaW4gSW50 ZXJuZXQNCiAgIGFwcGxpY2F0aW9ucyB0byBlbXBsb3kgdGhlIGFscGhhLTMgY29kZSB3aGVuIGFu IGFscGhhLTIgY29kZSBmb3IgdGhhdA0KICAgbGFuZ3VhZ2UgaXMgbm90IGF2YWlsYWJsZS4iDQoN CiAgIEluIG9yZGVyIHRvIGF2b2lkIGluc3RhYmlsaXR5IGluIHRoZSBjYW5vbmljYWwgZm9ybSBv ZiB0YWdzLCBpZiBhIHR3bw0KICAgY2hhcmFjdGVyIGNvZGUgaXMgYWRkZWQgdG8gSVNPIDYzOS0x IGZvciBhIGxhbmd1YWdlIGZvciB3aGljaCBhIHRocmVlDQogICBjaGFyYWN0ZXIgY29kZSB3YXMg YWxyZWFkeSBpbmNsdWRlZCBpbiBJU08gNjM5LTIsIHRoZSB0d28gY2hhcmFjdGVyDQogICBjb2Rl IE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQuICBTZWUgU2VjdGlvbiAzLjQuDQoNCiAgIEZvciBleGFt cGxlLCBpZiBzb21lIGNvbnRlbnQgd2VyZSB0YWdnZWQgd2l0aCAnaGF3JyAoSGF3YWlpYW4pLCB3 aGljaA0KICAgY3VycmVudGx5IGhhcyBubyB0d28gY2hhcmFjdGVyIGNvZGUsIHRoZSB0YWcgd291 bGQgbm90IGJlIGludmFsaWRhdGVkDQogICBpZiBJU08gNjM5LTEgd2VyZSB0byBhc3NpZ24gYSB0 d28gY2hhcmFjdGVyIGNvZGUgdG8gdGhlIEhhd2FpaWFuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgOV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIGxhbmd1YWdlIGF0IGEgbGF0ZXIgZGF0ZS4NCg0K ICAgRm9yIGV4YW1wbGUsIG9uZSBvZiB0aGUgZ3JhbmRmYXRoZXJlZCBJQU5BIHJlZ2lzdHJhdGlv bnMgaXMNCiAgICJpLWVub2NoaWFuIi4gIFRoZSBzdWJ0YWcgJ2Vub2NoaWFuJyBjb3VsZCBiZSBy ZWdpc3RlcmVkIGluIHRoZSBJQU5BDQogICByZWdpc3RyeSBhcyBhIHByaW1hcnkgbGFuZ3VhZ2Ug c3VidGFnIChhc3N1bWluZyB0aGF0IElTTyA2MzkgZG9lcyBub3QNCiAgIHJlZ2lzdGVyIHRoaXMg bGFuZ3VhZ2UgZmlyc3QpLCBtYWtpbmcgdGFncyBzdWNoIGFzICJlbm9jaGlhbi1BUSIgYW5kDQog ICAiZW5vY2hpYW4tTGF0biIgdmFsaWQuDQoNCjIuMi4yICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0 YWdzDQoNCiAgIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIGV4dGVuZGVkIGxhbmd1 YWdlIHN1YnRhZ3M6DQoNCiAgIDEuICBUaHJlZSBsZXR0ZXIgc3VidGFncyBpbW1lZGlhdGVseSBm b2xsb3dpbmcgdGhlIHByaW1hcnkgc3VidGFnIGFyZQ0KICAgICAgIHJlc2VydmVkIGZvciBmdXR1 cmUgc3RhbmRhcmRpemF0aW9uLCBhbnRpY2lwYXRpbmcgd29yayB0aGF0IGlzDQogICAgICAgY3Vy cmVudGx5IHVuZGVyIHdheSBvbiBJU08gNjM5Lg0KDQogICAyLiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ug c3VidGFncyBNVVNUIGZvbGxvdyB0aGUgcHJpbWFyeSBzdWJ0YWcgYW5kDQogICAgICAgcHJlY2Vk ZSBhbnkgb3RoZXIgc3VidGFncy4NCg0KICAgMy4gIFRoZXJlIE1BWSBiZSB1cCB0byB0aHJlZSBl eHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzLg0KDQogICA0LiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3Vi dGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIG9yIHVzZWQgdG8gZm9ybQ0KICAgICAgIGxhbmd1 YWdlIHRhZ3MuICBUaGVpciBzeW50YXggaXMgZGVzY3JpYmVkIGhlcmUgc28gdGhhdA0KICAgICAg IGltcGxlbWVudGF0aW9ucyBjYW4gYmUgY29tcGF0aWJsZSB3aXRoIGFueSBmdXR1cmUgcmV2aXNp b24gb2YNCiAgICAgICB0aGlzIGRvY3VtZW50IHdoaWNoIGRvZXMgcHJvdmlkZSBmb3IgdGhlaXIg cmVnaXN0cmF0aW9uLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcgcmVjb3Jkcywgb25j ZSB0aGV5IGFwcGVhciBpbiB0aGUgcmVnaXN0cnksDQogICBNVVNUIGluY2x1ZGUgZXhhY3RseSBv bmUgJ1ByZWZpeCcgZmllbGQgaW5kaWNhdGluZyBhbiBhcHByb3ByaWF0ZQ0KICAgbGFuZ3VhZ2Ug c3VidGFnIG9yIHNlcXVlbmNlIG9mIHN1YnRhZ3MgdGhhdCBNVVNUIGFsd2F5cyBhcHBlYXIgYXMg YQ0KICAgcHJlZml4IHRvIHRoZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcuDQoNCiAgIEV4YW1w bGU6IEluIGEgZnV0dXJlIHJldmlzaW9uIG9yIHVwZGF0ZSBvZiB0aGlzIGRvY3VtZW50LCB0aGUg dGFnDQogICAiemgtZ2FuIiAocmVnaXN0ZXJlZCB1bmRlciBSRkMgMzA2NikgbWlnaHQgYmVjb21l IGEgdmFsaWQgbm9uLQ0KICAgZ3JhbmRmYXRoZXJlZCAodGhhdCBpcywgcmVkdW5kYW50KSB0YWcg aW4gd2hpY2ggdGhlIHN1YnRhZyAnZ2FuJw0KICAgbWlnaHQgcmVwcmVzZW50IHRoZSBDaGluZXNl IGRpYWxlY3QgJ0dhbicuDQoNCjIuMi4zICBTY3JpcHQgU3VidGFnDQoNCiAgIFNjcmlwdCBzdWJ0 YWdzIGFyZSB1c2VkIHRvIGluZGljYXRlIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBzeXN0ZW0NCiAg IHZhcmlhdGlvbnMgdGhhdCBkaXN0aW5ndWlzaCB0aGUgd3JpdHRlbiBmb3JtcyBvZiBhIGxhbmd1 YWdlIG9yIGl0cw0KICAgZGlhbGVjdHMuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRo ZSBzY3JpcHQgc3VidGFnczoNCg0KICAgMS4gIEFsbCBmb3VyIGNoYXJhY3RlciBzdWJ0YWdzIHdl cmUgZGVmaW5lZCBhY2NvcmRpbmcgdG8NCiAgICAgICBbSVNPMTU5MjRdLS0iQ29kZXMgZm9yIHRo ZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgbmFtZXMgb2YNCiAgICAgICBzY3JpcHRzIjogYWxwaGEt NCBzY3JpcHQgY29kZXMsIG9yIHN1YnNlcXVlbnRseSBhc3NpZ25lZCBieSB0aGUNCiAgICAgICBJ U08gMTU5MjQgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24g Ym9kaWVzLA0KICAgICAgIGRlbm90aW5nIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBzeXN0ZW0gdXNl ZCBpbiBjb25qdW5jdGlvbiB3aXRoDQogICAgICAgdGhpcyBsYW5ndWFnZS4NCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAgICAgICAg IFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgMi4gIFNjcmlwdCBzdWJ0YWdz IE1VU1QgaW1tZWRpYXRlbHkgZm9sbG93IHRoZSBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgc3Vi dGFnIGFuZCBhbGwgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhbmQgTVVTVCBvY2N1ciBiZWZv cmUNCiAgICAgICBhbnkgb3RoZXIgdHlwZSBvZiBzdWJ0YWcgZGVzY3JpYmVkIGJlbG93Lg0KDQog ICAzLiAgVGhlIHNjcmlwdCBzdWJ0YWdzICdRYWFhJyB0aHJvdWdoICdRYWJ4JyBhcmUgcmVzZXJ2 ZWQgZm9yIHByaXZhdGUNCiAgICAgICB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRh Z3MgY29ycmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZA0KICAgICAgIGJ5IElTTyAxNTkyNCBmb3Ig cHJpdmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZCBmb3Igbm9uLQ0KICAgICAgIHJl Z2lzdGVyZWQgc2NyaXB0IHZhbHVlcy4gIFBsZWFzZSByZWZlciB0byBTZWN0aW9uIDQuNSBmb3Ig bW9yZQ0KICAgICAgIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgIDQu ICBTY3JpcHQgc3VidGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIHVzaW5nIHRoZSBwcm9jZXNz IGluDQogICAgICAgU2VjdGlvbiAzLjUgb2YgdGhpcyBkb2N1bWVudC4gIFZhcmlhbnQgc3VidGFn cyBNQVkgYmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdpc3RyYXRpb24gZm9yIHRoYXQgcHVy cG9zZS4NCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgc2NyaXB0IHN1YnRhZyBp biBhIGxhbmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgc2NyaXB0IHN1YnRhZyBTSE9VTEQgYmUg b21pdHRlZCB3aGVuIGl0IGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcNCiAgICAgICB2YWx1ZSB0byB0 aGUgdGFnIG9yIHdoZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnJ3MgcmVjb3JkDQogICAg ICAgaW5jbHVkZXMgYSBTdXBwcmVzcy1TY3JpcHQgZmllbGQgbGlzdGluZyB0aGUgYXBwbGljYWJs ZSBzY3JpcHQNCiAgICAgICBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6ICJzci1MYXRuIiByZXByZXNl bnRzIFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0Lg0KDQoyLjIuNCAgUmVn aW9uIFN1YnRhZw0KDQogICBSZWdpb24gc3VidGFncyBhcmUgdXNlZCB0byBpbmRpY2F0ZSBsaW5n dWlzdGljIHZhcmlhdGlvbnMgYXNzb2NpYXRlZA0KICAgd2l0aCBvciBhcHByb3ByaWF0ZSB0byBh IHNwZWNpZmljIGNvdW50cnksIHRlcnJpdG9yeSwgb3IgcmVnaW9uLg0KICAgVHlwaWNhbGx5LCBh IHJlZ2lvbiBzdWJ0YWcgaXMgdXNlZCB0byBpbmRpY2F0ZSByZWdpb25hbCBkaWFsZWN0cyBvcg0K ICAgdXNhZ2UsIG9yIHJlZ2lvbi1zcGVjaWZpYyBzcGVsbGluZyBjb252ZW50aW9ucy4gIEEgcmVn aW9uIHN1YnRhZyBjYW4NCiAgIGFsc28gYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IGNvbnRlbnQg aXMgZXhwcmVzc2VkIGluIGEgd2F5IHRoYXQgaXMNCiAgIGFwcHJvcHJpYXRlIGZvciB1c2UgdGhy b3VnaG91dCBhIHJlZ2lvbjsgZm9yIGluc3RhbmNlLCBTcGFuaXNoDQogICBjb250ZW50IHRhaWxv cmVkIHRvIGJlIHVzZWZ1bCB0aHJvdWdob3V0IExhdGluIEFtZXJpY2EuDQoNCiAgIFRoZSBmb2xs b3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIHJlZ2lvbiBzdWJ0YWdzOg0KDQogICAxLiAgUmVnaW9u IHN1YnRhZ3MgTVVTVCBmb2xsb3cgYW55IGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwgb3IN CiAgICAgICBzY3JpcHQgc3VidGFncyBhbmQgTVVTVCBwcmVjZWRlIGFsbCBvdGhlciBzdWJ0YWdz Lg0KDQogICAyLiAgQWxsIHR3byBjaGFyYWN0ZXIgc3VidGFncyBmb2xsb3dpbmcgdGhlIHByaW1h cnkgc3VidGFnIHdlcmUNCiAgICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFjY29y ZGluZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQNCiAgICAgICBpbiBbSVNPMzE2Ni0xXSAoIkNv ZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YNCiAgICAgICBjb3VudHJpZXMg YW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAtLSBQYXJ0IDE6IENvdW50cnkgY29kZXMiKSB1c2luZw0K ICAgICAgIHRoZSBsaXN0IG9mIGFscGhhLTIgY291bnRyeSBjb2Rlcywgb3IgdXNpbmcgYXNzaWdu bWVudHMNCiAgICAgICBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDMxNjYgbWFpbnRlbmFu Y2UgYWdlbmN5IG9yIGdvdmVybmluZw0KICAgICAgIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuDQoN CiAgIDMuICBBbGwgdGhyZWUgY2hhcmFjdGVyIHN1YnRhZ3MgY29uc2lzdGluZyBvZiBkaWdpdCAo bnVtZXJpYykNCiAgICAgICBjaGFyYWN0ZXJzIGZvbGxvd2luZyB0aGUgcHJpbWFyeSBzdWJ0YWcg d2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRo ZSBhc3NpZ25tZW50cyBmb3VuZCBpbiBVTiBTdGFuZGFyZA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMTFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICAgICAgQ291bnRyeSBvciBBcmVhIENvZGVzIGZv ciBTdGF0aXN0aWNhbCAgVXNlIFtVTl9NLjQ5XSBvcg0KICAgICAgIGFzc2lnbm1lbnRzIHN1YnNl cXVlbnRseSBtYWRlIGJ5IHRoZSBnb3Zlcm5pbmcgc3RhbmRhcmRzIGJvZHkuDQogICAgICAgTm90 ZSB0aGF0IG5vdCBhbGwgb2YgdGhlIFVOIE0uNDkgY29kZXMgYXJlIGRlZmluZWQgaW4gdGhlIElB TkENCiAgICAgICByZWdpc3RyeS4gIFRoZSBmb2xsb3dpbmcgcnVsZXMgZGVmaW5lIHdoaWNoIGNv ZGVzIGFyZSBlbnRlcmVkDQogICAgICAgaW50byB0aGUgcmVnaXN0cnkgYXMgdmFsaWQgc3VidGFn czoNCg0KICAgICAgIEEuICBVTiBudW1lcmljIGNvZGVzIGFzc2lnbmVkIHRvICdtYWNyby1nZW9n cmFwaGljYWwNCiAgICAgICAgICAgKGNvbnRpbmVudGFsKScgb3Igc3ViLXJlZ2lvbnMgTVVTVCBi ZSByZWdpc3RlcmVkIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeS4gIFRoZXNlIGNvZGVzIGFy ZSBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbmVkDQogICAgICAgICAgIElTTyAzMTY2IGFs cGhhLTIgY29kZSBhbmQgcmVwcmVzZW50IHN1cHJhLW5hdGlvbmFsIGFyZWFzLA0KICAgICAgICAg ICB1c3VhbGx5IGNvdmVyaW5nIG1vcmUgdGhhbiBvbmUgbmF0aW9uLCBzdGF0ZSwgcHJvdmluY2Us IG9yDQogICAgICAgICAgIHRlcnJpdG9yeS4NCg0KICAgICAgIEIuICBVTiBudW1lcmljIGNvZGVz IGZvciAnZWNvbm9taWMgZ3JvdXBpbmdzJyBvciAnb3RoZXINCiAgICAgICAgICAgZ3JvdXBpbmdz JyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFuZA0KICAgICAg ICAgICBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0KICAgICAgIEMu ICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMgd2l0aCBhbWJpZ3VvdXMg SVNPDQogICAgICAgICAgIDMxNjYgYWxwaGEtMiBjb2Rlcywgd2hlbiBlbnRlcmVkIGludG8gdGhl IHJlZ2lzdHJ5LCBNVVNUIGJlDQogICAgICAgICAgIGRlZmluZWQgYWNjb3JkaW5nIHRvIHRoZSBy dWxlcyBpbiBTZWN0aW9uIDMuNCBhbmQgTVVTVCBiZQ0KICAgICAgICAgICB1c2VkIHRvIGZvcm0g bGFuZ3VhZ2UgdGFncyB0aGF0IHJlcHJlc2VudCB0aGUgY291bnRyeSBvcg0KICAgICAgICAgICBy ZWdpb24gZm9yIHdoaWNoIHRoZXkgYXJlIGRlZmluZWQuDQoNCiAgICAgICBELiAgVU4gbnVtZXJp YyBjb2RlcyBmb3IgY291bnRyaWVzIG9yIGFyZWFzIGZvciB3aGljaCB0aGVyZSBpcyBhbg0KICAg ICAgICAgICBhc3NvY2lhdGVkIElTTyAzMTY2IGFscGhhLTIgY29kZSBpbiB0aGUgcmVnaXN0cnkg TVVTVCBOT1QgYmUNCiAgICAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSBhbmQgTVVT VCBOT1QgYmUgdXNlZCB0byBmb3JtDQogICAgICAgICAgIGxhbmd1YWdlIHRhZ3MuICBOb3RlIHRo YXQgdGhlIElTTyAzMTY2LWJhc2VkIHN1YnRhZyBpbiB0aGUNCiAgICAgICAgICAgcmVnaXN0cnkg TVVTVCBhY3R1YWxseSBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIFVOIE0uNDkgY29kZSBpbg0KICAg ICAgICAgICBxdWVzdGlvbi4NCg0KICAgICAgIEUuICBVTiBudW1lcmljIGNvZGVzIGFuZCBJU08g MzE2NiBhbHBoYS0yIGNvZGVzIGZvciBjb3VudHJpZXMgb3INCiAgICAgICAgICAgYXJlYXMgbGlz dGVkIGFzIGVsaWdpYmxlIGZvciByZWdpc3RyYXRpb24gaW4gW2luaXRpYWwtDQogICAgICAgICAg IHJlZ2lzdHJ5XSBidXQgbm90IHByZXNlbnRseSByZWdpc3RlcmVkIE1BWSBiZSBlbnRlcmVkIGlu dG8NCiAgICAgICAgICAgdGhlIElBTkEgcmVnaXN0cnkgdmlhIHRoZSBwcm9jZXNzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDMuNS4NCiAgICAgICAgICAgT25jZSByZWdpc3RlcmVkLCB0aGVzZSBjb2Rl cyBNQVkgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlDQogICAgICAgICAgIHRhZ3MuDQoNCiAgICAg ICBGLiAgQWxsIG90aGVyIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBvciBhcmVhcyB3 aGljaCBkbw0KICAgICAgICAgICBub3QgaGF2ZSBhbiBhc3NvY2lhdGVkIElTTyAzMTY2IGFscGhh LTIgY29kZSBNVVNUIE5PVCBiZQ0KICAgICAgICAgICBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5 IGFuZCBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0NCiAgICAgICAgICAgbGFuZ3VhZ2UgdGFncy4g IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZXNlIGNvZGVzLCBzZWUNCiAgICAgICAgICAg U2VjdGlvbiAzLjQuDQoNCiAgIDQuICBOb3RlOiBUaGUgYWxwaGFudW1lcmljIGNvZGVzIGluIEFw cGVuZGl4IFggb2YgdGhlIFVOIGRvY3VtZW50DQogICAgICAgTVVTVCBOT1QgYmUgZW50ZXJlZCBp bnRvIHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0bw0KICAgICAgIGZvcm0gbGFu Z3VhZ2UgdGFncy4gIChBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkIHRoZXNl DQogICAgICAgdmFsdWVzIG1hdGNoIHRoZSBJU08gMzE2NiBhbHBoYS0yIGNvZGVzLikNCg0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAg ICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICA1LiAgVGhlcmUg TVVTVCBiZSBhdCBtb3N0IG9uZSByZWdpb24gc3VidGFnIGluIGEgbGFuZ3VhZ2UgdGFnIGFuZCB0 aGUNCiAgICAgICByZWdpb24gc3VidGFnIE1BWSBiZSBvbWl0dGVkLCBhcyB3aGVuIGl0IGFkZHMg bm8gZGlzdGluZ3Vpc2hpbmcNCiAgICAgICB2YWx1ZSB0byB0aGUgdGFnLg0KDQogICA2LiAgVGhl IHJlZ2lvbiBzdWJ0YWdzICdBQScsICdRTSctJ1FaJywgJ1hBJy0nWFonLCBhbmQgJ1paJyBhcmUN CiAgICAgICByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNl IHN1YnRhZ3MNCiAgICAgICBjb3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkIGJ5IElTTyAzMTY2 IGZvciBwcml2YXRlIHVzZS4gIFRoZXNlDQogICAgICAgY29kZXMgTUFZIGJlIHVzZWQgZm9yIHBy aXZhdGUgdXNlIHJlZ2lvbiBzdWJ0YWdzIChpbnN0ZWFkIG9mDQogICAgICAgdXNpbmcgYSBwcml2 YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2UpLiAgUGxlYXNlIHJlZmVyIHRvDQogICAgICAgU2VjdGlv biA0LjUgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gcHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0KICAg ImRlLUNIIiByZXByZXNlbnRzIEdlcm1hbiAoJ2RlJykgYXMgdXNlZCBpbiBTd2l0emVybGFuZCAo J0NIJykuDQoNCiAgICJzci1MYXRuLUNTIiByZXByZXNlbnRzIFNlcmJpYW4gKCdzcicpIHdyaXR0 ZW4gdXNpbmcgTGF0aW4gc2NyaXB0DQogICAoJ0xhdG4nKSBhcyB1c2VkIGluIFNlcmJpYSBhbmQg TW9udGVuZWdybyAoJ0NTJykuDQoNCiAgICJlcy00MTkiIHJlcHJlc2VudHMgU3BhbmlzaCAoJ2Vz JykgYXBwcm9wcmlhdGUgdG8gdGhlIFVOLWRlZmluZWQNCiAgIExhdGluIEFtZXJpY2EgYW5kIENh cmliYmVhbiByZWdpb24gKCc0MTknKS4NCg0KMi4yLjUgIFZhcmlhbnQgU3VidGFncw0KDQogICBW YXJpYW50IHN1YnRhZ3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgYWRkaXRpb25hbCwgd2VsbC1yZWNv Z25pemVkDQogICB2YXJpYXRpb25zIHRoYXQgZGVmaW5lIGEgbGFuZ3VhZ2Ugb3IgaXRzIGRpYWxl Y3RzIHdoaWNoIGFyZSBub3QNCiAgIGNvdmVyZWQgYnkgb3RoZXIgYXZhaWxhYmxlIHN1YnRhZ3Mu ICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZQ0KICAgdmFyaWFudCBzdWJ0YWdzOg0K DQogICAxLiAgVmFyaWFudCBzdWJ0YWdzIGFyZSBub3QgYXNzb2NpYXRlZCB3aXRoIGFueSBleHRl cm5hbCBzdGFuZGFyZC4NCiAgICAgICBWYXJpYW50IHN1YnRhZ3MgYW5kIHRoZWlyIG1lYW5pbmdz IGFyZSBkZWZpbmVkIGJ5IHRoZQ0KICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGRlZmluZWQg aW4gU2VjdGlvbiAzLjUuDQoNCiAgIDIuICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBmb2xsb3cgYWxs IG9mIHRoZSBvdGhlciBkZWZpbmVkIHN1YnRhZ3MsIGJ1dA0KICAgICAgIHByZWNlZGUgYW55IGV4 dGVuc2lvbiBvciBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAzLiAgTW9yZSB0 aGFuIG9uZSB2YXJpYW50IE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIGxhbmd1YWdlIHRhZy4NCg0K ICAgNC4gIFZhcmlhbnQgc3VidGFncyBNVVNUIGJlIHJlZ2lzdGVyZWQgd2l0aCBJQU5BIGFjY29y ZGluZyB0byB0aGUNCiAgICAgICBydWxlcyBpbiBTZWN0aW9uIDMuNSBvZiB0aGlzIGRvY3VtZW50 IGJlZm9yZSBiZWluZyB1c2VkIHRvIGZvcm0NCiAgICAgICBsYW5ndWFnZSB0YWdzLiAgSW4gb3Jk ZXIgdG8gZGlzdGluZ3Vpc2ggdmFyaWFudHMgZnJvbSBvdGhlciB0eXBlcw0KICAgICAgIG9mIHN1 YnRhZ3MsIHJlZ2lzdHJhdGlvbnMgTVVTVCBtZWV0IHRoZSBmb2xsb3dpbmcgbGVuZ3RoIGFuZA0K ICAgICAgIGNvbnRlbnQgcmVzdHJpY3Rpb25zOg0KDQogICAgICAgMS4gIFZhcmlhbnQgc3VidGFn cyB0aGF0IGJlZ2luIHdpdGggYSBsZXR0ZXIgKGEteiwgQS1aKSBNVVNUIGJlDQogICAgICAgICAg IGF0IGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0KDQogICAgICAgMi4gIFZhcmlhbnQgc3Vi dGFncyB0aGF0IGJlZ2luIHdpdGggYSBkaWdpdCAoMC05KSBNVVNUIGJlIGF0DQogICAgICAgICAg IGxlYXN0IGZvdXIgY2hhcmFjdGVycyBsb25nLg0KDQogICBWYXJpYW50IHN1YnRhZyByZWNvcmRz IGluIHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkgTUFZIGluY2x1ZGUNCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAgICAgICAg IFtQYWdlIDEzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgb25lIG9yIG1vcmUgJ1ByZWZp eCcgZmllbGRzLCB3aGljaCBpbmRpY2F0ZXMgdGhlIGxhbmd1YWdlIHRhZyBvciB0YWdzDQogICB0 aGF0IHdvdWxkIG1ha2UgYSBzdWl0YWJsZSBwcmVmaXggKHdpdGggb3RoZXIgc3VidGFncywgYXMN CiAgIGFwcHJvcHJpYXRlKSBpbiBmb3JtaW5nIGEgbGFuZ3VhZ2UgdGFnIHdpdGggdGhlIHZhcmlh bnQuICBGb3INCiAgIGV4YW1wbGUsIHRoZSBzdWJ0YWcgJ25lZGlzJyBoYXMgYSBQcmVmaXggb2Yg InNsIiwgbWFraW5nIGl0IHN1aXRhYmxlDQogICB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mgc3VjaCBh cyAic2wtbmVkaXMiIGFuZCAic2wtSVQtbmVkaXMiLCBidXQgbm90DQogICBzdWl0YWJsZSBmb3Ig dXNlIGluIGEgdGFnIHN1Y2ggYXMgInpoLW5lZGlzIiBvciAiaXQtSVQtbmVkaXMiLg0KDQogICAi c2wtbmVkaXMiIHJlcHJlc2VudHMgdGhlIE5hdGlzb25lIG9yIE5hZGl6YSBkaWFsZWN0IG9mIFNs b3Zlbmlhbi4NCg0KICAgImRlLUNILTE5OTYiIHJlcHJlc2VudHMgR2VybWFuIGFzIHVzZWQgaW4g U3dpdHplcmxhbmQgYW5kIGFzIHdyaXR0ZW4NCiAgIHVzaW5nIHRoZSBzcGVsbGluZyByZWZvcm0g YmVnaW5uaW5nIGluIHRoZSB5ZWFyIDE5OTYgQy5FLg0KDQogICBNb3N0IHZhcmlhbnRzIHRoYXQg c2hhcmUgYSBwcmVmaXggYXJlIG11dHVhbGx5IGV4Y2x1c2l2ZS4gIEZvcg0KICAgZXhhbXBsZSwg dGhlIEdlcm1hbiBvcnRob2dyYXBoaWMgdmFyaWF0aW9ucyAnMTk5NicgYW5kICcxOTAxJyBTSE9V TEQNCiAgIE5PVCBiZSB1c2VkIGluIHRoZSBzYW1lIHRhZywgYXMgdGhleSByZXByZXNlbnQgdGhl IGRhdGVzIG9mIGRpZmZlcmVudA0KICAgc3BlbGxpbmcgcmVmb3Jtcy4gIEEgdmFyaWFudCB0aGF0 IGNhbiBtZWFuaW5nZnVsbHkgYmUgdXNlZCBpbg0KICAgY29tYmluYXRpb24gd2l0aCBhbm90aGVy IHZhcmlhbnQgU0hPVUxEIGluY2x1ZGUgYSAnUHJlZml4JyBmaWVsZCBpbg0KICAgaXRzIHJlZ2lz dHJ5IHJlY29yZCB0aGF0IGxpc3RzIHRoYXQgb3RoZXIgdmFyaWFudC4gIEZvciBleGFtcGxlLCBp Zg0KICAgYW5vdGhlciBHZXJtYW4gdmFyaWFudCAnZXhhbXBsZScgd2VyZSBjcmVhdGVkIHRoYXQg bWFkZSBzZW5zZSB0byB1c2UNCiAgIHdpdGggJzE5OTYnLCB0aGVuICdleGFtcGxlJyBzaG91bGQg aW5jbHVkZSB0d28gUHJlZml4IGZpZWxkczogImRlIg0KICAgYW5kICJkZS0xOTk2Ii4NCg0KMi4y LjYgIEV4dGVuc2lvbiBTdWJ0YWdzDQoNCiAgIEV4dGVuc2lvbnMgcHJvdmlkZSBhIG1lY2hhbmlz bSBmb3IgZXh0ZW5kaW5nIGxhbmd1YWdlIHRhZ3MgZm9yIHVzZSBpbg0KICAgdmFyaW91cyBhcHBs aWNhdGlvbnMuICBTZWU6IFNlY3Rpb24gMy43LiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseQ0K ICAgdG8gZXh0ZW5zaW9uczoNCg0KICAgMS4gICBFeHRlbnNpb24gc3VidGFncyBhcmUgc2VwYXJh dGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0KICAgICAgICBpbiB0aGlzIGRvY3Vt ZW50IGJ5IGEgc2luZ2xlIGNoYXJhY3RlciBzdWJ0YWcgKCJzaW5nbGV0b24iKS4NCiAgICAgICAg VGhlIHNpbmdsZXRvbiBNVVNUIGJlIG9uZSBhbGxvY2F0ZWQgdG8gYSByZWdpc3RyYXRpb24gYXV0 aG9yaXR5DQogICAgICAgIHZpYSB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMu NyBhbmQgTVVTVCBOT1QgYmUgdGhlDQogICAgICAgIGxldHRlciAneCcsIHdoaWNoIGlzIHJlc2Vy dmVkIGZvciBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAyLiAgIE5vdGU6IFBy aXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5jZXMgc3RhcnRpbmcgd2l0aCB0aGUgc2luZ2xldG9uDQog ICAgICAgIHN1YnRhZyAneCcgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMi43IGJlbG93Lg0K DQogICAzLiAgIEFuIGV4dGVuc2lvbiBNVVNUIGZvbGxvdyBhdCBsZWFzdCBhIHByaW1hcnkgbGFu Z3VhZ2Ugc3VidGFnLg0KICAgICAgICBUaGF0IGlzLCBhIGxhbmd1YWdlIHRhZyBjYW5ub3QgYmVn aW4gd2l0aCBhbiBleHRlbnNpb24uDQogICAgICAgIEV4dGVuc2lvbnMgZXh0ZW5kIGxhbmd1YWdl IHRhZ3MsIHRoZXkgZG8gbm90IG92ZXJyaWRlIG9yIHJlcGxhY2UNCiAgICAgICAgdGhlbS4gIEZv ciBleGFtcGxlLCAiYS12YWx1ZSIgaXMgbm90IGEgd2VsbC1mb3JtZWQgbGFuZ3VhZ2UgdGFnLA0K ICAgICAgICB3aGlsZSAiZGUtYS12YWx1ZSIgaXMuDQoNCiAgIDQuICAgRWFjaCBzaW5nbGV0b24g c3VidGFnIE1VU1QgYXBwZWFyIGF0IG1vc3Qgb25lIHRpbWUgaW4gZWFjaCB0YWcNCiAgICAgICAg KG90aGVyIHRoYW4gYXMgYSBwcml2YXRlIHVzZSBzdWJ0YWcpLiAgVGhhdCBpcywgc2luZ2xldG9u DQogICAgICAgIHN1YnRhZ3MgTVVTVCBOT1QgYmUgcmVwZWF0ZWQuICBGb3IgZXhhbXBsZSwgdGhl IHRhZyAiZW4tYS1iYmItYS0NCiAgICAgICAgY2NjIiBpcyBpbnZhbGlkIGJlY2F1c2UgdGhlIHN1 YnRhZyAnYScgYXBwZWFycyB0d2ljZS4gIE5vdGUgdGhhdA0KICAgICAgICB0aGUgdGFnICJlbi1h LWJiYi14LWEtY2NjIiBpcyB2YWxpZCBiZWNhdXNlIHRoZSBzZWNvbmQNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAgICAgICAgIFtQ YWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgICAgICBhcHBlYXJhbmNlIG9mIHRo ZSBzaW5nbGV0b24gJ2EnIGlzIGluIGEgcHJpdmF0ZSB1c2Ugc2VxdWVuY2UuDQoNCiAgIDUuICAg RXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IGFsbCBvZiB0aGUgcmVxdWlyZW1lbnRzIGZvciB0 aGUNCiAgICAgICAgY29udGVudCBhbmQgZm9ybWF0IG9mIHN1YnRhZ3MgZGVmaW5lZCBpbiB0aGlz IGRvY3VtZW50Lg0KDQogICA2LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1QgbWVldCB3aGF0ZXZl ciByZXF1aXJlbWVudHMgYXJlIHNldCBieSB0aGUNCiAgICAgICAgZG9jdW1lbnQgdGhhdCBkZWZp bmVzIHRoZWlyIHNpbmdsZXRvbiBwcmVmaXggYW5kIHdoYXRldmVyDQogICAgICAgIHJlcXVpcmVt ZW50cyBhcmUgcHJvdmlkZWQgYnkgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eS4NCg0KICAgNy4g ICBFYWNoIGV4dGVuc2lvbiBzdWJ0YWcgTVVTVCBiZSBmcm9tIHR3byB0byBlaWdodCBjaGFyYWN0 ZXJzIGxvbmcNCiAgICAgICAgYW5kIGNvbnNpc3Qgc29sZWx5IG9mIGxldHRlcnMgb3IgZGlnaXRz LCB3aXRoIGVhY2ggc3VidGFnDQogICAgICAgIHNlcGFyYXRlZCBieSBhIHNpbmdsZSAnLScuDQoN CiAgIDguICAgRWFjaCBzaW5nbGV0b24gTVVTVCBiZSBmb2xsb3dlZCBieSBhdCBsZWFzdCBvbmUg ZXh0ZW5zaW9uDQogICAgICAgIHN1YnRhZy4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJ0bGgtYS1i LWZvbyIgaXMgaW52YWxpZCBiZWNhdXNlDQogICAgICAgIHRoZSBmaXJzdCBzaW5nbGV0b24gJ2En IGlzIGZvbGxvd2VkIGltbWVkaWF0ZWx5IGJ5IGFub3RoZXINCiAgICAgICAgc2luZ2xldG9uICdi Jy4NCg0KICAgOS4gICBFeHRlbnNpb24gc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2Us IGV4dGVuZGVkIGxhbmd1YWdlLA0KICAgICAgICBzY3JpcHQsIHJlZ2lvbiBhbmQgdmFyaWFudCBz dWJ0YWdzIGluIGEgdGFnLg0KDQogICAxMC4gIEFsbCBzdWJ0YWdzIGZvbGxvd2luZyB0aGUgc2lu Z2xldG9uIGFuZCBiZWZvcmUgYW5vdGhlciBzaW5nbGV0b24NCiAgICAgICAgYXJlIHBhcnQgb2Yg dGhlIGV4dGVuc2lvbi4gIEV4YW1wbGU6IEluIHRoZSB0YWcgImZyLWEtTGF0biIsIHRoZQ0KICAg ICAgICBzdWJ0YWcgJ0xhdG4nIGRvZXMgbm90IHJlcHJlc2VudCB0aGUgc2NyaXB0IHN1YnRhZyAn TGF0bicNCiAgICAgICAgZGVmaW5lZCBpbiB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0 cnkuICBJdHMgbWVhbmluZyBpcw0KICAgICAgICBkZWZpbmVkIGJ5IHRoZSBleHRlbnNpb24gJ2En Lg0KDQogICAxMS4gIEluIHRoZSBldmVudCB0aGF0IG1vcmUgdGhhbiBvbmUgZXh0ZW5zaW9uIGFw cGVhcnMgaW4gYSBzaW5nbGUNCiAgICAgICAgdGFnLCB0aGUgdGFnIFNIT1VMRCBiZSBjYW5vbmlj YWxpemVkIGFzIGRlc2NyaWJlZCBpbg0KICAgICAgICBTZWN0aW9uIDQuNC4NCg0KICAgRm9yIGV4 YW1wbGUsIGlmIHRoZSBwcmVmaXggc2luZ2xldG9uICdyJyBhbmQgdGhlIHNob3duIHN1YnRhZ3Mg d2VyZQ0KICAgZGVmaW5lZCwgdGhlbiB0aGUgZm9sbG93aW5nIHRhZyB3b3VsZCBiZSBhIHZhbGlk IGV4YW1wbGU6ICJlbi1MYXRuLQ0KICAgR0ItYm9vbnQtci1leHRlbmRlZC1zZXF1ZW5jZS14LXBy aXZhdGUiDQoNCjIuMi43ICBQcml2YXRlIFVzZSBTdWJ0YWdzDQoNCiAgIFByaXZhdGUgdXNlIHN1 YnRhZ3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgZGlzdGluY3Rpb25zIGluIGxhbmd1YWdlDQogICBp bXBvcnRhbnQgaW4gYSBnaXZlbiBjb250ZXh0IGJ5IHByaXZhdGUgYWdyZWVtZW50LiAgVGhlIGZv bGxvd2luZw0KICAgcnVsZXMgYXBwbHkgdG8gcHJpdmF0ZSB1c2Ugc3VidGFnczoNCg0KICAgMS4g IFByaXZhdGUgdXNlIHN1YnRhZ3MgYXJlIHNlcGFyYXRlZCBmcm9tIHRoZSBvdGhlciBzdWJ0YWdz IGRlZmluZWQNCiAgICAgICBpbiB0aGlzIGRvY3VtZW50IGJ5IHRoZSByZXNlcnZlZCBzaW5nbGUt Y2hhcmFjdGVyIHN1YnRhZyAneCcuDQoNCiAgIDIuICBQcml2YXRlIHVzZSBzdWJ0YWdzIE1VU1Qg Y29uZm9ybSB0byB0aGUgZm9ybWF0IGFuZCBjb250ZW50DQogICAgICAgY29uc3RyYWludHMgZGVm aW5lZCBpbiB0aGUgQUJORiBmb3IgYWxsIHN1YnRhZ3MuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2Ug MTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICAzLiAgUHJpdmF0ZSB1c2Ugc3VidGFncyBN VVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2UsIGV4dGVuZGVkIGxhbmd1YWdlLA0KICAgICAgIHNjcmlw dCwgcmVnaW9uLCB2YXJpYW50LCBhbmQgZXh0ZW5zaW9uIHN1YnRhZ3MgaW4gdGhlIHRhZy4NCiAg ICAgICBBbm90aGVyIHdheSBvZiBzYXlpbmcgdGhpcyBpcyB0aGF0IGFsbCBzdWJ0YWdzIGZvbGxv d2luZyB0aGUNCiAgICAgICBzaW5nbGV0b24gJ3gnIE1VU1QgYmUgY29uc2lkZXJlZCBwcml2YXRl IHVzZS4gIEV4YW1wbGU6IFRoZQ0KICAgICAgIHN1YnRhZyAnVVMnIGluIHRoZSB0YWcgImVuLXgt VVMiIGlzIGEgcHJpdmF0ZSB1c2Ugc3VidGFnLg0KDQogICA0LiAgQSB0YWcgTUFZIGNvbnNpc3Qg ZW50aXJlbHkgb2YgcHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0KICAgNS4gIE5vIHNvdXJjZSBpcyBk ZWZpbmVkIGZvciBwcml2YXRlIHVzZSBzdWJ0YWdzLiAgVXNlIG9mIHByaXZhdGUgdXNlDQogICAg ICAgc3VidGFncyBpcyBieSBwcml2YXRlIGFncmVlbWVudCBvbmx5Lg0KDQogICA2LiAgUHJpdmF0 ZSB1c2Ugc3VidGFncyBhcmUgTk9UIFJFQ09NTUVOREVEIHdoZXJlIGFsdGVybmF0aXZlcyBleGlz dA0KICAgICAgIG9yIGZvciBnZW5lcmFsIGludGVyY2hhbmdlLiAgU2VlIFNlY3Rpb24gNC41IGZv ciBtb3JlIGluZm9ybWF0aW9uDQogICAgICAgb24gcHJpdmF0ZSB1c2Ugc3VidGFnIGNob2ljZS4N Cg0KICAgRm9yIGV4YW1wbGU6IFVzZXJzIHdobyB3aXNoZWQgdG8gdXRpbGl6ZSBjb2RlcyBmcm9t IHRoZSBFdGhub2xvZ3VlDQogICBwdWJsaWNhdGlvbiBvZiBTSUwgSW50ZXJuYXRpb25hbCBmb3Ig bGFuZ3VhZ2UgaWRlbnRpZmljYXRpb24gbWlnaHQNCiAgIGFncmVlIHRvIGV4Y2hhbmdlIHRhZ3Mg c3VjaCBhcyAiYXotQXJhYi14LUFaRS1kZXJiZW5kIi4gIFRoaXMgZXhhbXBsZQ0KICAgY29udGFp bnMgdHdvIHByaXZhdGUgdXNlIHN1YnRhZ3MuICBUaGUgZmlyc3QgaXMgJ0FaRScgYW5kIHRoZSBz ZWNvbmQNCiAgIGlzICdkZXJiZW5kJy4NCg0KMi4yLjggIFByZS1FeGlzdGluZyBSRkMgMzA2NiBS ZWdpc3RyYXRpb25zDQoNCiAgIEV4aXN0aW5nIElBTkEtcmVnaXN0ZXJlZCBsYW5ndWFnZSB0YWdz IGZyb20gUkZDIDE3NjYgYW5kL29yIFJGQyAzMDY2DQogICBtYWludGFpbiB0aGVpciB2YWxpZGl0 eS4gIFRoZXNlIHRhZ3Mgd2lsbCBiZSBtYWludGFpbmVkIGluIHRoZQ0KICAgcmVnaXN0cnkgaW4g cmVjb3JkcyBvZiBlaXRoZXIgdGhlICJncmFuZGZhdGhlcmVkIiBvciAicmVkdW5kYW50Ig0KICAg dHlwZS4gIEdyYW5kZmF0aGVyZWQgdGFncyBjb250YWluIG9uZSBvciBtb3JlIHN1YnRhZ3MgdGhh dCBhcmUgbm90DQogICBkZWZpbmVkIGluIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgKHNl ZSBTZWN0aW9uIDMpLiAgUmVkdW5kYW50DQogICB0YWdzIGNvbnNpc3QgZW50aXJlbHkgb2Ygc3Vi dGFncyBkZWZpbmVkIGFib3ZlIGFuZCB3aG9zZSBpbmRlcGVuZGVudA0KICAgcmVnaXN0cmF0aW9u IGlzIHN1cGVyc2VkZWQgYnkgdGhpcyBkb2N1bWVudC4gIEZvciBtb3JlIGluZm9ybWF0aW9uDQog ICBzZWUgU2VjdGlvbiAzLjguDQoNCiAgIEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgYWxs IGxhbmd1YWdlIHRhZ3MgZm9ybWVkIHVuZGVyIHRoZQ0KICAgZ3VpZGVsaW5lcyBpbiB0aGlzIGRv Y3VtZW50IHdlcmUgZWl0aGVyIGxlZ2FsLCB3ZWxsLWZvcm1lZCB0YWdzIG9yDQogICBjb3VsZCBo YXZlIGJlZW4gcmVnaXN0ZXJlZCB1bmRlciBSRkMgMzA2Ni4NCg0KMi4yLjkgIENsYXNzZXMgb2Yg Q29uZm9ybWFuY2UNCg0KICAgSW1wbGVtZW50YXRpb25zIHNvbWV0aW1lcyBuZWVkIHRvIGRlc2Ny aWJlIHRoZWlyIGNhcGFiaWxpdGllcyB3aXRoDQogICByZWdhcmQgdG8gdGhlIHJ1bGVzIGFuZCBw cmFjdGljZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuICBUaGVyZQ0KICAgYXJlIHR3byBj bGFzc2VzIG9mIGNvbmZvcm1pbmcgaW1wbGVtZW50YXRpb25zIGRlc2NyaWJlZCBieSB0aGlzDQog ICBkb2N1bWVudDogIndlbGwtZm9ybWVkIiBwcm9jZXNzb3JzIGFuZCAidmFsaWRhdGluZyIgcHJv Y2Vzc29ycy4NCiAgIENsYWltcyBvZiBjb25mb3JtYW5jZSBTSE9VTEQgZXhwbGljaXRseSByZWZl cmVuY2Ugb25lIG9mIHRoZXNlDQogICBkZWZpbml0aW9ucy4NCg0KICAgQW4gaW1wbGVtZW50YXRp b24gdGhhdCBjbGFpbXMgdG8gY2hlY2sgZm9yIHdlbGwtZm9ybWVkIGxhbmd1YWdlIHRhZ3MNCiAg IE1VU1Q6DQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2 LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDE2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0K ICAgbyAgQ2hlY2sgdGhhdCB0aGUgdGFnIGFuZCBhbGwgb2YgaXRzIHN1YnRhZ3MsIGluY2x1ZGlu ZyBleHRlbnNpb24gYW5kDQogICAgICBwcml2YXRlIHVzZSBzdWJ0YWdzLCBjb25mb3JtIHRvIHRo ZSBBQk5GIG9yIHRoYXQgdGhlIHRhZyBpcyBvbiB0aGUNCiAgICAgIGxpc3Qgb2YgZ3JhbmRmYXRo ZXJlZCB0YWdzLg0KDQogICBvICBDaGVjayB0aGF0IHNpbmdsZXRvbiBzdWJ0YWdzIHRoYXQgaWRl bnRpZnkgZXh0ZW5zaW9ucyBkbyBub3QNCiAgICAgIHJlcGVhdC4gIEZvciBleGFtcGxlLCB0aGUg dGFnICJlbi1hLXh4LWIteXktYS16eiIgaXMgbm90IHdlbGwtDQogICAgICBmb3JtZWQuDQoNCiAg IFdlbGwtZm9ybWVkIHByb2Nlc3NvcnMgYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQgdG8gaW1wbGVt ZW50IHRoZQ0KICAgY2Fub25pY2FsaXphdGlvbiBydWxlcyBjb250YWluZWQgaW4gU2VjdGlvbiA0 LjQuDQoNCiAgIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgY2xhaW1zIHRvIGJlIHZhbGlkYXRpbmcg TVVTVDoNCg0KICAgbyAgQ2hlY2sgdGhhdCB0aGUgdGFnIGlzIHdlbGwtZm9ybWVkLg0KDQogICBv ICBTcGVjaWZ5IHRoZSBwYXJ0aWN1bGFyIHJlZ2lzdHJ5IGRhdGUgZm9yIHdoaWNoIHRoZSBpbXBs ZW1lbnRhdGlvbg0KICAgICAgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBzdWJ0YWdzLg0KDQogICBv ICBDaGVjayB0aGF0IGVpdGhlciB0aGUgdGFnIGlzIGEgZ3JhbmRmYXRoZXJlZCB0YWcsIG9yIHRo YXQgYWxsDQogICAgICBsYW5ndWFnZSwgc2NyaXB0LCByZWdpb24sIGFuZCB2YXJpYW50IHN1YnRh Z3MgY29uc2lzdCBvZiB2YWxpZA0KICAgICAgY29kZXMgZm9yIHVzZSBpbiBsYW5ndWFnZSB0YWdz IGFjY29yZGluZyB0byB0aGUgSUFOQSByZWdpc3RyeSBhcw0KICAgICAgb2YgdGhlIHBhcnRpY3Vs YXIgZGF0ZSBzcGVjaWZpZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uLg0KDQogICBvICBTcGVjaWZ5 IHdoaWNoLCBpZiBhbnksIGV4dGVuc2lvbiBSRkNzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjcN CiAgICAgIGFyZSBzdXBwb3J0ZWQsIGluY2x1ZGluZyB2ZXJzaW9uLCByZXZpc2lvbiwgYW5kIGRh dGUuDQoNCiAgIG8gIEZvciBhbnkgc3VjaCBleHRlbnNpb25zIHN1cHBvcnRlZCwgY2hlY2sgdGhh dCBhbGwgc3VidGFncyB1c2VkIGluDQogICAgICB0aGF0IGV4dGVuc2lvbiBhcmUgdmFsaWQuDQoN CiAgIG8gIEZvciB2YXJpYW50IGFuZCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzLCBpZiB0aGUg cmVnaXN0cnkNCiAgICAgIGNvbnRhaW5zIG9uZSBvciBtb3JlICdQcmVmaXgnIGZpZWxkcyBmb3Ig dGhhdCBzdWJ0YWcsIGNoZWNrIHRoYXQNCiAgICAgIHRoZSB0YWcgbWF0Y2hlcyBhdCBsZWFzdCBv bmUgcHJlZml4LiAgVGhlIHRhZyBtYXRjaGVzIGlmIGFsbCB0aGUNCiAgICAgIHN1YnRhZ3MgaW4g dGhlICdQcmVmaXgnIGFsc28gYXBwZWFyIGluIHRoZSB0YWcuICBGb3IgZXhhbXBsZSwgdGhlDQog ICAgICBwcmVmaXggImVzLUNPIiBtYXRjaGVzIHRoZSB0YWcgImVzLUxhdG4tQ08teC1wcml2YXRl IiBiZWNhdXNlIGJvdGgNCiAgICAgIHRoZSAnZXMnIGxhbmd1YWdlIHN1YnRhZyBhbmQgJ0NPJyBy ZWdpb24gc3VidGFnIGFwcGVhciBpbiB0aGUgdGFnLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAg ICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCjMuICBSZWdp c3RyeSBGb3JtYXQgYW5kIE1haW50ZW5hbmNlDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgYW5kIHRoZSBtYWludGVuYW5jZQ0KICAgYW5kIHVw ZGF0ZSBwcm9jZWR1cmVzIGFzc29jaWF0ZWQgd2l0aCBpdCwgYXMgd2VsbCBhcyBhIHJlZ2lzdHJ5 IGZvcg0KICAgZXh0ZW5zaW9ucyB0byBsYW5ndWFnZSB0YWdzIChTZWN0aW9uIDMuNykuDQoNCiAg IFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgY29udGFpbnMgYSBjb21wcmVoZW5zaXZlIGxp c3Qgb2YgYWxsIG9mDQogICB0aGUgc3VidGFncyB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLiAgVGhp cyBhbGxvd3MgaW1wbGVtZW50ZXJzIGENCiAgIHN0cmFpZ2h0Zm9yd2FyZCBhbmQgcmVsaWFibGUg d2F5IHRvIHZhbGlkYXRlIGxhbmd1YWdlIHRhZ3MuICBUaGUNCiAgIExhbmd1YWdlIFN1YnRhZyBS ZWdpc3RyeSB3aWxsIGJlIG1haW50YWluZWQgc28gdGhhdCwgZXhjZXB0IGZvcg0KICAgZXh0ZW5z aW9uIHN1YnRhZ3MsIGl0IGlzIHBvc3NpYmxlIHRvIHZhbGlkYXRlIGFsbCBvZiB0aGUgc3VidGFn cyB0aGF0DQogICBhcHBlYXIgaW4gYSBsYW5ndWFnZSB0YWcgdW5kZXIgdGhlIHByb3Zpc2lvbnMg b2YgdGhpcyBkb2N1bWVudCBvciBpdHMNCiAgIHJldmlzaW9ucyBvciBzdWNjZXNzb3JzLiAgSW4g YWRkaXRpb24sIHRoZSBtZWFuaW5nIG9mIHRoZSB2YXJpb3VzDQogICBzdWJ0YWdzIHdpbGwgYmUg dW5hbWJpZ3VvdXMgYW5kIHN0YWJsZSBvdmVyIHRpbWUuICAoVGhlIG1lYW5pbmcgb2YNCiAgIHBy aXZhdGUgdXNlIHN1YnRhZ3MsIG9mIGNvdXJzZSwgaXMgbm90IGRlZmluZWQgYnkgdGhlIElBTkEg cmVnaXN0cnkuKQ0KDQozLjEgIEZvcm1hdCBvZiB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVn aXN0cnkNCg0KICAgVGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5ICgidGhlIHJlZ2lz dHJ5IikgY29uc2lzdHMgb2YgYSB0ZXh0DQogICBmaWxlIHRoYXQgaXMgbWFjaGluZSByZWFkYWJs ZSBpbiB0aGUgZm9ybWF0IGRlc2NyaWJlZCBpbiB0aGlzDQogICBzZWN0aW9uLCBwbHVzIGNvcGll cyBvZiB0aGUgcmVnaXN0cmF0aW9uIGZvcm1zIGFwcHJvdmVkIGluIGFjY29yZGFuY2UNCiAgIHdp dGggdGhlIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41LiAgVGhlIGV4aXN0aW5nIHJl Z2lzdHJhdGlvbg0KICAgZm9ybXMgZm9yIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFudCB0YWdz IHRha2VuIGZyb20gUkZDIDMwNjYgd2lsbA0KICAgYmUgbWFpbnRhaW5lZCBhcyBwYXJ0IG9mIHRo ZSBvYnNvbGV0ZSBSRkMgMzA2NiByZWdpc3RyeS4gIFRoZQ0KICAgcmVtYWluaW5nIHNldCBvZiBp bml0aWFsIHN1YnRhZ3Mgd2lsbCBub3QgaGF2ZSByZWdpc3RyYXRpb24gZm9ybXMNCiAgIGNyZWF0 ZWQgZm9yIHRoZW0uDQoNCiAgIFRoZSByZWdpc3RyeSBpcyBpbiB0aGUgdGV4dCBmb3JtYXQgZGVz Y3JpYmVkIGJlbG93LiAgVGhpcyBmb3JtYXQgd2FzDQogICBiYXNlZCBvbiB0aGUgcmVjb3JkLWph ciBmb3JtYXQgZGVzY3JpYmVkIGluIFtyZWNvcmQtamFyXS4NCg0KICAgRWFjaCBsaW5lIG9mIHRl eHQgaXMgbGltaXRlZCB0byA3MiBjaGFyYWN0ZXJzLCBpbmNsdWRpbmcgYWxsDQogICB3aGl0ZXNw YWNlLiAgUmVjb3JkcyBhcmUgc2VwYXJhdGVkIGJ5IGxpbmVzIGNvbnRhaW5pbmcgb25seSB0aGUN CiAgIHNlcXVlbmNlICIlJSIgKCV4MjUuMjUpLg0KDQogICBFYWNoIGZpZWxkIGNhbiBiZSB2aWV3 ZWQgYXMgYSBzaW5nbGUsIGxvZ2ljYWwgbGluZSBvZiBBU0NJSQ0KICAgY2hhcmFjdGVycywgIGNv bXByaXNpbmcgYSBmaWVsZC1uYW1lIGFuZCBhIGZpZWxkLWJvZHkgc2VwYXJhdGVkIGJ5IGENCiAg IENPTE9OIGNoYXJhY3RlciAoJXgzQSkuICBGb3IgY29udmVuaWVuY2UsIHRoZSBmaWVsZC1ib2R5 IHBvcnRpb24gb2YNCiAgIHRoaXMgY29uY2VwdHVhbCBlbnRpdHkgY2FuIGJlIHNwbGl0IGludG8g YSBtdWx0aXBsZS1saW5lDQogICByZXByZXNlbnRhdGlvbjsgdGhpcyBpcyBjYWxsZWQgImZvbGRp bmciLiAgVGhlIGZvcm1hdCBvZiB0aGUgcmVnaXN0cnkNCiAgIGlzIGRlc2NyaWJlZCBieSB0aGUg Zm9sbG93aW5nIEFCTkYgKHBlciBbUkZDMjIzNGJpc10pOg0KDQogICByZWdpc3RyeSAgID0gcmVj b3JkICooIiUlIiBDUkxGIHJlY29yZCkNCiAgIHJlY29yZCAgICAgPSAxKiggZmllbGQtbmFtZSAq U1AgIjoiICpTUCBmaWVsZC1ib2R5IENSTEYgKQ0KICAgZmllbGQtbmFtZSA9IChBTFBIQSAvIERJ R0lUKVsqKEFMUEhBIC8gRElHSVQgLyAiLSIpIChBTFBIQSAvIERJR0lUKV0NCiAgIGZpZWxkLWJv ZHkgPSAqKEFTQ0NIQVIvTFdTUCkNCiAgIEFTQ0NIQVIgICAgPSAleDIxLTI1IC8gJXgyNy03RSAv IFVOSUNIQVIgOyBOb3RlOiBBTVBFUlNBTkQgaXMgJXgyNg0KICAgVU5JQ0hBUiAgICA9ICImI3gi IDIqNkhFWERJRyAiOyINCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMg TWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIw MDUNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDI6IHJlY29yZC1qYXIgQUJO Rg0KDQogICBUaGUgc2VxdWVuY2UgJy4uJyAoJXgyRS4yRSkgaW4gYSBmaWVsZC1ib2R5IGRlbm90 ZXMgYSByYW5nZSBvZg0KICAgdmFsdWVzLiAgU3VjaCBhIHJhbmdlIHJlcHJlc2VudHMgYWxsIHN1 YnRhZ3Mgb2YgdGhlIHNhbWUgbGVuZ3RoIHRoYXQNCiAgIGFyZSBpbiBhbHBoYWJldGljIG9yIG51 bWVyaWMgb3JkZXIgd2l0aGluIHRoYXQgcmFuZ2UsIGluY2x1ZGluZyB0aGUNCiAgIHZhbHVlcyBl eHBsaWNpdGx5IG1lbnRpb25lZC4gIEZvciBleGFtcGxlICdhLi5jJyBkZW5vdGVzIHRoZSB2YWx1 ZXMNCiAgICdhJywgJ2InLCBhbmQgJ2MnIGFuZCAnMTEuLjEzJyBkZW5vdGVzIHRoZSB2YWx1ZXMg JzExJywgJzEyJywgYW5kDQogICAnMTMnLg0KDQogICBDaGFyYWN0ZXJzIGZyb20gb3V0c2lkZSB0 aGUgVVMtQVNDSUlbSVNPNjQ2XSByZXBlcnRvaXJlLCBhcyB3ZWxsIGFzDQogICB0aGUgQU1QRVJT QU5EIGNoYXJhY3RlciAoIiYiLCAleDI2KSB3aGVuIGl0IG9jY3VycyBpbiBhIGZpZWxkLWJvZHkN CiAgIGFyZSByZXByZXNlbnRlZCBieSBhICJOdW1lcmljIENoYXJhY3RlciBSZWZlcmVuY2UiIHVz aW5nIGhleGFkZWNpbWFsDQogICBub3RhdGlvbiBpbiB0aGUgc3R5bGUgdXNlZCBieSBbWE1MMTBd IChzZWUNCiAgIDxodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMteG1sLyNkdC1jaGFycmVmPikuICBU aGlzIGNvbnNpc3RzIG9mIHRoZQ0KICAgc2VxdWVuY2UgIiYjeCIgKCV4MjYuMjMuNzgpIGZvbGxv d2VkIGJ5IGEgaGV4YWRlY2ltYWwgcmVwcmVzZW50YXRpb24NCiAgIG9mIHRoZSBjaGFyYWN0ZXIn cyBjb2RlIHBvaW50IGluIFtJU08xMDY0Nl0gZm9sbG93ZWQgYnkgYSBjbG9zaW5nDQogICBzZW1p Y29sb24gKCV4M0IpLiAgRm9yIGV4YW1wbGUsIHRoZSBFVVJPIFNJR04sIFUrMjBBQywgd291bGQg YmUNCiAgIHJlcHJlc2VudGVkIGJ5IHRoZSBzZXF1ZW5jZSAiJiN4MjBBQzsiLiAgTm90ZSB0aGF0 IHRoZSBoZXhhZGVjaW1hbA0KICAgbm90YXRpb24gTUFZIGhhdmUgYmV0d2VlbiB0d28gYW5kIHNp eCBkaWdpdHMuDQoNCiAgIEFsbCBmaWVsZHMgd2hvc2UgZmllbGQtYm9keSBjb250YWlucyBhIGRh dGUgdmFsdWUgdXNlIHRoZSAiZnVsbC1kYXRlIg0KICAgZm9ybWF0IHNwZWNpZmllZCBpbiBbUkZD MzMzOV0uICBGb3IgZXhhbXBsZTogIjIwMDQtMDYtMjgiIHJlcHJlc2VudHMNCiAgIEp1bmUgMjgs IDIwMDQgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhci4NCg0KICAgVGhlIGZpcnN0IHJlY29yZCBp biB0aGUgZmlsZSBjb250YWlucyB0aGUgc2luZ2xlIGZpZWxkIHdob3NlIGZpZWxkLQ0KICAgbmFt ZSBpcyAiRmlsZS1EYXRlIi4gIFRoZSBmaWVsZC1ib2R5IG9mIHRoaXMgcmVjb3JkIGNvbnRhaW5z IHRoZSBsYXN0DQogICBtb2RpZmljYXRpb24gZGF0ZSBvZiB0aGlzIGNvcHkgb2YgdGhlIHJlZ2lz dHJ5LCBtYWtpbmcgaXQgcG9zc2libGUgdG8NCiAgIGNvbXBhcmUgZGlmZmVyZW50IHZlcnNpb25z IG9mIHRoZSByZWdpc3RyeS4gIFRoZSByZWdpc3RyeSBvbiB0aGUgSUFOQQ0KICAgd2Vic2l0ZSBp cyB0aGUgbW9zdCBjdXJyZW50LiAgVmVyc2lvbnMgd2l0aCBhbiBvbGRlciBkYXRlIHRoYW4gdGhh dA0KICAgb25lIGFyZSBub3QgdXAtdG8tZGF0ZS4NCg0KICAgRmlsZS1EYXRlOiAyMDA0LTA2LTI4 DQogICAlJQ0KDQogICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBFeGFtcGxlIG9mIHRoZSBGaWxl LURhdGUgUmVjb3JkDQoNCiAgIFN1YnNlcXVlbnQgcmVjb3JkcyByZXByZXNlbnQgc3VidGFncyBp biB0aGUgcmVnaXN0cnkuICBFYWNoIG9mIHRoZQ0KICAgZmllbGRzIGluIGVhY2ggcmVjb3JkIE1V U1Qgb2NjdXIgbm8gbW9yZSB0aGFuIG9uY2UsIHVubGVzcyBvdGhlcndpc2UNCiAgIG5vdGVkIGJl bG93LiAgRWFjaCByZWNvcmQgTVVTVCBjb250YWluIHRoZSBmb2xsb3dpbmcgZmllbGRzOg0KDQog ICBvICAnVHlwZScNCg0KICAgICAgKiAgVHlwZSdzIGZpZWxkLXZhbHVlIE1VU1QgY29uc2lzdCBv ZiBvbmUgb2YgdGhlIGZvbGxvd2luZw0KICAgICAgICAgc3RyaW5nczogImxhbmd1YWdlIiwgImV4 dGxhbmciLCAic2NyaXB0IiwgInJlZ2lvbiIsICJ2YXJpYW50IiwNCiAgICAgICAgICJncmFuZGZh dGhlcmVkIiwgYW5kICJyZWR1bmRhbnQiIGFuZCBkZW5vdGVzIHRoZSB0eXBlIG9mIHRhZyBvcg0K ICAgICAgICAgc3VidGFnLg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBp cmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJl ciAyMDA1DQoNCg0KICAgbyAgRWl0aGVyICdTdWJ0YWcnIG9yICdUYWcnDQoNCiAgICAgICogIFN1 YnRhZydzIGZpZWxkLXZhbHVlIGNvbnRhaW5zIHRoZSBzdWJ0YWcgYmVpbmcgZGVmaW5lZC4gIFRo aXMNCiAgICAgICAgIGZpZWxkIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3JkcyBvZiB3aG9zZSAn VHlwZScgaGFzIG9uZSBvZg0KICAgICAgICAgdGhlc2UgdmFsdWVzOiAibGFuZ3VhZ2UiLCAiZXh0 bGFuZyIsICJzY3JpcHQiLCAicmVnaW9uIiwgb3INCiAgICAgICAgICJ2YXJpYW50Ii4NCg0KICAg ICAgKiAgVGFnJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBjb21wbGV0ZSBsYW5ndWFnZSB0YWcu ICBUaGlzIGZpZWxkDQogICAgICAgICBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMgd2hvc2Ug J1R5cGUnIGhhcyBvbmUgb2YgdGhlc2UNCiAgICAgICAgIHZhbHVlczogImdyYW5kZmF0aGVyZWQi IG9yICJyZWR1bmRhbnQiLiAgTm90ZSB0aGF0IHRoZSBmaWVsZC0NCiAgICAgICAgIHZhbHVlIHdp bGwgYWx3YXlzIGZvbGxvdyB0aGUgJ2dyYW5kZmF0aGVyZWQnIHByb2R1Y3Rpb24gaW4gdGhlDQog ICAgICAgICBBQk5GIGluIFNlY3Rpb24gMi4xDQoNCiAgIG8gIERlc2NyaXB0aW9uDQoNCiAgICAg ICogIERlc2NyaXB0aW9uJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBub24tbm9ybWF0aXZlIGRl c2NyaXB0aW9uDQogICAgICAgICBvZiB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgQWRkZWQN Cg0KICAgICAgKiAgQWRkZWQncyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVj b3JkIHdhcyBhZGRlZCB0bw0KICAgICAgICAgdGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgJ1N1YnRh Zycgb3IgJ1RhZycgZmllbGQgTVVTVCB1c2UgbG93ZXJjYXNlIGxldHRlcnMgdG8gZm9ybSB0aGUN CiAgIHN1YnRhZyBvciB0YWcsIHdpdGggdHdvIGV4Y2VwdGlvbnMuICBTdWJ0YWdzIHdob3NlICdU eXBlJyBmaWVsZCBpcw0KICAgJ3NjcmlwdCcgKGluIG90aGVyIHdvcmRzLCBzdWJ0YWdzIGRlZmlu ZWQgYnkgSVNPIDE1OTI0KSBNVVNUIHVzZQ0KICAgdGl0bGVjYXNlLiAgU3VidGFncyB3aG9zZSAn VHlwZScgZmllbGQgaXMgJ3JlZ2lvbicgKGluIG90aGVyIHdvcmRzLA0KICAgc3VidGFncyBkZWZp bmVkIGJ5IElTTyAzMTY2KSBNVVNUIHVzZSB1cHBlcmNhc2UuICBUaGVzZSBleGNlcHRpb25zDQog ICBtaXJyb3IgdGhlIHVzZSBvZiBjYXNlIGluIHRoZSB1bmRlcmx5aW5nIHN0YW5kYXJkcy4NCg0K ICAgVGhlIGZpZWxkICdEZXNjcmlwdGlvbicgTUFZIGFwcGVhciBtb3JlIHRoYW4gb25lIHRpbWUg YW5kIGNvbnRhaW5zIGENCiAgIGRlc2NyaXB0aW9uIG9mIHRoZSB0YWcgb3Igc3VidGFnIGluIHRo ZSByZWNvcmQuICBBdCBsZWFzdCBvbmUgb2YgdGhlDQogICAnRGVzY3JpcHRpb24nIGZpZWxkcyBN VVNUIGJlIHdyaXR0ZW4gb3IgdHJhbnNjcmliZWQgaW50byB0aGUgTGF0aW4NCiAgIHNjcmlwdDsg dGhlIHNhbWUgb3IgYWRkaXRpb25hbCBmaWVsZHMgTUFZIGFsc28gaW5jbHVkZSBhIGRlc2NyaXB0 aW9uDQogICBpbiBhIG5vbi1MYXRpbiBzY3JpcHQuICBUaGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBp cyB1c2VkIGZvcg0KICAgaWRlbnRpZmljYXRpb24gcHVycG9zZXMgYW5kIFNIT1VMRCBOT1QgYmUg dGFrZW4gdG8gcmVwcmVzZW50IHRoZQ0KICAgYWN0dWFsIG5hdGl2ZSBuYW1lIG9mIHRoZSBsYW5n dWFnZSBvciB2YXJpYXRpb24gb3IgdG8gYmUgaW4gYW55DQogICBwYXJ0aWN1bGFyIGxhbmd1YWdl LiAgTW9zdCBkZXNjcmlwdGlvbnMgYXJlIHRha2VuIGRpcmVjdGx5IGZyb20NCiAgIHNvdXJjZSBz dGFuZGFyZHMgc3VjaCBhcyBJU08gNjM5IG9yIElTTyAzMTY2Lg0KDQogICBOb3RlOiBEZXNjcmlw dGlvbnMgaW4gcmVnaXN0cnkgZW50cmllcyB0aGF0IGNvcnJlc3BvbmQgdG8gSVNPIDYzOSwNCiAg IElTTyAxNTkyNCwgIElTTyAzMTY2IG9yIFVOIE0uNDkgY29kZXMgYXJlIGludGVuZGVkIG9ubHkg dG8gaW5kaWNhdGUNCiAgIHRoZSBtZWFuaW5nIG9mIHRoYXQgaWRlbnRpZmllciBhcyBkZWZpbmVk IGluIHRoZSBzb3VyY2Ugc3RhbmRhcmQgYXQNCiAgIHRoZSB0aW1lIGl0IHdhcyBhZGRlZCB0byB0 aGUgcmVnaXN0cnkuICBUaGUgZGVzY3JpcHRpb24gZG9lcyBub3QNCiAgIHJlcGxhY2UgdGhlIGNv bnRlbnQgb2YgdGhlIHNvdXJjZSBzdGFuZGFyZCBpdHNlbGYuICBUaGUgZGVzY3JpcHRpb25zDQog ICBhcmUgbm90IGludGVuZGVkIHRvIGJlIHRoZSBFbmdsaXNoIGxvY2FsaXplZCBuYW1lcyBmb3Ig dGhlIHN1YnRhZ3MuDQogICBMb2NhbGl6YXRpb24gb3IgdHJhbnNsYXRpb24gb2YgbGFuZ3VhZ2Ug dGFnIGFuZCBzdWJ0YWcgZGVzY3JpcHRpb25zDQogICBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBk b2N1bWVudC4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2 LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0K ICAgRWFjaCByZWNvcmQgTUFZIGFsc28gY29udGFpbiB0aGUgZm9sbG93aW5nIGZpZWxkczoNCg0K ICAgbyAgUHJlZmVycmVkLVZhbHVlDQoNCiAgICAgICogIEZvciBmaWVsZHMgb2YgdHlwZSAnbGFu Z3VhZ2UnLCAnZXh0bGFuZycsICdzY3JpcHQnLCAncmVnaW9uJywNCiAgICAgICAgIGFuZCAndmFy aWFudCcsICdQcmVmZXJyZWQtVmFsdWUnIGNvbnRhaW5zIGEgc3VidGFnIG9mIHRoZSBzYW1lDQog ICAgICAgICAnVHlwZScgd2hpY2ggaXMgcHJlZmVycmVkIGZvciBmb3JtaW5nIHRoZSBsYW5ndWFn ZSB0YWcuDQoNCiAgICAgICogIEZvciBmaWVsZHMgb2YgdHlwZSAnZ3JhbmRmYXRoZXJlZCcgYW5k ICdyZWR1bmRhbnQnLCBhIGNhbm9uaWNhbA0KICAgICAgICAgbWFwcGluZyB0byBhIGNvbXBsZXRl IGxhbmd1YWdlIHRhZy4NCg0KICAgbyAgRGVwcmVjYXRlZA0KDQogICAgICAqICBEZXByZWNhdGVk J3MgZmllbGQtdmFsdWUgY29udGFpbnMgdGhlIGRhdGUgdGhlIHJlY29yZCB3YXMNCiAgICAgICAg IGRlcHJlY2F0ZWQuDQoNCiAgIG8gIFByZWZpeA0KDQogICAgICAqICBQcmVmaXgncyBmaWVsZC12 YWx1ZSBjb250YWlucyBhIGxhbmd1YWdlIHRhZyB3aXRoIHdoaWNoIHRoaXMNCiAgICAgICAgIHN1 YnRhZyBNQVkgYmUgdXNlZCB0byBmb3JtIGEgbmV3IGxhbmd1YWdlIHRhZywgcGVyaGFwcyB3aXRo DQogICAgICAgICBvdGhlciBzdWJ0YWdzIGFzIHdlbGwuICBUaGlzIGZpZWxkIE1VU1Qgb25seSBh cHBlYXIgaW4gcmVjb3Jkcw0KICAgICAgICAgd2hvc2UgJ1R5cGUnIGZpZWxkLXZhbHVlIGlzICd2 YXJpYW50JyBvciAnZXh0bGFuZycuICBGb3INCiAgICAgICAgIGV4YW1wbGUsIHRoZSAnUHJlZml4 JyBmb3IgdGhlIHZhcmlhbnQgJ25lZGlzJyBpcyAnc2wnLCBtZWFuaW5nDQogICAgICAgICB0aGF0 IHRoZSB0YWdzICJzbC1uZWRpcyIgYW5kICJzbC1JVC1uZWRpcyIgbWlnaHQgYmUgYXBwcm9wcmlh dGUNCiAgICAgICAgIHdoaWxlIHRoZSB0YWcgImlzLW5lZGlzIiBpcyBub3QuDQoNCiAgIG8gIENv bW1lbnRzDQoNCiAgICAgICogIENvbW1lbnRzIGNvbnRhaW5zIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHN1YnRhZywgYXMNCiAgICAgICAgIGRlZW1lZCBhcHByb3ByaWF0ZSBmb3Ig dW5kZXJzdGFuZGluZyB0aGUgcmVnaXN0cnkgYW5kDQogICAgICAgICBpbXBsZW1lbnRpbmcgbGFu Z3VhZ2UgdGFncyB1c2luZyB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgU3VwcHJlc3MtU2Ny aXB0DQoNCiAgICAgICogIFN1cHByZXNzLVNjcmlwdCBjb250YWlucyBhIHNjcmlwdCBzdWJ0YWcg dGhhdCBTSE9VTEQgTk9UIGJlDQogICAgICAgICB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB3 aXRoIHRoZSBhc3NvY2lhdGVkIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICAgIHN1YnRhZy4gIFRo aXMgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgICAg ICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFNlZSBTZWN0aW9uIDQuMS4NCg0KICAgVGhl IGZpZWxkICdEZXByZWNhdGVkJyBNQVkgYmUgYWRkZWQgdG8gYW55IHJlY29yZCB2aWEgdGhlIG1h aW50ZW5hbmNlDQogICBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMyBvciB2aWEgdGhl IHJlZ2lzdHJhdGlvbiBwcm9jZXNzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUuICBVc3Vh bGx5IHRoZSBhZGRpdGlvbiBvZiBhICdEZXByZWNhdGVkJw0KICAgZmllbGQgaXMgZHVlIHRvIHRo ZSBhY3Rpb24gb2Ygb25lIG9mIHRoZSBzdGFuZGFyZHMgYm9kaWVzLCBzdWNoIGFzDQogICBJU08g MzE2Niwgd2l0aGRyYXdpbmcgYSBjb2RlLiAgSW4gc29tZSBoaXN0b3JpY2FsIGNhc2VzIGl0IG1p Z2h0IG5vdA0KICAgaGF2ZSBiZWVuIHBvc3NpYmxlIHRvIHJlY29uc3RydWN0IHRoZSBvcmlnaW5h bCBkZXByZWNhdGlvbiBkYXRlLiAgRm9yDQogICB0aGVzZSBjYXNlcywgYW4gYXBwcm94aW1hdGUg ZGF0ZSBhcHBlYXJzIGluIHRoZSByZWdpc3RyeS4gIEFsdGhvdWdoDQogICB2YWxpZCBpbiBsYW5n dWFnZSB0YWdzLCBzdWJ0YWdzIGFuZCB0YWdzIHdpdGggYSAnRGVwcmVjYXRlZCcgZmllbGQNCiAg IGFyZSBkZXByZWNhdGVkIGFuZCB2YWxpZGF0aW5nIHByb2Nlc3NvcnMgU0hPVUxEIE5PVCBnZW5l cmF0ZSB0aGVzZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2gg MjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0K DQogICBzdWJ0YWdzLiAgTm90ZSB0aGF0IGEgcmVjb3JkIHRoYXQgY29udGFpbnMgYSAnRGVwcmVj YXRlZCcgZmllbGQgYW5kDQogICBubyBjb3JyZXNwb25kaW5nICdQcmVmZXJyZWQtVmFsdWUnIGZp ZWxkIGhhcyBubyByZXBsYWNlbWVudCBtYXBwaW5nLg0KDQogICBUaGUgZmllbGQgJ1ByZWZlcnJl ZC1WYWx1ZScgY29udGFpbnMgYSBtYXBwaW5nIGJldHdlZW4gdGhlIHJlY29yZCBpbg0KICAgd2hp Y2ggaXQgYXBwZWFycyBhbmQgYW5vdGhlciB0YWcgb3Igc3VidGFnLiAgVGhlIHZhbHVlIGluIHRo aXMgZmllbGQNCiAgIGlzIFNUUk9OR0xZIFJFQ09NTUVOREVEIGFzIHRoZSBiZXN0IGNob2ljZSB0 byByZXByZXNlbnQgdGhlIHZhbHVlIG9mDQogICB0aGlzIHJlY29yZCB3aGVuIHNlbGVjdGluZyBh IGxhbmd1YWdlIHRhZy4gIFRoZXNlIHZhbHVlcyBmb3JtIHRocmVlDQogICBncm91cHM6DQoNCiAg IDEuICBJU08gNjM5IGxhbmd1YWdlIGNvZGVzIHdoaWNoIHdlcmUgbGF0ZXIgd2l0aGRyYXduIGlu IGZhdm9yIG9mDQogICAgICAgb3RoZXIgY29kZXMuICBUaGVzZSB2YWx1ZXMgYXJlIG1vc3RseSBh IGhpc3RvcmljYWwgY3VyaW9zaXR5Lg0KDQogICAyLiAgSVNPIDMxNjYgcmVnaW9uIGNvZGVzIHdo aWNoIGhhdmUgYmVlbiB3aXRoZHJhd24gaW4gZmF2b3Igb2YgYSBuZXcNCiAgICAgICBjb2RlLiAg VGhpcyBzb21ldGltZXMgaGFwcGVucyB3aGVuIGEgY291bnRyeSBjaGFuZ2VzIGl0cyBuYW1lIG9y DQogICAgICAgYWRtaW5pc3RyYXRpb24gaW4gc3VjaCBhIHdheSB0aGF0IHdhcnJhbnRzIGEgbmV3 IHJlZ2lvbiBjb2RlLg0KDQogICAzLiAgVGFncyBncmFuZGZhdGhlcmVkIGZyb20gUkZDIDMwNjYu ICBJbiBtYW55IGNhc2VzIHRoZXNlIHRhZ3MgaGF2ZQ0KICAgICAgIGJlY29tZSBvYnNvbGV0ZSBi ZWNhdXNlIHRoZSB2YWx1ZXMgdGhleSByZXByZXNlbnQgd2VyZSBsYXRlcg0KICAgICAgIGVuY29k ZWQgYnkgSVNPIDYzOS4NCg0KICAgUmVjb3JkcyB0aGF0IGNvbnRhaW4gYSAnUHJlZmVycmVkLVZh bHVlJyBmaWVsZCBNVVNUIGFsc28gaGF2ZSBhDQogICAnRGVwcmVjYXRlZCcgZmllbGQuICBUaGlz IGZpZWxkIGNvbnRhaW5zIGEgZGF0ZSBvZiBkZXByZWNhdGlvbi4gIFRodXMNCiAgIGEgbGFuZ3Vh Z2UgdGFnIHByb2Nlc3NvciBjYW4gdXNlIHRoZSByZWdpc3RyeSB0byBjb25zdHJ1Y3QgdGhlIHZh bGlkLA0KICAgbm9uLWRlcHJlY2F0ZWQgc2V0IG9mIHN1YnRhZ3MgZm9yIGEgZ2l2ZW4gZGF0ZS4g IEluIGFkZGl0aW9uLCBmb3IgYW55DQogICBnaXZlbiB0YWcsIGEgcHJvY2Vzc29yIGNhbiBjb25z dHJ1Y3QgdGhlIHNldCBvZiB2YWxpZCBsYW5ndWFnZSB0YWdzDQogICB0aGF0IGNvcnJlc3BvbmQg dG8gdGhhdCB0YWcgZm9yIGFsbCBkYXRlcyB1cCB0byB0aGUgZGF0ZSBvZiB0aGUNCiAgIHJlZ2lz dHJ5LiAgVGhlIGFiaWxpdHkgdG8gZG8gdGhlc2UgbWFwcGluZ3MgTUFZIGJlIGJlbmVmaWNpYWwg dG8NCiAgIGFwcGxpY2F0aW9ucyB0aGF0IGFyZSBtYXRjaGluZywgc2VsZWN0aW5nLCBmb3IgZmls dGVyaW5nIGNvbnRlbnQNCiAgIGJhc2VkIG9uIGl0cyBsYW5ndWFnZSB0YWdzLg0KDQogICBOb3Rl IHRoYXQgJ1ByZWZlcnJlZC1WYWx1ZScgbWFwcGluZ3MgaW4gcmVjb3JkcyBvZiB0eXBlICdyZWdp b24nDQogICBzb21ldGltZXMgZG8gbm90IHJlcHJlc2VudCBleGFjdGx5IHRoZSBzYW1lIG1lYW5p bmcgYXMgdGhlIG9yaWdpbmFsDQogICB2YWx1ZS4gIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgZm9y IGEgY291bnRyeSBjb2RlIHRvIGJlIGNoYW5nZWQgYW5kDQogICB0aGUgZWZmZWN0IHRoaXMgaGFz IG9uIHRoZSBmb3JtYXRpb24gb2YgbGFuZ3VhZ2UgdGFncyB3aWxsIGRlcGVuZCBvbg0KICAgdGhl IG5hdHVyZSBvZiB0aGUgY2hhbmdlIGluIHF1ZXN0aW9uLg0KDQogICBJbiBwYXJ0aWN1bGFyLCB0 aGUgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQgZG9lcyBub3QgaW1wbHkgcmV0YWdnaW5nDQogICBj b250ZW50IHRoYXQgdXNlcyB0aGUgYWZmZWN0ZWQgc3VidGFnLg0KDQogICBUaGUgZmllbGQgJ1By ZWZlcnJlZC1WYWx1ZScgTVVTVCBOT1QgYmUgbW9kaWZpZWQgb25jZSBjcmVhdGVkIGluIHRoZQ0K ICAgcmVnaXN0cnkuICBUaGUgZmllbGQgTUFZIGJlIGFkZGVkIHRvIHJlY29yZHMgb2YgdHlwZSAi Z3JhbmRmYXRoZXJlZCINCiAgIGFuZCAicmVnaW9uIiBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGlu IFNlY3Rpb24gMy4zLiAgT3RoZXJ3aXNlIHRoZQ0KICAgZmllbGQgTVVTVCBOT1QgYmUgYWRkZWQg dG8gYW55IHJlY29yZCBhbHJlYWR5IGluIHRoZSByZWdpc3RyeS4NCg0KICAgVGhlICdQcmVmZXJy ZWQtVmFsdWUnIGZpZWxkIGluIHJlY29yZHMgb2YgdHlwZSAiZ3JhbmRmYXRoZXJlZCIgYW5kDQog ICAicmVkdW5kYW50IiBjb250YWlucyB3aG9sZSBsYW5ndWFnZSB0YWdzIHRoYXQgYXJlIHN0cm9u Z2x5DQogICBSRUNPTU1FTkRFRCBmb3IgdXNlIGluIHBsYWNlIG9mIHRoZSByZWNvcmQncyB2YWx1 ZS4gIEluIG1hbnkgY2FzZXMNCiAgIHRoZSBtYXBwaW5ncyB3ZXJlIGNyZWF0ZWQgYnkgZGVwcmVj YXRpb24gb2YgdGhlIHRhZ3MgZHVyaW5nIHRoZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMjJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMDUNCg0KDQogICBwZXJpb2QgYmVmb3JlIHRoaXMgZG9jdW1lbnQgd2FzIGFk b3B0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAibm8tDQogICBueW4iIHdhcyBkZXByZWNhdGVk IGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTEgZGVmaW5lZCBsYW5ndWFnZSBjb2RlDQogICAnbm4n Lg0KDQogICBSZWNvcmRzIG9mIHR5cGUgJ3ZhcmlhbnQnIE1BWSBoYXZlIG1vcmUgdGhhbiBvbmUg ZmllbGQgb2YgdHlwZQ0KICAgJ1ByZWZpeCcuICBBZGRpdGlvbmFsIGZpZWxkcyBvZiB0aGlzIHR5 cGUgTUFZIGJlIGFkZGVkIHRvIGEgJ3ZhcmlhbnQnDQogICByZWNvcmQgdmlhIHRoZSByZWdpc3Ry YXRpb24gcHJvY2Vzcy4NCg0KICAgUmVjb3JkcyBvZiB0eXBlICdleHRsYW5nJyBNVVNUIGhhdmUg X2V4YWN0bHlfIG9uZSAnUHJlZml4JyBmaWVsZC4NCg0KICAgVGhlIGZpZWxkLXZhbHVlIG9mIHRo ZSAnUHJlZml4JyBmaWVsZCBjb25zaXN0cyBvZiBhIGxhbmd1YWdlIHRhZw0KICAgd2hvc2Ugc3Vi dGFncyBhcmUgYXBwcm9wcmlhdGUgdG8gdXNlIHdpdGggdGhpcyBzdWJ0YWcuICBGb3IgZXhhbXBs ZSwNCiAgIHRoZSB2YXJpYW50IHN1YnRhZyAnMTk5NicgaGFzIGEgUHJlZml4IGZpZWxkIG9mICJk ZSIuICBUaGlzIG1lYW5zDQogICB0aGF0IHRhZ3Mgc3RhcnRpbmcgd2l0aCB0aGUgc2VxdWVuY2Ug ImRlLSIgYXJlIGFwcHJvcHJpYXRlIHdpdGggdGhpcw0KICAgc3VidGFnLCBzbyAiZGUtTGF0Zy0x OTk2IiBhbmQgImRlLUNILTE5OTYiIGFyZSBib3RoIGFjY2VwdGFibGUsIHdoaWxlDQogICB0aGUg dGFnICJmci0xOTk2IiBpcyBhbiBpbmFwcHJvcHJpYXRlIGNob2ljZS4NCg0KICAgVGhlIGZpZWxk IG9mIHR5cGUgJ1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZCBmcm9tIGFueSByZWNvcmQuICBU aGUNCiAgIGZpZWxkLXZhbHVlIGZvciB0aGlzIHR5cGUgb2YgZmllbGQgTVVTVCBOT1QgYmUgbW9k aWZpZWQuDQoNCiAgIFRoZSBmaWVsZCAnQ29tbWVudHMnIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9u Y2UgcGVyIHJlY29yZC4gIFRoaXMNCiAgIGZpZWxkIE1BWSBiZSBpbnNlcnRlZCBvciBjaGFuZ2Vk IHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgYW5kIG5vDQogICBndWFyYW50ZWUgb2Ygc3Rh YmlsaXR5IGlzIHByb3ZpZGVkLiAgVGhlIGNvbnRlbnQgb2YgdGhpcyBmaWVsZCBpcyBub3QNCiAg IHJlc3RyaWN0ZWQsIGV4Y2VwdCBieSB0aGUgbmVlZCB0byByZWdpc3RlciB0aGUgaW5mb3JtYXRp b24sIHRoZQ0KICAgc3VpdGFiaWxpdHkgb2YgdGhlIHJlcXVlc3QsIGFuZCBieSByZWFzb25hYmxl IHByYWN0aWNhbCBzaXplDQogICBsaW1pdGF0aW9ucy4NCg0KICAgVGhlIGZpZWxkICdTdXBwcmVz cy1TY3JpcHQnIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3JkcyB3aG9zZSAnVHlwZScNCiAgIGZp ZWxkLXZhbHVlIGlzICdsYW5ndWFnZScuICBUaGlzIGZpZWxkIE1VU1QgTk9UIGFwcGVhciBtb3Jl IHRoYW4gb25lDQogICB0aW1lIGluIGEgcmVjb3JkLiAgVGhpcyBmaWVsZCBpbmRpY2F0ZXMgYSBz Y3JpcHQgdXNlZCB0byB3cml0ZSB0aGUNCiAgIG92ZXJ3aGVsbWluZyBtYWpvcml0eSBvZiBkb2N1 bWVudHMgZm9yIHRoZSBnaXZlbiBsYW5ndWFnZSBhbmQgd2hpY2gNCiAgIHRoZXJlZm9yZSBhZGRz IG5vIGRpc3Rpbmd1aXNoaW5nIGluZm9ybWF0aW9uIHRvIGEgbGFuZ3VhZ2UgdGFnLiAgSXQNCiAg IGhlbHBzIGVuc3VyZSBncmVhdGVyIGNvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGUgbGFuZ3VhZ2Ug dGFncw0KICAgZ2VuZXJhdGVkIGFjY29yZGluZyB0byB0aGUgcnVsZXMgaW4gdGhpcyBkb2N1bWVu dCBhbmQgbGFuZ3VhZ2UgdGFncw0KICAgYW5kIHRhZyBwcm9jZXNzb3JzIG9yIGNvbnN1bWVycyBi YXNlZCBvbiBSRkMgMzA2Ni4gIEZvciBleGFtcGxlLA0KICAgdmlydHVhbGx5IGFsbCBJY2VsYW5k aWMgZG9jdW1lbnRzIGFyZSB3cml0dGVuIGluIHRoZSBMYXRpbiBzY3JpcHQsDQogICBtYWtpbmcg dGhlIHN1YnRhZyAnTGF0bicgcmVkdW5kYW50IGluIHRoZSB0YWcgImlzLUxhdG4iLg0KDQozLjIg IExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlcg0KDQogICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmll d2VyIGlzIGFwcG9pbnRlZCBieSB0aGUgSUVTRyBmb3IgYW4NCiAgIGluZGVmaW5pdGUgdGVybSwg c3ViamVjdCB0byByZW1vdmFsIG9yIHJlcGxhY2VtZW50IGF0IHRoZSBJRVNHJ3MNCiAgIGRpc2Ny ZXRpb24uICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIG1vZGVyYXRlcyB0aGUgaWV0Zi0N CiAgIGxhbmd1YWdlcyBtYWlsaW5nIGxpc3QsIHJlc3BvbmRzIHRvIHJlcXVlc3RzIGZvciByZWdp c3RyYXRpb24sIGFuZA0KICAgcGVyZm9ybXMgdGhlIG90aGVyIHJlZ2lzdHJ5IG1haW50ZW5hbmNl IGR1dGllcyBkZXNjcmliZWQgaW4NCiAgIFNlY3Rpb24gMy4zLiAgT25seSB0aGUgTGFuZ3VhZ2Ug U3VidGFnIFJldmlld2VyIGlzIHBlcm1pdHRlZCB0bw0KICAgcmVxdWVzdCBJQU5BIHRvIGNoYW5n ZSwgdXBkYXRlIG9yIGFkZCByZWNvcmRzIHRvIHRoZSBMYW5ndWFnZSBTdWJ0YWcNCiAgIFJlZ2lz dHJ5Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIw MDYgICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBU aGUgcGVyZm9ybWFuY2Ugb3IgZGVjaXNpb25zIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3 ZXIgTUFZIGJlDQogICBhcHBlYWxlZCB0byB0aGUgSUVTRyB1bmRlciB0aGUgc2FtZSBydWxlcyBh cyBvdGhlciBJRVRGIGRlY2lzaW9ucw0KICAgKHNlZSBbUkZDMjAyNl0pLiAgVGhlIElFU0cgY2Fu IHJldmVyc2Ugb3Igb3ZlcnR1cm4gdGhlIGRlY2lzaW9uIG9mDQogICB0aGUgTGFuZ3VhZ2UgU3Vi dGFnIFJldmlld2VyLCBwcm92aWRlIGd1aWRhbmNlLCBvciB0YWtlIG90aGVyDQogICBhcHByb3By aWF0ZSBhY3Rpb25zLg0KDQozLjMgIE1haW50ZW5hbmNlIG9mIHRoZSBSZWdpc3RyeQ0KDQogICBN YWludGVuYW5jZSBvZiB0aGUgcmVnaXN0cnkgcmVxdWlyZXMgdGhhdCBhcyBjb2RlcyBhcmUgYXNz aWduZWQgb3INCiAgIHdpdGhkcmF3biBieSBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBh bmQgVU4gTS40OSwgdGhlIExhbmd1YWdlDQogICBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBldmFsdWF0 ZSBlYWNoIGNoYW5nZSwgZGV0ZXJtaW5lIHdoZXRoZXIgaXQNCiAgIGNvbmZsaWN0cyB3aXRoIGV4 aXN0aW5nIHJlZ2lzdHJ5IGVudHJpZXMsIGFuZCBzdWJtaXQgdGhlIGluZm9ybWF0aW9uDQogICB0 byBJQU5BIGZvciBpbmNsdXNpb24gaW4gdGhlIHJlZ2lzdHJ5LiAgSWYgYSBjaGFuZ2UgdGFrZXMg cGxhY2UgYW5kDQogICB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGRvZXMgbm90IGRvIHRo aXMgaW4gYSB0aW1lbHkgbWFubmVyLA0KICAgdGhlbiBhbnkgaW50ZXJlc3RlZCBwYXJ0eSBNQVkg dXNlIHRoZSBwcm9jZWR1cmUgaW4gU2VjdGlvbiAzLjUgdG8NCiAgIHJlZ2lzdGVyIHRoZSBhcHBy b3ByaWF0ZSB1cGRhdGUuDQoNCiAgIE5vdGU6IFRoZSByZWR1bmRhbnQgYW5kIGdyYW5kZmF0aGVy ZWQgZW50cmllcyB0b2dldGhlciBhcmUgdGhlDQogICBjb21wbGV0ZSBsaXN0IG9mIHRhZ3MgcmVn aXN0ZXJlZCB1bmRlciBbUkZDMzA2Nl0uICBUaGUgcmVkdW5kYW50IHRhZ3MNCiAgIGFyZSB0aG9z ZSB0aGF0IGNhbiBub3cgYmUgZm9ybWVkIHVzaW5nIHRoZSBzdWJ0YWdzIGRlZmluZWQgaW4gdGhl DQogICByZWdpc3RyeSB0b2dldGhlciB3aXRoIHRoZSBydWxlcyBvZiAgU2VjdGlvbiAyLjIuICBU aGUgZ3JhbmRmYXRoZXJlZA0KICAgZW50cmllcyBpbmNsdWRlIHRob3NlIHRoYXQgY2FuIG5ldmVy IGJlIGxlZ2FsIHVuZGVyIHRob3NlIHNhbWUNCiAgIHByb3Zpc2lvbnMuDQoNCiAgIFRoZSBzZXQg b2YgcmVkdW5kYW50IGFuZCBncmFuZGZhdGhlcmVkIHRhZ3MgaXMgcGVybWFuZW50IGFuZCBzdGFi bGU6DQogICBuZXcgZW50cmllcyBpbiB0aGlzIHNlY3Rpb24gTVVTVCBOT1QgYmUgYWRkZWQgYW5k IGV4aXN0aW5nIGVudHJpZXMNCiAgIE1VU1QgTk9UIGJlIHJlbW92ZWQuICBSZWNvcmRzIG9mIHR5 cGUgJ2dyYW5kZmF0aGVyZWQnIE1BWSBoYXZlIHRoZWlyDQogICB0eXBlIGNvbnZlcnRlZCB0byAn cmVkdW5kYW50Jzogc2VlIGl0ZW0gMTIgaW4gU2VjdGlvbiAzLjYgZm9yIG1vcmUNCiAgIGluZm9y bWF0aW9uLiAgVGhlIGRlY2lzaW9uIG1ha2luZyBwcm9jZXNzIGFib3V0IHdoaWNoIHRhZ3Mgd2Vy ZQ0KICAgaW5pdGlhbGx5IGdyYW5kZmF0aGVyZWQgYW5kIHdoaWNoIHdlcmUgbWFkZSByZWR1bmRh bnQgaXMgZGVzY3JpYmVkIGluDQogICBbaW5pdGlhbC1yZWdpc3RyeV0uDQoNCiAgIFJGQyAzMDY2 IHRhZ3MgdGhhdCB3ZXJlIGRlcHJlY2F0ZWQgcHJpb3IgdG8gdGhlIGFkb3B0aW9uIG9mIHRoaXMN CiAgIGRvY3VtZW50IGFyZSBwYXJ0IG9mIHRoZSBsaXN0IG9mIGdyYW5kZmF0aGVyZWQgdGFncyBh bmQgdGhlaXINCiAgIGNvbXBvbmVudCBzdWJ0YWdzIHdlcmUgbm90IGluY2x1ZGVkIGFzIHJlZ2lz dGVyZWQgdmFyaWFudHMgKGFsdGhvdWdoDQogICB0aGV5IHJlbWFpbiBlbGlnaWJsZSBmb3IgcmVn aXN0cmF0aW9uKS4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJhcnQtDQogICBsb2piYW4iIHdhcyBk ZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBsYW5ndWFnZSBzdWJ0YWcgJ2pibycuDQoNCiAgIFRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBlbnN1cmUgdGhhdCBuZXcgc3VidGFncyBt ZWV0IHRoZQ0KICAgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gNC4xIG9yIHN1Ym1pdCBhbiBhcHBy b3ByaWF0ZSBhbHRlcm5hdGUgc3VidGFnDQogICBhcyBkZXNjcmliZWQgaW4gdGhhdCBzZWN0aW9u LiAgV2hlbiBlaXRoZXIgYSBjaGFuZ2Ugb3IgYWRkaXRpb24gdG8NCiAgIHRoZSByZWdpc3RyeSBp cyBuZWVkZWQsIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBwcmVwYXJlIHRoZQ0K ICAgY29tcGxldGUgcmVjb3JkLCBpbmNsdWRpbmcgYWxsIGZpZWxkcywgYW5kIGZvcndhcmQgaXQg dG8gSUFOQSBmb3INCiAgIGluc2VydGlvbiBpbnRvIHRoZSByZWdpc3RyeS4gIEVhY2ggcmVjb3Jk IGJlaW5nIG1vZGlmaWVkIG9yIGluc2VydGVkDQogICBNVVNUIGJlIGZvcndhcmRlZCBpbiBhIHNl cGFyYXRlIG1lc3NhZ2UuDQoNCiAgIElmIGEgcmVjb3JkIHJlcHJlc2VudHMgYSBuZXcgc3VidGFn IHRoYXQgZG9lcyBub3QgY3VycmVudGx5IGV4aXN0IGluDQogICB0aGUgcmVnaXN0cnksIHRoZW4g dGhlIG1lc3NhZ2UncyBzdWJqZWN0IGxpbmUgTVVTVCBpbmNsdWRlIHRoZSB3b3JkDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAg ICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgICJJTlNFUlQiLiAgSWYg dGhlIHJlY29yZCByZXByZXNlbnRzIGEgY2hhbmdlIHRvIGFuIGV4aXN0aW5nIHN1YnRhZywNCiAg IHRoZW4gdGhlIHN1YmplY3QgbGluZSBvZiB0aGUgbWVzc2FnZSBNVVNUIGluY2x1ZGUgdGhlIHdv cmQgIk1PRElGWSIuDQogICBUaGUgbWVzc2FnZSBNVVNUIGNvbnRhaW4gYm90aCB0aGUgcmVjb3Jk IGZvciB0aGUgc3VidGFnIGJlaW5nDQogICBpbnNlcnRlZCBvciBtb2RpZmllZCBhbmQgdGhlIG5l dyBGaWxlLURhdGUgcmVjb3JkLiAgSGVyZSBpcyBhbg0KICAgZXhhbXBsZSBvZiB3aGF0IHRoZSBi b2R5IG9mIHRoZSBtZXNzYWdlIG1pZ2h0IGNvbnRhaW46DQoNCiAgIExBTkdVQUdFIFNVQlRBRyBN T0RJRklDQVRJT04NCiAgIEZpbGUtRGF0ZTogMjAwNS0wMS0wMg0KICAgJSUNCiAgIFR5cGU6IHZh cmlhbnQNCiAgIFN1YnRhZzogbmVkaXMNCiAgIERlc2NyaXB0aW9uOiBOYXRpc29uZSBkaWFsZWN0 DQogICBEZXNjcmlwdGlvbjogTmFkaXphIGRpYWxlY3QNCiAgIEFkZGVkOiAyMDAzLTEwLTA5DQog ICBQcmVmaXg6IHNsDQogICBDb21tZW50czogVGhpcyBpcyBhIGNvbW1lbnQgc2hvd24NCiAgICAg YXMgYW4gZXhhbXBsZS4NCiAgICUlDQoNCiAgICAgICAgIEZpZ3VyZSA0OiBFeGFtcGxlIG9mIGEg TGFuZ3VhZ2UgU3VidGFnIE1vZGlmaWNhdGlvbiBGb3JtDQoNCiAgIFdoZW5ldmVyIGFuIGVudHJ5 IGlzIGNyZWF0ZWQgb3IgbW9kaWZpZWQgaW4gdGhlIHJlZ2lzdHJ5LCB0aGUgJ0ZpbGUtDQogICBE YXRlJyByZWNvcmQgYXQgdGhlIHN0YXJ0IG9mIHRoZSByZWdpc3RyeSBpcyB1cGRhdGVkIHRvIHJl ZmxlY3QgdGhlDQogICBtb3N0IHJlY2VudCBtb2RpZmljYXRpb24gZGF0ZSBpbiB0aGUgW1JGQzMz MzldICJmdWxsLWRhdGUiIGZvcm1hdC4NCg0KICAgQmVmb3JlIGZvcndhcmRpbmcgYSBuZXcgcmVn aXN0cmF0aW9uIHRvIElBTkEsIHRoZSBMYW5ndWFnZSBTdWJ0YWcNCiAgIFJldmlld2VyIE1VU1Qg ZW5zdXJlIHRoYXQgdmFsdWVzIGluIHRoZSAnU3VidGFnJyBmaWVsZCBtYXRjaCBjYXNlDQogICBh Y2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uIGluIFNlY3Rpb24gMy4xLg0KDQozLjQgIFN0YWJp bGl0eSBvZiBJQU5BIFJlZ2lzdHJ5IEVudHJpZXMNCg0KICAgVGhlIHN0YWJpbGl0eSBvZiBlbnRy aWVzIGFuZCB0aGVpciBtZWFuaW5nIGluIHRoZSByZWdpc3RyeSBpcw0KICAgY3JpdGljYWwgdG8g dGhlIGxvbmcgdGVybSBzdGFiaWxpdHkgb2YgbGFuZ3VhZ2UgdGFncy4gIFRoZSBydWxlcyBpbg0K ICAgdGhpcyBzZWN0aW9uIGd1YXJhbnRlZSB0aGF0IGEgc3BlY2lmaWMgbGFuZ3VhZ2UgdGFnJ3Mg bWVhbmluZyBpcw0KICAgc3RhYmxlIG92ZXIgdGltZSBhbmQgd2lsbCBub3QgY2hhbmdlLg0KDQog ICBUaGVzZSBydWxlcyBzcGVjaWZpY2FsbHkgZGVhbCB3aXRoIGhvdyBjaGFuZ2VzIHRvIGNvZGVz IChpbmNsdWRpbmcNCiAgIHdpdGhkcmF3YWwgYW5kIGRlcHJlY2F0aW9uIG9mIGNvZGVzKSBtYWlu dGFpbmVkIGJ5IElTTyA2MzksIElTTw0KICAgMTU5MjQsIElTTyAzMTY2LCBhbmQgVU4gTS40OSBh cmUgcmVmbGVjdGVkIGluIHRoZSBJQU5BIExhbmd1YWdlDQogICBTdWJ0YWcgUmVnaXN0cnkuICBB c3NpZ25tZW50cyB0byB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkNCiAgIE1VU1Qg Zm9sbG93IHRoZSBmb2xsb3dpbmcgc3RhYmlsaXR5IHJ1bGVzOg0KDQogICAxLiAgIFZhbHVlcyBp biB0aGUgZmllbGRzICdUeXBlJywgJ1N1YnRhZycsICdUYWcnLCAnQWRkZWQnLA0KICAgICAgICAn RGVwcmVjYXRlZCcgYW5kICdQcmVmZXJyZWQtVmFsdWUnIE1VU1QgTk9UIGJlIGNoYW5nZWQgYW5k IGFyZQ0KICAgICAgICBndWFyYW50ZWVkIHRvIGJlIHN0YWJsZSBvdmVyIHRpbWUuDQoNCiAgIDIu ICAgVmFsdWVzIGluIHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIE1VU1QgTk9UIGJlIGNoYW5nZWQg aW4gYSB3YXkNCiAgICAgICAgdGhhdCB3b3VsZCBpbnZhbGlkYXRlIHByZXZpb3VzbHktZXhpc3Rp bmcgdGFncy4gIFRoZXkgTUFZIGJlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhw aXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAyNV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1i ZXIgMjAwNQ0KDQoNCiAgICAgICAgYnJvYWRlbmVkIHNvbWV3aGF0IGluIHNjb3BlLCBjaGFuZ2Vk IHRvIGFkZCBpbmZvcm1hdGlvbiwgb3INCiAgICAgICAgYWRhcHRlZCB0byB0aGUgbW9zdCBjb21t b24gbW9kZXJuIHVzYWdlLiAgRm9yIGV4YW1wbGUsIGNvdW50cmllcw0KICAgICAgICBvY2Nhc2lv bmFsbHkgY2hhbmdlIHRoZWlyIG9mZmljaWFsIG5hbWVzOiBhbiBoaXN0b3JpY2FsIGV4YW1wbGUN CiAgICAgICAgb2YgdGhpcyB3b3VsZCBiZSAiVXBwZXIgVm9sdGEiIGNoYW5naW5nIHRvICJCdXJr aW5hIEZhc28iLg0KDQogICAzLiAgIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcgTUFZIGJl IGFkZGVkIHRvIHJlY29yZHMgb2YgdHlwZQ0KICAgICAgICAndmFyaWFudCcgdmlhIHRoZSByZWdp c3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgNC4gICBWYWx1ZXMgaW4gdGhlIGZpZWxkICdQcmVmaXgn IE1BWSBiZSBtb2RpZmllZCwgc28gbG9uZyBhcyB0aGUNCiAgICAgICAgbW9kaWZpY2F0aW9ucyBi cm9hZGVuIHRoZSBzZXQgb2YgcHJlZml4ZXMuICBUaGF0IGlzLCBhIHByZWZpeA0KICAgICAgICBN QVkgYmUgcmVwbGFjZWQgYnkgb25lIG9mIGl0cyBvd24gcHJlZml4ZXMuICBGb3IgZXhhbXBsZSwg dGhlDQogICAgICAgIHByZWZpeCAiZW4tVVMiIGNvdWxkIGJlIHJlcGxhY2VkIGJ5ICJlbiIsIGJ1 dCBub3QgYnkgdGhlDQogICAgICAgIHByZWZpeGVzICJlbi1MYXRuIiwgImZyIiwgb3IgImVuLVVT LWJvb250Ii4gIElmIG9uZSBvZiB0aG9zZQ0KICAgICAgICBwcmVmaXhlcyB3ZXJlIG5lZWRlZCwg YSBuZXcgUHJlZml4IFNIT1VMRCBiZSByZWdpc3RlcmVkLg0KDQogICA1LiAgIFZhbHVlcyBpbiB0 aGUgZmllbGQgJ1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZC4NCg0KICAgNi4gICBUaGUgZmll bGQgJ0NvbW1lbnRzJyBNQVkgYmUgYWRkZWQsIGNoYW5nZWQsIG1vZGlmaWVkLCBvciByZW1vdmVk DQogICAgICAgIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3IgYW55IG9mIHRoZSBwcm9j ZXNzZXMgb3INCiAgICAgICAgY29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlv bi4NCg0KICAgNy4gICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTUFZIGJlIGFkZGVkIG9y IHJlbW92ZWQgdmlhIHRoZQ0KICAgICAgICByZWdpc3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgOC4g ICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIGFuZCBJU08gMzE2NiB0aGF0 IGRvIG5vdA0KICAgICAgICBjb25mbGljdCB3aXRoIGV4aXN0aW5nIHN1YnRhZ3Mgb2YgdGhlIGFz c29jaWF0ZWQgdHlwZSBhbmQgd2hvc2UNCiAgICAgICAgbWVhbmluZyBpcyBub3QgdGhlIHNhbWUg YXMgYW4gZXhpc3Rpbmcgc3VidGFnIG9mIHRoZSBzYW1lIHR5cGUNCiAgICAgICAgYXJlIGVudGVy ZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBuZXcgcmVjb3Jkcy4NCg0KICAgOS4gICBDb2Rl cyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIG9yIElTTyAzMTY2IHRoYXQgYXJlDQog ICAgICAgIHdpdGhkcmF3biBieSB0aGVpciByZXNwZWN0aXZlIG1haW50ZW5hbmNlIG9yIHJlZ2lz dHJhdGlvbg0KICAgICAgICBhdXRob3JpdHkgcmVtYWluIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3Mu ICBBICdEZXByZWNhdGVkJyBmaWVsZA0KICAgICAgICBjb250YWluaW5nIHRoZSBkYXRlIG9mIHdp dGhkcmF3YWwgaXMgYWRkZWQgdG8gdGhlIHJlY29yZC4gIElmIGENCiAgICAgICAgbmV3IHJlY29y ZCBvZiB0aGUgc2FtZSB0eXBlIGlzIGFkZGVkIHRoYXQgcmVwcmVzZW50cyBhDQogICAgICAgIHJl cGxhY2VtZW50IHZhbHVlLCB0aGVuIGEgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQgTUFZIGFsc28g YmUNCiAgICAgICAgYWRkZWQuICBUaGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgTUFZIGJlIHVzZWQg dG8gYWRkIGNvbW1lbnRzDQogICAgICAgIGFib3V0IHRoZSB3aXRoZHJhd2FsIG9mIHRoZSBjb2Rl IGJ5IHRoZSByZXNwZWN0aXZlIHN0YW5kYXJkLg0KDQogICAgICAgIEV4YW1wbGUgVGhlIHJlZ2lv biBjb2RlICdUTCcgd2FzIGFzc2lnbmVkIHRvIHRoZSBjb3VudHJ5ICdUaW1vci0NCiAgICAgICAg ICAgTGVzdGUnLCByZXBsYWNpbmcgdGhlIGNvZGUgJ1RQJyAod2hpY2ggd2FzIGFzc2lnbmVkIHRv ICdFYXN0DQogICAgICAgICAgIFRpbW9yJyB3aGVuIGl0IHdhcyB1bmRlciBhZG1pbmlzdHJhdGlv biBieSBQb3J0dWdhbCkuICBUaGUNCiAgICAgICAgICAgc3VidGFnICdUUCcgcmVtYWlucyB2YWxp ZCBpbiBsYW5ndWFnZSB0YWdzLCBidXQgaXRzIHJlY29yZA0KICAgICAgICAgICBjb250YWlucyB0 aGUgYSAnUHJlZmVycmVkLVZhbHVlJyBvZiAnVEwnIGFuZCBpdHMgZmllbGQNCiAgICAgICAgICAg J0RlcHJlY2F0ZWQnIGNvbnRhaW5zIHRoZSBkYXRlIHRoZSBuZXcgY29kZSB3YXMgYXNzaWduZWQN CiAgICAgICAgICAgKCcyMDA0LTA3LTA2JykuDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAyNl0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIDEwLiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYz OSwgSVNPIDE1OTI0LCBvciBJU08gMzE2NiB0aGF0IGNvbmZsaWN0DQogICAgICAgIHdpdGggZXhp c3Rpbmcgc3VidGFncyBvZiB0aGUgYXNzb2NpYXRlZCB0eXBlLCBpbmNsdWRpbmcgc3VidGFncw0K ICAgICAgICB0aGF0IGFyZSBkZXByZWNhdGVkLCBNVVNUIE5PVCBiZSBlbnRlcmVkIGludG8gdGhl IHJlZ2lzdHJ5LiAgVGhlDQogICAgICAgIGZvbGxvd2luZyBhZGRpdGlvbmFsIGNvbnNpZGVyYXRp b25zIGFwcGx5IHRvIHN1YnRhZyB2YWx1ZXMgdGhhdA0KICAgICAgICBhcmUgcmVhc3NpZ25lZDoN Cg0KICAgICAgICBBLiAgRm9yIElTTyA2MzkgY29kZXMsIGlmIHRoZSBuZXdseSBhc3NpZ25lZCBj b2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgICAgbm90IHJlcHJlc2VudGVkIGJ5IGEgc3VidGFn IGluIHRoZSBJQU5BIHJlZ2lzdHJ5LCB0aGUNCiAgICAgICAgICAgIExhbmd1YWdlIFN1YnRhZyBS ZXZpZXdlciwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41LCBTSEFMTA0KICAgICAgICAgICAg cHJlcGFyZSBhIHByb3Bvc2FsIGZvciBlbnRlcmluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBz b29uDQogICAgICAgICAgICBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIGxhbmd1YWdlIHN1YnRh ZyBhcyBhbiBhbHRlcm5hdGUNCiAgICAgICAgICAgIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUuICBU aGUgZm9ybSBvZiB0aGUgcmVnaXN0ZXJlZCBsYW5ndWFnZQ0KICAgICAgICAgICAgc3VidGFnIHdp bGwgYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIExhbmd1YWdlIFN1YnRhZw0KICAgICAgICAg ICAgUmV2aWV3ZXIgYW5kIE1VU1QgY29uZm9ybSB0byBvdGhlciByZXN0cmljdGlvbnMgb24gbGFu Z3VhZ2UNCiAgICAgICAgICAgIHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgICAgICBC LiAgRm9yIGFsbCBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMgZGVyaXZlZCBmcm9tIGFuIGV4dGVy bmFsDQogICAgICAgICAgICBzdGFuZGFyZCAoaS5lLiAgSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08g MzE2Niwgb3IgVU4gTS40OSksDQogICAgICAgICAgICBpZiBhIG5ldyBtZWFuaW5nIGlzIGFzc2ln bmVkIHRvIGFuIGV4aXN0aW5nIGNvZGUgYW5kIHRoZSBuZXcNCiAgICAgICAgICAgIG1lYW5pbmcg YnJvYWRlbnMgdGhlIG1lYW5pbmcgb2YgdGhhdCBjb2RlLCB0aGVuIHRoZSBtZWFuaW5nDQogICAg ICAgICAgICBmb3IgdGhlIGFzc29jaWF0ZWQgc3VidGFnIE1BWSBiZSBjaGFuZ2VkIHRvIG1hdGNo LiAgVGhlDQogICAgICAgICAgICBtZWFuaW5nIG9mIGEgc3VidGFnIE1VU1QgTk9UIGJlIG5hcnJv d2VkLCBob3dldmVyLCBhcyB0aGlzDQogICAgICAgICAgICBjYW4gcmVzdWx0IGluIGFuIHVua25v d24gcHJvcG9ydGlvbiBvZiB0aGUgZXhpc3RpbmcgdXNlcyBvZg0KICAgICAgICAgICAgYSBzdWJ0 YWcgYmVjb21pbmcgaW52YWxpZC4gIE5vdGU6IElTTyA2MzkgTUEvUkEgaGFzIGFkb3B0ZWQNCiAg ICAgICAgICAgIGEgc2ltaWxhciBzdGFiaWxpdHkgcG9saWN5Lg0KDQogICAgICAgIEMuICBGb3Ig SVNPIDE1OTI0IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMN CiAgICAgICAgICAgIG5vdCByZXByZXNlbnRlZCBieSBhIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdp c3RyeSwgdGhlDQogICAgICAgICAgICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsIGFzIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDMuNSwgU0hBTEwNCiAgICAgICAgICAgIHByZXBhcmUgYSBwcm9wb3Nh bCBmb3IgZW50ZXJpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgc29vbg0KICAgICAgICAgICAg YXMgcHJhY3RpY2FsIGEgcmVnaXN0ZXJlZCB2YXJpYW50IHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUN CiAgICAgICAgICAgIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUuICBUaGUgZm9ybSBvZiB0aGUgcmVn aXN0ZXJlZCB2YXJpYW50DQogICAgICAgICAgICBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlzY3Jl dGlvbiBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnDQogICAgICAgICAgICBSZXZpZXdlciBhbmQgTVVT VCBjb25mb3JtIHRvIG90aGVyIHJlc3RyaWN0aW9ucyBvbiB2YXJpYW50DQogICAgICAgICAgICBz dWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgRC4gIEZvciBJU08gMzE2NiBjb2Rl cywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICAgICBh c3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgVU4gTS40OSBjb2RlIGFzIGFub3RoZXIgJ3JlZ2lvbicN CiAgICAgICAgICAgIHN1YnRhZywgdGhlbiB0aGUgZXhpc3RpbmcgcmVnaW9uIHN1YnRhZyByZW1h aW5zIGFzIHRoZQ0KICAgICAgICAgICAgcHJlZmVycmVkIHZhbHVlIGZvciB0aGF0IHJlZ2lvbiBh bmQgbm8gbmV3IGVudHJ5IGlzIGNyZWF0ZWQuDQogICAgICAgICAgICBBIGNvbW1lbnQgTUFZIGJl IGFkZGVkIHRvIHRoZSBleGlzdGluZyByZWdpb24gc3VidGFnDQogICAgICAgICAgICBpbmRpY2F0 aW5nIHRoZSByZWxhdGlvbnNoaXAgdG8gdGhlIG5ldyBJU08gMzE2NiBjb2RlLg0KDQogICAgICAg IEUuICBGb3IgSVNPIDMxNjYgY29kZXMsIGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVh bmluZyBpcw0KICAgICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIGEgVU4gTS40OSBjb2RlIHRoYXQg aXMgbm90IHJlcHJlc2VudGVkIGJ5IGFuDQogICAgICAgICAgICBleGlzdGluZyByZWdpb24gc3Vi dGFnLCB0aGVuIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsDQogICAgICAgICAgICBhcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUsIFNIQUxMIHByZXBhcmUgYSBwcm9wb3NhbCBmb3INCiAg ICAgICAgICAgIGVudGVyaW5nIHRoZSBhcHByb3ByaWF0ZSBVTiBNLjQ5IGNvdW50cnkgY29kZSBh cyBhbiBlbnRyeSBpbg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFy Y2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMjddDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUN Cg0KDQogICAgICAgICAgICB0aGUgSUFOQSByZWdpc3RyeS4NCg0KICAgICAgICBGLiAgRm9yIElT TyAzMTY2IGNvZGVzLCBpZiB0aGVyZSBpcyBubyBhc3NvY2lhdGVkIFVOIG51bWVyaWMNCiAgICAg ICAgICAgIGNvZGUsIHRoZW4gdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBTSEFMTCBwZXRp dGlvbiB0aGUNCiAgICAgICAgICAgIFVOIHRvIGNyZWF0ZSBvbmUuICBJZiB0aGVyZSBpcyBubyBy ZXNwb25zZSBmcm9tIHRoZSBVTg0KICAgICAgICAgICAgd2l0aGluIG5pbmV0eSBkYXlzIG9mIHRo ZSByZXF1ZXN0IGJlaW5nIHNlbnQsIHRoZSBMYW5ndWFnZQ0KICAgICAgICAgICAgU3VidGFnIFJl dmlld2VyIFNIQUxMIHByZXBhcmUgYSBwcm9wb3NhbCBmb3IgZW50ZXJpbmcgaW4gdGhlDQogICAg ICAgICAgICBJQU5BIHJlZ2lzdHJ5IGFzIHNvb24gYXMgcHJhY3RpY2FsIGEgcmVnaXN0ZXJlZCB2 YXJpYW50DQogICAgICAgICAgICBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRlIHZhbHVlIGZvciB0aGUg bmV3IGNvZGUuICBUaGUgZm9ybSBvZg0KICAgICAgICAgICAgdGhlIHJlZ2lzdGVyZWQgdmFyaWFu dCBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlzY3JldGlvbiBvZg0KICAgICAgICAgICAgdGhlIExh bmd1YWdlIFN1YnRhZyBSZXZpZXdlciBhbmQgTVVTVCBjb25mb3JtIHRvIG90aGVyDQogICAgICAg ICAgICByZXN0cmljdGlvbnMgb24gdmFyaWFudCBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuICBU aGlzDQogICAgICAgICAgICBzaXR1YXRpb24gaXMgdmVyeSB1bmxpa2VseSB0byBldmVyIG9jY3Vy Lg0KDQogICAxMS4gIFVOIE0uNDkgaGFzIGNvZGVzIGZvciBib3RoIGNvdW50cmllcyBhbmQgYXJl YXMgKHN1Y2ggYXMgJzI3NicNCiAgICAgICAgZm9yIEdlcm1hbnkpIGFuZCBnZW9ncmFwaGljYWwg cmVnaW9ucyBhbmQgc3ViLXJlZ2lvbnMgKHN1Y2ggYXMNCiAgICAgICAgJzE1MCcgZm9yIEV1cm9w ZSkuICBVTiBNLjQ5IGNvdW50cnkgb3IgYXJlYSBjb2RlcyBmb3Igd2hpY2gNCiAgICAgICAgdGhl cmUgaXMgbm8gY29ycmVzcG9uZGluZyBJU08gMzE2NiBjb2RlIFNIT1VMRCBOT1QgYmUNCiAgICAg ICAgcmVnaXN0ZXJlZCwgZXhjZXB0IGFzIGEgc3Vycm9nYXRlIGZvciBhbiBJU08gMzE2NiBjb2Rl IHRoYXQgaXMNCiAgICAgICAgYmxvY2tlZCBmcm9tIHJlZ2lzdHJhdGlvbiBieSBhbiBleGlzdGlu ZyBzdWJ0YWcuICBJZiBzdWNoIGEgY29kZQ0KICAgICAgICBiZWNvbWVzIG5lY2Vzc2FyeSwgdGhl biB0aGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBmb3IgSVNPIDMxNjYNCiAgICAgICAgU0hPVUxE IGZpcnN0IGJlIHBldGl0aW9uZWQgdG8gYXNzaWduIGEgY29kZSB0byB0aGUgcmVnaW9uLiAgSWYN CiAgICAgICAgdGhlIHBldGl0aW9uIGZvciBhIGNvZGUgYXNzaWdubWVudCBieSBJU08gMzE2NiBp cyByZWZ1c2VkIG9yIG5vdA0KICAgICAgICBhY3RlZCBvbiBpbiBhIHRpbWVseSBtYW5uZXIsIHRo ZSByZWdpc3RyYXRpb24gcHJvY2VzcyBkZXNjcmliZWQNCiAgICAgICAgaW4gU2VjdGlvbiAzLjUg TUFZIHRoZW4gYmUgdXNlZCB0byByZWdpc3RlciB0aGUgY29ycmVzcG9uZGluZyBVTg0KICAgICAg ICBNLjQ5IGNvZGUuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyB3cml0dGVuLCB0aGVy ZSB3ZXJlDQogICAgICAgIG9ubHkgZm91ciBzdWNoIGNvZGVzOiA4MzAgKENoYW5uZWwgSXNsYW5k cyksIDgzMSAoR3Vlcm5zZXkpLCA4MzINCiAgICAgICAgKEplcnNleSksIGFuZCA4MzMgKElzbGUg b2YgTWFuKS4gIFRoaXMgd2F5IFVOIE0uNDkgY29kZXMgcmVtYWluDQogICAgICAgIGF2YWlsYWJs ZSBhcyB0aGUgdmFsdWUgb2YgbGFzdCByZXNvcnQgaW4gY2FzZXMgd2hlcmUgSVNPIDMxNjYNCiAg ICAgICAgcmVhc3NpZ25zIGEgZGVwcmVjYXRlZCB2YWx1ZSBpbiB0aGUgcmVnaXN0cnkuDQoNCiAg IDEyLiAgU3RhYmlsaXR5IHByb3Zpc2lvbnMgYXBwbHkgdG8gZ3JhbmRmYXRoZXJlZCB0YWdzIHdp dGggdGhpcw0KICAgICAgICBleGNlcHRpb246IHNob3VsZCBhbGwgb2YgdGhlIHN1YnRhZ3MgaW4g YSBncmFuZGZhdGhlcmVkIHRhZw0KICAgICAgICBiZWNvbWUgdmFsaWQgc3VidGFncyBpbiB0aGUg SUFOQSByZWdpc3RyeSwgdGhlbiB0aGUgZmllbGQgJ1R5cGUnDQogICAgICAgIGluIHRoYXQgcmVj b3JkIGlzIGNoYW5nZWQgZnJvbSAnZ3JhbmRmYXRoZXJlZCcgdG8gJ3JlZHVuZGFudCcuDQogICAg ICAgIE5vdGUgdGhhdCB0aGlzIHdpbGwgbm90IGFmZmVjdCBsYW5ndWFnZSB0YWdzIHRoYXQgbWF0 Y2ggdGhlDQogICAgICAgIGdyYW5kZmF0aGVyZWQgdGFnLCBzaW5jZSB0aGVzZSB0YWdzIHdpbGwg bm93IG1hdGNoIHZhbGlkDQogICAgICAgIGdlbmVyYXRpdmUgc3VidGFnIHNlcXVlbmNlcy4gIEZv ciBleGFtcGxlLCBpZiB0aGUgc3VidGFnICdnYW4nDQogICAgICAgIGluIHRoZSBsYW5ndWFnZSB0 YWcgInpoLWdhbiIgd2VyZSB0byBiZSByZWdpc3RlcmVkIGFzIGFuDQogICAgICAgIGV4dGVuZGVk IGxhbmd1YWdlIHN1YnRhZywgdGhlbiB0aGUgZ3JhbmRmYXRoZXJlZCB0YWcgInpoLWdhbiINCiAg ICAgICAgd291bGQgYmUgZGVwcmVjYXRlZCAoYnV0IGV4aXN0aW5nIGNvbnRlbnQgb3IgaW1wbGVt ZW50YXRpb25zDQogICAgICAgIHRoYXQgdXNlICJ6aC1nYW4iIHdvdWxkIHJlbWFpbiB2YWxpZCku DQoNCg0KMy41ICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlIGZvciBTdWJ0YWdzDQoNCiAgIFRoZSBw cm9jZWR1cmUgZ2l2ZW4gaGVyZSBNVVNUIGJlIHVzZWQgYnkgYW55b25lIHdobyB3YW50cyB0byB1 c2UgYQ0KICAgc3VidGFnIG5vdCBjdXJyZW50bHkgaW4gdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFn IFJlZ2lzdHJ5Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2gg MjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0K DQogICBPbmx5IHN1YnRhZ3Mgb2YgdHlwZSAnbGFuZ3VhZ2UnIGFuZCAndmFyaWFudCcgd2lsbCBi ZSBjb25zaWRlcmVkIGZvcg0KICAgaW5kZXBlbmRlbnQgcmVnaXN0cmF0aW9uIG9mIG5ldyBzdWJ0 YWdzLiAgSGFuZGxpbmcgb2Ygc3VidGFncyBuZWVkZWQNCiAgIGZvciBzdGFiaWxpdHkgYW5kIHN1 YnRhZ3MgbmVjZXNzYXJ5IHRvIGtlZXAgdGhlIHJlZ2lzdHJ5IHN5bmNocm9uaXplZA0KICAgd2l0 aCBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBhbmQgVU4gTS40OSB3aXRoaW4gdGhlIGxp bWl0cw0KICAgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IGFyZSBkZXNjcmliZWQgaW4gU2VjdGlv biAzLjMuICBTdGFiaWxpdHkNCiAgIHByb3Zpc2lvbnMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDMuNC4NCg0KICAgVGhpcyBwcm9jZWR1cmUgTUFZIGFsc28gYmUgdXNlZCB0byByZWdpc3RlciBv ciBhbHRlciB0aGUgaW5mb3JtYXRpb24NCiAgIGZvciB0aGUgIkRlc2NyaXB0aW9uIiwgIkNvbW1l bnRzIiwgIkRlcHJlY2F0ZWQiLCBvciAiUHJlZml4IiBmaWVsZHMNCiAgIGluIGEgc3VidGFnJ3Mg cmVjb3JkIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNC4gIENoYW5nZXMgdG8gYWxsDQogICBv dGhlciBmaWVsZHMgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXJlIE5PVCBwZXJtaXR0ZWQuDQoNCiAg IFJlZ2lzdGVyaW5nIGEgbmV3IHN1YnRhZyBvciByZXF1ZXN0aW5nIG1vZGlmaWNhdGlvbnMgdG8g YW4gZXhpc3RpbmcNCiAgIHRhZyBvciBzdWJ0YWcgc3RhcnRzIHdpdGggdGhlIHJlcXVlc3RlciBm aWxsaW5nIG91dCB0aGUgcmVnaXN0cmF0aW9uDQogICBmb3JtIHJlcHJvZHVjZWQgYmVsb3cuICBO b3RlIHRoYXQgZWFjaCByZXNwb25zZSBpcyBub3QgbGltaXRlZCBpbg0KICAgc2l6ZSBzbyB0aGF0 IHRoZSByZXF1ZXN0IGNhbiBhZGVxdWF0ZWx5IGRlc2NyaWJlIHRoZSByZWdpc3RyYXRpb24uDQog ICBUaGUgZmllbGRzIGluIHRoZSAiUmVjb3JkIFJlcXVlc3RlZCIgc2VjdGlvbiBTSE9VTEQgZm9s bG93IHRoZQ0KICAgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gMy4xLg0KDQogICBMQU5HVUFHRSBT VUJUQUcgUkVHSVNUUkFUSU9OIEZPUk0NCiAgIDEuIE5hbWUgb2YgcmVxdWVzdGVyOg0KICAgMi4g RS1tYWlsIGFkZHJlc3Mgb2YgcmVxdWVzdGVyOg0KICAgMy4gUmVjb3JkIFJlcXVlc3RlZDoNCg0K ICAgICAgVHlwZToNCiAgICAgIFN1YnRhZzoNCiAgICAgIERlc2NyaXB0aW9uOg0KICAgICAgUHJl Zml4Og0KICAgICAgUHJlZmVycmVkLVZhbHVlOg0KICAgICAgRGVwcmVjYXRlZDoNCiAgICAgIFN1 cHByZXNzLVNjcmlwdDoNCiAgICAgIENvbW1lbnRzOg0KDQogICA0LiBJbnRlbmRlZCBtZWFuaW5n IG9mIHRoZSBzdWJ0YWc6DQogICA1LiBSZWZlcmVuY2UgdG8gcHVibGlzaGVkIGRlc2NyaXB0aW9u DQogICAgICBvZiB0aGUgbGFuZ3VhZ2UgKGJvb2sgb3IgYXJ0aWNsZSk6DQogICA2LiBBbnkgb3Ro ZXIgcmVsZXZhbnQgaW5mb3JtYXRpb246DQoNCiAgICAgICAgICAgICAgRmlndXJlIDU6IFRoZSBM YW5ndWFnZSBTdWJ0YWcgUmVnaXN0cmF0aW9uIEZvcm0NCg0KICAgVGhlIHN1YnRhZyByZWdpc3Ry YXRpb24gZm9ybSBNVVNUIGJlIHNlbnQgdG8NCiAgIDxpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZz4g Zm9yIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBiZWZvcmUgaXQgY2FuDQogICBiZSBzdWJtaXR0 ZWQgdG8gSUFOQS4gIChUaGlzIGlzIGFuIG9wZW4gbGlzdCBhbmQgY2FuIGJlIGpvaW5lZCBieQ0K ICAgc2VuZGluZyBhIHJlcXVlc3QgdG8gPGlldGYtbGFuZ3VhZ2VzLXJlcXVlc3RAaWFuYS5vcmc+ LikNCg0KICAgVmFyaWFudCBzdWJ0YWdzIGFyZSB1c3VhbGx5IHJlZ2lzdGVyZWQgZm9yIHVzZSB3 aXRoIGEgcGFydGljdWxhcg0KICAgcmFuZ2Ugb2YgbGFuZ3VhZ2UgdGFncy4gIEZvciBleGFtcGxl LCB0aGUgc3VidGFnICdyb3phaicgaXMgaW50ZW5kZWQNCiAgIGZvciB1c2Ugd2l0aCBsYW5ndWFn ZSB0YWdzIHRoYXQgc3RhcnQgd2l0aCB0aGUgcHJpbWFyeSBsYW5ndWFnZQ0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAg W1BhZ2UgMjldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBzdWJ0YWcgInNsIiwgc2luY2Ug UmVzaWFuIGlzIGEgZGlhbGVjdCBvZiBTbG92ZW5pYW4uICBUaHVzIHRoZSBzdWJ0YWcNCiAgICdy b3phaicgd291bGQgYmUgYXBwcm9wcmlhdGUgaW4gdGFncyBzdWNoIGFzICJzbC1MYXRuLXJvemFq IiBvciAic2wtDQogICBJVC1yb3phaiIuICBUaGlzIGluZm9ybWF0aW9uIGlzIHN0b3JlZCBpbiB0 aGUgIlByZWZpeCIgZmllbGQgaW4gdGhlDQogICByZWdpc3RyeS4gIFZhcmlhbnQgcmVnaXN0cmF0 aW9uIHJlcXVlc3RzIFNIT1VMRCBpbmNsdWRlIGF0IGxlYXN0IG9uZQ0KICAgIlByZWZpeCIgZmll bGQgaW4gdGhlIHJlZ2lzdHJhdGlvbiBmb3JtLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0 YWdzIGFyZSByZXNlcnZlZCBmb3IgZnV0dXJlIHN0YW5kYXJkaXphdGlvbi4NCiAgIFRoZXNlIHN1 YnRhZ3Mgd2lsbCBiZSBSRVFVSVJFRCB0byBpbmNsdWRlIGV4YWN0bHkgb25lICJQcmVmaXgiIGZp ZWxkDQogICBvbmNlIHRoZXkgYXJlIGFsbG93ZWQgZm9yIHJlZ2lzdHJhdGlvbi4NCg0KICAgVGhl ICdQcmVmaXgnIGZpZWxkIGZvciBhIGdpdmVuIHJlZ2lzdGVyZWQgc3VidGFnIGV4aXN0cyBpbiB0 aGUgSUFOQQ0KICAgcmVnaXN0cnkgYXMgYSBndWlkZSB0byB1c2FnZS4gIEFkZGl0aW9uYWwgcHJl Zml4ZXMgTUFZIGJlIGFkZGVkIGJ5DQogICBmaWxpbmcgYW4gYWRkaXRpb25hbCByZWdpc3RyYXRp b24gZm9ybS4gIEluIHRoYXQgZm9ybSwgdGhlICJBbnkgb3RoZXINCiAgIHJlbGV2YW50IGluZm9y bWF0aW9uOiIgZmllbGQgTVVTVCBpbmRpY2F0ZSB0aGF0IGl0IGlzIHRoZSBhZGRpdGlvbiBvZg0K ICAgYSBwcmVmaXguDQoNCiAgIFJlcXVlc3RzIHRvIGFkZCBhIHByZWZpeCB0byBhIHZhcmlhbnQg c3VidGFnIHRoYXQgaW1wbHkgYSBkaWZmZXJlbnQNCiAgIHNlbWFudGljIG1lYW5pbmcgd2lsbCBw cm9iYWJseSBiZSByZWplY3RlZC4gIEZvciBleGFtcGxlLCBhIHJlcXVlc3QNCiAgIHRvIGFkZCB0 aGUgcHJlZml4ICJkZSIgdG8gdGhlIHN1YnRhZyAnbmVkaXMnIHNvIHRoYXQgdGhlIHRhZyAiZGUt DQogICBuZWRpcyIgcmVwcmVzZW50ZWQgc29tZSBHZXJtYW4gZGlhbGVjdCB3b3VsZCBiZSByZWpl Y3RlZC4gIFRoZQ0KICAgJ25lZGlzJyBzdWJ0YWcgcmVwcmVzZW50cyBhIHBhcnRpY3VsYXIgU2xv dmVuaWFuIGRpYWxlY3QgYW5kIHRoZQ0KICAgYWRkaXRpb25hbCByZWdpc3RyYXRpb24gd291bGQg Y2hhbmdlIHRoZSBzZW1hbnRpYyBtZWFuaW5nIGFzc2lnbmVkIHRvDQogICB0aGUgc3VidGFnLiAg QSBzZXBhcmF0ZSBzdWJ0YWcgU0hPVUxEIGJlIHByb3Bvc2VkIGluc3RlYWQuDQoNCiAgIFRoZSAn RGVzY3JpcHRpb24nIGZpZWxkIE1VU1QgY29udGFpbiBhIGRlc2NyaXB0aW9uIG9mIHRoZSB0YWcg YmVpbmcNCiAgIHJlZ2lzdGVyZWQgd3JpdHRlbiBvciB0cmFuc2NyaWJlZCBpbnRvIHRoZSBMYXRp biBzY3JpcHQ7IGl0IE1BWSBhbHNvDQogICBpbmNsdWRlIGEgZGVzY3JpcHRpb24gaW4gYSBub24t TGF0aW4gc2NyaXB0LiAgTm9uLUFTQ0lJIGNoYXJhY3RlcnMNCiAgIE1VU1QgYmUgZXNjYXBlZCB1 c2luZyB0aGUgc3ludGF4IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMS4gIFRoZQ0KICAgJ0Rlc2Ny aXB0aW9uJyBmaWVsZCBpcyB1c2VkIGZvciBpZGVudGlmaWNhdGlvbiBwdXJwb3NlcyBhbmQgZG9l c24ndA0KICAgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSBhY3R1YWwgbmF0aXZlIG5hbWUgb2Yg dGhlIGxhbmd1YWdlIG9yDQogICB2YXJpYXRpb24gb3IgdG8gYmUgaW4gYW55IHBhcnRpY3VsYXIg bGFuZ3VhZ2UuDQoNCiAgIFdoaWxlIHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGl0c2VsZiBpcyBu b3QgZ3VhcmFudGVlZCB0byBiZSBzdGFibGUNCiAgIGFuZCBlcnJhdGEgY29ycmVjdGlvbnMgTUFZ IGJlIHVuZGVydGFrZW4gZnJvbSB0aW1lIHRvIHRpbWUsIGF0dGVtcHRzDQogICB0byBwcm92aWRl IHRyYW5zbGF0aW9ucyBvciB0cmFuc2NyaXB0aW9ucyBvZiBlbnRyaWVzIGluIHRoZSByZWdpc3Ry eQ0KICAgaXRzZWxmIHdpbGwgcHJvYmFibHkgYmUgZnJvd25lZCB1cG9uIGJ5IHRoZSBjb21tdW5p dHkgb3IgcmVqZWN0ZWQNCiAgIG91dHJpZ2h0LCBhcyBjaGFuZ2VzIG9mIHRoaXMgbmF0dXJlIGhh dmUgYW4gaW1wYWN0IG9uIHRoZSBwcm92aXNpb25zDQogICBpbiBTZWN0aW9uIDMuNC4NCg0KICAg V2hlbiB0aGUgdHdvIHdlZWsgcGVyaW9kIGhhcyBwYXNzZWQgdGhlIExhbmd1YWdlIFN1YnRhZyBS ZXZpZXdlcg0KICAgZWl0aGVyIGZvcndhcmRzIHRoZSByZWNvcmQgdG8gYmUgaW5zZXJ0ZWQgb3Ig bW9kaWZpZWQgdG8NCiAgIGlhbmFAaWFuYS5vcmcgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmUg ZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLCBvcg0KICAgcmVqZWN0cyB0aGUgcmVxdWVzdCBiZWNh dXNlIG9mIHNpZ25pZmljYW50IG9iamVjdGlvbnMgcmFpc2VkIG9uIHRoZQ0KICAgbGlzdCBvciBk dWUgdG8gcHJvYmxlbXMgd2l0aCBjb25zdHJhaW50cyBpbiB0aGlzIGRvY3VtZW50ICh3aGljaCBN VVNUDQogICBiZSBleHBsaWNpdGx5IGNpdGVkKS4gIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3 ZXIgTUFZIGFsc28gZXh0ZW5kDQogICB0aGUgcmV2aWV3IHBlcmlvZCBpbiB0d28gd2VlayBpbmNy ZW1lbnRzIHRvIHBlcm1pdCBmdXJ0aGVyDQogICBkaXNjdXNzaW9uLiAgVGhlIExhbmd1YWdlIFN1 YnRhZyBSZXZpZXdlciBNVVNUIGluZGljYXRlIG9uIHRoZSBsaXN0DQogICB3aGV0aGVyIHRoZSBy ZWdpc3RyYXRpb24gaGFzIGJlZW4gYWNjZXB0ZWQsIHJlamVjdGVkLCBvciBleHRlbmRlZA0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAg ICAgICAgICAgW1BhZ2UgMzBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBmb2xsb3dpbmcg ZWFjaCB0d28gd2VlayBwZXJpb2QuDQoNCiAgIE5vdGUgdGhhdCB0aGUgTGFuZ3VhZ2UgU3VidGFn IFJldmlld2VyIE1BWSByYWlzZSBvYmplY3Rpb25zIG9uIHRoZQ0KICAgbGlzdCBpZiBoZSBvciBz aGUgc28gZGVzaXJlcy4gIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB0aGUNCiAgIG9iamVj dGlvbiBNVVNUIGJlIG1hZGUgcHVibGljbHkuDQoNCiAgIFRoZSBhcHBsaWNhbnQgaXMgZnJlZSB0 byBtb2RpZnkgYSByZWplY3RlZCBhcHBsaWNhdGlvbiB3aXRoDQogICBhZGRpdGlvbmFsIGluZm9y bWF0aW9uIGFuZCBzdWJtaXQgaXQgYWdhaW47IHRoaXMgcmVzdGFydHMgdGhlIHR3bw0KICAgd2Vl ayBjb21tZW50IHBlcmlvZC4NCg0KICAgRGVjaXNpb25zIG1hZGUgYnkgdGhlIExhbmd1YWdlIFN1 YnRhZyBSZXZpZXdlciBNQVkgYmUgYXBwZWFsZWQgdG8gdGhlDQogICBJRVNHIFtSRkMyMDI4XSB1 bmRlciB0aGUgc2FtZSBydWxlcyBhcyBvdGhlciBJRVRGIGRlY2lzaW9ucw0KICAgW1JGQzIwMjZd Lg0KDQogICBBbGwgYXBwcm92ZWQgcmVnaXN0cmF0aW9uIGZvcm1zIGFyZSBhdmFpbGFibGUgb25s aW5lIGluIHRoZSBkaXJlY3RvcnkNCiAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvbnVtYmVycy5odG1s IHVuZGVyICJsYW5ndWFnZXMiLg0KDQogICBVcGRhdGVzIG9yIGNoYW5nZXMgdG8gZXhpc3Rpbmcg cmVjb3JkcyBmb2xsb3cgdGhlIHNhbWUgcHJvY2VkdXJlIGFzDQogICBuZXcgcmVnaXN0cmF0aW9u cy4gIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgZGVjaWRlcyB3aGV0aGVyDQogICB0aGVy ZSBpcyBjb25zZW5zdXMgdG8gdXBkYXRlIHRoZSByZWdpc3RyYXRpb24gZm9sbG93aW5nIHRoZSB0 d28gd2Vlaw0KICAgcmV2aWV3IHBlcmlvZDsgbm9ybWFsbHkgb2JqZWN0aW9ucyBieSB0aGUgb3Jp Z2luYWwgcmVnaXN0cmFudCB3aWxsDQogICBjYXJyeSBleHRyYSB3ZWlnaHQgaW4gZm9ybWluZyBz dWNoIGEgY29uc2Vuc3VzLg0KDQogICBSZWdpc3RyYXRpb25zIGFyZSBwZXJtYW5lbnQgYW5kIHN0 YWJsZS4gIE9uY2UgcmVnaXN0ZXJlZCwgc3VidGFncw0KICAgd2lsbCBub3QgYmUgcmVtb3ZlZCBm cm9tIHRoZSByZWdpc3RyeSBhbmQgd2lsbCByZW1haW4gYSB2YWxpZCB3YXkgaW4NCiAgIHdoaWNo IHRvIHNwZWNpZnkgYSBzcGVjaWZpYyBsYW5ndWFnZSBvciB2YXJpYW50Lg0KDQogICBOb3RlOiBU aGUgcHVycG9zZSBvZiB0aGUgIkRlc2NyaXB0aW9uIiBpbiB0aGUgcmVnaXN0cmF0aW9uIGZvcm0g aXMNCiAgIGludGVuZGVkIGFzIGFuIGFpZCB0byBwZW9wbGUgdHJ5aW5nIHRvIHZlcmlmeSB3aGV0 aGVyIGEgbGFuZ3VhZ2UgaXMNCiAgIHJlZ2lzdGVyZWQgb3Igd2hhdCBsYW5ndWFnZSBvciBsYW5n dWFnZSB2YXJpYXRpb24gYSBwYXJ0aWN1bGFyIHN1YnRhZw0KICAgcmVmZXJzIHRvLiAgSW4gbW9z dCBjYXNlcywgcmVmZXJlbmNlIHRvIGFuIGF1dGhvcml0YXRpdmUgZ3JhbW1hciBvcg0KICAgZGlj dGlvbmFyeSBvZiB0aGF0IGxhbmd1YWdlIHdpbGwgYmUgdXNlZnVsOyBpbiBjYXNlcyB3aGVyZSBu byBzdWNoDQogICB3b3JrIGV4aXN0cywgb3RoZXIgd2VsbCBrbm93biB3b3JrcyBkZXNjcmliaW5n IHRoYXQgbGFuZ3VhZ2Ugb3IgaW4NCiAgIHRoYXQgbGFuZ3VhZ2UgTUFZIGJlIGFwcHJvcHJpYXRl LiAgVGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlcg0KICAgZGVjaWRlcyB3aGF0IGNvbnN0aXR1 dGVzICJnb29kIGVub3VnaCIgcmVmZXJlbmNlIG1hdGVyaWFsLiAgVGhpcw0KICAgcmVxdWlyZW1l bnQgaXMgbm90IGludGVuZGVkIHRvIGV4Y2x1ZGUgcGFydGljdWxhciBsYW5ndWFnZXMgb3INCiAg IGRpYWxlY3RzIGR1ZSB0byB0aGUgc2l6ZSBvZiB0aGUgc3BlYWtlciBwb3B1bGF0aW9uIG9yIGxh Y2sgb2YgYQ0KICAgc3RhbmRhcmRpemVkIG9ydGhvZ3JhcGh5LiAgTWlub3JpdHkgbGFuZ3VhZ2Vz IHdpbGwgYmUgY29uc2lkZXJlZA0KICAgZXF1YWxseSBvbiB0aGVpciBvd24gbWVyaXRzLg0KDQoz LjYgIFBvc3NpYmlsaXRpZXMgZm9yIFJlZ2lzdHJhdGlvbg0KDQogICBQb3NzaWJpbGl0aWVzIGZv ciByZWdpc3RyYXRpb24gb2Ygc3VidGFncyBvciBpbmZvcm1hdGlvbiBhYm91dA0KICAgc3VidGFn cyBpbmNsdWRlOg0KDQogICBvICBQcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MgZm9yIGxhbmd1YWdl cyBub3QgbGlzdGVkIGluIElTTyA2MzkgdGhhdA0KICAgICAgYXJlIG5vdCB2YXJpYW50cyBvZiBh bnkgbGlzdGVkIG9yIHJlZ2lzdGVyZWQgbGFuZ3VhZ2UgTUFZIGJlDQogICAgICByZWdpc3RlcmVk LiAgQXQgdGhlIHRpbWUgdGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCB0aGVyZSB3ZXJlIG5vDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAg ICAgICAgICAgICBbUGFnZSAzMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgICAgIGV4YW1w bGVzIG9mIHRoaXMgZm9ybSBvZiBzdWJ0YWcuICBCZWZvcmUgYXR0ZW1wdGluZyB0byByZWdpc3Rl ciBhDQogICAgICBsYW5ndWFnZSBzdWJ0YWcsIHRoZXJlIE1VU1QgYmUgYW4gYXR0ZW1wdCB0byBy ZWdpc3RlciB0aGUgbGFuZ3VhZ2UNCiAgICAgIHdpdGggSVNPIDYzOS4gIFN1YnRhZ3MgTVVTVCBO T1QgYmUgcmVnaXN0ZXJlZCBmb3IgY29kZXMgdGhhdCBleGlzdA0KICAgICAgaW4gSVNPIDYzOS0x IG9yIElTTyA2MzktMiwgd2hpY2ggYXJlIHVuZGVyIGNvbnNpZGVyYXRpb24gYnkgdGhlDQogICAg ICBJU08gNjM5IG1haW50ZW5hbmNlIG9yIHJlZ2lzdHJhdGlvbiBhdXRob3JpdGllcywgb3Igd2hp Y2ggaGF2ZQ0KICAgICAgbmV2ZXIgYmVlbiBhdHRlbXB0ZWQgZm9yIHJlZ2lzdHJhdGlvbiB3aXRo IHRob3NlIGF1dGhvcml0aWVzLiAgSWYNCiAgICAgIElTTyA2MzkgaGFzIHByZXZpb3VzbHkgcmVq ZWN0ZWQgYSBsYW5ndWFnZSBmb3IgcmVnaXN0cmF0aW9uLCBpdCBpcw0KICAgICAgcmVhc29uYWJs ZSB0byBhc3N1bWUgdGhhdCB0aGVyZSBtdXN0IGJlIGFkZGl0aW9uYWwgdmVyeSBjb21wZWxsaW5n DQogICAgICBldmlkZW5jZSBvZiBuZWVkIGJlZm9yZSBpdCB3aWxsIGJlIHJlZ2lzdGVyZWQgaW4g dGhlIElBTkEgcmVnaXN0cnkNCiAgICAgICh0byB0aGUgZXh0ZW50IHRoYXQgaXQgaXMgdmVyeSB1 bmxpa2VseSB0aGF0IGFueSBzdWJ0YWdzIHdpbGwgYmUNCiAgICAgIHJlZ2lzdGVyZWQgb2YgdGhp cyB0eXBlKS4NCg0KICAgbyAgRGlhbGVjdCBvciBvdGhlciBkaXZpc2lvbnMgb3IgdmFyaWF0aW9u cyB3aXRoaW4gYSBsYW5ndWFnZSwgaXRzDQogICAgICBvcnRob2dyYXBoeSwgd3JpdGluZyBzeXN0 ZW0sIHJlZ2lvbmFsIG9yIGhpc3RvcmljYWwgdXNhZ2UsDQogICAgICB0cmFuc2xpdGVyYXRpb24g b3Igb3RoZXIgdHJhbnNmb3JtYXRpb24sIG9yIGRpc3Rpbmd1aXNoaW5nDQogICAgICB2YXJpYXRp b24gTUFZIGJlIHJlZ2lzdGVyZWQgYXMgdmFyaWFudCBzdWJ0YWdzLiAgQW4gZXhhbXBsZSBpcyB0 aGUNCiAgICAgICdyb3phaicgc3VidGFnICh0aGUgUmVzaWFuIGRpYWxlY3Qgb2YgU2xvdmVuaWFu KS4NCg0KICAgbyAgVGhlIGFkZGl0aW9uIG9yIG1haW50ZW5hbmNlIG9mIGZpZWxkcyAoZ2VuZXJh bGx5IG9mIGFuDQogICAgICBpbmZvcm1hdGlvbmFsIG5hdHVyZSkgaW4gVGFnIG9yIFN1YnRhZyBy ZWNvcmRzIGFzIGRlc2NyaWJlZCBpbg0KICAgICAgU2VjdGlvbiAzLjEgYW5kIHN1YmplY3QgdG8g dGhlIHN0YWJpbGl0eSBwcm92aXNpb25zIGluDQogICAgICBTZWN0aW9uIDMuNC4gIFRoaXMgaW5j bHVkZXMgZGVzY3JpcHRpb25zOyBjb21tZW50czsgZGVwcmVjYXRpb24NCiAgICAgIGFuZCBwcmVm ZXJyZWQgdmFsdWVzIGZvciBvYnNvbGV0ZSBvciB3aXRoZHJhd24gY29kZXM7IG9yIHRoZQ0KICAg ICAgYWRkaXRpb24gb2Ygc2NyaXB0IG9yIGV4dGxhbmcgaW5mb3JtYXRpb24gdG8gcHJpbWFyeSBs YW5ndWFnZQ0KICAgICAgc3VidGFncy4NCg0KICAgbyAgVGhlIGFkZGl0aW9uIG9mIHJlY29yZHMg YW5kIHJlbGF0ZWQgZmllbGQgdmFsdWUgY2hhbmdlcyBuZWNlc3NhcnkNCiAgICAgIHRvIHJlZmxl Y3QgYXNzaWdubWVudHMgbWFkZSBieSBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBhbmQN CiAgICAgIFVOICBNLjQ5IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNC4NCg0KICAgU3VidGFn cyBwcm9wb3NlZCBmb3IgcmVnaXN0cmF0aW9uIHRoYXQgd291bGQgY2F1c2UgYWxsIG9yIHBhcnQg b2YgYQ0KICAgZ3JhbmRmYXRoZXJlZCB0YWcgdG8gYmVjb21lIHJlZHVuZGFudCBidXQgd2hvc2Ug bWVhbmluZyBjb25mbGljdHMNCiAgIHdpdGggb3IgYWx0ZXJzIHRoZSBtZWFuaW5nIG9mIHRoZSBn cmFuZGZhdGhlcmVkIHRhZyBNVVNUIGJlIHJlamVjdGVkLg0KDQogICBUaGlzIGRvY3VtZW50IGxl YXZlcyB0aGUgZGVjaXNpb24gb24gd2hhdCBzdWJ0YWdzIG9yIGNoYW5nZXMgdG8NCiAgIHN1YnRh Z3MgYXJlIGFwcHJvcHJpYXRlIChvciBub3QpIHRvIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0K ICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41Lg0KDQogICBOb3RlOiBmb3VyIGNoYXJhY3RlciBw cmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MgYXJlIHJlc2VydmVkIHRvIGFsbG93DQogICBmb3IgdGhl IHBvc3NpYmlsaXR5IG9mIGFscGhhNCBjb2RlcyBpbiBzb21lIGZ1dHVyZSBhZGRpdGlvbiB0byB0 aGUNCiAgIElTTyA2MzkgZmFtaWx5IG9mIHN0YW5kYXJkcy4NCg0KICAgSVNPIDYzOSBkZWZpbmVz IGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBhZGRpdGlvbnMgdG8gYW5kIGNoYW5nZXMgaW4NCiAg IHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBpbiBJU08gNjM5LiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAg IEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24gQ2VudHJlIGZvciBUZXJtaW5vbG9neSAoSW5mb3Rl cm0pDQogICBBaWNoaG9semdhc3NlIDYvMTIsIEFULTExMjANCiAgIFdpZW4sIEF1c3RyaWENCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAg ICAgICAgICAgIFtQYWdlIDMyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgIFBob25lOiAr NDMgMSAyNiA3NSAzNSBFeHQuIDMxMiBGYXg6ICs0MyAxIDIxNiAzMiA3Mg0KDQogICBJU08gNjM5 LTIgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFnZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFu Z2VzDQogICBpbiB0aGUgbGlzdCBvZiBsYW5ndWFnZXMgaW4gSVNPIDYzOS0yLiAgVGhpcyBhZ2Vu Y3kgaXM6DQoNCiAgIExpYnJhcnkgb2YgQ29uZ3Jlc3MNCiAgIE5ldHdvcmsgRGV2ZWxvcG1lbnQg YW5kIE1BUkMgU3RhbmRhcmRzIE9mZmljZQ0KICAgV2FzaGluZ3RvbiwgRC5DLiAyMDU0MCBVU0EN CiAgIFBob25lOiArMSAyMDIgNzA3IDYyMzcgIEZheDogKzEgMjAyIDcwNyAwMTE1DQogICBVUkw6 IGh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5DQoNCiAgIFRoZSBtYWludGVuYW5j ZSBhZ2VuY3kgZm9yIElTTyAzMTY2IChjb3VudHJ5IGNvZGVzKSBpczoNCg0KICAgSVNPIDMxNjYg TWFpbnRlbmFuY2UgQWdlbmN5DQogICBjL28gSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9y IFN0YW5kYXJkaXphdGlvbg0KICAgQ2FzZSBwb3N0YWxlIDU2DQogICBDSC0xMjExIEdlbmV2YSAy MCBTd2l0emVybGFuZA0KICAgUGhvbmU6ICs0MSAyMiA3NDkgNzIgMzMgIEZheDogKzQxIDIyIDc0 OSA3MyA0OQ0KICAgVVJMOiBodHRwOi8vd3d3Lmlzby5vcmcvaXNvL2VuL3Byb2RzLXNlcnZpY2Vz L2lzbzMxNjZtYS9pbmRleC5odG1sDQoNCiAgIFRoZSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IGZv ciBJU08gMTU5MjQgKHNjcmlwdCBjb2RlcykgaXM6DQoNCiAgIFVuaWNvZGUgQ29uc29ydGl1bSBC b3ggMzkxNDc2DQogICBNb3VudGFpbiBWaWV3LCBDQSA5NDAzOS0xNDc2LCBVU0ENCiAgIFVSTDog aHR0cDovL3d3dy51bmljb2RlLm9yZy9pc28xNTkyNA0KDQogICBUaGUgU3RhdGlzdGljcyBEaXZp c2lvbiBvZiB0aGUgVW5pdGVkIE5hdGlvbnMgU2VjcmV0YXJpYXQgbWFpbnRhaW5zDQogICB0aGUg U3RhbmRhcmQgQ291bnRyeSBvciBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UgYW5kIGNh biBiZQ0KICAgcmVhY2hlZCBhdDoNCg0KICAgU3RhdGlzdGljYWwgU2VydmljZXMgQnJhbmNoDQog ICBTdGF0aXN0aWNzIERpdmlzaW9uDQogICBVbml0ZWQgTmF0aW9ucywgUm9vbSBEQzItMTYyMA0K ICAgTmV3IFlvcmssIE5ZIDEwMDE3LCBVU0ENCg0KICAgRmF4OiArMS0yMTItOTYzLTA2MjMNCiAg IEUtbWFpbDogc3RhdGlzdGljc0B1bi5vcmcNCiAgIFVSTDogaHR0cDovL3Vuc3RhdHMudW4ub3Jn L3Vuc2QvbWV0aG9kcy9tNDkvbTQ5YWxwaGEuaHRtDQoNCjMuNyAgRXh0ZW5zaW9ucyBhbmQgRXh0 ZW5zaW9ucyBSZWdpc3RyeQ0KDQogICBFeHRlbnNpb24gc3VidGFncyBhcmUgdGhvc2UgaW50cm9k dWNlZCBieSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRhZ3MNCiAgICgic2luZ2xldG9ucyIpIG90aGVy IHRoYW4gJ3gnLiAgVGhleSBhcmUgcmVzZXJ2ZWQgZm9yIHRoZSBnZW5lcmF0aW9uDQogICBvZiBp ZGVudGlmaWVycyB3aGljaCBjb250YWluIGEgbGFuZ3VhZ2UgY29tcG9uZW50LCBhbmQgYXJlIGNv bXBhdGlibGUNCiAgIHdpdGggYXBwbGljYXRpb25zIHRoYXQgdW5kZXJzdGFuZCBsYW5ndWFnZSB0 YWdzLg0KDQogICBUaGUgc3RydWN0dXJlIGFuZCBmb3JtIG9mIGV4dGVuc2lvbnMgYXJlIGRlZmlu ZWQgYnkgdGhpcyBkb2N1bWVudCBzbw0KICAgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY2FuIGJlIGNy ZWF0ZWQgdGhhdCBhcmUgZm9yd2FyZCBjb21wYXRpYmxlIHdpdGgNCg0KDQoNClBoaWxsaXBzICYg RGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdl IDMzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgYXBwbGljYXRpb25zIHRoYXQgbWlnaHQg YmUgY3JlYXRlZCB1c2luZyBzaW5nbGV0b25zIGluIHRoZSBmdXR1cmUuDQogICBJbiBhZGRpdGlv biwgZGVmaW5pbmcgYSBtZWNoYW5pc20gZm9yIG1haW50YWluaW5nIHNpbmdsZXRvbnMgd2lsbA0K ICAgbGVuZCBzdGFiaWxpdHkgdG8gdGhpcyBkb2N1bWVudCBieSByZWR1Y2luZyB0aGUgbGlrZWx5 IG5lZWQgZm9yDQogICBmdXR1cmUgcmV2aXNpb25zIG9yIHVwZGF0ZXMuDQoNCiAgIFNpbmdsZSBj aGFyYWN0ZXIgc3VidGFncyBhcmUgYXNzaWduZWQgYnkgSUFOQSB1c2luZyB0aGUgIklFVEYNCiAg IENvbnNlbnN1cyIgcG9saWN5IGRlZmluZWQgYnkgW1JGQzI0MzRdLiAgVGhpcyBwb2xpY3kgcmVx dWlyZXMgdGhlDQogICBkZXZlbG9wbWVudCBvZiBhbiBSRkMsIHdoaWNoIFNIQUxMIGRlZmluZSB0 aGUgbmFtZSwgcHVycG9zZSwNCiAgIHByb2Nlc3NlcywgYW5kIHByb2NlZHVyZXMgZm9yIG1haW50 YWluaW5nIHRoZSBzdWJ0YWdzLiAgVGhlDQogICBtYWludGFpbmluZyBvciByZWdpc3RlcmluZyBh dXRob3JpdHksIGluY2x1ZGluZyBuYW1lLCBjb250YWN0IGVtYWlsLA0KICAgZGlzY3Vzc2lvbiBs aXN0IGVtYWlsLCBhbmQgVVJMIGxvY2F0aW9uIG9mIHRoZSByZWdpc3RyeSBNVVNUIGJlDQogICBp bmRpY2F0ZWQgY2xlYXJseSBpbiB0aGUgUkZDLiAgVGhlIFJGQyBNVVNUIHNwZWNpZnkgb3IgaW5j bHVkZSBlYWNoDQogICBvZiB0aGUgZm9sbG93aW5nOg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlv biBNVVNUIHJlZmVyZW5jZSB0aGUgc3BlY2lmaWMgdmVyc2lvbiBvciByZXZpc2lvbg0KICAgICAg b2YgdGhpcyBkb2N1bWVudCB0aGF0IGdvdmVybnMgaXRzIGNyZWF0aW9uIGFuZCBNVVNUIHJlZmVy ZW5jZSB0aGlzDQogICAgICBzZWN0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIG8gIFRoZSBz cGVjaWZpY2F0aW9uIGFuZCBhbGwgc3VidGFncyBkZWZpbmVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9u DQogICAgICBNVVNUIGZvbGxvdyB0aGUgQUJORiBhbmQgb3RoZXIgcnVsZXMgZm9yIHRoZSBmb3Jt YXRpb24gb2YgdGFncyBhbmQNCiAgICAgIHN1YnRhZ3MgYXMgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50LiAgSW4gcGFydGljdWxhciBpdCBNVVNUDQogICAgICBzcGVjaWZ5IHRoYXQgY2FzZSBpcyBu b3Qgc2lnbmlmaWNhbnQgYW5kIHRoYXQgc3VidGFncyBNVVNUIE5PVA0KICAgICAgZXhjZWVkIGVp Z2h0IGNoYXJhY3RlcnMgaW4gbGVuZ3RoLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNU IHNwZWNpZnkgYSBjYW5vbmljYWwgcmVwcmVzZW50YXRpb24uDQoNCiAgIG8gIFRoZSBzcGVjaWZp Y2F0aW9uIG9mIHZhbGlkIHN1YnRhZ3MgTVVTVCBiZSBhdmFpbGFibGUgb3ZlciB0aGUNCiAgICAg IEludGVybmV0IGFuZCBhdCBubyBjb3N0Lg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNU IGJlIGluIHRoZSBwdWJsaWMgZG9tYWluIG9yIGF2YWlsYWJsZSB2aWEgYQ0KICAgICAgcm95YWx0 eS1mcmVlIGxpY2Vuc2UgYWNjZXB0YWJsZSB0byB0aGUgSUVURiBhbmQgc3BlY2lmaWVkIGluIHRo ZQ0KICAgICAgUkZDLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIHZlcnNpb25l ZCBhbmQgZWFjaCB2ZXJzaW9uIG9mIHRoZQ0KICAgICAgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIG51 bWJlcmVkLCBkYXRlZCwgYW5kIHN0YWJsZS4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVT VCBiZSBzdGFibGUuICBUaGF0IGlzLCBleHRlbnNpb24gc3VidGFncywNCiAgICAgIG9uY2UgZGVm aW5lZCBieSBhIHNwZWNpZmljYXRpb24sIE1VU1QgTk9UIGJlIHJldHJhY3RlZCBvciBjaGFuZ2UN CiAgICAgIGluIG1lYW5pbmcgaW4gYW55IHN1YnN0YW50aWFsIHdheS4NCg0KICAgbyAgVGhlIHNw ZWNpZmljYXRpb24gTVVTVCBpbmNsdWRlIGluIGEgc2VwYXJhdGUgc2VjdGlvbiB0aGUNCiAgICAg IHJlZ2lzdHJhdGlvbiBmb3JtIHJlcHJvZHVjZWQgaW4gdGhpcyBzZWN0aW9uIChiZWxvdykgdG8g YmUgdXNlZCBpbg0KICAgICAgcmVnaXN0ZXJpbmcgdGhlIGV4dGVuc2lvbiB1cG9uIHB1YmxpY2F0 aW9uIGFzIGFuIFJGQy4NCg0KICAgbyAgSUFOQSBNVVNUIGJlIGluZm9ybWVkIG9mIGNoYW5nZXMg dG8gdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gYW5kDQogICAgICBVUkwgZm9yIHRoZSBzcGVjaWZp Y2F0aW9uLg0KDQogICBJQU5BIHdpbGwgbWFpbnRhaW4gYSByZWdpc3RyeSBvZiBhbGxvY2F0ZWQg c2luZ2xlIGNoYXJhY3Rlcg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMg TWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMzRdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIw MDUNCg0KDQogICAoc2luZ2xldG9uKSBzdWJ0YWdzLiAgVGhpcyByZWdpc3RyeSBNVVNUIHVzZSB0 aGUgcmVjb3JkLWphciBmb3JtYXQNCiAgIGRlc2NyaWJlZCBieSB0aGUgQUJORiBpbiBTZWN0aW9u IDMuMS4gIFVwb24gcHVibGljYXRpb24gb2YgYW4NCiAgIGV4dGVuc2lvbiBhcyBhbiBSRkMsIHRo ZSBtYWludGFpbmluZyBhdXRob3JpdHkgZGVmaW5lZCBpbiB0aGUgUkZDDQogICBNVVNUIGZvcndh cmQgdGhpcyByZWdpc3RyYXRpb24gZm9ybSB0byBpZXNnQGlldGYub3JnLCB3aG8gTVVTVA0KICAg Zm9yd2FyZCB0aGUgcmVxdWVzdCB0byBpYW5hQGlhbmEub3JnLiAgVGhlIG1haW50YWluaW5nIGF1 dGhvcml0eSBvZg0KICAgdGhlIGV4dGVuc2lvbiBNVVNUIG1haW50YWluIHRoZSBhY2N1cmFjeSBv ZiB0aGUgcmVjb3JkIGJ5IHNlbmRpbmcgYW4NCiAgIHVwZGF0ZWQgZnVsbCBjb3B5IG9mIHRoZSBy ZWNvcmQgdG8gaWFuYUBpYW5hLm9yZyB3aXRoIHRoZSBzdWJqZWN0DQogICBsaW5lICJMQU5HVUFH RSBUQUcgRVhURU5TSU9OIFVQREFURSIgd2hlbmV2ZXIgY29udGVudCBjaGFuZ2VzLiAgT25seQ0K ICAgdGhlICdDb21tZW50cycsICdDb250YWN0X0VtYWlsJywgJ01haWxpbmdfTGlzdCcsIGFuZCAn VVJMJyBmaWVsZHMgTUFZDQogICBiZSBtb2RpZmllZCBpbiB0aGVzZSB1cGRhdGVzLg0KDQogICBG YWlsdXJlIHRvIG1haW50YWluIHRoaXMgcmVjb3JkLCB0aGUgY29ycmVzcG9uZGluZyByZWdpc3Ry eSwgb3IgbWVldA0KICAgb3RoZXIgY29uZGl0aW9ucyBpbXBvc2VkIGJ5IHRoaXMgc2VjdGlvbiBv ZiB0aGlzIGRvY3VtZW50IE1BWSBiZQ0KICAgYXBwZWFsZWQgdG8gdGhlIElFU0cgW1JGQzIwMjhd IHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFzIG90aGVyIElFVEYNCiAgIGRlY2lzaW9ucyAoc2VlIFtS RkMyMDI2XSkgYW5kIE1BWSByZXN1bHQgaW4gdGhlIGF1dGhvcml0eSB0byBtYWludGFpbg0KICAg dGhlIGV4dGVuc2lvbiBiZWluZyB3aXRoZHJhd24gb3IgcmVhc3NpZ25lZCBieSB0aGUgSUVTRy4N CiAgICUlDQogICBJZGVudGlmaWVyOg0KICAgRGVzY3JpcHRpb246DQogICBDb21tZW50czoNCiAg IEFkZGVkOg0KICAgUkZDOg0KICAgQXV0aG9yaXR5Og0KICAgQ29udGFjdF9FbWFpbDoNCiAgIE1h aWxpbmdfTGlzdDoNCiAgIFVSTDoNCiAgICUlDQoNCiAgICBGaWd1cmUgNjogRm9ybWF0IG9mIFJl Y29yZHMgaW4gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5DQoNCiAgICdJZGVu dGlmaWVyJyBjb250YWlucyB0aGUgc2luZ2xlIGNoYXJhY3RlciBzdWJ0YWcgKHNpbmdsZXRvbikN CiAgIGFzc2lnbmVkIHRvIHRoZSBleHRlbnNpb24uICBUaGUgSW50ZXJuZXQtRHJhZnQgc3VibWl0 dGVkIHRvIGRlZmluZQ0KICAgdGhlIGV4dGVuc2lvbiBTSE9VTEQgc3BlY2lmeSB3aGljaCBsZXR0 ZXIgb3IgZGlnaXQgdG8gdXNlLCBhbHRob3VnaA0KICAgdGhlIElFU0cgTUFZIGNoYW5nZSB0aGUg YXNzaWdubWVudCB3aGVuIGFwcHJvdmluZyB0aGUgUkZDLg0KDQogICAnRGVzY3JpcHRpb24nIGNv bnRhaW5zIHRoZSBuYW1lIGFuZCBkZXNjcmlwdGlvbiBvZiB0aGUgZXh0ZW5zaW9uLg0KDQogICAn Q29tbWVudHMnIGlzIGFuIE9QVElPTkFMIGZpZWxkIGFuZCBNQVkgY29udGFpbiBhIGJyb2FkZXIg ZGVzY3JpcHRpb24NCiAgIG9mIHRoZSBleHRlbnNpb24uDQoNCiAgICdBZGRlZCcgY29udGFpbnMg dGhlIGRhdGUgdGhlIFJGQyB3YXMgcHVibGlzaGVkIGluIHRoZSAiZnVsbC1kYXRlIg0KICAgZm9y bWF0IHNwZWNpZmllZCBpbiBbUkZDMzMzOV0uICBGb3IgZXhhbXBsZTogMjAwNC0wNi0yOCByZXBy ZXNlbnRzDQogICBKdW5lIDI4LCAyMDA0LCBpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLg0KDQog ICAnUkZDJyBjb250YWlucyB0aGUgUkZDIG51bWJlciBhc3NpZ25lZCB0byB0aGUgZXh0ZW5zaW9u Lg0KDQogICAnQXV0aG9yaXR5JyBjb250YWlucyB0aGUgbmFtZSBvZiB0aGUgbWFpbnRhaW5pbmcg YXV0aG9yaXR5IGZvciB0aGUNCiAgIGV4dGVuc2lvbi4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDM1XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgJ0NvbnRhY3RfRW1haWwnIGNvbnRhaW5zIHRoZSBl bWFpbCBhZGRyZXNzIHVzZWQgdG8gY29udGFjdCB0aGUNCiAgIG1haW50YWluaW5nIGF1dGhvcml0 eS4NCg0KICAgJ01haWxpbmdfTGlzdCcgY29udGFpbnMgdGhlIFVSTCBvciBzdWJzY3JpcHRpb24g ZW1haWwgYWRkcmVzcyBvZiB0aGUNCiAgIG1haWxpbmcgbGlzdCB1c2VkIGJ5IHRoZSBtYWludGFp bmluZyBhdXRob3JpdHkuDQoNCiAgICdVUkwnIGNvbnRhaW5zIHRoZSBVUkwgb2YgdGhlIHJlZ2lz dHJ5IGZvciB0aGlzIGV4dGVuc2lvbi4NCg0KICAgVGhlIGRldGVybWluYXRpb24gb2Ygd2hldGhl ciBhbiBJbnRlcm5ldC1EcmFmdCBtZWV0cyB0aGUgYWJvdmUNCiAgIGNvbmRpdGlvbnMgYW5kIHRo ZSBkZWNpc2lvbiB0byBncmFudCBvciB3aXRoaG9sZCBzdWNoIGF1dGhvcml0eSByZXN0cw0KICAg c29sZWx5IHdpdGggdGhlIElFU0csIGFuZCBpcyBzdWJqZWN0IHRvIHRoZSBub3JtYWwgcmV2aWV3 IGFuZCBhcHBlYWxzDQogICBwcm9jZXNzIGFzc29jaWF0ZWQgd2l0aCB0aGUgUkZDIHByb2Nlc3Mu DQoNCiAgIEV4dGVuc2lvbiBhdXRob3JzIGFyZSBzdHJvbmdseSBjYXV0aW9uZWQgdGhhdCBtYW55 IChpbmNsdWRpbmcgbW9zdA0KICAgd2VsbC1mb3JtZWQpIHByb2Nlc3NvcnMgd2lsbCBiZSB1bmF3 YXJlIG9mIGFueSBzcGVjaWFsIHJlbGF0aW9uc2hpcHMNCiAgIG9yIG1lYW5pbmcgaW5oZXJlbnQg aW4gdGhlIG9yZGVyIG9mIGV4dGVuc2lvbiBzdWJ0YWdzLiAgRXh0ZW5zaW9uDQogICBhdXRob3Jz IFNIT1VMRCBhdm9pZCBzdWJ0YWcgcmVsYXRpb25zaGlwcyBvciBjYW5vbmljYWxpemF0aW9uDQog ICBtZWNoYW5pc21zIHRoYXQgaW50ZXJmZXJlIHdpdGggbWF0Y2hpbmcgb3Igd2l0aCBsZW5ndGgg cmVzdHJpY3Rpb25zDQogICB0aGF0IHNvbWV0aW1lcyBleGlzdCBpbiBjb21tb24gcHJvdG9jb2xz IHdoZXJlIHRoZSBleHRlbnNpb24gaXMgdXNlZC4NCiAgIEluIHBhcnRpY3VsYXIsIGFwcGxpY2F0 aW9ucyBNQVkgdHJ1bmNhdGUgdGhlIHN1YnRhZ3MgaW4gZG9pbmcNCiAgIG1hdGNoaW5nIG9yIGlu IGZpdHRpbmcgaW50byBsaW1pdGVkIGxlbmd0aHMsIHNvIGl0IGlzIFJFQ09NTUVOREVEDQogICB0 aGF0IHRoZSBtb3N0IHNpZ25pZmljYW50IGluZm9ybWF0aW9uIGJlIGluIHRoZSBtb3N0IHNpZ25p ZmljYW50DQogICAobGVmdC1tb3N0KSBzdWJ0YWdzLCBhbmQgdGhhdCB0aGUgc3BlY2lmaWNhdGlv biBncmFjZWZ1bGx5IGhhbmRsZQ0KICAgdHJ1bmNhdGVkIHN1YnRhZ3MuDQoNCiAgIFdoZW4gYSBs YW5ndWFnZSB0YWcgaXMgdG8gYmUgdXNlZCBpbiBhIHNwZWNpZmljLCBrbm93biwgcHJvdG9jb2ws IGl0DQogICBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBub3QgY29u dGFpbiBleHRlbnNpb25zIG5vdA0KICAgc3VwcG9ydGVkIGJ5IHRoYXQgcHJvdG9jb2wuICBJbiBh ZGRpdGlvbiwgbm90ZSB0aGF0IHNvbWUgcHJvdG9jb2xzDQogICBNQVkgaW1wb3NlIHVwcGVyIGxp bWl0cyBvbiB0aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmdzIHVzZWQgdG8gc3RvcmUgb3INCiAgIHRy YW5zcG9ydCB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQozLjggIEluaXRpYWxpemF0aW9uIG9mIHRoZSBS ZWdpc3RyaWVzDQoNCiAgIFVwb24gYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhbiBpbml0aWFs IHZlcnNpb24gb2YgdGhlIExhbmd1YWdlDQogICBTdWJ0YWcgUmVnaXN0cnkgY29udGFpbmluZyB0 aGUgdmFyaW91cyBzdWJ0YWdzIGluaXRpYWxseSB2YWxpZCBpbiBhDQogICBsYW5ndWFnZSB0YWcg aXMgbmVjZXNzYXJ5LiAgVGhpcyBjb2xsZWN0aW9uIG9mIHN1YnRhZ3MsIGFsb25nIHdpdGggYQ0K ICAgZGVzY3JpcHRpb24gb2YgdGhlIHByb2Nlc3MgdXNlZCB0byBjcmVhdGUgaXQsIGlzIGRlc2Ny aWJlZCBieQ0KICAgW2luaXRpYWwtcmVnaXN0cnldLiAgSUFOQSBTSEFMTCBwdWJsaXNoIHRoZSBp bml0aWFsIHZlcnNpb24gb2YgdGhlDQogICByZWdpc3RyeSBkZXNjcmliZWQgYnkgdGhpcyBkb2N1 bWVudCBmcm9tIHRoZSBjb250ZW50IG9mIFtpbml0aWFsLQ0KICAgcmVnaXN0cnldLiAgT25jZSBw dWJsaXNoZWQgYnkgSUFOQSwgdGhlIG1haW50ZW5hbmNlIHByb2NlZHVyZXMsIHJ1bGVzDQogICBh bmQgcmVnaXN0cmF0aW9uIHByb2Nlc3NlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCB3aWxs IGJlDQogICBhdmFpbGFibGUgZm9yIG5ldyByZWdpc3RyYXRpb25zIG9yIHVwZGF0ZXMuDQoNCiAg IFJlZ2lzdHJhdGlvbnMgdGhhdCBhcmUgaW4gcHJvY2VzcyB1bmRlciB0aGUgcnVsZXMgZGVmaW5l ZCBpbg0KICAgW1JGQzMwNjZdIHdoZW4gdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIE1BWSBiZSBj b21wbGV0ZWQgdW5kZXIgdGhlDQogICBmb3JtZXIgcnVsZXMsIGF0IHRoZSBkaXNjcmV0aW9uIG9m IHRoZSBMYW5ndWFnZSBUYWcgUmV2aWV3ZXIgKGFzDQogICBkZXNjcmliZWQgaW4gW1JGQzMwNjZd KS4gIFVudGlsIHRoZSBJRVNHIG9mZmljaWFsbHkgYXBwb2ludHMgYQ0KICAgTGFuZ3VhZ2UgU3Vi dGFnIFJldmlld2VyLCB0aGUgZXhpc3RpbmcgTGFuZ3VhZ2UgVGFnIFJldmlld2VyIFNIQUxMDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAg ICAgICAgICAgICBbUGFnZSAzNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIHNlcnZlIGFz IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIuDQoNCiAgIEFueSBuZXcgcmVnaXN0cmF0aW9u cyBzdWJtaXR0ZWQgdXNpbmcgdGhlIFJGQyAzMDY2IGZvcm1zIG9yIGZvcm1hdA0KICAgYWZ0ZXIg dGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYW5kIHB1YmxpY2F0aW9uIG9mIHRoZSByZWdp c3RyeQ0KICAgYnkgSUFOQSBNVVNUIGJlIHJlamVjdGVkLg0KDQogICBBbiBpbml0aWFsIHZlcnNp b24gb2YgdGhlIExhbmd1YWdlIEV4dGVuc2lvbiBSZWdpc3RyeSBkZXNjcmliZWQgaW4NCiAgIFNl Y3Rpb24gMy43IGlzIGFsc28gbmVlZGVkLiAgVGhlIExhbmd1YWdlIEV4dGVuc2lvbiBSZWdpc3Ry eSBTSEFMTCBiZQ0KICAgaW5pdGlhbGl6ZWQgd2l0aCBhIHNpbmdsZSByZWNvcmQgY29udGFpbmlu ZyBhIHNpbmdsZSBmaWVsZCBvZiB0eXBlDQogICAiRmlsZS1EYXRlIiBhcyBhIHBsYWNlaG9sZGVy IGZvciBmdXR1cmUgYXNzaWdubWVudHMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAg W1BhZ2UgMzddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQo0LiAgRm9ybWF0aW9uIGFuZCBQcm9j ZXNzaW5nIG9mIExhbmd1YWdlIFRhZ3MNCg0KICAgVGhpcyBzZWN0aW9uIGFkZHJlc3NlcyBob3cg dG8gdXNlIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgcmVnaXN0cnkNCiAgIHdpdGggdGhlIHRhZyBz eW50YXggdG8gY2hvb3NlLCBmb3JtIGFuZCBwcm9jZXNzIGxhbmd1YWdlIHRhZ3MuDQoNCjQuMSAg Q2hvaWNlIG9mIExhbmd1YWdlIFRhZw0KDQogICBPbmUgaXMgc29tZXRpbWVzIGZhY2VkIHdpdGgg dGhlIGNob2ljZSBiZXR3ZWVuIHNldmVyYWwgcG9zc2libGUgdGFncw0KICAgZm9yIHRoZSBzYW1l IGJvZHkgb2YgdGV4dC4NCg0KICAgSW50ZXJvcGVyYWJpbGl0eSBpcyBiZXN0IHNlcnZlZCB3aGVu IGFsbCB1c2VycyB1c2UgdGhlIHNhbWUgbGFuZ3VhZ2UNCiAgIHRhZyBpbiBvcmRlciB0byByZXBy ZXNlbnQgdGhlIHNhbWUgbGFuZ3VhZ2UuICBJZiBhbiBhcHBsaWNhdGlvbiBoYXMNCiAgIHJlcXVp cmVtZW50cyB0aGF0IG1ha2UgdGhlIHJ1bGVzIGhlcmUgaW5hcHBsaWNhYmxlLCB0aGVuIHRoYXQN CiAgIGFwcGxpY2F0aW9uIHJpc2tzIGRhbWFnaW5nIGludGVyb3BlcmFiaWxpdHkuICBJdCBpcyBz dHJvbmdseQ0KICAgUkVDT01NRU5ERUQgdGhhdCB1c2VycyBub3QgZGVmaW5lIHRoZWlyIG93biBy dWxlcyBmb3IgbGFuZ3VhZ2UgdGFnDQogICBjaG9pY2UuDQoNCiAgIFN1YnRhZ3MgU0hPVUxEIG9u bHkgYmUgdXNlZCB3aGVyZSB0aGV5IGFkZCB1c2VmdWwgZGlzdGluZ3Vpc2hpbmcNCiAgIGluZm9y bWF0aW9uOyBleHRyYW5lb3VzIHN1YnRhZ3MgaW50ZXJmZXJlIHdpdGggdGhlIG1lYW5pbmcsDQog ICB1bmRlcnN0YW5kaW5nLCBhbmQgcHJvY2Vzc2luZyBvZiBsYW5ndWFnZSB0YWdzLiAgSW4gcGFy dGljdWxhciwgdXNlcnMNCiAgIGFuZCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGZvbGxvdyB0aGUg J1ByZWZpeCcgYW5kICdTdXBwcmVzcy1TY3JpcHQnDQogICBmaWVsZHMgaW4gdGhlIHJlZ2lzdHJ5 IChkZWZpbmVkIGluIFNlY3Rpb24gMy4xKTogdGhlc2UgZmllbGRzIHByb3ZpZGUNCiAgIGd1aWRh bmNlIG9uIHdoZW4gc3BlY2lmaWMgYWRkaXRpb25hbCBzdWJ0YWdzIFNIT1VMRCAoYW5kIFNIT1VM RCBOT1QpDQogICBiZSB1c2VkIGluIGEgbGFuZ3VhZ2UgdGFnLg0KDQogICBPZiBwYXJ0aWN1bGFy IG5vdGUsIG1hbnkgYXBwbGljYXRpb25zIGNhbiBiZW5lZml0IGZyb20gdGhlIHVzZSBvZg0KICAg c2NyaXB0IHN1YnRhZ3MgaW4gbGFuZ3VhZ2UgdGFncywgYXMgbG9uZyBhcyB0aGUgdXNlIGlzIGNv bnNpc3RlbnQgZm9yDQogICBhIGdpdmVuIGNvbnRleHQuICBTY3JpcHQgc3VidGFncyB3ZXJlIG5v dCBmb3JtYWxseSBkZWZpbmVkIGluIFJGQw0KICAgMzA2NiBhbmQgdGhlaXIgdXNlIGNhbiBhZmZl Y3QgbWF0Y2hpbmcgYW5kIHN1YnRhZyBpZGVudGlmaWNhdGlvbiBieQ0KICAgaW1wbGVtZW50YXRp b25zIG9mIFJGQyAzMDY2LCBhcyB0aGVzZSBzdWJ0YWdzIGFwcGVhciBiZXR3ZWVuIHRoZQ0KICAg cHJpbWFyeSBsYW5ndWFnZSBhbmQgcmVnaW9uIHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwgaWYgYSB1 c2VyIHJlcXVlc3RzDQogICBjb250ZW50IGluIGFuIGltcGxlbWVudGF0aW9uIG9mIFNlY3Rpb24g Mi41IG9mIFtSRkMzMDY2XSB1c2luZyB0aGUNCiAgIGxhbmd1YWdlIHJhbmdlICJlbi1VUyIsIGNv bnRlbnQgbGFiZWxlZCAiZW4tTGF0bi1VUyIgd2lsbCBub3QgbWF0Y2gNCiAgIHRoZSByZXF1ZXN0 LiAgVGhlcmVmb3JlIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHdoZW4gc2NyaXB0IHN1YnRhZ3MN CiAgIHdpbGwgY3VzdG9tYXJpbHkgYmUgdXNlZCBhbmQgd2hlbiB0aGV5IG91Z2h0IG5vdCBiZSB1 c2VkLiAgSW4gdGhlDQogICByZWdpc3RyeSwgdGhlIFN1cHByZXNzLVNjcmlwdCBmaWVsZCBoZWxw cyBlbnN1cmUgZ3JlYXRlcg0KICAgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFnZSB0 YWdzIGdlbmVyYXRlZCBhY2NvcmRpbmcgdG8gdGhlDQogICBydWxlcyBpbiB0aGlzIGRvY3VtZW50 IGFuZCBsYW5ndWFnZSB0YWdzIGFuZCB0YWcgcHJvY2Vzc29ycyBvcg0KICAgY29uc3VtZXJzIGJh c2VkIG9uIFJGQyAzMDY2IGJ5IGRlZmluaW5nIHdoZW4gdXNlcnMgU0hPVUxEIE5PVCBpbmNsdWRl DQogICBhIHNjcmlwdCBzdWJ0YWcgd2l0aCBhIHBhcnRpY3VsYXIgcHJpbWFyeSBsYW5ndWFnZSBz dWJ0YWcuDQoNCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgKHR5cGUgJ2V4dGxhbmcnIGlu IHRoZSByZWdpc3RyeSwgc2VlDQogICBTZWN0aW9uIDMuMSkgYWxzbyBhcHBlYXIgYmV0d2VlbiB0 aGUgcHJpbWFyeSBsYW5ndWFnZSBhbmQgcmVnaW9uDQogICBzdWJ0YWdzIGFuZCBhcmUgcmVzZXJ2 ZWQgZm9yIGZ1dHVyZSBzdGFuZGFyZGl6YXRpb24uICBBcHBsaWNhdGlvbnMNCiAgIG1pZ2h0IGJl bmVmaXQgZnJvbSB0aGVpciBqdWRpY2lvdXMgdXNlIGluIGZvcm1pbmcgbGFuZ3VhZ2UgdGFncyBp bg0KICAgdGhlIGZ1dHVyZS4gIFNpbWlsYXIgcmVjb21tZW5kYXRpb25zIGFyZSBleHBlY3RlZCB0 byBhcHBseSB0byB0aGVpcg0KICAgdXNlIGFzIGFwcGx5IHRvIHNjcmlwdCBzdWJ0YWdzLg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAg ICAgICAgICAgICBbUGFnZSAzOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIFN0YW5kYXJk cywgcHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlvbnMgdGhhdCByZWZlcmVuY2UgdGhpcyBkb2N1bWVu dA0KICAgbm9ybWF0aXZlbHkgYnV0IGFwcGx5IGRpZmZlcmVudCBydWxlcyB0byB0aGUgb25lcyBn aXZlbiBpbiB0aGlzDQogICBzZWN0aW9uIE1VU1Qgc3BlY2lmeSBob3cgdGhlIHByb2NlZHVyZSB2 YXJpZXMgZnJvbSB0aGUgb25lIGdpdmVuDQogICBoZXJlLg0KDQogICBUaGUgY2hvaWNlIG9mIHN1 YnRhZ3MgdXNlZCB0byBmb3JtIGEgbGFuZ3VhZ2UgdGFnIFNIT1VMRCBiZSBndWlkZWQgYnkNCiAg IHRoZSBmb2xsb3dpbmcgcnVsZXM6DQoNCiAgIDEuICBVc2UgYXMgcHJlY2lzZSBhIHRhZyBhcyBw b3NzaWJsZSwgYnV0IG5vIG1vcmUgc3BlY2lmaWMgdGhhbiBpcw0KICAgICAgIGp1c3RpZmllZC4g IEF2b2lkIHVzaW5nIHN1YnRhZ3MgdGhhdCBhcmUgbm90IGltcG9ydGFudCBmb3INCiAgICAgICBk aXN0aW5ndWlzaGluZyBjb250ZW50IGluIGFuIGFwcGxpY2F0aW9uLg0KDQogICAgICAgKiAgRm9y IGV4YW1wbGUsICdkZScgbWlnaHQgc3VmZmljZSBmb3IgdGFnZ2luZyBhbiBlbWFpbCB3cml0dGVu DQogICAgICAgICAgaW4gR2VybWFuLCB3aGlsZSAiZGUtQ0gtMTk5NiIgaXMgcHJvYmFibHkgdW5u ZWNlc3NhcmlseQ0KICAgICAgICAgIHByZWNpc2UgZm9yIHN1Y2ggYSB0YXNrLg0KDQogICAyLiAg VGhlIHNjcmlwdCBzdWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFn cyB1bmxlc3MNCiAgICAgICB0aGUgc2NyaXB0IGFkZHMgc29tZSBkaXN0aW5ndWlzaGluZyBpbmZv cm1hdGlvbiB0byB0aGUgdGFnLiAgVGhlDQogICAgICAgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcg aW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2UgcmVjb3JkIGluIHRoZQ0KICAgICAgIHJlZ2lzdHJ5IGlu ZGljYXRlcyB3aGljaCBzY3JpcHQgc3VidGFncyBkbyBub3QgYWRkIGRpc3Rpbmd1aXNoaW5nDQog ICAgICAgaW5mb3JtYXRpb24gZm9yIG1vc3QgYXBwbGljYXRpb25zLg0KDQogICAgICAgKiAgRm9y IGV4YW1wbGUsIHRoZSBzdWJ0YWcgJ0xhdG4nIHNob3VsZCBub3QgYmUgdXNlZCB3aXRoIHRoZQ0K ICAgICAgICAgIHByaW1hcnkgbGFuZ3VhZ2UgJ2VuJyBiZWNhdXNlIG5lYXJseSBhbGwgRW5nbGlz aCBkb2N1bWVudHMgYXJlDQogICAgICAgICAgd3JpdHRlbiBpbiB0aGUgTGF0aW4gc2NyaXB0IGFu ZCBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQogICAgICAgICAgaW5mb3JtYXRpb24uICBIb3dl dmVyLCBpZiBhIGRvY3VtZW50IHdlcmUgd3JpdHRlbiBpbiBFbmdsaXNoDQogICAgICAgICAgbWl4 aW5nIExhdGluIHNjcmlwdCB3aXRoIGFub3RoZXIgc2NyaXB0IHN1Y2ggYXMgQnJhaWxsZQ0KICAg ICAgICAgICgnQnJhaScpLCB0aGVuIGl0IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIHRvIGNob29zZSB0 byBpbmRpY2F0ZQ0KICAgICAgICAgIGJvdGggc2NyaXB0cyB0byBhaWQgaW4gY29udGVudCBzZWxl Y3Rpb24sIHN1Y2ggYXMgdGhlDQogICAgICAgICAgYXBwbGljYXRpb24gb2YgYSBzdHlsZSBzaGVl dC4NCg0KICAgMy4gIElmIGEgdGFnIG9yIHN1YnRhZyBoYXMgYSAnUHJlZmVycmVkLVZhbHVlJyBm aWVsZCBpbiBpdHMgcmVnaXN0cnkNCiAgICAgICBlbnRyeSwgdGhlbiB0aGUgdmFsdWUgb2YgdGhh dCBmaWVsZCBTSE9VTEQgYmUgdXNlZCB0byBmb3JtIHRoZQ0KICAgICAgIGxhbmd1YWdlIHRhZyBp biBwcmVmZXJlbmNlIHRvIHRoZSB0YWcgb3Igc3VidGFnIGluIHdoaWNoIHRoZQ0KICAgICAgIHBy ZWZlcnJlZCB2YWx1ZSBhcHBlYXJzLg0KDQogICAgICAgKiAgRm9yIGV4YW1wbGUsIHVzZSAnaGUn IGZvciBIZWJyZXcgaW4gcHJlZmVyZW5jZSB0byAnaXcnLg0KDQogICA0LiAgVGhlICd1bmQnIChV bmRldGVybWluZWQpIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIFNIT1VMRCBOT1QgYmUNCiAgICAg ICB1c2VkIHRvIGxhYmVsIGNvbnRlbnQsIGV2ZW4gaWYgdGhlIGxhbmd1YWdlIGlzIHVua25vd24u ICBPbWl0dGluZw0KICAgICAgIHRoZSBsYW5ndWFnZSB0YWcgYWx0b2dldGhlciBpcyBwcmVmZXJy ZWQgdG8gdXNpbmcgYSB0YWcgd2l0aCBhDQogICAgICAgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcg b2YgJ3VuZCcuICBUaGUgJ3VuZCcgc3VidGFnIE1BWSBiZSB1c2VmdWwNCiAgICAgICBmb3IgcHJv dG9jb2xzIHRoYXQgcmVxdWlyZSBhIGxhbmd1YWdlIHRhZyB0byBiZSBwcm92aWRlZC4gIFRoZQ0K ICAgICAgICd1bmQnIHN1YnRhZyBNQVkgYWxzbyBiZSB1c2VmdWwgd2hlbiBtYXRjaGluZyBsYW5n dWFnZSB0YWdzIGluDQogICAgICAgY2VydGFpbiBzaXR1YXRpb25zLg0KDQogICA1LiAgVGhlICdt dWwnIChNdWx0aXBsZSkgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2Vk DQogICAgICAgd2hlbmV2ZXIgdGhlIHByb3RvY29sIGFsbG93cyB0aGUgc2VwYXJhdGUgdGFncyBm b3IgbXVsdGlwbGUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNo IDI2LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDM5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoN Cg0KICAgICAgIGxhbmd1YWdlcywgYXMgaXMgdGhlIGNhc2UgZm9yIHRoZSBDb250ZW50LUxhbmd1 YWdlIGhlYWRlciBpbg0KICAgICAgIEhUVFAuICBUaGUgJ211bCcgc3VidGFnIGNvbnZleXMgbGl0 dGxlIHVzZWZ1bCBpbmZvcm1hdGlvbjoNCiAgICAgICBjb250ZW50IGluIG11bHRpcGxlIGxhbmd1 YWdlcyBTSE9VTEQgaW5kaXZpZHVhbGx5IHRhZyB0aGUNCiAgICAgICBsYW5ndWFnZXMgd2hlcmUg dGhleSBhcHBlYXIgb3Igb3RoZXJ3aXNlIGluZGljYXRlIHRoZSBhY3R1YWwNCiAgICAgICBsYW5n dWFnZSBpbiBwcmVmZXJlbmNlIHRvIHRoZSAnbXVsJyBzdWJ0YWcuDQoNCiAgIDYuICBUaGUgc2Ft ZSB2YXJpYW50IHN1YnRhZyBTSE9VTEQgTk9UIGJlIHVzZWQgbW9yZSB0aGFuIG9uY2Ugd2l0aGlu DQogICAgICAgYSBsYW5ndWFnZSB0YWcuDQoNCiAgICAgICAqICBGb3IgZXhhbXBsZSwgZG8gbm90 IHVzZSAiZGUtREUtMTkwMS0xOTAxIi4NCg0KICAgVG8gZW5zdXJlIGNvbnNpc3RlbnQgYmFja3dh cmQgY29tcGF0aWJpbGl0eSwgdGhpcyBkb2N1bWVudCBjb250YWlucw0KICAgc2V2ZXJhbCBwcm92 aXNpb25zIHRvIGFjY291bnQgZm9yIHBvdGVudGlhbCBpbnN0YWJpbGl0eSBpbiB0aGUNCiAgIHN0 YW5kYXJkcyB1c2VkIHRvIGRlZmluZSB0aGUgc3VidGFncyB0aGF0IG1ha2UgdXAgbGFuZ3VhZ2Ug dGFncy4NCiAgIFRoZXNlIHByb3Zpc2lvbnMgbWVhbiB0aGF0IG5vIGxhbmd1YWdlIHRhZyBjcmVh dGVkIHVuZGVyIHRoZSBydWxlcyBpbg0KICAgdGhpcyBkb2N1bWVudCB3aWxsIGJlY29tZSBvYnNv bGV0ZS4NCg0KNC4yICBNZWFuaW5nIG9mIHRoZSBMYW5ndWFnZSBUYWcNCg0KICAgVGhlIHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIHRoZSB0YWcgYW5kIHRoZSBpbmZvcm1hdGlvbiBpdCByZWxhdGVzIHRv IGlzDQogICBkZWZpbmVkIGJ5IHRoZSBjb250ZXh0IGluIHdoaWNoIHRoZSB0YWcgYXBwZWFycy4g IEFjY29yZGluZ2x5LCB0aGlzDQogICBzZWN0aW9uIGdpdmVzIG9ubHkgcG9zc2libGUgZXhhbXBs ZXMgb2YgaXRzIHVzYWdlLg0KDQogICBvICBGb3IgYSBzaW5nbGUgaW5mb3JtYXRpb24gb2JqZWN0 LCB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0YWdzDQogICAgICBtaWdodCBiZSBpbnRlcnByZXRl ZCBhcyB0aGUgc2V0IG9mIGxhbmd1YWdlcyB0aGF0IGlzIG5lY2Vzc2FyeSBmb3INCiAgICAgIGEg Y29tcGxldGUgY29tcHJlaGVuc2lvbiBvZiB0aGUgY29tcGxldGUgb2JqZWN0LiAgRXhhbXBsZTog UGxhaW4NCiAgICAgIHRleHQgZG9jdW1lbnRzLg0KDQogICBvICBGb3IgYW4gYWdncmVnYXRpb24g b2YgaW5mb3JtYXRpb24gb2JqZWN0cywgdGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UNCiAgICAgIHRh Z3MgY291bGQgYmUgdGFrZW4gYXMgdGhlIHNldCBvZiBsYW5ndWFnZXMgdXNlZCBpbnNpZGUgY29t cG9uZW50cw0KICAgICAgb2YgdGhhdCBhZ2dyZWdhdGlvbi4gIEV4YW1wbGVzOiBEb2N1bWVudCBz dG9yZXMgYW5kIGxpYnJhcmllcy4NCg0KICAgbyAgRm9yIGluZm9ybWF0aW9uIG9iamVjdHMgd2hv c2UgcHVycG9zZSBpcyB0byBwcm92aWRlIGFsdGVybmF0aXZlcywNCiAgICAgIHRoZSBhc3NvY2lh dGVkIGxhbmd1YWdlIHRhZ3MgY291bGQgYmUgcmVnYXJkZWQgYXMgYSBoaW50IHRoYXQgdGhlDQog ICAgICBjb250ZW50IGlzIHByb3ZpZGVkIGluIHNldmVyYWwgbGFuZ3VhZ2VzLCBhbmQgdGhhdCBv bmUgaGFzIHRvDQogICAgICBpbnNwZWN0IGVhY2ggb2YgdGhlIGFsdGVybmF0aXZlcyBpbiBvcmRl ciB0byBmaW5kIGl0cyBsYW5ndWFnZSBvcg0KICAgICAgbGFuZ3VhZ2VzLiAgSW4gdGhpcyBjYXNl LCB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgdGFncyBtaWdodCBub3QNCiAgICAgIG1lYW4gdGhh dCBvbmUgbmVlZHMgdG8gYmUgbXVsdGktbGluZ3VhbCB0byBnZXQgY29tcGxldGUNCiAgICAgIHVu ZGVyc3RhbmRpbmcgb2YgdGhlIGRvY3VtZW50LiAgRXhhbXBsZTogTUlNRSBtdWx0aXBhcnQvDQog ICAgICBhbHRlcm5hdGl2ZS4NCg0KICAgbyAgSW4gbWFya3VwIGxhbmd1YWdlcywgc3VjaCBhcyBI VE1MIGFuZCBYTUwsIGxhbmd1YWdlIGluZm9ybWF0aW9uDQogICAgICBjYW4gYmUgYWRkZWQgdG8g ZWFjaCBwYXJ0IG9mIHRoZSBkb2N1bWVudCBpZGVudGlmaWVkIGJ5IHRoZSBtYXJrdXANCiAgICAg IHN0cnVjdHVyZSAoaW5jbHVkaW5nIHRoZSB3aG9sZSBkb2N1bWVudCBpdHNlbGYpLiAgRm9yIGV4 YW1wbGUsIG9uZQ0KICAgICAgY291bGQgd3JpdGUgPHNwYW4gbGFuZz0iZnIiPkMnZXN0IGxhIHZp ZS48L3NwYW4+IGluc2lkZSBhDQogICAgICBOb3J3ZWdpYW4gZG9jdW1lbnQ7IHRoZSBOb3J3ZWdp YW4tc3BlYWtpbmcgdXNlciBjb3VsZCB0aGVuIGFjY2Vzcw0KICAgICAgYSBGcmVuY2gtTm9yd2Vn aWFuIGRpY3Rpb25hcnkgdG8gZmluZCBvdXQgd2hhdCB0aGUgbWFya2VkIHNlY3Rpb24NCiAgICAg IG1lYW50LiAgSWYgdGhlIHVzZXIgd2VyZSBsaXN0ZW5pbmcgdG8gdGhhdCBkb2N1bWVudCB0aHJv dWdoIGENCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAy MDA2ICAgICAgICAgICAgICAgIFtQYWdlIDQwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAg ICAgc3BlZWNoIHN5bnRoZXNpcyBpbnRlcmZhY2UsIHRoaXMgZm9ybWF0aW9uIGNvdWxkIGJlIHVz ZWQgdG8gc2lnbmFsDQogICAgICB0aGUgc3ludGhlc2l6ZXIgdG8gYXBwcm9wcmlhdGVseSBhcHBs eSBGcmVuY2ggdGV4dC10by1zcGVlY2gNCiAgICAgIHByb251bmNpYXRpb24gcnVsZXMgdG8gdGhh dCBzcGFuIG9mIHRleHQsIGluc3RlYWQgb2YgYXBwbHlpbmcgdGhlDQogICAgICBpbmFwcHJvcHJp YXRlIE5vcndlZ2lhbiBydWxlcy4NCg0KICAgTGFuZ3VhZ2UgdGFncyBhcmUgcmVsYXRlZCB3aGVu IHRoZXkgY29udGFpbiBhIHNpbWlsYXIgc2VxdWVuY2Ugb2YNCiAgIHN1YnRhZ3MuICBGb3IgZXhh bXBsZSwgaWYgYSBsYW5ndWFnZSB0YWcgQiBjb250YWlucyBsYW5ndWFnZSB0YWcgQSBhcw0KICAg YSBwcmVmaXgsIHRoZW4gQiBpcyB0eXBpY2FsbHkgIm5hcnJvd2VyIiBvciAibW9yZSBzcGVjaWZp YyIgdGhhbiBBLg0KICAgVGh1cyAiemgtSGFudC1UVyIgaXMgbW9yZSBzcGVjaWZpYyB0aGFuICJ6 aC1IYW50Ii4NCg0KICAgVGhpcyByZWxhdGlvbnNoaXAgaXMgbm90IGd1YXJhbnRlZWQgaW4gYWxs IGNhc2VzOiBzcGVjaWZpY2FsbHksDQogICBsYW5ndWFnZXMgdGhhdCBiZWdpbiB3aXRoIHRoZSBz YW1lIHNlcXVlbmNlIG9mIHN1YnRhZ3MgYXJlIE5PVA0KICAgZ3VhcmFudGVlZCB0byBiZSBtdXR1 YWxseSBpbnRlbGxpZ2libGUsIGFsdGhvdWdoIHRoZXkgbWlnaHQgYmUuICBGb3INCiAgIGV4YW1w bGUsIHRoZSB0YWcgImF6IiBzaGFyZXMgYSBwcmVmaXggd2l0aCBib3RoICJhei1MYXRuIg0KICAg KEF6ZXJiYWlqYW5pIHdyaXR0ZW4gdXNpbmcgdGhlIExhdGluIHNjcmlwdCkgYW5kICJhei1DeXJs Ig0KICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4gdXNpbmcgdGhlIEN5cmlsbGljIHNjcmlwdCkuICBB IHBlcnNvbiBmbHVlbnQgaW4NCiAgIG9uZSBzY3JpcHQgbWlnaHQgbm90IGJlIGFibGUgdG8gcmVh ZCB0aGUgb3RoZXIsIGV2ZW4gdGhvdWdoIHRoZSB0ZXh0DQogICBtaWdodCBiZSBpZGVudGljYWwu ICBDb250ZW50IHRhZ2dlZCBhcyAiYXoiIG1vc3QgcHJvYmFibHkgaXMgd3JpdHRlbg0KICAgaW4g anVzdCBvbmUgc2NyaXB0IGFuZCB0aHVzIG1pZ2h0IG5vdCBiZSBpbnRlbGxpZ2libGUgdG8gYSBy ZWFkZXINCiAgIGZhbWlsaWFyIHdpdGggdGhlIG90aGVyIHNjcmlwdC4NCg0KNC4zICBMZW5ndGgg Q29uc2lkZXJhdGlvbnMNCg0KICAgW1JGQzMwNjZdIGRpZCBub3QgcHJvdmlkZSBhbiB1cHBlciBs aW1pdCBvbiB0aGUgc2l6ZSBvZiBsYW5ndWFnZQ0KICAgdGFncy4gIFdoaWxlIFJGQyAzMDY2IGRp ZCBkZWZpbmUgdGhlIHNlbWFudGljcyBvZiBwYXJ0aWN1bGFyIHN1YnRhZ3MNCiAgIGluIHN1Y2gg YSB3YXkgdGhhdCBtb3N0IGxhbmd1YWdlIHRhZ3MgY29uc2lzdGVkIG9mIGxhbmd1YWdlIGFuZA0K ICAgcmVnaW9uIHN1YnRhZ3Mgd2l0aCBhIGNvbWJpbmVkIHRvdGFsIGxlbmd0aCBvZiB1cCB0byBz aXggY2hhcmFjdGVycywNCiAgIGxhcmdlciByZWdpc3RlcmVkIHRhZ3Mgd2VyZSBub3Qgb25seSBw b3NzaWJsZSBidXQgd2VyZSBhY3R1YWxseQ0KICAgcmVnaXN0ZXJlZC4NCg0KICAgTmVpdGhlciB0 aGUgbGFuZ3VhZ2UgdGFnIHN5bnRheCBub3Igb3RoZXIgcmVxdWlyZW1lbnRzIGluIHRoaXMNCiAg IGRvY3VtZW50IGltcG9zZSBhIGZpeGVkIHVwcGVyIGxpbWl0IG9uIHRoZSBudW1iZXIgb2Ygc3Vi dGFncyBpbiBhDQogICBsYW5ndWFnZSB0YWcgKGFuZCB0aHVzIGFuIHVwcGVyIGJvdW5kIG9uIHRo ZSBzaXplIG9mIGEgdGFnKS4gIFRoZQ0KICAgbGFuZ3VhZ2UgdGFnIHN5bnRheCBzdWdnZXN0cyB0 aGF0LCBkZXBlbmRpbmcgb24gdGhlIHNwZWNpZmljDQogICBsYW5ndWFnZSwgbW9yZSBzdWJ0YWdz IChhbmQgdGh1cyBhIGxvbmdlciB0YWcpIGFyZSBzb21ldGltZXMNCiAgIG5lY2Vzc2FyeSB0byBj b21wbGV0ZWx5IGlkZW50aWZ5IHRoZSBsYW5ndWFnZSBmb3IgY2VydGFpbg0KICAgYXBwbGljYXRp b25zOyB0aHVzIGl0IGlzIHBvc3NpYmxlIHRvIGVudmlzaW9uIGxvbmcgb3IgY29tcGxleCBzdWJ0 YWcNCiAgIHNlcXVlbmNlcy4NCg0KNC4zLjEgIFdvcmtpbmcgd2l0aCBMaW1pdGVkIEJ1ZmZlciBT aXplcw0KDQogICBTb21lIGFwcGxpY2F0aW9ucyBhbmQgcHJvdG9jb2xzIGFyZSBmb3JjZWQgdG8g YWxsb2NhdGUgZml4ZWQgYnVmZmVyDQogICBzaXplcyBvciBvdGhlcndpc2UgbGltaXQgdGhlIGxl bmd0aCBvZiBhIGxhbmd1YWdlIHRhZy4gIEEgY29uZm9ybWFudA0KICAgaW1wbGVtZW50YXRpb24g b3Igc3BlY2lmaWNhdGlvbiBNQVkgcmVmdXNlIHRvIHN1cHBvcnQgdGhlIHN0b3JhZ2Ugb2YNCiAg IGxhbmd1YWdlIHRhZ3Mgd2hpY2ggZXhjZWVkIGEgc3BlY2lmaWVkIGxlbmd0aC4gIEFueSBzdWNo IGxpbWl0YXRpb24NCiAgIFNIT1VMRCBiZSBjbGVhcmx5IGRvY3VtZW50ZWQsIGFuZCBzdWNoIGRv Y3VtZW50YXRpb24gU0hPVUxEIGluY2x1ZGUNCiAgIHdoYXQgaGFwcGVucyB0byBsb25nZXIgdGFn cyAoZm9yIGV4YW1wbGUsIHdoZXRoZXIgYW4gZXJyb3IgdmFsdWUgaXMNCiAgIGdlbmVyYXRlZCBv ciB0aGUgbGFuZ3VhZ2UgdGFnIGlzIHRydW5jYXRlZCkuICBBIHByb3RvY29sIHRoYXQgYWxsb3dz DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAg ICAgICAgICAgICAgICBbUGFnZSA0MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIHRhZ3Mg dG8gYmUgdHJ1bmNhdGVkIGF0IGFuIGFyYml0cmFyeSBsaW1pdCwgd2l0aG91dCBnaXZpbmcgYW55 DQogICBpbmRpY2F0aW9uIG9mIHdoYXQgdGhhdCBsaW1pdCBpcywgaGFzIHRoZSBwb3RlbnRpYWwg Zm9yIGNhdXNpbmcgaGFybQ0KICAgYnkgY2hhbmdpbmcgdGhlIG1lYW5pbmcgb2YgdGFncyBpbiBz dWJzdGFudGlhbCB3YXlzLg0KDQogICBJbiBwcmFjdGljZSwgbW9zdCBsYW5ndWFnZSB0YWdzIGRv IG5vdCByZXF1aXJlIG1vcmUgdGhhbiBhIGZldw0KICAgc3VidGFncyBhbmQgd2lsbCBub3QgYXBw cm9hY2ggcmVhc29uYWJseSBzaXplZCBidWZmZXIgbGltaXRhdGlvbnM6DQogICBzZWUgU2VjdGlv biA0LjEuDQoNCiAgIFNvbWUgc3BlY2lmaWNhdGlvbnMgb3IgcHJvdG9jb2xzIGhhdmUgbGltaXRz IG9uIHRhZyBsZW5ndGggYnV0IGRvIG5vdA0KICAgaGF2ZSBhIGZpeGVkIGxlbmd0aCBsaW1pdGF0 aW9uLiAgRm9yIGV4YW1wbGUsIFtSRkMyMjMxXSAgaGFzIG5vDQogICBleHBsaWNpdCBsZW5ndGgg bGltaXRhdGlvbjogdGhlIGxlbmd0aCBhdmFpbGFibGUgZm9yIHRoZSBsYW5ndWFnZSB0YWcNCiAg IGlzIGNvbnN0cmFpbmVkIGJ5IHRoZSBsZW5ndGggb2Ygb3RoZXIgaGVhZGVyIGNvbXBvbmVudHMg KHN1Y2ggYXMgdGhlDQogICBjaGFyc2V0J3MgbmFtZSkgY291cGxlZCB3aXRoIHRoZSA3NiBjaGFy YWN0ZXIgbGltaXQgaW4gW1JGQzIwNDddLg0KICAgVGh1cyB0aGUgImxpbWl0IiBtaWdodCBiZSA1 MCBvciBtb3JlIGNoYXJhY3RlcnMsIGJ1dCBpdCBjb3VsZA0KICAgcG90ZW50aWFsbHkgYmUgcXVp dGUgc21hbGwuDQoNCiAgIFRoZSBjb25zaWRlcmF0aW9ucyBmb3IgYXNzaWduaW5nIGEgYnVmZmVy IGxpbWl0IGFyZToNCg0KICAgICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBOT1QgdHJ1bmNhdGUg bGFuZ3VhZ2UgdGFncyB1bmxlc3MgdGhlDQogICAgICBtZWFuaW5nIG9mIHRoZSB0YWcgaXMgcHVy cG9zZWZ1bGx5IGJlaW5nIGNoYW5nZWQsIG9yIHVubGVzcyB0aGUNCiAgICAgIHRhZyBkb2VzIG5v dCBmaXQgaW50byBhIGxpbWl0ZWQgYnVmZmVyIHNpemUgc3BlY2lmaWVkIGJ5IGENCiAgICAgIHBy b3RvY29sIGZvciBzdG9yYWdlIG9yIHRyYW5zbWlzc2lvbi4NCg0KICAgICAgSW1wbGVtZW50YXRp b25zIFNIT1VMRCB3YXJuIHRoZSB1c2VyIHdoZW4gYSB0YWcgaXMgdHJ1bmNhdGVkIHNpbmNlDQog ICAgICB0cnVuY2F0aW9uIGNoYW5nZXMgdGhlIHNlbWFudGljIG1lYW5pbmcgb2YgdGhlIHRhZy4N Cg0KICAgICAgSW1wbGVtZW50YXRpb25zIG9mIHByb3RvY29scyBvciBzcGVjaWZpY2F0aW9ucyB0 aGF0IGFyZSBzcGFjZQ0KICAgICAgY29uc3RyYWluZWQgYnV0IGRvIG5vdCBoYXZlIGEgZml4ZWQg bGltaXQgU0hPVUxEIHVzZSB0aGUgbG9uZ2VzdA0KICAgICAgcG9zc2libGUgdGFnIGluIHByZWZl cmVuY2UgdG8gdHJ1bmNhdGlvbi4NCg0KICAgICAgUHJvdG9jb2xzIG9yIHNwZWNpZmljYXRpb25z IHRoYXQgc3BlY2lmeSBsaW1pdGVkIGJ1ZmZlciBzaXplcyBmb3INCiAgICAgIGxhbmd1YWdlIHRh Z3MgTVVTVCBhbGxvdyBmb3IgbGFuZ3VhZ2UgdGFncyBvZiB1cCB0byAzMyBjaGFyYWN0ZXJzLg0K DQogICAgICBQcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBzcGVjaWZ5IGxpbWl0ZWQg YnVmZmVyIHNpemVzIGZvcg0KICAgICAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWxsb3cgZm9yIGxh bmd1YWdlIHRhZ3Mgb2YgYXQgbGVhc3QgNDINCiAgICAgIGNoYXJhY3RlcnMuDQoNCiAgIFRoZSBm b2xsb3dpbmcgaWxsdXN0cmF0aW9uIHNob3dzIGhvdyB0aGUgNDItY2hhcmFjdGVyIHJlY29tbWVu ZGF0aW9uDQogICB3YXMgZGVyaXZlZC4gIFRoZSBjb21iaW5hdGlvbiBvZiBsYW5ndWFnZSBhbmQg ZXh0ZW5kZWQgbGFuZ3VhZ2UNCiAgIHN1YnRhZ3Mgd2FzIGNob3NlbiBmb3IgZnV0dXJlIGNvbXBh dGliaWxpdHkuICBBdCB1cCB0byAxNSBjaGFyYWN0ZXJzLA0KICAgdGhpcyBjb21iaW5hdGlvbiBp cyBsb25nZXIgdGhhbiB0aGUgbG9uZ2VzdCBwb3NzaWJsZSBwcmltYXJ5IGxhbmd1YWdlDQogICBz dWJ0YWcgKDggY2hhcmFjdGVycyk6DQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA0Ml0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIGxhbmd1YWdlICAgICAgPSAgMyAoSVNPIDYzOS0y OyBJU08gNjM5LTEgcmVxdWlyZXMgMikNCiAgIGV4dGxhbmcxICAgICAgPSAgNCAoZWFjaCBzdWJz ZXF1ZW50IHN1YnRhZyBpbmNsdWRlcyAnLScpDQogICBleHRsYW5nMiAgICAgID0gIDQgKHVubGlr ZWx5OiBuZWVkcyBwcmVmaXg9Imxhbmd1YWdlLWV4dGxhbmcxIikNCiAgIGV4dGxhbmczICAgICAg PSAgNCAoZXh0cmVtZWx5IHVubGlrZWx5KQ0KICAgc2NyaXB0ICAgICAgICA9ICA1IChpZiBub3Qg c3VwcHJlc3NlZDogc2VlIFNlY3Rpb24gNC4xKQ0KICAgcmVnaW9uICAgICAgICA9ICA0IChVTiBN LjQ5OyBJU08gMzE2NiByZXF1aXJlcyAzKQ0KICAgdmFyaWFudDEgICAgICA9ICA5IChNVVNUIGhh dmUgbGFuZ3VhZ2UgYXMgYSBwcmVmaXgpDQogICB2YXJpYW50MiAgICAgID0gIDkgKE1VU1QgaGF2 ZSBsYW5ndWFnZS12YXJpYW50MSBhcyBhIHByZWZpeCkNCg0KICAgdG90YWwgICAgICAgICA9IDQy IGNoYXJhY3RlcnMNCg0KICAgICAgICAgICAgICBGaWd1cmUgNzogRGVyaXZhdGlvbiBvZiB0aGUg TGltaXQgb24gVGFnIExlbmd0aA0KDQoNCjQuMy4yICBUcnVuY2F0aW9uIG9mIExhbmd1YWdlIFRh Z3MNCg0KICAgVHJ1bmNhdGlvbiBvZiBhIGxhbmd1YWdlIHRhZyBhbHRlcnMgdGhlIG1lYW5pbmcg b2YgdGhlIHRhZywgYW5kIHRodXMNCiAgIFNIT1VMRCBiZSBhdm9pZGVkLiAgSG93ZXZlciwgdHJ1 bmNhdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGlzIHNvbWV0aW1lcw0KICAgbmVjZXNzYXJ5IGR1ZSB0 byBsaW1pdGVkIGJ1ZmZlciBzaXplcy4gIFN1Y2ggdHJ1bmNhdGlvbiBNVVNUIE5PVA0KICAgcGVy bWl0IGEgc3VidGFnIHRvIGJlIGNob3BwZWQgb2ZmIGluIHRoZSBtaWRkbGUgb3IgdGhlIGZvcm1h dGlvbiBvZg0KICAgaW52YWxpZCB0YWdzIChmb3IgZXhhbXBsZSwgb25lIGVuZGluZyB3aXRoIHRo ZSAiLSIgY2hhcmFjdGVyKS4NCg0KICAgVGhpcyBtZWFucyB0aGF0IGFwcGxpY2F0aW9ucyBvciBw cm90b2NvbHMgd2hpY2ggdHJ1bmNhdGUgdGFncyBNVVNUIGRvDQogICBzbyBieSBwcm9ncmVzc2l2 ZWx5IHJlbW92aW5nIHN1YnRhZ3MgYWxvbmcgd2l0aCB0aGVpciBwcmVjZWRpbmcgIi0iDQogICBm cm9tIHRoZSByaWdodCBzaWRlIG9mIHRoZSBsYW5ndWFnZSB0YWcgdW50aWwgdGhlIHRhZyBpcyBz aG9ydCBlbm91Z2gNCiAgIGZvciB0aGUgZ2l2ZW4gYnVmZmVyLiAgSWYgdGhlIHJlc3VsdGluZyB0 YWcgZW5kcyB3aXRoIGEgc2luZ2xlLQ0KICAgY2hhcmFjdGVyIHN1YnRhZywgdGhhdCBzdWJ0YWcg YW5kIGl0cyBwcmVjZWRpbmcgIi0iIE1VU1QgYWxzbyBiZQ0KICAgcmVtb3ZlZC4gIEZvciBleGFt cGxlOg0KDQogICBUYWcgdG8gdHJ1bmNhdGU6IHpoLUhhbnQtQ04tdmFyaWFudDEtYS1leHRlbmQx LXgtd2FkZWdpbGUtcHJpdmF0ZTENCiAgIDEuIHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRlbmQx LXgtd2FkZWdpbGUNCiAgIDIuIHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRlbmQxDQogICAzLiB6 aC1MYXRuLUNOLXZhcmlhbnQxDQogICA0LiB6aC1MYXRuLUNODQogICA1LiB6aC1MYXRuDQogICA2 LiB6aA0KDQogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA4OiBFeGFtcGxlIG9mIFRhZyBUcnVu Y2F0aW9uDQoNCg0KNC40ICBDYW5vbmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MNCg0KICAg U2luY2UgYSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHRhZyBpcyBzb21ldGltZXMgdXNlZCBieSBtYW55 IHByb2Nlc3NlcywNCiAgIGxhbmd1YWdlIHRhZ3MgU0hPVUxEIGFsd2F5cyBiZSBjcmVhdGVkIG9y IGdlbmVyYXRlZCBpbiBhIGNhbm9uaWNhbA0KICAgZm9ybS4NCg0KICAgQSBsYW5ndWFnZSB0YWcg aXMgaW4gY2Fub25pY2FsIGZvcm0gd2hlbjoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNDNdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMDUNCg0KDQogICAxLiAgVGhlIHRhZyBpcyB3ZWxsLWZvcm1lZCBhY2NvcmRp bmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gMi4xIGFuZA0KICAgICAgIFNlY3Rpb24gMi4yLg0KDQog ICAyLiAgU3VidGFncyBvZiB0eXBlICdSZWdpb24nIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1 ZSBtYXBwaW5nIGluDQogICAgICAgdGhlIElBTkEgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMuMSkg U0hPVUxEIGJlIHJlcGxhY2VkIHdpdGggdGhlaXINCiAgICAgICBtYXBwZWQgdmFsdWUuICBOb3Rl OiBJbiByYXJlIGNhc2VzIHRoZSBtYXBwZWQgdmFsdWUgd2lsbCBhbHNvDQogICAgICAgaGF2ZSBh IFByZWZlcnJlZC1WYWx1ZS4NCg0KICAgMy4gIFJlZHVuZGFudCBvciBncmFuZGZhdGhlcmVkIHRh Z3MgdGhhdCBoYXZlIGEgUHJlZmVycmVkLVZhbHVlDQogICAgICAgbWFwcGluZyBpbiB0aGUgSUFO QSByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4xKSBNVVNUIGJlIHJlcGxhY2VkDQogICAgICAgd2l0 aCB0aGVpciBtYXBwZWQgdmFsdWUuICBUaGVzZSBpdGVtcyBhcmUgZWl0aGVyIGRlcHJlY2F0ZWQN CiAgICAgICBtYXBwaW5ncyBjcmVhdGVkIGJlZm9yZSB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudCAoc3VjaCBhcw0KICAgICAgIHRoZSBtYXBwaW5nIG9mICJuby1ueW4iIHRvICJubiIgb3Ig Imkta2xpbmdvbiIgdG8gInRsaCIpIG9yIGFyZQ0KICAgICAgIHRoZSByZXN1bHQgb2YgbGF0ZXIg cmVnaXN0cmF0aW9ucyBvciBhZGRpdGlvbnMgdG8gdGhpcyBkb2N1bWVudA0KICAgICAgIChmb3Ig ZXhhbXBsZSwgInpoLWd1b3l1IiBtaWdodCBiZSBtYXBwZWQgdG8gYSBsYW5ndWFnZS1leHRsYW5n DQogICAgICAgY29tYmluYXRpb24gc3VjaCBhcyAiemgtY21uIiBieSBzb21lIGZ1dHVyZSB1cGRh dGUgb2YgdGhpcw0KICAgICAgIGRvY3VtZW50KS4NCg0KICAgNC4gIE90aGVyIHN1YnRhZ3MgdGhh dCBoYXZlIGEgUHJlZmVycmVkLVZhbHVlIG1hcHBpbmcgaW4gdGhlIElBTkENCiAgICAgICByZWdp c3RyeSAoc2VlIFNlY3Rpb24gMy4xKSBNVVNUIGJlIHJlcGxhY2VkIHdpdGggdGhlaXIgbWFwcGVk DQogICAgICAgdmFsdWUuICBUaGVzZSBpdGVtcyBjb25zaXN0IGVudGlyZWx5IG9mIGNsZXJpY2Fs IGNvcnJlY3Rpb25zIHRvDQogICAgICAgSVNPIDYzOS0xIGluIHdoaWNoIHRoZSBkZXByZWNhdGVk IHN1YnRhZ3MgaGF2ZSBiZWVuIG1haW50YWluZWQNCiAgICAgICBmb3IgY29tcGF0aWJpbGl0eSBw dXJwb3Nlcy4NCg0KICAgNS4gIElmIG1vcmUgdGhhbiBvbmUgZXh0ZW5zaW9uIHN1YnRhZyBzZXF1 ZW5jZSBleGlzdHMsIHRoZSBleHRlbnNpb24NCiAgICAgICBzZXF1ZW5jZXMgYXJlIG9yZGVyZWQg aW50byBjYXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVyIGJ5DQogICAgICAgc2luZ2xldG9uIHN1 YnRhZy4NCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAiZW4tQS1hYWEtQi1jY2MtYmJi LXgteHl6IiBpcyBpbiBjYW5vbmljYWwNCiAgIGZvcm0sIHdoaWxlICJlbi1CLWNjYy1iYmItQS1h YWEtWC14eXoiIGlzIHdlbGwtZm9ybWVkIGJ1dCBub3QgaW4NCiAgIGNhbm9uaWNhbCBmb3JtLg0K DQogICBFeGFtcGxlOiBUaGUgbGFuZ3VhZ2UgdGFnICJlbi1CVSIgKEVuZ2xpc2ggYXMgdXNlZCBp biBCdXJtYSkgaXMgbm90DQogICBjYW5vbmljYWwgYmVjYXVzZSB0aGUgJ0JVJyBzdWJ0YWcgaGFz IGEgY2Fub25pY2FsIG1hcHBpbmcgdG8gJ01NJw0KICAgKE15YW5tYXIpLCBhbHRob3VnaCB0aGUg dGFnICJlbi1CVSIgbWFpbnRhaW5zIGl0cyB2YWxpZGl0eS4NCg0KICAgQ2Fub25pY2FsaXphdGlv biBvZiBsYW5ndWFnZSB0YWdzIGRvZXMgbm90IGltcGx5IGFueXRoaW5nIGFib3V0IHRoZQ0KICAg dXNlIG9mIHVwcGVyIG9yIGxvd2VyY2FzZSBsZXR0ZXJzIHdoZW4gcHJvY2Vzc2luZyBvciBjb21w YXJpbmcNCiAgIHN1YnRhZ3MgKGFuZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEpLiAgQWxs IGNvbXBhcmlzb25zIE1VU1QgYmUNCiAgIHBlcmZvcm1lZCBpbiBhIGNhc2UtaW5zZW5zaXRpdmUg bWFubmVyLg0KDQogICBXaGVuIHBlcmZvcm1pbmcgY2Fub25pY2FsaXphdGlvbiBvZiBsYW5ndWFn ZSB0YWdzLCBwcm9jZXNzb3JzIE1BWQ0KICAgcmVndWxhcml6ZSB0aGUgY2FzZSBvZiB0aGUgc3Vi dGFncyAodGhhdCBpcywgdGhpcyBwcm9jZXNzIGlzDQogICBPUFRJT05BTCksIGZvbGxvd2luZyB0 aGUgY2FzZSB1c2VkIGluIHRoZSByZWdpc3RyeS4gIE5vdGUgdGhhdCB0aGlzDQogICBjb3JyZXNw b25kcyB0byB0aGUgZm9sbG93aW5nIGNhc2luZyBydWxlczogdXBwZXJjYXNlIGFsbCBub24taW5p dGlhbA0KICAgdHdvLWxldHRlciBzdWJ0YWdzOyB0aXRsZWNhc2UgYWxsIG5vbi1pbml0aWFsIGZv dXItbGV0dGVyIHN1YnRhZ3M7DQogICBsb3dlcmNhc2UgZXZlcnl0aGluZyBlbHNlLg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAg ICAgICAgICBbUGFnZSA0NF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIE5vdGU6IENhc2Ug Zm9sZGluZyBvZiBBU0NJSSBsZXR0ZXJzIGluIGNlcnRhaW4gbG9jYWxlcywgdW5sZXNzDQogICBj YXJlZnVsbHkgaGFuZGxlZCwgc29tZXRpbWVzIHByb2R1Y2VzIG5vbi1BU0NJSSBjaGFyYWN0ZXIg dmFsdWVzLg0KICAgVGhlIFVuaWNvZGUgQ2hhcmFjdGVyIERhdGFiYXNlIGZpbGUgIlNwZWNpYWxD YXNpbmcudHh0IiBkZWZpbmVzIHRoZQ0KICAgc3BlY2lmaWMgY2FzZXMgdGhhdCBhcmUga25vd24g dG8gY2F1c2UgcHJvYmxlbXMgd2l0aCB0aGlzLiAgSW4NCiAgIHBhcnRpY3VsYXIsIHRoZSBsZXR0 ZXIgJ2knIChVKzAwNjkpIGluIFR1cmtpc2ggYW5kIEF6ZXJiYWlqYW5pIGlzDQogICB1cHBlcmNh c2VkIHRvIFUrMDEzMCAoTEFUSU4gQ0FQSVRBTCBMRVRURVIgSSBXSVRIIERPVCBBQk9WRSkuDQog ICBJbXBsZW1lbnRlcnMgU0hPVUxEIHNwZWNpZnkgYSBsb2NhbGUtbmV1dHJhbCBjYXNpbmcgb3Bl cmF0aW9uIHRvDQogICBlbnN1cmUgdGhhdCBjYXNlIGZvbGRpbmcgb2Ygc3VidGFncyBkb2VzIG5v dCBwcm9kdWNlIHRoaXMgdmFsdWUsDQogICB3aGljaCBpcyBpbGxlZ2FsIGluIGxhbmd1YWdlIHRh Z3MuICBGb3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8NCiAgIHVwcGVyY2FzZSB0aGUgcmVnaW9u IHN1YnRhZyAnaW4nIHVzaW5nIFR1cmtpc2ggbG9jYWxlIHJ1bGVzLCB0aGUNCiAgIHNlcXVlbmNl IFUrMDEzMCBVKzAwNEUgd291bGQgcmVzdWx0IGluc3RlYWQgb2YgdGhlIGV4cGVjdGVkICdJTicu DQoNCiAgIE5vdGU6IGlmIHRoZSBmaWVsZCAnRGVwcmVjYXRlZCcgYXBwZWFycyBpbiBhIHJlZ2lz dHJ5IHJlY29yZCB3aXRob3V0DQogICBhbiBhY2NvbXBhbnlpbmcgJ1ByZWZlcnJlZC1WYWx1ZScg ZmllbGQsIHRoZW4gdGhhdCB0YWcgb3Igc3VidGFnIGlzDQogICBkZXByZWNhdGVkIHdpdGhvdXQg YSByZXBsYWNlbWVudC4gIFZhbGlkYXRpbmcgcHJvY2Vzc29ycyBTSE9VTEQgTk9UDQogICBnZW5l cmF0ZSB0YWdzIHRoYXQgaW5jbHVkZSB0aGVzZSB2YWx1ZXMsIGFsdGhvdWdoIHRoZSB2YWx1ZXMg YXJlDQogICBjYW5vbmljYWwgd2hlbiB0aGV5IGFwcGVhciBpbiBhIGxhbmd1YWdlIHRhZy4NCg0K ICAgQW4gZXh0ZW5zaW9uIE1VU1QgZGVmaW5lIGFueSByZWxhdGlvbnNoaXBzIHRoYXQgZXhpc3Qg YmV0d2VlbiB0aGUNCiAgIHZhcmlvdXMgc3VidGFncyBpbiB0aGUgZXh0ZW5zaW9uIGFuZCB0aHVz IE1BWSBkZWZpbmUgYW4gYWx0ZXJuYXRlDQogICBjYW5vbmljYWxpemF0aW9uIHNjaGVtZSBmb3Ig dGhlIGV4dGVuc2lvbidzIHN1YnRhZ3MuICBFeHRlbnNpb25zIE1BWQ0KICAgZGVmaW5lIGhvdyB0 aGUgb3JkZXIgb2YgdGhlIGV4dGVuc2lvbidzIHN1YnRhZ3MgYXJlIGludGVycHJldGVkLiAgRm9y DQogICBleGFtcGxlLCBhbiBleHRlbnNpb24gY291bGQgZGVmaW5lIHRoYXQgaXRzIHN1YnRhZ3Mg YXJlIGluIGNhbm9uaWNhbA0KICAgb3JkZXIgd2hlbiB0aGUgc3VidGFncyBhcmUgcGxhY2VkIGlu dG8gQVNDSUkgb3JkZXI6IHRoYXQgaXMsICJlbi1hLQ0KICAgYWFhLWJiYi1jY2MiIGluc3RlYWQg b2YgImVuLWEtY2NjLWJiYi1hYWEiLiAgQW5vdGhlciBleHRlbnNpb24gbWlnaHQNCiAgIGRlZmlu ZSB0aGF0IHRoZSBvcmRlciBvZiB0aGUgc3VidGFncyBpbmZsdWVuY2VzIHRoZWlyIHNlbWFudGlj DQogICBtZWFuaW5nIChzbyB0aGF0ICJlbi1iLWNjYy1iYmItYWFhIiBoYXMgYSBkaWZmZXJlbnQg dmFsdWUgZnJvbSAiZW4tYi0NCiAgIGFhYS1iYmItY2NjIikuICBIb3dldmVyLCBleHRlbnNpb24g c3BlY2lmaWNhdGlvbnMgU0hPVUxEIGJlIGRlc2lnbmVkDQogICBzbyB0aGF0IHRoZXkgYXJlIHRv bGVyYW50IG9mIHRoZSB0eXBpY2FsIHByb2Nlc3NlcyBkZXNjcmliZWQgaW4NCiAgIFNlY3Rpb24g My43Lg0KDQo0LjUgIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRlIFVzZSBTdWJ0YWdzDQoNCiAg IFByaXZhdGUgdXNlIHN1YnRhZ3MsIGxpa2UgYWxsIG90aGVyIHN1YnRhZ3MsIE1VU1QgY29uZm9y bSB0byB0aGUNCiAgIGZvcm1hdCBhbmQgY29udGVudCBjb25zdHJhaW50cyBpbiB0aGUgQUJORi4g IFByaXZhdGUgdXNlIHN1YnRhZ3MgaGF2ZQ0KICAgbm8gbWVhbmluZyBvdXRzaWRlIHRoZSBwcml2 YXRlIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBwYXJ0aWVzIHRoYXQNCiAgIGludGVuZCB0byB1c2Ug b3IgZXhjaGFuZ2UgbGFuZ3VhZ2UgdGFncyB0aGF0IGVtcGxveSB0aGVtLiAgVGhlIHNhbWUNCiAg IHN1YnRhZ3MgTUFZIGJlIHVzZWQgd2l0aCBhIGRpZmZlcmVudCBtZWFuaW5nIHVuZGVyIGEgc2Vw YXJhdGUgcHJpdmF0ZQ0KICAgYWdyZWVtZW50LiAgVGhleSBTSE9VTEQgTk9UIGJlIHVzZWQgd2hl cmUgYWx0ZXJuYXRpdmVzIGV4aXN0IGFuZA0KICAgU0hPVUxEIE5PVCBiZSB1c2VkIGluIGNvbnRl bnQgb3IgcHJvdG9jb2xzIGludGVuZGVkIGZvciBnZW5lcmFsIHVzZS4NCg0KICAgUHJpdmF0ZSB1 c2Ugc3VidGFncyBhcmUgc2ltcGx5IHVzZWxlc3MgZm9yIGluZm9ybWF0aW9uIGV4Y2hhbmdlDQog ICB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50LiAgVGhlIHZhbHVlIGFuZCBzZW1hbnRpYyBtZWFu aW5nIG9mIHByaXZhdGUNCiAgIHVzZSB0YWdzIGFuZCBvZiB0aGUgc3VidGFncyB1c2VkIHdpdGhp biBzdWNoIGEgbGFuZ3VhZ2UgdGFnIGFyZSBub3QNCiAgIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVu dC4NCg0KICAgU3VidGFncyBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIGhhdmluZyBh IHNwZWNpZmljIHByaXZhdGUgdXNlDQogICBtZWFuaW5nIGNvbnZleSBtb3JlIGluZm9ybWF0aW9u IHRoYXQgYSBwdXJlbHkgcHJpdmF0ZSB1c2UgdGFnDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA0NV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIHByZWZpeGVkIGJ5IHRoZSBzaW5nbGV0b24gc3VidGFn ICd4Jy4gIEZvciBhcHBsaWNhdGlvbnMgdGhpcw0KICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBN QVkgYmUgdXNlZnVsLg0KDQogICBGb3IgZXhhbXBsZSwgdGhlIHJlZ2lvbiBzdWJ0YWdzICdBQScs ICdaWicgYW5kIGluIHRoZSByYW5nZXMNCiAgICdRTSctJ1FaJyBhbmQgJ1hBJy0nWFonIChkZXJp dmVkIGZyb20gSVNPIDMxNjYgcHJpdmF0ZSB1c2UgY29kZXMpIE1BWQ0KICAgYmUgdXNlZCB0byBm b3JtIGEgbGFuZ3VhZ2UgdGFnLiAgQSB0YWcgc3VjaCBhcyAiemgtSGFucy1YUSIgY29udmV5cyBh DQogICBncmVhdCBkZWFsIG9mIHB1YmxpYywgaW50ZXJjaGFuZ2VhYmxlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBsYW5ndWFnZQ0KICAgbWF0ZXJpYWwgKHRoYXQgaXQgaXMgQ2hpbmVzZSBpbiB0aGUg c2ltcGxpZmllZCBDaGluZXNlIHNjcmlwdCBhbmQgaXMNCiAgIHN1aXRhYmxlIGZvciBzb21lIGdl b2dyYXBoaWMgcmVnaW9uICdYUScpLiAgV2hpbGUgdGhlIHByZWNpc2UNCiAgIGdlb2dyYXBoaWMg cmVnaW9uIGlzIG5vdCBrbm93biBvdXRzaWRlIG9mIHByaXZhdGUgYWdyZWVtZW50LCB0aGUgdGFn DQogICBjb252ZXlzIGZhciBtb3JlIGluZm9ybWF0aW9uIHRoYW4gYW4gb3BhcXVlIHRhZyBzdWNo IGFzICJ4LXNvbWVMYW5nIiwNCiAgIHdoaWNoIGNvbnRhaW5zIG5vIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBsYW5ndWFnZSBzdWJ0YWcgb3Igc2NyaXB0DQogICBzdWJ0YWcgb3V0c2lkZSBvZiB0aGUg cHJpdmF0ZSBhZ3JlZW1lbnQuDQoNCiAgIEhvd2V2ZXIsIGluIHNvbWUgY2FzZXMgY29udGVudCB0 YWdnZWQgd2l0aCBwcml2YXRlIHVzZSBzdWJ0YWdzIE1BWQ0KICAgaW50ZXJhY3Qgd2l0aCBvdGhl ciBzeXN0ZW1zIGluIGEgZGlmZmVyZW50IGFuZCBwb3NzaWJseSB1bnN1aXRhYmxlDQogICBtYW5u ZXIgY29tcGFyZWQgdG8gdGFncyB0aGF0IHVzZSBvcGFxdWUsIHByaXZhdGVseSBkZWZpbmVkIHN1 YnRhZ3MsDQogICBzbyB0aGUgY2hvaWNlIG9mIHRoZSBiZXN0IGFwcHJvYWNoIHNvbWV0aW1lcyBk ZXBlbmRzIG9uIHRoZQ0KICAgcGFydGljdWxhciBkb21haW4gaW4gcXVlc3Rpb24uDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAg ICAgICAgW1BhZ2UgNDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQo1LiAgSUFOQSBDb25zaWRl cmF0aW9ucw0KDQogICBUaGlzIHNlY3Rpb24gZGVhbHMgd2l0aCB0aGUgcHJvY2Vzc2VzIGFuZCBy ZXF1aXJlbWVudHMgbmVjZXNzYXJ5IGZvcg0KICAgSUFOQSB0byB1bmRlcnRha2UgdG8gbWFpbnRh aW4gdGhlIHN1YnRhZyBhbmQgZXh0ZW5zaW9uIHJlZ2lzdHJpZXMgYXMNCiAgIGRlZmluZWQgYnkg dGhpcyBkb2N1bWVudCBhbmQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSByZXF1aXJlbWVudHMgb2YN CiAgIFtSRkMyNDM0XS4NCg0KICAgVGhlIGltcGFjdCBvbiB0aGUgSUFOQSBtYWludGFpbmVycyBv ZiB0aGUgdHdvIHJlZ2lzdHJpZXMgZGVmaW5lZCBieQ0KICAgdGhpcyBkb2N1bWVudCB3aWxsIGJl IGEgc21hbGwgaW5jcmVhc2UgaW4gdGhlIGZyZXF1ZW5jeSBvZiBuZXcNCiAgIGVudHJpZXMgb3Ig dXBkYXRlcy4NCg0KNS4xICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkNCg0KICAgVXBvbiBhZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50LCB0aGUgcmVnaXN0cnkgd2lsbCBiZSBpbml0aWFsaXplZCBi eSBhDQogICBjb21wYW5pb24gZG9jdW1lbnQ6IFtpbml0aWFsLXJlZ2lzdHJ5XS4gIFRoZSBjcml0 ZXJpYSBhbmQgcHJvY2VzcyBmb3INCiAgIHNlbGVjdGluZyB0aGUgaW5pdGlhbCBzZXQgb2YgcmVj b3JkcyBpcyBkZXNjcmliZWQgaW4gdGhhdCBkb2N1bWVudC4NCiAgIFRoZSBpbml0aWFsIHNldCBv ZiByZWNvcmRzIHJlcHJlc2VudHMgbm8gaW1wYWN0IG9uIElBTkEsIHNpbmNlIHRoZQ0KICAgd29y ayB0byBjcmVhdGUgaXQgd2lsbCBiZSBwZXJmb3JtZWQgZXh0ZXJuYWxseS4NCg0KICAgVGhlIG5l dyByZWdpc3RyeSBNVVNUIGJlIGxpc3RlZCB1bmRlciAiTGFuZ3VhZ2UgVGFncyIgYXQNCiAgIDxo dHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbD4sIHJlcGxhY2luZyB0aGUgZXhpc3RpbmcN CiAgIHJlZ2lzdHJhdGlvbnMgZGVmaW5lZCBieSBbUkZDMzA2Nl0uICBUaGUgZXhpc3Rpbmcgc2V0 IG9mIHJlZ2lzdHJhdGlvbg0KICAgZm9ybXMgYW5kIFJGQyAzMDY2IHJlZ2lzdHJhdGlvbnMgTVVT VCBiZSByZWxhYmVsZWQgYXMgIkxhbmd1YWdlIFRhZ3MNCiAgIChPYnNvbGV0ZSkiIGFuZCBtYWlu dGFpbmVkIChidXQgbm90IGFkZGVkIHRvIG9yIG1vZGlmaWVkKS4NCg0KICAgRnV0dXJlIHdvcmsg b24gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBTSEFMTCBiZSBsaW1pdGVkIHRvDQogICBp bnNlcnRpbmcgb3IgcmVwbGFjaW5nIHdob2xlIHJlY29yZHMgcHJlZm9ybWF0dGVkIGZvciBJQU5B IGJ5IHRoZQ0KICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDMuMyBvZiB0aGlzIGRvY3VtZW50DQogICBhbmQgYXJjaGl2aW5nIHRoZSBmb3J3YXJkZWQg cmVnaXN0cmF0aW9uIGZvcm0uDQoNCiAgIEVhY2ggcmVjb3JkIE1VU1QgYmUgc2VudCB0byBpYW5h QGlhbmEub3JnIHdpdGggYSBzdWJqZWN0IGxpbmUNCiAgIGluZGljYXRpbmcgd2hldGhlciB0aGUg ZW5jbG9zZWQgcmVjb3JkIGlzIGFuIGluc2VydGlvbiBvZiBhIG5ldw0KICAgcmVjb3JkIChpbmRp Y2F0ZWQgYnkgdGhlIHdvcmQgIklOU0VSVCIgaW4gdGhlIHN1YmplY3QgbGluZSkgb3IgYQ0KICAg cmVwbGFjZW1lbnQgb2YgYW4gZXhpc3RpbmcgcmVjb3JkIChpbmRpY2F0ZWQgYnkgdGhlIHdvcmQg Ik1PRElGWSIgaW4NCiAgIHRoZSBzdWJqZWN0IGxpbmUpLiAgUmVjb3JkcyBNVVNUIE5PVCBiZSBk ZWxldGVkIGZyb20gdGhlIHJlZ2lzdHJ5Lg0KICAgSUFOQSBNVVNUIHBsYWNlIGFueSBpbnNlcnRl ZCBvciBtb2RpZmllZCByZWNvcmRzIGludG8gdGhlIGFwcHJvcHJpYXRlDQogICBzZWN0aW9uIG9m IHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnksIGdyb3VwaW5nIHRoZSByZWNvcmRzIGJ5DQog ICB0aGVpciAnVHlwZScgZmllbGQuICBJbnNlcnRlZCByZWNvcmRzIE1BWSBiZSBwbGFjZWQgYW55 d2hlcmUgaW4gdGhlDQogICBhcHByb3ByaWF0ZSBzZWN0aW9uOyB0aGVyZSBpcyBubyBndWFyYW50 ZWUgb2YgdGhlIG9yZGVyIG9mIHRoZQ0KICAgcmVjb3JkcyBiZXlvbmQgZ3JvdXBpbmcgdGhlbSB0 b2dldGhlciBieSAnVHlwZScuICBNb2RpZmllZCByZWNvcmRzDQogICBNVVNUIG92ZXJ3cml0ZSB0 aGUgcmVjb3JkIHRoZXkgcmVwbGFjZS4NCg0KICAgSW5jbHVkZWQgaW4gYW55IHJlcXVlc3QgdG8g aW5zZXJ0IG9yIG1vZGlmeSByZWNvcmRzIE1VU1QgYmUgYSBuZXcNCiAgIEZpbGUtRGF0ZSByZWNv cmQuICBUaGlzIHJlY29yZCBNVVNUIGJlIHBsYWNlZCBmaXJzdCBpbiB0aGUgcmVnaXN0cnkuDQog ICBJbiB0aGUgZXZlbnQgdGhhdCB0aGUgRmlsZS1EYXRlIHJlY29yZCBwcmVzZW50IGluIHRoZSBy ZWdpc3RyeSBoYXMgYQ0KICAgbGF0ZXIgZGF0ZSB0aGVuIHRoZSByZWNvcmQgYmVpbmcgaW5zZXJ0 ZWQgb3IgbW9kaWZpZWQsIHRoZSBleGlzdGluZw0KICAgcmVjb3JkIE1VU1QgYmUgcHJlc2VydmVk Lg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAw NiAgICAgICAgICAgICAgICBbUGFnZSA0N10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCjUuMiAg RXh0ZW5zaW9ucyBSZWdpc3RyeQ0KDQogICBUaGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgcmVn aXN0cnkgd2lsbCBhbHNvIGJlIGdlbmVyYXRlZCBhbmQgc2VudA0KICAgdG8gSUFOQSBhcyBkZXNj cmliZWQgaW4gU2VjdGlvbiAzLjcuICBUaGlzIHJlZ2lzdHJ5IGNhbiBjb250YWluIGF0DQogICBt b3N0IDM1IHJlY29yZHMgYW5kIHRodXMgY2hhbmdlcyB0byB0aGlzIHJlZ2lzdHJ5IGFyZSBleHBl Y3RlZCB0byBiZQ0KICAgdmVyeSBpbmZyZXF1ZW50Lg0KDQogICBGdXR1cmUgd29yayBieSBJQU5B IG9uIHRoZSBMYW5ndWFnZSBUYWcgRXh0ZW5zaW9ucyBSZWdpc3RyeSBpcw0KICAgbGltaXRlZCB0 byB0d28gY2FzZXMuICBGaXJzdCwgdGhlIElFU0cgTUFZIHJlcXVlc3QgdGhhdCBuZXcgcmVjb3Jk cw0KICAgYmUgaW5zZXJ0ZWQgaW50byB0aGlzIHJlZ2lzdHJ5IGZyb20gdGltZSB0byB0aW1lLiAg VGhlc2UgcmVxdWVzdHMNCiAgIE1VU1QgaW5jbHVkZSB0aGUgcmVjb3JkIHRvIGluc2VydCBpbiB0 aGUgZXhhY3QgZm9ybWF0IGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjcuICBJbiBhZGRpdGlv biwgdGhlcmUgTUFZIGJlIG9jY2FzaW9uYWwgcmVxdWVzdHMgZnJvbSB0aGUNCiAgIG1haW50YWlu aW5nIGF1dGhvcml0eSBmb3IgYSBzcGVjaWZpYyBleHRlbnNpb24gdG8gdXBkYXRlIHRoZSBjb250 YWN0DQogICBpbmZvcm1hdGlvbiBvciBVUkxzIGluIHRoZSByZWNvcmQuICBUaGVzZSByZXF1ZXN0 cyBNVVNUIGluY2x1ZGUgdGhlDQogICBjb21wbGV0ZSwgdXBkYXRlZCByZWNvcmQuICBJQU5BIGlz IG5vdCByZXNwb25zaWJsZSBmb3IgdmFsaWRhdGluZyB0aGUNCiAgIGluZm9ybWF0aW9uIHByb3Zp ZGVkLCBvbmx5IHRoYXQgaXQgaXMgcHJvcGVybHkgZm9ybWF0dGVkLiAgSXQgc2hvdWxkDQogICBy ZWFzb25hYmx5IGJlIHNlZW4gdG8gY29tZSBmcm9tIHRoZSBtYWludGFpbmluZyBhdXRob3JpdHkg bmFtZWQgaW4NCiAgIHRoZSByZWNvcmQgcHJlc2VudCBpbiB0aGUgcmVnaXN0cnkuDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAg ICAgICAgICBbUGFnZSA0OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCjYuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucw0KDQogICBMYW5ndWFnZSB0YWdzIHVzZWQgaW4gY29udGVudCBuZWdvdGlh dGlvbiwgbGlrZSBhbnkgb3RoZXIgaW5mb3JtYXRpb24NCiAgIGV4Y2hhbmdlZCBvbiB0aGUgSW50 ZXJuZXQsIG1pZ2h0IGJlIGEgc291cmNlIG9mIGNvbmNlcm4gYmVjYXVzZSB0aGV5DQogICBtaWdo dCBiZSB1c2VkIHRvIGluZmVyIHRoZSBuYXRpb25hbGl0eSBvZiB0aGUgc2VuZGVyLCBhbmQgdGh1 cw0KICAgaWRlbnRpZnkgcG90ZW50aWFsIHRhcmdldHMgZm9yIHN1cnZlaWxsYW5jZS4NCg0KICAg VGhpcyBpcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhp bmcgc2VudCBpcw0KICAgdmlzaWJsZSB0byB0aGUgcmVjZWl2aW5nIHBhcnR5IGFuZCBwb3NzaWJs eSB0byB0aGlyZCBwYXJ0aWVzIGFzIHdlbGwuDQogICBJdCBpcyB1c2VmdWwgdG8gYmUgYXdhcmUg dGhhdCBzdWNoIGNvbmNlcm5zIGNhbiBleGlzdCBpbiBzb21lIGNhc2VzLg0KDQogICBUaGUgZXZh bHVhdGlvbiBvZiB0aGUgZXhhY3QgbWFnbml0dWRlIG9mIHRoZSB0aHJlYXQsIGFuZCBhbnkgcG9z c2libGUNCiAgIGNvdW50ZXJtZWFzdXJlcywgaXMgbGVmdCB0byBlYWNoIGFwcGxpY2F0aW9uIHBy b3RvY29sIChzZWUgQkNQIDcyDQogICBbUkZDMzU1Ml0gZm9yIGJlc3QgY3VycmVudCBwcmFjdGlj ZSBndWlkYW5jZSBvbiBzZWN1cml0eSB0aHJlYXRzIGFuZA0KICAgZGVmZW5zZXMpLg0KDQogICBU aGUgbGFuZ3VhZ2UgdGFnIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgaW5mb3JtYXRpb24g aXRlbSBpcyBvZg0KICAgbm8gY29uc2VxdWVuY2Ugd2hhdHNvZXZlciBpbiBkZXRlcm1pbmluZyB3 aGV0aGVyIHRoYXQgY29udGVudCBtaWdodA0KICAgY29udGFpbiBwb3NzaWJsZSBob21vZ3JhcGhz LiAgVGhlIGZhY3QgdGhhdCBhIHRleHQgaXMgdGFnZ2VkIGFzIGJlaW5nDQogICBpbiBvbmUgbGFu Z3VhZ2Ugb3IgdXNpbmcgYSBwYXJ0aWN1bGFyIHNjcmlwdCBzdWJ0YWcgcHJvdmlkZXMgbm8NCiAg IGFzc3VyYW5jZSB3aGF0c29ldmVyIHRoYXQgaXQgZG9lcyBub3QgY29udGFpbiBjaGFyYWN0ZXJz IGZyb20gc2NyaXB0cw0KICAgb3RoZXIgdGhhbiB0aGUgb25lKHMpIGFzc29jaWF0ZWQgd2l0aCBv ciBzcGVjaWZpZWQgYnkgdGhhdCBsYW5ndWFnZQ0KICAgdGFnLg0KDQogICBTaW5jZSB0aGVyZSBp cyBubyBsaW1pdCB0byB0aGUgbnVtYmVyIG9mIHZhcmlhbnQsIHByaXZhdGUgdXNlLCBhbmQNCiAg IGV4dGVuc2lvbiBzdWJ0YWdzLCBhbmQgY29uc2VxdWVudGx5IG5vIGxpbWl0IG9uIHRoZSBwb3Nz aWJsZSBsZW5ndGgNCiAgIG9mIGEgdGFnLCBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBndWFyZCBh Z2FpbnN0IGJ1ZmZlciBvdmVyZmxvdw0KICAgYXR0YWNrcy4gIFNlZSBTZWN0aW9uIDQuMyBmb3Ig ZGV0YWlscyBvbiBsYW5ndWFnZSB0YWcgdHJ1bmNhdGlvbiwNCiAgIHdoaWNoIGNhbiBvY2N1ciBh cyBhIGNvbnNlcXVlbmNlIG9mIGRlZmVuc2VzIGFnYWluc3QgYnVmZmVyIG92ZXJmbG93Lg0KDQog ICBBbHRob3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBvZiB2YWxpZCBzdWJ0YWdzIGZvciBhbiBleHRl bnNpb24gKHNlZToNCiAgIFNlY3Rpb24gMy43KSBNVVNUIGJlIGF2YWlsYWJsZSBvdmVyIHRoZSBJ bnRlcm5ldCwgaW1wbGVtZW50YXRpb25zDQogICBTSE9VTEQgTk9UIG1lY2hhbmljYWxseSBkZXBl bmQgb24gaXQgYmVpbmcgYWx3YXlzIGFjY2Vzc2libGUsIHRvDQogICBwcmV2ZW50IGRlbmlhbC1v Zi1zZXJ2aWNlIGF0dGFja3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAg ICAgW1BhZ2UgNDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQo3LiAgQ2hhcmFjdGVyIFNldCBD b25zaWRlcmF0aW9ucw0KDQogICBUaGUgc3ludGF4IGluIHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMg dGhhdCBsYW5ndWFnZSB0YWdzIHVzZSBvbmx5IHRoZQ0KICAgY2hhcmFjdGVycyBBLVosIGEteiwg MC05LCBhbmQgSFlQSEVOLU1JTlVTLCB3aGljaCBhcmUgcHJlc2VudCBpbiBtb3N0DQogICBjaGFy YWN0ZXIgc2V0cywgc28gdGhlIGNvbXBvc2l0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgc2hvdWxkIG5v dCBoYXZlDQogICBhbnkgY2hhcmFjdGVyIHNldCBpc3N1ZXMuDQoNCiAgIFJlbmRlcmluZyBvZiBj aGFyYWN0ZXJzIGJhc2VkIG9uIHRoZSBjb250ZW50IG9mIGEgbGFuZ3VhZ2UgdGFnIGlzIG5vdA0K ICAgYWRkcmVzc2VkIGluIHRoaXMgbWVtby4gIEhpc3RvcmljYWxseSwgc29tZSBsYW5ndWFnZXMg aGF2ZSByZWxpZWQgb24NCiAgIHRoZSB1c2Ugb2Ygc3BlY2lmaWMgY2hhcmFjdGVyIHNldHMgb3Ig b3RoZXIgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8NCiAgIGluZmVyIGhvdyBhIHNwZWNpZmljIGNo YXJhY3RlciBzaG91bGQgYmUgcmVuZGVyZWQgKG5vdGFibHkgdGhpcw0KICAgYXBwbGllcyB0byBs YW5ndWFnZSBhbmQgY3VsdHVyZSBzcGVjaWZpYyB2YXJpYXRpb25zIG9mIEhhbiBpZGVvZ3JhcGhz DQogICBhcyB1c2VkIGluIEphcGFuZXNlLCBDaGluZXNlLCBhbmQgS29yZWFuKS4gIFdoZW4gbGFu Z3VhZ2UgdGFncyBhcmUNCiAgIGFwcGxpZWQgdG8gc3BhbnMgb2YgdGV4dCwgcmVuZGVyaW5nIGVu Z2luZXMgc29tZXRpbWVzIHVzZSB0aGF0DQogICBpbmZvcm1hdGlvbiBpbiBkZWNpZGluZyB3aGlj aCBmb250IHRvIHVzZSBpbiB0aGUgYWJzZW5jZSBvZiBvdGhlcg0KICAgaW5mb3JtYXRpb24sIHBh cnRpY3VsYXJseSB3aGVyZSBsYW5ndWFnZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5nDQogICB0cmFk aXRpb25zIHVzZSB0aGUgc2FtZSBjaGFyYWN0ZXJzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA1 MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCjguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYNCg0K ICAgVGhlIG1haW4gZ29hbHMgZm9yIHRoaXMgcmV2aXNpb24gb2YgbGFuZ3VhZ2UgdGFncyB3ZXJl IHRoZSBmb2xsb3dpbmc6DQoNCiAgICpDb21wYXRpYmlsaXR5LiogQWxsIFJGQyAzMDY2IGxhbmd1 YWdlIHRhZ3MgIChpbmNsdWRpbmcgdGhvc2UgaW4gdGhlDQogICBJQU5BIHJlZ2lzdHJ5KSAgcmVt YWluIHZhbGlkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBjaGFuZ2VzIGluDQogICB0aGlz IGRvY3VtZW50IHJlcHJlc2VudCBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIG9uIGxhbmd1YWdlIHRh Z3MuDQogICBUaGF0IGlzLCBpbiBubyBjYXNlIGlzIHRoZSBzeW50YXggbW9yZSBwZXJtaXNzaXZl IGFuZCBwcm9jZXNzb3JzDQogICBiYXNlZCBvbiB0aGUgQUJORiBhbmQgb3RoZXIgcHJvdmlzaW9u cyBvZiBSRkMgMzA2NiAoc3VjaCBhcyB0aG9zZQ0KICAgZGVzY3JpYmVkIGluIFtYTUxTY2hlbWFd KSB3aWxsIGJlIGFibGUgdG8gcHJvY2VzcyB0aGUgdGFncyBkZXNjcmliZWQNCiAgIGJ5IHRoaXMg ZG9jdW1lbnQuICBJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGxhbmd1YWdlIHRh Z3MNCiAgIGluIHN1Y2ggYXMgd2F5IGFzIHRvIGVuc3VyZSBmdXR1cmUgY29tcGF0aWJpbGl0eS4N Cg0KICAgKlN0YWJpbGl0eS4qIEJlY2F1c2Ugb2YgY2hhbmdlcyBpbiB0aGUgcGFzdCBpbiB0aGUg dW5kZXJseWluZyBJU08NCiAgIHN0YW5kYXJkcywgYSB2YWxpZCBSRkMgMzA2NiBsYW5ndWFnZSB0 YWcgY291bGQgYmVjb21lIGludmFsaWQgb3IgaGF2ZQ0KICAgaXRzIG1lYW5pbmcgY2hhbmdlLiAg VGhpcyBoYXMgdGhlIHBvdGVudGlhbCBvZiBpbnZhbGlkYXRpbmcgY29udGVudA0KICAgdGhhdCBt YXkgaGF2ZSBhbiBleHRlbnNpdmUgc2hlbGYtbGlmZS4gIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwg b25jZSBhDQogICBsYW5ndWFnZSB0YWcgaXMgdmFsaWQsIGl0IHJlbWFpbnMgdmFsaWQgZm9yZXZl ci4NCg0KICAgKlZhbGlkaXR5LiogIFRoZSBzdHJ1Y3R1cmUgb2YgbGFuZ3VhZ2UgdGFncyBkZWZp bmVkIGJ5IHRoaXMgZG9jdW1lbnQNCiAgIG1ha2VzIGl0IHBvc3NpYmxlIHRvIGRldGVybWluZSBp ZiBhIHBhcnRpY3VsYXIgdGFnIGlzIHdlbGwtZm9ybWVkDQogICB3aXRob3V0IHJlZ2FyZCBmb3Ig dGhlIGFjdHVhbCBjb250ZW50IG9yICJtZWFuaW5nIiBvZiB0aGUgdGFnIGFzIGENCiAgIHdob2xl LiAgVGhpcyBpcyBpbXBvcnRhbnQgYmVjYXVzZSB0aGUgcmVnaXN0cnkgZ3Jvd3MgYW5kIHVuZGVy bHlpbmcNCiAgIHN0YW5kYXJkcyBjaGFuZ2Ugb3ZlciB0aW1lLiAgSW4gYWRkaXRpb24sIGl0IG11 c3QgYmUgcG9zc2libGUgdG8NCiAgIGRldGVybWluZSBpZiBhIHRhZyBpcyB2YWxpZCAob3Igbm90 KSBmb3IgYSBnaXZlbiBwb2ludCBpbiB0aW1lIGluDQogICBvcmRlciB0byBwcm92aWRlIHJlcHJv ZHVjaWJsZSwgdGVzdGFibGUgcmVzdWx0cy4gIFRoaXMgcHJvY2VzcyBtdXN0DQogICBub3QgYmUg ZXJyb3ItcHJvbmU7IG90aGVyd2lzZSBpbXBsZW1lbnRhdGlvbnMgbWlnaHQgZ2l2ZSBkaWZmZXJl bnQNCiAgIHJlc3VsdHMuICBCeSBoYXZpbmcgYW4gYXV0aG9yaXRhdGl2ZSByZWdpc3RyeSB3aXRo IHNwZWNpZmljDQogICB2ZXJzaW9uaW5nIGluZm9ybWF0aW9uLCB0aGUgdmFsaWRpdHkgb2YgbGFu Z3VhZ2UgdGFncyBhdCBhbnkgcG9pbnQgaW4NCiAgIHRpbWUgY2FuIGJlIHByZWNpc2VseSBkZXRl cm1pbmVkIChpbnN0ZWFkIG9mIGludGVycG9sYXRpbmcgdmFsdWVzDQogICBmcm9tIG1hbnkgc2Vw YXJhdGUgc291cmNlcykuDQoNCiAgICpVdGlsaXR5LiogSXQgaXMgc29tZXRpbWVzIGltcG9ydGFu dCB0byBiZSBhYmxlIHRvIGRpZmZlcmVudGlhdGUNCiAgIGJldHdlZW4gd3JpdHRlbiBmb3JtcyBv ZiBhIGxhbmd1YWdlIC0tIGZvciBtYW55IGltcGxlbWVudGF0aW9ucyB0aGlzDQogICBpcyBtb3Jl IGltcG9ydGFudCB0aGFuIGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gdGhlIHNwb2tlbiB2YXJpYW50 cyBvZg0KICAgYSBsYW5ndWFnZS4gIExhbmd1YWdlcyBhcmUgd3JpdHRlbiBpbiBhIHdpZGUgdmFy aWV0eSBvZiBkaWZmZXJlbnQNCiAgIHNjcmlwdHMsIHNvIHRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg Zm9yIHRoZSBnZW5lcmF0aXZlIHVzZSBvZiBJU08NCiAgIDE1OTI0IHNjcmlwdCBjb2Rlcy4gIExp a2UgdGhlIGdlbmVyYXRpdmUgdXNlIG9mIElTTyBsYW5ndWFnZSBhbmQNCiAgIGNvdW50cnkgY29k ZXMgaW4gUkZDIDMwNjYsIHRoaXMgYWxsb3dzIGNvbWJpbmF0aW9ucyB0byBiZSBwcm9kdWNlZA0K ICAgd2l0aG91dCByZXNvcnRpbmcgdG8gdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiAgVGhlIGFk ZGl0aW9uIG9mIFVODQogICBNLjQ5IGNvZGVzIHByb3ZpZGVzIGZvciB0aGUgZ2VuZXJhdGlvbiBv ZiBsYW5ndWFnZSB0YWdzIHdpdGggcmVnaW9uYWwNCiAgIHNjb3BlLCB3aGljaCBpcyBhbHNvIHJl cXVpcmVkIGJ5IHNvbWUgYXBwbGljYXRpb25zLg0KDQogICBUaGUgcmVjYXN0IG9mIHRoZSByZWdp c3RyeSBmcm9tIGNvbnRhaW5pbmcgd2hvbGUgbGFuZ3VhZ2UgdGFncyB0bw0KICAgc3VidGFncyBp cyBhIGtleSBwYXJ0IG9mIHRoaXMuICBBbiBpbXBvcnRhbnQgZmVhdHVyZSBvZiBSRkMgMzA2NiB3 YXMNCiAgIHRoYXQgaXQgYWxsb3dlZCBnZW5lcmF0aXZlIHVzZSBvZiBzdWJ0YWdzLiAgVGhpcyBh bGxvd3MgcGVvcGxlIHRvDQogICBtZWFuaW5nZnVsbHkgdXNlIGdlbmVyYXRlZCB0YWdzLCB3aXRo b3V0IHRoZSBkZWxheXMgaW4gcmVnaXN0ZXJpbmcNCiAgIHdob2xlIHRhZ3Mgb3IgdGhlIG5lZWQg dG8gcmVnaXN0ZXIgYWxsIG9mIHRoZSBjb21iaW5hdGlvbnMgdGhhdCBtaWdodA0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAg ICAgW1BhZ2UgNTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBiZSB1c2VmdWwuDQoNCiAg IFRoZSBjaG9pY2Ugb2YgcGxhY2luZyB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2UgYW5kIHNjcmlwdCBz dWJ0YWdzDQogICBiZXR3ZWVuIHRoZSBwcmltYXJ5IGxhbmd1YWdlIGFuZCByZWdpb24gc3VidGFn cyB3YXMgd2lkZWx5IGRlYmF0ZWQuDQogICBUaGlzIGRlc2lnbiB3YXMgY2hvc2VuIGJlY2F1c2Ug dGhlIHByZXZhbGVudCBtYXRjaGluZyBhbmQgY29udGVudA0KICAgbmVnb3RpYXRpb24gc2NoZW1l cyByZWx5IG9uIHRoZSBzdWJ0YWdzIGJlaW5nIGFycmFuZ2VkIGluIG9yZGVyIG9mDQogICBpbmNy ZWFzaW5nIHNwZWNpZmljaXR5LiAgVGhhdCBpcywgdGhlIHN1YnRhZ3MgdGhhdCBtYXJrIGEgZ3Jl YXRlcg0KICAgYmFycmllciB0byBtdXR1YWwgaW50ZWxsaWdpYmlsaXR5IGFwcGVhciBsZWZ0LW1v c3QgaW4gYSB0YWcuICBGb3INCiAgIGV4YW1wbGUsIHdoZW4gc2VsZWN0aW5nIGNvbnRlbnQgd3Jp dHRlbiBpbiBBemVyYmFpamFuaSwgdGhlIHNjcmlwdA0KICAgKEFyYWJpYywgQ3lyaWxsaWMsIG9y IExhdGluKSByZXByZXNlbnRzIGEgZ3JlYXRlciBiYXJyaWVyIHRvDQogICB1bmRlcnN0YW5kaW5n IHRoYW4gYW55IHJlZ2lvbmFsIHZhcmlhdGlvbnMgKHRob3NlIGFzc29jaWF0ZWQgd2l0aA0KICAg QXplcmJhaWphbiBvciBJcmFuLCBmb3IgZXhhbXBsZSkuICBJbmRpdmlkdWFscyB3aG8gcHJlZmVy IGRvY3VtZW50cw0KICAgaW4gYSBwYXJ0aWN1bGFyIHNjcmlwdCwgYnV0IGNhbiBkZWFsIHdpdGgg dGhlIG1pbm9yIHJlZ2lvbmFsDQogICBkaWZmZXJlbmNlcywgY2FuIHRoZXJlZm9yZSBzZWxlY3Qg YXBwcm9wcmlhdGUgY29udGVudC4gIEFwcGxpY2F0aW9ucw0KICAgdGhhdCBkbyBub3QgZGVhbCB3 aXRoIHdyaXR0ZW4gY29udGVudCB3aWxsIGNvbnRpbnVlIHRvIG9taXQgdGhlc2UNCiAgIHN1YnRh Z3MuDQoNCiAgICpFeHRlbnNpYmlsaXR5LiogQmVjYXVzZSBvZiB0aGUgd2lkZXNwcmVhZCB1c2Ug b2YgbGFuZ3VhZ2UgdGFncywgaXQNCiAgIGlzIGRpc3J1cHRpdmUgdG8gaGF2ZSBwZXJpb2RpYyBy ZXZpc2lvbnMgb2YgdGhlIGNvcmUgc3BlY2lmaWNhdGlvbiwNCiAgIGV2ZW4gaW4gdGhlIGZhY2Ug b2YgZGVtb25zdHJhdGVkIG5lZWQuICBUaGUgZXh0ZW5zaW9uIG1lY2hhbmlzbQ0KICAgcHJvdmlk ZXMgZm9yIGEgd2F5IGZvciBpbmRlcGVuZGVudCBSRkNzIHRvIGRlZmluZSBleHRlbnNpb25zIHRv DQogICBsYW5ndWFnZSB0YWdzLiAgVGhlc2UgZXh0ZW5zaW9ucyBoYXZlIGEgdmVyeSBjb25zdHJh aW5lZCwgd2VsbC0NCiAgIGRlZmluZWQgc3RydWN0dXJlIHRoYXQgcHJldmVudCBleHRlbnNpb25z IGZyb20gaW50ZXJmZXJpbmcgd2l0aA0KICAgaW1wbGVtZW50YXRpb25zIG9mIGxhbmd1YWdlIHRh Z3MgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBUaGUgZG9jdW1lbnQgYWxzbyBhbnRp Y2lwYXRlcyBmZWF0dXJlcyBvZiBJU08gNjM5LTMgd2l0aCB0aGUgYWRkaXRpb24NCiAgIG9mIHRo ZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzLCBhcyB3ZWxsIGFzIHRoZSBwb3NzaWJpbGl0eSBv ZiBvdGhlcg0KICAgSVNPIDYzOSBwYXJ0cyBiZWNvbWluZyB1c2VmdWwgZm9yIHRoZSBmb3JtYXRp b24gb2YgbGFuZ3VhZ2UgdGFncyBpbg0KICAgdGhlIGZ1dHVyZS4NCg0KICAgVGhlIHVzZSBhbmQg ZGVmaW5pdGlvbiBvZiBwcml2YXRlIHVzZSB0YWdzIGhhcyBhbHNvIGJlZW4gbW9kaWZpZWQsIHRv DQogICBhbGxvdyBwZW9wbGUgdG8gdXNlIHByaXZhdGUgdXNlIHN1YnRhZ3MgdG8gZXh0ZW5kIG9y IG1vZGlmeSBkZWZpbmVkDQogICB0YWdzIGFuZCB0byBtb3ZlIGFzIG11Y2ggaW5mb3JtYXRpb24g YXMgcG9zc2libGUgb3V0IG9mIHByaXZhdGUgdXNlDQogICBhbmQgaW50byB0aGUgcmVndWxhciBz dHJ1Y3R1cmUuDQoNCiAgIFRoZSBnb2FsIGZvciBlYWNoIG9mIHRoZXNlIG1vZGlmaWNhdGlvbnMg aXMgdG8gcmVkdWNlIG9yIGVsaW1pbmF0ZQ0KICAgdGhlIG5lZWQgZm9yIGZ1dHVyZSByZXZpc2lv bnMgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgVGhlIHNwZWNpZmljIGNoYW5nZXMgaW4gdGhpcyBk b2N1bWVudCB0byBtZWV0IHRoZXNlIGdvYWxzIGFyZToNCg0KICAgbyAgRGVmaW5lcyB0aGUgQUJO RiBhbmQgcnVsZXMgZm9yIHN1YnRhZ3Mgc28gdGhhdCB0aGUgY2F0ZWdvcnkgb2YgYWxsDQogICAg ICBzdWJ0YWdzIGNhbiBiZSBkZXRlcm1pbmVkIHdpdGhvdXQgcmVmZXJlbmNlIHRvIHRoZSByZWdp c3RyeS4NCg0KICAgbyAgQWRkcyB0aGUgY29uY2VwdCBvZiB3ZWxsLWZvcm1lZCB2cy4gdmFsaWRh dGluZyBwcm9jZXNzb3JzLA0KICAgICAgZGVmaW5pbmcgdGhlIHJ1bGVzIGJ5IHdoaWNoIGFuIGlt cGxlbWVudGF0aW9uIGNhbiBjbGFpbSB0byBiZSBvbmUNCiAgICAgIG9yIHRoZSBvdGhlci4NCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAg ICAgICAgICAgICAgICBbUGFnZSA1Ml0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIG8gIFJl cGxhY2VzIHRoZSBJQU5BIGxhbmd1YWdlIHRhZyByZWdpc3RyeSB3aXRoIGEgbGFuZ3VhZ2Ugc3Vi dGFnDQogICAgICByZWdpc3RyeSB0aGF0IHByb3ZpZGVzIGEgY29tcGxldGUgbGlzdCBvZiB2YWxp ZCBzdWJ0YWdzIGluIHRoZQ0KICAgICAgSUFOQSByZWdpc3RyeS4gIFRoaXMgYWxsb3dzIGZvciBy b2J1c3QgaW1wbGVtZW50YXRpb24gYW5kIGVhc2Ugb2YNCiAgICAgIG1haW50ZW5hbmNlLiAgVGhl IGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSBiZWNvbWVzIHRoZSBjYW5vbmljYWwNCiAgICAgIHNv dXJjZSBmb3IgZm9ybWluZyBsYW5ndWFnZSB0YWdzLg0KDQogICBvICBQcm92aWRlcyBhIHByb2Nl c3MgdGhhdCBndWFyYW50ZWVzIHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLCBieQ0KICAgICAg aGFuZGxpbmcgcmV1c2Ugb2YgdmFsdWVzIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgYW5kIElTTyAz MTY2IGluDQogICAgICB0aGUgZXZlbnQgdGhhdCB0aGV5IHJlZ2lzdGVyIGEgcHJldmlvdXNseSB1 c2VkIHZhbHVlIGZvciBhIG5ldw0KICAgICAgcHVycG9zZS4NCg0KICAgbyAgQWxsb3dzIElTTyAx NTkyNCBzY3JpcHQgY29kZSBzdWJ0YWdzIGFuZCBhbGxvd3MgdGhlbSB0byBiZSB1c2VkDQogICAg ICBnZW5lcmF0aXZlbHkuICBEZWZpbmVzIGEgbWV0aG9kIGZvciBpbmRpY2F0aW5nIGluIHRoZSBy ZWdpc3RyeQ0KICAgICAgd2hlbiBzY3JpcHQgc3VidGFncyBhcmUgbmVjZXNzYXJ5IGZvciBhIGdp dmVuIGxhbmd1YWdlIHRhZy4NCg0KICAgbyAgQWRkcyB0aGUgY29uY2VwdCBvZiBhIHZhcmlhbnQg c3VidGFnIGFuZCBhbGxvd3MgdmFyaWFudHMgdG8gYmUNCiAgICAgIHVzZWQgZ2VuZXJhdGl2ZWx5 Lg0KDQogICBvICBBZGRzIHRoZSBhYmlsaXR5IHRvIHVzZSBhIGNsYXNzIG9mIFVOIE0uNDkgdGFn cyBmb3Igc3VwcmEtbmF0aW9uYWwNCiAgICAgIHJlZ2lvbnMgYW5kIHRvIHJlc29sdmUgY29uZmxp Y3RzIGluIHRoZSBhc3NpZ25tZW50IG9mIElTTyAzMTY2DQogICAgICBjb2Rlcy4NCg0KICAgbyAg RGVmaW5lcyB0aGUgcHJpdmF0ZSB1c2UgdGFncyBpbiBJU08gNjM5LCBJU08gMTU5MjQsIGFuZCBJ U08gMzE2Ng0KICAgICAgYXMgdGhlIG1lY2hhbmlzbSBmb3IgY3JlYXRpbmcgcHJpdmF0ZSB1c2Ug bGFuZ3VhZ2UsIHNjcmlwdCwgYW5kDQogICAgICByZWdpb24gc3VidGFncyByZXNwZWN0aXZlbHku DQoNCiAgIG8gIEFkZHMgYSB3ZWxsLWRlZmluZWQgZXh0ZW5zaW9uIG1lY2hhbmlzbS4NCg0KICAg byAgRGVmaW5lcyBhbiBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcsIHBvc3NpYmx5IGZvciB1c2Ug d2l0aCBjZXJ0YWluDQogICAgICBhbnRpY2lwYXRlZCBmZWF0dXJlcyBvZiBJU08gNjM5LTMuDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA1M10N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCjkuICBSZWZlcmVuY2VzDQoNCjkuMSAgTm9ybWF0aXZl IFJlZmVyZW5jZXMNCg0KICAgW0lTTzEwNjQ2XQ0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFs IE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPL0lFQw0KICAgICAgICAgICAg ICAxMDY0NjoyMDAzLiBJbmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0tIFVuaXZlcnNhbCBNdWx0aXBs ZS0NCiAgICAgICAgICAgICAgT2N0ZXQgQ29kZWQgQ2hhcmFjdGVyIFNldCAoVUNTKSIsIDIwMDMu DQoNCiAgIFtJU08xNTkyNF0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRp b24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTw0KICAgICAgICAgICAgICAxNTkyNDoyMDA0LiBJ bmZvcm1hdGlvbiBhbmQgZG9jdW1lbnRhdGlvbiAtLSBDb2RlcyBmb3IgdGhlDQogICAgICAgICAg ICAgIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIHNjcmlwdHMiLCBKYW51YXJ5IDIwMDQuDQoN CiAgIFtJU08zMTY2LTFdDQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9u IGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gMzE2Ni0NCiAgICAgICAgICAgICAgMToxOTk3LiBD b2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcw0KICAgICAg ICAgICAgICBhbmQgdGhlaXIgc3ViZGl2aXNpb25zIC0tIFBhcnQgMTogQ291bnRyeSBjb2RlcyIs IDE5OTcuDQoNCiAgIFtJU082MzktMV0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdh bml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyA2MzktDQogICAgICAgICAgICAgIDE6 MjAwMi4gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBsYW5ndWFnZXMN CiAgICAgICAgICAgICAgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiLCAyMDAyLg0KDQogICBbSVNP NjM5LTJdDQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFu ZGFyZGl6YXRpb24sICJJU08gNjM5LQ0KICAgICAgICAgICAgICAyOjE5OTguIENvZGVzIGZvciB0 aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgbGFuZ3VhZ2VzDQogICAgICAgICAgICAgIC0t IFBhcnQgMjogQWxwaGEtMyBjb2RlLCBmaXJzdCBlZGl0aW9uIiwgMTk5OC4NCg0KICAgW0lTTzY0 Nl0gICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNP L0lFQw0KICAgICAgICAgICAgICA2NDY6MTk5MSwgSW5mb3JtYXRpb24gdGVjaG5vbG9neSAtLSBJ U08gNy1iaXQgY29kZWQNCiAgICAgICAgICAgICAgY2hhcmFjdGVyIHNldCBmb3IgaW5mb3JtYXRp b24gaW50ZXJjaGFuZ2UuIiwgMTk5MS4NCg0KICAgW1JGQzIwMjZdICBCcmFkbmVyLCBTLiwgIlRo ZSBJbnRlcm5ldCBTdGFuZGFyZHMgUHJvY2VzcyAtLSBSZXZpc2lvbg0KICAgICAgICAgICAgICAz IiwgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuDQoNCiAgIFtSRkMyMDI4XSAgSG92ZXks IFIuIGFuZCBTLiBCcmFkbmVyLCAiVGhlIE9yZ2FuaXphdGlvbnMgSW52b2x2ZWQgaW4NCiAgICAg ICAgICAgICAgdGhlIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MiLCBCQ1AgMTEsIFJGQyAyMDI4LA0K ICAgICAgICAgICAgICBPY3RvYmVyIDE5OTYuDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4s ICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJl cXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtS RkMyMjM0YmlzXQ0KICAgICAgICAgICAgICBDcm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgIkF1 Z21lbnRlZCBCTkYgZm9yIFN5bnRheA0KICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJO RiIsIGRyYWZ0LWNyb2NrZXItYWJuZi1yZmMyMjM0YmlzLTAwDQogICAgICAgICAgICAgICh3b3Jr IGluIHByb2dyZXNzKSwgTWFyY2ggMjAwNS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNTRdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMDUNCg0KDQogICBbUkZDMjQzNF0gIE5hcnRlbiwgVC4gYW5kIEguIEFsdmVz dHJhbmQsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuDQogICAgICAgICAgICAgIElBTkEgQ29u c2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwgQkNQIDI2LCBSRkMgMjQzNCwNCiAgICAgICAg ICAgICAgT2N0b2JlciAxOTk4Lg0KDQogICBbUkZDMjg2MF0gIENhcnBlbnRlciwgQi4sIEJha2Vy LCBGLiwgYW5kIE0uIFJvYmVydHMsICJNZW1vcmFuZHVtIG9mDQogICAgICAgICAgICAgIFVuZGVy c3RhbmRpbmcgQ29uY2VybmluZyB0aGUgVGVjaG5pY2FsIFdvcmsgb2YgdGhlDQogICAgICAgICAg ICAgIEludGVybmV0IEFzc2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5IiwgUkZDIDI4NjAsIEp1bmUg MjAwMC4NCg0KICAgW1JGQzMzMzldICBLbHluZSwgRy4gYW5kIEMuIE5ld21hbiwgIkRhdGUgYW5k IFRpbWUgb24gdGhlIEludGVybmV0Og0KICAgICAgICAgICAgICBUaW1lc3RhbXBzIiwgUkZDIDMz MzksIEp1bHkgMjAwMi4NCg0KICAgW1VOX00uNDldICBTdGF0aXN0aWNzIERpdmlzaW9uLCBVbml0 ZWQgTmF0aW9ucywgIlN0YW5kYXJkIENvdW50cnkgb3INCiAgICAgICAgICAgICAgQXJlYSBDb2Rl cyBmb3IgU3RhdGlzdGljYWwgVXNlIiwgVU4gU3RhbmRhcmQgQ291bnRyeSBvcg0KICAgICAgICAg ICAgICBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UsIFJldmlzaW9uIDQgKFVuaXRlZCBO YXRpb25zDQogICAgICAgICAgICAgIHB1YmxpY2F0aW9uLCBTYWxlcyBOby4gOTguWFZJSS45LCBK dW5lIDE5OTkuDQoNCjkuMiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMTc2Nl0g IEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mDQogICAgICAg ICAgICAgIExhbmd1YWdlcyIsIFJGQyAxNzY2LCBNYXJjaCAxOTk1Lg0KDQogICBbUkZDMjA0N10g IE1vb3JlLCBLLiwgIk1JTUUgKE11bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIEV4dGVuc2lvbnMp DQogICAgICAgICAgICAgIFBhcnQgVGhyZWU6IE1lc3NhZ2UgSGVhZGVyIEV4dGVuc2lvbnMgZm9y IE5vbi1BU0NJSSBUZXh0IiwNCiAgICAgICAgICAgICAgUkZDIDIwNDcsIE5vdmVtYmVyIDE5OTYu DQoNCiAgIFtSRkMyMjMxXSAgRnJlZWQsIE4uIGFuZCBLLiBNb29yZSwgIk1JTUUgUGFyYW1ldGVy IFZhbHVlIGFuZCBFbmNvZGVkDQogICAgICAgICAgICAgIFdvcmQgRXh0ZW5zaW9uczogQ2hhcmFj dGVyIFNldHMsIExhbmd1YWdlcywgYW5kDQogICAgICAgICAgICAgIENvbnRpbnVhdGlvbnMiLCBS RkMgMjIzMSwgTm92ZW1iZXIgMTk5Ny4NCg0KICAgW1JGQzI3ODFdICBIb2ZmbWFuLCBQLiBhbmQg Ri4gWWVyZ2VhdSwgIlVURi0xNiwgYW4gZW5jb2Rpbmcgb2YgSVNPDQogICAgICAgICAgICAgIDEw NjQ2IiwgUkZDIDI3ODEsIEZlYnJ1YXJ5IDIwMDAuDQoNCiAgIFtSRkMzMDY2XSAgQWx2ZXN0cmFu ZCwgSC4sICJUYWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2YNCiAgICAgICAgICAgICAgTGFu Z3VhZ2VzIiwgQkNQIDQ3LCBSRkMgMzA2NiwgSmFudWFyeSAyMDAxLg0KDQogICBbUkZDMzU1Ml0g IFJlc2NvcmxhLCBFLiBhbmQgQi4gS29ydmVyLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBSRkMN CiAgICAgICAgICAgICAgVGV4dCBvbiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIsIEJDUCA3Miwg UkZDIDM1NTIsDQogICAgICAgICAgICAgIEp1bHkgMjAwMy4NCg0KICAgW1VuaWNvZGVdICBVbmlj b2RlIENvbnNvcnRpdW0sICJUaGUgVW5pY29kZSBDb25zb3J0aXVtLiBUaGUgVW5pY29kZQ0KICAg ICAgICAgICAgICBTdGFuZGFyZCwgVmVyc2lvbiA0LjEuMCwgZGVmaW5lZCBieTogVGhlIFVuaWNv ZGUgU3RhbmRhcmQsDQogICAgICAgICAgICAgIFZlcnNpb24gNC4wIChCb3N0b24sIE1BLCBBZGRp c29uLVdlc2xleSwgMjAwMy4gSVNCTiAwLTMyMS0NCiAgICAgICAgICAgICAgMTg1NzgtMSksIGFz IGFtZW5kZWQgYnkgVW5pY29kZSA0LjAuMQ0KICAgICAgICAgICAgICAoaHR0cDovL3d3dy51bmlj b2RlLm9yZy92ZXJzaW9ucy9Vbmljb2RlNC4wLjEpIGFuZCBieQ0KICAgICAgICAgICAgICBVbmlj b2RlIDQuMS4wDQogICAgICAgICAgICAgIChodHRwOi8vd3d3LnVuaWNvZGUub3JnL3ZlcnNpb25z L1VuaWNvZGU0LjEuMCkuIiwNCiAgICAgICAgICAgICAgTWFyY2ggMjAwNS4NCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYgICAgICAgICAgICAg ICAgW1BhZ2UgNTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBbWE1MMTBdICAgIEJyYXkg KGV0IGFsKSwgVC4sICJFeHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSAoWE1MKSAxLjAiLA0KICAg ICAgICAgICAgICAwMiAyMDA0Lg0KDQogICBbWE1MU2NoZW1hXQ0KICAgICAgICAgICAgICBCaXJv biwgUC4sIEVkLiBhbmQgQS4gTWFsaG90cmEsIEVkLiwgIlhNTCBTY2hlbWEgUGFydCAyOg0KICAg ICAgICAgICAgICBEYXRhdHlwZXMgU2Vjb25kIEVkaXRpb24iLCAxMCAyMDA0LCA8DQogICAgICAg ICAgICAgIGh0dHA6Ly93d3cudzMub3JnL1RSL3htbHNjaGVtYS0yLz4uDQoNCiAgIFtpbml0aWFs LXJlZ2lzdHJ5XQ0KICAgICAgICAgICAgICBFd2VsbCwgRC4sIEVkLiwgIkluaXRpYWwgTGFuZ3Vh Z2UgU3VidGFnIFJlZ2lzdHJ5IiwNCiAgICAgICAgICAgICAgSnVuZSAyMDA1LCA8aHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtbHRy dS1pbml0aWFsLXJlZ2lzdHJ5LTAwLnR4dD4uDQoNCiAgIFtpc282MzkucHJpbmNpcGxlc10NCiAg ICAgICAgICAgICAgSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWUsICJJU08gNjM5IEpv aW50IEFkdmlzb3J5DQogICAgICAgICAgICAgIENvbW1pdHRlZTogIFdvcmtpbmcgcHJpbmNpcGxl cyBmb3IgSVNPIDYzOSBtYWludGVuYW5jZSIsDQogICAgICAgICAgICAgIE1hcmNoIDIwMDAsDQog ICAgICAgICAgICAgIDxodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yLw0KICAg ICAgICAgICAgICBpc282MzlqYWNfbjNyLmh0bWw+Lg0KDQogICBbcmVjb3JkLWphcl0NCiAgICAg ICAgICAgICAgUmF5bW9uZCwgRS4sICJUaGUgQXJ0IG9mIFVuaXggUHJvZ3JhbW1pbmciLCAyMDAz LA0KICAgICAgICAgICAgICA8dXJuOmlzYm46MC0xMy0xNDI5MDEtOT4uDQoNCg0KQXV0aG9ycycg QWRkcmVzc2VzDQoNCiAgIEFkZGlzb24gUGhpbGxpcHMgKGVkaXRvcikNCiAgIFF1ZXN0IFNvZnR3 YXJlDQoNCiAgIEVtYWlsOiBhZGRpc29uLnBoaWxsaXBzQHF1ZXN0LmNvbQ0KICAgVVJJOiAgIGh0 dHA6Ly93d3cuaW50ZXItbG9jYWxlLmNvbQ0KDQoNCiAgIE1hcmsgRGF2aXMgKGVkaXRvcikNCiAg IElCTQ0KDQogICBFbWFpbDogbWFyay5kYXZpc0B1cy5pYm0uY29tDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2 ICAgICAgICAgICAgICAgIFtQYWdlIDU2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KQXBwZW5k aXggQS4gIEFja25vd2xlZGdlbWVudHMNCg0KICAgQW55IGxpc3Qgb2YgY29udHJpYnV0b3JzIGlz IGJvdW5kIHRvIGJlIGluY29tcGxldGU7IHBsZWFzZSByZWdhcmQgdGhlDQogICBmb2xsb3dpbmcg YXMgb25seSBhIHNlbGVjdGlvbiBmcm9tIHRoZSBncm91cCBvZiBwZW9wbGUgd2hvIGhhdmUNCiAg IGNvbnRyaWJ1dGVkIHRvIG1ha2UgdGhpcyBkb2N1bWVudCB3aGF0IGl0IGlzIHRvZGF5Lg0KDQog ICBUaGUgY29udHJpYnV0b3JzIHRvIFJGQyAzMDY2IGFuZCBSRkMgMTc2NiwgdGhlIHByZWN1cnNv cnMgb2YgdGhpcw0KICAgZG9jdW1lbnQsIG1hZGUgZW5vcm1vdXMgY29udHJpYnV0aW9ucyBkaXJl Y3RseSBvciBpbmRpcmVjdGx5IHRvIHRoaXMNCiAgIGRvY3VtZW50IGFuZCBhcmUgZ2VuZXJhbGx5 IHJlc3BvbnNpYmxlIGZvciB0aGUgc3VjY2VzcyBvZiBsYW5ndWFnZQ0KICAgdGFncy4NCg0KICAg VGhlIGZvbGxvd2luZyBwZW9wbGUgKGluIGFscGhhYmV0aWNhbCBvcmRlcikgY29udHJpYnV0ZWQg dG8gdGhpcw0KICAgZG9jdW1lbnQgb3IgdG8gUkZDcyAxNzY2IGFuZCAzMDY2Og0KDQogICBHbGVu biBBZGFtcywgSGFyYWxkIFR2ZWl0IEFsdmVzdHJhbmQsIFRpbSBCZXJuZXJzLUxlZSwgTWFyYyBC bGFuY2hldCwNCiAgIE5hdGhhbmllbCBCb3JlbnN0ZWluLCBLYXJlbiBCcm9vbWUsIEVyaWMgQnJ1 bm5lciwgU2VhbiBNLiBCdXJrZSwgTS5ULg0KICAgQ2FycmFzY28gQmVuaXRleiwgSmVyZW15IENh cnJvbGwsIEpvaG4gQ2xld3MsIEppbSBDb25rbGluLCBQZXRlcg0KICAgQ29uc3RhYmxlLCBKb2hu IENvd2FuLCBNYXJrIENyaXNwaW4sIERhdmUgQ3JvY2tlciwgRWx3eW4gRGF2aWVzLA0KICAgTWFy dGluIER1ZXJzdCwgRnJhbmsgRWxsZXJtYW4sIE1pY2hhZWwgRXZlcnNvbiwgRG91ZyBFd2VsbCwg TmVkDQogICBGcmVlZCwgVGltIEdvb2R3aW4sIERpcmstV2lsbGVtIHZhbiBHdWxpaywgTWFyaW9u IEd1bm4sIEpvZWwgSGFscHJlbiwNCiAgIEVsbGlvdHRlIFJ1c3R5IEhhcm9sZCwgUGF1bCBIb2Zm bWFuLCBTY290dCBIb2xsZW5iZWNrLCBSaWNoYXJkDQogICBJc2hpZGEsIE9sbGUgSmFybmVmb3Jz LCBLZW50IEthcmxzc29uLCBKb2huIEtsZW5zaW4sIEVya2tpDQogICBLb2xlaG1haW5lbiwgQWxh aW4gTGFCb250ZSwgRXJpYyBNYWRlciwgSXJhIE1jRG9uYWxkLCBLZWl0aCBNb29yZSwNCiAgIENo cmlzIE5ld21hbiwgTWFzYXRha2EgT2h0YSwgRHlsYW4gUGllcmNlLCBSYW5keSBQcmVzdWhuLCBH ZW9yZ2UNCiAgIFJob3RlbiwgRmVsaXggU2FzYWtpLCBNYXJrdXMgU2NoZXJlciwgS2VsZCBKb3Ju IFNpbW9uc2VuLCBUaGllcnJ5DQogICBTb3VyYmllciwgT3R0byBTdG9seiwgVGV4IFRleGluLCBB bmRyZWEgVmluZSwgUmh5cyBXZWF0aGVybGV5LCBNaXNoYQ0KICAgV29sZiwgRnJhbmNvaXMgWWVy Z2VhdSBhbmQgbWFueSwgbWFueSBvdGhlcnMuDQoNCiAgIFZlcnkgc3BlY2lhbCB0aGFua3MgbXVz dCBnbyB0byBIYXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCwgd2hvDQogICBvcmlnaW5hdGVkIFJGQ3Mg MTc2NiBhbmQgMzA2NiwgYW5kIHdpdGhvdXQgd2hvbSB0aGlzIGRvY3VtZW50IHdvdWxkDQogICBu b3QgaGF2ZSBiZWVuIHBvc3NpYmxlLiAgU3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBNaWNoYWVs IEV2ZXJzb24sDQogICB3aG8gaGFzIHNlcnZlZCBhcyBMYW5ndWFnZSBUYWcgUmV2aWV3ZXIgZm9y IGFsbW9zdCB0aGUgY29tcGxldGUNCiAgIHBlcmlvZCBzaW5jZSB0aGUgcHVibGljYXRpb24gb2Yg UkZDIDE3NjYuICBTcGVjaWFsIHRoYW5rcyB0byBEb3VnDQogICBFd2VsbCwgZm9yIGhpcyBwcm9k dWN0aW9uIG9mIHRoZSBmaXJzdCBjb21wbGV0ZSBzdWJ0YWcgcmVnaXN0cnksIGFuZA0KICAgaGlz IHdvcmsgaW4gcHJvZHVjaW5nIGEgdGVzdCBwYXJzZXIgZm9yIHZlcmlmeWluZyBsYW5ndWFnZSB0 YWdzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA1N10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCkFwcGVuZGl4IEIuICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBU YWdzIChJbmZvcm1hdGl2ZSkNCg0KICAgU2ltcGxlIGxhbmd1YWdlIHN1YnRhZzoNCg0KICAgICAg ZGUgKEdlcm1hbikNCg0KICAgICAgZnIgKEZyZW5jaCkNCg0KICAgICAgamEgKEphcGFuZXNlKQ0K DQogICAgICBpLWVub2NoaWFuIChleGFtcGxlIG9mIGEgZ3JhbmRmYXRoZXJlZCB0YWcpDQoNCiAg IExhbmd1YWdlIHN1YnRhZyBwbHVzIFNjcmlwdCBzdWJ0YWc6DQoNCiAgICAgIHpoLUhhbnQgKENo aW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUgVHJhZGl0aW9uYWwgQ2hpbmVzZSBzY3JpcHQpDQoNCiAg ICAgIHpoLUhhbnMgKENoaW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUgU2ltcGxpZmllZCBDaGluZXNl IHNjcmlwdCkNCg0KICAgICAgc3ItQ3lybCAoU2VyYmlhbiB3cml0dGVuIHVzaW5nIHRoZSAgQ3ly aWxsaWMgc2NyaXB0KQ0KDQogICAgICBzci1MYXRuIChTZXJiaWFuIHdyaXR0ZW4gdXNpbmcgdGhl IExhdGluIHNjcmlwdCkNCg0KICAgTGFuZ3VhZ2UtU2NyaXB0LVJlZ2lvbjoNCg0KICAgICAgemgt SGFucy1DTiAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBTaW1wbGlmaWVkIHNjcmlwdCBhcyB1 c2VkIGluDQogICAgICBtYWlubGFuZCBDaGluYSkNCg0KICAgICAgc3ItTGF0bi1DUyAoU2VyYmlh biB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQgYXMgdXNlZCBpbg0KICAgICAgU2VyYmlh IGFuZCBNb250ZW5lZ3JvKQ0KDQogICBMYW5ndWFnZS1WYXJpYW50Og0KDQogICAgICBzbC1yb3ph aiAoUmVzaWFuIGRpYWxlY3Qgb2YgU2xvdmVuaWFuDQoNCiAgICAgIHNsLW5lZGlzIChOYWRpemEg ZGlhbGVjdCBvZiBTbG92ZW5pYW4pDQoNCiAgIExhbmd1YWdlLVJlZ2lvbi1WYXJpYW50Og0KDQog ICAgICBkZS1DSC0xOTAxIChHZXJtYW4gYXMgdXNlZCBpbiBTd2l0emVybGFuZCB1c2luZyB0aGUg MTkwMSB2YXJpYW50DQogICAgICBbb3J0aG9ncmFwaHldKQ0KDQogICAgICBzbC1JVC1uZWRpcyAo U2xvdmVuaWFuIGFzIHVzZWQgaW4gSXRhbHksIE5hZGl6YSBkaWFsZWN0KQ0KDQogICBMYW5ndWFn ZS1TY3JpcHQtUmVnaW9uLVZhcmlhbnQ6DQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDU4XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgICAgc2wtTGF0bi1JVC1uZWRpcyAoTmFkaXphIGRp YWxlY3Qgb2YgU2xvdmVuaWFuIHdyaXR0ZW4gdXNpbmcgdGhlDQogICAgICBMYXRpbiBzY3JpcHQg YXMgdXNlZCBpbiBJdGFseS4gIE5vdGUgdGhhdCB0aGlzIHRhZyBpcyBOT1QNCiAgICAgIFJFQ09N TUVOREVEIGJlY2F1c2Ugc3VidGFnICdzbCcgaGFzIGEgU3VwcHJlc3MtU2NyaXB0IHZhbHVlIG9m DQogICAgICAnTGF0bicpDQoNCiAgIExhbmd1YWdlLVJlZ2lvbjoNCg0KICAgICAgZGUtREUgKEdl cm1hbiBmb3IgR2VybWFueSkNCg0KICAgICAgZW4tVVMgKEVuZ2xpc2ggYXMgdXNlZCBpbiB0aGUg VW5pdGVkIFN0YXRlcykNCg0KICAgICAgZXMtNDE5IChTcGFuaXNoIGFwcHJvcHJpYXRlIGZvciB0 aGUgTGF0aW4gQW1lcmljYSBhbmQgQ2FyaWJiZWFuDQogICAgICByZWdpb24gdXNpbmcgdGhlIFVO IHJlZ2lvbiBjb2RlKQ0KDQogICBQcml2YXRlIHVzZSBzdWJ0YWdzOg0KDQogICAgICBkZS1DSC14 LXBob25lYmsNCg0KICAgICAgYXotQXJhYi14LUFaRS1kZXJiZW5kDQoNCiAgIEV4dGVuZGVkIGxh bmd1YWdlIHN1YnRhZ3MgKGV4YW1wbGVzIE9OTFk6IGV4dGVuZGVkIGxhbmd1YWdlcyBNVVNUIGJl DQogICBkZWZpbmVkIGJ5IHJldmlzaW9uIG9yIHVwZGF0ZSB0byB0aGlzIGRvY3VtZW50KToNCg0K ICAgICAgemgtbWluDQoNCiAgICAgIHpoLW1pbi1uYW4tSGFudC1DTg0KDQogICBQcml2YXRlIHVz ZSByZWdpc3RyeSB2YWx1ZXM6DQoNCiAgICAgIHgtd2hhdGV2ZXIgKHByaXZhdGUgdXNlIHVzaW5n IHRoZSBzaW5nbGV0b24gJ3gnKQ0KDQogICAgICBxYWEtUWFhYS1RTS14LXNvdXRoZXJuIChhbGwg cHJpdmF0ZSB0YWdzKQ0KDQogICAgICBkZS1RYWFhIChHZXJtYW4sIHdpdGggYSBwcml2YXRlIHNj cmlwdCkNCg0KICAgICAgc3ItTGF0bi1RTSAoU2VyYmlhbiwgTGF0aW4tc2NyaXB0LCBwcml2YXRl IHJlZ2lvbikNCg0KICAgICAgc3ItUWFhYS1DUyAoU2VyYmlhbiwgcHJpdmF0ZSBzY3JpcHQsIGZv ciBTZXJiaWEgYW5kIE1vbnRlbmVncm8pDQoNCiAgIFRhZ3MgdGhhdCB1c2UgZXh0ZW5zaW9ucyAo ZXhhbXBsZXMgT05MWTogZXh0ZW5zaW9ucyBNVVNUIGJlIGRlZmluZWQNCiAgIGJ5IHJldmlzaW9u IG9yIHVwZGF0ZSB0byB0aGlzIGRvY3VtZW50IG9yIGJ5IFJGQyk6DQoNCiAgICAgIGVuLVVTLXUt aXNsYW1DYWwNCg0KICAgICAgemgtQ04tYS1teUV4dC14LXByaXZhdGUNCg0KDQoNCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAgICAg ICAgIFtQYWdlIDU5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgICAgZW4tYS1teUV4dC1i LWFub3RoZXINCg0KICAgU29tZSBJbnZhbGlkIFRhZ3M6DQoNCiAgICAgIGRlLTQxOS1ERSAodHdv IHJlZ2lvbiB0YWdzKQ0KDQogICAgICBhLURFICh1c2Ugb2YgYSBzaW5nbGUgY2hhcmFjdGVyIHN1 YnRhZyBpbiBwcmltYXJ5IHBvc2l0aW9uOyBub3RlDQogICAgICB0aGF0IHRoZXJlIGFyZSBhIGZl dyBncmFuZGZhdGhlcmVkIHRhZ3MgdGhhdCBzdGFydCB3aXRoICJpLSIgdGhhdA0KICAgICAgYXJl IHZhbGlkKQ0KDQogICAgICBhci1hLWFhYS1iLWJiYi1hLWNjYyAodHdvIGV4dGVuc2lvbnMgd2l0 aCBzYW1lIHNpbmdsZSBsZXR0ZXINCiAgICAgIHByZWZpeCkNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDA2ICAgICAgICAg ICAgICAgIFtQYWdlIDYwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KSW50ZWxsZWN0dWFsIFBy b3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRp bmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5 IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0 YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3Jp YmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vu c2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7 IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRl bnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBv biB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMg Y2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQ UiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFz c3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQg b2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVy bWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1w bGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFp bmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFy dHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMg b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0 aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVu dA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0 aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KRGlzY2xhaW1lciBvZiBWYWxp ZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhl cmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklC VVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNP UkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQog ICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNT IE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5G UklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFO VEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KQ29weXJp Z2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgy MDA1KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5z ZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBh cyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMu DQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVu Y3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50ZXJuZXQgU29jaWV0eS4N Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMDYg ICAgICAgICAgICAgICAgW1BhZ2UgNjFdDQoMDQo= ------_=_NextPart_001_01C5BFB1.830D9848 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C5BFB1.830D9848-- From ltru-bounces@ietf.org Thu Sep 22 18:13:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZHS-0007AO-Gh; Thu, 22 Sep 2005 18:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZHQ-00078z-Hc for ltru@megatron.ietf.org; Thu, 22 Sep 2005 18:11:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29181 for ; Thu, 22 Sep 2005 18:10:57 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIZNi-0006EX-Gf for ltru@ietf.org; Thu, 22 Sep 2005 18:17:31 -0400 Received: from h-68-165-6-126.snvacaid.dynamic.covad.net ([68.165.6.126] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EIZHJ-0005gW-00 for ltru@ietf.org; Thu, 22 Sep 2005 18:10:53 -0400 Message-ID: <004101c5bfc2$e0e9b360$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] Summary of IETF last call issues on ltru registry drafts Date: Thu, 22 Sep 2005 15:13:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Thursday, September 22, 2005 1:07 PM > Subject: RE: [Ltru] Summary of IETF last call issues on ltru registry drafts ... > I am submitting this document to the I-D editor under separate cover now too. ... Thank you for the quick turnaround. After we get agreement on words for the initial registry's section 3 note, and Doug has submitted his update, it will again be in our AD's hands. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Sep 22 18:50:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZts-0007Hs-HC; Thu, 22 Sep 2005 18:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZtG-00077x-LO; Thu, 22 Sep 2005 18:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01453; Thu, 22 Sep 2005 18:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIZzW-0006vx-VF; Thu, 22 Sep 2005 18:56:35 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EIZtB-0002nR-W8; Thu, 22 Sep 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Sep 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-13.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-registry-13.txt Pages : 60 Date : 2005-9-22 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-registry-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-registry-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-22170405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-22170405.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Thu Sep 22 20:25:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIbNo-0003lz-S8; Thu, 22 Sep 2005 20:25:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIbNn-0003lu-HL for ltru@megatron.ietf.org; Thu, 22 Sep 2005 20:25:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15401 for ; Thu, 22 Sep 2005 20:25:42 -0400 (EDT) Received: from eastrmmtao05.cox.net ([68.230.240.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIbU7-00049J-56 for ltru@ietf.org; Thu, 22 Sep 2005 20:32:16 -0400 Received: from A31P ([68.100.55.187]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20050923002515.IHGN24048.eastrmmtao05.cox.net@A31P>; Thu, 22 Sep 2005 20:25:15 -0400 From: "Scott Hollenbeck" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] Summary of IETF last call issues on ltru registry drafts Date: Thu, 22 Sep 2005 20:25:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <004101c5bfc2$e0e9b360$7f1afea9@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW/wt8/PszRxfLxS3OQT7kEfEM3AgAEdfzQ Message-Id: <20050923002515.IHGN24048.eastrmmtao05.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, September 22, 2005 6:14 PM > To: LTRU Working Group > Subject: Re: [Ltru] Summary of IETF last call issues on ltru > registry drafts > > Hi - > > > From: "Addison Phillips" > > To: "Randy Presuhn" ; "LTRU Working > > Group" > > Sent: Thursday, September 22, 2005 1:07 PM > > Subject: RE: [Ltru] Summary of IETF last call issues on > ltru registry > > drafts > ... > > I am submitting this document to the I-D editor under > separate cover now too. > ... > > Thank you for the quick turnaround. After we get agreement > on words for the initial registry's section 3 note, and Doug > has submitted his update, it will again be in our AD's hands. ...and I will take both documents to the IESG for evaluation once they have been updated. Randy, we do need to produce a short list of last call comments that were repeats from the working group reviews. That list will help the IESG better understand which issues were addressed by the group prior to the last call and those which were newly identified during the last call. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 02:01:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIgcf-0000nP-J8; Fri, 23 Sep 2005 02:01:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIgcd-0000nJ-Qu for ltru@megatron.ietf.org; Fri, 23 Sep 2005 02:01:23 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10923 for ; Fri, 23 Sep 2005 02:01:22 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050923060050.NFKP12165.mta10.adelphia.net@DEWELL> for ; Fri, 23 Sep 2005 02:00:50 -0400 Message-ID: <005601c5c004$1f42c980$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050921165755.JTXF3524.edge5.adelphia.net@megatron.ietf.org> Date: Thu, 22 Sep 2005 23: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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Note to RFC editor in initial registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > Let's see what Doug proposes for the note. I'd personally prefer > a reference to the registry draft, rather than putting an URL into > the note in the initial registry draft. That would leave fewer > opportunities for error in AUTH48. I'll propose some actual text probably Friday night or Saturday, after I've had a bit more sleep. The short answer is that I agree with Randy's comment above, and also agree in principle with his proposed text that simply says of the initial-registry text, "it was here once, but has been stripped out," rather than trying to show the reader how to reconstruct the initial registry. Reconstructing the initial registry won't work anyway because the "Added" date doesn't reflect changes (such as a Suppress-Script field added to an existing record), and also because the records for grandfathered and redundant tags have an "Added" date equal to the date the tag was added to the RFC 3066 registry (unlike the subtag records). -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 09:02:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EInC1-0005qL-Ls; Fri, 23 Sep 2005 09:02:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EInBx-0005n4-2M for ltru@megatron.ietf.org; Fri, 23 Sep 2005 09:02:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12914 for ; Fri, 23 Sep 2005 09:02:14 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EInIM-0005zd-6h for ltru@ietf.org; Fri, 23 Sep 2005 09:08:55 -0400 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EInBp-00057I-Ba for ltru@ietf.org; Fri, 23 Sep 2005 06:02:09 -0700 Message-Id: <6.2.3.4.2.20050923145524.03dec740@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 23 Sep 2005 14:56:54 +0200 To: "LTRU Working Group" From: r&d afrac In-Reply-To: <005601c5c004$1f42c980$030aa8c0@DEWELL> References: <20050921165755.JTXF3524.edge5.adelphia.net@megatron.ietf.org> <005601c5c004$1f42c980$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Ltru] el truth? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org http://vm666.free.fr/tmp/br504.mpg jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 11:09:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIpAl-0004Xl-Jr; Fri, 23 Sep 2005 11:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIpAj-0004Sz-61 for ltru@megatron.ietf.org; Fri, 23 Sep 2005 11:09:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20559 for ; Fri, 23 Sep 2005 11:09:07 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIpH8-0000gN-98 for ltru@ietf.org; Fri, 23 Sep 2005 11:15:49 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j8NF8Xgt004341; Fri, 23 Sep 2005 08:08:33 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Sep 2005 08:09:01 -0700 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] Re: Note to RFC editor in initial registry Date: Fri, 23 Sep 2005 08:08:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi, It's probably too late in this process, but... The ambiguity in the content of 'Added' would go away if the field were named 'Created' (clearly, the date wouldn't change with a modification). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org]On Behalf Of > Doug Ewell > Sent: Friday, September 23, 2005 2:01 AM > To: LTRU Working Group > Subject: [Ltru] Re: Note to RFC editor in initial registry > > > Randy Presuhn wrote: > > > Let's see what Doug proposes for the note. I'd personally prefer > > a reference to the registry draft, rather than putting an URL into > > the note in the initial registry draft. That would leave fewer > > opportunities for error in AUTH48. > > I'll propose some actual text probably Friday night or Saturday, after > I've had a bit more sleep. > > The short answer is that I agree with Randy's comment above, and also > agree in principle with his proposed text that simply says of the > initial-registry text, "it was here once, but has been stripped out," > rather than trying to show the reader how to reconstruct the initial > registry. > > Reconstructing the initial registry won't work anyway because the > "Added" date doesn't reflect changes (such as a Suppress-Script field > added to an existing record), and also because the records for > grandfathered and redundant tags have an "Added" date equal > to the date > the tag was added to the RFC 3066 registry (unlike the subtag > records). > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 11:42:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIpgg-0003m9-9z; Fri, 23 Sep 2005 11:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIpge-0003m1-VU for ltru@megatron.ietf.org; Fri, 23 Sep 2005 11:42:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21960 for ; Fri, 23 Sep 2005 11:42:04 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIpn3-0001SE-Qj for ltru@ietf.org; Fri, 23 Sep 2005 11:48:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 08:41:47 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvmbxw01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Sep 2005 08:41:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Note to RFC editor in initial registry Date: Fri, 23 Sep 2005 08:41:36 -0700 Message-ID: Thread-Topic: [Ltru] Re: Note to RFC editor in initial registry thread-index: AcXAUP0rZDSJXqoRTLmHDDbaVURN1gAA1j6A From: "Addison Phillips" To: "McDonald, Ira" , "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 23 Sep 2005 15:41:47.0395 (UTC) FILETIME=[4EA27530:01C5C055] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2059458795==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2059458795== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlcmUgaXMgbm8gYW1iaWd1aXR5IGluIHRoZSBjb250ZW50IG9mICdBZGRlZCc6IGl0IGlzIHRo ZSBkYXRlIHRoZSBzdWJ0YWcgKG9yIHRhZykgd2FzIGFkZGVkIHRvIHRoZSByZWdpc3RyeS4gSXQg c2F5cyBzbyBpbiB0aGUgZHJhZnQuIFRoZSB2YWx1ZSBpcyBndWFyYW50ZWVkIHRvIGJlIHN0YWJs ZSBvdmVyIHRpbWUsIHNvIGl0IGNhbm5vdCBiZSB0aGUgcmVjb3JkLWluc3RhbmNlJ3MgY3JlYXRp b24gZGF0ZS4NCg0KVGhlIG9uZSBwb3RlbnRpYWxseSBjdXJpb3VzIHR3aXN0IGlzIHRoYXQgdGhl IEZpbGUtRGF0ZSByZWNvcmQgbWF5IGhhdmUgYSBkYXRlIGxhdGVyIHRoYW4gYWxsIG9mIHRoZSBB ZGRlZCBhbmQgRGVwcmVjYXRlZCBkYXRlcyBpbiB0aGUgcmVnaXN0cnkuIElmIHdlIHdpc2hlZCB0 byBkbyBhbnl0aGluZywgaW5zdGVhZCBvZiBjaGFuZ2luZyAnQWRkZWQnIHRvICdDcmVhdGVkJyB3 ZSBjb3VsZCBjcmVhdGUgYW5vdGhlciBpbmZvcm1hdGl2ZSBmaWVsZCBjYWxsZWQgJ0xhc3QtTW9k aWZpZWQnLg0KDQpJIGhhcHBlbiB0byB0aGluayBpdCdzIHRvbyBsYXRlLCB0aG91Z2guIEkgc2Vu dCBkcmFmdC0xMyBvZmYgKGFuZCBpdCBnb3QgcHVibGlzaGVkKSB5ZXN0ZXJkYXkgYW5kIEkgZG9u J3Qgc2VlIHRoZSB1c2UgY2FzZSBmb3IgTGFzdC1Nb2RpZmllZCBhcyBiZWluZyB2ZXJ5IHN0cm9u Zy4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29y ZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUu DQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IGx0cnUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mDQo+IE1jRG9uYWxkLCBJcmENCj4gU2VudDogdmVuZHJlZGkgMjMg c2VwdGVtYnJlIDIwMDUgMDg6MDkNCj4gVG86ICdEb3VnIEV3ZWxsJzsgTFRSVSBXb3JraW5nIEdy b3VwDQo+IFN1YmplY3Q6IFJFOiBbTHRydV0gUmU6IE5vdGUgdG8gUkZDIGVkaXRvciBpbiBpbml0 aWFsIHJlZ2lzdHJ5DQo+IA0KPiBIaSwNCj4gDQo+IEl0J3MgcHJvYmFibHkgdG9vIGxhdGUgaW4g dGhpcyBwcm9jZXNzLCBidXQuLi4NCj4gDQo+IFRoZSBhbWJpZ3VpdHkgaW4gdGhlIGNvbnRlbnQg b2YgJ0FkZGVkJyB3b3VsZCBnbyBhd2F5IGlmDQo+IHRoZSBmaWVsZCB3ZXJlIG5hbWVkICdDcmVh dGVkJyAoY2xlYXJseSwgdGhlIGRhdGUgd291bGRuJ3QNCj4gY2hhbmdlIHdpdGggYSBtb2RpZmlj YXRpb24pLg0KPiANCj4gQ2hlZXJzLA0KPiAtIElyYQ0KPiANCj4gSXJhIE1jRG9uYWxkIChNdXNp Y2lhbiAvIFNvZnR3YXJlIEFyY2hpdGVjdCkNCj4gQmx1ZSBSb29mIE11c2ljIC8gSGlnaCBOb3J0 aCBJbmMNCj4gUE8gQm94IDIyMSAgR3JhbmQgTWFyYWlzLCBNSSAgNDk4MzkNCj4gcGhvbmU6ICsx LTkwNi00OTQtMjQzNA0KPiBlbWFpbDogaW1jZG9uYWxkQHNoYXJwbGFicy5jb20NCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddT24gQmVoYWxmIE9mDQo+ID4gRG91ZyBF d2VsbA0KPiA+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDIzLCAyMDA1IDI6MDEgQU0NCj4gPiBU bzogTFRSVSBXb3JraW5nIEdyb3VwDQo+ID4gU3ViamVjdDogW0x0cnVdIFJlOiBOb3RlIHRvIFJG QyBlZGl0b3IgaW4gaW5pdGlhbCByZWdpc3RyeQ0KPiA+DQo+ID4NCj4gPiBSYW5keSBQcmVzdWhu IDxyYW5keSB1bmRlcnNjb3JlIHByZXN1aG4gYXQgbWluZHNwcmluZyBkb3QgY29tPiB3cm90ZToN Cj4gPg0KPiA+ID4gTGV0J3Mgc2VlIHdoYXQgRG91ZyBwcm9wb3NlcyBmb3IgdGhlIG5vdGUuICBJ J2QgcGVyc29uYWxseSBwcmVmZXINCj4gPiA+IGEgcmVmZXJlbmNlIHRvIHRoZSByZWdpc3RyeSBk cmFmdCwgcmF0aGVyIHRoYW4gcHV0dGluZyBhbiBVUkwgaW50bw0KPiA+ID4gdGhlIG5vdGUgaW4g dGhlIGluaXRpYWwgcmVnaXN0cnkgZHJhZnQuICBUaGF0IHdvdWxkIGxlYXZlIGZld2VyDQo+ID4g PiBvcHBvcnR1bml0aWVzIGZvciBlcnJvciBpbiBBVVRINDguDQo+ID4NCj4gPiBJJ2xsIHByb3Bv c2Ugc29tZSBhY3R1YWwgdGV4dCBwcm9iYWJseSBGcmlkYXkgbmlnaHQgb3IgU2F0dXJkYXksIGFm dGVyDQo+ID4gSSd2ZSBoYWQgYSBiaXQgbW9yZSBzbGVlcC4NCj4gPg0KPiA+IFRoZSBzaG9ydCBh bnN3ZXIgaXMgdGhhdCBJIGFncmVlIHdpdGggUmFuZHkncyBjb21tZW50IGFib3ZlLCBhbmQgYWxz bw0KPiA+IGFncmVlIGluIHByaW5jaXBsZSB3aXRoIGhpcyBwcm9wb3NlZCB0ZXh0IHRoYXQgc2lt cGx5IHNheXMgb2YgdGhlDQo+ID4gaW5pdGlhbC1yZWdpc3RyeSB0ZXh0LCAiaXQgd2FzIGhlcmUg b25jZSwgYnV0IGhhcyBiZWVuIHN0cmlwcGVkIG91dCwiDQo+ID4gcmF0aGVyIHRoYW4gdHJ5aW5n IHRvIHNob3cgdGhlIHJlYWRlciBob3cgdG8gcmVjb25zdHJ1Y3QgdGhlIGluaXRpYWwNCj4gPiBy ZWdpc3RyeS4NCj4gPg0KPiA+IFJlY29uc3RydWN0aW5nIHRoZSBpbml0aWFsIHJlZ2lzdHJ5IHdv bid0IHdvcmsgYW55d2F5IGJlY2F1c2UgdGhlDQo+ID4gIkFkZGVkIiBkYXRlIGRvZXNuJ3QgcmVm bGVjdCBjaGFuZ2VzIChzdWNoIGFzIGEgU3VwcHJlc3MtU2NyaXB0IGZpZWxkDQo+ID4gYWRkZWQg dG8gYW4gZXhpc3RpbmcgcmVjb3JkKSwgYW5kIGFsc28gYmVjYXVzZSB0aGUgcmVjb3JkcyBmb3IN Cj4gPiBncmFuZGZhdGhlcmVkIGFuZCByZWR1bmRhbnQgdGFncyBoYXZlIGFuICJBZGRlZCIgZGF0 ZSBlcXVhbA0KPiA+IHRvIHRoZSBkYXRlDQo+ID4gdGhlIHRhZyB3YXMgYWRkZWQgdG8gdGhlIFJG QyAzMDY2IHJlZ2lzdHJ5ICh1bmxpa2UgdGhlIHN1YnRhZw0KPiA+IHJlY29yZHMpLg0KPiA+DQo+ ID4gLS0NCj4gPiBEb3VnIEV3ZWxsDQo+ID4gRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ID4gaHR0 cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTHRydSBtYWls aW5nIGxpc3QNCj4gPiBMdHJ1QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHRydQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== --===============2059458795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2059458795==-- From ltru-bounces@ietf.org Fri Sep 23 12:49:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqjk-0003Wi-SV; Fri, 23 Sep 2005 12:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqjk-0003WK-A0 for ltru@megatron.ietf.org; Fri, 23 Sep 2005 12:49:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24722 for ; Fri, 23 Sep 2005 12:49:21 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqqC-00030b-Q5 for ltru@ietf.org; Fri, 23 Sep 2005 12:56:06 -0400 Received: from h-68-165-4-173.snvacaid.dynamic.covad.net ([68.165.4.173] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EIqja-0006yN-00 for ltru@ietf.org; Fri, 23 Sep 2005 12:49:14 -0400 Message-ID: <000901c5c05f$1f764d40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050921165755.JTXF3524.edge5.adelphia.net@megatron.ietf.org><005601c5c004$1f42c980$030aa8c0@DEWELL> <6.2.3.4.2.20050923145524.03dec740@mail.afrac.org> Subject: Re: [Ltru] el truth? Date: Fri, 23 Sep 2005 09:52:02 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - Offensive, off-topic postings do not merit further comment. Randy ----- Original Message ----- > From: "r&d afrac" > To: "LTRU Working Group" > Sent: Friday, September 23, 2005 5:56 AM > Subject: [Ltru] el truth? > > http://vm666.free.fr/tmp/br504.mpg > jfc > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 12:50:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqkn-0003qx-6U; Fri, 23 Sep 2005 12:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqkl-0003ql-Hw for ltru@megatron.ietf.org; Fri, 23 Sep 2005 12:50:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24754 for ; Fri, 23 Sep 2005 12:50:25 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqrF-00032o-2X for ltru@ietf.org; Fri, 23 Sep 2005 12:57:09 -0400 Received: from h-68-165-4-173.snvacaid.dynamic.covad.net ([68.165.4.173] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EIqkk-0007Js-00 for ltru@ietf.org; Fri, 23 Sep 2005 12:50:26 -0400 Message-ID: <000e01c5c05f$4a72f0c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 23 Sep 2005 09:53:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - Please note that October 24 is a critical date for us if we are to meet October milestone for completing the matching draft! Randy ----- Original Message ----- > From: > To: > Sent: Thursday, September 22, 2005 9:00 PM > Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada > > > There are two (2) Internet-Draft cutoff dates for the 64th > IETF Meeting in Vancouver, British Columbia, Canada: > > October 17th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > October 17th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > October 10th at 9:00 AM ET. > > October 24th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, October 24th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, November 7th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 13:50:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrgh-0001x8-IG; Fri, 23 Sep 2005 13:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrgg-0001x0-Bm for ltru@megatron.ietf.org; Fri, 23 Sep 2005 13:50:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27044 for ; Fri, 23 Sep 2005 13:50:16 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIrn8-0004Q0-JB for ltru@ietf.org; Fri, 23 Sep 2005 13:56:59 -0400 Received: from alvmbxw02.prod.quest.corp ([10.1.0.209]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 10:50:02 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by alvmbxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 10:50:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] draft-matching-04 posted Date: Fri, 23 Sep 2005 10:49:51 -0700 Message-ID: Thread-Topic: [Ltru] draft-matching-04 posted thread-index: AcXAXwCFG/8z2zmESVms8uMMRAcePwAB+Y3Q From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 23 Sep 2005 17:50:01.0767 (UTC) FILETIME=[38D67370:01C5C067] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org All, I have posted an updated copy of draft-04 to my personal website and, = under separate cover, will submit it to the I-D editor in a few minutes. = There is also now a diff from -03. http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.xml http://www.inter-locale.com/ID/draft-matching-03-04-diff.html Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: vendredi 23 septembre 2005 09:53 > To: LTRU Working Group > Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the > 64thIETF Meeting in Vancouver, British Columbia, Canada >=20 > Hi - >=20 > Please note that October 24 is a critical date for us if we are to = meet > October milestone for completing the matching draft! >=20 > Randy >=20 > ----- Original Message ----- > > From: > > To: > > Sent: Thursday, September 22, 2005 9:00 PM > > Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF > Meeting in Vancouver, British Columbia, Canada > > > > > > There are two (2) Internet-Draft cutoff dates for the 64th > > IETF Meeting in Vancouver, British Columbia, Canada: > > > > October 17th: Cutoff Date for Initial (i.e., version -00) > > Internet-Draft Submissions > > > > All initial Internet-Drafts (version -00) must be submitted by = Monday, > > October 17th at 9:00 AM ET. As always, all initial submissions with = a > > filename beginning with "draft-ietf" must be approved by the > > appropriate WG Chair before they can be processed or announced. The > > Secretariat would appreciate receiving WG Chair approval by Monday, > > October 10th at 9:00 AM ET. > > > > October 24th: Cutoff Date for Revised (i.e., version -01 and higher) > > Internet-Draft Submissions > > > > All revised Internet-Drafts (version -01 and higher) must be = submitted > > by Monday, October 24th at 9:00 AM ET. > > > > Initial and revised Internet-Drafts received after their respective > > cutoff dates will not be made available in the Internet-Drafts > > directory or announced until on or after Monday, November 7th at = 9:00 > > AM ET, when Internet-Draft posting resumes. Please do not wait = until > > the last minute to submit. > > > > Thank you for your understanding and cooperation. If you have any > > questions or concerns, then please send a message to > > internet-drafts@ietf.org. > > > > The IETF Secretariat > > > > FYI: The Internet-Draft cutoff dates as well as other significant = dates > > for the 64th IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_64.html. > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 13:51:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIri1-0002Bp-2f; Fri, 23 Sep 2005 13:51:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrhz-0002Bb-5h; Fri, 23 Sep 2005 13:51:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27075; Fri, 23 Sep 2005 13:51:14 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIro4-0004R3-UQ; Fri, 23 Sep 2005 13:57:58 -0400 Received: from alvmbxw02.prod.quest.corp ([10.1.0.209]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 10:51:03 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by alvmbxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 10:51:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5C067.5CFE040A" Date: Fri, 23 Sep 2005 10:50:51 -0700 Message-ID: X-MS-Has-Attach: yes Thread-Topic: submission: ietf-ltru-matching-04 thread-index: AcXAZ1ZxBse9vMlqQc62gIlNw+BlFw== From: "Addison Phillips" To: X-OriginalArrivalTime: 23 Sep 2005 17:51:02.0906 (UTC) FILETIME=[5D4785A0:01C5C067] X-Spam-Score: 0.0 (/) X-Scan-Signature: 826b8da4948b827b02e4b599895c9e48 Cc: LTRU Working Group Subject: [Ltru] submission: ietf-ltru-matching-04 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C067.5CFE040A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGluIHRleHQgZm9ybWF0IGRyYWZ0 LTA0IG9mIGRyYWZ0LWlldGYtbHRydS1tYXRjaGluZy4NCg0KVGhhbmtzLA0KDQpBZGRpc29uIChm b3IgdGhlIGVkaXRvcnMpDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJj aGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFcz QyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMu b3JnL0ludGVybmF0aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVy ZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg== ------_=_NextPart_001_01C5C067.5CFE040A Content-Type: text/plain; name="draft-ietf-ltru-matching-04.txt" Content-Description: draft-ietf-ltru-matching-04.txt Content-Disposition: attachment; filename="draft-ietf-ltru-matching-04.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IE1hcmNoIDI3 LCAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjMsIDIwMDUNCg0KDQogICAgICAgICAgIE1hdGNoaW5n IFRhZ3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBvZiBMYW5ndWFnZXMNCiAgICAgICAgICAgICAg ICAgICAgICBkcmFmdC1pZXRmLWx0cnUtbWF0Y2hpbmctMDQNCg0KU3RhdHVzIG9mIHRoaXMgTWVt bw0KDQogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJl cHJlc2VudHMgdGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFp bXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBk aXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdp bGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJu ZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0 cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRl ZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0 ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2Yg SW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAg aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFm dCB3aWxsIGV4cGlyZSBvbiBNYXJjaCAyNywgMjAwNi4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQog ICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4NCg0KQWJzdHJhY3QN Cg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZGlmZmVyZW50IG1lY2hhbmlzbXMgZm9yIGNv bXBhcmluZywgbWF0Y2hpbmcsDQogICBhbmQgZXZhbHVhdGluZyBsYW5ndWFnZSB0YWdzLiAgUG9z c2libGUgYWxnb3JpdGhtcyBmb3IgbGFuZ3VhZ2UNCiAgIG5lZ290aWF0aW9uIGFuZCBjb250ZW50 IHNlbGVjdGlvbiBhcmUgZGVzY3JpYmVkLg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNywgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAg ICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRy b2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMw0KICAgMi4gIFRoZSBMYW5ndWFnZSBSYW5nZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDIuMSAgIEJhc2ljIExhbmd1YWdlIFJhbmdlIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgICAgICAyLjEuMSAgIE1h dGNoaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0K ICAgICAgIDIuMS4yICAgTG9va3VwIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA2DQogICAgIDIuMiAgIEV4dGVuZGVkIExhbmd1YWdlIFJhbmdlICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgICAyLjIuMSAgIEV4dGVuZGVk IFJhbmdlIE1hdGNoaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAg IDIuMi4yICAgRXh0ZW5kZWQgUmFuZ2UgTG9va3VwICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA5DQogICAgICAgMi4yLjMgICBEaXN0YW5jZSBNZXRyaWMgU2NoZW1lIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgICAgMi4zICAgTWVhbmluZyBvZiBMYW5ndWFn ZSBUYWdzIGFuZCBSYW5nZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KICAgICAyLjQgICBD aG9vc2luZyBCZXR3ZWVuIEFsdGVybmF0ZSBNYXRjaGluZyBTY2hlbWVzICAuIC4gLiAuIC4gLiAu IDEzDQogICAgIDIuNSAgIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRlIFVzZSBTdWJ0YWdzIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgICAgMi42ICAgTGVuZ3RoIENvbnNpZGVyYXRpb25zIGlu IE1hdGNoaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgMy4gIElBTkEgQ29uc2lk ZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQog ICA0LiAgQ2hhbmdlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTgNCiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQ0KICAgNi4gIENoYXJhY3RlciBTZXQgQ29u c2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDQogICA3LiAg UmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjENCiAgICAgNy4xICAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQ0KICAgICA3LjIgICBJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQogICAgICAgQXV0aG9y cycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjMNCiAgIEEuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAyNA0KICAgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29w eXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIDI1DQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg IEV4cGlyZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2Vw dGVtYmVyIDIwMDUNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIEh1bWFuIGJlaW5ncyBvbiBv dXIgcGxhbmV0IGhhdmUsIHBhc3QgYW5kIHByZXNlbnQsIHVzZWQgYSBudW1iZXIgb2YNCiAgIGxh bmd1YWdlcy4gIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgd2h5IG9uZSB3b3VsZCB3YW50IHRvIGlk ZW50aWZ5IHRoZQ0KICAgbGFuZ3VhZ2UgdXNlZCB3aGVuIHByZXNlbnRpbmcgb3IgcmVxdWVzdGlu ZyBpbmZvcm1hdGlvbi4NCg0KICAgSW5mb3JtYXRpb24gYWJvdXQgYSB1c2VyJ3MgbGFuZ3VhZ2Ug cHJlZmVyZW5jZXMgY29tbW9ubHkgbmVlZHMgdG8gYmUNCiAgIGlkZW50aWZpZWQgc28gdGhhdCBh cHByb3ByaWF0ZSBwcm9jZXNzaW5nIGNhbiBiZSBhcHBsaWVkLiAgRm9yDQogICBleGFtcGxlLCB0 aGUgdXNlcidzIGxhbmd1YWdlIHByZWZlcmVuY2VzIGluIGEgYnJvd3NlciBjYW4gYmUgdXNlZCB0 bw0KICAgc2VsZWN0IHdlYiBwYWdlcyBhcHByb3ByaWF0ZWx5LiAgQSBjaG9pY2Ugb2YgbGFuZ3Vh Z2UgcHJlZmVyZW5jZSBjYW4NCiAgIGFsc28gYmUgdXNlZCB0byBzZWxlY3QgYW1vbmcgdG9vbHMg KHN1Y2ggYXMgZGljdGlvbmFyaWVzKSB0byBhc3Npc3QNCiAgIGluIHRoZSBwcm9jZXNzaW5nIG9y IHVuZGVyc3RhbmRpbmcgb2YgY29udGVudCBpbiBkaWZmZXJlbnQgbGFuZ3VhZ2VzLg0KDQogICBH aXZlbiBhIHNldCBvZiBsYW5ndWFnZSBpZGVudGlmaWVycywgc3VjaCBhcyB0aG9zZSBkZWZpbmVk IGluIFtkcmFmdC0NCiAgIHJlZ2lzdHJ5XSwgdmFyaW91cyBtZWNoYW5pc21zIGNhbiBiZSBlbnZp c2lvbmVkIGZvciBwZXJmb3JtaW5nDQogICBsYW5ndWFnZSBuZWdvdGlhdGlvbiBhbmQgdGFnIG1h dGNoaW5nLiAgVGhlIHN1aXRhYmlsaXR5IG9mIGENCiAgIHBhcnRpY3VsYXIgbWVjaGFuaXNtIHRv IGEgcGFydGljdWxhciBhcHBsaWNhdGlvbiBkZXBlbmRzIG9uIHRoZSBuZWVkcw0KICAgb2YgdGhh dCBhcHBsaWNhdGlvbi4NCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHNldmVyYWwgbWVjaGFu aXNtcyBmb3IgbWF0Y2hpbmcgYW5kIGZpbHRlcmluZw0KICAgbmF0dXJhbCBsYW5ndWFnZSBjb250 ZW50IGlkZW50aWZpZWQgdXNpbmcgTGFuZ3VhZ2UgVGFncyBbZHJhZnQtDQogICByZWdpc3RyeV0u ICBJdCBhbHNvIGRlZmluZXMgdGhlIHN5bnRheCAoY2FsbGVkIGEgImxhbmd1YWdlIHJhbmdlIikN CiAgIGFzc29jaWF0ZWQgd2l0aCBlYWNoIG9mIHRoZXNlIG1lY2hhbmlzbXMgZm9yIHNwZWNpZnlp bmcgdXNlciBsYW5ndWFnZQ0KICAgcHJlZmVyZW5jZXMuDQoNCiAgIFRoZSBrZXl3b3JkcyAiTVVT VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gW1JGQzIxMTldLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI3LCAyMDA2ICAgICAg ICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRy dS1tYXRjaGluZyAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KMi4gIFRoZSBMYW5n dWFnZSBSYW5nZQ0KDQogICBMYW5ndWFnZSBUYWdzIFtkcmFmdC1yZWdpc3RyeV0gYXJlIHVzZWQg dG8gaWRlbnRpZnkgdGhlIGxhbmd1YWdlIG9mDQogICBzb21lIGluZm9ybWF0aW9uIGl0ZW0gb3Ig Y29udGVudC4gIEFwcGxpY2F0aW9ucyB0aGF0IHVzZSBsYW5ndWFnZQ0KICAgdGFncyBhcmUgb2Z0 ZW4gZmFjZWQgd2l0aCB0aGUgcHJvYmxlbSBvZiBpZGVudGlmeWluZyBzZXRzIG9mIGNvbnRlbnQN CiAgIHRoYXQgc2hhcmUgY2VydGFpbiBsYW5ndWFnZSBhdHRyaWJ1dGVzLiAgRm9yIGV4YW1wbGUs IEhUVFAgMS4xDQogICBbUkZDMjYxNl0gZGVzY3JpYmVzIGxhbmd1YWdlIHJhbmdlcyBpbiBpdHMg ZGlzY3Vzc2lvbiBvZiB0aGUgQWNjZXB0LQ0KICAgTGFuZ3VhZ2UgaGVhZGVyIChTZWN0aW9uIDE0 LjQpLCB3aGljaCBpcyB1c2VkIGZvciBzZWxlY3RpbmcgY29udGVudA0KICAgZnJvbSBzZXJ2ZXJz IGJhc2VkIG9uIHRoZSBsYW5ndWFnZSBvZiB0aGF0IGNvbnRlbnQuDQoNCiAgIFdoZW4gc2VsZWN0 aW5nIGNvbnRlbnQgYWNjb3JkaW5nIHRvIGl0cyBsYW5ndWFnZSwgaXQgaXMgdXNlZnVsIHRvDQog ICBoYXZlIGEgbWVjaGFuaXNtIGZvciBpZGVudGlmeWluZyBzZXRzIG9mIGxhbmd1YWdlIHRhZ3Mg dGhhdCBzaGFyZQ0KICAgc3BlY2lmaWMgYXR0cmlidXRlcy4gIFRoaXMgYWxsb3dzIHVzZXJzIHRv IHNlbGVjdCBvciBmaWx0ZXIgY29udGVudA0KICAgYmFzZWQgb24gc3BlY2lmaWMgcmVxdWlyZW1l bnRzLiAgU3VjaCBhbiBpZGVudGlmaWVyIGlzIGNhbGxlZCBhDQogICAiTGFuZ3VhZ2UgUmFuZ2Ui Lg0KDQoyLjEgIEJhc2ljIExhbmd1YWdlIFJhbmdlDQoNCiAgIEEgYmFzaWMgbGFuZ3VhZ2UgcmFu Z2UgaWRlbnRpZmllcyB0aGUgc2V0IG9mIGNvbnRlbnQgd2hvc2UgbGFuZ3VhZ2UNCiAgIHRhZ3Mg YmVnaW4gd2l0aCB0aGUgc2FtZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzLiAgQmFzaWMgbGFuZ3VhZ2Ug cmFuZ2VzDQogICBhcmUgZGVzY3JpYmVkIGluIFtSRkMzMDY2XSBhbmQgSFRUUCAxLjEgW1JGQzI2 MTZdICh3aGVyZSB0aGV5IGFyZQ0KICAgcmVmZXJyZWQgdG8gYXMgc2ltcGx5IGEgImxhbmd1YWdl IHJhbmdlIikuICBBIGJhc2ljIGxhbmd1YWdlIHJhbmdlIGlzDQogICBpZGVudGlmaWVkIGJ5IGl0 cyAnbGFuZ3VhZ2UtcmFuZ2UnIHRhZywgYnkgYWRhcHRpbmcgdGhlDQogICBBQk5GW1JGQzIyMzRi aXNdIGZyb20gSFRUUC8xLjEgW1JGQzI2MTZdIDoNCg0KICAgbGFuZ3VhZ2UtcmFuZ2UgPSBsYW5n dWFnZS10YWcgLyAiKiINCiAgIGxhbmd1YWdlLXRhZyAgID0gMSo4W2FscGhhbnVtXSAqWyItIiAx KjhhbHBoYW51bV0NCiAgIGFscGhhbnVtICAgICAgID0gQUxQSEEgLyBESUdJVA0KDQogICBUaGF0 IGlzLCBhIGxhbmd1YWdlLXJhbmdlIGhhcyB0aGUgc2FtZSBzeW50YXggYXMgYSBsYW5ndWFnZS10 YWcgb3IgaXMNCiAgIHRoZSBzaW5nbGUgY2hhcmFjdGVyICIqIi4gIEJhc2ljIExhbmd1YWdlIFJh bmdlcyBpbXBseSB0aGF0IHRoZXJlIGlzDQogICBhIHNlbWFudGljIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIGxhbmd1YWdlIHRhZ3MgdGhhdCBzaGFyZSB0aGUgc2FtZQ0KICAgcHJlZml4LiAgV2hpbGUg dGhpcyBpcyBvZnRlbiB0aGUgY2FzZSwgaXQgaXMgbm90IGFsd2F5cyB0cnVlLg0KDQogICBJbiBw YXJ0aWN1bGFyLCB0aGUgc2V0IG9mIGxhbmd1YWdlIHRhZ3MgdGhhdCBtYXRjaCBhIHNwZWNpZmlj DQogICBsYW5ndWFnZS1yYW5nZSBtaWdodCBub3QgYWxsIGJlIG11dHVhbGx5IGludGVsbGlnaWJs ZS4gIE1hdGNoaW5nIGENCiAgIGxhbmd1YWdlLXJhbmdlIChwcmVmaXgpIHRvIHZhcmlvdXMgbGFu Z3VhZ2UgdGFncyBkb2VzIG5vdCBtZWFuIHRoYXQNCiAgIGl0IGlzIGFsd2F5cyB0cnVlIHRoYXQg aWYgYSB1c2VyIHVuZGVyc3RhbmRzIGEgbGFuZ3VhZ2UgaWRlbnRpZmllZCBieQ0KICAgYSBjZXJ0 YWluIHRhZywgdGhlbiB0aGlzIHVzZXIgd2lsbCBhbHNvIHVuZGVyc3RhbmQgYWxsIG9mIHRoZQ0K ICAgbGFuZ3VhZ2VzIGZvciB3aGljaCB0aGlzIHRhZyBpcyBhIHByZWZpeC4gIFRoZSB1c2Ugb2Yg cHJlZml4ZXMgKGFuZA0KICAgdGh1cyBiYXNpYyBsYW5ndWFnZSByYW5nZXMpIHNpbXBseSBhbGxv d3MgdGhlIHVzZSBvZiBhIHByZWZpeCBpZiB0aGlzDQogICBpcyB0aGUgY2FzZS4NCg0KICAgTGFu Z3VhZ2UgdGFncyBhbmQgdGh1cyBsYW5ndWFnZSByYW5nZXMgYXJlIHRvIGJlIHRyZWF0ZWQgYXMg Y2FzZQ0KICAgaW5zZW5zaXRpdmU6IHRoZXJlIGV4aXN0IGNvbnZlbnRpb25zIGZvciB0aGUgY2Fw aXRhbGl6YXRpb24gb2Ygc29tZQ0KICAgb2YgdGhlIHN1YnRhZ3MsIGJ1dCB0aGVzZSBNVVNUIE5P VCBiZSB0YWtlbiB0byBjYXJyeSBtZWFuaW5nLg0KICAgTWF0Y2hpbmcgb2YgbGFuZ3VhZ2UgdGFn cyB0byBsYW5ndWFnZSByYW5nZXMgTVVTVCBiZSBkb25lIGluIGEgY2FzZQ0KICAgaW5zZW5zaXRp dmUgbWFubmVyLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2gg MjcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0K DQogICBXaGVuIHdvcmtpbmcgd2l0aCB0YWdzIGFuZCByYW5nZXMgdXNlcnMgU0hPVUxEIGFsc28g bm90ZSB0aGUNCiAgIGZvbGxvd2luZzoNCg0KICAgMS4gIFByaXZhdGUtdXNlIGFuZCBFeHRlbnNp b24gc3VidGFncyBhcmUgbm9ybWFsbHkgb3J0aG9nb25hbCB0bw0KICAgICAgIGxhbmd1YWdlIHRh ZyBmYWxsYmFjay4gIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgaWdub3JlDQogICAgICAgdW5yZWNv Z25pemVkIHByaXZhdGUtdXNlIGFuZCBleHRlbnNpb24gc3VidGFncyB3aGVuIHBlcmZvcm1pbmcN CiAgICAgICBsYW5ndWFnZSB0YWcgZmFsbGJhY2suICBTaW5jZSB0aGVzZSBzdWJ0YWdzIGFyZSBh bHdheXMgYXQgdGhlIGVuZA0KICAgICAgIG9mIHRoZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzLCB0aGV5 IGRvbid0IG5vcm1hbGx5IGludGVyZmVyZSB3aXRoDQogICAgICAgdGhlIHVzZSBvZiBwcmVmaXhl cyBmb3IgbWF0Y2hpbmcgaW4gdGhlIHNjaGVtZXMgZGVzY3JpYmVkIGJlbG93Lg0KDQogICAyLiAg SW1wbGVtZW50YXRpb25zIHRoYXQgY2hvb3NlIG5vdCB0byBpbnRlcnByZXQgb25lIG9yIG1vcmUg cHJpdmF0ZS0NCiAgICAgICB1c2Ugb3IgZXh0ZW5zaW9uIHN1YnRhZ3MgU0hPVUxEIE5PVCByZW1v dmUgb3IgbW9kaWZ5IHRoZXNlDQogICAgICAgZXh0ZW5zaW9ucyBpbiBjb250ZW50IHRoYXQgdGhl eSBhcmUgcHJvY2Vzc2luZy4gIFdoZW4gYSBsYW5ndWFnZQ0KICAgICAgIHRhZyBpbnN0YW5jZSBp cyB0byBiZSB1c2VkIGluIGEgc3BlY2lmaWMsIGtub3duIHByb3RvY29sLCBhbmQgaXMNCiAgICAg ICBub3QgYmVpbmcgcGFzc2VkIHRocm91Z2ggdG8gb3RoZXIgcHJvdG9jb2xzLCBsYW5ndWFnZSB0 YWdzIE1BWSBiZQ0KICAgICAgIGZpbHRlcmVkIHRvIHJlbW92ZSBzdWJ0YWdzIGFuZCBleHRlbnNp b25zIHRoYXQgYXJlIG5vdCBzdXBwb3J0ZWQNCiAgICAgICBieSB0aGF0IHByb3RvY29sLiAgU3Vj aCBmaWx0ZXJpbmcgU0hPVUxEIGJlIGF2b2lkZWQsIGlmIHBvc3NpYmxlLA0KICAgICAgIHNpbmNl IGl0IHJlbW92ZXMgaW5mb3JtYXRpb24gdGhhdCBtaWdodCBiZSByZWxldmFudCBpZiBzZXJ2aWNl cw0KICAgICAgIG9uIHRoZSBvdGhlciBlbmQgb2YgdGhlIHByb3RvY29sIHdvdWxkIG1ha2UgdXNl IG9mIHRoYXQNCiAgICAgICBpbmZvcm1hdGlvbi4NCg0KICAgMy4gIFNvbWUgYXBwbGljYXRpb25z IG9mIGxhbmd1YWdlIHRhZ3MgbWlnaHQgd2FudCBvciBuZWVkIHRvIGNvbnNpZGVyDQogICAgICAg ZXh0ZW5zaW9ucyBhbmQgcHJpdmF0ZS11c2Ugc3VidGFncyB3aGVuIG1hdGNoaW5nIHRhZ3MuICBJ Zg0KICAgICAgIGV4dGVuc2lvbnMgYW5kIHByaXZhdGUtdXNlIHN1YnRhZ3MgYXJlIGluY2x1ZGVk IGluIGEgbWF0Y2hpbmcgb3INCiAgICAgICBmaWx0ZXJpbmcgcHJvY2VzcyB0aGF0IHV0aWxpemVz IHRoZSBvbmUgb2YgdGhlIHNjaGVtZXMgZGVzY3JpYmVkDQogICAgICAgaW4gdGhpcyBkb2N1bWVu dCwgdGhlbiB0aGUgaW1wbGVtZW50YXRpb24gU0hPVUxEIGNhbm9uaWNhbGl6ZSB0aGUNCiAgICAg ICBsYW5ndWFnZSB0YWdzIGFuZC9vciByYW5nZXMgYmVmb3JlIHBlcmZvcm1pbmcgdGhlIG1hdGNo aW5nLiAgTm90ZQ0KICAgICAgIHRoYXQgbGFuZ3VhZ2UgdGFnIHByb2Nlc3NvcnMgdGhhdCBjbGFp bSB0byBiZSAid2VsbC1mb3JtZWQiDQogICAgICAgcHJvY2Vzc29ycyBhcyBkZWZpbmVkIGluIFtk cmFmdC1yZWdpc3RyeV0gZ2VuZXJhbGx5IGZhbGwgaW50bw0KICAgICAgIHRoaXMgY2F0ZWdvcnku DQoNCiAgIFRoZXJlIGFyZSB0d28gbWF0Y2hpbmcgc2NoZW1lcyB0aGF0IGFyZSBjb21tb25seSBh c3NvY2lhdGVkIHdpdGgNCiAgIGJhc2ljIGxhbmd1YWdlIHJhbmdlczogIG1hdGNoaW5nIGFuZCBs b29rdXAuDQoNCiAgIE5vdGUgdGhhdCBuZWl0aGVyIG1hdGNoaW5nIG5vciBsb29rdXAgdXNpbmcg YmFzaWMgbGFuZ3VhZ2UgcmFuZ2VzDQogICBhdHRlbXB0IHRvIHByb2Nlc3MgdGhlIHNlbWFudGlj cyBvZiB0aGUgdGFncyBvciByYW5nZXMgaW4gYW55IHdheS4NCiAgIFRoZSBsYW5ndWFnZSB0YWcg YW5kIGxhbmd1YWdlIHJhbmdlIGFyZSBjb21wYXJlZCBpbiBhIGNhc2UNCiAgIGluc2Vuc2l0aXZl IG1hbm5lciB1c2luZyBiYXNpYyBzdHJpbmcgcHJvY2Vzc2luZy4gIFRoZSBjaG9pY2Ugb2YNCiAg IHN1YnRhZ3MgaW4gYm90aCB0aGUgbGFuZ3VhZ2UgdGFnIGFuZCBsYW5ndWFnZSByYW5nZSBtYXkg YWZmZWN0IHRoZQ0KICAgcmVzdWx0cyBwcm9kdWNlZCBhcyBhIHJlc3VsdC4NCg0KMi4xLjEgIE1h dGNoaW5nDQoNCiAgIExhbmd1YWdlIHRhZyBtYXRjaGluZyBpcyB1c2VkIHRvIHNlbGVjdCBhbGwg Y29udGVudCB0aGF0IG1hdGNoZXMgYQ0KICAgZ2l2ZW4gcHJlZml4LiAgSW4gbWF0Y2hpbmcsIHRo ZSBsYW5ndWFnZSByYW5nZSByZXByZXNlbnRzIHRoZSBsZWFzdA0KICAgc3BlY2lmaWMgdGFnIHdo aWNoIGlzIGFuIGFjY2VwdGFibGUgbWF0Y2ggYW5kIGV2ZXJ5IHBpZWNlIG9mIGNvbnRlbnQNCiAg IHRoYXQgbWF0Y2hlcyBpcyByZXR1cm5lZC4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgIEV4cGlyZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMDUNCg0KDQogICBGb3IgZXhhbXBsZSwgaWYgYW4gYXBwbGljYXRpb24gaXMg YXBwbHlpbmcgYSBzdHlsZSB0byBhbGwgY29udGVudCBpbg0KICAgYSBkb2N1bWVudCBpbiBhIHBh cnRpY3VsYXIgbGFuZ3VhZ2UsIGl0IG1pZ2h0IHVzZSBsYW5ndWFnZSB0YWcNCiAgIG1hdGNoaW5n IHRvIHNlbGVjdCB0aGUgY29udGVudCB0byB3aGljaCB0aGUgc3R5bGUgaXMgYXBwbGllZC4NCg0K ICAgQSBsYW5ndWFnZS1yYW5nZSBtYXRjaGVzIGEgbGFuZ3VhZ2UtdGFnIGlmIGl0IGV4YWN0bHkg ZXF1YWxzIHRoZSB0YWcsDQogICBvciBpZiBpdCBleGFjdGx5IGVxdWFscyBhIHByZWZpeCBvZiB0 aGUgdGFnIHN1Y2ggdGhhdCB0aGUgZmlyc3QNCiAgIGNoYXJhY3RlciBmb2xsb3dpbmcgdGhlIHBy ZWZpeCBpcyAiLSIuICAoVGhhdCBpcywgdGhlIGxhbmd1YWdlLXJhbmdlDQogICAiZGUtZGUiIG1h dGNoZXMgdGhlIGxhbmd1YWdlIHRhZyAiZGUtREUtMTk5NiIsIGJ1dCBub3QgdGhlIGxhbmd1YWdl DQogICB0YWcgImRlLURldmEiLikNCg0KICAgVGhlIHNwZWNpYWwgcmFuZ2UgIioiIG1hdGNoZXMg YW55IHRhZy4gIEEgcHJvdG9jb2wgd2hpY2ggdXNlcw0KICAgbGFuZ3VhZ2UgcmFuZ2VzIE1BWSBz cGVjaWZ5IGFkZGl0aW9uYWwgcnVsZXMgYWJvdXQgdGhlIHNlbWFudGljcyBvZg0KICAgIioiOyBm b3IgaW5zdGFuY2UsIEhUVFAvMS4xIHNwZWNpZmllcyB0aGF0IHRoZSByYW5nZSAiKiIgbWF0Y2hl cyBvbmx5DQogICBsYW5ndWFnZXMgbm90IG1hdGNoZWQgYnkgYW55IG90aGVyIHJhbmdlIHdpdGhp biBhbiAiQWNjZXB0LUxhbmd1YWdlIg0KICAgaGVhZGVyLg0KDQoyLjEuMiAgTG9va3VwDQoNCiAg IENvbnRlbnQgbG9va3VwIGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzaW5nbGUgaW5mb3JtYXRpb24g aXRlbSB0aGF0DQogICBiZXN0IG1hdGNoZXMgdGhlIGxhbmd1YWdlIHJhbmdlIGZvciBhIGdpdmVu IHJlcXVlc3QuICBJbiBsb29rdXAsIHRoZQ0KICAgbGFuZ3VhZ2UgcmFuZ2UgcmVwcmVzZW50cyB0 aGUgbW9zdCBzcGVjaWZpYyB0YWcgd2hpY2ggaXMgYW4NCiAgIGFjY2VwdGFibGUgbWF0Y2ggYW5k IG9ubHkgdGhlIGNsb3Nlc3QgbWF0Y2hpbmcgaXRlbSBpcyByZXR1cm5lZC4NCg0KICAgRm9yIGV4 YW1wbGUsIGlmIGFuIGFwcGxpY2F0aW9uIGluc2VydHMgc29tZSBkeW5hbWljIGNvbnRlbnQgaW50 byBhDQogICBkb2N1bWVudCwgcmV0dXJuaW5nIGFuIGVtcHR5IHN0cmluZyBpZiB0aGVyZSBpcyBu byBleGFjdCBtYXRjaCBpcyBub3QNCiAgIGFuIG9wdGlvbi4gIEluc3RlYWQsIHRoZSBhcHBsaWNh dGlvbiAiZmFsbHMgYmFjayIgdW50aWwgaXQgZmluZHMgYQ0KICAgc3VpdGFibGUgcGllY2Ugb2Yg Y29udGVudCB0byBpbnNlcnQuDQoNCiAgIFdoZW4gcGVyZm9ybWluZyBsb29rdXAsIHRoZSBsYW5n dWFnZSByYW5nZSBpcyBwcm9ncmVzc2l2ZWx5IHRydW5jYXRlZA0KICAgZnJvbSB0aGUgZW5kIHVu dGlsIGEgbWF0Y2hpbmcgcGllY2Ugb2YgY29udGVudCBpcyBsb2NhdGVkLiAgRm9yDQogICBleGFt cGxlLCBzdGFydGluZyB3aXRoIHRoZSByYW5nZSAiemgtSGFudC1DTi14LXdhZGVnaWxlIiwgdGhl IGxvb2t1cA0KICAgd291bGQgcHJvZ3Jlc3NpdmVseSBzZWFyY2ggZm9yIGNvbnRlbnQgYXMgc2hv d24gYmVsb3c6DQoNCiAgIFJhbmdlIHRvIG1hdGNoOiB6aC1IYW50LUNOLXgtd2FkZWdpbGUNCiAg IDEuIHpoLUhhbnQtQ04teC13YWRlZ2lsZQ0KICAgMi4gemgtSGFudC1DTg0KICAgMy4gemgtSGFu dA0KICAgNC4gemgNCiAgIDUuIChkZWZhdWx0IGNvbnRlbnQgb3IgdGhlIGVtcHR5IHRhZykNCg0K ICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBEZWZhdWx0IEZhbGxiYWNrIFBhdHRlcm4gRXhhbXBs ZQ0KDQogICBUaGlzIHNjaGVtZSBhbGxvd3Mgc29tZSBmbGV4aWJpbGl0eSBpbiBmaW5kaW5nIGNv bnRlbnQuICBJdCBhbHNvDQogICB0eXBpY2FsbHkgcHJvdmlkZXMgYmV0dGVyIHJlc3VsdHMgd2hl biBkYXRhIGlzIG5vdCBhdmFpbGFibGUgYXQgYQ0KICAgc3BlY2lmaWMgbGV2ZWwgb2YgdGFnIGdy YW51bGFyaXR5IG9yIGlzIHNwYXJzZWx5IHBvcHVsYXRlZCAodGhhbiBpZg0KICAgdGhlIGRlZmF1 bHQgbGFuZ3VhZ2UgZm9yIHRoZSBzeXN0ZW0gb3IgY29udGVudCB3ZXJlIHVzZWQpLg0KDQoNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI3LCAyMDA2ICAgICAg ICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRy dS1tYXRjaGluZyAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KMi4yICBFeHRlbmRl ZCBMYW5ndWFnZSBSYW5nZQ0KDQogICBQcmVmaXggbWF0Y2hpbmcgdXNpbmcgYSBCYXNpYyBMYW5n dWFnZSBSYW5nZSwgYXMgZGVzY3JpYmVkIGFib3ZlLCBpcw0KICAgbm90IGFsd2F5cyB0aGUgbW9z dCBhcHByb3ByaWF0ZSB3YXkgdG8gYWNjZXNzIHRoZSBpbmZvcm1hdGlvbg0KICAgY29udGFpbmVk IGluIGxhbmd1YWdlIHRhZ3Mgd2hlbiBzZWxlY3Rpbmcgb3IgZmlsdGVyaW5nIGNvbnRlbnQuICBT b21lDQogICBhcHBsaWNhdGlvbnMgbWlnaHQgd2lzaCB0byBkZWZpbmUgYSBtb3JlIGdyYW51bGFy IG1hdGNoaW5nIHNjaGVtZSBhbmQNCiAgIHN1Y2ggYSBtYXRjaGluZyBzY2hlbWUgcmVxdWlyZXMg dGhlIGFiaWxpdHkgdG8gc3BlY2lmeSB0aGUgdmFyaW91cw0KICAgYXR0cmlidXRlcyBvZiBhIGxh bmd1YWdlIHRhZyBpbiB0aGUgbGFuZ3VhZ2UgcmFuZ2UuICBBbiBleHRlbmRlZA0KICAgbGFuZ3Vh Z2UgcmFuZ2UgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IHRoZSBmb2xsb3dpbmcgQUJORjoNCiAgIGV4 dGVuZGVkLWxhbmd1YWdlLXJhbmdlICA9IHJhbmdlIDsgYSByYW5nZQ0KICAgICAgICAgICAgICAg ICAvIHByaXZhdGV1c2UgICAgICAgICAgICAgIDsgcHJpdmF0ZSB1c2UgdGFnDQogICAgICAgICAg ICAgICAgIC8gZ3JhbmRmYXRoZXJlZCAgICAgICAgICAgOyBncmFuZGZhdGhlcmVkIHJlZ2lzdHJh dGlvbnMNCg0KICAgcmFuZ2UgICAgICAgICA9IChsYW5ndWFnZQ0KICAgICAgICAgICAgICAgICAg ICBbIi0iIHNjcmlwdF0NCiAgICAgICAgICAgICAgICAgICAgWyItIiByZWdpb25dDQogICAgICAg ICAgICAgICAgICAgICooIi0iIHZhcmlhbnQpDQogICAgICAgICAgICAgICAgICAgICooIi0iIGV4 dGVuc2lvbikNCiAgICAgICAgICAgICAgICAgICAgWyItIiBwcml2YXRldXNlXSkNCg0KICAgbGFu Z3VhZ2UgICAgICA9ICgyKjNBTFBIQSBbIGV4dGxhbmcgXSkgOyBzaG9ydGVzdCBJU08gNjM5IGNv ZGUNCiAgICAgICAgICAgICAgICAgLyA0QUxQSEEgICAgICAgICAgICAgICAgIDsgcmVzZXJ2ZWQg Zm9yIGZ1dHVyZSB1c2UNCiAgICAgICAgICAgICAgICAgLyA1KjhBTFBIQSAgICAgICAgICAgICAg IDsgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcNCiAgICAgICAgICAgICAgICAgLyAiKiIgICAg ICAgICAgICAgICAgICAgIDsgLi4uIG9yIHdpbGRjYXJkDQoNCiAgIGV4dGxhbmcgICAgICAgPSAq MigiLSIgM0FMUEhBKSAoIi0iICggM0FMUEhBIC8gIioiKSkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgd2lsZGNhcmQgY2FuIG9ubHkgYXBw ZWFyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7ICAgYXQgdGhl IGVuZA0KDQogICBzY3JpcHQgICAgICAgID0gNEFMUEhBICAgICAgICAgICAgICAgICA7IElTTyAx NTkyNCBjb2RlDQogICAgICAgICAgICAgICAgIC8gIioiICAgICAgICAgICAgICAgICAgICA7IG9y IHdpbGRjYXJkDQoNCiAgIHJlZ2lvbiAgICAgICAgPSAyQUxQSEEgICAgICAgICAgICAgICAgIDsg SVNPIDMxNjYgY29kZQ0KICAgICAgICAgICAgICAgICAvIDNESUdJVCAgICAgICAgICAgICAgICAg OyBVTiBNLjQ5IGNvZGUNCiAgICAgICAgICAgICAgICAgLyAiKiIgICAgICAgICAgICAgICAgICAg IDsgLi4uIG9yIHdpbGRjYXJkDQoNCiAgIHZhcmlhbnQgICAgICAgPSA1KjhhbHBoYW51bSAgICAg ICAgICAgIDsgcmVnaXN0ZXJlZCB2YXJpYW50cw0KICAgICAgICAgICAgICAgICAvIChESUdJVCAz YWxwaGFudW0pICAgICAgOw0KICAgICAgICAgICAgICAgICAvICIqIiAgICAgICAgICAgICAgICAg ICAgOyAuLi4gb3Igd2lsZGNhcmQNCg0KICAgZXh0ZW5zaW9uICAgICA9IHNpbmdsZXRvbiAqKCIt IiAoMio4YWxwaGFudW0pKSBbICItKiIgXQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgOyBleHRlbnNpb24gc3VidGFncw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgOyB3aWxkY2FyZCBjYW4gb25seSBhcHBlYXINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgICBhdCB0aGUgZW5kDQoNCiAgIHNpbmds ZXRvbiAgICAgPSAleDQxLTU3IC8gJXg1OS01QSAvICV4NjEtNzcgLyAleDc5LTdBIC8gRElHSVQN CiAgICAgICAgICAgICAgICAgOyAiYSItInciIC8gInkiLSJ6IiAvICJBIi0iVyIgLyAiWSItIloi IC8gIjAiLSI5Ig0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2gg MjcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0K DQogICAgICAgICAgICAgICAgIDsgU2luZ2xlIGxldHRlcnM6IHgvWCBpcyByZXNlcnZlZCBmb3Ig cHJpdmF0ZSB1c2UNCg0KICAgcHJpdmF0ZXVzZSAgICA9ICgieCIvIlgiKSAxKigiLSIgKDEqOGFs cGhhbnVtKSkNCg0KICAgZ3JhbmRmYXRoZXJlZCA9IDEqM0FMUEhBIDEqMigiLSIgKDIqOGFscGhh bnVtKSkNCiAgICAgICAgICAgICAgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9uDQog ICAgICAgICAgICAgICAgICAgOyBOb3RlOiBpIGlzIHRoZSBvbmx5IHNpbmdsZXRvbg0KICAgICAg ICAgICAgICAgICAgIDsgdGhhdCBzdGFydHMgYSBncmFuZGZhdGhlcmVkIHRhZw0KDQogICBhbHBo YW51bSAgICAgID0gKEFMUEhBIC8gRElHSVQpICAgICAgIDsgbGV0dGVycyBhbmQgbnVtYmVycw0K DQogICBJbiBhbiBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSwgdGhlIGlkZW50aWZpZXIgdGFrZXMg dGhlIGZvcm0gb2YgYQ0KICAgc2VyaWVzIG9mIHN1YnRhZ3Mgd2hpY2ggbXVzdCBjb25zaXN0IG9m IHdlbGwtZm9ybWVkIHN1YnRhZ3Mgb3IgdGhlDQogICBzcGVjaWFsIHN1YnRhZyAiKiIuICBGb3Ig ZXhhbXBsZSwgdGhlIGxhbmd1YWdlIHJhbmdlICJlbi0qLVVTIg0KICAgc3BlY2lmaWVzIGEgcHJp bWFyeSBsYW5ndWFnZSBvZiAnZW4nLCBmb2xsb3dlZCBieSBhbnkgc2NyaXB0IHN1YnRhZywNCiAg IGZvbGxvd2VkIGJ5IHRoZSByZWdpb24gc3VidGFnICdVUycuDQoNCiAgIEEgZmllbGQgbm90IHBy ZXNlbnQgaW4gdGhlIG1pZGRsZSBvZiBhbiBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSBNQVkNCiAg IGJlIHRyZWF0ZWQgYXMgaWYgdGhlIGZpZWxkIGNvbnRhaW5lZCBhICIqIi4gIEZvciBleGFtcGxl LCB0aGUgcmFuZ2UNCiAgICJlbi1VUyIgTUFZIGJlIGNvbnNpZGVyZWQgdG8gYmUgZXF1aXZhbGVu dCB0byB0aGUgcmFuZ2UgImVuLSotVVMiLg0KICAgVGhpcyBhbHNvIG1lYW5zIHRoYXQgbXVsdGlw bGUgd2lsZGNhcmRzIGNhbiBiZSBjb2xsYXBzZWQgKHNvIHRoYXQNCiAgICJlbi0qLSotVVMiIGlz IGVxdWl2YWxlbnQgdG8gImVuLSotVVMiKS4NCg0KICAgVGhlcmUgYXJlIHNldmVyYWwgbWF0Y2hp bmcgYWxnb3JpdGhtcyBvciBzY2hlbWVzIHdoaWNoIGNhbiBiZSBhcHBsaWVkDQogICB3aGVuIG1h dGNoaW5nIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlcyB0byBsYW5ndWFnZSB0YWdzLg0KDQoyLjIu MSAgRXh0ZW5kZWQgUmFuZ2UgTWF0Y2hpbmcNCg0KICAgSW4gZXh0ZW5kZWQgcmFuZ2UgbWF0Y2hp bmcsIHRoZSBzdWJ0YWdzIGluIGEgbGFuZ3VhZ2UgdGFnIGFyZQ0KICAgY29tcGFyZWQgdG8gdGhl IGNvcnJlc3BvbmRpbmcgc3VidGFncyBpbiB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UuDQog ICBBIHN1YnRhZyBpcyBjb25zaWRlcmVkIHRvIG1hdGNoIGlmIGl0IGV4YWN0bHkgbWF0Y2hlcyB0 aGUNCiAgIGNvcnJlc3BvbmRpbmcgc3VidGFnIGluIHRoZSByYW5nZSBvciB0aGUgcmFuZ2UgY29u dGFpbnMgYSBzdWJ0YWcgd2l0aA0KICAgdGhlIHZhbHVlICIqIiAod2hpY2ggbWF0Y2hlcyBhbGwg c3VidGFncywgaW5jbHVkaW5nIHRoZSBlbXB0eQ0KICAgc3VidGFnKS4gIEV4dGVuZGVkIFJhbmdl IE1hdGNoaW5nIGlzIGFuIGV4dGVuc2lvbiBvZiBiYXNpYyBtYXRjaGluZw0KICAgKFNlY3Rpb24g Mi4xLjEpOiB0aGUgbGFuZ3VhZ2UgcmFuZ2UgcmVwcmVzZW50cyB0aGUgbGVhc3Qgc3BlY2lmaWMg dGFnDQogICB3aGljaCBpcyBhbiBhY2NlcHRhYmxlIG1hdGNoLg0KDQogICBCeSBkZWZhdWx0IGFs bCBleHRlbnNpb25zIGFuZCB0aGVpciBzdWJ0YWdzIGFyZSBpZ25vcmVkIGZvciBleHRlbmRlZA0K ICAgbGFuZ3VhZ2UgcmFuZ2UgbWF0Y2hpbmcuDQoNCiAgIFByaXZhdGUgdXNlIHN1YnRhZ3MgTUFZ IGJlIHNwZWNpZmllZCBpbiB0aGUgbGFuZ3VhZ2UgcmFuZ2UgYW5kIE1VU1QNCiAgIE5PVCBiZSBp Z25vcmVkIHdoZW4gbWF0Y2hpbmcuDQoNCiAgIFN1YnRhZ3Mgbm90IHNwZWNpZmllZCwgaW5jbHVk aW5nIHRob3NlIGF0IHRoZSBlbmQgb2YgdGhlIGxhbmd1YWdlDQogICByYW5nZSwgYXJlIGFzc2ln bmVkIHRoZSB2YWx1ZSAiKiIuICBUaGlzIG1ha2VzIGVhY2ggcmFuZ2UgaW50byBhDQogICBwcmVm aXggbXVjaCBsaWtlIHRoYXQgdXNlZCBpbiBiYXNpYyBsYW5ndWFnZSByYW5nZSBtYXRjaGluZy4g IEZvcg0KICAgZXhhbXBsZSwgdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlICJ6aC0qLUNOIiBt YXRjaGVzIGFsbCBvZiB0aGUNCiAgIGZvbGxvd2luZyB0YWdzIGJlY2F1c2UgdGhlIHVuc3BlY2lm aWVkIHZhcmlhbnQgZmllbGQgaXMgZXhwYW5kZWQgdG8NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgICBFeHBpcmVzIE1hcmNoIDI3LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAg ICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgIioiOg0KDQogICAgICB6aC1IYW50LUNODQoNCiAg ICAgIHpoLUNODQoNCiAgICAgIHpoLUhhbnMtQ04NCg0KICAgICAgemgtQ04teC13YWRlZ2lsZQ0K DQogICAgICB6aC1MYXRuLUNOLWJvb250DQoNCiAgICAgIHpoLWNtbi1IYW5zLUNOLXgtd2FkZWdp bGUNCg0KDQoyLjIuMiAgRXh0ZW5kZWQgUmFuZ2UgTG9va3VwDQoNCiAgIEluIGV4dGVuZGVkIHJh bmdlIGxvb2t1cCwgdGhlIHN1YnRhZ3MgaW4gYSBsYW5ndWFnZSB0YWcgYXJlIGNvbXBhcmVkDQog ICB0byB0aGUgY29ycmVzcG9uZGluZyBzdWJ0YWdzIGluIHRoZSBleHRlbmRlZCBsYW5ndWFnZSBy YW5nZS4gIFRoZQ0KICAgc3VidGFnIGlzIGNvbnNpZGVyZWQgdG8gbWF0Y2ggaWYgaXQgZXhhY3Rs eSBtYXRjaGVzIHRoZSBjb3JyZXNwb25kaW5nDQogICBzdWJ0YWcgaW4gdGhlIHJhbmdlIG9yIHRo ZSByYW5nZSBjb250YWlucyBhIHN1YnRhZyB3aXRoIHRoZSB2YWx1ZSAiKiINCiAgICh3aGljaCBt YXRjaGVzIGFsbCBzdWJ0YWdzLCBpbmNsdWRpbmcgdGhlIGVtcHR5IHN1YnRhZykuICBFeHRlbmRl ZA0KICAgbGFuZ3VhZ2UgcmFuZ2UgbG9va3VwIGlzIGFuIGV4dGVuc2lvbiBvZiBiYXNpYyBsb29r dXANCiAgIChTZWN0aW9uIDIuMS4yKTogdGhlIGxhbmd1YWdlIHJhbmdlIHJlcHJlc2VudHMgdGhl IG1vc3Qgc3BlY2lmaWMgdGFnDQogICB3aGljaCB3aWxsIGZvcm0gYW4gYWNjZXB0YWJsZSBtYXRj aC4NCg0KICAgU3VidGFncyBub3Qgc3BlY2lmaWVkIGFyZSBhc3NpZ25lZCB0aGUgdmFsdWUgIioi IHByaW9yIHRvIHBlcmZvcm1pbmcNCiAgIHRhZyBtYXRjaGluZy4gIFVubGlrZSBpbiBleHRlbmRl ZCByYW5nZSBtYXRjaGluZywgaG93ZXZlciwgZmllbGRzIGF0DQogICB0aGUgZW5kIG9mIHRoZSBy YW5nZSBNVVNUIE5PVCBiZSBleHBhbmRlZCBpbiB0aGlzIG1hbm5lci4gIEZvcg0KICAgZXhhbXBs ZSwgImVuLVVTIiBNVVNUIE5PVCBiZSBjb25zaWRlcmVkIHRvIGJlIHRoZSBzYW1lIGFzIHRoZSBy YW5nZQ0KICAgImVuLVVTLSoiLiAgVGhpcyBhbGxvd3MgcmFuZ2VzIHRvIGJlIHNwZWNpZmljLiAg VGhlICIqIiB3aWxkY2FyZCBNVVNUDQogICBiZSB1c2VkIGF0IHRoZSBlbmQgb2YgdGhlIHJhbmdl IHRvIGluZGljYXRlIHRoYXQgYWxsIHRhZ3Mgd2l0aCB0aGUNCiAgIHJhbmdlIGFzIGEgcHJlZml4 IGFyZSBhbGxvd2FibGUgbWF0Y2hlcy4gIFRoYXQgaXMsIHRoZSByYW5nZSAiemgtKiINCiAgIG1h dGNoZXMgdGhlIHRhZ3MgInpoLUhhbnQiIGFuZCAiemgtSGFudC1DTiIsIHdoaWxlIHRoZSByYW5n ZSAiemgiDQogICBtYXRjaGVzIG5laXRoZXIgb2YgdGhvc2UgdGFncy4NCg0KICAgVGhlIHdpbGRj YXJkICIqIiBhdCB0aGUgZW5kIG9mIGEgcmFuZ2UgU0hPVUxEIGJlIGNvbnNpZGVyZWQgdG8gbWF0 Y2gNCiAgIGFueSBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzIChtYWtpbmcgZXh0ZW5kZWQg bGFuZ3VhZ2UgcmFuZ2UNCiAgIGxvb2t1cCBmdW5jdGlvbiBleGFjdGx5IGxpa2UgZXh0ZW5kZWQg cmFuZ2UgbWF0Y2hpbmcgU2VjdGlvbiAyLjIuMSkuDQoNCiAgIEJ5IGRlZmF1bHQgYWxsIGV4dGVu c2lvbnMgYW5kIHRoZWlyIHN1YnRhZ3MgU0hPVUxEIGJlIGlnbm9yZWQgZm9yDQogICBleHRlbmRl ZCBsYW5ndWFnZSByYW5nZSBsb29rdXAuICBQcml2YXRlIHVzZSBzdWJ0YWdzIE1BWSBiZSBzcGVj aWZpZWQNCiAgIGluIHRoZSBsYW5ndWFnZSByYW5nZSBhbmQgTVVTVCBOT1QgYmUgaWdub3JlZCB3 aGVuIHBlcmZvcm1pbmcgbG9va3VwLg0KICAgVGhlIHdpbGRjYXJkICIqIiBhdCB0aGUgZW5kIG9m IGEgcmFuZ2UgU0hPVUxEIGJlIGNvbnNpZGVyZWQgdG8gbWF0Y2gNCiAgIGFueSBwcml2YXRlIHVz ZSBzdWJ0YWcgc2VxdWVuY2VzIGluIGFkZGl0aW9uIHRvIHZhcmlhbnRzLg0KDQogICBGb3IgZXhh bXBsZSwgdGhlIHJhbmdlICIqLVVTIiBtYXRjaGVzIGFsbCBvZiB0aGUgZm9sbG93aW5nIHRhZ3M6 DQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE1hcmNoIDI3LCAyMDA2 ICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA1DQoNCg0KICAgICAg ZW4tVVMNCg0KICAgICAgZW4tTGF0bi1VUw0KDQogICAgICBlbi1VUy1yLWV4dGVuZHMgKGV4dGVu c2lvbnMgYXJlIGlnbm9yZWQpDQoNCiAgICAgIGZyLVVTDQoNCiAgIEZvciBleGFtcGxlLCB0aGUg cmFuZ2UgImVuLSotVVMiIG1hdGNoZXMgX25vbmVfIG9mIHRoZSBmb2xsb3dpbmcNCiAgIHRhZ3M6 DQoNCiAgICAgIGZyLVVTDQoNCiAgICAgIGVuIChtaXNzaW5nIHJlZ2lvbiBVUykNCg0KICAgICAg ZW4tTGF0biAobWlzc2luZyByZWdpb24gVVMpDQoNCiAgICAgIGVuLUxhdG4tVVMtc2NvdXNlICh2 YXJpYW50IGZpZWxkIGlzIHByZXNlbnQpDQoNCiAgIEZvciBleGFtcGxlLCB0aGUgcmFuZ2UgImVu LSoiIG1hdGNoZXMgYWxsIG9mIHRoZSBmb2xsb3dpbmcgdGFnczoNCg0KICAgICAgZW4tTGF0bg0K DQogICAgICBlbi1MYXRuLVVTDQoNCiAgICAgIGVuLUxhdG4tVVMtc2NvdXNlDQoNCiAgICAgIGVu LVVTDQoNCiAgICAgIGVuLXNjb3VzZQ0KDQogICBOb3RlIHRoYXQgdGhlIGFiaWxpdHkgdG8gYmUg c3BlY2lmaWMgaW4gZXh0ZW5kZWQgcmFuZ2UgbG9va3VwIGNhbg0KICAgbWFrZSB0aGlzIG1hdGNo aW5nIHNjaGVtZSBhIG1vcmUgYXBwcm9wcmlhdGUgcmVwbGFjZW1lbnQgZm9yIGJhc2ljDQogICBt YXRjaGluZyB0aGFuIHRoZSBleHRlbmRlZCByYW5nZSBtYXRjaGluZyBzY2hlbWUuDQoNCjIuMi4z ICBEaXN0YW5jZSBNZXRyaWMgU2NoZW1lDQoNCiAgIEJvdGggQmFzaWMgYW5kIEV4dGVuZGVkIExh bmd1YWdlIFJhbmdlcyBwcm9kdWNlIHNpbXBsZSBib29sZWFuDQogICBtYXRjaGVzLiAgU29tZSBh cHBsaWNhdGlvbnMgbWF5IGJlbmVmaXQgYnkgcHJvdmlkaW5nIGFuIGFycmF5IG9mDQogICByZXN1 bHRzIHdpdGggZGlmZmVyZW50IGxldmVscyBvZiBtYXRjaGluZywgZm9yIGV4YW1wbGUsIHNvcnRp bmcNCiAgIHJlc3VsdHMgYmFzZWQgb24gdGhlIG92ZXJhbGwgInF1YWxpdHkiIG9mIHRoZSBtYXRj aC4NCg0KICAgVGhpcyB0eXBlIG9mIG1hdGNoaW5nIGlzIHNvbWV0aW1lcyBjYWxsZWQgYSAiZGlz dGFuY2UgbWV0cmljIi4gIEENCiAgIGRpc3RhbmNlIG1ldHJpYyBhc3NpZ25zIGEgcGFpciBvZiBs YW5ndWFnZSB0YWdzIGEgbnVtZXJpYyB2YWx1ZQ0KICAgcmVwcmVzZW50aW5nIHRoZSAnZGlzdGFu Y2UnIGJldHdlZW4gdGhlIHR3by4gIEEgZGlzdGFuY2Ugb2YgemVybw0KICAgbWVhbnMgdGhhdCB0 aGV5IGFyZSBpZGVudGljYWwsIGEgc21hbGwgZGlzdGFuY2UgaW5kaWNhdGVzIHRoYXQgdGhleQ0K ICAgYXJlIHZlcnkgc2ltaWxhciwgYW5kIGEgbGFyZ2UgZGlzdGFuY2UgaW5kaWNhdGVkIHRoYXQg dGhleSBhcmUgdmVyeQ0KICAgZGlmZmVyZW50LiAgVXNpbmcgYSBkaXN0YW5jZSBtZXRyaWMsIGlt cGxlbWVudGF0aW9ucyBjYW4sIGZvcg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4 cGlyZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2VwdGVt YmVyIDIwMDUNCg0KDQogICBleGFtcGxlLCBhbGxvdyB1c2VycyB0byBzZWxlY3QgYSB0aHJlc2hv bGQgZGlzdGFuY2UgZm9yIGEgbWF0Y2ggdG8gYmUNCiAgIHN1Y2Nlc3NmdWwgb3IgYSBmaWx0ZXIg dG8gYmUgYXBwbGllZC4NCg0KICAgVGhlIGZpcnN0IHN0ZXAgaW4gdGhlIHByb2Nlc3MgaXMgdG8g bm9ybWFsaXplIHRoZSBleHRlbmRlZCBsYW5ndWFnZQ0KICAgcmFuZ2UgYW5kIHRoZSBsYW5ndWFn ZSB0YWdzIHRvIGJlIG1hdGNoZWQgdG8gaXQgYnkgY2Fub25pY2FsaXppbmcNCiAgIHRoZW0sIG1h cHBpbmcgZ3JhbmRmYXRoZXJlZCBhbmQgb2Jzb2xldGUgdGFncyBpbnRvIG1vZGVybg0KICAgZXF1 aXZhbGVudHMuDQoNCiAgIFRoZSBsYW5ndWFnZSByYW5nZSBhbmQgdGhlIGxhbmd1YWdlIHRhZ3Mg YXJlIHRoZW4gdHJhbnNmb3JtZWQgaW50bw0KICAgcXVpbnR1cGxlcyBvZiBlbGVtZW50cyBvZiB0 aGUgZm9ybSAobGFuZ3VhZ2UsIHNjcmlwdCwgY291bnRyeSwNCiAgIHZhcmlhbnQsIGV4dGVuc2lv bikuICBBbnkgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgY29uc2lkZXJlZA0KICAgcGFy dCBvZiB0aGUgbGFuZ3VhZ2UgZWxlbWVudDsgcHJpdmF0ZSB1c2Ugc3VidGFnIHNlcXVlbmNlcyBh cmUNCiAgIGNvbnNpZGVyZWQgcGFydCBvZiB0aGUgbGFuZ3VhZ2UgZWxlbWVudCBpZiBpbiB0aGUg aW5pdGlhbCBwb3NpdGlvbiBpbg0KICAgdGhlIHRhZyBhbmQgcGFydCBvZiB0aGUgdmFyaWFudCBl bGVtZW50IGlmIG5vdC4gIExhbmd1YWdlIHN1YnRhZ3MNCiAgICd1bmQnLCAnbXVsJywgYW5kIHRo ZSBzY3JpcHQgc3VidGFnICdaeXl5JyBhcmUgY29udmVydGVkIHRvICIqIi4NCg0KICAgTWlzc2lu ZyBjb21wb25lbnRzIGluIHRoZSBsYW5ndWFnZS10YWcgYXJlIHNldCB0byAiKiI7IHRodXMgYSAi KiINCiAgIHBhdHRlcm4gYmVjb21lcyB0aGUgcXVpbnR1cGxlICgiKiIsICIqIiwgIioiLCAiKiIs ICIqIikuICBNaXNzaW5nDQogICBjb21wb25lbnRzIGluIHRoZSBleHRlbmRlZCBsYW5ndWFnZS1y YW5nZSBhcmUgaGFuZGxlZCBzaW1pbGFybHkgdG8NCiAgIGV4dGVuZGVkIHJhbmdlIGxvb2t1cDog bWlzc2luZyBpbnRlcm5hbCBzdWJ0YWdzIGFyZSBleHBhbmRlZCB0byAiKiIuDQogICBNaXNzaW5n IGVuZCBzdWJ0YWdzIGFyZSBleHBhbmRlZCBhcyB0aGUgZW1wdHkgc3RyaW5nLiAgVGh1cyBhIHBh dHRlcm4NCiAgICJlbi1VUyIgYmVjb21lcyB0aGUgcXVpbnR1cGxlICgiZW4iLCIqIiwiVVMiLCIi LCIiKS4NCg0KICAgSGVyZSBhcmUgc29tZSBleGFtcGxlcyBvZiBsYW5ndWFnZS10YWdzIGFuZCB0 aGVpciBxdWludHVwbGVzOg0KDQogICAgICBlbi1VUyAoImVuIiwiKiIsIlVTIiwiKiIsIioiKQ0K DQogICAgICBzci1MYXRuICgic3IsIkxhdG4iLCIqIiwiKiIsIioiKQ0KDQogICAgICB6aC1jbW4t SGFudCAoInpoLWNtbiIsIkhhbnQiLCIqIiwiKiIsIioiKQ0KDQogICAgICB4LWZvbyAoIngtZm9v IiwiKiIsIioiLCIqIiwiKiIpDQoNCiAgICAgIGVuLXgtZm9vICgiZW4iLCIqIiwiKiIsIngtZm9v IiwiKiIpDQoNCiAgICAgIGktZGVmYXVsdCAoImktZGVmYXVsdCIsIioiLCIqIiwiKiIsIioiKQ0K DQogICAgICBzbC1MYXRuLUlULXJvYXpqICgic2wiLCJMYXRuIiwiSVQiLCJyb3phaiIsIioiKQ0K DQogICAgICB6aC1yLXdhZGVnaWxlICgiemgiLCIqIiwiKiIsIioiLCJyLXdhZGVnaWxlIikgLy8g aHlwb3RoZXRpY2FsDQoNCiAgIEVhY2ggbGFuZ3VhZ2UtcmFuZ2UvbGFuZ3VhZ2UtdGFnIHBhaXIg YmVpbmcgbWF0Y2hlZCBvciBmaWx0ZXJlZCBpcw0KICAgYXNzaWduZWQgYSBkaXN0YW5jZSB2YWx1 ZSwgd2hlcmVieSBzbWFsbCB2YWx1ZXMgaW5kaWNhdGUgYmV0dGVyDQogICBtYXRjaGVzIGFuZCBs YXJnZSB2YWx1ZXMgaW5kaWNhdGUgd29yc2Ugb25lcy4gIFRoZSBkaXN0YW5jZSBiZXR3ZWVuDQog ICB0aGUgcGFpciBpcyB0aGUgc3VtIG9mIHRoZSBkaXN0YW5jZXMgZm9yIGVhY2ggb2YgdGhlIGNv cnJlc3BvbmRpbmcNCiAgIGVsZW1lbnRzIG9mIHRoZSBxdWludHVwbGUuICBJZiB0aGUgZWxlbWVu dHMgYXJlIGlkZW50aWNhbCBvciBvbmUgaXMNCiAgICcqJywgdGhlbiB0aGUgZGlzdGFuY2UgdmFs dWUgYmV0d2VlbiB0aGVtIGlzIHplcm8uICBPdGhlcndpc2UsIGl0IGlzDQogICBnaXZlbiBieSB0 aGUgZm9sbG93aW5nIHRhYmxlOg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGly ZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2VwdGVtYmVy IDIwMDUNCg0KDQogICAgIDI1NiAgICBsYW5ndWFnZSBtaXNtYXRjaA0KICAgICAxMjggICAgc2Ny aXB0IG1pc21hdGNoDQogICAgICAzMiAgICByZWdpb24gbWlzbWF0Y2gNCiAgICAgICA0ICAgIHZh cmlhbnQgbWlzbWF0Y2gNCiAgICAgICAxICAgIGV4dGVuc2lvbiBtaXNtYXRjaA0KDQogICBBIHZh bHVlIG9mIDAgaXMgYSBwZXJmZWN0IG1hdGNoOyA0MjEgaXMgbm8gbWF0Y2ggYXQgYWxsLiAgRGlm ZmVyZW50DQogICB0aHJlc2hvbGQgdmFsdWVzIG1pZ2h0IGJlIGFwcHJvcHJpYXRlIGZvciBkaWZm ZXJlbnQgYXBwbGljYXRpb25zIGFuZA0KICAgaW1wbGVtZW50YXRpb25zIHdpbGwgcHJvYmFibHkg YWxsb3cgdXNlcnMgdG8gY2hvb3NlIHRoZSBtb3N0DQogICBhcHByb3ByaWF0ZSBzZWxlY3Rpb24g dmFsdWUsIHJhbmtpbmcgdGhlIHNlbGVjdGlvbnMgYmFzZWQgb24gc2NvcmUuDQoNCiAgIEV4YW1w bGVzIG9mIHZhcmlvdXMgdGFnJ3MgZGlzdGFuY2VzIGZyb20gdGhlIHJhbmdlICJlbi1VUyI6DQoN CiAgICJmciIgICAgICAgICAgICAgMjU2IChsYW5ndWFnZSBtaXNtYXRjaCwgcmVnaW9uIG1hdGNo KQ0KICAgImVuLUdCIiAgICAgICAgICAzODQgKGxhbmd1YWdlLCByZWdpb24gbWlzbWF0Y2gpDQog ICAiZW4tTGF0bi1VUyIgICAgICAgMCAoYWxsIGZpZWxkcyBtYXRjaCkNCiAgICJlbi1CcmFpIiAg ICAgICAgIDMyIChyZWdpb24gbWlzbWF0Y2gpDQogICAiZW4tVVMteC1mb28iICAgICAgNCAodmFy aWFudCBtaXNtYXRjaDogcmFuZ2UgaXMgdGhlIGVtcHR5IHN0cmluZykNCiAgICJlbi1VUy1yLXdh ZGVnaWxlIiAxIChleHRlbnNpb24gbWlzbWF0Y2g6IHJhbmdlIGlzIHRoZSBlbXB0eSBzdHJpbmcp DQoNCiAgIEltcGxlbWVudGF0aW9ucyBtYXkgd2FudCB0byB1c2UgbW9yZSBzb3BoaXN0aWNhdGVk IHdlaWdodHMgdGhhdA0KICAgZGVwZW5kIG9uIHRoZSB2YWx1ZXMgb2YgdGhlIGNvcnJlc3BvbmRp bmcgZWxlbWVudHMuICBGb3IgZXhhbXBsZSwNCiAgIGRlcGVuZGluZyBvbiB0aGUgZG9tYWluLCBh biBpbXBsZW1lbmF0aW9uIG1pZ2h0IGdpdmUgYSBzbWFsbCBkaXN0YW5jZQ0KICAgdG8gdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiB0aGUgbGFuZ3VhZ2Ugc3VidGFnICdubycgYW5kIHRoZSBjbG9zZWx5 DQogICByZWxhdGVkIGxhbmd1YWdlIHN1YnRhZ3MgJ25iJyBvciAnbm4nOyBvciBiZXR3ZWVuIHRo ZSBzY3JpcHQgc3VidGFncw0KICAgJ0thdGEnIGFuZCAnSGlyYSc7IG9yIGJldHdlZW4gdGhlIHJl Z2lvbiBzdWJ0YWdzICdVUycgYW5kICdVTScuDQoNCjIuMyAgTWVhbmluZyBvZiBMYW5ndWFnZSBU YWdzIGFuZCBSYW5nZXMNCg0KICAgQSBsYW5ndWFnZSB0YWcgZGVmaW5lcyBhIGxhbmd1YWdlIGFz IHNwb2tlbiAob3Igd3JpdHRlbiwgc2lnbmVkIG9yDQogICBvdGhlcndpc2Ugc2lnbmFsZWQpIGJ5 IGh1bWFuIGJlaW5ncyBmb3IgY29tbXVuaWNhdGlvbiBvZiBpbmZvcm1hdGlvbg0KICAgdG8gb3Ro ZXIgaHVtYW4gYmVpbmdzLg0KDQogICBJZiBhIGxhbmd1YWdlIHRhZyBCIGNvbnRhaW5zIGxhbmd1 YWdlIHRhZyBBIGFzIGEgcHJlZml4LCB0aGVuIEIgaXMNCiAgIHR5cGljYWxseSAibmFycm93ZXIi IG9yICJtb3JlIHNwZWNpZmljIiB0aGFuIEEuIEZvciBleGFtcGxlLCAiemgtDQogICBIYW50LVRX IiBpcyBtb3JlIHNwZWNpZmljIHRoYW4gInpoLUhhbnQiLg0KDQogICBUaGlzIHJlbGF0aW9uc2hp cCBpcyBub3QgZ3VhcmFudGVlZCBpbiBhbGwgY2FzZXM6IHNwZWNpZmljYWxseSwNCiAgIGxhbmd1 YWdlcyB0aGF0IGJlZ2luIHdpdGggdGhlIHNhbWUgc2VxdWVuY2Ugb2Ygc3VidGFncyBhcmUgTk9U DQogICBndWFyYW50ZWVkIHRvIGJlIG11dHVhbGx5IGludGVsbGlnaWJsZSwgYWx0aG91Z2ggdGhl eSBtaWdodCBiZS4NCg0KICAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImF6IiBzaGFyZXMgYSBwcmVm aXggd2l0aCBib3RoICJhei1MYXRuIg0KICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4gdXNpbmcgdGhl IExhdGluIHNjcmlwdCkgYW5kICJhei1DeXJsIg0KICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4gdXNp bmcgdGhlIEN5cmlsbGljIHNjcmlwdCkuICBBIHBlcnNvbiBmbHVlbnQgaW4NCiAgIG9uZSBzY3Jp cHQgbWlnaHQgbm90IGJlIGFibGUgdG8gcmVhZCB0aGUgb3RoZXIsIGV2ZW4gdGhvdWdoIHRoZSB0 ZXh0DQogICBtaWdodCBiZSBvdGhlcndpc2UgaWRlbnRpY2FsLiAgQ29udGVudCB0YWdnZWQgYXMg ImF6IiBtb3N0IHByb2JhYmx5DQogICBpcyB3cml0dGVuIGluIGp1c3Qgb25lIHNjcmlwdCBhbmQg dGh1cyBtaWdodCBub3QgYmUgaW50ZWxsaWdpYmxlIHRvIGENCiAgIHJlYWRlciBmYW1pbGlhciB3 aXRoIHRoZSBvdGhlciBzY3JpcHQuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhw aXJlcyBNYXJjaCAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICBTZXB0ZW1i ZXIgMjAwNQ0KDQoNCiAgIFZhcmlhbnQgc3VidGFncyBpbiBwYXJ0aWN1bGFyIHNlZW0gdG8gcmVw cmVzZW50IHNwZWNpZmljIGRpdmlzaW9ucyBpbg0KICAgbXV0dWFsIHVuZGVyc3RhbmRpbmcsIHNp bmNlIHRoZXkgb2Z0ZW4gZW5jb2RlIGRpYWxlY3RzIG9yIG90aGVyDQogICBpZGlvc3luY3JhdGlj IHZhcmlhdGlvbnMgd2l0aGluIGEgbGFuZ3VhZ2UuDQoNCiAgIFRoZSByZWxhdGlvbnNoaXAgYmV0 d2VlbiB0aGUgbGFuZ3VhZ2UgdGFnIGFuZCB0aGUgaW5mb3JtYXRpb24gaXQNCiAgIHJlbGF0ZXMg dG8gaXMgZGVmaW5lZCBieSB0aGUgc3RhbmRhcmQgZGVzY3JpYmluZyB0aGUgY29udGV4dCBpbiB3 aGljaA0KICAgaXQgYXBwZWFycy4gIEFjY29yZGluZ2x5LCB0aGlzIHNlY3Rpb24gY2FuIG9ubHkg Z2l2ZSBwb3NzaWJsZQ0KICAgZXhhbXBsZXMgb2YgaXRzIHVzYWdlLg0KDQogICBvICBGb3IgYSBz aW5nbGUgaW5mb3JtYXRpb24gb2JqZWN0LCB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0YWdzDQog ICAgICBtaWdodCBiZSBpbnRlcnByZXRlZCBhcyB0aGUgc2V0IG9mIGxhbmd1YWdlcyB0aGF0IGFy ZSBuZWNlc3NhcnkNCiAgICAgIGZvciBhIGNvbXBsZXRlIGNvbXByZWhlbnNpb24gb2YgdGhlIGNv bXBsZXRlIG9iamVjdC4gIEV4YW1wbGU6DQogICAgICBQbGFpbiB0ZXh0IGRvY3VtZW50cy4NCg0K ICAgbyAgRm9yIGFuIGFnZ3JlZ2F0aW9uIG9mIGluZm9ybWF0aW9uIG9iamVjdHMsIHRoZSBhc3Nv Y2lhdGVkIGxhbmd1YWdlDQogICAgICB0YWdzIGNvdWxkIGJlIHRha2VuIGFzIHRoZSBzZXQgb2Yg bGFuZ3VhZ2VzIHVzZWQgaW5zaWRlIGNvbXBvbmVudHMNCiAgICAgIG9mIHRoYXQgYWdncmVnYXRp b24uICBFeGFtcGxlczogRG9jdW1lbnQgc3RvcmVzIGFuZCBsaWJyYXJpZXMuDQoNCiAgIG8gIEZv ciBpbmZvcm1hdGlvbiBvYmplY3RzIHdob3NlIHB1cnBvc2UgaXMgdG8gcHJvdmlkZSBhbHRlcm5h dGl2ZXMsDQogICAgICB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0YWdzIGNvdWxkIGJlIHJlZ2Fy ZGVkIGFzIGEgaGludCB0aGF0IHRoZQ0KICAgICAgY29udGVudCBpcyBwcm92aWRlZCBpbiBzZXZl cmFsIGxhbmd1YWdlcywgYW5kIHRoYXQgb25lIGhhcyB0bw0KICAgICAgaW5zcGVjdCBlYWNoIG9m IHRoZSBhbHRlcm5hdGl2ZXMgaW4gb3JkZXIgdG8gZmluZCBpdHMgbGFuZ3VhZ2Ugb3INCiAgICAg IGxhbmd1YWdlcy4gIEluIHRoaXMgY2FzZSwgdGhlIHByZXNlbmNlIG9mIG11bHRpcGxlIHRhZ3Mg bWlnaHQgbm90DQogICAgICBtZWFuIHRoYXQgb25lIG5lZWRzIHRvIGJlIG11bHRpLWxpbmd1YWwg dG8gZ2V0IGNvbXBsZXRlDQogICAgICB1bmRlcnN0YW5kaW5nIG9mIHRoZSBkb2N1bWVudC4gIEV4 YW1wbGU6IE1JTUUgbXVsdGlwYXJ0Lw0KICAgICAgYWx0ZXJuYXRpdmUuDQoNCiAgIG8gIEluIG1h cmt1cCBsYW5ndWFnZXMsIHN1Y2ggYXMgSFRNTCBhbmQgWE1MLCBsYW5ndWFnZSBpbmZvcm1hdGlv bg0KICAgICAgY2FuIGJlIGFkZGVkIHRvIGVhY2ggcGFydCBvZiB0aGUgZG9jdW1lbnQgaWRlbnRp ZmllZCBieSB0aGUgbWFya3VwDQogICAgICBzdHJ1Y3R1cmUgKGluY2x1ZGluZyB0aGUgd2hvbGUg ZG9jdW1lbnQgaXRzZWxmKS4gIEZvciBleGFtcGxlLCBvbmUNCiAgICAgIGNvdWxkIHdyaXRlIDxz cGFuIGxhbmc9IkZSIj5DJ2VzdCBsYSB2aWUuPC9zcGFuPiBpbnNpZGUgYQ0KICAgICAgTm9yd2Vn aWFuIGRvY3VtZW50OyB0aGUgTm9yd2VnaWFuLXNwZWFraW5nIHVzZXIgY291bGQgdGhlbiBhY2Nl c3MNCiAgICAgIGEgRnJlbmNoLU5vcndlZ2lhbiBkaWN0aW9uYXJ5IHRvIGZpbmQgb3V0IHdoYXQg dGhlIG1hcmtlZCBzZWN0aW9uDQogICAgICBtZWFudC4gIElmIHRoZSB1c2VyIHdlcmUgbGlzdGVu aW5nIHRvIHRoYXQgZG9jdW1lbnQgdGhyb3VnaCBhDQogICAgICBzcGVlY2ggc3ludGhlc2lzIGlu dGVyZmFjZSwgdGhpcyBmb3JtYXRpb24gY291bGQgYmUgdXNlZCB0byBzaWduYWwNCiAgICAgIHRo ZSBzeW50aGVzaXplciB0byBhcHByb3ByaWF0ZWx5IGFwcGx5IEZyZW5jaCB0ZXh0LXRvLXNwZWVj aA0KICAgICAgcHJvbnVuY2lhdGlvbiBydWxlcyB0byB0aGF0IHNwYW4gb2YgdGV4dCwgaW5zdGVh ZCBvZiBtaXNhcHBseWluZw0KICAgICAgdGhlIE5vcndlZ2lhbiBydWxlcy4NCg0KDQoyLjQgIENo b29zaW5nIEJldHdlZW4gQWx0ZXJuYXRlIE1hdGNoaW5nIFNjaGVtZXMNCg0KICAgSW1wbGVtZW50 YXRpb25zIGNhbiBjaG9vc2UgdG8gaW1wbGVtZW50IGRpZmZlcmVudCBzdHlsZXMgb2YgbWF0Y2hp bmcNCiAgIGZvciBkaWZmZXJlbnQga2luZHMgb2YgcHJvY2Vzc2luZy4gIEZvciBleGFtcGxlLCBh biBpbXBsZW1lbnRhdGlvbg0KICAgY291bGQgdHJlYXQgYW4gYWJzZW50IHNjcmlwdCBzdWJ0YWcg YXMgYSAid2lsZGNhcmQiIGZpZWxkOyB0aHVzDQogICAiYXotQVoiIHdvdWxkIG1hdGNoICJhei1B WiIsICJhei1DeXJsLUFaIiwgImF6LUxhdG4tQVoiLCBldGMuIGJ1dCBub3QNCiAgICJheiIgKHRo aXMgaXMgYW4gZXhhbXBsZSBvZiBleHRlbmRlZCByYW5nZSBsb29rdXApLiAgSWYgb25lIGl0ZW0g aXMNCiAgIHRvIGJlIGNob3NlbiwgdGhlIGltcGxlbWVudGF0aW9uIGNvdWxkIHBpY2sgYW1vbmcg dGhvc2UgbWF0Y2hlcyBiYXNlZA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGly ZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2VwdGVtYmVy IDIwMDUNCg0KDQogICBvbiBvdGhlciBpbmZvcm1hdGlvbiwgc3VjaCBhcyB0aGUgbW9zdCBsaWtl bHkgc2NyaXB0IHVzZWQgaW4gdGhlDQogICBsYW5ndWFnZS9yZWdpb24gaW4gcXVlc3Rpb24gb3Ig dGhlIHNjcmlwdCB1c2VkIGJ5IG90aGVyIGNvbnRlbnQNCiAgIHNlbGVjdGVkLg0KDQogICBCZWNh dXNlIHRoZSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBjYW5ub3QgYmUgYWJzZW50IGluIGEgbGFu Z3VhZ2UNCiAgIHRhZywgdGhlICd1bmQnIHN1YnRhZyBpcyBzb21ldGltZXMgYmUgdXNlZCBhcyBh ICd3aWxkY2FyZCcgaW4gYmFzaWMNCiAgIG1hdGNoaW5nLiAgRm9yIGV4YW1wbGUsIGluIGEgcXVl cnkgd2hlcmUgeW91IHdhbnQgdG8gc2VsZWN0IGFsbA0KICAgbGFuZ3VhZ2UgdGFncyB0aGF0IGNv bnRhaW4gJ0xhdG4nIGFzIHRoZSBzY3JpcHQgY29kZSBhbmQgJ0FaJyBhcyB0aGUNCiAgIHJlZ2lv biBjb2RlLCB5b3UgY291bGQgdXNlIHRoZSByYW5nZSAidW5kLUxhdG4tQVoiLiAgVGhpcyByZXF1 aXJlcyBhbg0KICAgaW1wbGVtZW50YXRpb24gdG8gZXhhbWluZSB0aGUgYWN0dWFsIHZhbHVlcyBv ZiB0aGUgc3VidGFncywgdGhvdWdoLA0KICAgYW5kIHVzZXJzIFNIT1VMRCBOT1QgYXNzdW1lIHRo YXQgdGhlIHZhbHVlICd1bmQnIHdpbGwgYmUgdHJlYXRlZCBhcyBhDQogICB3aWxkY2FyZC4NCg0K ICAgVGhlIG1hdGNoaW5nIHNjaGVtZXMgZGVzY3JpYmVkIGVsc2V3aGVyZSBpbiB0aGlzIGRvY3Vt ZW50IGFyZQ0KICAgZGVzaWduZWQgc3VjaCB0aGF0IGltcGxlbWVudGF0aW9ucyBkbyBub3QgaGF2 ZSB0byBleGFtaW5lIHRoZSB2YWx1ZXMNCiAgIG9mIHRoZSBzdWJ0YWdzIHN1cHBsaWVkIGFuZCwg ZXhjZXB0IGZvciBzY29yZWQgbWF0Y2hpbmcsIHRoZXkgZG8gbm90DQogICBuZWVkIGFjY2VzcyB0 byB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IG5vciBkbyB0aGV5IHJlcXVpcmUgdGhlDQog ICB1c2Ugb2YgdmFsaWQgc3VidGFncyBpbiBsYW5ndWFnZSB0YWdzIG9yIHJhbmdlcy4gIFRoaXMg aGFzIGdyZWF0DQogICBiZW5lZml0IGZvciBzcGVlZCBhbmQgc2ltcGxpY2l0eSBvZiBpbXBsZW1l bnRhdGlvbi4NCg0KICAgSW1wbGVtZW50YXRpb25zIG1pZ2h0IGFsc28gd2lzaCB0byB1c2Ugc2Vt YW50aWMgaW5mb3JtYXRpb24gZXh0ZXJuYWwNCiAgIHRvIHRoZSBsYW5nYXVnZSB0YWdzIHdoZW4g cGVyZm9ybWluZyBmYWxsYmFjay4gIEZvciBleGFtcGxlLCB0aGUNCiAgIHByaW1hcnkgbGFuZ3Vh Z2Ugc3VidGFncyAnbm4nIChOeW5vcnNrIE5vcndlZ2lhbikgYW5kICduYicgKEJva21hbA0KICAg Tm9yd2VnaWFuKSBtaWdodCBib3RoIGJlIHVzZWZ1bGx5IG1hdGNoZWQgdG8gdGhlIG1vcmUgZ2Vu ZXJhbCBzdWJ0YWcNCiAgICdubycgKE5vcndlZ2lhbikuICBPciBhbiBhcHBsaWNhdGlvbiBtaWdo dCBpbmZlciB0aGF0IGNvbnRlbnQgbGFiZWxlZA0KICAgInpoLUNOIiBpcyBtb3JlbHkgbGlrZWx5 IHRvIG1hdGNoIHRoZSByYW5nZSAiemgtSGFucyIgdGhhbiBlcXVpdmFsZW50DQogICBjb250ZW50 IGxhYmVsZWQgInpoLVRXIi4NCg0KMi41ICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2Ug U3VidGFncw0KDQogICBQcml2YXRlLXVzZSBzdWJ0YWdzIHJlcXVpcmUgcHJpdmF0ZSBhZ3JlZW1l bnQgYmV0d2VlbiB0aGUgcGFydGllcw0KICAgdGhhdCBpbnRlbmQgdG8gdXNlIG9yIGV4Y2hhbmdl IGxhbmd1YWdlIHRhZ3MgdGhhdCB1c2UgdGhlbSBhbmQgZ3JlYXQNCiAgIGNhdXRpb24gU0hPVUxE IGJlIHVzZWQgaW4gZW1wbG95aW5nIHRoZW0gaW4gY29udGVudCBvciBwcm90b2NvbHMNCiAgIGlu dGVuZGVkIGZvciBnZW5lcmFsIHVzZS4gIFByaXZhdGUtdXNlIHN1YnRhZ3MgYXJlIHNpbXBseSB1 c2VsZXNzIGZvcg0KICAgaW5mb3JtYXRpb24gZXhjaGFuZ2Ugd2l0aG91dCBwcmlvciBhcnJhbmdl bWVudC4NCg0KICAgVGhlIHZhbHVlIGFuZCBzZW1hbnRpYyBtZWFuaW5nIG9mIHByaXZhdGUtdXNl IHRhZ3MgYW5kIG9mIHRoZSBzdWJ0YWdzDQogICB1c2VkIHdpdGhpbiBzdWNoIGEgbGFuZ3VhZ2Ug dGFnIGFyZSBub3QgZGVmaW5lZC4gIE1hdGNoaW5nIHByaXZhdGUNCiAgIHVzZSB0YWdzIHVzaW5n IGxhbmd1YWdlIHJhbmdlcyBvciBleHRlbmRlZCBsYW5ndWFnZSByYW5nZXMgY2FuIHJlc3VsdA0K ICAgaW4gdW5wcmVkaWN0YWJsZSBjb250ZW50IGJlaW5nIHJldHVybmVkLg0KDQoyLjYgIExlbmd0 aCBDb25zaWRlcmF0aW9ucyBpbiBNYXRjaGluZw0KDQogICBSRkMgMzA2NiBbUkZDMzA2Nl0gZGlk IG5vdCBwcm92aWRlIGFuIHVwcGVyIGxpbWl0IG9uIHRoZSBzaXplIG9mDQogICBsYW5ndWFnZSB0 YWdzIG9yIHJhbmdlcy4gIFJGQyAzMDY2IGRpZCBkZWZpbmUgdGhlIHNlbWFudGljcyBvZg0KICAg cGFydGljdWxhciBzdWJ0YWdzIGluIHN1Y2ggYSB3YXkgdGhhdCBtb3N0IGxhbmd1YWdlIHRhZ3Mg b3IgcmFuZ2VzDQogICBjb25zaXN0ZWQgb2YgbGFuZ3VhZ2UgYW5kIHJlZ2lvbiBzdWJ0YWdzIHdp dGggYSBjb21iaW5lZCB0b3RhbCBsZW5ndGgNCiAgIG9mIHVwIHRvIHNpeCBjaGFyYWN0ZXJzLiAg TGFyZ2VyIHRhZ3MgYW5kIHJhbmdlcyAoaW4gdGVybXMgb2YgYm90aA0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgW1Bh Z2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAg ICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBzdWJ0YWdzIGFuZCBjaGFyYWN0ZXJz KSBkaWQgZXhpc3QsIGhvd2V2ZXIuDQoNCiAgIFtkcmFmdC1yZWdpc3RyeV0gYWxzbyBkb2VzIG5v dCBpbXBvc2UgYSBmaXhlZCB1cHBlciBsaW1pdCBvbiB0aGUNCiAgIG51bWJlciBvZiBzdWJ0YWdz IGluIGEgbGFuZ3VhZ2UgdGFnIG9yIHJhbmdlIChhbmQgdGh1cyBhbiB1cHBlciBib3VuZA0KICAg b24gdGhlIHNpemUgb2YgZWl0aGVyKS4gIFRoZSBzeW50YXggaW4gdGhhdCBkb2N1bWVudCBzdWdn ZXN0cyB0aGF0LA0KICAgZGVwZW5kaW5nIG9uIHRoZSBzcGVjaWZpYyBsYW5ndWFnZSBvciByYW5n ZSBvZiBsYW5ndWFnZXMsIG1vcmUNCiAgIHN1YnRhZ3MgKGFuZCB0aHVzIGNoYXJhY3RlcnMpIGFy ZSBzb21ldGltZXMgbmVjZXNzYXJ5IGFzIGEgcmVzdWx0Lg0KICAgTGVuZ3RoIGNvbnNpZGVyYXRp b25zIGFuZCB0aGVpciBpbXBhY3Qgb24gdGhlIHNlbGVjdGlvbiBhbmQNCiAgIHByb2Nlc3Npbmcg b2YgdGFncyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xLjEgb2YgdGhhdCBkb2N1bWVudC4N Cg0KICAgQSBtYXRjaGluZyBpbXBsZW1lbnRhdGlvbiBNQVkgY2hvb3NlIHRvIGxpbWl0IHRoZSBs ZW5ndGggb2YgdGhlDQogICBsYW5ndWFnZSB0YWdzIG9yIHJhbmdlcyB1c2VkIGluIG1hdGNoaW5n LiAgQW55IHN1Y2ggbGltaXRhdGlvbiBTSE9VTEQNCiAgIGJlIGNsZWFybHkgZG9jdW1lbnRlZCwg YW5kIHN1Y2ggZG9jdW1lbnRhdGlvbiBTSE9VTEQgaW5jbHVkZSB0aGUNCiAgIGRpc3Bvc2l0aW9u IG9mIGFueSBsb25nZXIgdGFncyBvciByYW5nZXMgKGZvciBleGFtcGxlLCB3aGV0aGVyIGFuDQog ICBlcnJvciB2YWx1ZSBpcyBnZW5lcmF0ZWQgb3IgdGhlIGxhbmd1YWdlIHRhZyBvciByYW5nZSBp cyB0cnVuY2F0ZWQpLg0KICAgSWYgdHJ1bmNhdGlvbiBpcyBwZXJtaXR0ZWQgaXQgTVVTVCBOT1Qg cGVybWl0IGEgc3VidGFnIHRvIGJlIGRpdmlkZWQsDQogICBzaW5jZSB0aGlzIGNoYW5nZXMgdGhl IHNlbWFudGljcyBvZiB0aGUgc3VidGFnIGJlaW5nIG1hdGNoZWQgYW5kIGNhbg0KICAgcmVzdWx0 IGluIGZhbHNlIHBvc2l0aXZlcyBvciBuZWdhdGl2ZXMuDQoNCiAgIEltcGxlbWVudGF0aW9ucyB0 aGF0IHJlc3RyaWN0IHN0b3JhZ2UgU0hPVUxEIGNvbnNpZGVyIHRoZSBpbXBhY3Qgb2YNCiAgIHRh ZyBvciByYW5nZSB0cnVuY2F0aW9uIG9uIHRoZSByZXN1bHRpbmcgbWF0Y2hlcy4gIEZvciBleGFt cGxlLA0KICAgcmVtb3ZpbmcgdGhlICIqIiBmcm9tIHRoZSBlbmQgb2YgYW4gZXh0ZW5kZWQgbGFu Z3VhZ2UgcmFuZ2UgKHNlZQ0KICAgU2VjdGlvbiAyLjIpIGNhbiBncmVhdGx5IG1vZGlmeSB0aGUg c2V0IG9mIHJldHVybmVkIG1hdGNoZXMuICBBDQogICBwcm90b2NvbCB0aGF0IGFsbG93cyB0YWdz IG9yIHJhbmdlcyB0byBiZSB0cnVuY2F0ZWQgYXQgYW4gYXJiaXRyYXJ5DQogICBsaW1pdCwgd2l0 aG91dCBnaXZpbmcgYW55IGluZGljYXRpb24gb2Ygd2hhdCB0aGF0IGxpbWl0IGlzLCBoYXMgdGhl DQogICBwb3RlbnRpYWwgZm9yIGNhdXNpbmcgaGFybSBieSBjaGFuZ2luZyB0aGUgbWVhbmluZyBv ZiB2YWx1ZXMgaW4NCiAgIHN1YnN0YW50aWFsIHdheXMuDQoNCiAgIEluIHByYWN0aWNlLCBtb3N0 IHRhZ3MgZG8gbm90IHJlcXVpcmUgYWRkaXRpb25hbCBzdWJ0YWdzIG9yDQogICBzdWJzdGFudGlh bGx5IG1vcmUgY2hhcmFjdGVycy4gIEFkZGl0aW9uYWwgc3VidGFncyBzb21ldGltZXMgYWRkDQog ICB1c2VmdWwgZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24sIGJ1dCBleHRyYW5lb3VzIHN1YnRh Z3MgaW50ZXJmZXJlDQogICB3aXRoIHRoZSBtZWFuaW5nLCB1bmRlcnN0YW5kaW5nLCBhbmQgZXNw ZWNpYWxseSBtYXRjaGluZyBvZiBsYW5ndWFnZQ0KICAgdGFncy4gIFNpbmNlIGxhbmd1YWdlIHRh Z3Mgb3IgcmFuZ2VzIE1BWSBiZSB0cnVuY2F0ZWQgYnkgYW4NCiAgIGFwcGxpY2F0aW9uIG9yIHBy b3RvY29sIHRoYXQgbGltaXRzIHN0b3JhZ2UsIHdoZW4gY2hvb3NpbmcgbGFuZ3VhZ2UNCiAgIHRh Z3Mgb3IgcmFuZ2VzIHVzZXJzIGFuZCBhcHBsaWNhdGlvbnMgU0hPVUxEIGF2b2lkIGFkZGluZyBz dWJ0YWdzDQogICB0aGF0IGFkZCBubyBkaXN0aW5ndWlzaGluZyB2YWx1ZS4gIEluIHBhcnRpY3Vs YXIsIHVzZXJzIGFuZA0KICAgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBmb2xsb3cgdGhlICdQcmVm aXgnIGFuZCAnU3VwcHJlc3MtU2NyaXB0Jw0KICAgZmllbGRzIGluIHRoZSByZWdpc3RyeSAoZGVm aW5lZCBpbiBTZWN0aW9uIDMuNiBvZiBbZHJhZnQtcmVnaXN0cnldKToNCiAgIHRoZXNlIGZpZWxk cyBwcm92aWRlIGd1aWRhbmNlIG9uIHdoZW4gc3BlY2lmaWMgYWRkaXRpb25hbCBzdWJ0YWdzDQog ICBTSE9VTEQgKGFuZCBTSE9VTEQgTk9UKSBiZSB1c2VkLg0KDQogICBJbXBsZW1lbnRhdGlvbnMg TVVTVCBzdXBwb3J0IGEgbGltaXQgb2YgYXQgbGVhc3QgMzMgY2hhcmFjdGVycy4gIFRoaXMNCiAg IGxpbWl0IGluY2x1ZGVzIGF0IGxlYXN0IG9uZSBzdWJ0YWcgb2YgZWFjaCBub24tZXh0ZW5zaW9u LCBub24tcHJpdmF0ZQ0KICAgdXNlIHR5cGUuICBXaGVuIGNob29zaW5nIGEgYnVmZmVyIGxpbWl0 LCBhIGxlbmd0aCBvZiBhdCBsZWFzdCA0Mg0KICAgY2hhcmFjdGVycyBpcyBzdHJvbmdseSBSRUNP TU1FTkRFRC4NCg0KICAgVGhlIHByYWN0aWNhbCBsaW1pdCBvbiB0YWdzIG9yIHJhbmdlcyBkZXJp dmVkIHNvbGVseSBmcm9tIHJlZ2lzdGVyZWQNCiAgIHZhbHVlcyBpcyA0MiBjaGFyYWN0ZXJzLiAg SW1wbGVtZW50YXRpb25zIE1VU1QgYmUgYWJsZSB0byBoYW5kbGUgdGFncw0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAg W1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5n ICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQogICBhbmQgcmFuZ2VzIG9mIHRoaXMg bGVuZ3RoLiAgU3VwcG9ydCBmb3IgdGFncyBhbmQgcmFuZ2VzIG9mIGF0IGxlYXN0DQogICA2MiBj aGFyYWN0ZXJzIGluIGxlbmd0aCBpcyBSRUNPTU1FTkRFRC4gIEltcGxlbWVudGF0aW9ucyBNQVkg c3VwcG9ydA0KICAgbG9uZ2VyIHZhbHVlcywgaW5jbHVkaW5nIG1hdGNoaW5nIGV4dGVuc2l2ZSBz ZXRzIG9mIHByaXZhdGUgdXNlIG9yDQogICBleHRlbnNpb24gc3VidGFncy4NCg0KICAgQXBwbGlj YXRpb25zIG9yIHByb3RvY29scyB3aGljaCBoYXZlIHRvIHRydW5jYXRlIGEgdGFnIE1VU1QgZG8g c28gYnkNCiAgIHByb2dyZXNzaXZlbHkgcmVtb3Zpbmcgc3VidGFncyBhbG9uZyB3aXRoIHRoZWly IHByZWNlZGluZyAiLSIgZnJvbQ0KICAgdGhlIHJpZ2h0IHNpZGUgb2YgdGhlIGxhbmd1YWdlIHRh ZyB1bnRpbCB0aGUgdGFnIGlzIHNob3J0IGVub3VnaCBmb3INCiAgIHRoZSBnaXZlbiBidWZmZXIu ICBJZiB0aGUgcmVzdWx0aW5nIHRhZyBlbmRzIHdpdGggYSBzaW5nbGUtY2hhcmFjdGVyDQogICBz dWJ0YWcsIHRoYXQgc3VidGFnIGFuZCBpdHMgcHJlY2VkaW5nICItIiBNVVNUIGFsc28gYmUgcmVt b3ZlZC4gIEZvcg0KICAgZXhhbXBsZToNCg0KICAgVGFnIHRvIHRydW5jYXRlOiB6aC1IYW50LUNO LXZhcmlhbnQxLWEtZXh0ZW5kMS14LXdhZGVnaWxlLXByaXZhdGUxDQogICAxLiB6aC1IYW50LUNO LXZhcmlhbnQxLWEtZXh0ZW5kMS14LXdhZGVnaWxlDQogICAyLiB6aC1IYW50LUNOLXZhcmlhbnQx LWEtZXh0ZW5kMQ0KICAgMy4gemgtSGFudC1DTi12YXJpYW50MQ0KICAgNC4gemgtSGFudC1DTg0K ICAgNS4gemgtSGFudA0KICAgNi4gemgNCg0KICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNjog RXhhbXBsZSBvZiBUYWcgVHJ1bmNhdGlvbg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4 cGlyZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2VwdGVt YmVyIDIwMDUNCg0KDQozLiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50 IHByZXNlbnRzIG5vIG5ldyBvciBleGlzdGluZyBjb25zaWRlcmF0aW9ucyBmb3IgSUFOQS4NCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICBFeHBpcmVzIE1hcmNoIDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAg IFNlcHRlbWJlciAyMDA1DQoNCg0KNC4gIENoYW5nZXMNCg0KICAgVGhpcyBpcyB0aGUgZmlyc3Qg dmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBUaGUgZm9sbG93aW5nIGNoYW5nZXMgd2Vy ZSBwdXQgaW50byB0aGlzIGRvY3VtZW50IHNpbmNlIGRyYWZ0LTAzOg0KDQogICAgICBNb2RpZmll ZCB0aGUgQUJORiB0byBtYXRjaCBjaGFuZ2VzIGluIFtkcmFmdC1yZWdpc3RyeV0NCiAgICAgIChL Lkthcmxzc29uKQ0KDQogICAgICBNYXRjaGVkIHRoZSByZWZlcmVuY2VzIGFuZCByZWZlcmVuY2Ug Zm9ybWF0cyB0byBbZHJhZnQtcmVnaXN0cnldDQogICAgICAoSy5LYXJsc3NvbikNCg0KICAgICAg VmFyaW91cyBlZGl0cywgYWRkaXRpb25zLCBhbmQgZW1lbmRhdGlvbnMgdG8gZGVhbCB3aXRoIGNo YW5nZXMgaW4NCiAgICAgIHRoZSBMYXN0IENhbGwgb2YgZHJhZnQtcmVnaXN0cnkgYXMgd2VsbCBh cyBjbGVhbmluZyB1cCB0aGUgdGV4dC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMThd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAg ICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0K ICAgTGFuZ3VhZ2UgcmFuZ2VzIHVzZWQgaW4gY29udGVudCBuZWdvdGlhdGlvbiBtaWdodCBiZSB1 c2VkIHRvIGluZmVyDQogICB0aGUgbmF0aW9uYWxpdHkgb2YgdGhlIHNlbmRlciwgYW5kIHRodXMg aWRlbnRpZnkgcG90ZW50aWFsIHRhcmdldHMNCiAgIGZvciBzdXJ2ZWlsbGFuY2UuICBJbiBhZGRp dGlvbiwgdW5pcXVlIG9yIGhpZ2hseSB1bnVzdWFsIGxhbmd1YWdlDQogICByYW5nZXMgb3IgY29t YmluYXRpb25zIG9mIGxhbmd1YWdlIHJhbmdlcyBtaWdodCBiZSB1c2VkIHRvIHRyYWNrDQogICBz cGVjaWZpYyBpbmRpdmlkdWFsJ3MgYWN0aXZpdGllcy4NCg0KICAgVGhpcyBpcyBhIHNwZWNpYWwg Y2FzZSBvZiB0aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcgeW91IHNlbmQNCiAgIGlz IHZpc2libGUgdG8gdGhlIHJlY2VpdmluZyBwYXJ0eS4gIEl0IGlzIHVzZWZ1bCB0byBiZSBhd2Fy ZSB0aGF0DQogICBzdWNoIGNvbmNlcm5zIGNhbiBleGlzdCBpbiBzb21lIGNhc2VzLg0KDQogICBU aGUgZXZhbHVhdGlvbiBvZiB0aGUgZXhhY3QgbWFnbml0dWRlIG9mIHRoZSB0aHJlYXQsIGFuZCBh bnkgcG9zc2libGUNCiAgIGNvdW50ZXJtZWFzdXJlcywgaXMgbGVmdCB0byBlYWNoIGFwcGxpY2F0 aW9uIHByb3RvY29sLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAg RXhwaXJlcyBNYXJjaCAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICBTZXB0 ZW1iZXIgMjAwNQ0KDQoNCjYuICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25zDQoNCiAgIFRo ZSBzeW50YXggb2YgbGFuZ3VhZ2UgdGFncyBhbmQgbGFuZ3VhZ2UgcmFuZ2VzIHBlcm1pdCBvbmx5 IHRoZQ0KICAgY2hhcmFjdGVycyBBLVosIGEteiwgMC05LCBhbmQgSFlQSEVOLU1JTlVTICgleDJE KS4gIFRoZXNlIGNoYXJhY3RlcnMNCiAgIGFyZSBwcmVzZW50IGluIG1vc3QgY2hhcmFjdGVyIHNl dHMsIHNvIHByZXNlbnRhdGlvbiBvZiBsYW5ndWFnZSB0YWdzDQogICBzaG91bGQgbm90IHByZXNl bnQgYW55IGNoYXJhY3RlciBzZXQgaXNzdWVzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjcsIDIwMDYgICAg ICAgICAgICAgICAgW1BhZ2UgMjBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBs dHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDUNCg0KDQo3LiAgUmVmZXJl bmNlcw0KDQo3LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtJRC5pZXRmLWx0cnUtaW5p dGlhbF0NCiAgICAgICAgICAgICAgRXdlbGwsIEQuLCBFZC4sICJMYW5ndWFnZSBUYWdzIEluaXRp YWwgUmVnaXN0cnkgKHdvcmsgaW4NCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpIiwgQXVndXN0IDIw MDUsIDxodHRwOi8vd3d3LmlldGYub3JnLw0KICAgICAgICAgICAgICBpbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi1sdHJ1LWluaXRpYWwtMDQudHh0Pi4NCg0KICAgW1JGQzEzMjddICBIYXJkY2Fz dGxlLUtpbGxlLCBTLiwgIk1hcHBpbmcgYmV0d2VlbiBYLjQwMCgxOTg4KSAvIElTTw0KICAgICAg ICAgICAgICAxMDAyMSBhbmQgUkZDIDgyMiIsIFJGQyAxMzI3LCBNYXkgMTk5Mi4NCg0KICAgW1JG QzE1MjFdICBCb3JlbnN0ZWluLCBOLiBhbmQgTi4gRnJlZWQsICJNSU1FIChNdWx0aXB1cnBvc2Ug SW50ZXJuZXQNCiAgICAgICAgICAgICAgTWFpbCBFeHRlbnNpb25zKSBQYXJ0IE9uZTogTWVjaGFu aXNtcyBmb3IgU3BlY2lmeWluZyBhbmQNCiAgICAgICAgICAgICAgRGVzY3JpYmluZyB0aGUgRm9y bWF0IG9mIEludGVybmV0IE1lc3NhZ2UgQm9kaWVzIiwNCiAgICAgICAgICAgICAgUkZDIDE1MjEs IFNlcHRlbWJlciAxOTkzLg0KDQogICBbUkZDMjAyOF0gIEhvdmV5LCBSLiBhbmQgUy4gQnJhZG5l ciwgIlRoZSBPcmdhbml6YXRpb25zIEludm9sdmVkIGluDQogICAgICAgICAgICAgIHRoZSBJRVRG IFN0YW5kYXJkcyBQcm9jZXNzIiwgQkNQIDExLCBSRkMgMjAyOCwNCiAgICAgICAgICAgICAgT2N0 b2JlciAxOTk2Lg0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMi LCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDMjIzMV0gIEZyZWVkLCBO LiBhbmQgSy4gTW9vcmUsICJNSU1FIFBhcmFtZXRlciBWYWx1ZSBhbmQgRW5jb2RlZA0KICAgICAg ICAgICAgICBXb3JkIEV4dGVuc2lvbnM6IENoYXJhY3RlciBTZXRzLCBMYW5ndWFnZXMsIGFuZA0K ICAgICAgICAgICAgICBDb250aW51YXRpb25zIiwgUkZDIDIyMzEsIE5vdmVtYmVyIDE5OTcuDQoN CiAgIFtSRkMyMjM0YmlzXQ0KICAgICAgICAgICAgICBDcm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVs bCwgIkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRheA0KICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9u czogQUJORiIsIGRyYWZ0LWNyb2NrZXItYWJuZi1yZmMyMjM0YmlzLTAwDQogICAgICAgICAgICAg ICh3b3JrIGluIHByb2dyZXNzKSwgTWFyY2ggMjAwNS4NCg0KICAgW1JGQzIzOTZdICBCZXJuZXJz LUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAiVW5pZm9ybQ0KICAgICAg ICAgICAgICBSZXNvdXJjZSBJZGVudGlmaWVycyAoVVJJKTogR2VuZXJpYyBTeW50YXgiLCBSRkMg MjM5NiwNCiAgICAgICAgICAgICAgQXVndXN0IDE5OTguDQoNCiAgIFtSRkMyNDM0XSAgTmFydGVu LCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4NCiAgICAg ICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJG QyAyNDM0LA0KICAgICAgICAgICAgICBPY3RvYmVyIDE5OTguDQoNCiAgIFtSRkMyNjE2XSAgRmll bGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLA0KICAgICAgICAg ICAgICBNYXNpbnRlciwgTC4sIExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAiSHlwZXJ0 ZXh0DQogICAgICAgICAgICAgIFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xIiwgUkZDIDI2 MTYsIEp1bmUgMTk5OS4NCg0KICAgW1JGQzI4NjBdICBDYXJwZW50ZXIsIEIuLCBCYWtlciwgRi4s IGFuZCBNLiBSb2JlcnRzLCAiTWVtb3JhbmR1bSBvZg0KICAgICAgICAgICAgICBVbmRlcnN0YW5k aW5nIENvbmNlcm5pbmcgdGhlIFRlY2huaWNhbCBXb3JrIG9mIHRoZQ0KICAgICAgICAgICAgICBJ bnRlcm5ldCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSIsIFJGQyAyODYwLCBKdW5lIDIwMDAu DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNywgMjAwNiAg ICAgICAgICAgICAgICBbUGFnZSAyMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg IGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCiAgIFtSRkMz NjI5XSAgWWVyZ2VhdSwgRi4sICJVVEYtOCwgYSB0cmFuc2Zvcm1hdGlvbiBmb3JtYXQgb2YgSVNP DQogICAgICAgICAgICAgIDEwNjQ2IiwgU1REIDYzLCBSRkMgMzYyOSwgTm92ZW1iZXIgMjAwMy4N Cg0KICAgW2RyYWZ0LXJlZ2lzdHJ5XQ0KICAgICAgICAgICAgICBQaGlsbGlwcywgQS4sIEVkLiBh bmQgTS4gRGF2aXMsIEVkLiwgIlRhZ3MgZm9yIHRoZQ0KICAgICAgICAgICAgICBJZGVudGlmaWNh dGlvbiBvZiBMYW5ndWFnZXMgKHdvcmsgaW4gcHJvZ3Jlc3MpIiwNCiAgICAgICAgICAgICAgQXVn dXN0IDIwMDUsIDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LTEyLnR4dD4uDQoNCjcuMiAgSW5mb3JtYXRp dmUgUmVmZXJlbmNlcw0KDQogICBbSVNPMTU5MjRdDQogICAgICAgICAgICAgICJJU08gMTU5MjQ6 MjAwNC4gSW5mb3JtYXRpb24gYW5kIGRvY3VtZW50YXRpb24gLS0gQ29kZXMNCiAgICAgICAgICAg ICAgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBzY3JpcHRzIiwgSmFudWFyeSAy MDA0Lg0KDQogICBbSVNPMzE2Ni0xXQ0KICAgICAgICAgICAgICAiSVNPIDMxNjYtMToxOTk3LiBD b2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mDQogICAgICAgICAgICAgIGNv dW50cmllcyBhbmQgdGhlaXIgc3ViZGl2aXNpb25zIC0tIFBhcnQgMTogQ291bnRyeQ0KICAgICAg ICAgICAgICBjb2RlcyIsIDE5OTcuDQoNCiAgIFtJU082MzktMV0NCiAgICAgICAgICAgICAgIklT TyA2MzktMToyMDAyLiBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mDQog ICAgICAgICAgICAgIGxhbmd1YWdlcyAtLSBQYXJ0IDE6IEFscGhhLTIgY29kZSIsIDIwMDIuDQoN CiAgIFtJU082MzktMl0NCiAgICAgICAgICAgICAgIklTTyA2MzktMjoxOTk4LiBDb2RlcyBmb3Ig dGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mDQogICAgICAgICAgICAgIGxhbmd1YWdlcyAt LSBQYXJ0IDI6IEFscGhhLTMgY29kZSwgZmlyc3QgZWRpdGlvbiIsIDE5OTguDQoNCiAgIFtSRkMx NzY2XSAgQWx2ZXN0cmFuZCwgSC4sICJUYWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2YNCiAg ICAgICAgICAgICAgTGFuZ3VhZ2VzIiwgUkZDIDE3NjYsIE1hcmNoIDE5OTUuDQoNCiAgIFtSRkMz MDY2XSAgQWx2ZXN0cmFuZCwgSC4sICJUYWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2YNCiAg ICAgICAgICAgICAgTGFuZ3VhZ2VzIiwgQkNQIDQ3LCBSRkMgMzA2NiwgSmFudWFyeSAyMDAxLg0K DQogICBbUkZDMzMzOV0gIEtseW5lLCBHLiBhbmQgQy4gTmV3bWFuLCAiRGF0ZSBhbmQgVGltZSBv biB0aGUgSW50ZXJuZXQ6DQogICAgICAgICAgICAgIFRpbWVzdGFtcHMiLCBSRkMgMzMzOSwgSnVs eSAyMDAyLg0KDQogICBbVU5fTS40OV0gIFN0YXRpc3RpY3MgRGl2aXNpb24sIFVuaXRlZCBOYXRp b25zLCAiU3RhbmRhcmQgQ291bnRyeSBvcg0KICAgICAgICAgICAgICBBcmVhIENvZGVzIGZvciBT dGF0aXN0aWNhbCBVc2UiLCBVTiBTdGFuZGFyZCBDb3VudHJ5IG9yDQogICAgICAgICAgICAgIEFy ZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2FsIFVzZSwgUmV2aXNpb24gNCAoVW5pdGVkIE5hdGlvbnMN CiAgICAgICAgICAgICAgcHVibGljYXRpb24sIFNhbGVzIE5vLiA5OC5YVklJLjksIEp1bmUgMTk5 OS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMg TWFyY2ggMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIw MDUNCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgQWRkaXNvbiBQaGlsbGlwcyAoZWRpdG9y KQ0KICAgUXVlc3QgU29mdHdhcmUNCg0KICAgRW1haWw6IGFkZGlzb24gZG90IHBoaWxsaXBzIGF0 IHF1ZXN0IGRvdCBjb20NCg0KDQogICBNYXJrIERhdmlzIChlZGl0b3IpDQogICBJQk0NCg0KICAg RW1haWw6IG1hcmsgZG90IGRhdmlzIGF0IGlibSBkb3QgY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNywgMjAwNiAgICAgICAg ICAgICAgICBbUGFnZSAyM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUt bWF0Y2hpbmcgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNQ0KDQoNCkFwcGVuZGl4IEEuICBB Y2tub3dsZWRnZW1lbnRzDQoNCiAgIEFueSBsaXN0IG9mIGNvbnRyaWJ1dG9ycyBpcyBib3VuZCB0 byBiZSBpbmNvbXBsZXRlOyBwbGVhc2UgcmVnYXJkIHRoZQ0KICAgZm9sbG93aW5nIGFzIG9ubHkg YSBzZWxlY3Rpb24gZnJvbSB0aGUgZ3JvdXAgb2YgcGVvcGxlIHdobyBoYXZlDQogICBjb250cmli dXRlZCB0byBtYWtlIHRoaXMgZG9jdW1lbnQgd2hhdCBpdCBpcyB0b2RheS4NCg0KICAgVGhlIGNv bnRyaWJ1dG9ycyB0byBbZHJhZnQtcmVnaXN0cnldLCBbUkZDMzA2Nl0gYW5kIFtSRkMxNzY2XSwg ZWFjaA0KICAgb2Ygd2hpY2ggaXMgYSAgcHJlY3Vyc29yIHRvIHRoaXMgZG9jdW1lbnQsIG1hZGUg ZW5vcm1vdXMNCiAgIGNvbnRyaWJ1dGlvbnMgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSB0byB0aGlz IGRvY3VtZW50IGFuZCBhcmUNCiAgIGdlbmVyYWxseSByZXNwb25zaWJsZSBmb3IgdGhlIHN1Y2Nl c3Mgb2YgbGFuZ3VhZ2UgdGFncy4NCg0KICAgVGhlIGZvbGxvd2luZyBwZW9wbGUgKGluIGFscGhh YmV0aWNhbCBvcmRlciBieSBmYW1pbHkgbmFtZSkNCiAgIGNvbnRyaWJ1dGVkIHRvIHRoaXMgZG9j dW1lbnQ6DQoNCiAgIEplcmVteSBDYXJyb2xsLCBKb2huIENvd2FuLCBGcmFuayBFbGxlcm1hbm4s IERvdWcgRXdlbGwsIEtlbnQNCiAgIEthcmxzc29uLCBJcmEgTWNEb25hbGQsIE0uIFBhdHRvbiwg UmFuZHkgUHJlc3VobiBhbmQgbWFueSwgbWFueQ0KICAgb3RoZXJzLg0KDQogICBWZXJ5IHNwZWNp YWwgdGhhbmtzIG11c3QgZ28gdG8gSGFyYWxkIFR2ZWl0IEFsdmVzdHJhbmQsIHdobw0KICAgb3Jp Z2luYXRlZCBSRkNzIDE3NjYgYW5kIDMwNjYsIGFuZCB3aXRob3V0IHdob20gdGhpcyBkb2N1bWVu dCB3b3VsZA0KICAgbm90IGhhdmUgYmVlbiBwb3NzaWJsZS4NCg0KICAgRm9yIHRoaXMgcGFydGlj dWxhciBkb2N1bWVudCwgSm9obiBDb3dhbiBvcmlnaW5hdGVkIHRoZSBzY2hlbWUNCiAgIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDIuMi4zLiAgTWFyayBEYXZpcyBvcmlnaW5hdGVkIHRoZSBzY2hlbWUN CiAgIGRlc2NyaWJlZCBpbiB0aGUgU2VjdGlvbiAyLjEuMi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAg RXhwaXJlcyBNYXJjaCAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICBTZXB0 ZW1iZXIgMjAwNQ0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhl IElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBv ZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRo YXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24g b3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBv ciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBt aWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhh dCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkg c3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNw ZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4 IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUg SUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJl IG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8g b2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAg IHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlz DQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUg SVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUg SUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRp b24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9y IG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0 aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVh c2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGll dGYub3JnLg0KDQoNCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBh bmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQog ICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUv U0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVS TkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBE SVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5H IEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAg SU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElN UExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QNCiAgIHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFp bmVkIGluIEJDUCA3OCwgYW5kDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBh dXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAg IEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRl ZCBieSB0aGUNCiAgIEludGVybmV0IFNvY2lldHkuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgICBFeHBpcmVzIE1hcmNoIDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDI1XQ0K DA0K ------_=_NextPart_001_01C5C067.5CFE040A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C5C067.5CFE040A-- From ltru-bounces@ietf.org Fri Sep 23 13:53:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrjv-0002bB-Cl; Fri, 23 Sep 2005 13:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrjt-0002b6-TZ for ltru@megatron.ietf.org; Fri, 23 Sep 2005 13:53:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27194 for ; Fri, 23 Sep 2005 13:53:36 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIrqN-0004W0-Ri for ltru@ietf.org; Fri, 23 Sep 2005 14:00:20 -0400 Received: from alvmbxw02.prod.quest.corp ([10.1.0.209]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 10:53:28 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by alvmbxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 10:53:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 64thIETF Meeting in Vancouver, British Columbia, Canada Date: Fri, 23 Sep 2005 10:53:17 -0700 Message-ID: Thread-Topic: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 64thIETF Meeting in Vancouver, British Columbia, Canada thread-index: AcXAXwCFG/8z2zmESVms8uMMRAcePwACFpig From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 23 Sep 2005 17:53:27.0933 (UTC) FILETIME=[B3B8E2D0:01C5C067] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Randy, Thanks for pointing this out. I don't think we're that far from done on this work. In doing all the = diffs and idnits stuff this morning, I found that we've done a fair bit = to flesh out the distance metric stuff (which was the weakest portion of = the document) and otherwise fill in the various gaps. I have some notes about the document, which I will forward, one issue = per message, in a few minutes. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: vendredi 23 septembre 2005 09:53 > To: LTRU Working Group > Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the > 64thIETF Meeting in Vancouver, British Columbia, Canada >=20 > Hi - >=20 > Please note that October 24 is a critical date for us if we are to = meet > October milestone for completing the matching draft! >=20 > Randy >=20 > ----- Original Message ----- > > From: > > To: > > Sent: Thursday, September 22, 2005 9:00 PM > > Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF > Meeting in Vancouver, British Columbia, Canada > > > > > > There are two (2) Internet-Draft cutoff dates for the 64th > > IETF Meeting in Vancouver, British Columbia, Canada: > > > > October 17th: Cutoff Date for Initial (i.e., version -00) > > Internet-Draft Submissions > > > > All initial Internet-Drafts (version -00) must be submitted by = Monday, > > October 17th at 9:00 AM ET. As always, all initial submissions with = a > > filename beginning with "draft-ietf" must be approved by the > > appropriate WG Chair before they can be processed or announced. The > > Secretariat would appreciate receiving WG Chair approval by Monday, > > October 10th at 9:00 AM ET. > > > > October 24th: Cutoff Date for Revised (i.e., version -01 and higher) > > Internet-Draft Submissions > > > > All revised Internet-Drafts (version -01 and higher) must be = submitted > > by Monday, October 24th at 9:00 AM ET. > > > > Initial and revised Internet-Drafts received after their respective > > cutoff dates will not be made available in the Internet-Drafts > > directory or announced until on or after Monday, November 7th at = 9:00 > > AM ET, when Internet-Draft posting resumes. Please do not wait = until > > the last minute to submit. > > > > Thank you for your understanding and cooperation. If you have any > > questions or concerns, then please send a message to > > internet-drafts@ietf.org. > > > > The IETF Secretariat > > > > FYI: The Internet-Draft cutoff dates as well as other significant = dates > > for the 64th IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_64.html. > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 15:01:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsnK-0001Ls-TW; Fri, 23 Sep 2005 15:01:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsnJ-0001Ll-5V for ltru@megatron.ietf.org; Fri, 23 Sep 2005 15:01:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00041 for ; Fri, 23 Sep 2005 15:01:11 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIstm-00062J-LY for ltru@ietf.org; Fri, 23 Sep 2005 15:07:56 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EIsn8-0004Lz-Ks; Fri, 23 Sep 2005 12:01:03 -0700 Message-Id: <6.2.3.4.2.20050923205817.04fceeb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 23 Sep 2005 21:00:55 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] el truth? In-Reply-To: <000901c5c05f$1f764d40$7f1afea9@oemcomputer> References: <20050921165755.JTXF3524.edge5.adelphia.net@megatron.ietf.org> <005601c5c004$1f42c980$030aa8c0@DEWELL> <6.2.3.4.2.20050923145524.03dec740@mail.afrac.org> <000901c5c05f$1f764d40$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 18:52 23/09/2005, Randy Presuhn wrote: >Hi - >Offensive, off-topic postings do not merit further comment. Offensive? Off-topic? It seems you really have a problem with networked language understanding and multicultural real world! That kind of comment identify the author .... Please indicate your langtag for that file. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Sep 23 15:50:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItYm-00049y-5w; Fri, 23 Sep 2005 15:50:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItYZ-000450-Ov; Fri, 23 Sep 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03429; Fri, 23 Sep 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EItf3-000788-OT; Fri, 23 Sep 2005 15:56:46 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EItYX-0002iE-VC; Fri, 23 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-04.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Matching Tags for the Identification of Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-matching-04.txt Pages : 25 Date : 2005-9-23 This document describes different mechanisms for comparing, matching, and evaluating language tags. Possible algorithms for language negotiation and content selection are described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-matching-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-matching-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-23144046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-23144046.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Sat Sep 24 19:23:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJJMu-0007rk-VE; Sat, 24 Sep 2005 19:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJJMt-0007rf-JX for ltru@megatron.ietf.org; Sat, 24 Sep 2005 19:23:43 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28008 for ; Sat, 24 Sep 2005 19:23:39 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050924232311.TBGD12165.mta10.adelphia.net@DEWELL>; Sat, 24 Sep 2005 19:23:11 -0400 Message-ID: <003001c5c15e$e5fbd3e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050921165755.JTXF3524.edge5.adelphia.net@megatron.ietf.org> Date: Sat, 24 Sep 2005 16:22:56 -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 Content-Transfer-Encoding: 7bit Cc: John C Klensin Subject: [Ltru] Re: Note to RFC editor in initial registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > By the way, John Klensin proposed that the note be something like > > "3. The initial contents of the registry as specified > in this document are those entries in the IANA registry > [IANA-registry] with a field-name of "Added" and a value > of "2005-07-10". Note that [ltru-registry, Section 3.1] > requires that an "Added" field appear in each > registration record and that its Section 3.3(1) > specifies that field must not be changed after > registration." My concern with this is that it goes beyond the original intent of restricting the delivery of the initial registry contents to the RFC Editor, and reducing the size of draft-initial. It attempts to explain to the reader how she may reconstruct the initial registry on her own. Not only do I think this is a non-goal, I can think of two reasons why it doesn't work: (1) The redundant and grandfathered tags don't have an "Added" date of 2005-07-10 (or whatever the actual pub date is). Instead, their "Added" date is the same as the date the record was added to the RFC 3066 whole-tag registry. For example, the "Added" date for i-ami is 1999-05-25. This could be easily fixed by changing John's text to read "... and a value no later than '2005-07-10'," being careful to use the real cutoff date. (2) More problematic, for purposes of reconstructing the initial registry, is the fact that the "Added" date is not changed when a change is made to the record, such as adding a "Suppress-Script" field where none previously existed. This is not an "ambiguity," as Ira stated, but it does mean that a record with date X might have been modified some time after X. In order to allow reconstruction of a previous version, there would have to be a "Last-Modified" field, and no, I am not advocating adding such a field at this late date. I think we need to decide whether we want draft-initial to be simply a means of communicating the initial registry contents to IANA, or also allow users at some arbitrary future date to reconstruct the initial registry somehow. If we want to stick to the original intent, then we should simply state that the actual initial contents were stripped by the RFC Editor to reduce size, prevent misuse, etc. and leave it at that. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 24 20:01:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJJxp-000594-Lq; Sat, 24 Sep 2005 20:01:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJJxo-00057A-7B for ltru@megatron.ietf.org; Sat, 24 Sep 2005 20:01:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29258 for ; Sat, 24 Sep 2005 20:01:50 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJK4X-0002E3-Ok for ltru@ietf.org; Sat, 24 Sep 2005 20:08:50 -0400 Received: from alvmbxw02.prod.quest.corp ([10.1.0.209]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 17:01:37 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by alvmbxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 17:01:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 17:01:25 -0700 Message-ID: Thread-Topic: [Ltru] Re: Note to RFC editor in initial registry thread-index: AcXBXyFXFuDmer1vQpOc7eY50oW2sgAAJddg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 25 Sep 2005 00:01:37.0688 (UTC) FILETIME=[4CA7C180:01C5C164] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: John C Klensin X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1510463193==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1510463193== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RG91ZywNCg0KSSBhZ3JlZSB3aXRoIHlvdXIgZ2VuZXJhbCBpZGVhLiBJIGRvbid0IHNlZSBhbnkg dXRpbGl0eSBpbiByZWNvbnN0cnVjdGluZyB0aGUgb3JpZ2luYWwgcmVnaXN0cnkuIFRoZSBwb2lu dCBvZiB0aGUgdGV4dCBpbiB0aGUgZHJhZnQsIGFzIEkgcmVjYWxsLCB3YXMgdG8gZW5hYmxlIG91 ciBjb250ZW1wb3JhcmllcyB0byBkZXRlcm1pbmUgd2h5IHRoZSBpbml0aWFsIHJlZ2lzdHJ5IGlz IHRoZSB3YXkgaXQgaXMsIG5vdCB0byBlbmFibGUgb3VyIGRlc2NlbmRhbnRzIHRvIHJlY29uc3Ry dWN0IHRoZSBleGFjdCByZWdpc3RyeSAoYSBwcm9qZWN0IG9mIGR1YmlvdXMgdmFsdWUpLg0KDQpU aGUgcHVycG9zZSBvZiAnQWRkZWQnIGlzIGRldGVybWluaW5nIHdoZXRoZXIgYSBwYXJ0aWN1bGFy IHN1YnRhZyB3YXMgdmFsaWQgYXMgb2YgYSBwYXJ0aWN1bGFyIGRhdGUuIERhdGVzIGVhcmxpZXIg dGhhbiAiRGF0ZSBCIiBhcmUgYXQgYmVzdCBpbmZvcm1hdGl2ZTogdGhleSBoYXZlIG5vIG1lYW5p bmcgaW4gdGhlIGNvbnRleHQgb2YgMzA2NmJpcyBbbm8gc3VidGFncyB3ZXJlIGluIHRoZSByZWdp c3RyeSBiZWZvcmUgdGhlIHJlZ2lzdHJ5IHdhcyBjcmVhdGVkOyBzb21lIHN1YnRhZ3Mgd2VyZSB2 YWxpZCBpbiBSRkMgMzA2NiB0YWdzLCBhbmQgJ0FkZGVkJyBjYW4gYmUgdXNlZCB0byBkZXRlcm1p bmUgd2hpY2ggb25lcyB3ZXJlIHZhbGlkIGFzIG9mIERhdGUgQl0uIA0KDQpUaGUgJ0FkZGVkJyBk YXRlLCBhcyBwcmVzZW50bHkgY29tcG9zZWQsIGlzIHVzZWZ1bCBpbiBhdCBsZWFzdCB0aGVzZSB0 d28gY2FzZXM6DQoNCmkuIGlmIG9uZSB3aXNoZXMgdG8gZGV0ZXJtaW5lIGlmIGEgcGFydGljdWxh ciB2YWxpZGF0aW5nIHRhZyBwcm9jZXNzb3IgKHdpdGggYSBnaXZlbiBmaWxlLWRhdGUpIHN1cHBv cnRzIGEgcGFydGljdWxhciB0YWcgb3Igc3VidGFnDQoNCmlpLiBpZiBvbmUgd2lzaGVzIHRvIGNy ZWF0ZSBhIHByb2Nlc3NvciB3aGljaCB2YWxpZGF0ZXMgdGFncyBhcyBvZiBhIHBhcnRpY3VsYXIg ZGF0ZSAocG9zc2libHkgaW4gY29uY2VydCB3aXRoIGRpZmZlcmVudCBtYXBwaW5nIHZhbHVlcyBj b3VydGVzeSBvZiB0aGUgJ0RlcHJlY2F0ZWQnIGRhdGUgZmllbGQpDQoNCkl0IGlzIHVzZWZ1bCB0 byBwb2ludCBvdXQgdGhhdCB0aGUgRmlsZS1EYXRlIHZhbHVlIG1heSBiZSBsYXRlciB0aGFuIGV2 ZXJ5ICdBZGRlZCcgYW5kICdEZXByZWNhdGVkJyB2YWx1ZSBpbiB0aGUgcmVnaXN0cnkuIFRoYXQg aXMsIHRoZXJlIG1heSBub3QgYmUgYSBkYXRlIHZhbHVlIGluIHRoZSByZWdpc3RyeSBlcXVhbCB0 byB0aGUgRmlsZS1EYXRlLg0KDQpJbiBhbnkgY2FzZSwgeW91IGRvbid0IG5lZWQgdG8gYWRvcHQg Sm9obiBLbGVuc2luJ3MgZXhhY3Qgd29yZHMuIEl0IHNlZW1zIHRvIG1lIHRoYXQgaGUgd2FzIHVu YXdhcmUgb2Ygc29tZSBvZiB0aGUgZGV0YWlscyBvZiByZWdpc3RyYXRpb24gYW5kIHByb3Bvc2Vk IHRleHQgdGhhdCBzZWVtZWQgZml0dGluZy4gSSB3b3VsZCBzdWdnZXN0IHRoYXQgeW91IGp1c3Qg bW9kaWZ5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGFuZCB3ZSBtb3ZlIGFsb25nLiBIb3cgYWJvdXQ6 DQoNCi0tDQozLiAgVGhlIGluaXRpYWwgc2V0IG9mIHN1YnRhZ3MgaW4gdGhlIHJlZ2lzdHJ5LCB3 aGljaCB3ZXJlIHNwZWNpZmllZCBieSB0aGlzIGRvY3VtZW50LCBhcmUgdGhvc2UgcmVjb3JkcyBp biB0aGUgSUFOQSByZWdpc3RyeSBbSUFOQS1yZWdpc3RyeV0gd2l0aCAiQWRkZWQiIGZpZWxkLXZh bHVlcyBiZWZvcmUgMjAwNS0wNy0xMS4gIE5vdGUgdGhhdCBbbHRydS1yZWdpc3RyeSwgU2VjdGlv biAzLjFdIHJlcXVpcmVzIHRoYXQgYW4gIkFkZGVkIiBmaWVsZCBhcHBlYXIgaW4gZWFjaCByZWdp c3RyYXRpb24gcmVjb3JkIGFuZCB0aGF0IFNlY3Rpb24gMy4zKDEpIHNwZWNpZmllcyB0aGF0IGZp ZWxkIG11c3Qgbm90IGJlIGNoYW5nZWQgYWZ0ZXIgcmVnaXN0cmF0aW9uLiAoT3RoZXIgZmllbGRz IGluIHRoZXNlIHJlY29yZHMgbWF5IGhhdmUgYmVlbiBtb2RpZmllZCBhdCBhIGxhdGVyIGRhdGUs IHN1YmplY3QgdG8gdGhlIHJlc3RyaWN0aW9ucyBpbiBTZWN0aW9uIDMuNCBvZiBbbHRydS1yZWdp c3RyeV0uKQ0KLS0NCg0KTkI+IHRoZSBkYXRlIDIwMDUtMDctMTEgaXMgIkRhdGUgQiArIDEiDQoN CkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3Qs IFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29y a2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQg aXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZg0KPiBEb3VnIEV3ZWxsDQo+IFNlbnQ6IHNhbWVkaSAyNCBzZXB0ZW1icmUg MjAwNSAxNjoyMw0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IENjOiBKb2huIEMgS2xlbnNp bg0KPiBTdWJqZWN0OiBbTHRydV0gUmU6IE5vdGUgdG8gUkZDIGVkaXRvciBpbiBpbml0aWFsIHJl Z2lzdHJ5DQo+IA0KPiBSYW5keSBQcmVzdWhuIDxyYW5keSB1bmRlcnNjb3JlIHByZXN1aG4gYXQg bWluZHNwcmluZyBkb3QgY29tPiB3cm90ZToNCj4gDQo+ID4gQnkgdGhlIHdheSwgSm9obiBLbGVu c2luIHByb3Bvc2VkIHRoYXQgdGhlIG5vdGUgYmUgc29tZXRoaW5nIGxpa2UNCj4gPg0KPiA+ICIz LiAgVGhlIGluaXRpYWwgY29udGVudHMgb2YgdGhlIHJlZ2lzdHJ5IGFzIHNwZWNpZmllZA0KPiA+ IGluIHRoaXMgZG9jdW1lbnQgYXJlIHRob3NlIGVudHJpZXMgaW4gdGhlIElBTkEgcmVnaXN0cnkN Cj4gPiBbSUFOQS1yZWdpc3RyeV0gd2l0aCBhIGZpZWxkLW5hbWUgb2YgIkFkZGVkIiBhbmQgYSB2 YWx1ZQ0KPiA+IG9mICIyMDA1LTA3LTEwIi4gIE5vdGUgdGhhdCBbbHRydS1yZWdpc3RyeSwgU2Vj dGlvbiAzLjFdDQo+ID4gcmVxdWlyZXMgdGhhdCBhbiAiQWRkZWQiIGZpZWxkIGFwcGVhciBpbiBl YWNoDQo+ID4gcmVnaXN0cmF0aW9uIHJlY29yZCBhbmQgdGhhdCBpdHMgU2VjdGlvbiAzLjMoMSkN Cj4gPiBzcGVjaWZpZXMgdGhhdCBmaWVsZCBtdXN0IG5vdCBiZSBjaGFuZ2VkIGFmdGVyDQo+ID4g cmVnaXN0cmF0aW9uLiINCj4gDQo+IE15IGNvbmNlcm4gd2l0aCB0aGlzIGlzIHRoYXQgaXQgZ29l cyBiZXlvbmQgdGhlIG9yaWdpbmFsIGludGVudCBvZg0KPiByZXN0cmljdGluZyB0aGUgZGVsaXZl cnkgb2YgdGhlIGluaXRpYWwgcmVnaXN0cnkgY29udGVudHMgdG8gdGhlIFJGQw0KPiBFZGl0b3Is IGFuZCByZWR1Y2luZyB0aGUgc2l6ZSBvZiBkcmFmdC1pbml0aWFsLiAgSXQgYXR0ZW1wdHMgdG8g ZXhwbGFpbg0KPiB0byB0aGUgcmVhZGVyIGhvdyBzaGUgbWF5IHJlY29uc3RydWN0IHRoZSBpbml0 aWFsIHJlZ2lzdHJ5IG9uIGhlciBvd24uDQo+IE5vdCBvbmx5IGRvIEkgdGhpbmsgdGhpcyBpcyBh IG5vbi1nb2FsLCBJIGNhbiB0aGluayBvZiB0d28gcmVhc29ucyB3aHkNCj4gaXQgZG9lc24ndCB3 b3JrOg0KPiANCj4gKDEpICBUaGUgcmVkdW5kYW50IGFuZCBncmFuZGZhdGhlcmVkIHRhZ3MgZG9u J3QgaGF2ZSBhbiAiQWRkZWQiIGRhdGUgb2YNCj4gMjAwNS0wNy0xMCAob3Igd2hhdGV2ZXIgdGhl IGFjdHVhbCBwdWIgZGF0ZSBpcykuICBJbnN0ZWFkLCB0aGVpciAiQWRkZWQiDQo+IGRhdGUgaXMg dGhlIHNhbWUgYXMgdGhlIGRhdGUgdGhlIHJlY29yZCB3YXMgYWRkZWQgdG8gdGhlIFJGQyAzMDY2 DQo+IHdob2xlLXRhZyByZWdpc3RyeS4gIEZvciBleGFtcGxlLCB0aGUgIkFkZGVkIiBkYXRlIGZv ciBpLWFtaSBpcw0KPiAxOTk5LTA1LTI1LiAgVGhpcyBjb3VsZCBiZSBlYXNpbHkgZml4ZWQgYnkg Y2hhbmdpbmcgSm9obidzIHRleHQgdG8gcmVhZA0KPiAiLi4uIGFuZCBhIHZhbHVlIG5vIGxhdGVy IHRoYW4gJzIwMDUtMDctMTAnLCIgYmVpbmcgY2FyZWZ1bCB0byB1c2UgdGhlDQo+IHJlYWwgY3V0 b2ZmIGRhdGUuDQo+IA0KPiAoMikgIE1vcmUgcHJvYmxlbWF0aWMsIGZvciBwdXJwb3NlcyBvZiBy ZWNvbnN0cnVjdGluZyB0aGUgaW5pdGlhbA0KPiByZWdpc3RyeSwgaXMgdGhlIGZhY3QgdGhhdCB0 aGUgIkFkZGVkIiBkYXRlIGlzIG5vdCBjaGFuZ2VkIHdoZW4gYSBjaGFuZ2UNCj4gaXMgbWFkZSB0 byB0aGUgcmVjb3JkLCBzdWNoIGFzIGFkZGluZyBhICJTdXBwcmVzcy1TY3JpcHQiIGZpZWxkIHdo ZXJlDQo+IG5vbmUgcHJldmlvdXNseSBleGlzdGVkLiAgVGhpcyBpcyBub3QgYW4gImFtYmlndWl0 eSwiIGFzIElyYSBzdGF0ZWQsIGJ1dA0KPiBpdCBkb2VzIG1lYW4gdGhhdCBhIHJlY29yZCB3aXRo IGRhdGUgWCBtaWdodCBoYXZlIGJlZW4gbW9kaWZpZWQgc29tZQ0KPiB0aW1lIGFmdGVyIFguICBJ biBvcmRlciB0byBhbGxvdyByZWNvbnN0cnVjdGlvbiBvZiBhIHByZXZpb3VzIHZlcnNpb24sDQo+ IHRoZXJlIHdvdWxkIGhhdmUgdG8gYmUgYSAiTGFzdC1Nb2RpZmllZCIgZmllbGQsIGFuZCBubywg SSBhbSBub3QNCj4gYWR2b2NhdGluZyBhZGRpbmcgc3VjaCBhIGZpZWxkIGF0IHRoaXMgbGF0ZSBk YXRlLg0KPiANCj4gSSB0aGluayB3ZSBuZWVkIHRvIGRlY2lkZSB3aGV0aGVyIHdlIHdhbnQgZHJh ZnQtaW5pdGlhbCB0byBiZSBzaW1wbHkgYQ0KPiBtZWFucyBvZiBjb21tdW5pY2F0aW5nIHRoZSBp bml0aWFsIHJlZ2lzdHJ5IGNvbnRlbnRzIHRvIElBTkEsIG9yIGFsc28NCj4gYWxsb3cgdXNlcnMg YXQgc29tZSBhcmJpdHJhcnkgZnV0dXJlIGRhdGUgdG8gcmVjb25zdHJ1Y3QgdGhlIGluaXRpYWwN Cj4gcmVnaXN0cnkgc29tZWhvdy4gIElmIHdlIHdhbnQgdG8gc3RpY2sgdG8gdGhlIG9yaWdpbmFs IGludGVudCwgdGhlbiB3ZQ0KPiBzaG91bGQgc2ltcGx5IHN0YXRlIHRoYXQgdGhlIGFjdHVhbCBp bml0aWFsIGNvbnRlbnRzIHdlcmUgc3RyaXBwZWQgYnkNCj4gdGhlIFJGQyBFZGl0b3IgdG8gcmVk dWNlIHNpemUsIHByZXZlbnQgbWlzdXNlLCBldGMuIGFuZCBsZWF2ZSBpdCBhdA0KPiB0aGF0Lg0K PiANCj4gLS0NCj4gRG91ZyBFd2VsbA0KPiBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gaHR0cDov L3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0K PiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2x0cnUNCg== --===============1510463193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1510463193==-- From ltru-bounces@ietf.org Sat Sep 24 21:45:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLZr-00042t-Go; Sat, 24 Sep 2005 21:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLZo-00042l-Nj for ltru@megatron.ietf.org; Sat, 24 Sep 2005 21:45:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02809 for ; Sat, 24 Sep 2005 21:45:10 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJLgX-0004Ck-8S for ltru@ietf.org; Sat, 24 Sep 2005 21:52:11 -0400 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050925014454.VTCZ24716.mta9.adelphia.net@DEWELL>; Sat, 24 Sep 2005 21:44:54 -0400 Message-ID: <003501c5c172$8f0c2ee0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 18:43:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: John C Klensin X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > In any case, you don't need to adopt John Klensin's exact words. It > seems to me that he was unaware of some of the details of registration > and proposed text that seemed fitting. I would suggest that you just > modify the proposed wording and we move along. How about: > > -- > 3. The initial set of subtags in the registry, which were specified > by this document, are those records in the IANA registry [IANA- > registry] with "Added" field-values before 2005-07-11. Note that > [ltru-registry, Section 3.1] requires that an "Added" field appear in > each registration record and that Section 3.3(1) specifies that field > must not be changed after registration. (Other fields in these records > may have been modified at a later date, subject to the restrictions in > Section 3.4 of [ltru-registry].) > -- > > NB> the date 2005-07-11 is "Date B + 1" That's OK with me, except I'm still worried about explicitly specifying the date. That gives us (or the RFC Editor) one more opportunity to forget to update "all" the dates. How about: ... with "Added" field values no later than the date of publication of this document. This assumes that the File-Date and Added dates for subtags (not grandfathered or redundant tags) in the initial registry, the date of publication of draft-initial, and the date of publication of draft-registry are all the same. I think we have been making that assumption all along, and need to be able to rely on it. I would also remove the parentheses from the last sentence, to avoid de-emphasizing it -- because I think it is important -- and append something like: Because of this, it may not be possible to use a future version of the Language Subtag Registry to reconstruct an exact copy of the initial registry contents. Comments? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 24 21:55:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLk9-0005ZB-Qn; Sat, 24 Sep 2005 21:55:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLk9-0005Z1-13 for ltru@megatron.ietf.org; Sat, 24 Sep 2005 21:55:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03019 for ; Sat, 24 Sep 2005 21:55:50 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJLqq-0004M9-Qq for ltru@ietf.org; Sat, 24 Sep 2005 22:02:52 -0400 Received: from alvmbxw02.prod.quest.corp ([10.1.0.209]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 18:55:34 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by alvmbxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 18:55:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 18:55:21 -0700 Message-ID: Thread-Topic: [Ltru] Re: Note to RFC editor in initial registry thread-index: AcXBcr2nyJEhxJ8YSjmK2f4OxFb/VgAAWmbQ From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 25 Sep 2005 01:55:34.0195 (UTC) FILETIME=[3787F030:01C5C174] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: John C Klensin X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1928556644==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1928556644== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U291bmRzIGZpbmUgdG8gbWUuIA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkds b2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5h dGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRG91ZyBFd2VsbCBbbWFpbHRvOmRld2VsbEBhZGVs cGhpYS5uZXRdDQo+IFNlbnQ6IHNhbWVkaSAyNCBzZXB0ZW1icmUgMjAwNSAxODo0NA0KPiBUbzog TFRSVSBXb3JraW5nIEdyb3VwDQo+IENjOiBBZGRpc29uIFBoaWxsaXBzOyBKb2huIEMgS2xlbnNp bg0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBOb3RlIHRvIFJGQyBlZGl0b3IgaW4gaW5pdGlh bCByZWdpc3RyeQ0KPiANCj4gQWRkaXNvbiBQaGlsbGlwcyA8YWRkaXNvbiBkb3QgcGhpbGxpcHMg YXQgcXVlc3QgZG90IGNvbT4gd3JvdGU6DQo+IA0KPiA+IEluIGFueSBjYXNlLCB5b3UgZG9uJ3Qg bmVlZCB0byBhZG9wdCBKb2huIEtsZW5zaW4ncyBleGFjdCB3b3Jkcy4gSXQNCj4gPiBzZWVtcyB0 byBtZSB0aGF0IGhlIHdhcyB1bmF3YXJlIG9mIHNvbWUgb2YgdGhlIGRldGFpbHMgb2YgcmVnaXN0 cmF0aW9uDQo+ID4gYW5kIHByb3Bvc2VkIHRleHQgdGhhdCBzZWVtZWQgZml0dGluZy4gSSB3b3Vs ZCBzdWdnZXN0IHRoYXQgeW91IGp1c3QNCj4gPiBtb2RpZnkgdGhlIHByb3Bvc2VkIHdvcmRpbmcg YW5kIHdlIG1vdmUgYWxvbmcuIEhvdyBhYm91dDoNCj4gPg0KPiA+IC0tDQo+ID4gMy4gIFRoZSBp bml0aWFsIHNldCBvZiBzdWJ0YWdzIGluIHRoZSByZWdpc3RyeSwgd2hpY2ggd2VyZSBzcGVjaWZp ZWQNCj4gPiBieSB0aGlzIGRvY3VtZW50LCBhcmUgdGhvc2UgcmVjb3JkcyBpbiB0aGUgSUFOQSBy ZWdpc3RyeSBbSUFOQS0NCj4gPiByZWdpc3RyeV0gd2l0aCAiQWRkZWQiIGZpZWxkLXZhbHVlcyBi ZWZvcmUgMjAwNS0wNy0xMS4gIE5vdGUgdGhhdA0KPiA+IFtsdHJ1LXJlZ2lzdHJ5LCBTZWN0aW9u IDMuMV0gcmVxdWlyZXMgdGhhdCBhbiAiQWRkZWQiIGZpZWxkIGFwcGVhciBpbg0KPiA+IGVhY2gg cmVnaXN0cmF0aW9uIHJlY29yZCBhbmQgdGhhdCBTZWN0aW9uIDMuMygxKSBzcGVjaWZpZXMgdGhh dCBmaWVsZA0KPiA+IG11c3Qgbm90IGJlIGNoYW5nZWQgYWZ0ZXIgcmVnaXN0cmF0aW9uLiAoT3Ro ZXIgZmllbGRzIGluIHRoZXNlIHJlY29yZHMNCj4gPiBtYXkgaGF2ZSBiZWVuIG1vZGlmaWVkIGF0 IGEgbGF0ZXIgZGF0ZSwgc3ViamVjdCB0byB0aGUgcmVzdHJpY3Rpb25zIGluDQo+ID4gU2VjdGlv biAzLjQgb2YgW2x0cnUtcmVnaXN0cnldLikNCj4gPiAtLQ0KPiA+DQo+ID4gTkI+IHRoZSBkYXRl IDIwMDUtMDctMTEgaXMgIkRhdGUgQiArIDEiDQo+IA0KPiBUaGF0J3MgT0sgd2l0aCBtZSwgZXhj ZXB0IEknbSBzdGlsbCB3b3JyaWVkIGFib3V0IGV4cGxpY2l0bHkgc3BlY2lmeWluZw0KPiB0aGUg ZGF0ZS4gIFRoYXQgZ2l2ZXMgdXMgKG9yIHRoZSBSRkMgRWRpdG9yKSBvbmUgbW9yZSBvcHBvcnR1 bml0eSB0bw0KPiBmb3JnZXQgdG8gdXBkYXRlICJhbGwiIHRoZSBkYXRlcy4gIEhvdyBhYm91dDoN Cj4gDQo+ICAgICAuLi4gd2l0aCAiQWRkZWQiIGZpZWxkIHZhbHVlcyBubyBsYXRlciB0aGFuIHRo ZSBkYXRlIG9mIHB1YmxpY2F0aW9uDQo+ICAgICBvZiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gVGhp cyBhc3N1bWVzIHRoYXQgdGhlIEZpbGUtRGF0ZSBhbmQgQWRkZWQgZGF0ZXMgZm9yIHN1YnRhZ3Mg KG5vdA0KPiBncmFuZGZhdGhlcmVkIG9yIHJlZHVuZGFudCB0YWdzKSBpbiB0aGUgaW5pdGlhbCBy ZWdpc3RyeSwgdGhlIGRhdGUgb2YNCj4gcHVibGljYXRpb24gb2YgZHJhZnQtaW5pdGlhbCwgYW5k IHRoZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mDQo+IGRyYWZ0LXJlZ2lzdHJ5IGFyZSBhbGwgdGhl IHNhbWUuICBJIHRoaW5rIHdlIGhhdmUgYmVlbiBtYWtpbmcgdGhhdA0KPiBhc3N1bXB0aW9uIGFs bCBhbG9uZywgYW5kIG5lZWQgdG8gYmUgYWJsZSB0byByZWx5IG9uIGl0Lg0KPiANCj4gSSB3b3Vs ZCBhbHNvIHJlbW92ZSB0aGUgcGFyZW50aGVzZXMgZnJvbSB0aGUgbGFzdCBzZW50ZW5jZSwgdG8g YXZvaWQNCj4gZGUtZW1waGFzaXppbmcgaXQgLS0gYmVjYXVzZSBJIHRoaW5rIGl0IGlzIGltcG9y dGFudCAtLSBhbmQgYXBwZW5kDQo+IHNvbWV0aGluZyBsaWtlOg0KPiANCj4gICAgIEJlY2F1c2Ug b2YgdGhpcywgaXQgbWF5IG5vdCBiZSBwb3NzaWJsZSB0byB1c2UgYSBmdXR1cmUgdmVyc2lvbiBv Zg0KPiAgICAgdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSB0byByZWNvbnN0cnVjdCBhbiBl eGFjdCBjb3B5IG9mIHRoZQ0KPiAgICAgaW5pdGlhbCByZWdpc3RyeSBjb250ZW50cy4NCj4gDQo+ IENvbW1lbnRzPw0KPiANCj4gLS0NCj4gRG91ZyBFd2VsbA0KPiBGdWxsZXJ0b24sIENhbGlmb3Ju aWENCj4gaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCg0K --===============1928556644== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1928556644==-- From ltru-bounces@ietf.org Sat Sep 24 21:56:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLkr-0005bk-4b; Sat, 24 Sep 2005 21:56:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLkp-0005bY-Ug for ltru@megatron.ietf.org; Sat, 24 Sep 2005 21:56:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03026 for ; Sat, 24 Sep 2005 21:56:32 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJLrZ-0004Mj-8G for ltru@ietf.org; Sat, 24 Sep 2005 22:03:34 -0400 Received: from h-68-166-189-49.snvacaid.dynamic.covad.net ([68.166.189.49] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EJLkm-0006WF-00 for ltru@ietf.org; Sat, 24 Sep 2005 21:56:33 -0400 Message-ID: <002001c5c174$beddc820$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 18:59:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor: > From: "Addison Phillips" > To: "Doug Ewell" ; "LTRU Working Group" > Cc: "John C Klensin" > Sent: Saturday, September 24, 2005 5:01 PM > Subject: RE: [Ltru] Re: Note to RFC editor in initial registry ... > 3. The initial set of subtags in the registry, which were specified > by this document, are those records in the IANA registry [IANA-registry] > with "Added" field-values before 2005-07-11. Note that [ltru-registry, > Section 3.1] requires that an "Added" field appear in each registration > record and that Section 3.3(1) specifies that field must not be > changed after registration. (Other fields in these records may have > been modified at a later date, subject to the restrictions > in Section 3.4 of [ltru-registry].) > -- > > NB> the date 2005-07-11 is "Date B + 1" ... Just a little word-smithing, and a comment: -------------- 3. The remainder of this section specified the initial set of subtags for the registry. This material was deleted on publication of this memo, to avoid any confusion with the registry itself [I-D.ietf-ltru-registry]. Each of these initial entries has an "Added" field value prior to YYYY-MM-DD. Note that [I-D.ietf-ltru-registry] Section 3.3(1) specifies that this field must not change after registration. Other fields in these records may subsequently be modified, subject to the restrictions in Section 3.4 of [I-D.ietf-ltru-registry]. RFC EDITOR NOTE: the remainder of this section is to be deleted upon publication. ---------------- I think that all is really needed is the first paragraph and the note. I'll go along with the second paragraph if folks think it's really useful and necessary, but I'd be happier without it. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 24 22:00:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLoR-0006NQ-Nt; Sat, 24 Sep 2005 22:00:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLoQ-0006NL-3D for ltru@megatron.ietf.org; Sat, 24 Sep 2005 22:00:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03268 for ; Sat, 24 Sep 2005 22:00:15 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJLvA-0004To-Sf for ltru@ietf.org; Sat, 24 Sep 2005 22:07:17 -0400 Received: from h-68-166-189-49.snvacaid.dynamic.covad.net ([68.166.189.49] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EJLoO-0007AZ-00 for ltru@ietf.org; Sat, 24 Sep 2005 22:00:17 -0400 Message-ID: <002501c5c175$466fe5c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <003501c5c172$8f0c2ee0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 19:03:08 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Doug Ewell" > To: "LTRU Working Group" > Cc: "John C Klensin" > Sent: Saturday, September 24, 2005 6:43 PM > Subject: Re: [Ltru] Re: Note to RFC editor in initial registry ... > > NB> the date 2005-07-11 is "Date B + 1" > > That's OK with me, except I'm still worried about explicitly specifying > the date. That gives us (or the RFC Editor) one more opportunity to > forget to update "all" the dates. How about: > > ... with "Added" field values no later than the date of publication > of this document. I like this a lot. > This assumes that the File-Date and Added dates for subtags (not > grandfathered or redundant tags) in the initial registry, the date of > publication of draft-initial, and the date of publication of > draft-registry are all the same. I think we have been making that > assumption all along, and need to be able to rely on it. > > I would also remove the parentheses from the last sentence, to avoid > de-emphasizing it -- because I think it is important -- and append > something like: > > Because of this, it may not be possible to use a future version of > the Language Subtag Registry to reconstruct an exact copy of the > initial registry contents. > > Comments? ... If folks think we need any text on reconstruction, I think this addition would be an important one. (I'm still not convinced that we need to say *anything* about reconstruction, though I'm willing to go along with it.) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 24 22:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLp1-0006Of-VE; Sat, 24 Sep 2005 22:00:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLp0-0006OF-Ab for ltru@megatron.ietf.org; Sat, 24 Sep 2005 22:00:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03275 for ; Sat, 24 Sep 2005 22:00:51 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJLvl-0004U1-9Q for ltru@ietf.org; Sat, 24 Sep 2005 22:07:53 -0400 Received: from irvmbxw02.prod.quest.corp ([10.1.2.203]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 19:00:44 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvmbxw02.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Sep 2005 19:00:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 19:00:31 -0700 Message-ID: Thread-Topic: [Ltru] Re: Note to RFC editor in initial registry thread-index: AcXBdHdJ8OF2A+ocTWSHo7E5jLNiFwAAF52g From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 25 Sep 2005 02:00:44.0589 (UTC) FILETIME=[F08A4DD0:01C5C174] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org That would work even better. And I too would be happy with just the one = paragraph. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Randy Presuhn > Sent: samedi 24 septembre 2005 18:59 > To: LTRU Working Group > Subject: Re: [Ltru] Re: Note to RFC editor in initial registry >=20 > Hi - >=20 > As a technical contributor: >=20 > > From: "Addison Phillips" > > To: "Doug Ewell" ; "LTRU Working Group" > > > Cc: "John C Klensin" > > Sent: Saturday, September 24, 2005 5:01 PM > > Subject: RE: [Ltru] Re: Note to RFC editor in initial registry > ... > > 3. The initial set of subtags in the registry, which were specified > > by this document, are those records in the IANA registry = [IANA-registry] > > with "Added" field-values before 2005-07-11. Note that = [ltru-registry, > > Section 3.1] requires that an "Added" field appear in each = registration > > record and that Section 3.3(1) specifies that field must not be > > changed after registration. (Other fields in these records may have > > been modified at a later date, subject to the restrictions > > in Section 3.4 of [ltru-registry].) > > -- > > > > NB> the date 2005-07-11 is "Date B + 1" > ... >=20 > Just a little word-smithing, and a comment: >=20 > -------------- > 3. The remainder of this section specified the initial set of subtags > for the registry. This material was deleted on publication of this > memo, to avoid any confusion with the registry itself [I-D.ietf-ltru- > registry]. >=20 > Each of these initial entries has an "Added" field value prior > to YYYY-MM-DD. Note that [I-D.ietf-ltru-registry] Section 3.3(1) > specifies that this field must not change after registration. > Other fields in these records may subsequently be modified, > subject to the restrictions in Section 3.4 of = [I-D.ietf-ltru-registry]. >=20 > RFC EDITOR NOTE: the remainder of this section is to be deleted upon > publication. > ---------------- >=20 > I think that all is really needed is the first paragraph and the note. > I'll go along with the second paragraph if folks think it's really = useful > and necessary, but I'd be happier without it. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 24 22:08:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLwW-0007hV-Cw; Sat, 24 Sep 2005 22:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJLwV-0007gW-HH for ltru@megatron.ietf.org; Sat, 24 Sep 2005 22:08:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03599 for ; Sat, 24 Sep 2005 22:08:37 -0400 (EDT) Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJM3F-0004cd-FU for ltru@ietf.org; Sat, 24 Sep 2005 22:15:38 -0400 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050925020828.HAOL10221.mta13.adelphia.net@DEWELL> for ; Sat, 24 Sep 2005 22:08:28 -0400 Message-ID: <005e01c5c175$c796a440$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Subject: Re: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 19:06:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org To summarize, I propose to amend draft-initial-04 by adding the following text to the beginning of Section 3: [NOTE TO RFC EDITOR: Please remove this note and the rest of this section, replacing it with the following comment: The initial set of subtags in the registry, which were specified by this document, are those records in the IANA registry [IANA-registry] with "Added" field-values no later than the date of publication of this document. Note that Section 3.1 of [ltru-registry] requires that an "Added" field appear in each registration record and that Section 3.3(1) specifies that field must not be changed after registration. Other fields in these records may have been modified at a later date, subject to the restrictions in Section 3.4 of [ltru-registry]. Because of this, it may not be possible to use a future version of the Language Subtag Registry to reconstruct an exact copy of the initial registry contents.] I would need to know what to put within the square brackets for [IANA-registry]. Presumably this would be a normative reference to whatever URI is chosen for the Language Subtag Registry. I would have to get this information in time for AUTH48, or the RFC Editor would have to plug in the correct value at the time of text substitution. The only other amendment to draft-initial-04 would be the addition of the following record to the initial registry contents: Type: language Subtag: rup Description: Aromanian Description: Arumanian Description: Macedo-Romanian Added: 2005-09-20 Note that 'ain' for Ainu is already in draft-initial-04, but not in previous versions. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 24 22:27:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJMEj-0002J7-Os; Sat, 24 Sep 2005 22:27:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJMEh-0002J2-P1 for ltru@megatron.ietf.org; Sat, 24 Sep 2005 22:27:27 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04065 for ; Sat, 24 Sep 2005 22:27:24 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050925022656.LPSJ27017.mta11.adelphia.net@DEWELL> for ; Sat, 24 Sep 2005 22:26:56 -0400 Message-ID: <006101c5c178$904c8f60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050922160912.KKYO5972.edge6.adelphia.net@megatron.ietf.org> Date: Sat, 24 Sep 2005 19:26:39 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: record jar reference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > And I somehow expect that the UN pages will delete 830 and/or > 3166-1 will list GG+JE+IM precisely five minutes before the > end of your "AUTH48". Don't think I haven't thought about that. ISO 639 has already added two language code elements since July. I had hoped things would quiet down in the source standards while we were finishing this off, but noooo. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Sep 24 22:41:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJMSW-00049t-14; Sat, 24 Sep 2005 22:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJMSU-00049o-QQ for ltru@megatron.ietf.org; Sat, 24 Sep 2005 22:41:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04439 for ; Sat, 24 Sep 2005 22:41:36 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJMZ9-0005B8-WE for ltru@ietf.org; Sat, 24 Sep 2005 22:48:38 -0400 Received: from IRVPFXW01.prod.quest.corp ([10.1.2.202]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 19:41:22 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by IRVPFXW01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Sep 2005 19:41:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 19:41:09 -0700 Message-ID: Thread-Topic: [Ltru] Re: Note to RFC editor in initial registry thread-index: AcXBdiIUtEUAiLc2T5ykt+EorETsGQAA7INA From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 25 Sep 2005 02:41:22.0564 (UTC) FILETIME=[9DAFC440:01C5C17A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1273848903==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1273848903== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QXZvaWQgdGhlIHByb2JsZW0uIFVzZSB0aGlzIGluc3RlYWQgb2YgdGhlIGZpcnN0IHNlbnRlbmNl Og0KDQotLQ0KVGhlIGluaXRpYWwgc2V0IG9mIHJlY29yZHMgaW4gdGhlIExhbmd1YWdlIFN1YnRh ZyBSZWdpc3RyeSBkZWZpbmVkIGJ5IFtsdHJ1LXJlZ2lzdHJ5XSB3ZXJlIG9yaWdpbmFsbHkgZGVm aW5lZCBpbiB0aGlzIHNlY3Rpb24uIFRoaXMgc2V0IGNvbnNpc3RzIG9mIHRob3NlIHJlY29yZHMg d2l0aCAiQWRkZWQiIGZpZWxkLXZhbHVlcyBubyBsYXRlciB0aGFuIHRoZSBkYXRlIG9mIHB1Ymxp Y2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQotLQ0KDQpOb3RlIHRoZSB1c2Ugb2YgInJlY29yZHMi IGluc3RlYWQgb2YgInN1YnRhZ3MiOiBpdCdzIGltcG9ydGFudCwgSSB0aGluay4NCg0KQWRkaXNv bg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3Qg U29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdy b3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBh cmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0 cnUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQo+IERvdWcgRXdlbGwNCj4gU2VudDogc2FtZWRpIDI0IHNlcHRlbWJyZSAyMDA1IDE5 OjA3DQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBSZTog Tm90ZSB0byBSRkMgZWRpdG9yIGluIGluaXRpYWwgcmVnaXN0cnkNCj4gDQo+IFRvIHN1bW1hcml6 ZSwgSSBwcm9wb3NlIHRvIGFtZW5kIGRyYWZ0LWluaXRpYWwtMDQgYnkgYWRkaW5nIHRoZQ0KPiBm b2xsb3dpbmcgdGV4dCB0byB0aGUgYmVnaW5uaW5nIG9mIFNlY3Rpb24gMzoNCj4gDQo+IFtOT1RF IFRPIFJGQyBFRElUT1I6IFBsZWFzZSByZW1vdmUgdGhpcyBub3RlIGFuZCB0aGUgcmVzdCBvZiB0 aGlzDQo+IHNlY3Rpb24sIHJlcGxhY2luZyBpdCB3aXRoIHRoZSBmb2xsb3dpbmcgY29tbWVudDoN Cj4gDQo+IFRoZSBpbml0aWFsIHNldCBvZiBzdWJ0YWdzIGluIHRoZSByZWdpc3RyeSwgd2hpY2gg d2VyZSBzcGVjaWZpZWQgYnkgdGhpcw0KPiBkb2N1bWVudCwgYXJlIHRob3NlIHJlY29yZHMgaW4g dGhlIElBTkEgcmVnaXN0cnkgW0lBTkEtcmVnaXN0cnldIHdpdGgNCj4gIkFkZGVkIiBmaWVsZC12 YWx1ZXMgbm8gbGF0ZXIgdGhhbiB0aGUgZGF0ZSBvZiBwdWJsaWNhdGlvbiBvZiB0aGlzDQo+IGRv Y3VtZW50LiAgTm90ZSB0aGF0IFNlY3Rpb24gMy4xIG9mIFtsdHJ1LXJlZ2lzdHJ5XSByZXF1aXJl cyB0aGF0IGFuDQo+ICJBZGRlZCIgZmllbGQgYXBwZWFyIGluIGVhY2ggcmVnaXN0cmF0aW9uIHJl Y29yZCBhbmQgdGhhdCBTZWN0aW9uIDMuMygxKQ0KPiBzcGVjaWZpZXMgdGhhdCBmaWVsZCBtdXN0 IG5vdCBiZSBjaGFuZ2VkIGFmdGVyIHJlZ2lzdHJhdGlvbi4gT3RoZXINCj4gZmllbGRzIGluIHRo ZXNlIHJlY29yZHMgbWF5IGhhdmUgYmVlbiBtb2RpZmllZCBhdCBhIGxhdGVyIGRhdGUsIHN1Ympl Y3QNCj4gdG8gdGhlIHJlc3RyaWN0aW9ucyBpbiBTZWN0aW9uIDMuNCBvZiBbbHRydS1yZWdpc3Ry eV0uICBCZWNhdXNlIG9mIHRoaXMsDQo+IGl0IG1heSBub3QgYmUgcG9zc2libGUgdG8gdXNlIGEg ZnV0dXJlIHZlcnNpb24gb2YgdGhlIExhbmd1YWdlIFN1YnRhZw0KPiBSZWdpc3RyeSB0byByZWNv bnN0cnVjdCBhbiBleGFjdCBjb3B5IG9mIHRoZSBpbml0aWFsIHJlZ2lzdHJ5IGNvbnRlbnRzLl0N Cj4gDQo+IEkgd291bGQgbmVlZCB0byBrbm93IHdoYXQgdG8gcHV0IHdpdGhpbiB0aGUgc3F1YXJl IGJyYWNrZXRzIGZvcg0KPiBbSUFOQS1yZWdpc3RyeV0uICBQcmVzdW1hYmx5IHRoaXMgd291bGQg YmUgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvDQo+IHdoYXRldmVyIFVSSSBpcyBjaG9zZW4gZm9y IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkuICBJIHdvdWxkIGhhdmUNCj4gdG8gZ2V0IHRo aXMgaW5mb3JtYXRpb24gaW4gdGltZSBmb3IgQVVUSDQ4LCBvciB0aGUgUkZDIEVkaXRvciB3b3Vs ZCBoYXZlDQo+IHRvIHBsdWcgaW4gdGhlIGNvcnJlY3QgdmFsdWUgYXQgdGhlIHRpbWUgb2YgdGV4 dCBzdWJzdGl0dXRpb24uDQo+IA0KPiBUaGUgb25seSBvdGhlciBhbWVuZG1lbnQgdG8gZHJhZnQt aW5pdGlhbC0wNCB3b3VsZCBiZSB0aGUgYWRkaXRpb24gb2YNCj4gdGhlIGZvbGxvd2luZyByZWNv cmQgdG8gdGhlIGluaXRpYWwgcmVnaXN0cnkgY29udGVudHM6DQo+IA0KPiBUeXBlOiBsYW5ndWFn ZQ0KPiBTdWJ0YWc6IHJ1cA0KPiBEZXNjcmlwdGlvbjogQXJvbWFuaWFuDQo+IERlc2NyaXB0aW9u OiBBcnVtYW5pYW4NCj4gRGVzY3JpcHRpb246IE1hY2Vkby1Sb21hbmlhbg0KPiBBZGRlZDogMjAw NS0wOS0yMA0KPiANCj4gTm90ZSB0aGF0ICdhaW4nIGZvciBBaW51IGlzIGFscmVhZHkgaW4gZHJh ZnQtaW5pdGlhbC0wNCwgYnV0IG5vdCBpbg0KPiBwcmV2aW91cyB2ZXJzaW9ucy4NCj4gDQo+IC0t DQo+IERvdWcgRXdlbGwNCj4gRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+IGh0dHA6Ly91c2Vycy5h ZGVscGhpYS5uZXQvfmRld2VsbC8NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============1273848903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1273848903==-- From ltru-bounces@ietf.org Sat Sep 24 22:58:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJMiJ-0006ns-J7; Sat, 24 Sep 2005 22:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJMiI-0006mF-T0 for ltru@megatron.ietf.org; Sat, 24 Sep 2005 22:58:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04967 for ; Sat, 24 Sep 2005 22:57:59 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJMp2-0005UE-Sg for ltru@ietf.org; Sat, 24 Sep 2005 23:05:02 -0400 Received: from h-68-166-189-49.snvacaid.dynamic.covad.net ([68.166.189.49] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EJMiB-0006XF-00 for ltru@ietf.org; Sat, 24 Sep 2005 22:57:56 -0400 Message-ID: <001c01c5c17d$530a8bc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 20:00:45 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Addison Phillips" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Saturday, September 24, 2005 7:41 PM > Subject: RE: [Ltru] Re: Note to RFC editor in initial registry > > Avoid the problem. Use this instead of the first sentence: > > -- > The initial set of records in the Language Subtag Registry defined > by [ltru-registry] were originally defined in this section. This s/were/was/ (verb/subject agreement) > set consists of those records with "Added" field-values no later > than the date of publication of this document. > -- ... I like this proposal. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 25 00:15:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJNvK-0001K3-GQ; Sun, 25 Sep 2005 00:15:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJNvI-0001JS-GT for ltru@megatron.ietf.org; Sun, 25 Sep 2005 00:15:32 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07455 for ; Sun, 25 Sep 2005 00:15:28 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050925041500.KFKU10221.mta13.adelphia.net@DEWELL> for ; Sun, 25 Sep 2005 00:15:00 -0400 Message-ID: <008301c5c187$8551bf40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050925020209.DDHS23403.edge4.adelphia.net@megatron.ietf.org> Date: Sat, 24 Sep 2005 21:13:43 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Note to RFC editor in initial registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a unified response to several messages, so don't anyone jump to any conclusions until you've read the whole thing. Randy Presuhn wrote: > 3. The remainder of this section specified the initial set of subtags > for the registry. This material was deleted on publication of this > memo, to avoid any confusion with the registry itself > [I-D.ietf-ltru-registry]. What is the role of the reference [I-D.ietf-ltru-registry] here? In this context it looks like a pointer to the registry, which is not true. Draft-initial is already chock-full of references to draft-registry without adding another non-essential one. I suggest deleting the reference, and also adding the word "potential" before "confusion," though I'm not dogmatic about the latter. > Each of these initial entries has an "Added" field value prior > to YYYY-MM-DD. Note that [I-D.ietf-ltru-registry] Section 3.3(1) > specifies that this field must not change after registration. > Other fields in these records may subsequently be modified, > subject to the restrictions in Section 3.4 of > [I-D.ietf-ltru-registry]. I still would like to avoid specifying the literal date. If we do, we'll have to be really, really sure we don't miss updating this in the closing moments. > RFC EDITOR NOTE: the remainder of this section is to be deleted upon > publication. Good so far. (Lest anyone forget, this is whole purpose of this exercise.) > I think that all is really needed is the first paragraph and the note. > I'll go along with the second paragraph if folks think it's really > useful and necessary, but I'd be happier without it. I'm fine with removing it, because I don't think there should be any need to re-create the initial registry. The current one is what's interesting. Later: >> ... How about: >> >> ... with "Added" field values no later than the date of >> publication of this document. > > I like this a lot. Good, if we have to have this paragraph at all. >> Because of this, it may not be possible to use a future version >> of the Language Subtag Registry to reconstruct an exact copy of >> the initial registry contents. >> >> Comments? > ... > > If folks think we need any text on reconstruction, I think this > addition would be an important one. (I'm still not convinced that we > need to say *anything* about reconstruction, though I'm willing to go > along with it.) Agreed. Addison Phillips wrote: > That would work even better. And I too would be happy with just the > one paragraph. In a private message, it was also suggested to use "records" instead of "subtags," and I agree with this (some records are for tags, not subtags). OK, so here's what we have now: 3. The remainder of this section specified the initial set of records for the registry. This material was deleted on publication of this memo, to avoid any potential confusion with the registry itself. [RFC EDITOR NOTE: the remainder of this section is to be deleted upon publication.] Comments? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 25 00:28:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJO83-0003Dq-IQ; Sun, 25 Sep 2005 00:28:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJO81-0003Dl-Ha for ltru@megatron.ietf.org; Sun, 25 Sep 2005 00:28:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07869 for ; Sun, 25 Sep 2005 00:28:35 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJOEl-0007H3-Ab for ltru@ietf.org; Sun, 25 Sep 2005 00:35:39 -0400 Received: from alvmbxw02.prod.quest.corp ([10.1.0.209]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 21:28:24 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by alvmbxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 21:28:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 21:28:11 -0700 Message-ID: Thread-Topic: [Ltru] Re: Note to RFC editor in initial registry thread-index: AcXBh+rVFd9aqonGS+e7gr++ASFq4gAAItjw From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 25 Sep 2005 04:28:23.0471 (UTC) FILETIME=[90D86BF0:01C5C189] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1393105846==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1393105846== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UHV0IGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggKGFib3V0IHRoZSBtYXRlcmlhbCBoYXZpbmcgYmVl biBkZWxldGVkKS4gTGVhdmUgb3V0IHRoZSByZXN0LiBBcyBhbiBSRkMgdGhpcyBkb2N1bWVudCB3 aWxsIGJlIG9mIGludGVyZXN0IG9ubHkgdG8gZGlnaXRhbCBhcmNoYWVvbG9naXN0cywgdGhlIG1l YXQgb2YgdGhlIHJlZ2lzdHJ5IGhhdmluZyBsb25nIHNpbmNlIGJlZW4gcGlja2VkIGZyb20gaXRz IGJvbmVzLiBUaGUgbWF0ZXJpYWwgYmVpbmcgc3VnZ2VzdGVkIGRvZXNuJ3QgZG8gYW55dGhpbmcg dGhhdCBkcmFmdC1yZWdpc3RyeSBkb2Vzbid0IGRvIChleGNlcHQgc3BlY2lmeWluZyBob3cgdG8g aWRlbnRpZnkgdGhlIG9yaWdpbmFsIHNldCBvZiByZWNvcmRzKS4NCg0KQSBiZXR0ZXIgd2F5IHRv IGRvIHRoYXQgbWlnaHQgYmUgdG8gd3JpdGU6DQoNCi0tDQpUaGUgRmlsZS1EYXRlIHJlY29yZCBv ZiB0aGUgaW5pdGlhbCByZWdpc3RyeSB3YXMgdGhlIGRhdGUgb2YgcHVibGljYXRpb24gb2YgdGhp cyBkb2N1bWVudC4NCi0tDQoNClRoYXQgaXMgYWxsIG9mIHRoZSBpbmZvcm1hdGlvbiBvbmUgYWN0 dWFsbHkgbmVlZHMgdG8gY292ZXIgYWxsIHRoZSB0ZXh0IHN1Z2dlc3RlZCBwcmV2aW91c2x5IDot KQ0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0 ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3Jl IFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4N Ckl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YNCj4gRG91ZyBFd2VsbA0KPiBTZW50OiBzYW1lZGkgMjQgc2VwdGVt YnJlIDIwMDUgMjE6MTQNCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRy dV0gUmU6IE5vdGUgdG8gUkZDIGVkaXRvciBpbiBpbml0aWFsIHJlZ2lzdHJ5DQo+IA0KPiBUaGlz IGlzIGEgdW5pZmllZCByZXNwb25zZSB0byBzZXZlcmFsIG1lc3NhZ2VzLCBzbyBkb24ndCBhbnlv bmUganVtcCB0bw0KPiBhbnkgY29uY2x1c2lvbnMgdW50aWwgeW91J3ZlIHJlYWQgdGhlIHdob2xl IHRoaW5nLg0KPiANCj4gUmFuZHkgUHJlc3VobiA8cmFuZHkgdW5kZXJzY29yZSBwcmVzdWhuIGF0 IG1pbmRzcHJpbmcgZG90IGNvbT4gd3JvdGU6DQo+IA0KPiA+IDMuICBUaGUgcmVtYWluZGVyIG9m IHRoaXMgc2VjdGlvbiBzcGVjaWZpZWQgdGhlIGluaXRpYWwgc2V0IG9mIHN1YnRhZ3MNCj4gPiBm b3IgdGhlIHJlZ2lzdHJ5LiAgVGhpcyBtYXRlcmlhbCB3YXMgZGVsZXRlZCBvbiBwdWJsaWNhdGlv biBvZiB0aGlzDQo+ID4gbWVtbywgdG8gYXZvaWQgYW55IGNvbmZ1c2lvbiB3aXRoIHRoZSByZWdp c3RyeSBpdHNlbGYNCj4gPiBbSS1ELmlldGYtbHRydS1yZWdpc3RyeV0uDQo+IA0KPiBXaGF0IGlz IHRoZSByb2xlIG9mIHRoZSByZWZlcmVuY2UgW0ktRC5pZXRmLWx0cnUtcmVnaXN0cnldIGhlcmU/ ICBJbg0KPiB0aGlzIGNvbnRleHQgaXQgbG9va3MgbGlrZSBhIHBvaW50ZXIgdG8gdGhlIHJlZ2lz dHJ5LCB3aGljaCBpcyBub3QgdHJ1ZS4NCj4gRHJhZnQtaW5pdGlhbCBpcyBhbHJlYWR5IGNob2Nr LWZ1bGwgb2YgcmVmZXJlbmNlcyB0byBkcmFmdC1yZWdpc3RyeQ0KPiB3aXRob3V0IGFkZGluZyBh bm90aGVyIG5vbi1lc3NlbnRpYWwgb25lLg0KPiANCj4gSSBzdWdnZXN0IGRlbGV0aW5nIHRoZSBy ZWZlcmVuY2UsIGFuZCBhbHNvIGFkZGluZyB0aGUgd29yZCAicG90ZW50aWFsIg0KPiBiZWZvcmUg ImNvbmZ1c2lvbiwiIHRob3VnaCBJJ20gbm90IGRvZ21hdGljIGFib3V0IHRoZSBsYXR0ZXIuDQo+ IA0KPiA+IEVhY2ggb2YgdGhlc2UgaW5pdGlhbCBlbnRyaWVzIGhhcyBhbiAiQWRkZWQiIGZpZWxk IHZhbHVlIHByaW9yDQo+ID4gdG8gWVlZWS1NTS1ERC4gIE5vdGUgdGhhdCBbSS1ELmlldGYtbHRy dS1yZWdpc3RyeV0gU2VjdGlvbiAzLjMoMSkNCj4gPiBzcGVjaWZpZXMgdGhhdCB0aGlzIGZpZWxk IG11c3Qgbm90IGNoYW5nZSBhZnRlciByZWdpc3RyYXRpb24uDQo+ID4gT3RoZXIgZmllbGRzIGlu IHRoZXNlIHJlY29yZHMgbWF5IHN1YnNlcXVlbnRseSBiZSBtb2RpZmllZCwNCj4gPiBzdWJqZWN0 IHRvIHRoZSByZXN0cmljdGlvbnMgaW4gU2VjdGlvbiAzLjQgb2YNCj4gPiBbSS1ELmlldGYtbHRy dS1yZWdpc3RyeV0uDQo+IA0KPiBJIHN0aWxsIHdvdWxkIGxpa2UgdG8gYXZvaWQgc3BlY2lmeWlu ZyB0aGUgbGl0ZXJhbCBkYXRlLiAgSWYgd2UgZG8sDQo+IHdlJ2xsIGhhdmUgdG8gYmUgcmVhbGx5 LCByZWFsbHkgc3VyZSB3ZSBkb24ndCBtaXNzIHVwZGF0aW5nIHRoaXMgaW4gdGhlDQo+IGNsb3Np bmcgbW9tZW50cy4NCj4gDQo+ID4gUkZDIEVESVRPUiBOT1RFOiB0aGUgcmVtYWluZGVyIG9mIHRo aXMgc2VjdGlvbiBpcyB0byBiZSBkZWxldGVkIHVwb24NCj4gPiBwdWJsaWNhdGlvbi4NCj4gDQo+ IEdvb2Qgc28gZmFyLiAgKExlc3QgYW55b25lIGZvcmdldCwgdGhpcyBpcyB3aG9sZSBwdXJwb3Nl IG9mIHRoaXMNCj4gZXhlcmNpc2UuKQ0KPiANCj4gPiBJIHRoaW5rIHRoYXQgYWxsIGlzIHJlYWxs eSBuZWVkZWQgaXMgdGhlIGZpcnN0IHBhcmFncmFwaCBhbmQgdGhlIG5vdGUuDQo+ID4gSSdsbCBn byBhbG9uZyB3aXRoIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGlmIGZvbGtzIHRoaW5rIGl0J3MgcmVh bGx5DQo+ID4gdXNlZnVsIGFuZCBuZWNlc3NhcnksIGJ1dCBJJ2QgYmUgaGFwcGllciB3aXRob3V0 IGl0Lg0KPiANCj4gSSdtIGZpbmUgd2l0aCByZW1vdmluZyBpdCwgYmVjYXVzZSBJIGRvbid0IHRo aW5rIHRoZXJlIHNob3VsZCBiZSBhbnkNCj4gbmVlZCB0byByZS1jcmVhdGUgdGhlIGluaXRpYWwg cmVnaXN0cnkuICBUaGUgY3VycmVudCBvbmUgaXMgd2hhdCdzDQo+IGludGVyZXN0aW5nLg0KPiAN Cj4gTGF0ZXI6DQo+IA0KPiA+PiAuLi4gSG93IGFib3V0Og0KPiA+Pg0KPiA+PiAgICAgLi4uIHdp dGggIkFkZGVkIiBmaWVsZCB2YWx1ZXMgbm8gbGF0ZXIgdGhhbiB0aGUgZGF0ZSBvZg0KPiA+PiAg ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4NCj4gPg0KPiA+IEkgbGlrZSB0aGlzIGEg bG90Lg0KPiANCj4gR29vZCwgaWYgd2UgaGF2ZSB0byBoYXZlIHRoaXMgcGFyYWdyYXBoIGF0IGFs bC4NCj4gDQo+ID4+ICAgICBCZWNhdXNlIG9mIHRoaXMsIGl0IG1heSBub3QgYmUgcG9zc2libGUg dG8gdXNlIGEgZnV0dXJlIHZlcnNpb24NCj4gPj4gICAgIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcg UmVnaXN0cnkgdG8gcmVjb25zdHJ1Y3QgYW4gZXhhY3QgY29weSBvZg0KPiA+PiAgICAgdGhlIGlu aXRpYWwgcmVnaXN0cnkgY29udGVudHMuDQo+ID4+DQo+ID4+IENvbW1lbnRzPw0KPiA+IC4uLg0K PiA+DQo+ID4gSWYgZm9sa3MgdGhpbmsgd2UgbmVlZCBhbnkgdGV4dCBvbiByZWNvbnN0cnVjdGlv biwgSSB0aGluayB0aGlzDQo+ID4gYWRkaXRpb24gd291bGQgYmUgYW4gaW1wb3J0YW50IG9uZS4g IChJJ20gc3RpbGwgbm90IGNvbnZpbmNlZCB0aGF0IHdlDQo+ID4gbmVlZCB0byBzYXkgKmFueXRo aW5nKiBhYm91dCByZWNvbnN0cnVjdGlvbiwgdGhvdWdoIEknbSB3aWxsaW5nIHRvIGdvDQo+ID4g YWxvbmcgd2l0aCBpdC4pDQo+IA0KPiBBZ3JlZWQuDQo+IA0KPiBBZGRpc29uIFBoaWxsaXBzIDxh ZGRpc29uIGRvdCBwaGlsbGlwcyBhdCBxdWVzdCBkb3QgY29tPiB3cm90ZToNCj4gDQo+ID4gVGhh dCB3b3VsZCB3b3JrIGV2ZW4gYmV0dGVyLiBBbmQgSSB0b28gd291bGQgYmUgaGFwcHkgd2l0aCBq dXN0IHRoZQ0KPiA+IG9uZSBwYXJhZ3JhcGguDQo+IA0KPiBJbiBhIHByaXZhdGUgbWVzc2FnZSwg aXQgd2FzIGFsc28gc3VnZ2VzdGVkIHRvIHVzZSAicmVjb3JkcyIgaW5zdGVhZCBvZg0KPiAic3Vi dGFncywiIGFuZCBJIGFncmVlIHdpdGggdGhpcyAoc29tZSByZWNvcmRzIGFyZSBmb3IgdGFncywg bm90DQo+IHN1YnRhZ3MpLg0KPiANCj4gT0ssIHNvIGhlcmUncyB3aGF0IHdlIGhhdmUgbm93Og0K PiANCj4gPHByb3Bvc2VkLXRleHQ+DQo+IDMuICBUaGUgcmVtYWluZGVyIG9mIHRoaXMgc2VjdGlv biBzcGVjaWZpZWQgdGhlIGluaXRpYWwgc2V0IG9mIHJlY29yZHMNCj4gZm9yIHRoZSByZWdpc3Ry eS4gIFRoaXMgbWF0ZXJpYWwgd2FzIGRlbGV0ZWQgb24gcHVibGljYXRpb24gb2YgdGhpcw0KPiBt ZW1vLCB0byBhdm9pZCBhbnkgcG90ZW50aWFsIGNvbmZ1c2lvbiB3aXRoIHRoZSByZWdpc3RyeSBp dHNlbGYuDQo+IA0KPiA8IS0tIHBvc3NpYmxlIHNlY29uZCBwYXJhZ3JhcGggLS0+DQo+IDwhLS0N Cj4gRWFjaCBvZiB0aGVzZSBpbml0aWFsIGVudHJpZXMgaGFzIGFuICJBZGRlZCIgZmllbGQgdmFs dWUgbm8gbGF0ZXIgdGhhbg0KPiB0aGUgZGF0ZSBvZiBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3Vt ZW50LiAgTm90ZSB0aGF0IFNlY3Rpb24gMy4zICgxKSBvZg0KPiBbSS1ELmlldGYtbHRydS1yZWdp c3RyeV0gc3BlY2lmaWVzIHRoYXQgdGhpcyBmaWVsZCBtdXN0IG5vdCBjaGFuZ2UgYWZ0ZXINCj4g cmVnaXN0cmF0aW9uLiAgT3RoZXIgZmllbGRzIGluIHRoZXNlIHJlY29yZHMgbWF5IHN1YnNlcXVl bnRseSBiZQ0KPiBtb2RpZmllZCwgc3ViamVjdCB0byB0aGUgcmVzdHJpY3Rpb25zIGluIFNlY3Rp b24gMy40IG9mDQo+IFtJLUQuaWV0Zi1sdHJ1LXJlZ2lzdHJ5XS4NCj4gLS0+DQo+IDwhLS0gYWx0 ZXJuYXRpdmUgcG9zc2libGUgc2Vjb25kIHBhcmFncmFwaCAtLT4NCj4gPCEtLSB0aGlzIGFzc3Vt ZXMgYW4gaW5pdGlhbCByZWdpc3RyeSBGaWxlLURhdGUgb2YgMjAwNS0xMi0wMSAtLT4NCj4gPCEt LQ0KPiBFYWNoIG9mIHRoZXNlIGluaXRpYWwgZW50cmllcyBoYXMgYW4gIkFkZGVkIiBmaWVsZCB2 YWx1ZSBwcmlvciB0bw0KPiAyMDA1LTEyLTAyLiAgTm90ZSB0aGF0IFNlY3Rpb24gMy4zICgxKSBv ZiBbSS1ELmlldGYtbHRydS1yZWdpc3RyeV0NCj4gc3BlY2lmaWVzIHRoYXQgdGhpcyBmaWVsZCBt dXN0IG5vdCBjaGFuZ2UgYWZ0ZXIgcmVnaXN0cmF0aW9uLiAgT3RoZXINCj4gZmllbGRzIGluIHRo ZXNlIHJlY29yZHMgbWF5IHN1YnNlcXVlbnRseSBiZSBtb2RpZmllZCwgc3ViamVjdCB0byB0aGUN Cj4gcmVzdHJpY3Rpb25zIGluIFNlY3Rpb24gMy40IG9mIFtJLUQuaWV0Zi1sdHJ1LXJlZ2lzdHJ5 XS4NCj4gLS0+DQo+IA0KPiBbUkZDIEVESVRPUiBOT1RFOiB0aGUgcmVtYWluZGVyIG9mIHRoaXMg c2VjdGlvbiBpcyB0byBiZSBkZWxldGVkIHVwb24NCj4gcHVibGljYXRpb24uXQ0KPiA8L3Byb3Bv c2VkLXRleHQ+DQo+IA0KPiBDb21tZW50cz8NCj4gDQo+IC0tDQo+IERvdWcgRXdlbGwNCj4gRnVs bGVydG9uLCBDYWxpZm9ybmlhDQo+IGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2VsbC8N Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============1393105846== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1393105846==-- From ltru-bounces@ietf.org Sun Sep 25 00:34:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJODB-00047r-Kt; Sun, 25 Sep 2005 00:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJOD9-00041o-KL for ltru@megatron.ietf.org; Sun, 25 Sep 2005 00:33:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08143 for ; Sun, 25 Sep 2005 00:33:56 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJOJu-0007Pm-Vu for ltru@ietf.org; Sun, 25 Sep 2005 00:41:00 -0400 Received: from h-68-166-189-49.snvacaid.dynamic.covad.net ([68.166.189.49] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EJOCz-0001F2-00 for ltru@ietf.org; Sun, 25 Sep 2005 00:33:49 -0400 Message-ID: <000a01c5c18a$b6a8f1a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050925020209.DDHS23403.edge4.adelphia.net@megatron.ietf.org> <008301c5c187$8551bf40$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Note to RFC editor in initial registry Date: Sat, 24 Sep 2005 21:36:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, September 24, 2005 9:13 PM > Subject: [Ltru] Re: Note to RFC editor in initial registry ... > OK, so here's what we have now: > > > 3. The remainder of this section specified the initial set of records > for the registry. This material was deleted on publication of this > memo, to avoid any potential confusion with the registry itself. Looks good to me. Ship it. :-) > > > > > I could live with either of these, but would be happier without them. > [RFC EDITOR NOTE: the remainder of this section is to be deleted upon > publication.] > > > Comments? ... Looks good; thanks for sorting through all the comments. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 25 01:13:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJOp7-00011p-0D; Sun, 25 Sep 2005 01:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJOp3-00011d-Mk for ltru@megatron.ietf.org; Sun, 25 Sep 2005 01:13:10 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09418 for ; Sun, 25 Sep 2005 01:13:08 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050925051237.PGSW27017.mta11.adelphia.net@DEWELL> for ; Sun, 25 Sep 2005 01:12:37 -0400 Message-ID: <00a401c5c18f$69b0b680$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050925043503.CSGQ23403.edge4.adelphia.net@megatron.ietf.org> Date: Sat, 24 Sep 2005 22:10:13 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Note to RFC editor in initial registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Put in the first paragraph (about the material having been deleted). > Leave out the rest. Randy Presuhn wrote: > I could live with either of these, but would be happier without them. OK, good enough. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 25 02:07:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJPfx-0008RA-R9; Sun, 25 Sep 2005 02:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJPfw-0008R4-7G for ltru@megatron.ietf.org; Sun, 25 Sep 2005 02:07:48 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17027 for ; Sun, 25 Sep 2005 02:07:41 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050925060707.DWWF12165.mta10.adelphia.net@DEWELL>; Sun, 25 Sep 2005 02:07:07 -0400 Message-ID: <00bd01c5c197$07e68ee0$030aa8c0@DEWELL> From: "Doug Ewell" To: Date: Sat, 24 Sep 2005 23:04:44 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BA_01C5C15C.5A720120" 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 Cc: LTRU Working Group Subject: [Ltru] Submission: LTRU initial-registry draft-05 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00BA_01C5C15C.5A720120 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear Editor, Attached please find the sixth draft of the LTRU initial-registry document, "draft-ietf-ltru-initial-05", in text format. This draft was generated from XML source using xml2rfc, and has been scanned with idnits. The XML source is available at http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-05.xml, or via e-mail on request. Best regards, -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ------=_NextPart_000_00BA_01C5C15C.5A720120 Content-Type: text/plain; name="draft-ietf-ltru-initial-05.txt" Content-Disposition: attachment; filename="draft-ietf-ltru-initial-05.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= LTRU D. Ewell, Ed.=0A= Internet-Draft September 24, 2005=0A= Expires: March 28, 2006=0A= =0A= =0A= Initial Language Subtag Registry=0A= draft-ietf-ltru-initial-05=0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on March 28, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2005).=0A= =0A= Abstract=0A= =0A= This memo defines the initial contents of the IANA Language Subtag=0A= Registry for use in forming tags for the identification of languages.=0A= Since the contents of this memo only serve as a starting point for=0A= the registry, it is inappropriate to use this memo in lieu of the=0A= registry.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 1]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. Initialization of the Registry . . . . . . . . . . . . . . . 4=0A= 3. Initial Registry Contents . . . . . . . . . . . . . . . . . . 7=0A= 4. Omitted Code Elements . . . . . . . . . . . . . . . . . . . . 113=0A= 5. Security Considerations . . . . . . . . . . . . . . . . . . . 114=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115=0A= 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 116=0A= 7.1. Normative References . . . . . . . . . . . . . . . . . . 116=0A= 7.2. Informative References . . . . . . . . . . . . . . . . . 116=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 117=0A= Intellectual Property and Copyright Statements . . . . . . . . . 118=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 2]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= 1. Introduction=0A= =0A= [I-D.ietf-ltru-registry] provides for a Language Subtag Registry and=0A= describes its format. This memo defines the initial contents of the=0A= IANA Language Subtag Registry, using the criteria described in=0A= Section 2.=0A= =0A= The Language Subtag Registry is formatted in a modified record-jar=0A= text format, as described in [record-jar]. The specific format of=0A= the registry, and the definition and intended purpose of each of the=0A= fields, are described in [I-D.ietf-ltru-registry].=0A= =0A= The registry is expected to change over time, as new subtags are=0A= registered and existing subtags are modified or deprecated. The=0A= process of updating the registry is described in Section 3 of=0A= [I-D.ietf-ltru-registry]. This memo does not define the permanent=0A= contents of the registry and should not be represented as doing so.=0A= =0A= Many of the subtags defined in this registry are based on code=0A= elements defined in [ISO639-1], [ISO639-2], [ISO15924], [ISO3166-1],=0A= and [UN_M.49]. This registry is not a mirror of the code lists=0A= defined by these standards, and should not be used as one.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 3]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= 2. Initialization of the Registry=0A= =0A= Section 3.7 of [I-D.ietf-ltru-registry] requires that the LTRU=0A= working group create an initial version of the Language Subtag=0A= Registry and populate it with the initial set of subtags. This=0A= involves converting the entries from the existing IANA language tag=0A= registry defined by [RFC3066] to the new format, as well as defining=0A= valid subtags from various source standards. This section describes=0A= the process that was used to create the initial registry entries.=0A= =0A= The initial set of records was based on the following standards:=0A= [ISO639-1], [ISO639-2], [ISO15924], and [ISO3166-1]. The following=0A= criteria were used to select and format the records of the subtags=0A= included in the initial Language Subtag Registry (hereafter "ILSR"):=0A= =0A= 1. For each source standard, the date of the standard referenced=0A= in [RFC1766] was selected as the starting date. Code elements=0A= that were valid on that date in the selected standard were added=0A= to the ILSR. Code elements that were previously assigned, but=0A= which were vacated or withdrawn before that date, were not added=0A= to the ILSR.=0A= =0A= 2. For each successive change to the standard, any additional=0A= assignments up to the date of the adoption of [I-D.ietf-ltru-=0A= registry] were added to the ILSR. Values that have been withdrawn=0A= are marked as deprecated, but not removed. Changes in meaning or=0A= assignment of a subtag were permitted during this process (for=0A= example, the [ISO3166-1] code element 'CS' was originally assigned=0A= to Czechoslovakia and is now assigned to Serbia and Montenegro).=0A= =0A= Code elements from [UN_M.49] were also included in the ILSR using the=0A= criteria above, with the following additional rules:=0A= =0A= 3. UN numeric code elements assigned to "macro-geographical=0A= (continental)" regions as of the date of adoption of [I-D.ietf-=0A= ltru-registry] were added to the ILSR and thereby made valid for=0A= use in language tags.=0A= =0A= 4. The UN numeric code elements for "economic groupings" or=0A= "other groupings," and the alphanumeric code elements in Appendix=0A= X of the UN document, were not added to the ILSR.=0A= =0A= 5. The UN numeric code elements for countries or areas not=0A= associated with an assigned [ISO3166-1] alpha-2 code element were=0A= not added to the ILSR. These values are listed in Section 4 and=0A= may be requested for registration by individuals using the process=0A= defined in [I-D.ietf-ltru-registry] and according to the rules=0A= described therein. Listing of these code elements in this section=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 4]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= is not a guarantee of future registration.=0A= =0A= 6. Code elements that were withdrawn, vacated, or deprecated from=0A= [UN_M.49] as of the date of adoption of [I-D.ietf-ltru-registry]=0A= were not added to the ILSR.=0A= =0A= Using the initial set of subtags described above, the tags in the=0A= [RFC3066] registry were evaluated as follows:=0A= =0A= 7. Tags in the [RFC3066] registry that were not deprecated,=0A= consisted entirely of subtags already in this document, and have=0A= the correct form and format for tags defined by [I-D.ietf-ltru-=0A= registry] were converted to records of type "redundant" in the=0A= ILSR. For example, "zh-Hant" is now defined by [I-D.ietf-ltru-=0A= registry] because 'zh' is an [ISO639-1] code element and 'Hant' is=0A= an [ISO15924] code element, and both are defined as subtags in the=0A= ILSR.=0A= =0A= 8. Tags in the [RFC3066] registry that contained one or more=0A= subtags that either did not match the valid registration pattern=0A= or were not otherwise defined by [I-D.ietf-ltru-registry] were=0A= converted to corresponding records of type "grandfathered" in the=0A= ILSR. These records cannot become type "redundant" except by=0A= revision of [I-D.ietf-ltru-registry], but may have a "Deprecated"=0A= and "Preferred-Value" field added to them if a subsequent subtag=0A= assignment or combination of assignments renders the tag obsolete.=0A= =0A= 9. Tags in the [RFC3066] registry that had a notation that they=0A= were deprecated were converted to records of type "grandfathered"=0A= in the ILSR. The record for the grandfathered entry contains a=0A= "Deprecated" field with the most appropriate date that can be=0A= determined for when the [RFC3066] record was deprecated. The=0A= "Comments" field may optionally contain a reason for the=0A= deprecation. The "Preferred-Value" field contains a tag that=0A= replaces the value. For example, the [RFC3066] tag "art-lojban"=0A= is deprecated and thus appears as a grandfathered tag in the ILSR.=0A= Its "Deprecated" field contains the deprecation date (in this case=0A= "2003-09-02") and the "Preferred-Value" field the value "jbo".=0A= =0A= 10. The remaining tags in the [RFC3066] registry are not=0A= deprecated and have a format consistent with language tags as=0A= defined by [I-D.ietf-ltru-registry] but contain subtags which are=0A= not defined in the ILSR. These subtags are eligible for=0A= registration as variants. The ILSR contains appropriate variant=0A= records for the following list of subtags, and the registered=0A= [RFC3066] tags containing these subtags were entered into the ILSR=0A= as type "redundant":=0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 5]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= 1901 (use with Prefix: de)=0A= =0A= 1996 (use with Prefix: de)=0A= =0A= nedis (use with Prefix: sl)=0A= =0A= rozaj (use with Prefix: sl)=0A= =0A= 11. All remaining [RFC3066] registered tags were converted to=0A= records of type "grandfathered" in the ILSR. Interested parties=0A= may use the registration process in [I-D.ietf-ltru-registry] to=0A= attempt to register the variant subtags not already present in the=0A= Language Subtag Registry. If all of the subtags in the original=0A= tag become fully defined by the resulting registrations, then the=0A= original tag is superseded. Such tags will have their record=0A= changed from type "grandfathered" to type "redundant" in the=0A= registry. Note that previous approval of a tag under [RFC3066] is=0A= not a guarantee of approval of a variant subtag under [I-D.ietf-=0A= ltru-registry]. The existing [RFC3066] tag maintains its=0A= validity, but the original reason for its registration might have=0A= become obsolete.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 6]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= 3. Initial Registry Contents=0A= =0A= The remainder of this section specified the initial set of records=0A= for the registry. This material was deleted on publication of this=0A= memo, to avoid any potential confusion with the registry itself.=0A= =0A= [RFC EDITOR NOTE: the remainder of this section is to be deleted upon=0A= publication.]=0A= =0A= The initial Language Subtag Registry follows. The registry begins=0A= with the line that starts with the string "File-Date" and continues=0A= to the end of this section. Headers, footers, line breaks, and other=0A= vertical whitespace introduced by the RFC process are not=0A= significant. Leading horizontal whitespace relative to the "File-=0A= Date" line indicates a continued line in the record-jar format, and=0A= must not be deleted.=0A= =0A= File-Date: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: aa=0A= Description: Afar=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ab=0A= Description: Abkhazian=0A= Added: 2005-09-24=0A= Suppress-Script: Cyrl=0A= %%=0A= Type: language=0A= Subtag: ae=0A= Description: Avestan=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: af=0A= Description: Afrikaans=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ak=0A= Description: Akan=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: am=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 7]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Amharic=0A= Added: 2005-09-24=0A= Suppress-Script: Ethi=0A= %%=0A= Type: language=0A= Subtag: an=0A= Description: Aragonese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ar=0A= Description: Arabic=0A= Added: 2005-09-24=0A= Suppress-Script: Arab=0A= %%=0A= Type: language=0A= Subtag: as=0A= Description: Assamese=0A= Added: 2005-09-24=0A= Suppress-Script: Beng=0A= %%=0A= Type: language=0A= Subtag: av=0A= Description: Avaric=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ay=0A= Description: Aymara=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: az=0A= Description: Azerbaijani=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ba=0A= Description: Bashkir=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: be=0A= Description: Belarusian=0A= Added: 2005-09-24=0A= Suppress-Script: Cyrl=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 8]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: bg=0A= Description: Bulgarian=0A= Added: 2005-09-24=0A= Suppress-Script: Cyrl=0A= %%=0A= Type: language=0A= Subtag: bh=0A= Description: Bihari=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bi=0A= Description: Bislama=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bm=0A= Description: Bambara=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bn=0A= Description: Bengali=0A= Added: 2005-09-24=0A= Suppress-Script: Beng=0A= %%=0A= Type: language=0A= Subtag: bo=0A= Description: Tibetan=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: br=0A= Description: Breton=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bs=0A= Description: Bosnian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ca=0A= Description: Catalan=0A= Description: Valencian=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 9]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ce=0A= Description: Chechen=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ch=0A= Description: Chamorro=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: co=0A= Description: Corsican=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cr=0A= Description: Cree=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cs=0A= Description: Czech=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: cu=0A= Description: Church Slavic=0A= Description: Old Slavonic=0A= Description: Church Slavonic=0A= Description: Old Bulgarian=0A= Description: Old Church Slavonic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cv=0A= Description: Chuvash=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cy=0A= Description: Welsh=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 10]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: da=0A= Description: Danish=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: de=0A= Description: German=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: dv=0A= Description: Divehi=0A= Added: 2005-09-24=0A= Suppress-Script: Thaa=0A= %%=0A= Type: language=0A= Subtag: dz=0A= Description: Dzongkha=0A= Added: 2005-09-24=0A= Suppress-Script: Tibt=0A= %%=0A= Type: language=0A= Subtag: ee=0A= Description: Ewe=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: el=0A= Description: Greek, Modern (1453-)=0A= Added: 2005-09-24=0A= Suppress-Script: Grek=0A= %%=0A= Type: language=0A= Subtag: en=0A= Description: English=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: eo=0A= Description: Esperanto=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 11]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: es=0A= Description: Spanish=0A= Description: Castilian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: et=0A= Description: Estonian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: eu=0A= Description: Basque=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: fa=0A= Description: Persian=0A= Added: 2005-09-24=0A= Suppress-Script: Arab=0A= %%=0A= Type: language=0A= Subtag: ff=0A= Description: Fulah=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: fi=0A= Description: Finnish=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: fj=0A= Description: Fijian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: fo=0A= Description: Faroese=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 12]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: fr=0A= Description: French=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: fy=0A= Description: Frisian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ga=0A= Description: Irish=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: gd=0A= Description: Gaelic=0A= Description: Scottish Gaelic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gl=0A= Description: Galician=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: gn=0A= Description: Guarani=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: gu=0A= Description: Gujarati=0A= Added: 2005-09-24=0A= Suppress-Script: Gujr=0A= %%=0A= Type: language=0A= Subtag: gv=0A= Description: Manx=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 13]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: ha=0A= Description: Hausa=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: he=0A= Description: Hebrew=0A= Added: 2005-09-24=0A= Suppress-Script: Hebr=0A= %%=0A= Type: language=0A= Subtag: hi=0A= Description: Hindi=0A= Added: 2005-09-24=0A= Suppress-Script: Deva=0A= %%=0A= Type: language=0A= Subtag: ho=0A= Description: Hiri Motu=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: hr=0A= Description: Croatian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ht=0A= Description: Haitian=0A= Description: Haitian Creole=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: hu=0A= Description: Hungarian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: hy=0A= Description: Armenian=0A= Added: 2005-09-24=0A= Suppress-Script: Armn=0A= %%=0A= Type: language=0A= Subtag: hz=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 14]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Herero=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ia=0A= Description: Interlingua (International Auxiliary Language=0A= Association)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: id=0A= Description: Indonesian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ie=0A= Description: Interlingue=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ig=0A= Description: Igbo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ii=0A= Description: Sichuan Yi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ik=0A= Description: Inupiaq=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: in=0A= Description: Indonesian=0A= Added: 2005-09-24=0A= Preferred-Value: id=0A= Deprecated: 1989-01-01=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: io=0A= Description: Ido=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 15]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: is=0A= Description: Icelandic=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: it=0A= Description: Italian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: iu=0A= Description: Inuktitut=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: iw=0A= Description: Hebrew=0A= Added: 2005-09-24=0A= Preferred-Value: he=0A= Deprecated: 1989-01-01=0A= Suppress-Script: Hebr=0A= %%=0A= Type: language=0A= Subtag: ja=0A= Description: Japanese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ji=0A= Description: Yiddish=0A= Added: 2005-09-24=0A= Preferred-Value: yi=0A= Deprecated: 1989-01-01=0A= %%=0A= Type: language=0A= Subtag: jv=0A= Description: Javanese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: jw=0A= Description: Javanese=0A= Added: 2005-09-24=0A= Preferred-Value: jv=0A= Deprecated: 2001-08-13=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 16]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Comments: published by error in Table 1 of ISO 639:1988=0A= %%=0A= Type: language=0A= Subtag: ka=0A= Description: Georgian=0A= Added: 2005-09-24=0A= Suppress-Script: Geor=0A= %%=0A= Type: language=0A= Subtag: kg=0A= Description: Kongo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ki=0A= Description: Kikuyu=0A= Description: Gikuyu=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kj=0A= Description: Kuanyama=0A= Description: Kwanyama=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kk=0A= Description: Kazakh=0A= Added: 2005-09-24=0A= Suppress-Script: Cyrl=0A= %%=0A= Type: language=0A= Subtag: kl=0A= Description: Kalaallisut=0A= Description: Greenlandic=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: km=0A= Description: Khmer=0A= Added: 2005-09-24=0A= Suppress-Script: Khmr=0A= %%=0A= Type: language=0A= Subtag: kn=0A= Description: Kannada=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 17]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Suppress-Script: Knda=0A= %%=0A= Type: language=0A= Subtag: ko=0A= Description: Korean=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kr=0A= Description: Kanuri=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ks=0A= Description: Kashmiri=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ku=0A= Description: Kurdish=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kv=0A= Description: Komi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kw=0A= Description: Cornish=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ky=0A= Description: Kirghiz=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: la=0A= Description: Latin=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: lb=0A= Description: Luxembourgish=0A= Description: Letzeburgesch=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 18]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: lg=0A= Description: Ganda=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: li=0A= Description: Limburgan=0A= Description: Limburger=0A= Description: Limburgish=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ln=0A= Description: Lingala=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: lo=0A= Description: Lao=0A= Added: 2005-09-24=0A= Suppress-Script: Laoo=0A= %%=0A= Type: language=0A= Subtag: lt=0A= Description: Lithuanian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: lu=0A= Description: Luba-Katanga=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lv=0A= Description: Latvian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: mg=0A= Description: Malagasy=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 19]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: mh=0A= Description: Marshallese=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: mi=0A= Description: Maori=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mk=0A= Description: Macedonian=0A= Added: 2005-09-24=0A= Suppress-Script: Cyrl=0A= %%=0A= Type: language=0A= Subtag: ml=0A= Description: Malayalam=0A= Added: 2005-09-24=0A= Suppress-Script: Mlym=0A= %%=0A= Type: language=0A= Subtag: mn=0A= Description: Mongolian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mo=0A= Description: Moldavian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: mr=0A= Description: Marathi=0A= Added: 2005-09-24=0A= Suppress-Script: Deva=0A= %%=0A= Type: language=0A= Subtag: ms=0A= Description: Malay=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 20]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: mt=0A= Description: Maltese=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: my=0A= Description: Burmese=0A= Added: 2005-09-24=0A= Suppress-Script: Mymr=0A= %%=0A= Type: language=0A= Subtag: na=0A= Description: Nauru=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: nb=0A= Description: Norwegian Bokmål=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: nd=0A= Description: Ndebele, North=0A= Description: North Ndebele=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ne=0A= Description: Nepali=0A= Added: 2005-09-24=0A= Suppress-Script: Deva=0A= %%=0A= Type: language=0A= Subtag: ng=0A= Description: Ndonga=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nl=0A= Description: Dutch=0A= Description: Flemish=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 21]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: nn=0A= Description: Norwegian Nynorsk=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: no=0A= Description: Norwegian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: nr=0A= Description: Ndebele, South=0A= Description: South Ndebele=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: nv=0A= Description: Navajo=0A= Description: Navaho=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ny=0A= Description: Chichewa=0A= Description: Chewa=0A= Description: Nyanja=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: oc=0A= Description: Occitan (post 1500)=0A= Description: Provençal=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: oj=0A= Description: Ojibwa=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: om=0A= Description: Oromo=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 22]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: or=0A= Description: Oriya=0A= Added: 2005-09-24=0A= Suppress-Script: Orya=0A= %%=0A= Type: language=0A= Subtag: os=0A= Description: Ossetian=0A= Description: Ossetic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pa=0A= Description: Panjabi=0A= Description: Punjabi=0A= Added: 2005-09-24=0A= Suppress-Script: Guru=0A= %%=0A= Type: language=0A= Subtag: pi=0A= Description: Pali=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pl=0A= Description: Polish=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ps=0A= Description: Pushto=0A= Added: 2005-09-24=0A= Suppress-Script: Arab=0A= %%=0A= Type: language=0A= Subtag: pt=0A= Description: Portuguese=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: qu=0A= Description: Quechua=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 23]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: rm=0A= Description: Raeto-Romance=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: rn=0A= Description: Rundi=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ro=0A= Description: Romanian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ru=0A= Description: Russian=0A= Added: 2005-09-24=0A= Suppress-Script: Cyrl=0A= %%=0A= Type: language=0A= Subtag: rw=0A= Description: Kinyarwanda=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: sa=0A= Description: Sanskrit=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sc=0A= Description: Sardinian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sd=0A= Description: Sindhi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: se=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 24]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Northern Sami=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sg=0A= Description: Sango=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: sh=0A= Description: Serbo-Croatian=0A= Added: 2005-09-24=0A= Deprecated: 2000-02-18=0A= %%=0A= Type: language=0A= Subtag: si=0A= Description: Sinhala=0A= Description: Sinhalese=0A= Added: 2005-09-24=0A= Suppress-Script: Sinh=0A= %%=0A= Type: language=0A= Subtag: sk=0A= Description: Slovak=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: sl=0A= Description: Slovenian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: sm=0A= Description: Samoan=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: sn=0A= Description: Shona=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: so=0A= Description: Somali=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 25]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: sq=0A= Description: Albanian=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: sr=0A= Description: Serbian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ss=0A= Description: Swati=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: st=0A= Description: Sotho, Southern=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: su=0A= Description: Sundanese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sv=0A= Description: Swedish=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: sw=0A= Description: Swahili=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ta=0A= Description: Tamil=0A= Added: 2005-09-24=0A= Suppress-Script: Taml=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 26]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: te=0A= Description: Telugu=0A= Added: 2005-09-24=0A= Suppress-Script: Telu=0A= %%=0A= Type: language=0A= Subtag: tg=0A= Description: Tajik=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: th=0A= Description: Thai=0A= Added: 2005-09-24=0A= Suppress-Script: Thai=0A= %%=0A= Type: language=0A= Subtag: ti=0A= Description: Tigrinya=0A= Added: 2005-09-24=0A= Suppress-Script: Ethi=0A= %%=0A= Type: language=0A= Subtag: tk=0A= Description: Turkmen=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tl=0A= Description: Tagalog=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: tn=0A= Description: Tswana=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: to=0A= Description: Tonga (Tonga Islands)=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 27]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: tr=0A= Description: Turkish=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ts=0A= Description: Tsonga=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: tt=0A= Description: Tatar=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tw=0A= Description: Twi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ty=0A= Description: Tahitian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ug=0A= Description: Uighur=0A= Description: Uyghur=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: uk=0A= Description: Ukrainian=0A= Added: 2005-09-24=0A= Suppress-Script: Cyrl=0A= %%=0A= Type: language=0A= Subtag: ur=0A= Description: Urdu=0A= Added: 2005-09-24=0A= Suppress-Script: Arab=0A= %%=0A= Type: language=0A= Subtag: uz=0A= Description: Uzbek=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 28]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: ve=0A= Description: Venda=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: vi=0A= Description: Vietnamese=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: vo=0A= Description: Volapük=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: wa=0A= Description: Walloon=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: wo=0A= Description: Wolof=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: xh=0A= Description: Xhosa=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: yi=0A= Description: Yiddish=0A= Added: 2005-09-24=0A= Suppress-Script: Hebr=0A= %%=0A= Type: language=0A= Subtag: yo=0A= Description: Yoruba=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: za=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 29]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Zhuang=0A= Description: Chuang=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: zh=0A= Description: Chinese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: zu=0A= Description: Zulu=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ace=0A= Description: Achinese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ach=0A= Description: Acoli=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ada=0A= Description: Adangme=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ady=0A= Description: Adyghe=0A= Description: Adygei=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: afa=0A= Description: Afro-Asiatic (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: afh=0A= Description: Afrihili=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ain=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 30]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Ainu=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: akk=0A= Description: Akkadian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ale=0A= Description: Aleut=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: alg=0A= Description: Algonquian languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: alt=0A= Description: Southern Altai=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ang=0A= Description: English, Old (ca. 450-1100)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: apa=0A= Description: Apache languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: arc=0A= Description: Aramaic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: arn=0A= Description: Araucanian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: arp=0A= Description: Arapaho=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 31]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: art=0A= Description: Artificial (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: arw=0A= Description: Arawak=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ast=0A= Description: Asturian=0A= Description: Bable=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ath=0A= Description: Athapascan languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: aus=0A= Description: Australian languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: awa=0A= Description: Awadhi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bad=0A= Description: Banda=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bai=0A= Description: Bamileke languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bal=0A= Description: Baluchi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ban=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 32]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Balinese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bas=0A= Description: Basa=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bat=0A= Description: Baltic (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bej=0A= Description: Beja=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bem=0A= Description: Bemba=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ber=0A= Description: Berber (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bho=0A= Description: Bhojpuri=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bik=0A= Description: Bikol=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bin=0A= Description: Bini=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bla=0A= Description: Siksika=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 33]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: bnt=0A= Description: Bantu (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bra=0A= Description: Braj=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: btk=0A= Description: Batak (Indonesia)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bua=0A= Description: Buriat=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: bug=0A= Description: Buginese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: byn=0A= Description: Blin=0A= Description: Bilin=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cad=0A= Description: Caddo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cai=0A= Description: Central American Indian (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: car=0A= Description: Carib=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cau=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 34]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Caucasian (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ceb=0A= Description: Cebuano=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cel=0A= Description: Celtic (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: chb=0A= Description: Chibcha=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: chg=0A= Description: Chagatai=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: chk=0A= Description: Chuukese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: chm=0A= Description: Mari=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: chn=0A= Description: Chinook jargon=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cho=0A= Description: Choctaw=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: chp=0A= Description: Chipewyan=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 35]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: chr=0A= Description: Cherokee=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: chy=0A= Description: Cheyenne=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cmc=0A= Description: Chamic languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cop=0A= Description: Coptic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cpe=0A= Description: Creoles and pidgins, English-based (Other)=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: cpf=0A= Description: Creoles and pidgins, French-based (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cpp=0A= Description: Creoles and pidgins, Portuguese-based (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: crh=0A= Description: Crimean Tatar=0A= Description: Crimean Turkish=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: crp=0A= Description: Creoles and pidgins (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 36]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: csb=0A= Description: Kashubian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: cus=0A= Description: Cushitic (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: dak=0A= Description: Dakota=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: dar=0A= Description: Dargwa=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: day=0A= Description: Dayak=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: del=0A= Description: Delaware=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: den=0A= Description: Slave (Athapascan)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: dgr=0A= Description: Dogrib=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: din=0A= Description: Dinka=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: doi=0A= Description: Dogri=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 37]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: dra=0A= Description: Dravidian (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: dsb=0A= Description: Lower Sorbian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: dua=0A= Description: Duala=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: dum=0A= Description: Dutch, Middle (ca. 1050-1350)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: dyu=0A= Description: Dyula=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: efi=0A= Description: Efik=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: egy=0A= Description: Egyptian (Ancient)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: eka=0A= Description: Ekajuk=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: elx=0A= Description: Elamite=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: enm=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 38]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: English, Middle (1100-1500)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ewo=0A= Description: Ewondo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: fan=0A= Description: Fang=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: fat=0A= Description: Fanti=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: fil=0A= Description: Filipino=0A= Description: Pilipino=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: fiu=0A= Description: Finno-Ugrian (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: fon=0A= Description: Fon=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: frm=0A= Description: French, Middle (ca. 1400-1600)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: fro=0A= Description: French, Old (842-ca. 1400)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: fur=0A= Description: Friulian=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 39]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: gaa=0A= Description: Ga=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gay=0A= Description: Gayo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gba=0A= Description: Gbaya=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gem=0A= Description: Germanic (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gez=0A= Description: Geez=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gil=0A= Description: Gilbertese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gmh=0A= Description: German, Middle High (ca. 1050-1500)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: goh=0A= Description: German, Old High (ca. 750-1050)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gon=0A= Description: Gondi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gor=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 40]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Gorontalo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: got=0A= Description: Gothic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: grb=0A= Description: Grebo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: grc=0A= Description: Greek, Ancient (to 1453)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: gwi=0A= Description: Gwich´in=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: hai=0A= Description: Haida=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: haw=0A= Description: Hawaiian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: hil=0A= Description: Hiligaynon=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: him=0A= Description: Himachali=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: hit=0A= Description: Hittite=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 41]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: hmn=0A= Description: Hmong=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: hsb=0A= Description: Upper Sorbian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: hup=0A= Description: Hupa=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: iba=0A= Description: Iban=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ijo=0A= Description: Ijo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ilo=0A= Description: Iloko=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: inc=0A= Description: Indic (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ine=0A= Description: Indo-European (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: inh=0A= Description: Ingush=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ira=0A= Description: Iranian (Other)=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 42]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: iro=0A= Description: Iroquoian languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: jbo=0A= Description: Lojban=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: jpr=0A= Description: Judeo-Persian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: jrb=0A= Description: Judeo-Arabic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kaa=0A= Description: Kara-Kalpak=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kab=0A= Description: Kabyle=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kac=0A= Description: Kachin=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kam=0A= Description: Kamba=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kar=0A= Description: Karen=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 43]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: kaw=0A= Description: Kawi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kbd=0A= Description: Kabardian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kha=0A= Description: Khasi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: khi=0A= Description: Khoisan (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kho=0A= Description: Khotanese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kmb=0A= Description: Kimbundu=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kok=0A= Description: Konkani=0A= Added: 2005-09-24=0A= Suppress-Script: Deva=0A= %%=0A= Type: language=0A= Subtag: kos=0A= Description: Kosraean=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kpe=0A= Description: Kpelle=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: krc=0A= Description: Karachay-Balkar=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 44]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kro=0A= Description: Kru=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kru=0A= Description: Kurukh=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kum=0A= Description: Kumyk=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: kut=0A= Description: Kutenai=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lad=0A= Description: Ladino=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lah=0A= Description: Lahnda=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lam=0A= Description: Lamba=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lez=0A= Description: Lezghian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lol=0A= Description: Mongo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 45]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: loz=0A= Description: Lozi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lua=0A= Description: Luba-Lulua=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lui=0A= Description: Luiseno=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lun=0A= Description: Lunda=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: luo=0A= Description: Luo (Kenya and Tanzania)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: lus=0A= Description: Lushai=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mad=0A= Description: Madurese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mag=0A= Description: Magahi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mai=0A= Description: Maithili=0A= Added: 2005-09-24=0A= Suppress-Script: Deva=0A= %%=0A= Type: language=0A= Subtag: mak=0A= Description: Makasar=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 46]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: man=0A= Description: Mandingo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: map=0A= Description: Austronesian (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mas=0A= Description: Masai=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mdf=0A= Description: Moksha=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mdr=0A= Description: Mandar=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: men=0A= Description: Mende=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: mga=0A= Description: Irish, Middle (900-1200)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mic=0A= Description: Mi'kmaq=0A= Description: Micmac=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: min=0A= Description: Minangkabau=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 47]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: mis=0A= Description: Miscellaneous languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mkh=0A= Description: Mon-Khmer (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mnc=0A= Description: Manchu=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mni=0A= Description: Manipuri=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mno=0A= Description: Manobo languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: moh=0A= Description: Mohawk=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mos=0A= Description: Mossi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mul=0A= Description: Multiple languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mun=0A= Description: Munda languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mus=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 48]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Creek=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mwl=0A= Description: Mirandese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: mwr=0A= Description: Marwari=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: myn=0A= Description: Mayan languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: myv=0A= Description: Erzya=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nah=0A= Description: Nahuatl=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nai=0A= Description: North American Indian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nap=0A= Description: Neapolitan=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nds=0A= Description: Low German=0A= Description: Low Saxon=0A= Description: German, Low=0A= Description: Saxon, Low=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: new=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 49]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Nepal Bhasa=0A= Description: Newari=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nia=0A= Description: Nias=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nic=0A= Description: Niger-Kordofanian (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: niu=0A= Description: Niuean=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: nog=0A= Description: Nogai=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: non=0A= Description: Norse, Old=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nso=0A= Description: Northern Sotho=0A= Description: Pedi=0A= Description: Sepedi=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: nub=0A= Description: Nubian languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nwc=0A= Description: Classical Newari=0A= Description: Old Newari=0A= Description: Classical Nepal Bhasa=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 50]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nym=0A= Description: Nyamwezi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nyn=0A= Description: Nyankole=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nyo=0A= Description: Nyoro=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: nzi=0A= Description: Nzima=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: osa=0A= Description: Osage=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ota=0A= Description: Turkish, Ottoman (1500-1928)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: oto=0A= Description: Otomian languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: paa=0A= Description: Papuan (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pag=0A= Description: Pangasinan=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 51]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: pal=0A= Description: Pahlavi=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pam=0A= Description: Pampanga=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pap=0A= Description: Papiamento=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pau=0A= Description: Palauan=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: peo=0A= Description: Persian, Old (ca. 600-400 B.C.)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: phi=0A= Description: Philippine (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: phn=0A= Description: Phoenician=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pon=0A= Description: Pohnpeian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pra=0A= Description: Prakrit languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: pro=0A= Description: Provençal, Old (to 1500)=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 52]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: qaa..qtz=0A= Description: PRIVATE USE=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: raj=0A= Description: Rajasthani=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: rap=0A= Description: Rapanui=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: rar=0A= Description: Rarotongan=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: roa=0A= Description: Romance (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: rom=0A= Description: Romany=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: rup=0A= Description: Aromanian=0A= Description: Arumanian=0A= Description: Macedo-Romanian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sad=0A= Description: Sandawe=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sah=0A= Description: Yakut=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 53]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: language=0A= Subtag: sai=0A= Description: South American Indian (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sal=0A= Description: Salishan languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sam=0A= Description: Samaritan Aramaic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sas=0A= Description: Sasak=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sat=0A= Description: Santali=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: scn=0A= Description: Sicilian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sco=0A= Description: Scots=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sel=0A= Description: Selkup=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sem=0A= Description: Semitic (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sga=0A= Description: Irish, Old (to 900)=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 54]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sgn=0A= Description: Sign Languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: shn=0A= Description: Shan=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sid=0A= Description: Sidamo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sio=0A= Description: Siouan languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sit=0A= Description: Sino-Tibetan (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sla=0A= Description: Slavic (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sma=0A= Description: Southern Sami=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: smi=0A= Description: Sami languages (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: smj=0A= Description: Lule Sami=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 55]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: smn=0A= Description: Inari Sami=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sms=0A= Description: Skolt Sami=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: snk=0A= Description: Soninke=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sog=0A= Description: Sogdian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: son=0A= Description: Songhai=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: srn=0A= Description: Sranan Tongo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: srr=0A= Description: Serer=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ssa=0A= Description: Nilo-Saharan (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: suk=0A= Description: Sukuma=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sus=0A= Description: Susu=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 56]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: sux=0A= Description: Sumerian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: syr=0A= Description: Syriac=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tai=0A= Description: Tai (Other)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tem=0A= Description: Timne=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: ter=0A= Description: Tereno=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tet=0A= Description: Tetum=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tig=0A= Description: Tigre=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tiv=0A= Description: Tiv=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tkl=0A= Description: Tokelau=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 57]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: tlh=0A= Description: Klingon=0A= Description: tlhIngan-Hol=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tli=0A= Description: Tlingit=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tmh=0A= Description: Tamashek=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: tog=0A= Description: Tonga (Nyasa)=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tpi=0A= Description: Tok Pisin=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: tsi=0A= Description: Tsimshian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tum=0A= Description: Tumbuka=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tup=0A= Description: Tupi languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: tut=0A= Description: Altaic (Other)=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 58]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: language=0A= Subtag: tvl=0A= Description: Tuvalu=0A= Added: 2005-09-24=0A= Suppress-Script: Latn=0A= %%=0A= Type: language=0A= Subtag: tyv=0A= Description: Tuvinian=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: udm=0A= Description: Udmurt=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: uga=0A= Description: Ugaritic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: umb=0A= Description: Umbundu=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: und=0A= Description: Undetermined=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: vai=0A= Description: Vai=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: vot=0A= Description: Votic=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: wak=0A= Description: Wakashan languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 59]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: wal=0A= Description: Walamo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: war=0A= Description: Waray=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: was=0A= Description: Washo=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: wen=0A= Description: Sorbian languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: xal=0A= Description: Kalmyk=0A= Description: Oirat=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: yao=0A= Description: Yao=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: yap=0A= Description: Yapese=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: ypk=0A= Description: Yupik languages=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: zap=0A= Description: Zapotec=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: zen=0A= Description: Zenaga=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 60]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: znd=0A= Description: Zande=0A= Added: 2005-09-24=0A= %%=0A= Type: language=0A= Subtag: zun=0A= Description: Zuni=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Arab=0A= Description: Arabic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Armn=0A= Description: Armenian=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Bali=0A= Description: Balinese=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Batk=0A= Description: Batak=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Beng=0A= Description: Bengali=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Blis=0A= Description: Blissymbols=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Bopo=0A= Description: Bopomofo=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 61]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: Brah=0A= Description: Brahmi=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Brai=0A= Description: Braille=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Bugi=0A= Description: Buginese=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Buhd=0A= Description: Buhid=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Cans=0A= Description: Unified Canadian Aboriginal Syllabics=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Cham=0A= Description: Cham=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Cher=0A= Description: Cherokee=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Cirt=0A= Description: Cirth=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Copt=0A= Description: Coptic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Cprt=0A= Description: Cypriot=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 62]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: script=0A= Subtag: Cyrl=0A= Description: Cyrillic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Cyrs=0A= Description: Cyrillic (Old Church Slavonic variant)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Deva=0A= Description: Devanagari (Nagari)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Dsrt=0A= Description: Deseret (Mormon)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Egyd=0A= Description: Egyptian demotic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Egyh=0A= Description: Egyptian hieratic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Egyp=0A= Description: Egyptian hieroglyphs=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Ethi=0A= Description: Ethiopic (Ge‘ez)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Geok=0A= Description: Khutsuri (Asomtavruli and Nuskhuri)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Geor=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 63]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Georgian (Mkhedruli)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Glag=0A= Description: Glagolitic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Goth=0A= Description: Gothic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Grek=0A= Description: Greek=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Gujr=0A= Description: Gujarati=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Guru=0A= Description: Gurmukhi=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hang=0A= Description: Hangul (Hangŭl, Hangeul)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hani=0A= Description: Han (Hanzi, Kanji, Hanja)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hano=0A= Description: Hanunoo (Hanunóo)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hans=0A= Description: Han (Simplified variant)=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 64]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: script=0A= Subtag: Hant=0A= Description: Han (Traditional variant)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hebr=0A= Description: Hebrew=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hira=0A= Description: Hiragana=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hmng=0A= Description: Pahawh Hmong=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hrkt=0A= Description: (alias for Hiragana + Katakana)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Hung=0A= Description: Old Hungarian=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Inds=0A= Description: Indus (Harappan)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Ital=0A= Description: Old Italic (Etruscan, Oscan, etc.)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Java=0A= Description: Javanese=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Kali=0A= Description: Kayah Li=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 65]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Kana=0A= Description: Katakana=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Khar=0A= Description: Kharoshthi=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Khmr=0A= Description: Khmer=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Knda=0A= Description: Kannada=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Laoo=0A= Description: Lao=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Latf=0A= Description: Latin (Fraktur variant)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Latg=0A= Description: Latin (Gaelic variant)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Latn=0A= Description: Latin=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Lepc=0A= Description: Lepcha (Róng)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 66]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: Limb=0A= Description: Limbu=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Lina=0A= Description: Linear A=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Linb=0A= Description: Linear B=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Mand=0A= Description: Mandaean=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Maya=0A= Description: Mayan hieroglyphs=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Mero=0A= Description: Meroitic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Mlym=0A= Description: Malayalam=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Mong=0A= Description: Mongolian=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Mymr=0A= Description: Myanmar (Burmese)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Nkoo=0A= Description: N’Ko=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 67]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: script=0A= Subtag: Ogam=0A= Description: Ogham=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Orkh=0A= Description: Orkhon=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Orya=0A= Description: Oriya=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Osma=0A= Description: Osmanya=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Perm=0A= Description: Old Permic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Phag=0A= Description: Phags-pa=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Phnx=0A= Description: Phoenician=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Plrd=0A= Description: Pollard Phonetic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Qaaa..Qabx=0A= Description: PRIVATE USE=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Roro=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 68]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Rongorongo=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Runr=0A= Description: Runic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Sara=0A= Description: Sarati=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Shaw=0A= Description: Shavian (Shaw)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Sinh=0A= Description: Sinhala=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Sylo=0A= Description: Syloti Nagri=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Syrc=0A= Description: Syriac=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Syre=0A= Description: Syriac (Estrangelo variant)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Syrj=0A= Description: Syriac (Western variant)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Syrn=0A= Description: Syriac (Eastern variant)=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 69]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: script=0A= Subtag: Tagb=0A= Description: Tagbanwa=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Tale=0A= Description: Tai Le=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Talu=0A= Description: New Tai Lue=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Taml=0A= Description: Tamil=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Telu=0A= Description: Telugu=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Teng=0A= Description: Tengwar=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Tfng=0A= Description: Tifinagh (Berber)=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Tglg=0A= Description: Tagalog=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Thaa=0A= Description: Thaana=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Thai=0A= Description: Thai=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 70]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Tibt=0A= Description: Tibetan=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Ugar=0A= Description: Ugaritic=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Vaii=0A= Description: Vai=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Visp=0A= Description: Visible Speech=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Xpeo=0A= Description: Old Persian=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Xsux=0A= Description: Cuneiform, Sumero-Akkadian=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Yiii=0A= Description: Yi=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Zxxx=0A= Description: Code for unwritten languages=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= Subtag: Zyyy=0A= Description: Code for undetermined script=0A= Added: 2005-09-24=0A= %%=0A= Type: script=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 71]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: Zzzz=0A= Description: Code for uncoded script=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AA=0A= Description: PRIVATE USE=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AD=0A= Description: Andorra=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AE=0A= Description: United Arab Emirates=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AF=0A= Description: Afghanistan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AG=0A= Description: Antigua and Barbuda=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AI=0A= Description: Anguilla=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AL=0A= Description: Albania=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AM=0A= Description: Armenia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AN=0A= Description: Netherlands Antilles=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 72]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: region=0A= Subtag: AO=0A= Description: Angola=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AQ=0A= Description: Antarctica=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AR=0A= Description: Argentina=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AS=0A= Description: American Samoa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AT=0A= Description: Austria=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AU=0A= Description: Australia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AW=0A= Description: Aruba=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AX=0A= Description: Åland Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: AZ=0A= Description: Azerbaijan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BA=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 73]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Bosnia and Herzegovina=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BB=0A= Description: Barbados=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BD=0A= Description: Bangladesh=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BE=0A= Description: Belgium=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BF=0A= Description: Burkina Faso=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BG=0A= Description: Bulgaria=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BH=0A= Description: Bahrain=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BI=0A= Description: Burundi=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BJ=0A= Description: Benin=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BM=0A= Description: Bermuda=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 74]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: region=0A= Subtag: BN=0A= Description: Brunei Darussalam=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BO=0A= Description: Bolivia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BR=0A= Description: Brazil=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BS=0A= Description: Bahamas=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BT=0A= Description: Bhutan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BU=0A= Description: Burma=0A= Added: 2005-09-24=0A= Preferred-Value: MM=0A= Deprecated: 1989-12-05=0A= %%=0A= Type: region=0A= Subtag: BV=0A= Description: Bouvet Island=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BW=0A= Description: Botswana=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: BY=0A= Description: Belarus=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 75]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: BZ=0A= Description: Belize=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CA=0A= Description: Canada=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CC=0A= Description: Cocos (Keeling) Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CD=0A= Description: Congo, The Democratic Republic of the=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CF=0A= Description: Central African Republic=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CG=0A= Description: Congo=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CH=0A= Description: Switzerland=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CI=0A= Description: Côte d'Ivoire=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CK=0A= Description: Cook Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CL=0A= Description: Chile=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 76]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: region=0A= Subtag: CM=0A= Description: Cameroon=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CN=0A= Description: China=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CO=0A= Description: Colombia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CR=0A= Description: Costa Rica=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CS=0A= Description: Serbia and Montenegro=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CU=0A= Description: Cuba=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CV=0A= Description: Cape Verde=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CX=0A= Description: Christmas Island=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CY=0A= Description: Cyprus=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: CZ=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 77]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Czech Republic=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: DD=0A= Description: German Democratic Republic=0A= Added: 2005-09-24=0A= Preferred-Value: DE=0A= Deprecated: 1990-10-30=0A= %%=0A= Type: region=0A= Subtag: DE=0A= Description: Germany=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: DJ=0A= Description: Djibouti=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: DK=0A= Description: Denmark=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: DM=0A= Description: Dominica=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: DO=0A= Description: Dominican Republic=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: DZ=0A= Description: Algeria=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: EC=0A= Description: Ecuador=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: EE=0A= Description: Estonia=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 78]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: EG=0A= Description: Egypt=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: EH=0A= Description: Western Sahara=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: ER=0A= Description: Eritrea=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: ES=0A= Description: Spain=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: ET=0A= Description: Ethiopia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: FI=0A= Description: Finland=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: FJ=0A= Description: Fiji=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: FK=0A= Description: Falkland Islands (Malvinas)=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: FM=0A= Description: Micronesia, Federated States of=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 79]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: FO=0A= Description: Faroe Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: FR=0A= Description: France=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: FX=0A= Description: Metropolitan France=0A= Added: 2005-09-24=0A= Preferred-Value: FR=0A= Deprecated: 1997-07-14=0A= %%=0A= Type: region=0A= Subtag: GA=0A= Description: Gabon=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GB=0A= Description: United Kingdom=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GD=0A= Description: Grenada=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GE=0A= Description: Georgia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GF=0A= Description: French Guiana=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GH=0A= Description: Ghana=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GI=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 80]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Gibraltar=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GL=0A= Description: Greenland=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GM=0A= Description: Gambia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GN=0A= Description: Guinea=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GP=0A= Description: Guadeloupe=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GQ=0A= Description: Equatorial Guinea=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GR=0A= Description: Greece=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GS=0A= Description: South Georgia and the South Sandwich Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GT=0A= Description: Guatemala=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GU=0A= Description: Guam=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 81]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: region=0A= Subtag: GW=0A= Description: Guinea-Bissau=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: GY=0A= Description: Guyana=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: HK=0A= Description: Hong Kong=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: HM=0A= Description: Heard Island and McDonald Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: HN=0A= Description: Honduras=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: HR=0A= Description: Croatia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: HT=0A= Description: Haiti=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: HU=0A= Description: Hungary=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: ID=0A= Description: Indonesia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: IE=0A= Description: Ireland=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 82]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: IL=0A= Description: Israel=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: IN=0A= Description: India=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: IO=0A= Description: British Indian Ocean Territory=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: IQ=0A= Description: Iraq=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: IR=0A= Description: Iran, Islamic Republic of=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: IS=0A= Description: Iceland=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: IT=0A= Description: Italy=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: JM=0A= Description: Jamaica=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: JO=0A= Description: Jordan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 83]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: JP=0A= Description: Japan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KE=0A= Description: Kenya=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KG=0A= Description: Kyrgyzstan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KH=0A= Description: Cambodia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KI=0A= Description: Kiribati=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KM=0A= Description: Comoros=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KN=0A= Description: Saint Kitts and Nevis=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KP=0A= Description: Korea, Democratic People's Republic of=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KR=0A= Description: Korea, Republic of=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KW=0A= Description: Kuwait=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 84]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: region=0A= Subtag: KY=0A= Description: Cayman Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: KZ=0A= Description: Kazakhstan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LA=0A= Description: Lao People's Democratic Republic=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LB=0A= Description: Lebanon=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LC=0A= Description: Saint Lucia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LI=0A= Description: Liechtenstein=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LK=0A= Description: Sri Lanka=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LR=0A= Description: Liberia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LS=0A= Description: Lesotho=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LT=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 85]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Lithuania=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LU=0A= Description: Luxembourg=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LV=0A= Description: Latvia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: LY=0A= Description: Libyan Arab Jamahiriya=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MA=0A= Description: Morocco=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MC=0A= Description: Monaco=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MD=0A= Description: Moldova, Republic of=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MG=0A= Description: Madagascar=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MH=0A= Description: Marshall Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MK=0A= Description: Macedonia, The Former Yugoslav Republic of=0A= Added: 2005-09-24=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 86]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: region=0A= Subtag: ML=0A= Description: Mali=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MM=0A= Description: Myanmar=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MN=0A= Description: Mongolia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MO=0A= Description: Macao=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MP=0A= Description: Northern Mariana Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MQ=0A= Description: Martinique=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MR=0A= Description: Mauritania=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MS=0A= Description: Montserrat=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MT=0A= Description: Malta=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MU=0A= Description: Mauritius=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 87]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MV=0A= Description: Maldives=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MW=0A= Description: Malawi=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MX=0A= Description: Mexico=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MY=0A= Description: Malaysia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: MZ=0A= Description: Mozambique=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NA=0A= Description: Namibia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NC=0A= Description: New Caledonia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NE=0A= Description: Niger=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NF=0A= Description: Norfolk Island=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 88]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: NG=0A= Description: Nigeria=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NI=0A= Description: Nicaragua=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NL=0A= Description: Netherlands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NO=0A= Description: Norway=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NP=0A= Description: Nepal=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NR=0A= Description: Nauru=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NT=0A= Description: Neutral Zone=0A= Added: 2005-09-24=0A= Deprecated: 1993-07-12=0A= %%=0A= Type: region=0A= Subtag: NU=0A= Description: Niue=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: NZ=0A= Description: New Zealand=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: OM=0A= Description: Oman=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 89]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PA=0A= Description: Panama=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PE=0A= Description: Peru=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PF=0A= Description: French Polynesia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PG=0A= Description: Papua New Guinea=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PH=0A= Description: Philippines=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PK=0A= Description: Pakistan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PL=0A= Description: Poland=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PM=0A= Description: Saint Pierre and Miquelon=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PN=0A= Description: Pitcairn=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 90]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: PR=0A= Description: Puerto Rico=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PS=0A= Description: Palestinian Territory, Occupied=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PT=0A= Description: Portugal=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PW=0A= Description: Palau=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: PY=0A= Description: Paraguay=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: QA=0A= Description: Qatar=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: QM..QZ=0A= Description: PRIVATE USE=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: RE=0A= Description: Réunion=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: RO=0A= Description: Romania=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: RU=0A= Description: Russian Federation=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 91]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: region=0A= Subtag: RW=0A= Description: Rwanda=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SA=0A= Description: Saudi Arabia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SB=0A= Description: Solomon Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SC=0A= Description: Seychelles=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SD=0A= Description: Sudan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SE=0A= Description: Sweden=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SG=0A= Description: Singapore=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SH=0A= Description: Saint Helena=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SI=0A= Description: Slovenia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SJ=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 92]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Svalbard and Jan Mayen=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SK=0A= Description: Slovakia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SL=0A= Description: Sierra Leone=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SM=0A= Description: San Marino=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SN=0A= Description: Senegal=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SO=0A= Description: Somalia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SR=0A= Description: Suriname=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: ST=0A= Description: Sao Tome and Principe=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SU=0A= Description: Union of Soviet Socialist Republics=0A= Added: 2005-09-24=0A= Deprecated: 1992-08-30=0A= %%=0A= Type: region=0A= Subtag: SV=0A= Description: El Salvador=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 93]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: region=0A= Subtag: SY=0A= Description: Syrian Arab Republic=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: SZ=0A= Description: Swaziland=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TC=0A= Description: Turks and Caicos Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TD=0A= Description: Chad=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TF=0A= Description: French Southern Territories=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TG=0A= Description: Togo=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TH=0A= Description: Thailand=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TJ=0A= Description: Tajikistan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TK=0A= Description: Tokelau=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TL=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 94]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Timor-Leste=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TM=0A= Description: Turkmenistan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TN=0A= Description: Tunisia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TO=0A= Description: Tonga=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TP=0A= Description: East Timor=0A= Added: 2005-09-24=0A= Preferred-Value: TL=0A= Deprecated: 2002-11-15=0A= %%=0A= Type: region=0A= Subtag: TR=0A= Description: Turkey=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TT=0A= Description: Trinidad and Tobago=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TV=0A= Description: Tuvalu=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TW=0A= Description: Taiwan, Province of China=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: TZ=0A= Description: Tanzania, United Republic of=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 95]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: UA=0A= Description: Ukraine=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: UG=0A= Description: Uganda=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: UM=0A= Description: United States Minor Outlying Islands=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: US=0A= Description: United States=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: UY=0A= Description: Uruguay=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: UZ=0A= Description: Uzbekistan=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: VA=0A= Description: Holy See (Vatican City State)=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: VC=0A= Description: Saint Vincent and the Grenadines=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: VE=0A= Description: Venezuela=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 96]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: VG=0A= Description: Virgin Islands, British=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: VI=0A= Description: Virgin Islands, U.S.=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: VN=0A= Description: Viet Nam=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: VU=0A= Description: Vanuatu=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: WF=0A= Description: Wallis and Futuna=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: WS=0A= Description: Samoa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: XA..XZ=0A= Description: PRIVATE USE=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: YD=0A= Description: Yemen, Democratic=0A= Added: 2005-09-24=0A= Preferred-Value: YE=0A= Deprecated: 1990-08-14=0A= %%=0A= Type: region=0A= Subtag: YE=0A= Description: Yemen=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: YT=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 97]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Mayotte=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: YU=0A= Description: Yugoslavia=0A= Added: 2005-09-24=0A= Preferred-Value: CS=0A= Deprecated: 2003-07-23=0A= %%=0A= Type: region=0A= Subtag: ZA=0A= Description: South Africa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: ZM=0A= Description: Zambia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: ZR=0A= Description: Zaire=0A= Added: 2005-09-24=0A= Preferred-Value: CD=0A= Deprecated: 1997-07-14=0A= %%=0A= Type: region=0A= Subtag: ZW=0A= Description: Zimbabwe=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: ZZ=0A= Description: PRIVATE USE=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 001=0A= Description: World=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 002=0A= Description: Africa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 98]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Subtag: 005=0A= Description: South America=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 009=0A= Description: Oceania=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 011=0A= Description: Western Africa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 013=0A= Description: Central America=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 014=0A= Description: Eastern Africa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 015=0A= Description: Northern Africa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 017=0A= Description: Middle Africa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 018=0A= Description: Southern Africa=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 019=0A= Description: Americas=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 021=0A= Description: Northern America=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 99]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: region=0A= Subtag: 029=0A= Description: Caribbean=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 030=0A= Description: Eastern Asia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 034=0A= Description: Southern Asia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 035=0A= Description: South-Eastern Asia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 039=0A= Description: Southern Europe=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 053=0A= Description: Australia and New Zealand=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 054=0A= Description: Melanesia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 057=0A= Description: Micronesia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 061=0A= Description: Polynesia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 142=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 100]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Asia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 143=0A= Description: Central Asia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 145=0A= Description: Western Asia=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 150=0A= Description: Europe=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 151=0A= Description: Eastern Europe=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 154=0A= Description: Northern Europe=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 155=0A= Description: Western Europe=0A= Added: 2005-09-24=0A= %%=0A= Type: region=0A= Subtag: 419=0A= Description: Latin America and the Caribbean=0A= Added: 2005-09-24=0A= %%=0A= Type: variant=0A= Subtag: 1901=0A= Description: Traditional German orthography=0A= Added: 2005-09-24=0A= Prefix: de=0A= %%=0A= Type: variant=0A= Subtag: 1996=0A= Description: German orthography of 1996=0A= Added: 2005-09-24=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 101]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Prefix: de=0A= %%=0A= Type: variant=0A= Subtag: nedis=0A= Description: Natisone dialect=0A= Description: Nadiza dialect=0A= Added: 2005-09-24=0A= Prefix: sl=0A= %%=0A= Type: variant=0A= Subtag: rozaj=0A= Description: Resian=0A= Description: Resianic=0A= Description: Rezijan=0A= Added: 2005-09-24=0A= Prefix: sl=0A= %%=0A= Type: grandfathered=0A= Tag: art-lojban=0A= Description: Lojban=0A= Added: 2001-11-11=0A= Preferred-Value: jbo=0A= Deprecated: 2003-09-02=0A= Comments: replaced by ISO code jbo=0A= %%=0A= Type: grandfathered=0A= Tag: cel-gaulish=0A= Description: Gaulish=0A= Added: 2001-05-25=0A= %%=0A= Type: grandfathered=0A= Tag: en-boont=0A= Description: Boontling=0A= Added: 2003-02-14=0A= %%=0A= Type: grandfathered=0A= Tag: en-GB-oed=0A= Description: English, Oxford English Dictionary spelling=0A= Added: 2003-07-09=0A= %%=0A= Type: grandfathered=0A= Tag: en-scouse=0A= Description: Scouse=0A= Added: 2000-05-25=0A= %%=0A= Type: grandfathered=0A= Tag: i-ami=0A= Description: 'Amis=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 102]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 1999-05-25=0A= %%=0A= Type: grandfathered=0A= Tag: i-bnn=0A= Description: Bunun=0A= Added: 1999-05-25=0A= %%=0A= Type: grandfathered=0A= Tag: i-default=0A= Description: Default Language=0A= Added: 1998-03-10=0A= %%=0A= Type: grandfathered=0A= Tag: i-enochian=0A= Description: Enochian=0A= Added: 2002-07-03=0A= %%=0A= Type: grandfathered=0A= Tag: i-hak=0A= Description: Hakka=0A= Added: 1999-01-31=0A= Preferred-Value: zh-hakka=0A= Deprecated: 2000-01-10=0A= %%=0A= Type: grandfathered=0A= Tag: i-klingon=0A= Description: Klingon=0A= Added: 1999-05-26=0A= Preferred-Value: tlh=0A= Deprecated: 2004-02-24=0A= Comments: replaced by ISO code tlh=0A= %%=0A= Type: grandfathered=0A= Tag: i-lux=0A= Description: Luxembourgish=0A= Added: 1997-09-19=0A= Preferred-Value: lb=0A= Deprecated: 1998-09-09=0A= Comments: replaced by ISO code lb=0A= %%=0A= Type: grandfathered=0A= Tag: i-mingo=0A= Description: Mingo=0A= Added: 1997-09-19=0A= %%=0A= Type: grandfathered=0A= Tag: i-navajo=0A= Description: Navajo=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 103]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 1997-09-19=0A= Preferred-Value: nv=0A= Deprecated: 2000-02-18=0A= Comments: replaced by ISO code nv=0A= %%=0A= Type: grandfathered=0A= Tag: i-pwn=0A= Description: Paiwan=0A= Added: 1999-05-25=0A= %%=0A= Type: grandfathered=0A= Tag: i-tao=0A= Description: Tao=0A= Added: 1999-05-25=0A= %%=0A= Type: grandfathered=0A= Tag: i-tay=0A= Description: Tayal=0A= Added: 1999-05-25=0A= %%=0A= Type: grandfathered=0A= Tag: i-tsu=0A= Description: Tsou=0A= Added: 1999-05-25=0A= %%=0A= Type: grandfathered=0A= Tag: no-bok=0A= Description: Norwegian Bokmal=0A= Added: 1995-08-23=0A= Preferred-Value: nb=0A= Deprecated: 2000-02-18=0A= Comments: replaced by ISO code nb=0A= %%=0A= Type: grandfathered=0A= Tag: no-nyn=0A= Description: Norwegian Nynorsk=0A= Added: 1995-08-23=0A= Preferred-Value: nn=0A= Deprecated: 2000-02-18=0A= Comments: replaced by ISO code nn=0A= %%=0A= Type: grandfathered=0A= Tag: sgn-BE-fr=0A= Description: Belgian-French Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: grandfathered=0A= Tag: sgn-BE-nl=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 104]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Belgian-Flemish Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: grandfathered=0A= Tag: sgn-CH-de=0A= Description: Swiss German Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: grandfathered=0A= Tag: zh-cmn=0A= Description: Mandarin Chinese=0A= Added: 2005-07-15=0A= %%=0A= Type: grandfathered=0A= Tag: zh-cmn-Hans=0A= Description: Mandarin Chinese (Simplified)=0A= Added: 2005-07-15=0A= %%=0A= Type: grandfathered=0A= Tag: zh-cmn-Hant=0A= Description: Mandarin Chinese (Traditional)=0A= Added: 2005-07-15=0A= %%=0A= Type: grandfathered=0A= Tag: zh-gan=0A= Description: Kan or Gan=0A= Added: 1999-12-18=0A= %%=0A= Type: grandfathered=0A= Tag: zh-guoyu=0A= Description: Mandarin or Standard Chinese=0A= Added: 1999-12-18=0A= Preferred-Value: zh-cmn=0A= Deprecated: 2005-07-15=0A= %%=0A= Type: grandfathered=0A= Tag: zh-hakka=0A= Description: Hakka=0A= Added: 1999-12-18=0A= %%=0A= Type: grandfathered=0A= Tag: zh-min=0A= Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese=0A= Added: 1999-12-18=0A= %%=0A= Type: grandfathered=0A= Tag: zh-min-nan=0A= Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 105]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Fujian, Hoklo, Southern Fukien, Ho-lo=0A= Added: 2001-03-26=0A= %%=0A= Type: grandfathered=0A= Tag: zh-wuu=0A= Description: Shanghaiese or Wu=0A= Added: 1999-12-18=0A= %%=0A= Type: grandfathered=0A= Tag: zh-xiang=0A= Description: Xiang or Hunanese=0A= Added: 1999-12-18=0A= %%=0A= Type: grandfathered=0A= Tag: zh-yue=0A= Description: Cantonese=0A= Added: 1999-12-18=0A= %%=0A= Type: redundant=0A= Tag: az-Arab=0A= Description: Azerbaijani in Arabic script=0A= Added: 2003-05-30=0A= %%=0A= Type: redundant=0A= Tag: az-Cyrl=0A= Description: Azerbaijani in Cyrillic script=0A= Added: 2003-05-30=0A= %%=0A= Type: redundant=0A= Tag: az-Latn=0A= Description: Azerbaijani in Latin script=0A= Added: 2003-05-30=0A= %%=0A= Type: redundant=0A= Tag: be-Latn=0A= Description: Belarusian in Latin script=0A= Added: 2005-01-06=0A= %%=0A= Type: redundant=0A= Tag: bs-Cyrl=0A= Description: Bosnian in Cyrillic script=0A= Added: 2005-02-17=0A= %%=0A= Type: redundant=0A= Tag: bs-Latn=0A= Description: Bosnian in Latin script=0A= Added: 2005-02-17=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 106]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: redundant=0A= Tag: de-1901=0A= Description: German, traditional orthography=0A= Added: 2001-07-17=0A= %%=0A= Type: redundant=0A= Tag: de-1996=0A= Description: German, orthography of 1996=0A= Added: 2001-07-17=0A= %%=0A= Type: redundant=0A= Tag: de-AT-1901=0A= Description: German, Austrian variant, traditional orthography=0A= Added: 2001-07-17=0A= %%=0A= Type: redundant=0A= Tag: de-AT-1996=0A= Description: German, Austrian variant, orthography of 1996=0A= Added: 2001-07-17=0A= %%=0A= Type: redundant=0A= Tag: de-CH-1901=0A= Description: German, Swiss variant, traditional orthography=0A= Added: 2001-07-17=0A= %%=0A= Type: redundant=0A= Tag: de-CH-1996=0A= Description: German, Swiss variant, orthography of 1996=0A= Added: 2001-07-17=0A= %%=0A= Type: redundant=0A= Tag: de-DE-1901=0A= Description: German, German variant, traditional orthography=0A= Added: 2001-07-17=0A= %%=0A= Type: redundant=0A= Tag: de-DE-1996=0A= Description: German, German variant, orthography of 1996=0A= Added: 2001-07-17=0A= %%=0A= Type: redundant=0A= Tag: es-419=0A= Description: Latin American Spanish=0A= Added: 2005-07-15=0A= %%=0A= Type: redundant=0A= Tag: iu-Cans=0A= Description: Inuktitut in Canadian Aboriginal Syllabic script=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 107]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Added: 2005-02-17=0A= %%=0A= Type: redundant=0A= Tag: iu-Latn=0A= Description: Inuktitut in Latin script=0A= Added: 2005-02-17=0A= %%=0A= Type: redundant=0A= Tag: mn-Cyrl=0A= Description: Mongolian in Cyrillic script=0A= Added: 2005-02-17=0A= %%=0A= Type: redundant=0A= Tag: mn-Mong=0A= Description: Mongolian in Mongolian script=0A= Added: 2005-02-17=0A= %%=0A= Type: redundant=0A= Tag: sgn-BR=0A= Description: Brazilian Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-CO=0A= Description: Colombian Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-DE=0A= Description: German Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-DK=0A= Description: Danish Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-ES=0A= Description: Spanish Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-FR=0A= Description: French Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 108]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Tag: sgn-GB=0A= Description: British Sign Language=0A= Added: 2001-03-02=0A= %%=0A= Type: redundant=0A= Tag: sgn-GR=0A= Description: Greek Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-IE=0A= Description: Irish Sign Language=0A= Added: 2001-03-02=0A= %%=0A= Type: redundant=0A= Tag: sgn-IT=0A= Description: Italian Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-JP=0A= Description: Japanese Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-MX=0A= Description: Mexican Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-NI=0A= Description: Nicaraguan Sign Language=0A= Added: 2001-03-02=0A= %%=0A= Type: redundant=0A= Tag: sgn-NL=0A= Description: Dutch Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-NO=0A= Description: Norwegian Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-PT=0A= Description: Portuguese Sign Language=0A= Added: 2001-11-11=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 109]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= %%=0A= Type: redundant=0A= Tag: sgn-SE=0A= Description: Swedish Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sgn-US=0A= Description: American Sign Language=0A= Added: 2001-03-02=0A= %%=0A= Type: redundant=0A= Tag: sgn-ZA=0A= Description: South African Sign Language=0A= Added: 2001-11-11=0A= %%=0A= Type: redundant=0A= Tag: sl-nedis=0A= Description: Natisone dialect, Nadiza dialect=0A= Added: 2004-06-01=0A= %%=0A= Type: redundant=0A= Tag: sl-rozaj=0A= Description: Resian, Resianic, Rezijan=0A= Added: 2003-10-09=0A= %%=0A= Type: redundant=0A= Tag: sr-Cyrl=0A= Description: Serbian in Cyrillic script=0A= Added: 2003-05-30=0A= %%=0A= Type: redundant=0A= Tag: sr-Latn=0A= Description: Serbian in Latin script=0A= Added: 2003-05-30=0A= %%=0A= Type: redundant=0A= Tag: tg-Arab=0A= Description: Tajik in Arabic script=0A= Added: 2005-02-17=0A= %%=0A= Type: redundant=0A= Tag: tg-Cyrl=0A= Description: Tajik in Cyrillic script=0A= Added: 2005-02-17=0A= %%=0A= Type: redundant=0A= Tag: uz-Cyrl=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 110]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Description: Uzbek in Cyrillic script=0A= Added: 2003-05-30=0A= %%=0A= Type: redundant=0A= Tag: uz-Latn=0A= Description: Uzbek in Latin script=0A= Added: 2003-05-30=0A= %%=0A= Type: redundant=0A= Tag: yi-latn=0A= Description: Yiddish, in Latin script=0A= Added: 2003-01-07=0A= %%=0A= Type: redundant=0A= Tag: zh-Hans=0A= Description: simplified Chinese=0A= Added: 2003-05-30=0A= %%=0A= Type: redundant=0A= Tag: zh-Hans-CN=0A= Description: PRC Mainland Chinese in simplified script=0A= Added: 2005-04-13=0A= %%=0A= Type: redundant=0A= Tag: zh-Hans-HK=0A= Description: Hong Kong Chinese in simplified script=0A= Added: 2005-04-11=0A= %%=0A= Type: redundant=0A= Tag: zh-Hans-MO=0A= Description: Macao Chinese in simplified script=0A= Added: 2005-04-11=0A= %%=0A= Type: redundant=0A= Tag: zh-Hans-SG=0A= Description: Singapore Chinese in simplified script=0A= Added: 2005-04-11=0A= %%=0A= Type: redundant=0A= Tag: zh-Hans-TW=0A= Description: Taiwan Chinese in simplified script=0A= Added: 2005-04-11=0A= %%=0A= Type: redundant=0A= Tag: zh-Hant=0A= Description: traditional Chinese=0A= Added: 2003-05-30=0A= %%=0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 111]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Type: redundant=0A= Tag: zh-Hant-CN=0A= Description: PRC Mainland Chinese in traditional script=0A= Added: 2005-04-13=0A= %%=0A= Type: redundant=0A= Tag: zh-Hant-HK=0A= Description: Hong Kong Chinese in traditional script=0A= Added: 2005-04-11=0A= %%=0A= Type: redundant=0A= Tag: zh-Hant-MO=0A= Description: Macao Chinese in traditional script=0A= Added: 2005-04-11=0A= %%=0A= Type: redundant=0A= Tag: zh-Hant-SG=0A= Description: Singapore Chinese in traditional script=0A= Added: 2005-04-11=0A= %%=0A= Type: redundant=0A= Tag: zh-Hant-TW=0A= Description: Taiwan Chinese in traditional script=0A= Added: 2005-04-11=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 112]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= 4. Omitted Code Elements=0A= =0A= The following code elements from [UN_M.49] were not associated with=0A= [ISO3166-1] alpha-2 code elements. Consequently, they were not=0A= assigned as subtags in the initial Language Subtag Registry, but are=0A= valid candidates for registration as region subtags, using the=0A= process in [I-D.ietf-ltru-registry]:=0A= =0A= 830 Channel Islands=0A= =0A= 831 Guernsey=0A= =0A= 832 Jersey=0A= =0A= 833 Isle of Man=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 113]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= 5. Security Considerations=0A= =0A= This document specifies the initial contents to be used by IANA in=0A= populating the Language Subtag Registry. For security considerations=0A= relevant to that registry and the use of language tags, see=0A= [I-D.ietf-ltru-registry].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 114]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= This document provides the initial content for the Language Subtag=0A= Registry to be maintained by IANA. For details on the procedures for=0A= the format and ongoing maintenance of this registry, see [I-D.ietf-=0A= ltru-registry].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 115]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= 7. References=0A= =0A= 7.1. Normative References=0A= =0A= [I-D.ietf-ltru-registry]=0A= Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying=0A= Languages", September 2005.=0A= =0A= 7.2. Informative References=0A= =0A= [ISO15924]=0A= International Organization for Standardization, "ISO=0A= 15924:2004. Information and documentation -- Codes for=0A= the representation of names of scripts", January 2004.=0A= =0A= [ISO3166-1]=0A= International Organization for Standardization, "ISO 3166:=0A= 1988. Codes for the representation of names of countries,=0A= 3rd edition", August 1988.=0A= =0A= [ISO639-1]=0A= International Organization for Standardization, "ISO 639-=0A= 1:2002. Codes for the representation of names of=0A= languages -- Part 1: Alpha-2 code", 2002.=0A= =0A= [ISO639-2]=0A= International Organization for Standardization, "ISO 639-=0A= 2:1998. Codes for the representation of names of=0A= languages -- Part 2: Alpha-3 code, first edition", 1998.=0A= =0A= [RFC1766] Alvestrand, H., "Tags for the Identification of=0A= Languages", RFC 1766, March 1995.=0A= =0A= [RFC3066] Alvestrand, H., "Tags for the Identification of=0A= Languages", BCP 47, RFC 3066, January 2001.=0A= =0A= [UN_M.49] Statistics Division, United Nations, "Standard Country or=0A= Area Codes for Statistical Use", UN Standard Country or=0A= Area Codes for Statistical Use, Revision 4 (United Nations=0A= publication, Sales No. 98.XVII.9, June 1999.=0A= =0A= [record-jar]=0A= Raymond, E., "The Art of Unix Programming", 2003.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 116]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Author's Address=0A= =0A= Doug Ewell (editor)=0A= =0A= Email: dewell@adelphia.net=0A= URI: http://users.adelphia.net/~dewell=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 117]=0A= =0C=0A= Internet-Draft Initial Language Subtag Registry September 2005=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2005). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Ewell Expires March 28, 2006 [Page 118]=0A= =0C=0A= =0A= ------=_NextPart_000_00BA_01C5C15C.5A720120 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_00BA_01C5C15C.5A720120-- From ltru-bounces@ietf.org Sun Sep 25 06:02:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJTKk-0000Tg-0X; Sun, 25 Sep 2005 06:02:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJTKg-0000Rw-LW for ltru@megatron.ietf.org; Sun, 25 Sep 2005 06:02:08 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02904 for ; Sun, 25 Sep 2005 06:02:03 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EJTJJ-0006oc-SR for ltru@lists.ietf.org; Sun, 25 Sep 2005 12:00:41 +0200 Received: from c-134-88-52.hh.dial.de.ignite.net ([62.134.88.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Sep 2005 12:00:41 +0200 Received: from nobody by c-134-88-52.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Sep 2005 12:00:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 25 Sep 2005 11:58:37 +0200 Organization: Lines: 27 Message-ID: <433674CC.78BC@xyzzy.claranet.de> References: <20050922160912.KKYO5972.edge6.adelphia.net@megatron.ietf.org> <006101c5c178$904c8f60$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-52.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: record jar reference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I had hoped things would quiet down in the source standards > while we were finishing this off, but noooo. Murphy. If Addison adds... ...between and in AUTH48 you could copy the complete resulting [record-jar] reference from the source: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-13.xml The part... ...worked as expected in draft 13, and amazon confirms that it is correct - their form wants it of course without 'urn:isbn:'. I'd still like a real registry URL in the stub chapter 3 later in AUTH48, and the RFC editor is also the right place to get a "no" for this plan - generally they hate URLs, but maybe they would accept an IANA registry URL. If not asking cannot hurt, the text is complete and fine as it is (for date B 2005-09-24). Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 25 06:08:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJTQQ-0001Il-3S; Sun, 25 Sep 2005 06:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJTQK-0001Cm-Aw for ltru@megatron.ietf.org; Sun, 25 Sep 2005 06:08:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03070 for ; Sun, 25 Sep 2005 06:07:53 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJTX9-0001XA-41 for ltru@ietf.org; Sun, 25 Sep 2005 06:14:59 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1EJTQ9-000NrI-0B; Sun, 25 Sep 2005 06:07:45 -0400 Date: Sun, 25 Sep 2005 06:07:41 -0400 From: John C Klensin To: Addison Phillips , Doug Ewell , LTRU Working Group Subject: RE: [Ltru] Re: Note to RFC editor in initial registry Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org For the record, this works for me too. The attempt to specify how the initial registry could be reconstructed was only on the basis that one might want to have that if the original intention was to publish the list as an RFC. If you didn't intend that, or don't think it desirable, then fine -- I really have no position on that subject. john --On Saturday, September 24, 2005 18:55 -0700 Addison Phillips wrote: > Sounds fine to me. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > >> -----Original Message----- >> From: Doug Ewell [mailto:dewell@adelphia.net] >> Sent: samedi 24 septembre 2005 18:44 >> To: LTRU Working Group >> Cc: Addison Phillips; John C Klensin >> Subject: Re: [Ltru] Re: Note to RFC editor in initial registry >> >> Addison Phillips >> wrote: >> >> > In any case, you don't need to adopt John Klensin's exact >> > words. It seems to me that he was unaware of some of the >> > details of registration and proposed text that seemed >> > fitting. I would suggest that you just modify the proposed >> > wording and we move along. How about: >> > >> > -- >> > 3. The initial set of subtags in the registry, which were >> > specified by this document, are those records in the IANA >> > registry [IANA- registry] with "Added" field-values before >> > 2005-07-11. Note that [ltru-registry, Section 3.1] >> > requires that an "Added" field appear in each registration >> > record and that Section 3.3(1) specifies that field must >> > not be changed after registration. (Other fields in these >> > records may have been modified at a later date, subject to >> > the restrictions in Section 3.4 of [ltru-registry].) >> > -- >> > >> > NB> the date 2005-07-11 is "Date B + 1" >> >> That's OK with me, except I'm still worried about explicitly >> specifying the date. That gives us (or the RFC Editor) one >> more opportunity to forget to update "all" the dates. How >> about: >> >> ... with "Added" field values no later than the date of >> publication of this document. >> >> This assumes that the File-Date and Added dates for subtags >> (not grandfathered or redundant tags) in the initial >> registry, the date of publication of draft-initial, and the >> date of publication of draft-registry are all the same. I >> think we have been making that assumption all along, and need >> to be able to rely on it. >> >> I would also remove the parentheses from the last sentence, >> to avoid de-emphasizing it -- because I think it is important >> -- and append something like: >> >> Because of this, it may not be possible to use a future >> version of the Language Subtag Registry to reconstruct an >> exact copy of the initial registry contents. >> >> Comments? >> >> -- >> Doug Ewell >> Fullerton, California >> http://users.adelphia.net/~dewell/ >> > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 25 12:44:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJZY9-0004h2-Cc; Sun, 25 Sep 2005 12:40:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJZXZ-0003J1-4i for ltru@megatron.ietf.org; Sun, 25 Sep 2005 12:39:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15056 for ; Sun, 25 Sep 2005 11:03:07 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJY8q-0007nI-Ds for ltru@ietf.org; Sun, 25 Sep 2005 11:10:15 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j8PF2ku7028505; Sun, 25 Sep 2005 08:02:46 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 25 Sep 2005 08:03:18 -0700 Message-ID: From: "McDonald, Ira" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: record jar reference Date: Sun, 25 Sep 2005 08:03:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org]On Behalf Of > Frank Ellermann > Sent: Sunday, September 25, 2005 5:59 AM > To: ltru@ietf.org > Subject: [Ltru] Re: record jar reference > > > > I'd still like a real registry URL in the stub chapter 3 later > in AUTH48, and the RFC editor is also the right place to get a > "no" for this plan - generally they hate URLs, but maybe they > would accept an IANA registry URL. If not asking cannot hurt, > the text is complete and fine as it is (for date B 2005-09-24). > > Bye, Frank There's plenty of precedent for the RFC Editor to publish real URLs in RFCs. For example, the Printer MIB v2 (RFC 3805) and Finisher MIB (RFC 3806) were published with the real IANA registry URLs (for their textual convention IANA MIBs) in their RFCs. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 25 14:23:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJb9d-0001py-RM; Sun, 25 Sep 2005 14:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJb8y-0001lc-N7 for ltru@megatron.ietf.org; Sun, 25 Sep 2005 14:23:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23922 for ; Sun, 25 Sep 2005 14:22:13 -0400 (EDT) Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJbFY-0004Im-4r for ltru@ietf.org; Sun, 25 Sep 2005 14:29:22 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8PIKl40016032 for ; Sun, 25 Sep 2005 14:20:47 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8PIMUHF478198 for ; Sun, 25 Sep 2005 12:22:30 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j8PILsUT001758 for ; Sun, 25 Sep 2005 12:21:54 -0600 Received: from [127.0.0.1] (sig-9-48-127-26.mts.ibm.com [9.48.127.26]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j8PILrpo001728; Sun, 25 Sep 2005 12:21:54 -0600 Message-ID: <4336EABF.9070905@icu-project.org> Date: Sun, 25 Sep 2005 11:21:51 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: Note to RFC editor in initial registry References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: John C Klensin , Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Me too. Addison Phillips wrote: > Sounds fine to me. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > >>-----Original Message----- >>From: Doug Ewell [mailto:dewell@adelphia.net] >>Sent: samedi 24 septembre 2005 18:44 >>To: LTRU Working Group >>Cc: Addison Phillips; John C Klensin >>Subject: Re: [Ltru] Re: Note to RFC editor in initial registry >> >>Addison Phillips wrote: >> >> >>>In any case, you don't need to adopt John Klensin's exact words. It >>>seems to me that he was unaware of some of the details of registration >>>and proposed text that seemed fitting. I would suggest that you just >>>modify the proposed wording and we move along. How about: >>> >>>-- >>>3. The initial set of subtags in the registry, which were specified >>>by this document, are those records in the IANA registry [IANA- >>>registry] with "Added" field-values before 2005-07-11. Note that >>>[ltru-registry, Section 3.1] requires that an "Added" field appear in >>>each registration record and that Section 3.3(1) specifies that field >>>must not be changed after registration. (Other fields in these records >>>may have been modified at a later date, subject to the restrictions in >>>Section 3.4 of [ltru-registry].) >>>-- >>> >>>NB> the date 2005-07-11 is "Date B + 1" >> >>That's OK with me, except I'm still worried about explicitly specifying >>the date. That gives us (or the RFC Editor) one more opportunity to >>forget to update "all" the dates. How about: >> >> ... with "Added" field values no later than the date of publication >> of this document. >> >>This assumes that the File-Date and Added dates for subtags (not >>grandfathered or redundant tags) in the initial registry, the date of >>publication of draft-initial, and the date of publication of >>draft-registry are all the same. I think we have been making that >>assumption all along, and need to be able to rely on it. >> >>I would also remove the parentheses from the last sentence, to avoid >>de-emphasizing it -- because I think it is important -- and append >>something like: >> >> Because of this, it may not be possible to use a future version of >> the Language Subtag Registry to reconstruct an exact copy of the >> initial registry contents. >> >>Comments? >> >>-- >>Doug Ewell >>Fullerton, California >>http://users.adelphia.net/~dewell/ >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Sep 25 15:47:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJcTX-0003Zr-TI; Sun, 25 Sep 2005 15:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJcTD-0003WP-Hz for ltru@megatron.ietf.org; Sun, 25 Sep 2005 15:47:51 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29356 for ; Sun, 25 Sep 2005 15:46:36 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EJcR1-0007xc-Qq for ltru@lists.ietf.org; Sun, 25 Sep 2005 21:45:15 +0200 Received: from c-134-88-52.hh.dial.de.ignite.net ([62.134.88.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Sep 2005 21:45:15 +0200 Received: from nobody by c-134-88-52.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Sep 2005 21:45:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 25 Sep 2005 21:42:40 +0200 Organization: Lines: 22 Message-ID: <4336FDB0.E6F@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-52.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] registry URL (was: record jar reference) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org McDonald, Ira wrote: > There's plenty of precedent for the RFC Editor to publish > real URLs in RFCs. Yes, they s/hate/discourage/ URLs (2.8 in rfc2223bis -08), because "RfCs never change". A link check for some early RfCs would be messy. Maybe a point (among others) for another "decruft" experiment. > the Printer MIB v2 (RFC 3805) and Finisher MIB (RFC 3806) > were published with the real IANA registry URLs | 10.1. Normative References [...] | [CHARSET] IANA Character Set Registry: | http://www.iana.org/assignments/character-sets Something like that could be nice, but of course not essential. The "user" artwork in its figure 1 is hilarious ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 26 10:50:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuJ5-0007kN-8e; Mon, 26 Sep 2005 10:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuIt-0007fj-9I; Mon, 26 Sep 2005 10:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02094; Mon, 26 Sep 2005 10:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJuPx-0007Kv-2J; Mon, 26 Sep 2005 10:57:21 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EJuIs-0006d7-22; Mon, 26 Sep 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Sep 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-initial-05.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Initial Language Subtag Registry Author(s) : D. Ewell Filename : draft-ietf-ltru-initial-05.txt Pages : 118 Date : 2005-9-26 This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-initial-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-initial-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-26095401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-initial-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-initial-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-26095401.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Mon Sep 26 12:26:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvob-0007H9-Ue; Mon, 26 Sep 2005 12:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvoZ-0007Gg-BC for ltru@megatron.ietf.org; Mon, 26 Sep 2005 12:26:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22476 for ; Mon, 26 Sep 2005 12:26:48 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJvvd-0007Jd-32 for ltru@ietf.org; Mon, 26 Sep 2005 12:34:10 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 26 Sep 2005 09:26:39 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 09:26:39 -0700 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 Subject: RE: [Ltru] el truth? Date: Mon, 26 Sep 2005 09:26:44 -0700 Message-ID: Thread-Topic: [Ltru] el truth? Thread-Index: AcXAcU3FBT4Yg5fjRY+yrFR1A9GhZQCRM+tw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 26 Sep 2005 16:26:39.0068 (UTC) FILETIME=[123C69C0:01C5C2B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of r&d afrac > Sent: Friday, September 23, 2005 12:01 PM > Offensive? Off-topic? > It seems you really have a problem with networked language > understanding and multicultural real world! > That kind of comment identify the author .... > Please indicate your langtag for that file. That file has two streams of linguistic content, each of which could be tagged: "fr" for one, "en" for the other. The file as a whole contains content in two languages, and would face no greater issue for tagging than any other bilingual document. In principle, a server might be able to return this content in response to a request for either "en" or "fr". If a user wishes to request specifically *audio* that is in French, then the protocol for content negotiation would need to distinguish between modalities for which linguistic attributes are specified. There is no difficulty whatsoever creating language tags appropriate for this file. The only issues have to do with the metadata categories used for content in a given application context and negotiation mechanisms that make reference to those categories -- all of which is beyond the scope of the current projects of this WG. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 26 14:21:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJxbl-0006eO-5y; Mon, 26 Sep 2005 14:21:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJxbj-0006eG-FJ for ltru@megatron.ietf.org; Mon, 26 Sep 2005 14:21:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28017 for ; Mon, 26 Sep 2005 14:21:42 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJxin-0001pr-Ic for ltru@ietf.org; Mon, 26 Sep 2005 14:29:03 -0400 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EJxbV-0000tm-ME; Mon, 26 Sep 2005 11:21:30 -0700 Message-Id: <6.2.3.4.2.20050926194043.050a20e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 26 Sep 2005 19:51:18 +0200 To: "Peter Constable" , "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] el truth? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Dear Peter, thank you for your ... lack of response: At 18:26 26/09/2005, Peter Constable wrote: >There is no difficulty whatsoever creating language tags appropriate for >this file. The only issues have to do with the metadata categories used >for content in a given application context and negotiation mechanisms >that make reference to those categories -- all of which is beyond the >scope of the current projects of this WG. please be _specific_. There is a file. There is a tagging to associate. This file is signed by a French prestigious language school and has be prepared by students from the quoted countries, let assume it is intended for their fellow students. What IS the full tagging to associate to this file? This file is touring the world right now as people love it. This is a unique occasion to clarify your proposition: I will give your tagging and ours so people can understand the difference (our will probably be didactic and something like 0-langroot.org:fraparfun, once the site has started - but the DRS will take time to be specified and deploy). jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 26 15:47:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJywp-0004Hz-Ug; Mon, 26 Sep 2005 15:47:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJywo-0004Ha-9y for ltru@megatron.ietf.org; Mon, 26 Sep 2005 15:47:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05630 for ; Mon, 26 Sep 2005 15:47:32 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-res.bigfish.com ([63.161.60.61] helo=mail4-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJz3u-0004om-Tu for ltru@ietf.org; Mon, 26 Sep 2005 15:54:55 -0400 Received: from mail4-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail4-res-R.bigfish.com (Postfix) with ESMTP id 423015308AF; Mon, 26 Sep 2005 19:47:20 +0000 (UTC) X-BigFish: VP Received: by mail4-res (MessageSwitch) id 1127764040154802_30134; Mon, 26 Sep 2005 19:47:20 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail4-res.bigfish.com (Postfix) with ESMTP id E8F6253080B; Mon, 26 Sep 2005 19:47:19 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005092612392302:38403 ; Mon, 26 Sep 2005 12:39:23 -0700 To: "Peter Constable" Subject: RE: [Ltru] el truth? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Mon, 26 Sep 2005 12:30:15 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 09/26/2005 12:30:16, Serialize complete at 09/26/2005 12:30:16, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 09/26/2005 12:39:23 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 09/26/2005 12:56:21 PM, Serialize complete at 09/26/2005 12:56:21 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2039443673==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============2039443673== Content-Type: multipart/alternative; boundary="=_alternative 006B257588257088_=" This is a multipart message in MIME format. --=_alternative 006B257588257088_= Content-Type: text/plain; charset="us-ascii" This is exactly how we would classify the file at Sony Pictures. No problem. We specify acceptable audio and text languages in our metadata standard -- this is somewhat specific to our own business needs -- and allow multiple selections for any given title or product. Our DVDs have multiple language tracks (subtitled/dubbed localizations and the original spoken language) and Digital Cinema will increasingly allow this in film. Some films are also in multiple languages in their original versions. Sometimes the beginning title sequences or end credits remain in the original language while the rest of the film is localized. We track it all. Just because the spoken and written attributes are not in RFC 3066, doesn't mean we can't use this as a standard today. In fact, the film and television standards we must comply with track spoken and written languages as separate elements so I'm not sure we'd even want this attribute in our codes. We do set a rule that script types should never be used with dubbed content, but that seems fairly obvious. We also allow for the "spoken" language "silent" to be combined with a text language of, say, French for title cards in silent films. (We are implementing an industry-specific custom tag, xsi, for now and are working with the MPA to standardize on that within the industry.) I would argue that the "en" is "en-FR" because the "e" in English is not capitalized. ;) I also agree that the file sent was offensive and xenophobic. Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Peter Constable" Sent by: ltru-bounces@ietf.org 09/26/2005 09:26 AM To: "LTRU Working Group" cc: Subject: RE: [Ltru] el truth? > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of r&d afrac > Sent: Friday, September 23, 2005 12:01 PM > Offensive? Off-topic? > It seems you really have a problem with networked language > understanding and multicultural real world! > That kind of comment identify the author .... > Please indicate your langtag for that file. That file has two streams of linguistic content, each of which could be tagged: "fr" for one, "en" for the other. The file as a whole contains content in two languages, and would face no greater issue for tagging than any other bilingual document. In principle, a server might be able to return this content in response to a request for either "en" or "fr". If a user wishes to request specifically *audio* that is in French, then the protocol for content negotiation would need to distinguish between modalities for which linguistic attributes are specified. There is no difficulty whatsoever creating language tags appropriate for this file. The only issues have to do with the metadata categories used for content in a given application context and negotiation mechanisms that make reference to those categories -- all of which is beyond the scope of the current projects of this WG. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 006B257588257088_= Content-Type: text/html; charset="us-ascii"
This is exactly how we would classify the file at Sony Pictures. No problem. We specify acceptable audio and text languages in our metadata standard -- this is somewhat specific to our own business needs -- and allow multiple selections for any given title or product. Our DVDs have multiple language tracks (subtitled/dubbed localizations and the original spoken language) and Digital Cinema will increasingly allow this in film.

Some films are also in multiple languages in their original versions. Sometimes the beginning title sequences or end credits remain in the original language while the rest of the film is localized. We track it all. Just because the spoken and written attributes are not in RFC 3066, doesn't mean we can't use this as a standard today.  In fact, the film and television standards we must comply with track spoken and written languages as separate elements so I'm not sure we'd even want this attribute in our codes. We do set a rule that script types should never be used with dubbed content, but that seems fairly obvious.

We also allow for the "spoken" language "silent" to be combined with a text language of, say, French for title cards in silent films. (We are implementing an industry-specific custom tag, xsi, for now and are working with the MPA to standardize on that within the industry.)

I would argue that the "en" is "en-FR" because the "e" in English is not capitalized.  ;) I also agree that the file sent was offensive and xenophobic.

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384



"Peter Constable" <petercon@microsoft.com>
Sent by: ltru-bounces@ietf.org

09/26/2005 09:26 AM

       
        To:        "LTRU Working Group" <ltru@ietf.org>
        cc:        
        Subject:        RE: [Ltru] el truth?



> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf
Of r&d afrac
> Sent: Friday, September 23, 2005 12:01 PM

> Offensive? Off-topic?
> It seems you really have a problem with networked language
> understanding and multicultural real world!
> That kind of comment identify the author ....
> Please indicate your langtag for that file.

That file has two streams of linguistic content, each of which could be
tagged: "fr" for one, "en" for the other. The file as a whole contains
content in two languages, and would face no greater issue for tagging
than any other bilingual document. In principle, a server might be able
to return this content in response to a request for either "en" or "fr".
If a user wishes to request specifically *audio* that is in French, then
the protocol for content negotiation would need to distinguish between
modalities for which linguistic attributes are specified.

There is no difficulty whatsoever creating language tags appropriate for
this file. The only issues have to do with the metadata categories used
for content in a given application context and negotiation mechanisms
that make reference to those categories -- all of which is beyond the
scope of the current projects of this WG.



Peter Constable

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

--=_alternative 006B257588257088_=-- --===============2039443673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2039443673==-- From ltru-bounces@ietf.org Mon Sep 26 16:02:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJzB9-0006xF-9W; Mon, 26 Sep 2005 16:02:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJzB8-0006xA-0E for ltru@megatron.ietf.org; Mon, 26 Sep 2005 16:02:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06453 for ; Mon, 26 Sep 2005 16:02:18 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJzIB-0005PW-UB for ltru@ietf.org; Mon, 26 Sep 2005 16:09:41 -0400 Received: from h-64-105-136-20.snvacaid.dynamic.covad.net ([64.105.136.20] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EJzAw-0005Ag-00 for ltru@ietf.org; Mon, 26 Sep 2005 16:02:11 -0400 Message-ID: <001801c5c2d5$94afd0e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.3.4.2.20050926194043.050a20e0@mail.afrac.org> Date: Mon, 26 Sep 2005 13:05:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Ltru] Public RFC 3934 warning to Jefsey X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Jefsey - The ltru working group already reached a consensus on issue #1127, on the tagging of multilingual content. Peter is correct that negotiation mechanisms are beyond the scope of this working group, as are the choices made by specific protocols or file formats for the association of language tags with content. >From an off-list discussion, I know that you've already been given an example of how one protocol would tag that video. Martin wrote in response to your off-list question: | Even more, some protocols (such as HTTP used to serve the | video in question) can easily carry more than one language. | In the specific case in question, it could have come | served with | | Content-Type: video/mpeg | Content-Language: fr, en Rehashing a closed issue, particularly on a document which has already finished IETF last call, without the introduction of substantively new rationale or operational experience, is, in the judgment of this co-chair, disruptive behaviour per RFC 3934. Such behaviour wastes the working group's time, which would be better spent on completing the matching draft. If you persist in this or other disruptive behaviour on the ltru working group mailing list, your posting privileges to ltru@ietf.org will be suspended for a period of 30 days. Randy, ltru co-chair > From: "r&d afrac" > To: "Peter Constable" ; "LTRU Working Group" > Sent: Monday, September 26, 2005 10:51 AM > Subject: RE: [Ltru] el truth? > > Dear Peter, > thank you for your ... lack of response: > > At 18:26 26/09/2005, Peter Constable wrote: > >There is no difficulty whatsoever creating language tags appropriate for > >this file. The only issues have to do with the metadata categories used > >for content in a given application context and negotiation mechanisms > >that make reference to those categories -- all of which is beyond the > >scope of the current projects of this WG. > > please be _specific_. > > There is a file. There is a tagging to associate. This file is signed > by a French prestigious language school and has be prepared by > students from the quoted countries, let assume it is intended for > their fellow students. > > What IS the full tagging to associate to this file? > > This file is touring the world right now as people love it. This is a > unique occasion to clarify your proposition: I will give your tagging > and ours so people can understand the difference (our will probably > be didactic and something like 0-langroot.org:fraparfun, once the > site has started - but the DRS will take time to be specified and deploy). > jfc > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 26 16:23:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJzW2-0004Bc-Vk; Mon, 26 Sep 2005 16:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJzW1-0004BX-VC for ltru@megatron.ietf.org; Mon, 26 Sep 2005 16:23:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07293 for ; Mon, 26 Sep 2005 16:23:56 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJzd7-0005uz-9j for ltru@ietf.org; Mon, 26 Sep 2005 16:31:19 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8QKNd1C029053; Mon, 26 Sep 2005 16:23:40 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 26 Sep 2005 16:23:39 -0400 Date: Mon, 26 Sep 2005 16:23:39 -0400 From: "John.Cowan" To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] el truth? Message-ID: <20050926202338.GB19052@NYCMJCOWA2> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > We also allow for the "spoken" language "silent" to be combined with a > text language of, say, French for title cards in silent films. (We are > implementing an industry-specific custom tag, xsi, for now and are working > with the MPA to standardize on that within the industry.) Please don't use "xsi" for this purpose: play by the rules and use "x-silent". In the ISO 639-3 and RFC 3066ter regime, we will be using "xsi" for Sio, a minority language of Papua New Guinea. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 26 17:27:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK0VB-00014y-Rw; Mon, 26 Sep 2005 17:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK0V9-00014m-B6 for ltru@megatron.ietf.org; Mon, 26 Sep 2005 17:27:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10462 for ; Mon, 26 Sep 2005 17:27:04 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-haw.bigfish.com ([12.129.199.61] helo=mail13-haw-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK0cE-0007Ve-H9 for ltru@ietf.org; Mon, 26 Sep 2005 17:34:29 -0400 Received: from mail13-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail13-haw-R.bigfish.com (Postfix) with ESMTP id 27BD43E1816; Mon, 26 Sep 2005 21:26:55 +0000 (UTC) X-BigFish: VP Received: by mail13-haw (MessageSwitch) id 1127770014979630_20043; Mon, 26 Sep 2005 21:26:54 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail13-haw.bigfish.com (Postfix) with ESMTP id A03133E20CE; Mon, 26 Sep 2005 21:26:54 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005092614291005:42843 ; Mon, 26 Sep 2005 14:29:10 -0700 To: "John.Cowan" , "LTRU Working Group" Subject: Re: [Ltru] el truth? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Mon, 26 Sep 2005 14:20:02 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 09/26/2005 14:20:03, Serialize complete at 09/26/2005 14:20:03, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 09/26/2005 02:29:10 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 09/26/2005 02:35:56 PM, Serialize complete at 09/26/2005 02:35:56 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1794992722==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1794992722== Content-Type: multipart/alternative; boundary="=_alternative 0075327388257088_=" This is a multipart message in MIME format. --=_alternative 0075327388257088_= Content-Type: text/plain; charset="us-ascii" I have notified the MPA and others that use of this tag is not acceptable. Thanks, John. - Karen "John.Cowan" Sent by: ltru-bounces@ietf.org 09/26/2005 01:23 PM To: Karen_Broome@spe.sony.com cc: LTRU Working Group Subject: Re: [Ltru] el truth? Karen_Broome@spe.sony.com scripsit: > We also allow for the "spoken" language "silent" to be combined with a > text language of, say, French for title cards in silent films. (We are > implementing an industry-specific custom tag, xsi, for now and are working > with the MPA to standardize on that within the industry.) Please don't use "xsi" for this purpose: play by the rules and use "x-silent". In the ISO 639-3 and RFC 3066ter regime, we will be using "xsi" for Sio, a minority language of Papua New Guinea. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 0075327388257088_= Content-Type: text/html; charset="us-ascii"
I have notified the MPA and others that use of this tag is not acceptable. Thanks, John.

- Karen



"John.Cowan" <jcowan@reutershealth.com>
Sent by: ltru-bounces@ietf.org

09/26/2005 01:23 PM

       
        To:        Karen_Broome@spe.sony.com
        cc:        LTRU Working Group <ltru@ietf.org>
        Subject:        Re: [Ltru] el truth?



Karen_Broome@spe.sony.com scripsit:

> We also allow for the "spoken" language "silent" to be combined with a
> text language of, say, French for title cards in silent films. (We are
> implementing an industry-specific custom tag, xsi, for now and are working
> with the MPA to standardize on that within the industry.)

Please don't use "xsi" for this purpose: play by the rules and use "x-silent".
In the ISO 639-3 and RFC 3066ter regime, we will be using "xsi" for Sio, a
minority language of Papua New Guinea.

--
John Cowan  jcowan@reutershealth.com  www.reutershealth.com  www.ccil.org/~cowan
Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."

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

--=_alternative 0075327388257088_=-- --===============1794992722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1794992722==-- From ltru-bounces@ietf.org Mon Sep 26 19:31:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK2Rw-0005JS-CK; Mon, 26 Sep 2005 19:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK2Rv-0005JC-GR for ltru@megatron.ietf.org; Mon, 26 Sep 2005 19:31:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18652 for ; Mon, 26 Sep 2005 19:31:52 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK2Z4-0002UX-9Y for ltru@ietf.org; Mon, 26 Sep 2005 19:39:18 -0400 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EK2Rp-00033Q-4A; Mon, 26 Sep 2005 16:31:49 -0700 Message-Id: <6.2.3.4.2.20050927005751.036cfd60@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 27 Sep 2005 01:00:53 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Public RFC 3934 warning to Jefsey In-Reply-To: <001801c5c2d5$94afd0e0$7f1afea9@oemcomputer> References: <6.2.3.4.2.20050926194043.050a20e0@mail.afrac.org> <001801c5c2d5$94afd0e0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 22:05 26/09/2005, Randy Presuhn wrote: >Hi Jefsey - >Peter is correct that negotiation mechanisms are beyond the scope of >this working group, Thank you for saying it. Full support. jfc At 18:08 27/08/2005, Addison Phillips wrote: >No, this is called "language negotiation according to user >preferences". It is what the "q" weights in Accept-Language are for, >for example. > >There are some different examples of how this could be useful. > >Case #1: Consider a user who speaks both Slovenian and Italian who >subscribes to an RSS news feed. RSS indicates the language of an >article using a language tag. If the user instructs her newsreader >to filter the articles in the news feed, she might use this >Accept-Language setting: > >sl;q=1.0,it;q=0.8,sl-rozaj;q=0.0 > >The lowest distance metric value for each article (when comparing to >each range in succession) is the weight for the article as a whole. >That weight can be divided by the q weight associated with that >range to produce the "final score". When the articles are ordered by >score, this produces a list in which Slovenian articles always >appear before Italian articles on each "level" of matching, but in >which articles in the Resian dialect ("sl-rozaj") never appear >(score is "infinity" essentially, since divide by zero is an error) >or at least appear at the very end. > >Case #2: Consider a news feed from Japan. A friend tells me that an >interesting English language article appeared in this particular >news feed, but can't remember exactly when or what it was called. I >can set "ja;q=0.0" to filter out all the Japanese (presumably the >majority of the news feed), making the article easier to find. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 26 19:32:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK2S0-0005Jz-Ke; Mon, 26 Sep 2005 19:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK2Rw-0005JT-DU for ltru@megatron.ietf.org; Mon, 26 Sep 2005 19:31:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18655 for ; Mon, 26 Sep 2005 19:31:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK2Z4-0002Ud-9c for ltru@ietf.org; Mon, 26 Sep 2005 19:39:19 -0400 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EK2Rr-00033Q-7b; Mon, 26 Sep 2005 16:31:51 -0700 Message-Id: <6.2.3.4.2.20050927011032.04686eb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 27 Sep 2005 01:20:37 +0200 To: "John.Cowan" , Karen_Broome@spe.sony.com From: r&d afrac Subject: Re: [Ltru] el truth? In-Reply-To: <20050926202338.GB19052@NYCMJCOWA2> References: <20050926202338.GB19052@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 22:23 26/09/2005, John.Cowan wrote: >Karen_Broome@spe.sony.com scripsit: > > We also allow for the "spoken" language "silent" to be combined with a > > text language of, say, French for title cards in silent films. (We are > > implementing an industry-specific custom tag, xsi, for now and are working > > with the MPA to standardize on that within the industry. >Please don't use "xsi" for this purpose: play by the rules and use "x-silent". I am not sure you can do that. From what Lee documented and I accepted, this could be done in a private space (like an intranet or a VPN). Here you talk of an Industry standard. This is exactly the case URI-tags RFC will document as "mpa.org:silent". >In the ISO 639-3 and RFC 3066ter regime, we will be using "xsi" for >Sio, a minority language of Papua New Guinea. Languages are in first position. Silent is modal. This is not because you are silent that you cannot read, listen or think? Think for example to a rebus. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Sep 26 22:42:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK5Qm-0004aI-Ja; Mon, 26 Sep 2005 22:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK5Qk-0004Zt-NF for ltru@megatron.ietf.org; Mon, 26 Sep 2005 22:42:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26548 for ; Mon, 26 Sep 2005 22:42:51 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK5Xs-0006j0-C1 for ltru@ietf.org; Mon, 26 Sep 2005 22:50:17 -0400 Received: from h-64-105-136-20.snvacaid.dynamic.covad.net ([64.105.136.20] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EK5Qf-0005zS-00 for ltru@ietf.org; Mon, 26 Sep 2005 22:42:49 -0400 Message-ID: <003e01c5c30d$8fb62fc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.3.4.2.20050926194043.050a20e0@mail.afrac.org> <001801c5c2d5$94afd0e0$7f1afea9@oemcomputer> <6.2.3.4.2.20050927005751.036cfd60@mail.afrac.org> Subject: Re: [Ltru] Public RFC 3934 warning to Jefsey Date: Mon, 26 Sep 2005 19:45:45 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "r&d afrac" > To: "Randy Presuhn" ; "LTRU Working Group" > Cc: "Scott Hollenbeck" > Sent: Monday, September 26, 2005 4:00 PM > Subject: Re: [Ltru] Public RFC 3934 warning to Jefsey > > At 22:05 26/09/2005, Randy Presuhn wrote: > >Hi Jefsey - > >Peter is correct that negotiation mechanisms are beyond the scope of > >this working group, > > Thank you for saying it. Full support. > jfc Why the quote from Addison? He wasn't writing about negotiation mechanisms. He was explaining why a particular type of matching algorithm is useful in support of negotiation mechanisms. Providing use cases for matching algorithms (clearly within our scope) is quite a different matter from specifying negotiation mechanisms. If I were feeling less charitable, I'd cite this as yet another case of misrepresenting WG members' positions. > At 18:08 27/08/2005, Addison Phillips wrote: > >No, this is called "language negotiation according to user > >preferences". It is what the "q" weights in Accept-Language are for, > >for example. > > > >There are some different examples of how this could be useful. ... Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 00:13:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK6pK-0005CJ-95; Tue, 27 Sep 2005 00:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK6pI-0005C9-Nj for ltru@megatron.ietf.org; Tue, 27 Sep 2005 00:12:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29285 for ; Tue, 27 Sep 2005 00:12:18 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK6wT-0008Qb-5q for ltru@ietf.org; Tue, 27 Sep 2005 00:19:46 -0400 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EK6pB-0002iH-Iq; Mon, 26 Sep 2005 21:12:14 -0700 Message-Id: <6.2.3.4.2.20050927055927.0371bc10@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 27 Sep 2005 06:05:36 +0200 To: "Randy Presuhn" From: r&d afrac Subject: Re: [Ltru] Public RFC 3934 warning to Jefsey In-Reply-To: <003e01c5c30d$8fb62fc0$7f1afea9@oemcomputer> References: <6.2.3.4.2.20050926194043.050a20e0@mail.afrac.org> <001801c5c2d5$94afd0e0$7f1afea9@oemcomputer> <6.2.3.4.2.20050927005751.036cfd60@mail.afrac.org> <003e01c5c30d$8fb62fc0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On 04:45 27/09/2005, Randy Presuhn said: >If I were feeling less charitable, I'd cite this as yet another case of >misrepresenting WG members' positions. Dear Chair, If I were feeling less charitable, I'd cite this as yet another case of misrepresenting a WG member's posts... Providing use cases for matching algorithms (clearly within our scope) is what is my example about. Do take care 8-) jfc > At 18:08 27/08/2005, Addison Phillips wrote: > > >No, this is called "language negotiation according to user > > >preferences". It is what the "q" weights in Accept-Language are for, > > >for example. > > > > > >There are some different examples of how this could be useful. >... > >Randy, ltru co-chair > > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 00:59:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK7Z2-0006kL-E1; Tue, 27 Sep 2005 00:59:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK7Z1-0006hM-36 for ltru@megatron.ietf.org; Tue, 27 Sep 2005 00:59:35 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01006 for ; Tue, 27 Sep 2005 00:59:32 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050927045903.OKKJ27017.mta11.adelphia.net@DEWELL> for ; Tue, 27 Sep 2005 00:59:03 -0400 Message-ID: <001801c5c320$26a14480$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050926213245.ZED2608.edge2.adelphia.net@megatron.ietf.org> Date: Mon, 26 Sep 2005 21:58:49 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Tagging of silent films (was: Re: el truth?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Karen Broome wrote: > Some films are also in multiple languages in their original versions. "The Red Violin" (1999) leaps to mind, with spoken content in de, en, fr, it, and zh-cmn. > We also allow for the "spoken" language "silent" to be combined with a > text language of, say, French for title cards in silent films. (We are > implementing an industry-specific custom tag, xsi, for now and are > working with the MPA to standardize on that within the industry.) As John indicated, "xsi" is not available for private assignment, and in fact is allocated to a "real" language in ISO/DIS 639-3. John's suggestion of "x-silent" would work fine; so would "qsi". In either case, a private (industry-specific) agreement on the meaning of the tag would be in place, so this is an appropriate use case for private-use tagging. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 01:39:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK8BC-000614-Dc; Tue, 27 Sep 2005 01:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK8BA-00060z-82 for ltru@megatron.ietf.org; Tue, 27 Sep 2005 01:39:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02437 for ; Tue, 27 Sep 2005 01:38:59 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK8IL-0001mV-9N for ltru@ietf.org; Tue, 27 Sep 2005 01:46:26 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 22:38:45 -0700 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvmbxw01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Sep 2005 22:38:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Tagging of silent films (was: Re: el truth?) Date: Mon, 26 Sep 2005 22:38:29 -0700 Message-ID: Thread-Topic: [Ltru] Tagging of silent films (was: Re: el truth?) thread-index: AcXDIEkkGVyKmTbfSHyf3/atmQ7R/QABPgmw From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 27 Sep 2005 05:38:44.0517 (UTC) FILETIME=[B99C6D50:01C5C325] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1959049267==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1959049267== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RG91ZyBFd2VsbCB3cm90ZToNCg0KPiBzbyB3b3VsZCAicXNpIg0KDQpUaGUgdXNlIG9mIHByaXZh dGUgdXNlIGNvZGVzIGZyb20gSVNPIDYzOSB3b3VsZCBpbmRlZWQgYmUgYSBnb29kIGNob2ljZSwg ZXNwZWNpYWxseSBpZiBvbmUgd2lzaGVzIHRvIHVzZSBhIGxhbmd1YWdlIHN1YnRhZyBnZW5lcmF0 aXZlbHkgd2l0aCBvdGhlciBzdWJ0YWdzLS1vciB3aXNoZXMgdG8gdXNlIGFuIGV4dGVuc2lvbi4g VGhleSBhcmUgZ3VhcmFudGVlZCBub3QgdG8gY29uZmxpY3Qgd2l0aCBhbnkgb3RoZXIgdmFsdWVz IGFuZCBhcHBlYXIgaW4gdGhlIG5vcm1hbCAibGFuZ3VhZ2UiIGxvY2F0aW9uLS1hbmQgdGhlc2Ug Y29kZXMgd2VyZSBpbmNsdWRlZCBpbiB0aGUgcmVnaXN0cnkgZm9yIHByZWNpc2VseSB0aGlzIHB1 cnBvc2UuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBB cmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9u IENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0 dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0K --===============1959049267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1959049267==-- From ltru-bounces@ietf.org Tue Sep 27 07:01:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDD7-0007C4-NV; Tue, 27 Sep 2005 07:01:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDD6-0007Bz-5K for ltru@megatron.ietf.org; Tue, 27 Sep 2005 07:01:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29167 for ; Tue, 27 Sep 2005 07:01:17 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKDKL-0001CT-3j for ltru@ietf.org; Tue, 27 Sep 2005 07:08:49 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3668A258067; Tue, 27 Sep 2005 13:00:46 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21920-05; Tue, 27 Sep 2005 13:00:33 +0200 (CEST) Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DDB6258066; Tue, 27 Sep 2005 13:00:31 +0200 (CEST) Date: Tue, 27 Sep 2005 13:01:04 +0200 From: Harald Tveit Alvestrand To: Addison Phillips , Doug Ewell , LTRU Working Group Subject: RE: [Ltru] Tagging of silent films (was: Re: el truth?) Message-ID: <25886F4A2C6C547489B77F58@gloppen.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On mandag, september 26, 2005 22:38:29 -0700 Addison Phillips wrote: > Doug Ewell wrote: > >> so would "qsi" > > The use of private use codes from ISO 639 would indeed be a good choice, > especially if one wishes to use a language subtag generatively with other > subtags--or wishes to use an extension. They are guaranteed not to > conflict with any other values and appear in the normal "language" > location--and these codes were included in the registry for precisely > this purpose. However, they ARE guaranteed to conflict with other private use of those codes. Don't standardize private-use codes - not even in an "industry-wide agreement". It hurts. i-silent is no longer available for public registration, methinks. und-silent would be a valid code, if "silent" is registered as a variant subtag with "und" as its prefix. Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 07:18:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDTR-0002UR-KW; Tue, 27 Sep 2005 07:18:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDTP-0002UJ-Lh for ltru@megatron.ietf.org; Tue, 27 Sep 2005 07:18:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00079 for ; Tue, 27 Sep 2005 07:18:11 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKDaa-0001gK-SG for ltru@ietf.org; Tue, 27 Sep 2005 07:25:38 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EKDTG-0003PJ-5V; Tue, 27 Sep 2005 04:18:02 -0700 Message-Id: <6.2.3.4.2.20050927130544.04c07220@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 27 Sep 2005 13:17:18 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Tagging of silent films (was: Re: el truth?) In-Reply-To: <001801c5c320$26a14480$030aa8c0@DEWELL> References: <20050926213245.ZED2608.edge2.adelphia.net@megatron.ietf.org> <001801c5c320$26a14480$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 06:58 27/09/2005, Doug Ewell wrote: >John's suggestion of "x-silent" would work fine; so would "qsi". Is this a consensus of this WG that the RFC 3066 bis is to be read in the following way: 1. "x-silent" can be specified in a public standard? 2. "qsi" should be used: then please give some URL documenting where "qsi" comes from. 3. "silent" is a modal indication: are other modal indications to be given through languages tags? Where is their list? Or do I read this thread wrong? jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 08:31:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKEcf-0003AI-Dd; Tue, 27 Sep 2005 08:31:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKEce-0003AA-9X for ltru@megatron.ietf.org; Tue, 27 Sep 2005 08:31:48 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04426 for ; Tue, 27 Sep 2005 08:31:44 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EKEaP-0000GZ-Ou for ltru@lists.ietf.org; Tue, 27 Sep 2005 14:29:29 +0200 Received: from c-134-88-150.hh.dial.de.ignite.net ([62.134.88.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Sep 2005 14:29:29 +0200 Received: from nobody by c-134-88-150.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Sep 2005 14:29:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 27 Sep 2005 14:25:50 +0200 Organization: Lines: 48 Message-ID: <43393A4E.7070@xyzzy.claranet.de> References: <20050926213245.ZED2608.edge2.adelphia.net@megatron.ietf.org> <001801c5c320$26a14480$030aa8c0@DEWELL> <6.2.3.4.2.20050927130544.04c07220@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-150.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Tagging of silent films (was: Re: el truth?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org r&d afrac wrote: > 1. "x-silent" can be specified in a public standard? Not in a valid RfC, x-whatever is for private use. But an organization like Afrac or Unicode could define some meaning for its own private uses - as the name says. > 2. "qsi" should be used: then please give some URL > documenting where "qsi" comes from. | Type: language | Subtag: qaa..qtz | Description: PRIVATE USE | Added: 2005-09-24 Found in draft-ietf-ltru-initial-05. For details why qsi belongs to qaa..qtz see draft-ietf-ltru-registry-13. qaa..qtz are reserved for local use in ISO 639-2, see http://www.loc.gov/standards/iso639-2/langcodes.html#qr http://www.loc.gov/standards/iso639-2/codechanges.html says that is no new feature, RfC 3066 makes no exception for qaa..qtz, so qsi is already free for private use. That won't change with 3066bis - unlike private use region codes, 3066 didn't allow that in language tags. > 3. "silent" is a modal indication: are other modal > indications to be given through languages tags? At the moment the complete list of registered variants at date-B will be 1901, 1996, nedis, and rozaj. After date-B more variants can be registered. > Where is their list? The list is on page 102 of draft-ietf-ltru-initial-05 > Or do I read this thread wrong? Difficult to guess. Harald's idea und-silent could make sense. Or before date-B i-silent could in theory still be registered as defined in RfC 3066 chapter 3. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 09:25:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFT4-0007g4-DT; Tue, 27 Sep 2005 09:25:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFT2-0007fj-0R for ltru@megatron.ietf.org; Tue, 27 Sep 2005 09:25:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06892 for ; Tue, 27 Sep 2005 09:25:54 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKFaH-00054Q-7k for ltru@ietf.org; Tue, 27 Sep 2005 09:33:26 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8RDPdeZ002304; Tue, 27 Sep 2005 09:25:40 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 27 Sep 2005 09:25:39 -0400 Date: Tue, 27 Sep 2005 09:25:39 -0400 From: "John.Cowan" To: Harald Tveit Alvestrand Subject: Re: [Ltru] Tagging of silent films (was: Re: el truth?) Message-ID: <20050927132538.GB23896@NYCMJCOWA2> References: <25886F4A2C6C547489B77F58@gloppen.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25886F4A2C6C547489B77F58@gloppen.hjemme.alvestrand.no> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Harald Tveit Alvestrand scripsit: > However, they ARE guaranteed to conflict with other private use of those > codes. > > Don't standardize private-use codes - not even in an "industry-wide > agreement". It hurts. I think that use of private tags by a group is precisely what they are for. If private tags can't even be used by private agreement (between film people), they are useless. > i-silent is no longer available for public registration, methinks. Technically it still is, since we are in the RFC 3066 regime. In the RFC 3066bis regime, the equivalent would be simply "silent", a non-639 language subtag. > und-silent would be a valid code, if "silent" is registered as a variant > subtag with "und" as its prefix. Yes, that is registerable in both regimes. It's a little paradoxical, though, since "und" represents ignorance on the part of the tagger, to qualify ignorance with something specific. OTOH, people in silent films are generally speaking in some language, but viewers don't know or care what it is. -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com SAXParserFactory [is] a hideous, evil monstrosity of a class that should be hung, shot, beheaded, drawn and quartered, burned at the stake, buried in unconsecrated ground, dug up, cremated, and the ashes tossed in the Tiber while the complete cast of Wicked sings "Ding dong, the witch is dead." --Elliotte Rusty Harold on xml-dev _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 09:26:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFTk-0007kr-8E; Tue, 27 Sep 2005 09:26:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFTj-0007km-7o for ltru@megatron.ietf.org; Tue, 27 Sep 2005 09:26:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06931 for ; Tue, 27 Sep 2005 09:26:37 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKFaw-00055v-B7 for ltru@ietf.org; Tue, 27 Sep 2005 09:34:09 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 27 Sep 2005 06:26:26 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2005 06:26:26 -0700 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 Subject: RE: [Ltru] Tagging of silent films (was: Re: el truth?) Date: Tue, 27 Sep 2005 06:26:29 -0700 Message-ID: Thread-Topic: [Ltru] Tagging of silent films (was: Re: el truth?) Thread-Index: AcXDUvJIzUrJtbMBSk6aN/oYiY7ZewAEwMmg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 27 Sep 2005 13:26:26.0141 (UTC) FILETIME=[0FA470D0:01C5C367] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Harald Tveit Alvestrand > Don't standardize private-use codes - not even in an "industry-wide > agreement". It hurts. >=20 > i-silent is no longer available for public registration, methinks. >=20 > und-silent would be a valid code, if "silent" is registered as a variant > subtag with "und" as its prefix. Harald's concern is valid. I have suggested to the ISO 639 JAC that a special-purpose ID be added for "no linguistic content", which would suffice for what MPAA needs.=20 ("Language of audio track =3D no linguistic content" could imply a film with audio but no narration or dialogue, which isn't strictly silent, but for a "language of audio track" attribute it would be appropriate to indicate no linguistic content but not to indicate that there's no audio track whatsoever.) Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 09:53:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFtk-0005Ub-Ru; Tue, 27 Sep 2005 09:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFtj-0005UR-7J for ltru@megatron.ietf.org; Tue, 27 Sep 2005 09:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09190 for ; Tue, 27 Sep 2005 09:53:29 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKG0x-0005ug-L5 for ltru@ietf.org; Tue, 27 Sep 2005 10:01:02 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CD9C25806E; Tue, 27 Sep 2005 15:52:52 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25805-06; Tue, 27 Sep 2005 15:52:42 +0200 (CEST) Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 37442258067; Tue, 27 Sep 2005 15:52:41 +0200 (CEST) Date: Tue, 27 Sep 2005 15:53:13 +0200 From: Harald Tveit Alvestrand To: "John.Cowan" Subject: Re: [Ltru] Tagging of silent films (was: Re: el truth?) Message-ID: <52B04DE55C8CFFAEAF1424AF@gloppen.hjemme.alvestrand.no> In-Reply-To: <20050927132538.GB23896@NYCMJCOWA2> References: <25886F4A2C6C547489B77F58@gloppen.hjemme.alvestrand.no> <20050927132538.GB23896@NYCMJCOWA2> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On tirsdag, september 27, 2005 09:25:39 -0400 "John.Cowan" wrote: > Harald Tveit Alvestrand scripsit: > >> However, they ARE guaranteed to conflict with other private use of those >> codes. >> >> Don't standardize private-use codes - not even in an "industry-wide >> agreement". It hurts. > > I think that use of private tags by a group is precisely what they are > for. If private tags can't even be used by private agreement (between > film people), they are useless. That logically follows, of course - consider what happens when the film people adopt "qsi" for silent movies, the car people adopt "qsi" for a "test" voice on the car guidance system, and you insert a disk into the car entertainment system..... Outside of use inside a single system/database, private tags are useless, IMHO. >> i-silent is no longer available for public registration, methinks. > > Technically it still is, since we are in the RFC 3066 regime. In the > RFC 3066bis regime, the equivalent would be simply "silent", a non-639 > language subtag. I certainly wouldn't encourage creating more interim registrations..... >> und-silent would be a valid code, if "silent" is registered as a variant >> subtag with "und" as its prefix. > > Yes, that is registerable in both regimes. It's a little paradoxical, > though, since "und" represents ignorance on the part of the tagger, to > qualify ignorance with something specific. OTOH, people in silent films > are generally speaking in some language, but viewers don't know or care > what it is. I'm told that deaf people often laugh in the most bizarre spots when watching silent movies - they are used to lip-reading the dialogue :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 10:09:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKG9c-0001cJ-Q8; Tue, 27 Sep 2005 10:09:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKG9b-0001cD-9n for ltru@megatron.ietf.org; Tue, 27 Sep 2005 10:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10513 for ; Tue, 27 Sep 2005 10:09:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKGGq-0006O8-T6 for ltru@ietf.org; Tue, 27 Sep 2005 10:17:26 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EKG9Y-0003dD-GA; Tue, 27 Sep 2005 07:09:53 -0700 Message-Id: <6.2.3.4.2.20050927144821.05205e80@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 27 Sep 2005 15:12:17 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: Tagging of silent films (was: Re: el truth?) In-Reply-To: <43393A4E.7070@xyzzy.claranet.de> References: <20050926213245.ZED2608.edge2.adelphia.net@megatron.ietf.org> <001801c5c320$26a14480$030aa8c0@DEWELL> <6.2.3.4.2.20050927130544.04c07220@mail.afrac.org> <43393A4E.7070@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 14:25 27/09/2005, Frank Ellermann wrote: >r&d afrac wrote: > > > 1. "x-silent" can be specified in a public standard? > >Not in a valid RfC, x-whatever is for private use. But >an organization like Afrac or Unicode could define some >meaning for its own private uses - as the name says. I would like this to be formally confirmed by a real consensus of the WG and an addition to the document. This is not what Lee has documented against me, and I think he is right. Afrac or Unicode could define such a meaning for private use, meaning in a private space of exchanges. Not in a public one (space of exchanges, trust and services [SETS] being a notion Intlnet/AFRAC is preparing a draft about, but which seems easily understandable in the current state of the art: intranet, VPN, etc. as opposed to the shared usage of the common global Internet resources). I am not at my desk, and I have no access to archives, but I think I recall Lee gave a good description by analogy. Otherwise we are going to have an "x-tag" confusion. I do not object on the principle as I find the ABNF absurd here and proposed an IESG LC addition as "0- + IRI-tag ABNF". But I oppose the confusion: the "x-" usage MUST be clear and respect RFC 3066 bis. If this is not clear I think it is clear common interest to be very precise. All the constraints imposed via the ABNF would be wasted otherwise. > > 2. "qsi" should be used: then please give some URL > > documenting where "qsi" comes from. > >| Type: language >| Subtag: qaa..qtz >| Description: PRIVATE USE >| Added: 2005-09-24 > >Found in draft-ietf-ltru-initial-05. For details why >qsi belongs to qaa..qtz see draft-ietf-ltru-registry-13. That "qaa ... qtz" are for private use is OK. But: 1. I do not see where "qsi" is specifically documented as "silent" 2. I do not see the difference between ISO 639-3 private use and RFC 3066 bis private use? Is it on purpose that "PRIVATE USE" was retained while a normal (RFC 1958) Internet standard practice would call for "private use"? If there is one (I have not my ISO 639-3 draft with me, but I find none in RFC 639-4 draft), it should be spelled out in the document (may be in the paragraph proposed above?). >qaa..qtz are reserved for local use in ISO 639-2, see >http://www.loc.gov/standards/iso639-2/langcodes.html#qr > >http://www.loc.gov/standards/iso639-2/codechanges.html >says that is no new feature, RfC 3066 makes no exception >for qaa..qtz, so qsi is already free for private use. Yes. But here "qsi" comes as it was already specified as to be used instead as to be free? >That won't change with 3066bis - unlike private use >region codes, 3066 didn't allow that in language tags. > > > 3. "silent" is a modal indication: are other modal > > indications to be given through languages tags? > >At the moment the complete list of registered variants >at date-B will be 1901, 1996, nedis, and rozaj. After >date-B more variants can be registered. You talk of language variants. I talk of mode (silence, smile, fount, loudness, sex, age, italic, etc.) > > Where is their list? > >The list is on page 102 of draft-ietf-ltru-initial-05 cf. above. > > Or do I read this thread wrong? > >Difficult to guess. Harald's idea und-silent could make >sense. Or before date-B i-silent could in theory still >be registered as defined in RfC 3066 chapter 3. No. I gave an example yesterday: a rebus. This is silent and is related to a language. IMHO scripts are modes and the appropriate way would be (in RFC 3066 bis wording) script = oral-silent. But if I am correct the ABNF would have difficulties supporting script variants (or am I wrong?). Thanks. JFC _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 13:49:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJaP-0007cE-8b; Tue, 27 Sep 2005 13:49:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJaM-0007c6-Pu; Tue, 27 Sep 2005 13:49:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27404; Tue, 27 Sep 2005 13:49:45 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-red.bigfish.com ([216.148.222.61] helo=mail59-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKJhc-0004MR-OH; Tue, 27 Sep 2005 13:57:19 -0400 Received: from mail59-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail59-red-R.bigfish.com (Postfix) with ESMTP id 858012A2925; Tue, 27 Sep 2005 17:49:22 +0000 (UTC) X-BigFish: VP Received: by mail59-red (MessageSwitch) id 1127843349957044_29733; Tue, 27 Sep 2005 17:49:09 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail59-red.bigfish.com (Postfix) with ESMTP id C841B2A2B0A; Tue, 27 Sep 2005 17:49:09 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005092710375698:80597 ; Tue, 27 Sep 2005 10:37:56 -0700 To: Harald Tveit Alvestrand Subject: Re: [Ltru] Tagging of silent films (was: Re: el truth?) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Tue, 27 Sep 2005 10:28:48 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 09/27/2005 10:28:49, Serialize complete at 09/27/2005 10:28:49, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 09/27/2005 10:37:56 AM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 09/27/2005 10:58:12 AM, Serialize complete at 09/27/2005 10:58:12 AM X-Spam-Score: 0.4 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: ltru-bounces@ietf.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1905545990==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1905545990== Content-Type: multipart/alternative; boundary="=_alternative 006006FD88257089_=" This is a multipart message in MIME format. --=_alternative 006006FD88257089_= Content-Type: text/plain; charset="us-ascii" I discussed whether to request a formal tag for this usage with the MPA. We figured if we registered it, we would need to dilute the meaning to make it more global and define it, as Peter suggests, as "no linguistic content" or "no language present." But this is semantically different from "silent," which is very specific to our industry. Consider the difference between a silent film -- defined as a film with an actor mouthing words that features title cards to indicate what the actor is saying -- to films like Baraka, Koyaanisqatsi, and the Triplets of Belleville, which feature no language at all. (Belleville does have songs in French, but that's slightly different.) Also, the Library of Congress genre list defines "actuality" films as those early films that wowed viewers by merely showing a train entering a station. These latter examples would fall under the "no language present" classification, but not the "silent" classification. In other words, it's possible we may need both tags -- silent AND no language present. I don't consider silent to be a modal classification -- spoken, written, and signed are modes. And I'll even admit this is a somewhat impure use of language data. (Another reason why I don't think this should be registered.) Ideally, this metadata should be a boolean value. Silent or not silent. But within our industry, for compliance with external standards and product definition, we must define this as a language. I think und-silent is an oxymoron. If it's undetermined, how do you know it's silent? You've determined that the film features an actor mouthing the words, and you may have defined the title cards as being in French, English, or Sio. That doesn't seem undetermined to me. (If you don't mind, I'd prefer to gloss over the lipreaders issue.) At present, we have no plans to register this tag and prefer to use "qsi" over "x-silent." I do think if the private use tags cannot be used for this purpose, what good are they? Do you really want me to request formal tags for both "silent" and "no language present"? That's my potential business need. That could set a precedent for other weird tags from other industries to enter the registry. Silent seems very industry-specific to me and this seemed to be an appropriate use case for the private use tag. Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Harald Tveit Alvestrand Sent by: ltru-bounces@ietf.org 09/27/2005 06:53 AM To: "John.Cowan" cc: ltru@ietf.org Subject: Re: [Ltru] Tagging of silent films (was: Re: el truth?) --On tirsdag, september 27, 2005 09:25:39 -0400 "John.Cowan" wrote: > Harald Tveit Alvestrand scripsit: > >> However, they ARE guaranteed to conflict with other private use of those >> codes. >> >> Don't standardize private-use codes - not even in an "industry-wide >> agreement". It hurts. > > I think that use of private tags by a group is precisely what they are > for. If private tags can't even be used by private agreement (between > film people), they are useless. That logically follows, of course - consider what happens when the film people adopt "qsi" for silent movies, the car people adopt "qsi" for a "test" voice on the car guidance system, and you insert a disk into the car entertainment system..... Outside of use inside a single system/database, private tags are useless, IMHO. >> i-silent is no longer available for public registration, methinks. > > Technically it still is, since we are in the RFC 3066 regime. In the > RFC 3066bis regime, the equivalent would be simply "silent", a non-639 > language subtag. I certainly wouldn't encourage creating more interim registrations..... >> und-silent would be a valid code, if "silent" is registered as a variant >> subtag with "und" as its prefix. > > Yes, that is registerable in both regimes. It's a little paradoxical, > though, since "und" represents ignorance on the part of the tagger, to > qualify ignorance with something specific. OTOH, people in silent films > are generally speaking in some language, but viewers don't know or care > what it is. I'm told that deaf people often laugh in the most bizarre spots when watching silent movies - they are used to lip-reading the dialogue :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 006006FD88257089_= Content-Type: text/html; charset="us-ascii"
I discussed whether to request a formal tag for this usage with the MPA. We figured if we registered it, we would need to dilute the meaning to make it more global and define it, as Peter suggests, as "no linguistic content" or "no language present."

But this is semantically different from "silent," which is very specific to our industry. Consider the difference between a silent film -- defined as a film with an actor mouthing words that features title cards to indicate what the actor is saying -- to films like Baraka, Koyaanisqatsi, and the Triplets of Belleville, which feature no language at all. (Belleville does have songs in French, but that's slightly different.) Also, the Library of Congress genre list defines "actuality" films as those early films that wowed viewers by merely showing a train entering a station. These latter examples would fall under the "no language present" classification, but not the "silent" classification.

In other words, it's possible we may need both tags -- silent AND no language present.

I don't consider silent to be a modal classification -- spoken, written, and signed are modes. And I'll even admit this is a somewhat impure use of language data. (Another reason why I don't think this should be registered.) Ideally, this metadata should be a boolean value. Silent or not silent. But within our industry, for compliance with external standards and product definition, we must define this as a language.

I think und-silent is an oxymoron. If it's undetermined, how do you know it's silent? You've determined that the film features an actor mouthing the words, and you may have defined the title cards as being in French, English, or Sio. That doesn't seem undetermined to me. (If you don't mind, I'd prefer to gloss over the lipreaders issue.)

At present, we have no plans to register this tag and prefer to use "qsi" over "x-silent." I do think if the private use tags cannot be used for this purpose, what good are they? Do you really want me to request formal tags for both "silent" and "no language present"? That's my potential business need. That could set a precedent for other weird tags from other industries to enter the registry. Silent seems very industry-specific to me and this seemed to be an appropriate use case for the private use tag.

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384




Harald Tveit Alvestrand <harald@alvestrand.no>
Sent by: ltru-bounces@ietf.org

09/27/2005 06:53 AM

       
        To:        "John.Cowan" <jcowan@reutershealth.com>
        cc:        ltru@ietf.org
        Subject:        Re: [Ltru] Tagging of silent films (was: Re: el truth?)





--On tirsdag, september 27, 2005 09:25:39 -0400 "John.Cowan"
<jcowan@reutershealth.com> wrote:

> Harald Tveit Alvestrand scripsit:
>
>> However, they ARE guaranteed to conflict with other private use of those
>> codes.
>>
>> Don't standardize private-use codes - not even in an "industry-wide
>> agreement". It hurts.
>
> I think that use of private tags by a group is precisely what they are
> for.  If private tags can't even be used by private agreement (between
> film people), they are useless.

That logically follows, of course - consider what happens when the film
people adopt "qsi" for silent movies, the car people adopt "qsi" for a
"test" voice on the car guidance system, and you insert a disk into the car
entertainment system.....

Outside of use inside a single system/database, private tags are useless,
IMHO.

>> i-silent is no longer available for public registration, methinks.
>
> Technically it still is, since we are in the RFC 3066 regime.  In the
> RFC 3066bis regime, the equivalent would be simply "silent", a non-639
> language subtag.

I certainly wouldn't encourage creating more interim  registrations.....

>> und-silent would be a valid code, if "silent" is registered as a variant
>> subtag with "und" as its prefix.
>
> Yes, that is registerable in both regimes.  It's a little paradoxical,
> though, since "und" represents ignorance on the part of the tagger, to
> qualify ignorance with something specific.  OTOH, people in silent films
> are generally speaking in some language, but viewers don't know or care
> what it is.

I'm told that deaf people often laugh in the most bizarre spots when
watching silent movies - they are used to lip-reading the dialogue :-)


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

--=_alternative 006006FD88257089_=-- --===============1905545990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1905545990==-- From ltru-bounces@ietf.org Tue Sep 27 15:23:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKL3W-0007Oz-0d; Tue, 27 Sep 2005 15:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKL3U-0007NY-Co for ltru@megatron.ietf.org; Tue, 27 Sep 2005 15:23:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03767 for ; Tue, 27 Sep 2005 15:23:54 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKLAm-0006xr-Hy for ltru@ietf.org; Tue, 27 Sep 2005 15:31:29 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 27 Sep 2005 12:23:45 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2005 12:23:45 -0700 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 Subject: RE: [Ltru] Re: Tagging of silent films (was: Re: el truth?) Date: Tue, 27 Sep 2005 12:23:44 -0700 Message-ID: Thread-Topic: [Ltru] Re: Tagging of silent films (was: Re: el truth?) Thread-Index: AcXDbWFthlubpQlqTd+qMCHiqeJnLgAKgAVQ From: "Peter Constable" To: X-OriginalArrivalTime: 27 Sep 2005 19:23:45.0379 (UTC) FILETIME=[FA6C8B30:01C5C398] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of r&d afrac > > > 1. "x-silent" can be specified in a public standard? > > > >Not in a valid RfC, x-whatever is for private use. But > >an organization like Afrac or Unicode could define some > >meaning for its own private uses - as the name says. >=20 > I would like this to be formally confirmed by a real consensus of the > WG and an addition to the document. I don't get this. Nobody else seems to have difficulty understanding what "private use" means and the implications of private use tags, such as that a meaning won't be specified in an RFC but that anybody outside of IETF can choose to do what they want with private-use tags in their implementation of RFC 3066(bis). That plus the fact that the WG and IETF last calls are over makes me inclined to say we should not take any particular action related to this request. > > > 2. "qsi" should be used: then please give some URL > > > documenting where "qsi" comes from. > > > >| Type: language > >| Subtag: qaa..qtz > >| Description: PRIVATE USE > >| Added: 2005-09-24 > > > >Found in draft-ietf-ltru-initial-05. For details why > >qsi belongs to qaa..qtz see draft-ietf-ltru-registry-13. >=20 > That "qaa ... qtz" are for private use is OK. But: > 1. I do not see where "qsi" is specifically documented as "silent" One industry application of RFC 3066 was planning to use the private-use tag "qsi" to indicate movies that are "silent". If you want to find that documented, you'll need to consult *that* spec. Neither IETF nor IANA nor ISO document "qsi" as meaning "silent". > >At the moment the complete list of registered variants > >at date-B will be 1901, 1996, nedis, and rozaj. After > >date-B more variants can be registered. >=20 > You talk of language variants. I talk of mode (silence, smile, fount, > loudness, sex, age, italic, etc.) Language tags defined by RFC 3066(bis) are intended to indicate linguistic attributes of content; attributes such as typography, emotional stance or other attributes of speakers/authors, etc. are entirely out of scope. There may be valid reasons to indicate such things as metadata attributes on content, but the tags defined by this spec are not the appropriate mechanism for that. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 16:36:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMBh-0001Yz-3w; Tue, 27 Sep 2005 16:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMBe-0001Ui-6y; Tue, 27 Sep 2005 16:36:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19040; Tue, 27 Sep 2005 16:36:24 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKMIx-0004eb-8e; Tue, 27 Sep 2005 16:44:00 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8RKa7NL004005; Tue, 27 Sep 2005 16:36:07 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 27 Sep 2005 16:36:06 -0400 Date: Tue, 27 Sep 2005 16:36:06 -0400 From: "John.Cowan" To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Tagging of silent films (was: Re: el truth?) Message-ID: <20050927203606.GC25960@NYCMJCOWA2> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru-bounces@ietf.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: [long posting snipped] +1 -- Winter: MIT, John Cowan Keio, INRIA, jcowan@reutershealth.com Issue lots of Drafts. http://www.ccil.org/~cowan So much more to understand! http://www.reutershealth.com Might simplicity return? (A "tanka", or extended haiku) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Sep 27 16:42:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMHd-0003Bc-Nt; Tue, 27 Sep 2005 16:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMHR-00038J-4t for ltru@megatron.ietf.org; Tue, 27 Sep 2005 16:42:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19397 for ; Tue, 27 Sep 2005 16:42:23 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKMOk-0004pI-CL for ltru@ietf.org; Tue, 27 Sep 2005 16:49:59 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 27 Sep 2005 13:42:14 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2005 13:42:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Tagging of silent films (was: Re: el truth?) Date: Tue, 27 Sep 2005 13:42:13 -0700 Message-ID: Thread-Topic: [Ltru] Tagging of silent films (was: Re: el truth?) Thread-Index: AcXDjB8VrfderDPZTCqgQPP9P2PXCQAFLORg From: "Peter Constable" To: X-OriginalArrivalTime: 27 Sep 2005 20:42:14.0268 (UTC) FILETIME=[F123FBC0:01C5C3A3] X-Spam-Score: 0.6 (/) X-Scan-Signature: 38a35b5fc88e9b9a2affced027b040a4 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1377665856==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1377665856== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C3A3.F09A402A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C3A3.F09A402A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the risk of straying off topic... =20 If you are distinguishing between audio tracks and subtitles, then I would think you could have a film in which there is no audio track, but there are subtitles. For such a film,