From randy_presuhn@mindspring.com Thu Jun 2 10:20:51 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 8105FE06A6; Thu, 2 Jun 2011 10:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYcMNaBGGq0J; Thu, 2 Jun 2011 10:20:50 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA8E05D3; Thu, 2 Jun 2011 10:20:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Un+4Lu2sfgiKqwhMg+9nh0B+jw/KHem1vxhh17qLmT2ZKHtZ9RQ0PqeaVEqRapg5; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.238.251] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QSBZh-0001mA-7w; Thu, 02 Jun 2011 13:20:49 -0400 Message-ID: <001601cc2149$ecfaf260$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , , "Disman" Date: Thu, 2 Jun 2011 10:24:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b3828163b0401dbf5030128e30377d03e55d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.238.251 Subject: [Ltru] Fw: 81th IETF - Working Group/BOF Scheduling - REMINDER 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: Thu, 02 Jun 2011 17:20:51 -0000 Hi - Forwarded for your information, and to shake loose any "bouncers" from these mailing lists. Randy ----- Original Message ----- > From: "IETF Agenda" > To: "Working Group Chairs" > Cc: > Sent: Thursday, June 02, 2011 9:22 AM > Subject: 81th IETF - Working Group/BOF Scheduling - REMINDER > > ----------------------------------------------------------------- > 81th IETF Quebec City, Canada > Meeting Dates: July 24-29, 2011 > Host: RIM > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday mid-afternoon > (15:15). > > We are accepting scheduling requests for all Working Groups and BOFs > starting today. The milestones and deadlines for scheduling-related > activities are as follows: > > NOTE: cutoff dates are subject to change. > > - 2011-06-06 (Monday): Cutoff date for requests to schedule Working Group > meetings at 17:00 PT (00:00 UTC). To request a Working Group session, use > the IETF Meeting Session Request Tool. > - 2011- 06-13 (Monday): Cutoff date for BOF proposal requests to Area > Directors at 17:00 PT (00:00 UTC). To request a BOF, please see > instructions on Requesting a BOF. > - 2011-06-16 (Thursday): Cutoff date for Area Directors to approve BOFs > at 17:00 PT (00:00 UTC). > - 2011-06-23 (Thursday): Preliminary agenda published for comment. > - 2011-06-27 (Monday): Cutoff date for requests to reschedule Working > Group and BOF meetings 17:00 PT (00:00 UTC). > - 2011-06-27 (Monday): Working Group Chair approval for initial document > (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). > - 2011-07-01 (Friday): Final agenda to be published. > - 2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) > submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. > - 2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 > PT (00:00 UTC), upload using IETF ID Submission Tool. > - 2011-07-13 (Wednesday): Draft Working Group agendas due by 17:00 PT > (00:00 UTC), upload using IETF Meeting Materials Management Tool. > - 2011-07-18 (Monday): Revised Working Group agendas due by 17:00 PT > (00:00 UTC), upload using IETF Meeting Materials Management Tool. > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using the > "IETF Meeting Session Request Tool," a Web-based tool for submitting all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the message, > and include all of the information specified in item (4) of "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, July 13, 2011 by 17:00 PT (00:00 > UTC). Revised Working Group agendas are due no later than Monday, July > 18, 2011 at 17:00 PT (00:00 UTC). The proposed agenda for a BOF session > should be submitted along with your request for a session. Please be sure > to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 81 Meeting Materials" Web page is: > > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=81 > > If you are a Working Group chair, then you already have accounts on the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both tools. > If you are a BOF chair who is not also a Working Group chair, then you > will be given an account on the "IETF Meeting Materials Management Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =============================================================== > For your convenience, comprehensive information on requesting meeting > sessions at IETF 81 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted using > the "IETF Meeting Session Request Tool," a Web-based tool for submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, then > please send a message to ietf-action@ietf.org. If you are unable to use > the tool, then you may send your request via e-mail to agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please read the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request must be > approved by an Area Director. Additional sessions will be assigned, based > on availability, after Monday, June 27, 2011 at 17:00 PT (00:00 UTC), the > cut-off date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance: > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =============================================================== > For your convenience please find here a list of the IETF Area Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Pete Resnick > Peter Saint-Andre > > Internet Area (int) > Jari Arkko > Ralph Droms > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Gonzalo Camarillo > Robert Sparks > > Routing Area (rtg) > Stewart Bryant > Adrian Farrel > > Security Area (sec) > Stephen Farrell > Sean Turner > > Transport Area (tsv) > Wesley Eddy > David Harrington > =========================================================== > 80th IETF Meeting Attendance Number and Minutes Recorded:\ > > Working Groups > > 6lowpan - 131 > 6man - 162 > abfab - 49 > abfab (second session) - 36 > alto - 105 > ancp - 9 > apparea (AG) - 129 - 145 mins > armd - 114 - 60 mins > atoca - 37 - 71 mins > avtcore - 90 - 110 mins > avtext - 75 - 15 mins > behave - 120 > bmwg - 34 - 150 mins > ccamp - 89 > ccamp (2nd session) - 74 - 165 mins > cdni BOF - 132 - 123 mins > clue - 91 - 120 mins > codec - 59 > conex - 67 > core - 106 > core (2nd session) - 93 > dane - 115 - 130 mins > decade - 49 - 120 mins > dhc - 53 - 120 mins > dime - 15 > dispatch - 100 - 60 mins > dkim - 24 - 65 mins > dnsext - 154 > dnsop - 70 - 60 mins > drinks - 23 - 60 mins > eai - 23 > ecrit - 45 > eman - 51 > emu - 30 - 90 mins > fecframe - 14 > forces - 17 - 80 mins > geopriv - 61 > grow - 61 > hip - 17 - 70 mins > hiprg (RG) - 35 - 120 mins > hokey - 24 > httpbis - 51 > hybi - 96 > iccrg (RG) - 80 - 150 mins > idr - 107 - 120 mins > intarea (AG) - 186 > ipfix - 37 > ippm - 21 - 118 mins > iri - 23 > isis - 57 > karp - 41 > kitten - 14 > krb-wg - 20 > l2vpn - 134 - 150 mins > lisp - 74 > lwig - 86 > manet - 32 - 140 mins > marf - 18 > mboned - 21 > mext - 43 > mif - 64 > mip4 - 16 - 50 mins > mmusic - 59 - 150 mins > mpls - 172 > mpls (2nd session) - 106 > mptcp - 49 > msec - 24 > multimob - 42 - 160 mins > nea - 23 - 110 mins > netext - 42 > netconf - 28 > netmod - 30 - 80 mins > nfsv4 - 18 - 130 mins > nfsv4 (second session) - 17 - 60 mins > oauth - 55 - 150 mins > opsarea (AG) - 85 - 150 mins > ospf - 39 - 135 mins > p2prg - 62 > p2psip - 49 - 128 mins > paws BOF - 54 > pce - 41 > pcn - 19 - 85 mins > pcp - 59 > pim - 30 - 120 mins > pkix - 49 - 105 mins > plasma BOF - 42 - 101 mins > ppsp - 60 - 150 mins > precis - 28 - 185 mins > pwe3 - 113 - 152 mins > radext - 18 - 149 mins > renum BOF - 100 > rmt - 19 - 60 mins > roll - 74 > rtcweb BOF - 239 > rtgarea (AG) - 223 > rtgwg - 119 - 127 mins > saag (AG) - 99 - 125 mins > samrg (RG) - 27 - 110 mins > savi - 21 - 90 mins > sidr - 137 - 174 mins > sipclf - 18 - 95 mins > sipcore - 62 - 55 mins > sipcore (2nd session) - 35 > soc - 49 > softwire - 102 > splices - 41 - 85 mins > tcpm - 51 > tictoc - 21 - 145 mins > trill - 88 - 115 mins > tsvarea (AG) - 119 - 150 mins > tsvwg - 66 - 160 mins > urnbis - 21 - 120 mins > v6ops - 196 > v6ops (second session) - 136 > vcarddav - 13 - 60 mins > vipr - 58 - 109 mins > websec - 91 - 125 mins > xmpp - 44 From randy_presuhn@mindspring.com Mon Jun 13 11:30:11 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 0601921F844D for ; Mon, 13 Jun 2011 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DygzBARy80dQ for ; Mon, 13 Jun 2011 11:30:10 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 43C1921F844A for ; Mon, 13 Jun 2011 11:30:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tXmzgsrs1YFQZHsuEUmn6ujvmg2MC2mIKW3kWE6/1YI/CPDcIpvFmEuC/ndswg5a; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.53.60] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QWBtp-0006KO-BJ for ltru@ietf.org; Mon, 13 Jun 2011 14:30:09 -0400 Message-ID: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 13 Jun 2011 11:34:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b382a8299d47f56c350c950e5ae5e159f3a3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.53.60 Subject: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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: Mon, 13 Jun 2011 18:30:11 -0000 Hi - This sounds like something folks on this list might find of interest. Randy > From: > To: > Sent: Monday, June 13, 2011 8:38 AM > Subject: I-D Action: draft-falk-transliteration-tags-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Tags for the Identification of Transliterated Text > Author(s) : Courtney Falk > Filename : draft-falk-transliteration-tags-01.txt > Pages : 7 > Date : 2011-06-13 > > This document describes the structure, content, creation, and > semantics of language tags for use in describing text that was > transliterated from one orthographic system to another. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-falk-transliteration-tags-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-falk-transliteration-tags-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mark.edward.davis@gmail.com Tue Jun 14 18:11:03 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 59CBB21F847B for ; Tue, 14 Jun 2011 18:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIb5HaBvcJlr for ; Tue, 14 Jun 2011 18:11:01 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E278021F847A for ; Tue, 14 Jun 2011 18:11:00 -0700 (PDT) Received: by ywp31 with SMTP id 31so4103247ywp.31 for ; Tue, 14 Jun 2011 18:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9v/+QgPa97w/IHRo/vFtJvpHTgYeUWH9MLM30dz5XLg=; b=pVdOa0jPrp6wDJ8AMVlkR4Ustw5cGrwuq9LHuX3VpSt6HDDYBjceX39ZnDcNLLmnP4 L1k791elhw3iVIUmrAnco8b6Nt4ccHIppz0zGSqTghGLO7lEcb3pF0Obc6PZcNcZbS4B ObFlw5d3qcLiOgT1iOPZXauHF875jlC3nsbPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ErxuPVLgoX7YsGZo5YAoi2sAzw1+knLR/C6mR1zRmEpxGuC312TLdEzmGhlB0jZkAs XRr6xpTMl4iNTxc9YcngxLm2OoLPIX6wwVZfbB5LUBBFMMWgOcvcRtwswNEqTiTcmV2w tRHdR3rvqfSxu2pCRO4Pp4ZGh/RhnJSkvYBn8= MIME-Version: 1.0 Received: by 10.150.115.6 with SMTP id n6mr154927ybc.43.1308100258204; Tue, 14 Jun 2011 18:10:58 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.151.38.19 with HTTP; Tue, 14 Jun 2011 18:10:58 -0700 (PDT) In-Reply-To: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> References: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> Date: Tue, 14 Jun 2011 18:10:58 -0700 X-Google-Sender-Auth: 8xcKQgB-SovU2CjWHNf2frg3_38 Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: Randy Presuhn Content-Type: multipart/alternative; boundary=000e0cd4c08e388c0a04a5b5d3ba Cc: LTRU Working Group Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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, 15 Jun 2011 01:11:03 -0000 --000e0cd4c08e388c0a04a5b5d3ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are major problems with that approach. Where should comments be directed? Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* ---------- Forwarded message ---------- From: Randy Presuhn Date: Mon, Jun 13, 2011 at 11:34 Subject: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt To: LTRU Working Group Hi - This sounds like something folks on this list might find of interest. Randy > From: > To: > Sent: Monday, June 13, 2011 8:38 AM > Subject: I-D Action: draft-falk-transliteration-tags-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Tags for the Identification of Transliterated Text > Author(s) : Courtney Falk > Filename : draft-falk-transliteration-tags-01.txt > Pages : 7 > Date : 2011-06-13 > > This document describes the structure, content, creation, and > semantics of language tags for use in describing text that was > transliterated from one orthographic system to another. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-falk-transliteration-tags-01.tx= t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-falk-transliteration-tags-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru --000e0cd4c08e388c0a04a5b5d3ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are major problems with that approach. Where should comme= nts be directed?

= Mark

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


---------- Forwarded message ----------<= br>From: Randy Presuhn = <randy_presuhn@mindsprin= g.com>
Date: Mon, Jun 13, 2011 at 11:34
Subject: [Ltru] Fw: I-D Action: draft-f= alk-transliteration-tags-01.txt
To: LTRU Working Group <ltru@ietf.org>


Hi -

This sounds like something folks on this list might find of interest.

Randy

> From: <internet-drafts@= ietf.org>
> To: <i-d-announce@ietf.org= >
> Sent: Monday, June 13, 2011 8:38 AM
> Subject: I-D Action: draft-falk-transliteration-tags-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
> Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Tags for the Identification= of Transliterated Text
> Author(s) =C2=A0 =C2=A0 =C2=A0 : Courtney Falk
> Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-falk-transliteration-tags-= 01.txt
> Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7
> Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2011-06-13
>
> =C2=A0 =C2=A0This document describes the structure, content, creation,= and
> =C2=A0 =C2=A0semantics of language tags for use in describing text tha= t was
> =C2=A0 =C2=A0transliterated from one orthographic system to another. >
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draf= t-falk-transliteration-tags-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-= falk-transliteration-tags-01.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

--000e0cd4c08e388c0a04a5b5d3ba-- From duerst@it.aoyama.ac.jp Tue Jun 14 18:38:10 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 9696111E8079 for ; Tue, 14 Jun 2011 18:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.79 X-Spam-Level: X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTYSO5limZUs for ; Tue, 14 Jun 2011 18:38:09 -0700 (PDT) Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 91BF311E8076 for ; Tue, 14 Jun 2011 18:38:03 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p5F1bt6G010408 for ; Wed, 15 Jun 2011 10:37:55 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 7fed_cd5c_179988da_96f0_11e0_8e46_001d0969ab06; Wed, 15 Jun 2011 10:37:55 +0900 Received: from [IPv6:::1] ([133.2.210.5]:42622) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 15 Jun 2011 10:37:50 +0900 Message-ID: <4DF80CD1.1090907@it.aoyama.ac.jp> Date: Wed, 15 Jun 2011 10:37:21 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= References: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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, 15 Jun 2011 01:38:10 -0000 I suggest you send them to the author and copy this list (or the ietf-languages list, but not both, please). That way, you can point to them later if necessary. Regards, Martin. On 2011/06/15 10:10, Mark Davis ☕ wrote: > There are major problems with that approach. Where should comments be > directed? > > Mark > > *— Il meglio è l’inimico del bene —* > > > ---------- Forwarded message ---------- > From: Randy Presuhn > Date: Mon, Jun 13, 2011 at 11:34 > Subject: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt > To: LTRU Working Group > > > Hi - > > This sounds like something folks on this list might find of interest. > > Randy > >> From: >> To: >> Sent: Monday, June 13, 2011 8:38 AM >> Subject: I-D Action: draft-falk-transliteration-tags-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> Title : Tags for the Identification of Transliterated Text >> Author(s) : Courtney Falk >> Filename : draft-falk-transliteration-tags-01.txt >> Pages : 7 >> Date : 2011-06-13 >> >> This document describes the structure, content, creation, and >> semantics of language tags for use in describing text that was >> transliterated from one orthographic system to another. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-falk-transliteration-tags-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-falk-transliteration-tags-01.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru From randy_presuhn@mindspring.com Wed Jun 15 10:15:06 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 C7CDB21F8486 for ; Wed, 15 Jun 2011 10:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d75ARGxnFCOZ for ; Wed, 15 Jun 2011 10:15:06 -0700 (PDT) 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 CD3CF21F8543 for ; Wed, 15 Jun 2011 10:15:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WnX1t4ZgmwRFoPmRZ5OSydqNqMaHQct1qJb7taCWDvs9qvA+fGO6SVCeB1FyzNnA; 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.187.238.207] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QWtgH-0007EW-1K for ltru@ietf.org; Wed, 15 Jun 2011 13:15:05 -0400 Message-ID: <000e01cc2b80$563628e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> <4DF80CD1.1090907@it.aoyama.ac.jp> Date: Wed, 15 Jun 2011 10:19:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b38226128258301dca347e3af5f7b07c2d0a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.238.207 Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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, 15 Jun 2011 17:15:06 -0000 Hi - > From: "Martin J. Dürst" > To: "Mark Davis ☕" > Cc: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, June 14, 2011 6:37 PM > Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt > > I suggest you send them to the author and copy this list (or the > ietf-languages list, but not both, please). That way, you can point to > them later if necessary. ... I have already sent some directly to the author, but my comments barely scratched the surface, so I'm sure additional comments would be helpful. > On 2011/06/15 10:10, Mark Davis ☕ wrote: > > There are major problems with that approach. Indeed. Randy From randy_presuhn@mindspring.com Wed Jun 15 10:46:11 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 B5DDF11E80B5 for ; Wed, 15 Jun 2011 10:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOVrthtb5U8Z for ; Wed, 15 Jun 2011 10:46:11 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC7511E8090 for ; Wed, 15 Jun 2011 10:46:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tdzulqHVg8NNLGi5miJxPQOiwyizHS6HnrWT5CPOZk5bZmaF2UY2ylnu2Dv7K/+g; 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.187.238.207] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QWuAM-0003UT-KV for ltru@ietf.org; Wed, 15 Jun 2011 13:46:10 -0400 Message-ID: <003d01cc2b84$af13f560$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer><4DF80CD1.1090907@it.aoyama.ac.jp> <000e01cc2b80$563628e0$6801a8c0@oemcomputer> <2CB55BFC7405E94F830537BD924318D5EBF06DE3BF@USSDIXMSG11.am.sony.com> Date: Wed, 15 Jun 2011 10:50:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b382588c0f59a1c3e0cce7953c0b2d503d82350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.238.207 Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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, 15 Jun 2011 17:46:11 -0000 Hi - I started out with an off-list response, but I figure this is something worth sending to the list. Off-list, a contributor asked: ... > I'd love to see your input. I'd like to make sure I understand > all the concerns. Is there any way you could forward this to the list? My response: Sorry, already deleted. As I recall, the main concerns were (1) there already *is* support for identifying orthographies (remember German?) (2) the I-D seems to assume that transliterations always result in "Latin" (previous discussion on LTRU included transliterations to Cyrillic and Hangul, among others) (3) the "original orthography" is irrelevant for the transliteration systems I've been able to think of. (At the same time, some transliteration systems are quite "lossy" and some don't do "round trip" very well.) Consider also the transliteration of material which was originally in audio form... (4) The draft doesn't clearly distinguish "orthography" from "transliteration". This may be because the boundary between the two can be fuzzy, but even that is an issue that should be addressed. (5) How this fits in with *transcription* systems (e.g. IPA) should be addressed. The boundary gets fuzzy with orthographies that are equivalent to phonemic representations of the language. (e.g., Pinyin for Mandarin) (6) The proposed singleton usage appears broken and unnecessary. Or something like that. I may have forgotten something here, or, in the process of reconstruction, thought of something I missed the first time. Randy From cowan@ccil.org Wed Jun 15 11:05:55 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 7DECC21F851F for ; Wed, 15 Jun 2011 11:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d81AVqL84dv1 for ; Wed, 15 Jun 2011 11:05:54 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDAF21F851E for ; Wed, 15 Jun 2011 11:05:54 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.69) (envelope-from ) id 1QWuTQ-0006zf-Fm; Wed, 15 Jun 2011 14:05:52 -0400 Date: Wed, 15 Jun 2011 14:05:52 -0400 From: John Cowan To: Randy Presuhn Message-ID: <20110615180552.GA22853@mercury.ccil.org> References: <000e01cc2b80$563628e0$6801a8c0@oemcomputer> <2CB55BFC7405E94F830537BD924318D5EBF06DE3BF@USSDIXMSG11.am.sony.com> <003d01cc2b84$af13f560$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003d01cc2b84$af13f560$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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, 15 Jun 2011 18:05:55 -0000 Randy Presuhn scripsit: > (3) the "original orthography" is irrelevant for the transliteration > systems I've been able to think of. (At the same time, some > transliteration systems are quite "lossy" and some don't do "round > trip" very well.) Consider also the transliteration of material > which was originally in audio form... Transliteration proper maps the symbols of one script onto the symbols of another, typically in a reversible way. Therefore, the original orthography is essential to it: Petrine Russian transliterated to Latin will look different from modern Russian, because Petrine Russian has letters that don't exist in modern Russian. Transcription as opposed to transliteration is specific to a pair of languages, and is typically not sensitive to the orthography of the source. -- After fixing the Y2K bug in an application: John Cowan WELCOME TO cowan@ccil.org DATE: MONDAK, JANUARK 1, 1900 http://www.ccil.org/~cowan From randy_presuhn@mindspring.com Wed Jun 15 11:39:24 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 6561911E8153 for ; Wed, 15 Jun 2011 11:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D45r3DJdXX6 for ; Wed, 15 Jun 2011 11:39:23 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id B754B11E8141 for ; Wed, 15 Jun 2011 11:39:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=InRLWU5l6QeYC/mcjlwWaXU4uSkrqPI6+bot93OOxUUr/8+UNEj21Z05AYTUje/j; 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.187.238.207] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QWuzq-0000k7-W2 for ltru@ietf.org; Wed, 15 Jun 2011 14:39:23 -0400 Message-ID: <005101cc2b8c$1cce4e00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <000e01cc2b80$563628e0$6801a8c0@oemcomputer> <2CB55BFC7405E94F830537BD924318D5EBF06DE3BF@USSDIXMSG11.am.sony.com> <003d01cc2b84$af13f560$6801a8c0@oemcomputer> <20110615180552.GA22853@mercury.ccil.org> Date: Wed, 15 Jun 2011 11:43:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b382fe91a901e65a85b861ca70213ef3cf77350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.238.207 Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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, 15 Jun 2011 18:39:24 -0000 Hi - > From: "John Cowan" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Wednesday, June 15, 2011 11:05 AM > Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt ... > Transliteration proper maps the symbols of one script onto the symbols > of another, typically in a reversible way. Therefore, the original > orthography is essential to it: Petrine Russian transliterated to Latin > will look different from modern Russian, because Petrine Russian has > letters that don't exist in modern Russian. ... I'd consider those to be different transliteration systems, rather than a single system accomodating multiple orthographies. But that's just a different way of slicing the pie, so we're probably in violent agreement. The "reversability" problem is bigger here. The only system that provides for the *really* old letters (pre-Petrine) loses the Ф/Ѳ and И/І distinctions that were abolished in the 1918 orthographic reforms. The new passport system loses the "ye/yo" distinction. (Some Russian printed material doesn't make the distinction as well, collapsing both letters into "ye", making life complicated for learners :-) Some sequences of letters become ambiguous in some systems. In short, it's a mess, even though as a practical matter these systems get the job done. (I've noticed that in practice, some transliterations *aren't*, at least in the narrow sense you propose, for the common sequence "yego", which is pronounced "yevo", and frequently (but not always!) "transliterated" "yevo". The boundary between transliteration and transcription, though formally clear, gets fuzzy in practice.) Randy From doug@ewellic.org Wed Jun 15 12:30:44 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 E656621F859C for ; Wed, 15 Jun 2011 12:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4luaMWcdVbm for ; Wed, 15 Jun 2011 12:30:43 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id 1D6C621F8597 for ; Wed, 15 Jun 2011 12:30:43 -0700 (PDT) Received: (qmail 21789 invoked from network); 15 Jun 2011 19:30:42 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 15 Jun 2011 19:30:42 -0000 Received: (qmail 15016 invoked by uid 99); 15 Jun 2011 19:30:42 -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.5.04 Message-Id: <20110615123041.665a7a7059d7ee80bb4d670165c8327d.da9e254c54.wbe@email03.secureserver.net> From: "Doug Ewell" To: ltru@ietf.org Date: Wed, 15 Jun 2011 12:30:41 -0700 Mime-Version: 1.0 Cc: court@infiauto.com Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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, 15 Jun 2011 19:30:44 -0000 Mark Davis =F0=9F=8D=A3 wrote: > There are major problems with that approach. Where should comments > be directed? One of the major problems with this draft, which hasn't been mentioned yet, is that RFC 5646, Section 3.7 sets out specific requirements for extensions. It's not enough just to have an RFC that proposes singletons: the singletons must be formally communicated to IANA and added to the extensions registry, there must be a registry of valid subtags, there must be a registering authority and discussion mailing list, etc. The present draft does not meet any of these requirements. The draft states that the 's' singleton would be followed by "the ISO 15924 for the source script" (part of the draft's underlying misconception that ISO code elements, not subtags from the LSR, are directly used in language tags) and that the 't' singleton would be followed by "a 2-8 character alphanumeric string abbreviation of the transliteration system," There is no list, or pointer to a list, of 't' subtags, nor any indication or assurance of their stability as required by Section 3.7. The draft says there are no IANA considerations, which is far from true for a BCP 47 extension. A comparison with RFC 6067 (the 'u' extension) would be helpful in understanding how the BCP 47 requirements should be fulfilled. While I was surprised by the RFC 6067 implementation of "registry" as a set of CLDR XML files, there is definitely a well-defined, freely accessible list of subtags, a mailing list where users can ask questions about then, and a process for proposing new ones. I am a believer in the concept of BCP 47 extensions and would welcome a better-conceived proposal that follows the BCP 47 rules and takes existing BCP 47 mechanisms into better account (e.g. variant subtags already exist for several transliteration systems). The present proposal is not suitable. -- Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14 www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell =C2=AD From mark.edward.davis@gmail.com Fri Jun 17 14:07:51 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 EA4F711E80EF for ; Fri, 17 Jun 2011 14:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQGn0nPcFz9P for ; Fri, 17 Jun 2011 14:07:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83511E807F for ; Fri, 17 Jun 2011 14:07:51 -0700 (PDT) Received: by yxt33 with SMTP id 33so2391715yxt.31 for ; Fri, 17 Jun 2011 14:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sqlvEoNOvl5Ulf0nqVJT2o6Kh+FM8j67ZzxfoZ5cGEs=; b=A+eqSRxuRU5fanAgsxp6GUF4FbGNz9K1MKe+aIq0esmtGWwWSz9/zED9Uk007CX56Q wihTJ9NqWPvo1H791WgWcIKfqBO8EqSgyD9kxO3w47qVCRvtSZ8ZYSArbOZRy+LNt2tq XOYdII+6/+gvegFXaTnEM6jGd3SS93HReNsg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=borl9J4fpS0TgpiUfRCd8IEDc4cfM7U6RoOggpjushNLKv3ylBZu0RknFV8yHz8sHR WnJAZg3t7pVAgWkPYgE9zZjDY7ZrnagiIK6ZJxoyjNvH5itLmeJoYgoXYZx7clD7DO8a XBx6toDJKFYnKwr6wbKQBTmRs5T6rmiMyabDg= MIME-Version: 1.0 Received: by 10.151.43.8 with SMTP id v8mr2874341ybj.296.1308344870448; Fri, 17 Jun 2011 14:07:50 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.151.156.18 with HTTP; Fri, 17 Jun 2011 14:07:50 -0700 (PDT) In-Reply-To: <003d01cc2b84$af13f560$6801a8c0@oemcomputer> References: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> <4DF80CD1.1090907@it.aoyama.ac.jp> <000e01cc2b80$563628e0$6801a8c0@oemcomputer> <2CB55BFC7405E94F830537BD924318D5EBF06DE3BF@USSDIXMSG11.am.sony.com> <003d01cc2b84$af13f560$6801a8c0@oemcomputer> Date: Fri, 17 Jun 2011 14:07:50 -0700 X-Google-Sender-Auth: piLwsxBBiwqEhMTSkxmwGlUciJg Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: Randy Presuhn , court@infiauto.com Content-Type: multipart/alternative; boundary=00151750d9e63f2f6104a5eec7d3 Cc: LTRU Working Group Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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: Fri, 17 Jun 2011 21:07:52 -0000 --00151750d9e63f2f6104a5eec7d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoshito, Addison, and I had had an action for a while now from the CLDR committee to submit a draft for a an extension. Rather than go through all the problems in the falk draft, we put together an alternative approach, leveraging the work we already did for the -u- extension. It just got posted at http://tools.ietf.org/html/draft-davis-t-langtag-ext-00 Courtney, I think this provides a superset of the functionality that you ar= e interested in. Perhaps you can read it over, and we can add you as an autho= r of the next version of this draft instead of having the two competing proposals. Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* On Wed, Jun 15, 2011 at 10:50, Randy Presuhn wrote: > Hi - > > I started out with an off-list response, but I figure this is > something worth sending to the list. > > Off-list, a contributor asked: > > ... > > I'd love to see your input. I'd like to make sure I understand > > all the concerns. Is there any way you could forward this to the list? > > My response: > > Sorry, already deleted. As I recall, the main concerns were > > (1) there already *is* support for identifying orthographies > (remember German?) > (2) the I-D seems to assume that transliterations always result > in "Latin" (previous discussion on LTRU included transliterations > to Cyrillic and Hangul, among others) > (3) the "original orthography" is irrelevant for the transliteration > systems I've been able to think of. (At the same time, some > transliteration systems are quite "lossy" and some don't do > "round trip" very well.) Consider also the transliteration of > material > which was originally in audio form... > (4) The draft doesn't clearly distinguish "orthography" from > "transliteration". > This may be because the boundary between the two can be fuzzy, but > even > that is an issue that should be addressed. > (5) How this fits in with *transcription* systems (e.g. IPA) should be > addressed. The boundary gets fuzzy with orthographies that are > equivalent > to phonemic representations of the language. (e.g., Pinyin for > Mandarin) > (6) The proposed singleton usage appears broken and unnecessary. > > Or something like that. I may have forgotten something here, or, in the > process of reconstruction, thought of something I missed the first time. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --00151750d9e63f2f6104a5eec7d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoshito, Addison, and I had had an act= ion for a while now from the CLDR committee to submit a draft for a an exte= nsion. Rather than go through all the problems in the falk draft, we put to= gether an alternative approach, leveraging the work we already did for the = -u- extension.

It just got pos= ted at=C2=A0http://tools.ietf.org/html/draft-davis-t-langtag-ext-00

Courtney, I think this provides a superset of th= e functionality that you are interested in. Perhaps you can read it over, a= nd we can add you as an author of the next version of this draft instead of= having the two competing proposals.

= Mark

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


On Wed, Jun 15, 2011 at 10:50, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

I started out with an off-list response, but I figure this is
something worth sending to the list.

Off-list, a contributor asked:

...
> I'd love to see your input. I'd like to make sure I understand=
> all the concerns. Is there any way you could forward this to the list?=

My response:

Sorry, already deleted. =C2=A0As I recall, the main concerns were

=C2=A0(1) there already *is* support for identifying orthographies
=C2=A0 =C2=A0 =C2=A0(remember German?)
=C2=A0(2) the I-D seems to assume that transliterations always result
=C2=A0 =C2=A0 =C2=A0in "Latin" (previous discussion on LTRU incl= uded transliterations
=C2=A0 =C2=A0 =C2=A0to Cyrillic and Hangul, among others)
=C2=A0(3) the "original orthography" is irrelevant for the trans= literation
=C2=A0 =C2=A0 =C2=A0systems I've been able to think of. =C2=A0(At the = same time, some
=C2=A0 =C2=A0 =C2=A0transliteration systems are quite "lossy" an= d some don't do
=C2=A0 =C2=A0 =C2=A0"round trip" very well.) =C2=A0Consider also= the transliteration of material
=C2=A0 =C2=A0 =C2=A0which was originally in audio form...
=C2=A0(4) The draft doesn't clearly distinguish "orthography"= ; from "transliteration".
=C2=A0 =C2=A0 =C2=A0This may be because the boundary between the two can b= e fuzzy, but even
=C2=A0 =C2=A0 =C2=A0that is an issue that should be addressed.
=C2=A0(5) How this fits in with *transcription* systems (e.g. IPA) should = be
=C2=A0 =C2=A0 =C2=A0addressed. =C2=A0The boundary gets fuzzy with orthogra= phies that are equivalent
=C2=A0 =C2=A0 =C2=A0to phonemic representations of the language. =C2=A0(e.= g., Pinyin for Mandarin)
=C2=A0(6) The proposed singleton usage appears broken and unnecessary.

Or something like that. =C2=A0I may have forgotten something here, or, in t= he
process of reconstruction, thought of something I missed the first time.

Randy

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

--00151750d9e63f2f6104a5eec7d3-- From court@infiauto.com Fri Jun 17 19:44: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 7BD1711E80F8 for ; Fri, 17 Jun 2011 19:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7PKeqYHXlXe for ; Fri, 17 Jun 2011 19:44:40 -0700 (PDT) Received: from mx10.antispamcloud.com (delivery.antispamcloud.com [173.224.112.117]) by ietfa.amsl.com (Postfix) with ESMTP id AFFB511E81C7 for ; Fri, 17 Jun 2011 19:44:40 -0700 (PDT) Received: from lobster.arvixe.com ([174.122.140.66]) by mx10.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QXlWU-0007bl-RZ; Sat, 18 Jun 2011 04:44:39 +0200 Received: from [96.241.147.220] (helo=[192.168.1.248]) by lobster.arvixe.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QXlWR-001lO0-Mi; Fri, 17 Jun 2011 19:44:31 -0700 Message-ID: <4DFC110F.9070206@infiauto.com> Date: Fri, 17 Jun 2011 22:44:31 -0400 From: Courtney Falk Organization: Infinite Automata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= References: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> <4DF80CD1.1090907@it.aoyama.ac.jp> <000e01cc2b80$563628e0$6801a8c0@oemcomputer> <2CB55BFC7405E94F830537BD924318D5EBF06DE3BF@USSDIXMSG11.am.sony.com> <003d01cc2b84$af13f560$6801a8c0@oemcomputer> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090907090205000805010000" X-Filter-ID: XtLePq6GTMn8G68F0EmQvTBXL25mGtm8/SbWrgn8toFYmXQ3ZQ/FRfkBY7OZtiA7JYRGiu4wDuX/ sGw1Y7RAsTZj9Z77VY13dRgr2psAOGiV+1GQfaAmTCJL+6Me4aiTG0jcJ2jq49NGEcwdCyQ3eBNc FrjCbtVP4vwtw+SEClfowRhTcmW9dbCrg8F9crYxLIRa6rN8055kXeh9h5eIGUe7MtA1G307dR6e iYLyeFfkyS/b7+RzgSSp5p4Hi96VfJLpMvDkG27ShZCnqlyeja9NeaW+O2Pk6giVAyByJj4f4owT EtTTUOwR3+hSksaMwLGqAf7zrp+4jedRkM7RyqCl7jNYUEMNPmtaqDqCK0oJH6sC5oCk/8v9mZ1n Ys+93ma/mRzF2AoVfsFHxgoSuuVhj+uxLnRfZX4WjzprUJYJYLE570VTJleGTZs8BBPFlGS52+Wg bSFMsU7xdA1g/CgNDeSsUsoDzz/5u9DW4UBXMMf2ivh8PZ4CC53k6S6z49hHSXu2kGkJbdUwkm0t JqW726nWiJet6q9F0IK1cajTGIVL1ZftMLaDabQBXCE6DPAWL0lqEbmGiITJD5GZh2bDupOgBPeF 26wOhm3sZlY/OMVuzRyqIKdfJZx16Jg+ X-Originating-IP: 174.122.140.66 Authentication-Results: antispamcloud.com; auth=pass () smtp.auth=174.122.140.66 X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: SB/global_tokens (0.00139390157347) X-Mailman-Approved-At: Sat, 18 Jun 2011 15:55:15 -0700 Cc: LTRU Working Group Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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: Sat, 18 Jun 2011 15:31:29 -0000 This is a multi-part message in MIME format. --------------090907090205000805010000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Mark, After reading through your draft I think it better encompasses what I was intending. I'd be glad to be included as a co-author. Courtney On 06/17/2011 05:07 PM, Mark Davis ☕ wrote: > Yoshito, Addison, and I had had an action for a while now from the > CLDR committee to submit a draft for a an extension. Rather than go > through all the problems in the falk draft, we put together an > alternative approach, leveraging the work we already did for the -u- > extension. > > It just got posted at > http://tools.ietf.org/html/draft-davis-t-langtag-ext-00 > > Courtney, I think this provides a superset of the functionality that > you are interested in. Perhaps you can read it over, and we can add > you as an author of the next version of this draft instead of having > the two competing proposals. > > Mark > > /— Il meglio è l’inimico del bene —/ > > > On Wed, Jun 15, 2011 at 10:50, Randy Presuhn > > > wrote: > > Hi - > > I started out with an off-list response, but I figure this is > something worth sending to the list. > > Off-list, a contributor asked: > > ... > > I'd love to see your input. I'd like to make sure I understand > > all the concerns. Is there any way you could forward this to the > list? > > My response: > > Sorry, already deleted. As I recall, the main concerns were > > (1) there already *is* support for identifying orthographies > (remember German?) > (2) the I-D seems to assume that transliterations always result > in "Latin" (previous discussion on LTRU included transliterations > to Cyrillic and Hangul, among others) > (3) the "original orthography" is irrelevant for the transliteration > systems I've been able to think of. (At the same time, some > transliteration systems are quite "lossy" and some don't do > "round trip" very well.) Consider also the transliteration > of material > which was originally in audio form... > (4) The draft doesn't clearly distinguish "orthography" from > "transliteration". > This may be because the boundary between the two can be > fuzzy, but even > that is an issue that should be addressed. > (5) How this fits in with *transcription* systems (e.g. IPA) > should be > addressed. The boundary gets fuzzy with orthographies that > are equivalent > to phonemic representations of the language. (e.g., Pinyin > for Mandarin) > (6) The proposed singleton usage appears broken and unnecessary. > > Or something like that. I may have forgotten something here, or, > in the > process of reconstruction, thought of something I missed the first > time. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > --------------090907090205000805010000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Mark,

After reading through your draft I think it better encompasses what I was intending.  I'd be glad to be included as a co-author.


Courtney

On 06/17/2011 05:07 PM, Mark Davis ☕ wrote:
Yoshito, Addison, and I had had an action for a while now from the CLDR committee to submit a draft for a an extension. Rather than go through all the problems in the falk draft, we put together an alternative approach, leveraging the work we already did for the -u- extension.


Courtney, I think this provides a superset of the functionality that you are interested in. Perhaps you can read it over, and we can add you as an author of the next version of this draft instead of having the two competing proposals.

Mark

— Il meglio è l’inimico del bene —


On Wed, Jun 15, 2011 at 10:50, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
Hi -

I started out with an off-list response, but I figure this is
something worth sending to the list.

Off-list, a contributor asked:

...
> I'd love to see your input. I'd like to make sure I understand
> all the concerns. Is there any way you could forward this to the list?

My response:

Sorry, already deleted.  As I recall, the main concerns were

 (1) there already *is* support for identifying orthographies
     (remember German?)
 (2) the I-D seems to assume that transliterations always result
     in "Latin" (previous discussion on LTRU included transliterations
     to Cyrillic and Hangul, among others)
 (3) the "original orthography" is irrelevant for the transliteration
     systems I've been able to think of.  (At the same time, some
     transliteration systems are quite "lossy" and some don't do
     "round trip" very well.)  Consider also the transliteration of material
     which was originally in audio form...
 (4) The draft doesn't clearly distinguish "orthography" from "transliteration".
     This may be because the boundary between the two can be fuzzy, but even
     that is an issue that should be addressed.
 (5) How this fits in with *transcription* systems (e.g. IPA) should be
     addressed.  The boundary gets fuzzy with orthographies that are equivalent
     to phonemic representations of the language.  (e.g., Pinyin for Mandarin)
 (6) The proposed singleton usage appears broken and unnecessary.

Or something like that.  I may have forgotten something here, or, in the
process of reconstruction, thought of something I missed the first time.

Randy

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


--------------090907090205000805010000-- From duerst@it.aoyama.ac.jp Mon Jun 20 23:39: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 29E0E11E813C for ; Mon, 20 Jun 2011 23:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.878 X-Spam-Level: X-Spam-Status: No, score=-99.878 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ92C3-Wgii6 for ; Mon, 20 Jun 2011 23:39:33 -0700 (PDT) Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9B111E80CF for ; Mon, 20 Jun 2011 23:39:32 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p5L6dMvB025812 for ; Tue, 21 Jun 2011 15:39:22 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 446d_7a84_32ab303e_9bd1_11e0_9ce4_001d0969ab06; Tue, 21 Jun 2011 15:39:22 +0900 Received: from [IPv6:::1] ([133.2.210.5]:38817) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 21 Jun 2011 15:39:16 +0900 Message-ID: <4E003C87.5090009@it.aoyama.ac.jp> Date: Tue, 21 Jun 2011 15:39:03 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= References: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> <4DF80CD1.1090907@it.aoyama.ac.jp> <000e01cc2b80$563628e0$6801a8c0@oemcomputer> <2CB55BFC7405E94F830537BD924318D5EBF06DE3BF@USSDIXMSG11.am.sony.com> <003d01cc2b84$af13f560$6801a8c0@oemcomputer> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group , court@infiauto.com Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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: Tue, 21 Jun 2011 06:39:34 -0000 Hello Mark, others, Overall comment: The idea to reuse language tags to indicate transliteration/transcription source, and to add some additional tags to distinguish methods seems to be reasonable and sound. The description of the structure of the allowed subtags and of the responsibility split between IETF (this draft) and UTC (UTS 35) looks quite messy to me, and should be cleaned up. I'd personally prefer that UTS 35 (or whatever else on the Unicode side) only define the part (after the m0 subtag). Detailled comments: "In addition, it may also be important to specify a particular specification for the transformation.": Too much 'spec' in one sentence. "For example, if one is transcribing the names of Italian or Russian cities on a map for Japanese users, each name will need to be transliterated into katakana using rules appropriate for the source language and target languages.": "source languages and target language"? BCP47 required information: The first three paragraphs should move to the introduction. "followed by a sequence of subtags that would form a language tag": Here and in general: Don't use 'would'. >>>> The structure of 't' subtags is determined by the Unicode CLDR Technical Committee, in accordance with the policies and procedures in http://www.unicode.org/consortium/tc-procedures.html, and subject to the Unicode Consortium Policies on http://www.unicode.org/policies/policies.html. >>>> The following paragraph is also difficult to understand. I wouldn't know exactly what falls on what side. I think one major reason is that we are treading new ground here, it's the first time we have a singleton definition that allows reuse of language tags (with a few restrictions) as well as intends to define its own extensions. >>>> Changes that can be made by successive versions of LDML [UTS35] by the Unicode Consortium without requiring a new RFC include the allocation of new subtags for use after the 't' extension. A new RFC would be required for material changes to an existing 't' subtag, or an incompatible change to the overall syntactic structure of the 't' extension; however, such a change would be contrary to the policies of the Unicode Consortium, and thus is not anticipated. >>>> 2.1 Summary: There seems to be quite some overlap between the part of section 2 before the 2.1 heading. One question I would have as a linguistic researcher is: How much effort and time is involved in getting a 'mechanism' approved? If such 'mechanisms' are e.g. rejected with arguments like "if we accept it, then everybody has to implement it" or so, then I would see that as a problem. So much for the moment. Regards, Martin. On 2011/06/18 6:07, Mark Davis ☕ wrote: > Yoshito, Addison, and I had had an action for a while now from the CLDR > committee to submit a draft for a an extension. Rather than go through all > the problems in the falk draft, we put together an alternative approach, > leveraging the work we already did for the -u- extension. > > It just got posted at > http://tools.ietf.org/html/draft-davis-t-langtag-ext-00 > > Courtney, I think this provides a superset of the functionality that you are > interested in. Perhaps you can read it over, and we can add you as an author > of the next version of this draft instead of having the two competing > proposals. > > Mark > > *— Il meglio è l’inimico del bene —* > > > On Wed, Jun 15, 2011 at 10:50, Randy Presuhn > wrote: > >> Hi - >> >> I started out with an off-list response, but I figure this is >> something worth sending to the list. >> >> Off-list, a contributor asked: >> >> ... >>> I'd love to see your input. I'd like to make sure I understand >>> all the concerns. Is there any way you could forward this to the list? >> >> My response: >> >> Sorry, already deleted. As I recall, the main concerns were >> >> (1) there already *is* support for identifying orthographies >> (remember German?) >> (2) the I-D seems to assume that transliterations always result >> in "Latin" (previous discussion on LTRU included transliterations >> to Cyrillic and Hangul, among others) >> (3) the "original orthography" is irrelevant for the transliteration >> systems I've been able to think of. (At the same time, some >> transliteration systems are quite "lossy" and some don't do >> "round trip" very well.) Consider also the transliteration of >> material >> which was originally in audio form... >> (4) The draft doesn't clearly distinguish "orthography" from >> "transliteration". >> This may be because the boundary between the two can be fuzzy, but >> even >> that is an issue that should be addressed. >> (5) How this fits in with *transcription* systems (e.g. IPA) should be >> addressed. The boundary gets fuzzy with orthographies that are >> equivalent >> to phonemic representations of the language. (e.g., Pinyin for >> Mandarin) >> (6) The proposed singleton usage appears broken and unnecessary. >> >> Or something like that. I may have forgotten something here, or, in the >> process of reconstruction, thought of something I missed the first time. >> >> Randy >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www.ietf.org/mailman/listinfo/ltru >> > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru From mark.edward.davis@gmail.com Tue Jun 21 09:00: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 BF83F11E829F for ; Tue, 21 Jun 2011 09:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Pnq4rrsiD19 for ; Tue, 21 Jun 2011 09:00:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB24711E8299 for ; Tue, 21 Jun 2011 09:00:31 -0700 (PDT) Received: by gya6 with SMTP id 6so1768991gya.31 for ; Tue, 21 Jun 2011 09:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YzyQS2C9CokNEiTypKdHZl9Pi8VKQcw6uB9UDrsGefU=; b=fBiLIksuTGocIn3yF2+G/x/PIb2/xqi9WeomgxYO8SbwGozCqFaLKry1rYjsV4JfIC skI2qEC0qf6OLiGNhZ+bUigC+CHOCVRmqwDSNJIi9kVsDPq0LdI8DHOoDISkvsmlmMye utYw9VCTJlj8v/nLpKPxt/k1MMECcVRBe5ZRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=HbuAZ1/UJD4uge8QW/TY1XfNz2gpX2A3O3O/M3bf2WdRRPBdiOC5xfc+jKzI7tVVqd mJ+5AmdyrfpjVINiw+BCjZngRU5WgLDnhIkUUe6Aum8A05tcoZlfuNgafZlG+dIoYgDH m7ZkNsZ+LTNNtn9Y5Fu1ygBB/6mMsPOrAE54A= MIME-Version: 1.0 Received: by 10.151.118.10 with SMTP id v10mr7593484ybm.23.1308672029364; Tue, 21 Jun 2011 09:00:29 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.151.146.9 with HTTP; Tue, 21 Jun 2011 09:00:29 -0700 (PDT) In-Reply-To: <4E003C87.5090009@it.aoyama.ac.jp> References: <002701cc29f8$7c3e7d00$6801a8c0@oemcomputer> <4DF80CD1.1090907@it.aoyama.ac.jp> <000e01cc2b80$563628e0$6801a8c0@oemcomputer> <2CB55BFC7405E94F830537BD924318D5EBF06DE3BF@USSDIXMSG11.am.sony.com> <003d01cc2b84$af13f560$6801a8c0@oemcomputer> <4E003C87.5090009@it.aoyama.ac.jp> Date: Tue, 21 Jun 2011 09:00:29 -0700 X-Google-Sender-Auth: 2T6oqDRuiTCmyGQgtGSglecvz2g Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001e680f184070124604a63af3a3 Cc: LTRU Working Group , court@infiauto.com Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt 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: Tue, 21 Jun 2011 16:00:35 -0000 --001e680f184070124604a63af3a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Those are good issues; thanks for raising them and starting the discussion. Comments below. ------------------------------ Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* On Mon, Jun 20, 2011 at 23:39, "Martin J. D=C3=BCrst" wrote: > Hello Mark, others, > > Overall comment: > The idea to reuse language tags to indicate transliteration/transcription > source, and to add some additional tags to distinguish methods seems to b= e > reasonable and sound. > > The description of the structure of the allowed subtags and of the > responsibility split between IETF (this draft) and UTC (UTS 35) looks qui= te > messy to me, and should be cleaned up. I'd personally prefer that UTS 35 = (or > whatever else on the Unicode side) only define the part (afte= r > the m0 subtag). > That would be my preference as well (can't speak for my coauthors). We patterned it this way following what ended up being accepted for the -u= - extension. That is, the spec is in UTS35, but there is a summary here. But of course, there are many ways to do it. And maybe this summary is too detailed, at least for the mechanism part, and we could just have it in UTS35. We considered a number of alternatives: - We could define everything after -t- to be the source language, and everything after -m- to be the mechanism. But that burns 2 extension letters, just one. - We also considered having everything in the -u extension, for which we already have the structure set up. However, that would force us to have artificial source subtags like 'en0' instead of 'en', because the -u- extension wouldn't allow the 2-letter subtags (it already defines a use = for them). - We could also have -t- be just the source, and define the mechanism in -u-, also easy. But we felt it would be better to have everything under = one extension. > > > Detailled comments: > > "In addition, it may also be important to > specify a particular specification for the transformation.": Too much > 'spec' in one sentence. > ok > > "For example, if one is transcribing the names of Italian or Russian > cities on a map for Japanese users, each name will need to be > transliterated into katakana using rules appropriate for the source > language and target languages.": "source languages and target language"= ? > yes > > BCP47 required information: The first three paragraphs should move to the > introduction. > Other authors, what do you think? > > "followed by a sequence of subtags that would form a language tag": Here > and in general: Don't use 'would'. > Grammatically, it is that the sequence of subtags *would* form a language subtag if they *were* separated out. They are not actually a language tag, because they occur in the middle of another language subtag. How would you like that to be phrased? > >>>> > The structure of 't' subtags is determined by the Unicode CLDR > Technical Committee, in accordance with the policies and procedures > in http://www.unicode.org/**consortium/tc-procedures.html, > and subject > to the Unicode Consortium Policies on > http://www.unicode.org/**policies/policies.html > . > >>>> > > > The following paragraph is also difficult to understand. I wouldn't know > exactly what falls on what side. I think one major reason is that we are > treading new ground here, it's the first time we have a singleton definit= ion > that allows reuse of language tags (with a few restrictions) as well as > intends to define its own extensions. > These were both patterned after what was used for the -u- extension. We can take a look at them to try to clarify. > > >>>> > Changes that can be made by successive versions of LDML [UTS35] by > the Unicode Consortium without requiring a new RFC include the > allocation of new subtags for use after the 't' extension. A new RFC > would be required for material changes to an existing 't' subtag, or > an incompatible change to the overall syntactic structure of the 't' > extension; however, such a change would be contrary to the policies > of the Unicode Consortium, and thus is not anticipated. > >>>> > > 2.1 Summary: There seems to be quite some overlap between the part of > section 2 before the 2.1 heading. > > > One question I would have as a linguistic researcher is: How much effort > and time is involved in getting a 'mechanism' approved? If such 'mechanis= ms' > are e.g. rejected with arguments like "if we accept it, then everybody ha= s > to implement it" or so, then I would see that as a problem. > Good point. I'll propose some text. > > So much for the moment. > > > Regards, Martin. > > > > On 2011/06/18 6:07, Mark Davis =E2=98=95 wrote: > >> Yoshito, Addison, and I had had an action for a while now from the CLDR >> committee to submit a draft for a an extension. Rather than go through a= ll >> the problems in the falk draft, we put together an alternative approach, >> leveraging the work we already did for the -u- extension. >> >> It just got posted at >> http://tools.ietf.org/html/**draft-davis-t-langtag-ext-00 >> >> Courtney, I think this provides a superset of the functionality that you >> are >> interested in. Perhaps you can read it over, and we can add you as an >> author >> of the next version of this draft instead of having the two competing >> proposals. >> >> Mark >> >> *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* >> >> >> On Wed, Jun 15, 2011 at 10:50, Randy Presuhn >> **wrote: >> >> Hi - >>> >>> I started out with an off-list response, but I figure this is >>> something worth sending to the list. >>> >>> Off-list, a contributor asked: >>> >>> ... >>> >>>> I'd love to see your input. I'd like to make sure I understand >>>> all the concerns. Is there any way you could forward this to the list? >>>> >>> >>> My response: >>> >>> Sorry, already deleted. As I recall, the main concerns were >>> >>> (1) there already *is* support for identifying orthographies >>> (remember German?) >>> (2) the I-D seems to assume that transliterations always result >>> in "Latin" (previous discussion on LTRU included transliterations >>> to Cyrillic and Hangul, among others) >>> (3) the "original orthography" is irrelevant for the transliteration >>> systems I've been able to think of. (At the same time, some >>> transliteration systems are quite "lossy" and some don't do >>> "round trip" very well.) Consider also the transliteration of >>> material >>> which was originally in audio form... >>> (4) The draft doesn't clearly distinguish "orthography" from >>> "transliteration". >>> This may be because the boundary between the two can be fuzzy, but >>> even >>> that is an issue that should be addressed. >>> (5) How this fits in with *transcription* systems (e.g. IPA) should be >>> addressed. The boundary gets fuzzy with orthographies that are >>> equivalent >>> to phonemic representations of the language. (e.g., Pinyin for >>> Mandarin) >>> (6) The proposed singleton usage appears broken and unnecessary. >>> >>> Or something like that. I may have forgotten something here, or, in th= e >>> process of reconstruction, thought of something I missed the first time= . >>> >>> Randy >>> >>> ______________________________**_________________ >>> Ltru mailing list >>> Ltru@ietf.org >>> https://www.ietf.org/mailman/**listinfo/ltru >>> >>> >> >> >> ______________________________**_________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www.ietf.org/mailman/**listinfo/ltru >> > --001e680f184070124604a63af3a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Those are good issues; thanks for rais= ing them and starting the discussion. Comments below.

Mark
=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico = del bene =E2=80=94


On Mon, Jun 20, 2011 at 23:39, "Mar= tin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> wrote:
Hello Mark, others,

Overall comment:
The idea to reuse language tags to indicate transliteration/transcription s= ource, and to add some additional tags to distinguish methods seems to be r= easonable and sound.

The description of the structure of the allowed subtags and of the responsi= bility split between IETF (this draft) and UTC (UTS 35) looks quite messy t= o me, and should be cleaned up. I'd personally prefer that UTS 35 (or w= hatever else on the Unicode side) only define the <mechanism> part (a= fter the m0 subtag).

That would be my preference as well (can&#= 39;t speak for my coauthors).

We patterned it this= way following what ended up being accepted for =C2=A0the -u- extension. Th= at is, the spec is in UTS35, but there is a summary here. But of course, th= ere are many ways to do it. And maybe this summary is too detailed, at leas= t for the mechanism part, and we could just have it in UTS35.

We considered a number of alternatives:
    <= li>We could define everything after -t- to be the source language, and ever= ything after -m- to be the mechanism.=C2=A0But that burns 2 extension lette= rs, just one.
  • We also considered having everything in the -u extension,=C2=A0for whic= h we already have the structure set up. However, that would force us to hav= e artificial source subtags like 'en0' instead of 'en', bec= ause the -u- extension wouldn't allow the 2-letter subtags (it already = defines a use for them).
  • We could also have -t- be just the source, and define the mechanism in = -u-, also easy. But we felt it would be better to have everything under one= extension.




Detailled comments:

"In addition, it may also be important to
=C2=A0 specify a particular specification for the transformation.": T= oo much 'spec' in one sentence.

ok
=C2=A0

"For example, if one is transcribing the names of Italian or Russian =C2=A0 cities on a map for Japanese users, each name will need to be
=C2=A0 transliterated into katakana using rules appropriate for the source=
=C2=A0 language and target languages.": "source languages and ta= rget language"?

yes
=C2= =A0

BCP47 required information: The first three paragraphs should move to the i= ntroduction.

Other authors, what do you= think?
=C2=A0

"followed by a sequence of subtags that would form a language tag"= ;: Here and in general: Don't use 'would'.

Grammatically, it is that the sequence of subtags *would* f= orm a language subtag if they *were* separated out. They are not actually a= language tag, because they occur in the middle of another language subtag.= How would you like that to be phrased?



http://www.unicode.org/consortium/tc-procedures.h= tml, and subject
=C2=A0 to the Unicode Consortium Policies on
=C2=A0 http://www.unicode.org/policies/policies.html.
>>>>


The following paragraph is also difficult to understand. I wouldn't kno= w exactly what falls on what side. I think one major reason is that we are = treading new ground here, it's the first time we have a singleton defin= ition that allows reuse of language tags (with a few restrictions) as well = as intends to define its own extensions.

These were both patterned after what was u= sed for the -u- extension. We can take a look at them to try to clarify.

=C2=A0

>>>>
=C2=A0 Changes that can be made by successive versions of LDML [UTS35] by<= br> =C2=A0 the Unicode Consortium without requiring a new RFC include the
=C2=A0 allocation of new subtags for use after the 't' extension. = =C2=A0A new RFC
=C2=A0 would be required for material changes to an existing 't' s= ubtag, or
=C2=A0 an incompatible change to the overall syntactic structure of the &#= 39;t'
=C2=A0 extension; however, such a change would be contrary to the policies=
=C2=A0 of the Unicode Consortium, and thus is not anticipated.
>>>>

2.1 Summary: There seems to be quite some overlap between the part of secti= on 2 before the 2.1 heading.


One question I would have as a linguistic researcher is: How much effort an= d time is involved in getting a 'mechanism' approved? If such '= mechanisms' are e.g. rejected with arguments like "if we accept it= , then everybody has to implement it" or so, then I would see that as = a problem.

Good point. I'll propose some text.
=C2=A0

So much for the moment.


Regards, =C2=A0 Martin.



On 2011/06/18 6:07, Mark Davis =E2=98=95 wrote:
Yoshito, Addison, and I had had an action for a while now from the CLDR
committee to submit a draft for a an extension. Rather than go through all<= br> the problems in the falk draft, we put together an alternative approach, leveraging the work we already did for the -u- extension.

It just got posted at
http://tools.ietf.org/html/draft-davis-t-langtag-ext-00<= /a>

Courtney, I think this provides a superset of the functionality that you ar= e
interested in. Perhaps you can read it over, and we can add you as an autho= r
of the next version of this draft instead of having the two competing
proposals.

Mark

*=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94*


On Wed, Jun 15, 2011 at 10:50, Randy Presuhn
<randy= _presuhn@mindspring.com>wrote:

Hi -

I started out with an off-list response, but I figure this is
something worth sending to the list.

Off-list, a contributor asked:

...
I'd love to see your input. I'd like to make sure I understand
all the concerns. Is there any way you could forward this to the list?

My response:

Sorry, already deleted. =C2=A0As I recall, the main concerns were

=C2=A0(1) there already *is* support for identifying orthographies
=C2=A0 =C2=A0 =C2=A0(remember German?)
=C2=A0(2) the I-D seems to assume that transliterations always result
=C2=A0 =C2=A0 =C2=A0in "Latin" (previous discussion on LTRU incl= uded transliterations
=C2=A0 =C2=A0 =C2=A0to Cyrillic and Hangul, among others)
=C2=A0(3) the "original orthography" is irrelevant for the trans= literation
=C2=A0 =C2=A0 =C2=A0systems I've been able to think of. =C2=A0(At the = same time, some
=C2=A0 =C2=A0 =C2=A0transliteration systems are quite "lossy" an= d some don't do
=C2=A0 =C2=A0 =C2=A0"round trip" very well.) =C2=A0Consider also= the transliteration of
material
=C2=A0 =C2=A0 =C2=A0which was originally in audio form...
=C2=A0(4) The draft doesn't clearly distinguish "orthography"= ; from
"transliteration".
=C2=A0 =C2=A0 =C2=A0This may be because the boundary between the two can b= e fuzzy, but
even
=C2=A0 =C2=A0 =C2=A0that is an issue that should be addressed.
=C2=A0(5) How this fits in with *transcription* systems (e.g. IPA) should = be
=C2=A0 =C2=A0 =C2=A0addressed. =C2=A0The boundary gets fuzzy with orthogra= phies that are
equivalent
=C2=A0 =C2=A0 =C2=A0to phonemic representations of the language. =C2=A0(e.= g., Pinyin for
Mandarin)
=C2=A0(6) The proposed singleton usage appears broken and unnecessary.

Or something like that. =C2=A0I may have forgotten something here, or, in t= he
process of reconstruction, thought of something I missed the first time.
Randy

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




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

--001e680f184070124604a63af3a3-- From mark.edward.davis@gmail.com Wed Jun 22 15:00:50 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 864C911E80AB for ; Wed, 22 Jun 2011 15:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn6+9xz27gsr for ; Wed, 22 Jun 2011 15:00:48 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A147511E8085 for ; Wed, 22 Jun 2011 15:00:48 -0700 (PDT) Received: by yie30 with SMTP id 30so757946yie.31 for ; Wed, 22 Jun 2011 15:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=GfbXvwZI4smjajjfy3HSVEkKaQjimrdJwhgndZi0QbY=; b=altrt0C3c4Go5pML/TgqERHyi12HXOHvBtQNhiupOybjPaPb5kp8oRWoc2Uujvr2Ni QN90cfkclI5MfqjgAnGG8SCVZspuGCwXYIZQ+x69zW9PKvl06AKQzDXWR9pVLeCsP1Lw LgRgBIy9ZGMP7Hvk9ycQNw0lG1369deK8a5Mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=GNBBZum4AdZ1cRnDZLsvE3O3XjHDWoa0r+34bZ2XzFkb/az/sDlPkWshDZv1SMzWXr Ob3Fuj8U2oGOmpE3UWBgyuChiMjErzIEHAX5WyEKDMVN+8qsGlI+3y5l2nmMJYrL/ddS VWsXayBMeCpzIbfYqG8zJwEerTgs0F+AdQ3ZQ= MIME-Version: 1.0 Received: by 10.151.111.10 with SMTP id o10mr1449472ybm.80.1308780047777; Wed, 22 Jun 2011 15:00:47 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.151.146.9 with HTTP; Wed, 22 Jun 2011 15:00:47 -0700 (PDT) Date: Wed, 22 Jun 2011 15:00:47 -0700 X-Google-Sender-Auth: ptthyoqznVn7Lbw5AVnFUlEHV5Y Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001517574434d63f0704a65419d4 Cc: LTRU Working Group , court@infiauto.com Subject: [Ltru] draft-davis-t-langtag-ext 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, 22 Jun 2011 22:00:50 -0000 --001517574434d63f0704a65419d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A new draft posted at http://tools.ietf.org/html/draft-davis-t-langtag-ext-01 Martin, we tried to address your concerns; please take a look and let us know what you think. Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* On Tue, Jun 21, 2011 at 09:00, Mark Davis =E2=98=95 wr= ote: > Those are good issues; thanks for raising them and starting the discussio= n. > Comments below. > > ------------------------------ > Mark > *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* > > > > On Mon, Jun 20, 2011 at 23:39, "Martin J. D=C3=BCrst" wrote: > >> Hello Mark, others, >> >> Overall comment: >> The idea to reuse language tags to indicate transliteration/transcriptio= n >> source, and to add some additional tags to distinguish methods seems to = be >> reasonable and sound. >> >> The description of the structure of the allowed subtags and of the >> responsibility split between IETF (this draft) and UTC (UTS 35) looks qu= ite >> messy to me, and should be cleaned up. I'd personally prefer that UTS 35= (or >> whatever else on the Unicode side) only define the part (aft= er >> the m0 subtag). >> > > That would be my preference as well (can't speak for my coauthors). > > We patterned it this way following what ended up being accepted for the > -u- extension. That is, the spec is in UTS35, but there is a summary here= . > But of course, there are many ways to do it. And maybe this summary is to= o > detailed, at least for the mechanism part, and we could just have it in > UTS35. > > We considered a number of alternatives: > > - We could define everything after -t- to be the source language, and > everything after -m- to be the mechanism. But that burns 2 extension > letters, just one. > - We also considered having everything in the -u extension, for which > we already have the structure set up. However, that would force us to = have > artificial source subtags like 'en0' instead of 'en', because the -u- > extension wouldn't allow the 2-letter subtags (it already defines a us= e for > them). > - We could also have -t- be just the source, and define the mechanism > in -u-, also easy. But we felt it would be better to have everything u= nder > one extension. > > > >> >> >> Detailled comments: >> >> "In addition, it may also be important to >> specify a particular specification for the transformation.": Too much >> 'spec' in one sentence. >> > > ok > > >> >> "For example, if one is transcribing the names of Italian or Russian >> cities on a map for Japanese users, each name will need to be >> transliterated into katakana using rules appropriate for the source >> language and target languages.": "source languages and target language= "? >> > > yes > > >> >> BCP47 required information: The first three paragraphs should move to th= e >> introduction. >> > > Other authors, what do you think? > > >> >> "followed by a sequence of subtags that would form a language tag": Here >> and in general: Don't use 'would'. >> > > Grammatically, it is that the sequence of subtags *would* form a language > subtag if they *were* separated out. They are not actually a language tag= , > because they occur in the middle of another language subtag. How would yo= u > like that to be phrased? > > > > >> >>>> >> The structure of 't' subtags is determined by the Unicode CLDR >> Technical Committee, in accordance with the policies and procedures >> in http://www.unicode.org/**consortium/tc-procedures.html, >> and subject >> to the Unicode Consortium Policies on >> http://www.unicode.org/**policies/policies.html >> . >> >>>> >> >> >> The following paragraph is also difficult to understand. I wouldn't know >> exactly what falls on what side. I think one major reason is that we are >> treading new ground here, it's the first time we have a singleton defini= tion >> that allows reuse of language tags (with a few restrictions) as well as >> intends to define its own extensions. >> > > These were both patterned after what was used for the -u- extension. We c= an > take a look at them to try to clarify. > > > >> >> >>>> >> Changes that can be made by successive versions of LDML [UTS35] by >> the Unicode Consortium without requiring a new RFC include the >> allocation of new subtags for use after the 't' extension. A new RFC >> would be required for material changes to an existing 't' subtag, or >> an incompatible change to the overall syntactic structure of the 't' >> extension; however, such a change would be contrary to the policies >> of the Unicode Consortium, and thus is not anticipated. >> >>>> >> >> 2.1 Summary: There seems to be quite some overlap between the part of >> section 2 before the 2.1 heading. >> >> >> One question I would have as a linguistic researcher is: How much effort >> and time is involved in getting a 'mechanism' approved? If such 'mechani= sms' >> are e.g. rejected with arguments like "if we accept it, then everybody h= as >> to implement it" or so, then I would see that as a problem. >> > > Good point. I'll propose some text. > > >> >> So much for the moment. >> >> >> Regards, Martin. >> >> >> >> On 2011/06/18 6:07, Mark Davis =E2=98=95 wrote: >> >>> Yoshito, Addison, and I had had an action for a while now from the CLDR >>> committee to submit a draft for a an extension. Rather than go through >>> all >>> the problems in the falk draft, we put together an alternative approach= , >>> leveraging the work we already did for the -u- extension. >>> >>> It just got posted at >>> http://tools.ietf.org/html/**draft-davis-t-langtag-ext-00 >>> >>> Courtney, I think this provides a superset of the functionality that yo= u >>> are >>> interested in. Perhaps you can read it over, and we can add you as an >>> author >>> of the next version of this draft instead of having the two competing >>> proposals. >>> >>> Mark >>> >>> *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* >>> >>> >>> On Wed, Jun 15, 2011 at 10:50, Randy Presuhn >>> **wrote: >>> >>> Hi - >>>> >>>> I started out with an off-list response, but I figure this is >>>> something worth sending to the list. >>>> >>>> Off-list, a contributor asked: >>>> >>>> ... >>>> >>>>> I'd love to see your input. I'd like to make sure I understand >>>>> all the concerns. Is there any way you could forward this to the list= ? >>>>> >>>> >>>> My response: >>>> >>>> Sorry, already deleted. As I recall, the main concerns were >>>> >>>> (1) there already *is* support for identifying orthographies >>>> (remember German?) >>>> (2) the I-D seems to assume that transliterations always result >>>> in "Latin" (previous discussion on LTRU included transliterations >>>> to Cyrillic and Hangul, among others) >>>> (3) the "original orthography" is irrelevant for the transliteration >>>> systems I've been able to think of. (At the same time, some >>>> transliteration systems are quite "lossy" and some don't do >>>> "round trip" very well.) Consider also the transliteration of >>>> material >>>> which was originally in audio form... >>>> (4) The draft doesn't clearly distinguish "orthography" from >>>> "transliteration". >>>> This may be because the boundary between the two can be fuzzy, bu= t >>>> even >>>> that is an issue that should be addressed. >>>> (5) How this fits in with *transcription* systems (e.g. IPA) should b= e >>>> addressed. The boundary gets fuzzy with orthographies that are >>>> equivalent >>>> to phonemic representations of the language. (e.g., Pinyin for >>>> Mandarin) >>>> (6) The proposed singleton usage appears broken and unnecessary. >>>> >>>> Or something like that. I may have forgotten something here, or, in t= he >>>> process of reconstruction, thought of something I missed the first tim= e. >>>> >>>> Randy >>>> >>>> ______________________________**_________________ >>>> Ltru mailing list >>>> Ltru@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/ltru >>>> >>>> >>> >>> >>> ______________________________**_________________ >>> Ltru mailing list >>> Ltru@ietf.org >>> https://www.ietf.org/mailman/**listinfo/ltru >>> >> > --001517574434d63f0704a65419d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A new draft posted at=C2=A0http://tools.ietf.= org/html/draft-davis-t-langtag-ext-01
On Tue, Jun 21, 2011 at 09:00, Mark Davi= s =E2=98=95 <mar= k@macchiato.com> wrote:
Those are good issues; thanks for rais= ing them and starting the discussion. Comments below.

Mark
=E2=80=94 Il meglio =C3=A8 = l=E2=80=99inimico del bene =E2=80=94



On Mon, Jun 20, 2011 a= t 23:39, "Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp= > wrote:
Hello Mark, others,

Overall comment:
The idea to reuse language tags to indicate transliteration/transcription s= ource, and to add some additional tags to distinguish methods seems to be r= easonable and sound.

The description of the structure of the allowed subtags and of the responsi= bility split between IETF (this draft) and UTC (UTS 35) looks quite messy t= o me, and should be cleaned up. I'd personally prefer that UTS 35 (or w= hatever else on the Unicode side) only define the <mechanism> part (a= fter the m0 subtag).

That would be my preference as well = (can't speak for my coauthors).

We patterned i= t this way following what ended up being accepted for =C2=A0the -u- extensi= on. That is, the spec is in UTS35, but there is a summary here. But of cour= se, there are many ways to do it. And maybe this summary is too detailed, a= t least for the mechanism part, and we could just have it in UTS35.

We considered a number of alternatives:
    <= li>We could define everything after -t- to be the source language, and ever= ything after -m- to be the mechanism.=C2=A0But that burns 2 extension lette= rs, just one.
  • We also considered having everything in the -u extension,=C2=A0for whic= h we already have the structure set up. However, that would force us to hav= e artificial source subtags like 'en0' instead of 'en', bec= ause the -u- extension wouldn't allow the 2-letter subtags (it already = defines a use for them).
  • We could also have -t- be just the source, and define the mechanism in = -u-, also easy. But we felt it would be better to have everything under one= extension.




Detailled comments:

"In addition, it may also be important to
=C2=A0 specify a particular specification for the transformation.": T= oo much 'spec' in one sentence.

ok
=C2=A0

"For example, if one is transcribing the names of Italian or Russian =C2=A0 cities on a map for Japanese users, each name will need to be
=C2=A0 transliterated into katakana using rules appropriate for the source=
=C2=A0 language and target languages.": "source languages and ta= rget language"?

yes
=C2=A0

BCP47 required information: The first three paragraphs should move to the i= ntroduction.

Other authors, what = do you think?
=C2=A0

"followed by a sequence of subtags that would form a language tag"= ;: Here and in general: Don't use 'would'.

Grammatically, it is that the sequence of subtags *wo= uld* form a language subtag if they *were* separated out. They are not actu= ally a language tag, because they occur in the middle of another language s= ubtag. How would you like that to be phrased?




>>>>
=C2=A0 The structure of 't' subtags is determined by the Unicode C= LDR
=C2=A0 Technical Committee, in accordance with the policies and procedures=
=C2=A0 in http://www.unicode.org/consortium/tc-procedures.h= tml, and subject
=C2=A0 to the Unicode Consortium Policies on
=C2=A0 http://www.unicode.org/policies/policies.html.
>>>>


The following paragraph is also difficult to understand. I wouldn't kno= w exactly what falls on what side. I think one major reason is that we are = treading new ground here, it's the first time we have a singleton defin= ition that allows reuse of language tags (with a few restrictions) as well = as intends to define its own extensions.

These were both patterned after what= was used for the -u- extension. We can take a look at them to try to clari= fy.

=C2=A0

>>>>
=C2=A0 Changes that can be made by successive versions of LDML [UTS35] by<= br> =C2=A0 the Unicode Consortium without requiring a new RFC include the
=C2=A0 allocation of new subtags for use after the 't' extension. = =C2=A0A new RFC
=C2=A0 would be required for material changes to an existing 't' s= ubtag, or
=C2=A0 an incompatible change to the overall syntactic structure of the &#= 39;t'
=C2=A0 extension; however, such a change would be contrary to the policies=
=C2=A0 of the Unicode Consortium, and thus is not anticipated.
>>>>

2.1 Summary: There seems to be quite some overlap between the part of secti= on 2 before the 2.1 heading.


One question I would have as a linguistic researcher is: How much effort an= d time is involved in getting a 'mechanism' approved? If such '= mechanisms' are e.g. rejected with arguments like "if we accept it= , then everybody has to implement it" or so, then I would see that as = a problem.

Good point. I'll propose some te= xt.
=C2=A0

So much for the moment.


Regards, =C2=A0 Martin.



On 2011/06/18 6:07, Mark Davis =E2=98=95 wrote:
Yoshito, Addison, and I had had an action for a while now from the CLDR
committee to submit a draft for a an extension. Rather than go through all<= br> the problems in the falk draft, we put together an alternative approach, leveraging the work we already did for the -u- extension.

It just got posted at
http://tools.ietf.org/html/draft-davis-t-langtag-ext-00<= /a>

Courtney, I think this provides a superset of the functionality that you ar= e
interested in. Perhaps you can read it over, and we can add you as an autho= r
of the next version of this draft instead of having the two competing
proposals.

Mark

*=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94*


On Wed, Jun 15, 2011 at 10:50, Randy Presuhn
<randy= _presuhn@mindspring.com>wrote:

Hi -

I started out with an off-list response, but I figure this is
something worth sending to the list.

Off-list, a contributor asked:

...
I'd love to see your input. I'd like to make sure I understand
all the concerns. Is there any way you could forward this to the list?

My response:

Sorry, already deleted. =C2=A0As I recall, the main concerns were

=C2=A0(1) there already *is* support for identifying orthographies
=C2=A0 =C2=A0 =C2=A0(remember German?)
=C2=A0(2) the I-D seems to assume that transliterations always result
=C2=A0 =C2=A0 =C2=A0in "Latin" (previous discussion on LTRU incl= uded transliterations
=C2=A0 =C2=A0 =C2=A0to Cyrillic and Hangul, among others)
=C2=A0(3) the "original orthography" is irrelevant for the trans= literation
=C2=A0 =C2=A0 =C2=A0systems I've been able to think of. =C2=A0(At the = same time, some
=C2=A0 =C2=A0 =C2=A0transliteration systems are quite "lossy" an= d some don't do
=C2=A0 =C2=A0 =C2=A0"round trip" very well.) =C2=A0Consider also= the transliteration of
material
=C2=A0 =C2=A0 =C2=A0which was originally in audio form...
=C2=A0(4) The draft doesn't clearly distinguish "orthography"= ; from
"transliteration".
=C2=A0 =C2=A0 =C2=A0This may be because the boundary between the two can b= e fuzzy, but
even
=C2=A0 =C2=A0 =C2=A0that is an issue that should be addressed.
=C2=A0(5) How this fits in with *transcription* systems (e.g. IPA) should = be
=C2=A0 =C2=A0 =C2=A0addressed. =C2=A0The boundary gets fuzzy with orthogra= phies that are
equivalent
=C2=A0 =C2=A0 =C2=A0to phonemic representations of the language. =C2=A0(e.= g., Pinyin for
Mandarin)
=C2=A0(6) The proposed singleton usage appears broken and unnecessary.

Or something like that. =C2=A0I may have forgotten something here, or, in t= he
process of reconstruction, thought of something I missed the first time.
Randy

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




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


--001517574434d63f0704a65419d4-- From randy_presuhn@mindspring.com Sun Jun 26 20:45:46 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 DD83511E80AE; Sun, 26 Jun 2011 20:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDKFzZ3wW1bB; Sun, 26 Jun 2011 20:45:46 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 64B3B11E80A8; Sun, 26 Jun 2011 20:45:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mIuudlLDnYc4pVSgO9jaj+sUdAhtvl25nVW0k2RCzMxoXlR/+e1knhgOPvfc7wJJ; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.51.238] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qb2la-0004gW-KN; Sun, 26 Jun 2011 23:45:42 -0400 Message-ID: <004501cc347d$541943c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Disman" , "LTRU Working Group" , Date: Sun, 26 Jun 2011 20:50:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b382458ad5aad61811d284a08bace0eb9235350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.51.238 Subject: [Ltru] Fw: Please help the Nomcom 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: Mon, 27 Jun 2011 03:45:47 -0000 Hi - Fwd FYI. Randy ----- Original Message ----- > From: "NomCom Chair" > To: "Working Group Chairs" > Sent: Friday, June 24, 2011 11:35 AM > Subject: Please help the Nomcom > > Hi WG chairs, > We have had a good response to the first call for volunteers but the > rate at which new volunteers are coming in is slowing down. The Nomcom > process is best served by a large pool of volunteers drawn from a wide > spectrum of IETF attendees. Where else would we find this wide spectrum > if not in the WG mailing lists. > > I would really appreciate it if you can forward the message onto your > working group mailing lists. > > The latest volunteer status and the second call for volunteers can be > found at > https://datatracker.ietf.org/ann/nomcom/2964/ > > Thanks in advance for your help. > > Suresh Krishnan > Nomcom Chair 2011-2012 > Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com From randy_presuhn@mindspring.com Wed Jun 29 13:25:52 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 66A7711E80C3; Wed, 29 Jun 2011 13:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDwpKc-9vsp1; Wed, 29 Jun 2011 13:25:52 -0700 (PDT) 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 E4FE911E80A4; Wed, 29 Jun 2011 13:25:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=haZcxfj/Fc5sWDTywtzA7tF4yPIcRCNkdLHwiz3LbVMFyr17cMZ2O+QlfgjmQQvn; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.175.112] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qc1KZ-0006dG-Ap; Wed, 29 Jun 2011 16:25:51 -0400 Message-ID: <010201cc369b$64d1bec0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Disman" , , "LTRU Working Group" Date: Wed, 29 Jun 2011 13:30:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b3826d3b8ce61ed00ba8594c57d472929d17350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.175.112 Subject: [Ltru] Fw: Internet Draft Initial Version (-00) Cut-Off Monday, July 4 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, 29 Jun 2011 20:25:52 -0000 Hi - fwd fyi. Randy ----- Original Message ----- > From: "Internet-Drafts Administrator" > To: "IETF Announcement list" > Sent: Wednesday, June 29, 2011 1:22 PM > Subject: Internet Draft Initial Version (-00) Cut-Off Monday, July 4 > > This is a reminder that the Internet Draft Initial Version (-00) cut- > off is this coming Monday, July 4, 2011. Please note that, because > the AMS office is closed this Monday, manual submissions will not be > processed until Tuesday, July 5. > > All Initial Version (-00) submissions are due by 17:00 PDT (00:00 > Tuesday, July 5 UTC). > > All drafts can be uploaded using the ID submission tool located here: > https://datatracker.ietf.org/submit/ > > The Internet-Draft cutoff dates as well as other significant dates for > IETF 81 can be found at: > http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF81 > > Thank you for your understanding and cooperation. If you have any > questions or concerns please send a message to > internet-drafts@ietf.org. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce