mail archive Language Tag Registry Update working group discussion list
ltru.ietf.org
(List home) (Recent threads) (187 other Internet Engineering Task Force (IETF) lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- Low traffic list: less than 3 messages per day
- This list contains about 191 messages, beginning Jun 2011
- 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
Availability of 't' extension document and data
Ad
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?
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 *— Il meglio è l’inimico del bene —* * * * [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 > > > _______________________________________________ > Ltru mailing list > > https://www.ietf.org/mailman/listinfo/ltru >
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 happeningYup.> (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
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