From doug@ewellic.org Wed Dec 7 10:14:38 2011 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14E221F8BB1 for ; Wed, 7 Dec 2011 10:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrGhcqXym0K6 for ; Wed, 7 Dec 2011 10:14:38 -0800 (PST) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by ietfa.amsl.com (Postfix) with SMTP id 4B95F21F8B7C for ; Wed, 7 Dec 2011 10:14:38 -0800 (PST) Received: (qmail 20548 invoked from network); 7 Dec 2011 18:14:37 -0000 Received: from unknown (HELO localhost) (72.167.218.134) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 7 Dec 2011 18:14:37 -0000 Received: (qmail 25275 invoked by uid 99); 7 Dec 2011 18:14:37 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.190 User-Agent: Web-Based Email 5.6.06 Message-Id: <20111207111436.665a7a7059d7ee80bb4d670165c8327d.912aa587c9.wbe@email03.secureserver.net> From: "Doug Ewell" To: ltru@ietf.org Date: Wed, 07 Dec 2011 11:14:36 -0700 Mime-Version: 1.0 Subject: [Ltru] Availability of 't' extension document and data X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 18:14:38 -0000 According to the IETF Datatracker, draft-davis-t-langtag-ext-07 ("BCP 47=0A= Extension T - Transformed Content") has been approved by IESG and=0Aforward= ed to the RFC Editor queue.=0A=0AThe time a document normally spends in the= RFC Editor queue varies=0Adramatically, and can be unexpectedly long (as B= CP 47 veterans know),=0Abut the RFC Editor FAQ notes that "Typical time to = publish is 1-2=0Amonths."=0A=0ASection 2.9 of draft-davis-t-langtag-ext-07 = says, "The data and=0Aspecification will be available by the time this inte= rnet draft has been=0Aapproved. The description field is in the process of= being added to=0ACLDR." The first sentence is repeated in Section 2.1. T= his was an=0Aongoing concern of mine during the draft process, which was pa= rtially=0Aaddressed by including sample data in Section 2.9.=0A=0AAccording= to the CLDR "Releases/Downloads" page, Version 2.1 of CLDR is=0Ascheduled = to be released on February 1, 2012. This is eight weeks from=0Anow.=0A=0AW= hat is the likelihood that the data for the 't' extension actually will=0Ab= e made available in time for RFC publication?=0A=0A--=0ADoug Ewell | Thornt= on, Colorado, USA | RFC 5645, 4645, UTN #14=0Awww.ewellic.org | www.faceboo= k.com/doug.ewell | @DougEwell =C2=AD=0A=0A From mark.edward.davis@gmail.com Wed Dec 7 10:42:34 2011 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4186011E80A5 for ; Wed, 7 Dec 2011 10:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7Hj-xXoeq2b for ; Wed, 7 Dec 2011 10:42:33 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 440B411E8094 for ; Wed, 7 Dec 2011 10:42:33 -0800 (PST) Received: by qadb15 with SMTP id b15so4042705qad.10 for ; Wed, 07 Dec 2011 10:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/FMdZzBPprqGqHRb8zMpgZ+7XPJdYXO6M6SeIDalqKE=; b=r2owvtsvbAFtkcXdobtS/u4b1GOl1IIiiLVeD1ISxUDiFsGkjVHbTjEyptoFBkBbtF gQLKT9FwLtTRBOWQxeA/+hRYKT5edrkhYHIGYT8KHLcTwiFidnlYrHTwk0gyg+NLh5Cy mhgYo3sSJw4PsCF05TG+jDLKHq+0p35DSayYc= MIME-Version: 1.0 Received: by 10.50.169.99 with SMTP id ad3mr104448igc.6.1323283352193; Wed, 07 Dec 2011 10:42:32 -0800 (PST) Sender: mark.edward.davis@gmail.com Received: by 10.42.219.67 with HTTP; Wed, 7 Dec 2011 10:42:32 -0800 (PST) In-Reply-To: <20111207111436.665a7a7059d7ee80bb4d670165c8327d.912aa587c9.wbe@email03.secureserver.net> References: <20111207111436.665a7a7059d7ee80bb4d670165c8327d.912aa587c9.wbe@email03.secureserver.net> Date: Wed, 7 Dec 2011 10:42:32 -0800 X-Google-Sender-Auth: Qw3hyyltwhau0WW2f_RRgq0DLZc Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: Doug Ewell Content-Type: multipart/alternative; boundary=e89a8f2343fd250a8b04b384ea48 Cc: ltru@ietf.org Subject: Re: [Ltru] Availability of 't' extension document and data X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 18:42:34 -0000 --e89a8f2343fd250a8b04b384ea48 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The editorial process for the RFCs involves the authors, so there is no danger of that happening (and I've never seen it happen in less than 2 months anyway). So I wouldn't lose any sleep over this one, Doug. Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* * * * [https://plus.google.com/114199149796022210033] * On Wed, Dec 7, 2011 at 10:14, Doug Ewell wrote: > According to the IETF Datatracker, draft-davis-t-langtag-ext-07 ("BCP 47 > Extension T - Transformed Content") has been approved by IESG and > forwarded to the RFC Editor queue. > > The time a document normally spends in the RFC Editor queue varies > dramatically, and can be unexpectedly long (as BCP 47 veterans know), > but the RFC Editor FAQ notes that "Typical time to publish is 1-2 > months." > > Section 2.9 of draft-davis-t-langtag-ext-07 says, "The data and > specification will be available by the time this internet draft has been > approved. The description field is in the process of being added to > CLDR." The first sentence is repeated in Section 2.1. This was an > ongoing concern of mine during the draft process, which was partially > addressed by including sample data in Section 2.9. > > According to the CLDR "Releases/Downloads" page, Version 2.1 of CLDR is > scheduled to be released on February 1, 2012. This is eight weeks from > now. > > What is the likelihood that the data for the 't' extension actually will > be made available in time for RFC publication? > > -- > Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14 > www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell =C2=AD > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --e89a8f2343fd250a8b04b384ea48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Th= e editorial process for the RFCs involves the authors, so there is no dange= r of that happening (and I've never seen it happen in less than 2 month= s anyway). So I wouldn't lose any sleep over this one, Doug.

<= i>=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94


On Wed, Dec 7, 2011 at 10:14, Doug Ewell= <doug@ewellic.org= > wrote:
According to the IETF Datatracker, draft-davis-t-langtag-ext-07 ("BCP = 47
Extension T - Transformed Content") has been approved by IESG and
forwarded to the RFC Editor queue.

The time a document normally spends in the RFC Editor queue varies
dramatically, and can be unexpectedly long (as BCP 47 veterans know),
but the RFC Editor FAQ notes that "Typical time to publish is 1-2
months."

Section 2.9 of draft-davis-t-langtag-ext-07 says, "The data and
specification will be available by the time this internet draft has been approved. =C2=A0The description field is in the process of being added to CLDR." =C2=A0The first sentence is repeated in Section 2.1. =C2=A0This= was an
ongoing concern of mine during the draft process, which was partially
addressed by including sample data in Section 2.9.

According to the CLDR "Releases/Downloads" page, Version 2.1 of C= LDR is
scheduled to be released on February 1, 2012. =C2=A0This is eight weeks fro= m
now.

What is the likelihood that the data for the 't' extension actually= will
be made available in time for RFC publication?

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | = www.facebo= ok.com/doug.ewell | @DougEwell =C2=AD


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

--e89a8f2343fd250a8b04b384ea48-- From randy_presuhn@mindspring.com Wed Dec 7 11:04:36 2011 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E842F21F8BD8 for ; Wed, 7 Dec 2011 11:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.092 X-Spam-Level: X-Spam-Status: No, score=-100.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c8TzRVJ7Byp for ; Wed, 7 Dec 2011 11:04:36 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7A821F8BD3 for ; Wed, 7 Dec 2011 11:04:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ntmpP/9o7Pej3VTF6fl8XkHCH1Mcdb+lVOtYpFcBSOWZfnRJG0P+2oNW8pTxaQzT; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.53.231] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RYMnB-0003I4-OH for ltru@ietf.org; Wed, 07 Dec 2011 14:04:34 -0500 Message-ID: <003001ccb513$52aa4b80$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111207111436.665a7a7059d7ee80bb4d670165c8327d.912aa587c9.wbe@email03.secureserver.net> Date: Wed, 7 Dec 2011 11:06:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f632a5f61f23803da5c297c4a9c548f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.53.231 Subject: Re: [Ltru] Availability of 't' extension document and data X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 19:04:37 -0000 Hi - > From: "Mark Davis ☕" > To: "Doug Ewell" > Cc: > Sent: Wednesday, December 07, 2011 10:42 AM > Subject: Re: [Ltru] Availability of 't' extension document and data > > The editorial process for the RFCs involves the authors, so there is no > danger of that happening Yup. > (and I've never seen it happen in less than 2 > months anyway). It *can* go surprisinly fast, particularly if other standards-track documents in the editor's queue depend on it for their normative references. > So I wouldn't lose any sleep over this one, Doug. Agreed. We're not dealing with automata. Randy From stpeter@stpeter.im Wed Dec 7 11:28:41 2011 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1B21F8783 for ; Wed, 7 Dec 2011 11:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koKp+wiRRMqw for ; Wed, 7 Dec 2011 11:28:41 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 15AEA21F877F for ; Wed, 7 Dec 2011 11:28:41 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5717D42306; Wed, 7 Dec 2011 12:35:58 -0700 (MST) Message-ID: <4EDFBE67.7060604@stpeter.im> Date: Wed, 07 Dec 2011 12:28:39 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= References: <20111207111436.665a7a7059d7ee80bb4d670165c8327d.912aa587c9.wbe@email03.secureserver.net> In-Reply-To: X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: ltru@ietf.org, Doug Ewell Subject: Re: [Ltru] Availability of 't' extension document and data X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 19:28:41 -0000 On 12/7/11 11:42 AM, Mark Davis ☕ wrote: > The editorial process for the RFCs involves the authors, so there is no > danger of that happening (and I've never seen it happen in less than 2 > months anyway). So I wouldn't lose any sleep over this one, Doug. Right now it's running around 6 weeks on average. In any case, this kind of thing can be fixed during AUTH48. Peter -- Peter Saint-Andre https://stpeter.im/