From ltru-bounces@lists.ietf.org Sat Apr 30 22:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS3mQ-0003Ss-Kv; Sat, 30 Apr 2005 22:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS3mN-0003Sn-OE for ltru@megatron.ietf.org; Sat, 30 Apr 2005 22:01:58 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16914 for ; Sat, 30 Apr 2005 22:01:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DS3ei-0000nF-2B for ltru@lists.ietf.org; Sun, 01 May 2005 03:54:05 +0200 Received: from 62.80.58.163 ([62.80.58.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 03:54:00 +0200 Received: from nobody by 62.80.58.163 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 03:54:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 01 May 2005 01:45:14 +0200 Organization: Lines: 15 Message-ID: <4274188A.2A25@xyzzy.claranet.de> References: <20050428160446.HYMY27459.mta2.adelphia.net@megatron.ietf.org> <004a01c54d9c$530683e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.163 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: >> Maybe Doug can use ZZ as an additional plausibilty test. > Plausibility of what? Of the output of your region code generator. Mark's ZZ- codes plus TW should match all non-deprecated alpha-2 codes without UN number. It's about something I don't see, somewhere hidden in the generator you match numbers and alpha-2 codes to catch the remaining UN numbers for the registry. Or do you do this manually ? Not really important, but with this zoo of codes it's easy to miss something. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 01 01:20:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS6sJ-0005E6-L2; Sun, 01 May 2005 01:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS6sH-0005E1-Az for ltru@megatron.ietf.org; Sun, 01 May 2005 01:20:13 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26805 for ; Sun, 1 May 2005 01:20:11 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DS6mL-0001zC-CF for ltru@lists.ietf.org; Sun, 01 May 2005 07:14:05 +0200 Received: from du-042-229.access.de.clara.net ([213.221.65.229]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 07:14:05 +0200 Received: from nobody by du-042-229.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 07:14:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 01 May 2005 07:17:10 +0200 Organization: Lines: 183 Message-ID: <42746656.6F00@xyzzy.claranet.de> References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> <01d901c54892$06b864e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-229.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: New registry with Suppress_Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I could add other Latin-only languages like Corsican > and Hawaiian and Walloon [...] I've proposed ways to fill these gaps (e.g. let the language tag list do it), Jefsey proposed "agreement of three experts" in a similar context, and IMHO it has to be done before the final date-B. If we have no proper procedure at all the draft registry should go through a normal "last call" as RfC, so that others have a chance to check and add Suppress-Scripts. It's a very bad idea to add or remove Suppress-Scripts _after_ the final date-B, because that could in theory force a "worldwide retagging" to avoid incompatibilities. Below you see a quick and dirty list based on the draft registry with File-Date: 2005-04-30, bye, Frank AA AFAR | CYRL AB ABKHAZIAN | AE AVESTAN LATN AF AFRIKAANS | AK AKAN | ETHI AM AMHARIC AN ARAGONESE | ARAB AR ARABIC | BENG AS ASSAMESE AV AVARIC | LATN AY AYMARA | AZ AZERBAIJANI BA BASHKIR | CYRL BE BELARUSIAN | CYRL BG BULGARIAN BH BIHARI | BI BISLAMA | BM BAMBARA BENG BN BENGALI | BO TIBETAN | BR BRETON LATN BS BOSNIAN | LATN CA CATALAN; VALE | CE CHECHEN LATN CH CHAMORRO | CO CORSICAN | CR CREE LATN CS CZECH | CU CHURCH SLAVIC | CV CHUVASH LATN CY WELSH | LATN DA DANISH | LATN DE GERMAN THAA DV DIVEHI | TIBT DZ DZONGKHA | EE EWE GREK EL GREEK, MODERN | LATN EN ENGLISH | LATN EO ESPERANTO LATN ES SPANISH; CAST | LATN ET ESTONIAN | LATN EU BASQUE ARAB FA PERSIAN | FF FULAH | LATN FI FINNISH LATN FJ FIJIAN | LATN FO FAROESE | LATN FR FRENCH FY FRISIAN | LATN GA IRISH | GD GAELIC; SCOTT LATN GL GALLEGAN | LATN GN GUARANI | GUJR GU GUJARATI LATN GV MANX | HA HAUSA | HEBR HE HEBREW DEVA HI HINDI | HO HIRI MOTU | LATN HR CROATIAN LATN HT HAITIAN; HAIT | LATN HU HUNGARIAN | ARMN HY ARMENIAN HZ HERERO | IA INTERLINGUA ( | LATN ID INDONESIAN IE INTERLINGUE | IG IGBO | II SICHUAN YI IK INUPIAQ | LATN IN INDONESIAN | IO IDO LATN IS ICELANDIC | LATN IT ITALIAN | IU INUKTITUT HEBR IW HEBREW | JA JAPANESE | JI YIDDISH JV JAVANESE | JW JAVANESE | GEOR KA GEORGIAN KG KONGO | KI KIKUYU; GIKUY | KJ KUANYAMA; KWA CYRL KK KAZAKH | LATN KL KALAALLISUT; | KHMR KM KHMER KNDA KN KANNADA | KO KOREAN | KR KANURI KS KASHMIRI | KU KURDISH | KV KOMI KW CORNISH | KY KIRGHIZ | LATN LA LATIN LATN LB LUXEMBOURGISH | LG GANDA | LI LIMBURGAN; LI LATN LN LINGALA | LAOO LO LAO | LATN LT LITHUANIAN LU LUBA-KATANGA | LATN LV LATVIAN | LATN MG MALAGASY LATN MH MARSHALLESE | MI MAORI | CYRL MK MACEDONIAN MLYM ML MALAYALAM | MN MONGOLIAN | LATN MO MOLDAVIAN DEVA MR MARATHI | LATN MS MALAY | LATN MT MALTESE MYMR MY BURMESE | LATN NA NAURU | LATN NB NORWEGIAN BOK LATN ND NDEBELE, NORT | DEVA NE NEPALI | NG NDONGA LATN NL DUTCH; FLEMIS | LATN NN NORWEGIAN NYN | LATN NO NORWEGIAN LATN NR NDEBELE, SOUT | NV NAVAJO; NAVAH | LATN NY CHICHEWA; CHE OC OCCITAN (POST | OJ OJIBWA | LATN OM OROMO ORYA OR ORIYA | OS OSSETIAN; OSS | GURU PA PANJABI; PUNJ PI PALI | LATN PL POLISH | ARAB PS PUSHTO LATN PT PORTUGUESE | LATN QU QUECHUA | RM RAETO-ROMANCE LATN RN RUNDI | LATN RO ROMANIAN | CYRL RU RUSSIAN LATN RW KINYARWANDA | SA SANSKRIT | SC SARDINIAN SD SINDHI | SE NORTHERN SAMI | LATN SG SANGO SH SERBO-CROATIA | SINH SI SINHALA; SINH | LATN SK SLOVAK LATN SL SLOVENIAN | LATN SM SAMOAN | SN SHONA LATN SO SOMALI | LATN SQ ALBANIAN | SR SERBIAN LATN SS SWATI | LATN ST SOTHO, SOUTHE | SU SUNDANESE LATN SV SWEDISH | LATN SW SWAHILI | TAML TA TAMIL TELU TE TELUGU | TG TAJIK | THAI TH THAI ETHI TI TIGRINYA | TK TURKMEN | LATN TL TAGALOG LATN TN TSWANA | LATN TO TONGA (TONGA | LATN TR TURKISH LATN TS TSONGA | TT TATAR | TW TWI TY TAHITIAN | UG UIGHUR; UYGHU | CYRL UK UKRAINIAN ARAB UR URDU | UZ UZBEK | LATN VE VENDA LATN VI VIETNAMESE | VO VOLAPüK | WA WALLOON LATN WO WOLOF | LATN XH XHOSA | HEBR YI YIDDISH YO YORUBA | ZA ZHUANG; CHUAN | ZH CHINESE LATN ZU ZULU | ACE ACHINESE | ACH ACOLI ADA ADANGME | ADY ADYGHE; ADYGE | AFA AFRO-ASIATIC AFH AFRIHILI | AKK AKKADIAN | ALE ALEUT ALG ALGONQUIAN LA | ALT SOUTHERN ALTA | ANG ENGLISH, OLD APA APACHE LANGUA | ARC ARAMAIC | ARN ARAUCANIAN ARP ARAPAHO | ART ARTIFICIAL (O | ARW ARAWAK AST ASTURIAN; BAB | ATH ATHAPASCAN LA | AUS AUSTRALIAN LA AWA AWADHI | BAD BANDA | BAI BAMILEKE LANG BAL BALUCHI | BAN BALINESE | BAS BASA BAT BALTIC (OTHER | BEJ BEJA | BEM BEMBA BER BERBER (OTHER | BHO BHOJPURI | BIK BIKOL BIN BINI | BLA SIKSIKA | BNT BANTU (OTHER) BRA BRAJ | BTK BATAK (INDONE | BUA BURIAT BUG BUGINESE | BYN BLIN; BILIN | CAD CADDO CAI CENTRAL AMERI | CAR CARIB | CAU CAUCASIAN (OT CEB CEBUANO | CEL CELTIC (OTHER | CHB CHIBCHA CHG CHAGATAI | CHK CHUUKESE | CHM MARI CHN CHINOOK JARGO | CHO CHOCTAW | CHP CHIPEWYAN CHR CHEROKEE | CHY CHEYENNE | CMC CHAMIC LANGUA COP COPTIC | LATN CPE CREOLES AND P | CPF CREOLES AND P CPP CREOLES AND P | CRH CRIMEAN TATAR | CRP CREOLES AND P CSB KASHUBIAN | CUS CUSHITIC (OTH | DAK DAKOTA DAR DARGWA | DAY DAYAK | DEL DELAWARE DEN SLAVE (ATHAPA | DGR DOGRIB | DIN DINKA DOI DOGRI | DRA DRAVIDIAN (OT | DSB LOWER SORBIAN DUA DUALA | DUM DUTCH, MIDDLE | DYU DYULA EFI EFIK | EGY EGYPTIAN (ANC | EKA EKAJUK ELX ELAMITE | ENM ENGLISH, MIDD | EWO EWONDO FAN FANG | FAT FANTI | FIL FILIPINO; PIL FIU FINNO-UGRIAN | FON FON | FRM FRENCH, MIDDL FRO FRENCH, OLD ( | FUR FRIULIAN | GAA GA GAY GAYO | GBA GBAYA | GEM GERMANIC (OTH GEZ GEEZ | GIL GILBERTESE | GMH GERMAN, MIDDL GOH GERMAN, OLD H | GON GONDI | GOR GORONTALO GOT GOTHIC | GRB GREBO | GRC GREEK, ANCIEN GWI GWICH´IN | HAI HAIDA | HAW HAWAIIAN HIL HILIGAYNON | HIM HIMACHALI | HIT HITTITE HMN HMONG | HSB UPPER SORBIAN | HUP HUPA IBA IBAN | IJO IJO | ILO ILOKO INC INDIC (OTHER) | INE INDO-EUROPEAN | INH INGUSH IRA IRANIAN (OTHE | IRO IROQUOIAN LAN | JBO LOJBAN JPR JUDEO-PERSIAN | JRB JUDEO-ARABIC | KAA KARA-KALPAK KAB KABYLE | KAC KACHIN | KAM KAMBA KAR KAREN | KAW KAWI | KBD KABARDIAN KHA KHASI | KHI KHOISAN (OTHE | KHO KHOTANESE KMB KIMBUNDU | DEVA KOK KONKANI | KOS KOSRAEAN KPE KPELLE | KRC KARACHAY-BALK | KRO KRU KRU KURUKH | KUM KUMYK | KUT KUTENAI LAD LADINO | LAH LAHNDA | LAM LAMBA LEZ LEZGHIAN | LOL MONGO | LOZ LOZI LUA LUBA-LULUA | LUI LUISENO | LUN LUNDA LUO LUO (KENYA AN | LUS LUSHAI | MAD MADURESE MAG MAGAHI | DEVA MAI MAITHILI | MAK MAKASAR MAN MANDINGO | MAP AUSTRONESIAN | MAS MASAI MDF MOKSHA | MDR MANDAR | LATN MEN MENDE MGA IRISH, MIDDLE | MIC MI'KMAQ; MICM | MIN MINANGKABAU MIS MISCELLANEOUS | MKH MON-KHMER (OT | MNC MANCHU MNI MANIPURI | MNO MANOBO LANGUA | MOH MOHAWK MOS MOSSI | MUL MULTIPLE LANG | MUN MUNDA LANGUAG MUS CREEK | MWL MIRANDESE | MWR MARWARI MYN MAYAN LANGUAG | MYV ERZYA | NAH NAHUATL NAI NORTH AMERICA | NAP NEAPOLITAN | NDS LOW GERMAN; L NEW NEPAL BHASA; | NIA NIAS | NIC NIGER-KORDOFA LATN NIU NIUEAN | NOG NOGAI | NON NORSE, OLD LATN NSO NORTHERN SOTH | NUB NUBIAN LANGUA | NWC CLASSICAL NEW NYM NYAMWEZI | NYN NYANKOLE | NYO NYORO NZI NZIMA | OSA OSAGE | OTA TURKISH, OTTO OTO OTOMIAN LANGU | PAA PAPUAN (OTHER | PAG PANGASINAN PAL PAHLAVI | PAM PAMPANGA | PAP PAPIAMENTO PAU PALAUAN | PEO PERSIAN, OLD | PHI PHILIPPINE (O PHN PHOENICIAN | PON POHNPEIAN | PRA PRAKRIT LANGU PRO PROVENçA | QAA PRIVATE USE | RAJ RAJASTHANI RAP RAPANUI | RAR RAROTONGAN | ROA ROMANCE (OTHE ROM ROMANY | SAD SANDAWE | SAH YAKUT SAI SOUTH AMERICA | SAL SALISHAN LANG | SAM SAMARITAN ARA SAS SASAK | SAT SANTALI | SCN SICILIAN SCO SCOTS | SEL SELKUP | SEM SEMITIC (OTHE SGA IRISH, OLD (T | SGN SIGN LANGUAGE | SHN SHAN SID SIDAMO | SIO SIOUAN LANGUA | SIT SINO-TIBETAN SLA SLAVIC (OTHER | SMA SOUTHERN SAMI | SMI SAMI LANGUAGE SMJ LULE SAMI | SMN INARI SAMI | SMS SKOLT SAMI SNK SONINKE | SOG SOGDIAN | LATN SON SONGHAI SRN SRANAN TONGO | SRR SERER | SSA NILO-SAHARAN SUK SUKUMA | SUS SUSU | SUX SUMERIAN SYR SYRIAC | TAI TAI (OTHER) | LATN TEM TIMNE TER TERENO | TET TETUM | TIG TIGRE TIV TIV | LATN TKL TOKELAU | TLH KLINGON; TLHI TLI TLINGIT | LATN TMH TAMASHEK | TOG TONGA (NYASA) LATN TPI TOK PISIN | TSI TSIMSHIAN | TUM TUMBUKA TUP TUPI LANGUAGE | TUT ALTAIC (OTHER | LATN TVL TUVALU TYV TUVINIAN | UDM UDMURT | UGA UGARITIC UMB UMBUNDU | UND UNDETERMINED | VAI VAI VOT VOTIC | WAK WAKASHAN LANG | WAL WALAMO WAR WARAY | WAS WASHO | WEN SORBIAN LANGU XAL KALMYK; OIRAT | YAO YAO | YAP YAPESE YPK YUPIK LANGUAG | ZAP ZAPOTEC | ZEN ZENAGA ZND ZANDE | ZUN ZUNI | _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 01 01:39:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS7Ab-0007b8-SF; Sun, 01 May 2005 01:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS7Aa-0007Yx-7P for ltru@megatron.ietf.org; Sun, 01 May 2005 01:39:08 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27612 for ; Sun, 1 May 2005 01:39:06 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DS74j-0003IM-2C for ltru@lists.ietf.org; Sun, 01 May 2005 07:33:05 +0200 Received: from du-042-229.access.de.clara.net ([213.221.65.229]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 07:33:05 +0200 Received: from nobody by du-042-229.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 07:33:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 01 May 2005 07:37:48 +0200 Organization: Lines: 43 Message-ID: <42746B2C.43F0@xyzzy.claranet.de> References: <003301c54900$06bb6820$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-229.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Open tickets on initial registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > 878 should the initial registry contents i-d be > published as an RFC? > My opinion is NO on the second (878). Without any procedure to get most Suppress-Scripts right before the final date B my opinion is YES. I've just parsed the 2005-04-30 draft registry and found no unresolved references (subtags in Canonical, Redundant, Recommended-Prefix, and Suppress-Script). Some "Added" are newer than the "Deprecated", that's an odd side-effect, see below. General observation: It's possible to create an associative array of tags if all subtags excl. languages are noted as "-value", e.g. FR (French) vs. -FR (France). This allows a TAG.N = VAL and TAG.VAL = N structure for script languages like awk or REXX. Probably obvious, but I like this feature of the registry, it's really straight forward. Bye, Frank IN (2004-07-06) => ID (1989-01-01) IW (2004-07-06) => HE (1989-01-01) JI (2004-07-06) => YI (1989-01-01) JW (2005-01-17) => JV (2001-08-13) SH (2004-07-06) => ?? (2000-02-18) -BU (2004-07-06) => -MM (1989-12-05) -DD (2004-07-06) => -DE (1990-10-30) -FX (2004-07-06) => -FR (1997-07-14) -NT (2004-07-06) => ??? (1993-07-12) -SU (2004-07-06) => ??? (1992-08-30) -TP (2004-07-06) => -TL (2002-11-15) -YD (2004-07-06) => -YE (1990-08-14) -YU (2005-01-01) => -CS (2003-07-23) -ZR (2004-07-06) => -CD (1997-07-14) 967 (sub)tags in 5014 lines, 297 xrefs okay _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 01 02:30:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS7yL-0008DE-7w; Sun, 01 May 2005 02:30:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS7yI-0008Cx-J0 for ltru@megatron.ietf.org; Sun, 01 May 2005 02:30:31 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20980 for ; Sun, 1 May 2005 02:30:28 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DS7sG-0006Kk-5f for ltru@lists.ietf.org; Sun, 01 May 2005 08:24:16 +0200 Received: from du-042-229.access.de.clara.net ([213.221.65.229]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 08:24:16 +0200 Received: from nobody by du-042-229.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 08:24:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 01 May 2005 08:29:13 +0200 Organization: Lines: 46 Message-ID: <42747738.6BBE@xyzzy.claranet.de> References: <001301c54df0$c53371e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-229.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: ISO 3166-1 DIS ballot X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > The draft contains SPECIFIC, EXPLICIT steps for what to do > if and when ISO 3166/MA ever reuses a code element. This > is one of the basic rationales for the whole LTRU project. Specific and explicit steps drifting away from the ISO 3166-1 alpha-2 codes faster than necessary, because it insists on a "canonical forever" fiction in addition to stability. For something like RH => ZW or YU => CS after date-B these steps would keep the old RH and YU as canonical, instead of propoagating the new codes ZW and CS. No difference for the stability, all four codes are allowed and "stable forever" from the POV of the registry. But fifty years later RH and YU might be reused for other and new regions. In that case the explicit and specific steps will add the UN numbers for these regios if available. Let's assume that this works (without a petition from the tag reviewer to the UN - what an idea) and the new RH and YU are registered by their UN number. Of course users will get it wrong. Almost all regions use their ISO 3166-1 alpha-2 codes in tags, it's hard to understand why that should be wrong for codes that haven't be used for more than 50 years. And then these errors will not only clash with deprecated stable codes, but with canonical stable codes. A complete 50 years transition period wasted for nothing insisting on a "canonical forever" fiction. > To state that the draft will "work without problems" only > until ISO 3166/MA reuses a code element, and that at that > point the registry will be "forced to take an emergency > exit," demonstrates complete misunderstanding of the > mechanism described in the draft. Quite the contrary, the draft demonstrates a complete lack of understanding of what was wrong with RfC 3066. The draft indirectly says "tags ougt to be stable, and if ISO 3166-1 isn't then ISO 3166-1 is wrong". But the opposite is true, ISO 3166-1 was never stable, will never be stable, is not meant to be stable, and attempts to abuse it as source for stable codes are doomed. See CS, GE, SK, etc. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 01 05:00:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSAJ7-0005jE-Tc; Sun, 01 May 2005 05:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSAJ6-0005ip-Dz for ltru@megatron.ietf.org; Sun, 01 May 2005 05:00:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05607 for ; Sun, 1 May 2005 05:00:05 -0400 (EDT) Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSAWU-0000vN-K4 for ltru@ietf.org; Sun, 01 May 2005 05:14:01 -0400 Received: (qmail 43427 messnum 2893268 invoked from network[194.125.207.24/ts11-024.dublin.indigo.ie]); 1 May 2005 08:59:48 -0000 Received: from ts11-024.dublin.indigo.ie (HELO egt.ie) (194.125.207.24) by mail06.svc.cra.dublin.eircom.net (qp 43427) with SMTP; 1 May 2005 08:59:48 -0000 Message-ID: <42749A09.566AA286@egt.ie> Date: Sun, 01 May 2005 09:57:45 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: New registry with Suppress_Script References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> <01d901c54892$06b864e0$030aa8c0@DEWELL> <42746656.6F00@xyzzy.claranet.de> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA05607 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, Frank, You seem to be missing LATN before KW and BR in some places, as in: LATN KW CORNISH LATN BR BRETON Is this at all significant, or am I missing something? Hard to be sure with 100s of msgs (more than one could be expected to read) coming through thick and fast on list .=20 mg =20 ----- Scr=EDobh Frank Ellermann: >=20 > Doug Ewell wrote: >=20 > > I could add other Latin-only languages like Corsican > > and Hawaiian and Walloon > [...] >=20 > I've proposed ways to fill these gaps (e.g. let the > language tag list do it), Jefsey proposed "agreement > of three experts" in a similar context, and IMHO it > has to be done before the final date-B. >=20 > If we have no proper procedure at all the draft registry > should go through a normal "last call" as RfC, so that > others have a chance to check and add Suppress-Scripts. >=20 > It's a very bad idea to add or remove Suppress-Scripts > _after_ the final date-B, because that could in theory > force a "worldwide retagging" to avoid incompatibilities. >=20 > Below you see a quick and dirty list based on the draft > registry with File-Date: 2005-04-30, bye, Frank >=20 > AA AFAR | CYRL AB ABKHAZIAN | AE AVESTAN > LATN AF AFRIKAANS | AK AKAN | ETHI AM AMHARIC... --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:48:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQ1-0005jD-VA; Mon, 02 May 2005 07:48:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSEFQ-0008PM-Nw for ltru@megatron.ietf.org; Sun, 01 May 2005 09:12:37 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21129 for ; Sun, 1 May 2005 09:12:32 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSE9G-0000EU-UX for ltru@lists.ietf.org; Sun, 01 May 2005 15:06:14 +0200 Received: from 212.82.251.150 ([212.82.251.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 15:06:14 +0200 Received: from nobody by 212.82.251.150 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 May 2005 15:06:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 01 May 2005 15:11:41 +0200 Organization: Lines: 16 Message-ID: <4274D58C.542D@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.150 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Open points before -02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, here's my short list of issues in -01 (details later): 1 - check and fill gaps in Suppress-Scripts 2 - check SHOULD, MUST, and rationale for Suppress-Scripts 3 - improve registry ABNF, simplify the corresponding chapter 4 - redefine canonical / deprecated to follow the underlying ISO and UN standards (stable forever != canonical forever) 5 - move redundant tags from draft registry to an appendix If that's really all we should in theory be ready in about two weeks, excluding point 1 "Suppress-Script gaps", that could be the most time consuming problem. Transforming Doug's lstreg.txt to proto-I-D-XML, and creating a proper I-D with xml2rfc, should be a matter of hours. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQ4-0005uz-Hp; Mon, 02 May 2005 07:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSGjU-0001Vo-Gf for ltru@megatron.ietf.org; Sun, 01 May 2005 11:51:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29389 for ; Sun, 1 May 2005 11:51:45 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSGwy-00055U-Bt for ltru@ietf.org; Sun, 01 May 2005 12:05:45 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 08:51:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: ISO 3166-1 DIS ballot Date: Sun, 1 May 2005 08:51:35 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B38FD4D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: ISO 3166-1 DIS ballot Thread-Index: AcVN8TTx5QbPv6BwQ0GJZyHyjE68zgAcyWTA From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 01 May 2005 15:51:36.0736 (UTC) FILETIME=[A8030200:01C54E65] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2117340342==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============2117340342== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBkb24ndCB0aGluayB5b3UgZ3V5cyBhcmUgc2F5aW5nIGFueXRoaW5nIGRpZmZlcmVudCBmcm9t IG9uZSBhbm90aGVyLiBBY3R1YWxseSwgSSdtIGEgYml0IGJhZmZsZWQgYnkgdGhpcyB0aHJlYWQu IEZyYW5rJ3Mgbm90ZSBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IGNvdXBsZWQgd2l0aCB0aGUgNTAt eWVhciBwZXJpb2QgdGhlIGdlbmVyYWwgYXBwcm9hY2ggdG8gaGFuZGxpbmcgcmVnaW9uIGNvZGVz IHdpbGwgd29yay4gSGUgdGhlbiBnb2VzIG9uIHRvIHN1Z2dlc3Qgd2hhdCBoZSBoYXMgY29uc2lz dGVudGx5IGFkdm9jYXRlZDogdGhhdCBjYW5vbmljYWwgbWFwcGluZ3Mgc2hvdWxkIGZvbGxvdyBj b3VudHJ5IGNvZGUgYXNzaWdubWVudHMuDQoNClRoZSBjb250cmFyeSBvcGluaW9uIGhhcyBiZWVu IHN0YXRlZCBieSBzZXZlcmFsIHBlb3BsZSBvbiB0aGlzIGxpc3QgKG1vc3QgcmVjZW50bHkgYnkg Sm9obiBDb3dhbiksIHdoaWNoIGlzIHRoYXQgd2Ugc2hvdWxkbid0IGJlIGZvcmNlZCBieSBJU08g MzE2NiB0byBjcmVhdGUgaW5zdGFiaWxpdHkgaW4gbGFuZ3VhZ2UgdGFncyBieSBjb25zdGFudGx5 IGFzc2lnbmluZyBhbmQgd2l0aGRyYXdpbmcgY29kZXMuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQ LiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFp ciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5h dGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiAN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGxpc3Rz LmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXSBPbg0KPiBCZWhh bGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50OiAyMDA15bm0NOaciDMw5pelIDE4OjU1DQo+IFRvOiBM VFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogW0x0cnVdIFJlOiBJU08gMzE2Ni0xIERJUyBi YWxsb3QNCj4gDQo+IEZyYW5rIEVsbGVybWFubiA8bm9ib2R5IGF0IHh5enp5IGRvdCBjbGFyYW5l dCBkb3QgZGU+IHdyb3RlOg0KPiANCj4gPiBJbiBvdGhlciB3b3JkcyAzMDY2YmlzIGRyYWZ0IC0w MSBzaG91bGQgd29yayB3aXRob3V0IHByb2JsZW1zDQo+ID4gYXQgbGVhc3QgdW50aWwgZGF0ZSBB IHBsdXMgNTAgeWVhcnMgKDIwMzgpLiAgQW5kIG1heWJlIHdlIGNhbg0KPiA+IGltcHJvdmUgdGhp cyBzaXR1YXRpb24gaW4gZHJhZnQgLTAyIHdpdGggYSBuZXcgImNhbm9uaWNhbCIgcnVsZQ0KPiA+ IGZvbGxvd2luZyAzMTY2LTEgYXMgbG9uZyBhcyBwb3NzaWJsZSAtIHVudGlsIHRoZSByZWdpc3Ry eSBpcw0KPiA+IGZpbmFsbHkgZm9yY2VkIHRvIHRha2UgdGhlIGVtZXJnZW5jeSBleGl0ICJVTiBu dW1iZXIiLg0KPiANCj4gYW5kIFJhbmR5IHJlc3BvbmRlZDoNCj4gDQo+ID4gRG8geW91IGhhdmUg c3BlY2lmaWMgdGV4dCB5b3UnZCBsaWtlIHRvIHByb3Bvc2U/DQo+ID4gS2VlcCBpbiBtaW5kIHRo YXQgd2UgZG9uJ3Qgd2FudCB0byBtYWtlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZQ0KPiA+IHRvIHdv cmstaW4tcHJvZ3Jlc3MuDQo+IA0KPiBUaGVyZSdzIG1vcmUgdG8gaXQgdGhhbiB0aGF0Lg0KPiAN Cj4gVGhlIGRyYWZ0IGNvbnRhaW5zIFNQRUNJRklDLCBFWFBMSUNJVCBzdGVwcyBmb3Igd2hhdCB0 byBkbyBpZiBhbmQgd2hlbg0KPiBJU08gMzE2Ni9NQSBldmVyIHJldXNlcyBhIGNvZGUgZWxlbWVu dC4gIFRoaXMgaXMgb25lIG9mIHRoZSBiYXNpYw0KPiByYXRpb25hbGVzIGZvciB0aGUgd2hvbGUg TFRSVSBwcm9qZWN0Lg0KPiANCj4gVG8gc3RhdGUgdGhhdCB0aGUgZHJhZnQgd2lsbCAid29yayB3 aXRob3V0IHByb2JsZW1zIiBvbmx5IHVudGlsIElTTw0KPiAzMTY2L01BIHJldXNlcyBhIGNvZGUg ZWxlbWVudCwgYW5kIHRoYXQgYXQgdGhhdCBwb2ludCB0aGUgcmVnaXN0cnkgd2lsbA0KPiBiZSAi Zm9yY2VkIHRvIHRha2UgYW4gZW1lcmdlbmN5IGV4aXQsIiBkZW1vbnN0cmF0ZXMgY29tcGxldGUN Cj4gbWlzdW5kZXJzdGFuZGluZyBvZiB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGUgZHJh ZnQuDQo+IA0KPiBQbGVhc2UgcmVhZCBTZWN0aW9uIDMuMyBhZ2FpbiwgaW4gcGFydGljdWxhciB0 aGUgbmV4dC10by1sYXN0IGJ1bGxldA0KPiBwb2ludCAodGhlIG9uZSB3aXRoIHNpeCBzdWItYnVs bGV0IHBvaW50cyk6DQo+IA0KPiBodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQt aWV0Zi1sdHJ1LXJlZ2lzdHJ5LQ0KPiAwMS5odG1sI2lhbmFzdGFiaWxpdHkNCj4gDQo+IC0tDQo+ IERvdWcgRXdlbGwNCj4gRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+IGh0dHA6Ly91c2Vycy5hZGVs cGhpYS5uZXQvfmRld2VsbC8NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0 cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1 DQoNCg== --===============2117340342== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2117340342==-- From ltru-bounces@lists.ietf.org Mon May 02 07:49:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQ4-0005wM-OB; Mon, 02 May 2005 07:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSGoK-00028J-Ci for ltru@megatron.ietf.org; Sun, 01 May 2005 11:56:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29510 for ; Sun, 1 May 2005 11:56:45 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSH1p-0005Es-EA for ltru@ietf.org; Sun, 01 May 2005 12:10:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 08:56:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: New registry with Suppress_Script Date: Sun, 1 May 2005 08:56:38 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B38FD4F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: New registry with Suppress_Script Thread-Index: AcVODZ4DJs+VS3AqRfWfYeFBaNzbigAWB1SA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 01 May 2005 15:56:38.0938 (UTC) FILETIME=[5C235FA0:01C54E66] X-Spam-Score: 0.1 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I slightly disagree. There is little harm to adding suppress script fields for some time = after the draft is adopted, since content and implementations will not = have been created under the new regime yet and because = content/implementations should still follow the guidelines in the draft = when choosing tags (which favors not using scripts unless required, = which they are not if a language uses one script). There would be a good bit more harm from removing one. I therefore favor being conservative in assigning suppress script = fields. And I absolutely favor a full review and last call for the = registry itself. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?4?30? 22:17 > To: ltru@ietf.org > Subject: [Ltru] Re: New registry with Suppress_Script >=20 > Doug Ewell wrote: >=20 > > I could add other Latin-only languages like Corsican > > and Hawaiian and Walloon > [...] >=20 > I've proposed ways to fill these gaps (e.g. let the > language tag list do it), Jefsey proposed "agreement > of three experts" in a similar context, and IMHO it > has to be done before the final date-B. >=20 > If we have no proper procedure at all the draft registry > should go through a normal "last call" as RfC, so that > others have a chance to check and add Suppress-Scripts. >=20 > It's a very bad idea to add or remove Suppress-Scripts > _after_ the final date-B, because that could in theory > force a "worldwide retagging" to avoid incompatibilities. >=20 > Below you see a quick and dirty list based on the draft > registry with File-Date: 2005-04-30, bye, Frank >=20 > AA AFAR | CYRL AB ABKHAZIAN | AE AVESTAN > LATN AF AFRIKAANS | AK AKAN | ETHI AM AMHARIC > AN ARAGONESE | ARAB AR ARABIC | BENG AS ASSAMESE > AV AVARIC | LATN AY AYMARA | AZ AZERBAIJANI > BA BASHKIR | CYRL BE BELARUSIAN | CYRL BG BULGARIAN > BH BIHARI | BI BISLAMA | BM BAMBARA > BENG BN BENGALI | BO TIBETAN | BR BRETON > LATN BS BOSNIAN | LATN CA CATALAN; VALE | CE CHECHEN > LATN CH CHAMORRO | CO CORSICAN | CR CREE > LATN CS CZECH | CU CHURCH SLAVIC | CV CHUVASH > LATN CY WELSH | LATN DA DANISH | LATN DE GERMAN > THAA DV DIVEHI | TIBT DZ DZONGKHA | EE EWE > GREK EL GREEK, MODERN | LATN EN ENGLISH | LATN EO ESPERANTO > LATN ES SPANISH; CAST | LATN ET ESTONIAN | LATN EU BASQUE > ARAB FA PERSIAN | FF FULAH | LATN FI FINNISH > LATN FJ FIJIAN | LATN FO FAROESE | LATN FR FRENCH > FY FRISIAN | LATN GA IRISH | GD GAELIC; = SCOTT > LATN GL GALLEGAN | LATN GN GUARANI | GUJR GU GUJARATI > LATN GV MANX | HA HAUSA | HEBR HE HEBREW > DEVA HI HINDI | HO HIRI MOTU | LATN HR CROATIAN > LATN HT HAITIAN; HAIT | LATN HU HUNGARIAN | ARMN HY ARMENIAN > HZ HERERO | IA INTERLINGUA ( | LATN ID INDONESIAN > IE INTERLINGUE | IG IGBO | II SICHUAN YI > IK INUPIAQ | LATN IN INDONESIAN | IO IDO > LATN IS ICELANDIC | LATN IT ITALIAN | IU INUKTITUT > HEBR IW HEBREW | JA JAPANESE | JI YIDDISH > JV JAVANESE | JW JAVANESE | GEOR KA GEORGIAN > KG KONGO | KI KIKUYU; GIKUY | KJ KUANYAMA; = KWA > CYRL KK KAZAKH | LATN KL KALAALLISUT; | KHMR KM KHMER > KNDA KN KANNADA | KO KOREAN | KR KANURI > KS KASHMIRI | KU KURDISH | KV KOMI > KW CORNISH | KY KIRGHIZ | LATN LA LATIN > LATN LB LUXEMBOURGISH | LG GANDA | LI LIMBURGAN; = LI > LATN LN LINGALA | LAOO LO LAO | LATN LT LITHUANIAN > LU LUBA-KATANGA | LATN LV LATVIAN | LATN MG MALAGASY > LATN MH MARSHALLESE | MI MAORI | CYRL MK MACEDONIAN > MLYM ML MALAYALAM | MN MONGOLIAN | LATN MO MOLDAVIAN > DEVA MR MARATHI | LATN MS MALAY | LATN MT MALTESE > MYMR MY BURMESE | LATN NA NAURU | LATN NB NORWEGIAN = BOK > LATN ND NDEBELE, NORT | DEVA NE NEPALI | NG NDONGA > LATN NL DUTCH; FLEMIS | LATN NN NORWEGIAN NYN | LATN NO NORWEGIAN > LATN NR NDEBELE, SOUT | NV NAVAJO; NAVAH | LATN NY CHICHEWA; = CHE > OC OCCITAN (POST | OJ OJIBWA | LATN OM OROMO > ORYA OR ORIYA | OS OSSETIAN; OSS | GURU PA PANJABI; = PUNJ > PI PALI | LATN PL POLISH | ARAB PS PUSHTO > LATN PT PORTUGUESE | LATN QU QUECHUA | RM = RAETO-ROMANCE > LATN RN RUNDI | LATN RO ROMANIAN | CYRL RU RUSSIAN > LATN RW KINYARWANDA | SA SANSKRIT | SC SARDINIAN > SD SINDHI | SE NORTHERN SAMI | LATN SG SANGO > SH SERBO-CROATIA | SINH SI SINHALA; SINH | LATN SK SLOVAK > LATN SL SLOVENIAN | LATN SM SAMOAN | SN SHONA > LATN SO SOMALI | LATN SQ ALBANIAN | SR SERBIAN > LATN SS SWATI | LATN ST SOTHO, SOUTHE | SU SUNDANESE > LATN SV SWEDISH | LATN SW SWAHILI | TAML TA TAMIL > TELU TE TELUGU | TG TAJIK | THAI TH THAI > ETHI TI TIGRINYA | TK TURKMEN | LATN TL TAGALOG > LATN TN TSWANA | LATN TO TONGA (TONGA | LATN TR TURKISH > LATN TS TSONGA | TT TATAR | TW TWI > TY TAHITIAN | UG UIGHUR; UYGHU | CYRL UK UKRAINIAN > ARAB UR URDU | UZ UZBEK | LATN VE VENDA > LATN VI VIETNAMESE | VO VOLAPüK | WA WALLOON > LATN WO WOLOF | LATN XH XHOSA | HEBR YI YIDDISH > YO YORUBA | ZA ZHUANG; CHUAN | ZH CHINESE > LATN ZU ZULU | ACE ACHINESE | ACH ACOLI > ADA ADANGME | ADY ADYGHE; ADYGE | AFA = AFRO-ASIATIC > AFH AFRIHILI | AKK AKKADIAN | ALE ALEUT > ALG ALGONQUIAN LA | ALT SOUTHERN ALTA | ANG ENGLISH, = OLD > APA APACHE LANGUA | ARC ARAMAIC | ARN ARAUCANIAN > ARP ARAPAHO | ART ARTIFICIAL (O | ARW ARAWAK > AST ASTURIAN; BAB | ATH ATHAPASCAN LA | AUS AUSTRALIAN = LA > AWA AWADHI | BAD BANDA | BAI BAMILEKE = LANG > BAL BALUCHI | BAN BALINESE | BAS BASA > BAT BALTIC (OTHER | BEJ BEJA | BEM BEMBA > BER BERBER (OTHER | BHO BHOJPURI | BIK BIKOL > BIN BINI | BLA SIKSIKA | BNT BANTU = (OTHER) > BRA BRAJ | BTK BATAK (INDONE | BUA BURIAT > BUG BUGINESE | BYN BLIN; BILIN | CAD CADDO > CAI CENTRAL AMERI | CAR CARIB | CAU CAUCASIAN = (OT > CEB CEBUANO | CEL CELTIC (OTHER | CHB CHIBCHA > CHG CHAGATAI | CHK CHUUKESE | CHM MARI > CHN CHINOOK JARGO | CHO CHOCTAW | CHP CHIPEWYAN > CHR CHEROKEE | CHY CHEYENNE | CMC CHAMIC = LANGUA > COP COPTIC | LATN CPE CREOLES AND P | CPF CREOLES AND = P > CPP CREOLES AND P | CRH CRIMEAN TATAR | CRP CREOLES AND = P > CSB KASHUBIAN | CUS CUSHITIC (OTH | DAK DAKOTA > DAR DARGWA | DAY DAYAK | DEL DELAWARE > DEN SLAVE (ATHAPA | DGR DOGRIB | DIN DINKA > DOI DOGRI | DRA DRAVIDIAN (OT | DSB LOWER = SORBIAN > DUA DUALA | DUM DUTCH, MIDDLE | DYU DYULA > EFI EFIK | EGY EGYPTIAN (ANC | EKA EKAJUK > ELX ELAMITE | ENM ENGLISH, MIDD | EWO EWONDO > FAN FANG | FAT FANTI | FIL FILIPINO; = PIL > FIU FINNO-UGRIAN | FON FON | FRM FRENCH, = MIDDL > FRO FRENCH, OLD ( | FUR FRIULIAN | GAA GA > GAY GAYO | GBA GBAYA | GEM GERMANIC = (OTH > GEZ GEEZ | GIL GILBERTESE | GMH GERMAN, = MIDDL > GOH GERMAN, OLD H | GON GONDI | GOR GORONTALO > GOT GOTHIC | GRB GREBO | GRC GREEK, = ANCIEN > GWI GWICH´IN | HAI HAIDA | HAW HAWAIIAN > HIL HILIGAYNON | HIM HIMACHALI | HIT HITTITE > HMN HMONG | HSB UPPER SORBIAN | HUP HUPA > IBA IBAN | IJO IJO | ILO ILOKO > INC INDIC (OTHER) | INE INDO-EUROPEAN | INH INGUSH > IRA IRANIAN (OTHE | IRO IROQUOIAN LAN | JBO LOJBAN > JPR JUDEO-PERSIAN | JRB JUDEO-ARABIC | KAA KARA-KALPAK > KAB KABYLE | KAC KACHIN | KAM KAMBA > KAR KAREN | KAW KAWI | KBD KABARDIAN > KHA KHASI | KHI KHOISAN (OTHE | KHO KHOTANESE > KMB KIMBUNDU | DEVA KOK KONKANI | KOS KOSRAEAN > KPE KPELLE | KRC KARACHAY-BALK | KRO KRU > KRU KURUKH | KUM KUMYK | KUT KUTENAI > LAD LADINO | LAH LAHNDA | LAM LAMBA > LEZ LEZGHIAN | LOL MONGO | LOZ LOZI > LUA LUBA-LULUA | LUI LUISENO | LUN LUNDA > LUO LUO (KENYA AN | LUS LUSHAI | MAD MADURESE > MAG MAGAHI | DEVA MAI MAITHILI | MAK MAKASAR > MAN MANDINGO | MAP AUSTRONESIAN | MAS MASAI > MDF MOKSHA | MDR MANDAR | LATN MEN MENDE > MGA IRISH, MIDDLE | MIC MI'KMAQ; MICM | MIN MINANGKABAU > MIS MISCELLANEOUS | MKH MON-KHMER (OT | MNC MANCHU > MNI MANIPURI | MNO MANOBO LANGUA | MOH MOHAWK > MOS MOSSI | MUL MULTIPLE LANG | MUN MUNDA = LANGUAG > MUS CREEK | MWL MIRANDESE | MWR MARWARI > MYN MAYAN LANGUAG | MYV ERZYA | NAH NAHUATL > NAI NORTH AMERICA | NAP NEAPOLITAN | NDS LOW GERMAN; = L > NEW NEPAL BHASA; | NIA NIAS | NIC = NIGER-KORDOFA > LATN NIU NIUEAN | NOG NOGAI | NON NORSE, OLD > LATN NSO NORTHERN SOTH | NUB NUBIAN LANGUA | NWC CLASSICAL = NEW > NYM NYAMWEZI | NYN NYANKOLE | NYO NYORO > NZI NZIMA | OSA OSAGE | OTA TURKISH, = OTTO > OTO OTOMIAN LANGU | PAA PAPUAN (OTHER | PAG PANGASINAN > PAL PAHLAVI | PAM PAMPANGA | PAP PAPIAMENTO > PAU PALAUAN | PEO PERSIAN, OLD | PHI PHILIPPINE = (O > PHN PHOENICIAN | PON POHNPEIAN | PRA PRAKRIT = LANGU > PRO PROVENçA | QAA PRIVATE USE | RAJ RAJASTHANI > RAP RAPANUI | RAR RAROTONGAN | ROA ROMANCE = (OTHE > ROM ROMANY | SAD SANDAWE | SAH YAKUT > SAI SOUTH AMERICA | SAL SALISHAN LANG | SAM SAMARITAN = ARA > SAS SASAK | SAT SANTALI | SCN SICILIAN > SCO SCOTS | SEL SELKUP | SEM SEMITIC = (OTHE > SGA IRISH, OLD (T | SGN SIGN LANGUAGE | SHN SHAN > SID SIDAMO | SIO SIOUAN LANGUA | SIT = SINO-TIBETAN > SLA SLAVIC (OTHER | SMA SOUTHERN SAMI | SMI SAMI = LANGUAGE > SMJ LULE SAMI | SMN INARI SAMI | SMS SKOLT SAMI > SNK SONINKE | SOG SOGDIAN | LATN SON SONGHAI > SRN SRANAN TONGO | SRR SERER | SSA = NILO-SAHARAN > SUK SUKUMA | SUS SUSU | SUX SUMERIAN > SYR SYRIAC | TAI TAI (OTHER) | LATN TEM TIMNE > TER TERENO | TET TETUM | TIG TIGRE > TIV TIV | LATN TKL TOKELAU | TLH KLINGON; = TLHI > TLI TLINGIT | LATN TMH TAMASHEK | TOG TONGA = (NYASA) > LATN TPI TOK PISIN | TSI TSIMSHIAN | TUM TUMBUKA > TUP TUPI LANGUAGE | TUT ALTAIC (OTHER | LATN TVL TUVALU > TYV TUVINIAN | UDM UDMURT | UGA UGARITIC > UMB UMBUNDU | UND UNDETERMINED | VAI VAI > VOT VOTIC | WAK WAKASHAN LANG | WAL WALAMO > WAR WARAY | WAS WASHO | WEN SORBIAN = LANGU > XAL KALMYK; OIRAT | YAO YAO | YAP YAPESE > YPK YUPIK LANGUAG | ZAP ZAPOTEC | ZEN ZENAGA > ZND ZANDE | ZUN ZUNI | >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQ8-0006Fh-HQ; Mon, 02 May 2005 07:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSL93-0002iW-AV for ltru@megatron.ietf.org; Sun, 01 May 2005 16:34:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15340 for ; Sun, 1 May 2005 16:34:26 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSLMa-0002aQ-HL for ltru@ietf.org; Sun, 01 May 2005 16:48:29 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 13:34:14 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 May 2005 13:34:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: New registry with Suppress_Script Date: Sun, 1 May 2005 13:34:20 -0700 Message-ID: Thread-Topic: [Ltru] Re: New registry with Suppress_Script Thread-Index: AcVODZurqrrJRpBrRcKlgUb/YCrlHgAfqgvg From: "Peter Constable" To: X-OriginalArrivalTime: 01 May 2005 20:34:14.0380 (UTC) FILETIME=[238E22C0:01C54E8D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Could we filter out the collective language IDs? None of those should have a suppress script value.=20 It might also be easier to process if we grouped into the following categories: a) those with reviewed suppress-script values on which we have consensus b) those with proposed suppress-script values waiting for review c) known non-candidates for suppress-script because they are written in multiple scripts (reviewed and consensus established) d) those believed to be written in multiple scripts - waiting for review e) unknown Peter > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Sent: Saturday, April 30, 2005 10:17 PM > To: ltru@ietf.org > Subject: [Ltru] Re: New registry with Suppress_Script >=20 > Doug Ewell wrote: >=20 > > I could add other Latin-only languages like Corsican > > and Hawaiian and Walloon > [...] >=20 > I've proposed ways to fill these gaps (e.g. let the > language tag list do it), Jefsey proposed "agreement > of three experts" in a similar context, and IMHO it > has to be done before the final date-B. >=20 > If we have no proper procedure at all the draft registry > should go through a normal "last call" as RfC, so that > others have a chance to check and add Suppress-Scripts. >=20 > It's a very bad idea to add or remove Suppress-Scripts > _after_ the final date-B, because that could in theory > force a "worldwide retagging" to avoid incompatibilities. >=20 > Below you see a quick and dirty list based on the draft > registry with File-Date: 2005-04-30, bye, Frank >=20 > AA AFAR | CYRL AB ABKHAZIAN | AE AVESTAN > LATN AF AFRIKAANS | AK AKAN | ETHI AM AMHARIC > AN ARAGONESE | ARAB AR ARABIC | BENG AS ASSAMESE > AV AVARIC | LATN AY AYMARA | AZ AZERBAIJANI > BA BASHKIR | CYRL BE BELARUSIAN | CYRL BG BULGARIAN > BH BIHARI | BI BISLAMA | BM BAMBARA > BENG BN BENGALI | BO TIBETAN | BR BRETON > LATN BS BOSNIAN | LATN CA CATALAN; VALE | CE CHECHEN > LATN CH CHAMORRO | CO CORSICAN | CR CREE > LATN CS CZECH | CU CHURCH SLAVIC | CV CHUVASH > LATN CY WELSH | LATN DA DANISH | LATN DE GERMAN > THAA DV DIVEHI | TIBT DZ DZONGKHA | EE EWE > GREK EL GREEK, MODERN | LATN EN ENGLISH | LATN EO ESPERANTO > LATN ES SPANISH; CAST | LATN ET ESTONIAN | LATN EU BASQUE > ARAB FA PERSIAN | FF FULAH | LATN FI FINNISH > LATN FJ FIJIAN | LATN FO FAROESE | LATN FR FRENCH > FY FRISIAN | LATN GA IRISH | GD GAELIC; SCOTT > LATN GL GALLEGAN | LATN GN GUARANI | GUJR GU GUJARATI > LATN GV MANX | HA HAUSA | HEBR HE HEBREW > DEVA HI HINDI | HO HIRI MOTU | LATN HR CROATIAN > LATN HT HAITIAN; HAIT | LATN HU HUNGARIAN | ARMN HY ARMENIAN > HZ HERERO | IA INTERLINGUA ( | LATN ID INDONESIAN > IE INTERLINGUE | IG IGBO | II SICHUAN YI > IK INUPIAQ | LATN IN INDONESIAN | IO IDO > LATN IS ICELANDIC | LATN IT ITALIAN | IU INUKTITUT > HEBR IW HEBREW | JA JAPANESE | JI YIDDISH > JV JAVANESE | JW JAVANESE | GEOR KA GEORGIAN > KG KONGO | KI KIKUYU; GIKUY | KJ KUANYAMA; KWA > CYRL KK KAZAKH | LATN KL KALAALLISUT; | KHMR KM KHMER > KNDA KN KANNADA | KO KOREAN | KR KANURI > KS KASHMIRI | KU KURDISH | KV KOMI > KW CORNISH | KY KIRGHIZ | LATN LA LATIN > LATN LB LUXEMBOURGISH | LG GANDA | LI LIMBURGAN; LI > LATN LN LINGALA | LAOO LO LAO | LATN LT LITHUANIAN > LU LUBA-KATANGA | LATN LV LATVIAN | LATN MG MALAGASY > LATN MH MARSHALLESE | MI MAORI | CYRL MK MACEDONIAN > MLYM ML MALAYALAM | MN MONGOLIAN | LATN MO MOLDAVIAN > DEVA MR MARATHI | LATN MS MALAY | LATN MT MALTESE > MYMR MY BURMESE | LATN NA NAURU | LATN NB NORWEGIAN BOK > LATN ND NDEBELE, NORT | DEVA NE NEPALI | NG NDONGA > LATN NL DUTCH; FLEMIS | LATN NN NORWEGIAN NYN | LATN NO NORWEGIAN > LATN NR NDEBELE, SOUT | NV NAVAJO; NAVAH | LATN NY CHICHEWA; CHE > OC OCCITAN (POST | OJ OJIBWA | LATN OM OROMO > ORYA OR ORIYA | OS OSSETIAN; OSS | GURU PA PANJABI; PUNJ > PI PALI | LATN PL POLISH | ARAB PS PUSHTO > LATN PT PORTUGUESE | LATN QU QUECHUA | RM RAETO-ROMANCE > LATN RN RUNDI | LATN RO ROMANIAN | CYRL RU RUSSIAN > LATN RW KINYARWANDA | SA SANSKRIT | SC SARDINIAN > SD SINDHI | SE NORTHERN SAMI | LATN SG SANGO > SH SERBO-CROATIA | SINH SI SINHALA; SINH | LATN SK SLOVAK > LATN SL SLOVENIAN | LATN SM SAMOAN | SN SHONA > LATN SO SOMALI | LATN SQ ALBANIAN | SR SERBIAN > LATN SS SWATI | LATN ST SOTHO, SOUTHE | SU SUNDANESE > LATN SV SWEDISH | LATN SW SWAHILI | TAML TA TAMIL > TELU TE TELUGU | TG TAJIK | THAI TH THAI > ETHI TI TIGRINYA | TK TURKMEN | LATN TL TAGALOG > LATN TN TSWANA | LATN TO TONGA (TONGA | LATN TR TURKISH > LATN TS TSONGA | TT TATAR | TW TWI > TY TAHITIAN | UG UIGHUR; UYGHU | CYRL UK UKRAINIAN > ARAB UR URDU | UZ UZBEK | LATN VE VENDA > LATN VI VIETNAMESE | VO VOLAPüK | WA WALLOON > LATN WO WOLOF | LATN XH XHOSA | HEBR YI YIDDISH > YO YORUBA | ZA ZHUANG; CHUAN | ZH CHINESE > LATN ZU ZULU | ACE ACHINESE | ACH ACOLI > ADA ADANGME | ADY ADYGHE; ADYGE | AFA AFRO-ASIATIC > AFH AFRIHILI | AKK AKKADIAN | ALE ALEUT > ALG ALGONQUIAN LA | ALT SOUTHERN ALTA | ANG ENGLISH, OLD > APA APACHE LANGUA | ARC ARAMAIC | ARN ARAUCANIAN > ARP ARAPAHO | ART ARTIFICIAL (O | ARW ARAWAK > AST ASTURIAN; BAB | ATH ATHAPASCAN LA | AUS AUSTRALIAN LA > AWA AWADHI | BAD BANDA | BAI BAMILEKE LANG > BAL BALUCHI | BAN BALINESE | BAS BASA > BAT BALTIC (OTHER | BEJ BEJA | BEM BEMBA > BER BERBER (OTHER | BHO BHOJPURI | BIK BIKOL > BIN BINI | BLA SIKSIKA | BNT BANTU (OTHER) > BRA BRAJ | BTK BATAK (INDONE | BUA BURIAT > BUG BUGINESE | BYN BLIN; BILIN | CAD CADDO > CAI CENTRAL AMERI | CAR CARIB | CAU CAUCASIAN (OT > CEB CEBUANO | CEL CELTIC (OTHER | CHB CHIBCHA > CHG CHAGATAI | CHK CHUUKESE | CHM MARI > CHN CHINOOK JARGO | CHO CHOCTAW | CHP CHIPEWYAN > CHR CHEROKEE | CHY CHEYENNE | CMC CHAMIC LANGUA > COP COPTIC | LATN CPE CREOLES AND P | CPF CREOLES AND P > CPP CREOLES AND P | CRH CRIMEAN TATAR | CRP CREOLES AND P > CSB KASHUBIAN | CUS CUSHITIC (OTH | DAK DAKOTA > DAR DARGWA | DAY DAYAK | DEL DELAWARE > DEN SLAVE (ATHAPA | DGR DOGRIB | DIN DINKA > DOI DOGRI | DRA DRAVIDIAN (OT | DSB LOWER SORBIAN > DUA DUALA | DUM DUTCH, MIDDLE | DYU DYULA > EFI EFIK | EGY EGYPTIAN (ANC | EKA EKAJUK > ELX ELAMITE | ENM ENGLISH, MIDD | EWO EWONDO > FAN FANG | FAT FANTI | FIL FILIPINO; PIL > FIU FINNO-UGRIAN | FON FON | FRM FRENCH, MIDDL > FRO FRENCH, OLD ( | FUR FRIULIAN | GAA GA > GAY GAYO | GBA GBAYA | GEM GERMANIC (OTH > GEZ GEEZ | GIL GILBERTESE | GMH GERMAN, MIDDL > GOH GERMAN, OLD H | GON GONDI | GOR GORONTALO > GOT GOTHIC | GRB GREBO | GRC GREEK, ANCIEN > GWI GWICH´IN | HAI HAIDA | HAW HAWAIIAN > HIL HILIGAYNON | HIM HIMACHALI | HIT HITTITE > HMN HMONG | HSB UPPER SORBIAN | HUP HUPA > IBA IBAN | IJO IJO | ILO ILOKO > INC INDIC (OTHER) | INE INDO-EUROPEAN | INH INGUSH > IRA IRANIAN (OTHE | IRO IROQUOIAN LAN | JBO LOJBAN > JPR JUDEO-PERSIAN | JRB JUDEO-ARABIC | KAA KARA-KALPAK > KAB KABYLE | KAC KACHIN | KAM KAMBA > KAR KAREN | KAW KAWI | KBD KABARDIAN > KHA KHASI | KHI KHOISAN (OTHE | KHO KHOTANESE > KMB KIMBUNDU | DEVA KOK KONKANI | KOS KOSRAEAN > KPE KPELLE | KRC KARACHAY-BALK | KRO KRU > KRU KURUKH | KUM KUMYK | KUT KUTENAI > LAD LADINO | LAH LAHNDA | LAM LAMBA > LEZ LEZGHIAN | LOL MONGO | LOZ LOZI > LUA LUBA-LULUA | LUI LUISENO | LUN LUNDA > LUO LUO (KENYA AN | LUS LUSHAI | MAD MADURESE > MAG MAGAHI | DEVA MAI MAITHILI | MAK MAKASAR > MAN MANDINGO | MAP AUSTRONESIAN | MAS MASAI > MDF MOKSHA | MDR MANDAR | LATN MEN MENDE > MGA IRISH, MIDDLE | MIC MI'KMAQ; MICM | MIN MINANGKABAU > MIS MISCELLANEOUS | MKH MON-KHMER (OT | MNC MANCHU > MNI MANIPURI | MNO MANOBO LANGUA | MOH MOHAWK > MOS MOSSI | MUL MULTIPLE LANG | MUN MUNDA LANGUAG > MUS CREEK | MWL MIRANDESE | MWR MARWARI > MYN MAYAN LANGUAG | MYV ERZYA | NAH NAHUATL > NAI NORTH AMERICA | NAP NEAPOLITAN | NDS LOW GERMAN; L > NEW NEPAL BHASA; | NIA NIAS | NIC NIGER-KORDOFA > LATN NIU NIUEAN | NOG NOGAI | NON NORSE, OLD > LATN NSO NORTHERN SOTH | NUB NUBIAN LANGUA | NWC CLASSICAL NEW > NYM NYAMWEZI | NYN NYANKOLE | NYO NYORO > NZI NZIMA | OSA OSAGE | OTA TURKISH, OTTO > OTO OTOMIAN LANGU | PAA PAPUAN (OTHER | PAG PANGASINAN > PAL PAHLAVI | PAM PAMPANGA | PAP PAPIAMENTO > PAU PALAUAN | PEO PERSIAN, OLD | PHI PHILIPPINE (O > PHN PHOENICIAN | PON POHNPEIAN | PRA PRAKRIT LANGU > PRO PROVENçA | QAA PRIVATE USE | RAJ RAJASTHANI > RAP RAPANUI | RAR RAROTONGAN | ROA ROMANCE (OTHE > ROM ROMANY | SAD SANDAWE | SAH YAKUT > SAI SOUTH AMERICA | SAL SALISHAN LANG | SAM SAMARITAN ARA > SAS SASAK | SAT SANTALI | SCN SICILIAN > SCO SCOTS | SEL SELKUP | SEM SEMITIC (OTHE > SGA IRISH, OLD (T | SGN SIGN LANGUAGE | SHN SHAN > SID SIDAMO | SIO SIOUAN LANGUA | SIT SINO-TIBETAN > SLA SLAVIC (OTHER | SMA SOUTHERN SAMI | SMI SAMI LANGUAGE > SMJ LULE SAMI | SMN INARI SAMI | SMS SKOLT SAMI > SNK SONINKE | SOG SOGDIAN | LATN SON SONGHAI > SRN SRANAN TONGO | SRR SERER | SSA NILO-SAHARAN > SUK SUKUMA | SUS SUSU | SUX SUMERIAN > SYR SYRIAC | TAI TAI (OTHER) | LATN TEM TIMNE > TER TERENO | TET TETUM | TIG TIGRE > TIV TIV | LATN TKL TOKELAU | TLH KLINGON; TLHI > TLI TLINGIT | LATN TMH TAMASHEK | TOG TONGA (NYASA) > LATN TPI TOK PISIN | TSI TSIMSHIAN | TUM TUMBUKA > TUP TUPI LANGUAGE | TUT ALTAIC (OTHER | LATN TVL TUVALU > TYV TUVINIAN | UDM UDMURT | UGA UGARITIC > UMB UMBUNDU | UND UNDETERMINED | VAI VAI > VOT VOTIC | WAK WAKASHAN LANG | WAL WALAMO > WAR WARAY | WAS WASHO | WEN SORBIAN LANGU > XAL KALMYK; OIRAT | YAO YAO | YAP YAPESE > YPK YUPIK LANGUAG | ZAP ZAPOTEC | ZEN ZENAGA > ZND ZANDE | ZUN ZUNI | >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQ8-0006G5-Lt; Mon, 02 May 2005 07:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSLCY-00030a-G7 for ltru@megatron.ietf.org; Sun, 01 May 2005 16:38:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15615 for ; Sun, 1 May 2005 16:38:04 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSLQ6-0002d7-AI for ltru@ietf.org; Sun, 01 May 2005 16:52:06 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 13:37:56 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 May 2005 13:37:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Open tickets on initial registry Date: Sun, 1 May 2005 13:38:03 -0700 Message-ID: Thread-Topic: [Ltru] Re: Open tickets on initial registry Thread-Index: AcVOEBxfPuYCqXspQiehfDQ8cqu7vwAfR2Wg From: "Peter Constable" To: X-OriginalArrivalTime: 01 May 2005 20:37:56.0787 (UTC) FILETIME=[A81EC030:01C54E8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > > 878 should the initial registry contents i-d be > > published as an RFC? >=20 > > My opinion is NO on the second (878). >=20 > Without any procedure to get most Suppress-Scripts > right before the final date B my opinion is YES. I'd like to think it should be possible to get 3066bis moving toward last call independent of the process of getting the initial registry prepared. If publishing the registry as an RFC would facilitate that, then perhaps that should be considered. What I don't want to see is progress on 3066bis stagnate while we process the initial registry values, which I think has been happening a bit. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQ9-0006Ge-SX; Mon, 02 May 2005 07:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSMhn-0003A5-Lv for ltru@megatron.ietf.org; Sun, 01 May 2005 18:14:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20584 for ; Sun, 1 May 2005 18:14:24 -0400 (EDT) Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSMvL-000418-1k for ltru@ietf.org; Sun, 01 May 2005 18:28:28 -0400 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050501221411.YAAS4191.mta13.adelphia.net@DEWELL>; Sun, 1 May 2005 18:14:11 -0400 Message-ID: <003901c54e9a$a780e6a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B38FD4D@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: ISO 3166-1 DIS ballot Date: Sun, 1 May 2005 15:10:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I don't think you guys are saying anything different from one another. > Actually, I'm a bit baffled by this thread. Frank's note seems to > indicate that coupled with the 50-year period the general approach to > handling region codes will work. He then goes on to suggest what he > has consistently advocated: that canonical mappings should follow > country code assignments. > > The contrary opinion has been stated by several people on this list > (most recently by John Cowan), which is that we shouldn't be forced by > ISO 3166 to create instability in language tags by constantly > assigning and withdrawing codes. Then I agree with John. I don't think changing the subtags people "should" use because of changes in ISO 3166 does anything to solve the stability problem. The approach described by the draft requires no "emergency exit" to handle ISO changes; on the contrary, it carefully plans for them. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQC-0006II-Hj; Mon, 02 May 2005 07:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSQ9P-0004jk-Fr for ltru@megatron.ietf.org; Sun, 01 May 2005 21:55:11 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00965 for ; Sun, 1 May 2005 21:55:07 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050502015438.QAU13270.mta11.adelphia.net@DEWELL> for ; Sun, 1 May 2005 21:54:38 -0400 Message-ID: <004601c54eb9$8bf60680$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050501090019.EVU11382.mta7.adelphia.net@megatron.ietf.org> Date: Sun, 1 May 2005 18:52:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >>> Maybe Doug can use ZZ as an additional plausibilty test. >> >> Plausibility of what? > > Of the output of your region code generator. Mark's ZZ- > codes plus TW should match all non-deprecated alpha-2 > codes without UN number. It's about something I don't > see, somewhere hidden in the generator you match numbers > and alpha-2 codes to catch the remaining UN numbers for > the registry. Or do you do this manually ? Not really > important, but with this zoo of codes it's easy to miss > something. I don't have a region code generator. I do what we've been talking about, manually: start with the current ISO 3166-1 codes, then add the ones that were withdrawn since 1988, then add the UN codes for macrogeographic regions, plus 830 and 833 because the represent country-like regions that don't have an ISO code, plus 200 because we haven't yet reached consensus to remove it. In particular, I don't cross-check the set of region codes with CLDR, MARC, the CIA Factbook, or any other reference. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQC-0006Ig-L3; Mon, 02 May 2005 07:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSQGv-0005Ea-Aq for ltru@megatron.ietf.org; Sun, 01 May 2005 22:02:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01377 for ; Sun, 1 May 2005 22:02:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSQUV-00073F-TM for ltru@ietf.org; Sun, 01 May 2005 22:17:00 -0400 Received: from lns-p19-19-idf-82-254-255-93.adsl.proxad.net ([82.254.255.93] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DSQGt-0003Yd-O1 for ltru@ietf.org; Sun, 01 May 2005 19:02:56 -0700 Message-Id: <6.2.1.2.2.20050502033918.0573bd60@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 02 May 2005 04:02:52 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Ltru] regionalisation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org For information I engage a project which calls for a certain convergence of E.164 and ISO 3166. I will need to know the main script and language for a given telephone exchange (on-line telephone directory). I note that IETF is engaged in utilising ISO 3166 alpha-2 codes - with the problems Franck rises - only because at the beginning we needed to build names and chose ISO 3166 alpha-3 first, and pasted alpha-2 for refilers when connecting the ARPA Internet. We were also using X.121 but IETF was never concerned due to the slowliness of IPv6 (however the DoD wrote an RFC on the matter). Anyway X.121 uses nationwide DCC - (Data Country Codes) as does ISO 3166. Internet is a network communication tool and ITU is more appropriate for the defining the regionalisation standard of a network than ISO and UN. Actually E.163 and area codes are probably more precise for what we want to document than ISO 3166 even ISO 3166-2 which is only a list, while the telephone directory is usually hierarchical and very local. We obviously have a problem of stability. I tend to think E.164 is by nature more stable than ISO 3166 and it is all numeric. Main area codes stability is actually to consider: a part from adjustments like in the US due to the scarcity of number in some zones, or the reorganisation of the French system adding a regional layer, I tend to think it is more stable than ISO-3166-2 which keeps fixed location, while area code and exchanges tend to follow the population (what interests us in term of language). Has someone considered the inputs from the WG-Geopriv? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQD-0006KB-RU; Mon, 02 May 2005 07:49:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSTjo-0004Ho-0V for ltru@megatron.ietf.org; Mon, 02 May 2005 01:45:01 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14040 for ; Mon, 2 May 2005 01:44:58 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050502054428.GXPV13270.mta11.adelphia.net@DEWELL>; Mon, 2 May 2005 01:44:28 -0400 Message-ID: <007201c54ed9$cd569340$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 1 May 2005 22:42:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Last registry for now X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org When I first mocked up a sample of the proposed Language Subtag Registry back in July 2004, based on the description in draft-phillips-langtags-04, my intent was to show list members on ietf-languages what the registry would look like, and how it would be updated to reflect any changes in the core ISO standards or IETF registrations. I hoped it would encourage any necessary questions about the format of the registry, the update process, and the subtag mechanism itself. To a great extent, this has been successful. Unfortunately, it seems that to an even greater extent, the continual updating of the sample registry has become a distraction from the overall process of evaluating the draft, and moving it toward the Last Call that is scheduled for this month. This has become especially true in regard to discussions that focus on the exact contents of the registry and on decisions to exclude (or include) certain "useless" or "stupid" subtags, usually region subtags. It seems that by updating the contents of the registry so frequently -- about 30 times since July -- I have been a major contributor to this distraction. Additionally, my role in trying to maintain a draft registry has become badly misunderstood. I am not some kind of Registry Czar who imposes his personal will on which subtags "should" and "should not" be valid. I make only those changes that seem to have consensus within the group or seem uncontroversial. I have never tried to effect changes in the draft by going through the "back door" of the registry. Unfortunately, some recent posts to the effect that "maybe Doug can do this or that" imply that the draft is (or should be) controlled by the registry, not the other way around. This is not good. It would be perfectly possible for WG members to visualize how the "live" registry will look and behave, and use that information to evaluate the draft, without constant and distracting changes in the content of the sample registry. Section 3.7 of draft-01 explains how the initial registry will be constructed from the core ISO standards and the existing Language Tag Registry, and how it will be updated. In particular, it states that the initial registry will be submitted for a Last Call of its own. That is the time when group members should focus on fine-tuning the registry, not now. Consequently, I have uploaded a new sample registry, dated 2005-04-30, to the usual URL: http://users.adelphia.net/~dewell/lstreg.txt Barring any further architectural changes to the registry, this will be the LAST registry update I will make until the draft passes Last Call. "Architectural changes" would include things like new fields, changes in field names, or a change in the overall format of the registry. To demonstrate this, the current version makes *only* the following changes over the previous version, dated 2005-04-19: 1. The "%%" lines at the start and end of the file are dropped. 2. Underscores in field names are replaced by hyphens. For example, "File_Date" is changed to "File-Date". 3. Descriptions are copied exactly from the ISO standards, including any non-Latin-1 characters. Note that none of the content changes we have been discussing lately (e.g. tweaks to Suppress-Script entries and UN macrogeographical codes) are incorporated. This is intentional, because including these changes would only start another round of registry fine-tuning threads and would push the draft document even farther away from completion. If any list members feel (as I do) that some or all of these content changes should be incorporated in the initial registry, the time to discuss this is after the draft is approved, during the registry Last Call. In the meantime, let's focus on getting any remaining issues resolved in draft-01, and moving it toward Last Call, because if that doesn't happen, the registry won't matter one bit. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQD-0006KZ-VB; Mon, 02 May 2005 07:49:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSUss-0003YD-Hl for ltru@megatron.ietf.org; Mon, 02 May 2005 02:58:26 -0400 Received: from gundel.de.clara.net (gundel.de.clara.net [212.82.225.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08940 for ; Mon, 2 May 2005 02:58:14 -0400 (EDT) Received: from [212.82.251.104] (helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1DSV5m-000JSV-TF for ltru@lists.ietf.org; Mon, 02 May 2005 09:11:47 +0200 Message-ID: <4275CE69.84E@xyzzy.claranet.de> Supersedes: <4274A94F.2D66@xyzzy.claranet.de> Date: Sun, 01 May 2005 12:02:55 +0200 From: Frank Ellermann Organization: X-Mailer: Mozilla 3.0 (OS/2; U) MIME-Version: 1.0 To: ltru@ietf.org References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> <01d901c54892$06b864e0$030aa8c0@DEWELL> <42746656.6F00@xyzzy.claranet.de> <42749A09.566AA286@egt.ie> <4274A94F.2D66@xyzzy.claranet.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: New registry with Suppress_Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Marion Gunn wrote: > You seem to be missing LATN before KW and BR in some places, > as in: > LATN KW CORNISH > LATN BR BRETON And others like fy, li, oc, nds, and what Doug already said. > Is this at all significant, or am I missing something? IMO it is significant, the missing piece is a procedure to fill these gaps. > 100s of msgs (more than one could be expected to read) > coming through thick and fast on list . It's quiet again after Randy gagged his ticket system ;-) [reposted, mailing list problem after 2005-05-01 12:00 (?)] _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 07:49:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQE-0006Kx-2K; Mon, 02 May 2005 07:49:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSUss-0003YC-Hl for ltru@megatron.ietf.org; Mon, 02 May 2005 02:58:26 -0400 Received: from gundel.de.clara.net (gundel.de.clara.net [212.82.225.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08942 for ; Mon, 2 May 2005 02:58:15 -0400 (EDT) Received: from [212.82.251.104] (helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1DSV5k-000JSG-JC; Mon, 02 May 2005 09:11:45 +0200 Message-ID: <4275CDDE.F20@xyzzy.claranet.de> Supersedes: <4274D58C.542D@xyzzy.claranet.de> References: <4274D58C.542D@xyzzy.claranet.de> Date: Sun, 01 May 2005 15:11:41 +0200 From: Frank Ellermann Organization: X-Mailer: Mozilla 3.0 (OS/2; U) MIME-Version: 1.0 To: ltru@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Open points before -02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, here's my short list of issues in -01 (details later): 1 - check and fill gaps in Suppress-Scripts 2 - check SHOULD, MUST, and rationale for Suppress-Scripts 3 - improve registry ABNF, simplify the corresponding chapter 4 - redefine canonical / deprecated to follow the underlying ISO and UN standards (stable forever != canonical forever) 5 - move redundant tags from draft registry to an appendix If that's really all we should in theory be ready in about two weeks, excluding point 1 "Suppress-Script gaps", that could be the most time consuming problem. Transforming Doug's lstreg.txt to proto-I-D-XML, and creating a proper I-D with xml2rfc, should be a matter of hours. Bye. [reposted, mailing list problem after 2005-05-01 12:00 (?)] _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 10:24:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSbqy-0003PO-Kf; Mon, 02 May 2005 10:24:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSbqx-0003I4-7I for ltru@megatron.ietf.org; Mon, 02 May 2005 10:24:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21363 for ; Mon, 2 May 2005 10:24:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSc4e-0004pW-5D for ltru@ietf.org; Mon, 02 May 2005 10:39:04 -0400 Received: from i01m-116-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DSbqm-0000Mz-Vc for ltru@ietf.org; Mon, 02 May 2005 07:24:45 -0700 Message-Id: <6.2.1.2.2.20050502162405.040e9c50@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 02 May 2005 16:24:38 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Last registry for now Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Doug, thank you for this effort. You only face the usual problem of a decentralised network. When someone starts doing something of common use there are two normal reactions: 1. he is the csar (centralized/dominance network syndrom) 2. why does he do it this way (decentralized/democratic network syndrom). This is because he creates something abnormal in a decentralized network: a single point of possible unreliability/dependance. In a distributed network it works by subsidiarity. Each is caring for his own destiny and freely decides who he trusts and how he organises his own security. When someone interferes in the best interest of someone else (as you do) it is not to stay/block/stop, it is to transfer and remove oneselve once he has permitted others to behave by their own. What I need (and this is the problem of the whole IANA), is a copy of the software generator and a reference to your sources. To be able to run it. To verify that I reach the same file as yours in making a diff. There are two solutions: - either the registry is entrusted to the IEFT and maintained/published as an RFC and your tool is used to produced the RFC and the check is made by the members of the WG who want. The Internet being the adherence to the RFC/BPC/STD one can presume most will be satisfied by the IESG final check. - either the registry is entrusted to the IANA - in a way similar to the DNS files. Then there is an urgent need for the description of a stable noh-IANA process of verification, maintenance, cross-checks, as the one I run for the DNS on a daily basis reaching a real life situation which (for a reference file) quite different from the DNS NTI/ICANN root (http://nicso.org) I documented several time. CENTR and ccNSO members are just now starting anew a review process of the IANA deliverables. When you see the dispute over the "CS" case ... I suppose you would be puzzled about the IANA management of the ccTLD tables. To do that, we need the stable, clear, scalable description (requested by the Charter) about the way the Internet addresses the ISO and non-ISO tables variations. This should lead to one or several documented codes (practice and codes are the basis for IESG approvals) generating the same registry information from the same sources. For that your sources must be quoted in your file header (also to acknowledge the true authors). Please provide the trusted URL of the source files you used and the source code or the code logic you followed. We inspect them, build our own code and generate a copy. We will check it with yours to verify that we both/all are right and to understand and correct the possible discrepancies. Otherwise we will run it by our own, and if there is a discrepancy we start with another unnecessary dispute on sources and concepts. jfc On 07:42 02/05/2005, Doug Ewell said: >When I first mocked up a sample of the proposed Language Subtag Registry >back in July 2004, based on the description in >draft-phillips-langtags-04, my intent was to show list members on >ietf-languages what the registry would look like, and how it would be >updated to reflect any changes in the core ISO standards or IETF >registrations. I hoped it would encourage any necessary questions about >the format of the registry, the update process, and the subtag mechanism >itself. To a great extent, this has been successful. > >Unfortunately, it seems that to an even greater extent, the continual >updating of the sample registry has become a distraction from the >overall process of evaluating the draft, and moving it toward the Last >Call that is scheduled for this month. This has become especially true >in regard to discussions that focus on the exact contents of the >registry and on decisions to exclude (or include) certain "useless" or >"stupid" subtags, usually region subtags. > >It seems that by updating the contents of the registry so frequently -- >about 30 times since July -- I have been a major contributor to this >distraction. > >Additionally, my role in trying to maintain a draft registry has become >badly misunderstood. I am not some kind of Registry Czar who imposes >his personal will on which subtags "should" and "should not" be valid. >I make only those changes that seem to have consensus within the group >or seem uncontroversial. I have never tried to effect changes in the >draft by going through the "back door" of the registry. Unfortunately, >some recent posts to the effect that "maybe Doug can do this or that" >imply that the draft is (or should be) controlled by the registry, not >the other way around. This is not good. > >It would be perfectly possible for WG members to visualize how the >"live" registry will look and behave, and use that information to >evaluate the draft, without constant and distracting changes in the >content of the sample registry. > >Section 3.7 of draft-01 explains how the initial registry will be >constructed from the core ISO standards and the existing Language Tag >Registry, and how it will be updated. In particular, it states that the >initial registry will be submitted for a Last Call of its own. That is >the time when group members should focus on fine-tuning the registry, >not now. > >Consequently, I have uploaded a new sample registry, dated 2005-04-30, >to the usual URL: > >http://users.adelphia.net/~dewell/lstreg.txt > >Barring any further architectural changes to the registry, this will be >the LAST registry update I will make until the draft passes Last Call. >"Architectural changes" would include things like new fields, changes in >field names, or a change in the overall format of the registry. To >demonstrate this, the current version makes *only* the following changes >over the previous version, dated 2005-04-19: > >1. The "%%" lines at the start and end of the file are dropped. > >2. Underscores in field names are replaced by hyphens. For example, >"File_Date" is changed to "File-Date". > >3. Descriptions are copied exactly from the ISO standards, including >any non-Latin-1 characters. > >Note that none of the content changes we have been discussing lately >(e.g. tweaks to Suppress-Script entries and UN macrogeographical codes) >are incorporated. This is intentional, because including these changes >would only start another round of registry fine-tuning threads and would >push the draft document even farther away from completion. If any list >members feel (as I do) that some or all of these content changes should >be incorporated in the initial registry, the time to discuss this is >after the draft is approved, during the registry Last Call. > >In the meantime, let's focus on getting any remaining issues resolved in >draft-01, and moving it toward Last Call, because if that doesn't >happen, the registry won't matter one bit. > >-- >Doug Ewell >Fullerton, California >http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 10:25:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSbru-0005zA-Mi; Mon, 02 May 2005 10:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSbrt-0005z1-5O for ltru@megatron.ietf.org; Mon, 02 May 2005 10:25:53 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21390 for ; Mon, 2 May 2005 10:25:50 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSbkx-0003uW-FE for ltru@lists.ietf.org; Mon, 02 May 2005 16:18:43 +0200 Received: from c-134-88-194.hh.dial.de.ignite.net ([62.134.88.194]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 16:18:43 +0200 Received: from nobody by c-134-88-194.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 16:18:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 02 May 2005 16:08:57 +0200 Organization: Lines: 18 Message-ID: <42763479.6004@xyzzy.claranet.de> References: <20050501090019.EVU11382.mta7.adelphia.net@megatron.ietf.org> <004601c54eb9$8bf60680$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-194.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I don't cross-check the set of region codes with CLDR, I'll try this one when I've time. The difference should be something like ZZ, 003. 021, 200, 830, and 833. > the CIA Factbook That won't work, it's based on the different FIPS 10-4: All parts of UM (Wake, Johnston, Midland, Navassa, etc.) separately, some French islands like Europe and Glorioso near Madagascar, the Spratly- and Paracel Islands, PS as West Bank + Gaza strip Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 11:56:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSdHS-0003DR-N4; Mon, 02 May 2005 11:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSdHQ-0003DD-Gf for ltru@megatron.ietf.org; Mon, 02 May 2005 11:56:20 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28049 for ; Mon, 2 May 2005 11:56:17 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSdAl-0001x6-Ub for ltru@lists.ietf.org; Mon, 02 May 2005 17:49:27 +0200 Received: from c-134-88-194.hh.dial.de.ignite.net ([62.134.88.194]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 17:49:27 +0200 Received: from nobody by c-134-88-194.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 17:49:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 02 May 2005 17:43:02 +0200 Organization: Lines: 57 Message-ID: <42764A86.3457@xyzzy.claranet.de> References: <007201c54ed9$cd569340$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-194.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last registry for now X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > the continual updating of the sample registry has become a > distraction from the overall process of evaluating the draft Without your draft registry I wouldn't understand one word in the registry draft (excl. its ABNF), the draft registry is no distraction, quite the contrary, it's the essence. > decisions to exclude (or include) certain "useless" or > "stupid" subtags, usually region subtags. 200 reflects a procedural issue in the registry draft, and 003 might be a hint that UN M49 is not as consistent as we hoped. Whether it's "stupid" or "useless" is beside the point, but we cannot get rid of it as soon as it's in. The registry draft creates a stable registry. Subtags are never deleted. We are damned to get it right. I've no problem with this principle, but it has some disadvantages, and 003 helped me to see this. Of course it's more relevant for registered languages and for registered variants, John proposed some generic variants like -northern on the languages list. Playing with your draft registry allows me to test such ideas, and maybe the registry draft should say that generic variants are a bad idea. If that's the case, I'm not at all sure. > I make only those changes that seem to have consensus within > the group or seem uncontroversial. Yes, and if some results are strange it's not your fault, but a problem in the registry draft or in the source standards. > the time when group members should focus on fine-tuning the > registry, not now. IBTD. Trying to do something with your draft registry is the best way to find problems in the registry draft. Four of my five "last points" are a direct consequence of simply trying to parse lstreg.txt 2005-04-30. These five "last points" are certainly not about the two obscure region codes 003 and 200. > the current version makes *only* the following changes over > the previous version, dated 2005-04-19: [...] 4. Added date of deprecation to "jw". (2001-08-13) I've checked all xrefs and a diff. The "forever stable" idea means _one_ chance to get it right for subtag values. Other fields can be fixed, missing subtags can be added, but there's no clean way to get rid of unwanted subtags. Even if they are deprecated they'll block the corresponding field value forever. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 13:05:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeLy-0005GY-6f; Mon, 02 May 2005 13:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeLw-0005BV-7M for ltru@megatron.ietf.org; Mon, 02 May 2005 13:05:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04595 for ; Mon, 2 May 2005 13:05:01 -0400 (EDT) Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSeZd-0007zn-KE for ltru@ietf.org; Mon, 02 May 2005 13:19:14 -0400 Received: (qmail 53751 messnum 2892177 invoked from network[194.125.207.107/ts11-107.dublin.indigo.ie]); 2 May 2005 17:04:50 -0000 Received: from ts11-107.dublin.indigo.ie (HELO egt.ie) (194.125.207.107) by mail07.svc.cra.dublin.eircom.net (qp 53751) with SMTP; 2 May 2005 17:04:50 -0000 Message-ID: <42765D34.7BE584F5@egt.ie> Date: Mon, 02 May 2005 18:02:44 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Last registry for now References: <007201c54ed9$cd569340$030aa8c0@DEWELL> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA04595 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Scr=EDobh Doug Ewell: > ... >=20 > 2. Underscores in field names are replaced by hyphens. For example, > "File_Date" is changed to "File-Date"... Was there some irresistible reason for that last-minute framework change, Doug?=20 I ask because underscores are linguistically neutral, hyphens not so, and you just wouldn't want to know what that change would do to some languages (if ever your registry were to be localized for use on non-English servers). Best, mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 13:10:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeRJ-0002Ji-Hp; Mon, 02 May 2005 13:10:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeRI-0002Jd-Nl for ltru@megatron.ietf.org; Mon, 02 May 2005 13:10:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04909 for ; Mon, 2 May 2005 13:10:32 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSeey-000860-DA for ltru@ietf.org; Mon, 02 May 2005 13:24:45 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 10:10:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last registry for now Date: Mon, 2 May 2005 10:10:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B38FFF0@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last registry for now Thread-Index: AcVPOTULDyjiy8wmSdK++BtrTd+R2AAAFj/Q From: "Addison Phillips" To: "Marion Gunn" X-OriginalArrivalTime: 02 May 2005 17:10:23.0457 (UTC) FILETIME=[D3C52510:01C54F39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Because the draft says so. The hyphen is defined in the field names (tokens that will remain in = "English", i.e. they are identifiers and not localizable values). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Marion Gunn > Sent: 2005?5?2? 10:03 > Cc: LTRU Working Group > Subject: Re: [Ltru] Last registry for now >=20 > Scr=EDobh Doug Ewell: > > ... > > > > 2. Underscores in field names are replaced by hyphens. For = example, > > "File_Date" is changed to "File-Date"... >=20 > Was there some irresistible reason for that last-minute framework > change, Doug? >=20 > I ask because underscores are linguistically neutral, hyphens not so, > and you just wouldn't want to know what that change would do to some > languages (if ever your registry were to be localized for use on > non-English servers). >=20 > Best, > mg >=20 >=20 > -- >=20 > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 13:11:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeSb-0002dM-Bz; Mon, 02 May 2005 13:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeSa-0002dH-CE for ltru@megatron.ietf.org; Mon, 02 May 2005 13:11:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05080 for ; Mon, 2 May 2005 13:11:53 -0400 (EDT) Received: from mail13.svc.cra.dublin.eircom.net ([159.134.118.29]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSegI-00088L-0K for ltru@ietf.org; Mon, 02 May 2005 13:26:07 -0400 Received: (qmail 1467 messnum 4212633 invoked from network[194.125.207.107/ts11-107.dublin.indigo.ie]); 2 May 2005 17:11:44 -0000 Received: from ts11-107.dublin.indigo.ie (HELO egt.ie) (194.125.207.107) by mail13.svc.cra.dublin.eircom.net (qp 1467) with SMTP; 2 May 2005 17:11:44 -0000 Message-ID: <42765ED4.46DA1711@egt.ie> Date: Mon, 02 May 2005 18:09:39 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: Last registry for now References: <007201c54ed9$cd569340$030aa8c0@DEWELL> <42764A86.3457@xyzzy.claranet.de> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA05080 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org And I'd describe Doug's draft registry as his lighting of a candle where others might have only cursed the dark. Keep up the good work,=20 mg=20 Scr=EDobh Frank Ellermann: > ... > Without your draft registry I wouldn't understand one word in > the registry draft (excl. its ABNF), the draft registry is no > distraction, quite the contrary, it's the essence... --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 13:18:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeZG-000133-Tn; Mon, 02 May 2005 13:18:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeZF-0000uB-SH for ltru@megatron.ietf.org; Mon, 02 May 2005 13:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05683 for ; Mon, 2 May 2005 13:18:47 -0400 (EDT) Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSemx-0008Ij-CZ for ltru@ietf.org; Mon, 02 May 2005 13:33:00 -0400 Received: (qmail 29728 messnum 6391270 invoked from network[194.125.207.107/ts11-107.dublin.indigo.ie]); 2 May 2005 17:18:38 -0000 Received: from ts11-107.dublin.indigo.ie (HELO egt.ie) (194.125.207.107) by mail00.svc.cra.dublin.eircom.net (qp 29728) with SMTP; 2 May 2005 17:18:38 -0000 Message-ID: <42766071.D443EC06@egt.ie> Date: Mon, 02 May 2005 18:16:32 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Last registry for now References: <634978A7DF025A40BFEF33EB191E13BC0B38FFF0@irvmbxw01.quest.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA05683 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Unseen identifiers? If so, it doesn't matter. If not, it does. Or maybe not. My 'candle' comment still stands.:-) mg Scr=EDobh Addison Phillips: >=20 > Because the draft says so. >=20 > The hyphen is defined in the field names (tokens that will remain in "E= nglish", i.e. they are identifiers and not localizable values). >=20 > Addison --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 14:45:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfum-0004DD-SY; Mon, 02 May 2005 14:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfuk-0004CE-PX for ltru@megatron.ietf.org; Mon, 02 May 2005 14:45:07 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17393 for ; Mon, 2 May 2005 14:45:04 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSfnO-0002xy-JB for ltru@lists.ietf.org; Mon, 02 May 2005 20:37:30 +0200 Received: from du-001-206.access.de.clara.net ([212.82.227.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 20:37:30 +0200 Received: from nobody by du-001-206.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 20:37:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 02 May 2005 20:39:51 +0200 Organization: Lines: 42 Message-ID: <427673F7.5224@xyzzy.claranet.de> References: <4274D58C.542D@xyzzy.claranet.de> <4275CDDE.F20@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-206.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] 5 - Appendix D: Redundant Tags (was: Open points before -02) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, the details for: | 5 - move redundant tags from draft registry to an appendix At the moment the draft registry contains 64 redundant tags in 320 lines or about 6 KB. Adding the explanation in the registry draft, and the code in all future 3066bis parsers to ignore these 64 really redundant tags I prefer to move them to a new "appendix D" enumeration. Proposed text for the "IANA Considerations": Appendix D (Redundant Tags) lists all tags registered under the rules of [RfC 3066] which are now covered by identical and fully compatible tags composed of subtags. Unlike all other "grandfathered" tags these redundant tags and their registration forms should not be kept in the IANA registry. Proposed text for "Appedix D: Redundant Tags" The following valid tags were registered under the rules of [RfC 3066] and are now covered by identical tags composed of subtags. They are therefore not copied to the list of "grandfathered" tags defined in Section 2.2.8. Redundant tags: az-Arab, az-Cyrl, az-Latn, be-Latn, bs-Cyrl, bs-Latn, cel-gaulish, de-1901, de-1996, de-AT-1901, de-AT-1996, de-CH-1901, de-CH-1996, de-DE-1901, de-DE-1996, en-boont, en-scouse, iu-Cans, iu-Latn, mn-Cyrl, mn-Mong, sgn-BR, sgn-CO, sgn-DE, sgn-DK, sgn-ES, sgn-FR, sgn-GB, sgn-GR, sgn-IE, sgn-IT, sgn-JP, sgn-MX, sgn-NI, sgn-NL, sgn-NO, sgn-PT, sgn-SE, sgn-US, sgn-ZA, sl-nedis, sl-rozaj, sr-Cyrl, sr-Latn, tg-Arab, tg-Cyrl, uz-Cyrl, uz-Latn, yi-latn, zh-guoyu, zh-hakka, zh-Hans, zh-Hans-CN, zh-Hans-HK, zh-Hans-MO, zh-Hans-SG, zh-Hans-TW, zh-Hant, zh-Hant-CN, zh-Hant-HK, zh-Hant-MO, zh-Hant-SG, zh-Hant-TW, zh-xiang. About 25 lines in less than 2 KB text, and no sweat for developers of 3066bis code. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 14:56:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSg5c-0007RN-8Y; Mon, 02 May 2005 14:56:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSg5a-0007P5-Al for ltru@megatron.ietf.org; Mon, 02 May 2005 14:56:18 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18377 for ; Mon, 2 May 2005 14:56:16 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSfzT-00078O-OE for ltru@lists.ietf.org; Mon, 02 May 2005 20:49:59 +0200 Received: from du-001-206.access.de.clara.net ([212.82.227.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 20:49:59 +0200 Received: from nobody by du-001-206.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 20:49:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 02 May 2005 20:44:28 +0200 Organization: Lines: 46 Message-ID: <4276750C.2030@xyzzy.claranet.de> References: <4274D58C.542D@xyzzy.claranet.de> <4275CDDE.F20@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-206.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] 3 - Simplified registry ABNF (was: Open points before -02) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Here's the updated registry ABNF for: | 3 - improve registry ABNF, simplify the corresponding chapter registry = file-date *( "%%" CRLF record ) file-date = "File-Date:" 1*SP date CRLF ; first line record = 1*( field CRLF ) field = type / tag / timestamp / reference / explanation type = "Type:" 1*SP ( subtag-type / "grandfathered" ) subtag-type = "language" / "extlang" / "script" / "region" / "variant" tag = ( "Subtag:" / "Tag:" ) 1*SP tagtext reference = ( "Canonical:" / "Suppress-Script:" / "Recommended-Prefix:" ) 1*SP value explanation = ( "Description:" / "Comments:" ) 1*SP text timestamp = ( "Added:" / "Deprecated:" ) 1*SP date date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; see RfC 3339 value = 1*( ALPHA / DIGIT / "-" ) ; note no WSP text = *( ASC-char / LWSP ) ; note folding WSP ASC-char = %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 UNI-char = "&#x" 2*6HEXDIG ";" I've removed "Redundant:" and tagtype. This ABNF is a subset of the general ABNF in draft -01, and it simplifies the implementation of "registry parsers": - Five sets of fields, line folding 'LWSP' is only possible in the 'text' of an 'explanation' (i.e. "Comments:" or "Description:"). - A Recommended-Prefix with more than 50 characters is impossible, it has no SP for the folding. Removing 14 "Recommended-" would allow 64 characters for a monster "Prefix:", and it would reduce the size of the registry. BTW, the draft -01 prefix limit is 71. - UNI-char is only possible in the 'text' of an 'explanation', six cases of a 'type' are enumerated, 'date' and 'value' have their own syntax without special characters. - No more space 'SP' before the colon, at least one 'SP' after the colon, i.e. colon added to the 11 field names. - The 11 possible field names are more visible than in draft -01. The ABNF reflects Doug's latest draft registry (2005-04-30). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 15:08:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgH4-00034n-RE; Mon, 02 May 2005 15:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgH1-0002KK-30 for ltru@megatron.ietf.org; Mon, 02 May 2005 15:08:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20584 for ; Mon, 2 May 2005 15:08:05 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSgUj-0003ik-I6 for ltru@ietf.org; Mon, 02 May 2005 15:22:18 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 12:07:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] 3 - Simplified registry ABNF (was: Open points before -02) Date: Mon, 2 May 2005 12:07:47 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B3900DB@irvmbxw01.quest.com> Thread-Topic: [Ltru] 3 - Simplified registry ABNF (was: Open points before -02) Thread-Index: AcVPSOLGr5uZKCTEQm21aKrt3uueFQAAGfmg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 02 May 2005 19:07:49.0444 (UTC) FILETIME=[3B817040:01C54F4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I don't like this for a number of reasons. 1. I used the registry format definition over in the section on the = extensions registry. This is only possible if there is a generic = registry ABNF. 2. It is useful to actually describe record-jar formally. Perhaps an I-D = should be created that does just that so that no one else need replicate = this experience. 3. I don't care very much for ultra complicated ABNF which is amply = handled by the text. 4. I don't think this actually makes writing a registry parser any = easier (the tasks are the same) 5. It makes the registry itself somewhat uglier (whitespace use is = somewhat more constrained). One thing I liked about the old registry = format that I miss is that it was more eminently human readable. = Anything that reduces the ability of humans to use the thing I'm not = wild about. But most of this is just my personal predilection and not a technical = objection to doing this. I'll follow consensus on this. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?5?2? 11:44 > To: ltru@ietf.org > Subject: [Ltru] 3 - Simplified registry ABNF (was: Open points before = -02) >=20 > Here's the updated registry ABNF for: >=20 > | 3 - improve registry ABNF, simplify the corresponding chapter >=20 > registry =3D file-date *( "%%" CRLF record ) > file-date =3D "File-Date:" 1*SP date CRLF ; first line > record =3D 1*( field CRLF ) > field =3D type / tag / timestamp / reference / explanation > type =3D "Type:" 1*SP ( subtag-type / "grandfathered" ) > subtag-type =3D "language" / "extlang" / "script" > / "region" / "variant" > tag =3D ( "Subtag:" / "Tag:" ) 1*SP tagtext > reference =3D ( "Canonical:" / "Suppress-Script:" > / "Recommended-Prefix:" ) 1*SP value > explanation =3D ( "Description:" / "Comments:" ) 1*SP text > timestamp =3D ( "Added:" / "Deprecated:" ) 1*SP date > date =3D 4DIGIT "-" 2DIGIT "-" 2DIGIT ; see RfC 3339 > value =3D 1*( ALPHA / DIGIT / "-" ) ; note no WSP > text =3D *( ASC-char / LWSP ) ; note folding WSP > ASC-char =3D %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 > UNI-char =3D "&#x" 2*6HEXDIG ";" >=20 > I've removed "Redundant:" and tagtype. This ABNF is a subset of > the general ABNF in draft -01, and it simplifies the implementation > of "registry parsers": >=20 > - Five sets of fields, line folding 'LWSP' is only possible in the > 'text' of an 'explanation' (i.e. "Comments:" or "Description:"). >=20 > - A Recommended-Prefix with more than 50 characters is impossible, > it has no SP for the folding. Removing 14 "Recommended-" would > allow 64 characters for a monster "Prefix:", and it would reduce > the size of the registry. BTW, the draft -01 prefix limit is 71. >=20 > - UNI-char is only possible in the 'text' of an 'explanation', six > cases of a 'type' are enumerated, 'date' and 'value' have their > own syntax without special characters. >=20 > - No more space 'SP' before the colon, at least one 'SP' after the > colon, i.e. colon added to the 11 field names. >=20 > - The 11 possible field names are more visible than in draft -01. > The ABNF reflects Doug's latest draft registry (2005-04-30). >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 15:09:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgIj-0005Xg-CF; Mon, 02 May 2005 15:09:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgIh-0005Xb-AC for ltru@megatron.ietf.org; Mon, 02 May 2005 15:09:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20879 for ; Mon, 2 May 2005 15:09:49 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSgWQ-0003lV-08 for ltru@ietf.org; Mon, 02 May 2005 15:24:03 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 12:09:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] 5 - Appendix D: Redundant Tags (was: Open points before -02) Date: Mon, 2 May 2005 12:09:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B3900E1@irvmbxw01.quest.com> Thread-Topic: [Ltru] 5 - Appendix D: Redundant Tags (was: Open points before -02) Thread-Index: AcVPRxXOXxeYfyRkS9KzDPMgHAozrAAAyoJQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 02 May 2005 19:09:41.0052 (UTC) FILETIME=[7E0777C0:01C54F4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org One reason we haven't done this is that there are still tags getting = registered (up to Date B, right?) Another is that not listing them might lead to the "where did my = registry go?" questions in the future. The redundant entries are not = actually useful for anything other than answering this question, if you = think about it. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?5?2? 11:40 > To: ltru@ietf.org > Subject: [Ltru] 5 - Appendix D: Redundant Tags (was: Open points = before - > 02) >=20 > Hi, the details for: >=20 > | 5 - move redundant tags from draft registry to an appendix >=20 > At the moment the draft registry contains 64 redundant tags > in 320 lines or about 6 KB. >=20 > Adding the explanation in the registry draft, and the code in > all future 3066bis parsers to ignore these 64 really redundant > tags I prefer to move them to a new "appendix D" enumeration. >=20 > Proposed text for the "IANA Considerations": >=20 > Appendix D (Redundant Tags) lists all tags registered under > the rules of [RfC 3066] which are now covered by identical > and fully compatible tags composed of subtags. Unlike all > other "grandfathered" tags these redundant tags and their > registration forms should not be kept in the IANA registry. >=20 > Proposed text for "Appedix D: Redundant Tags" >=20 > The following valid tags were registered under the rules of > [RfC 3066] and are now covered by identical tags composed > of subtags. They are therefore not copied to the list of > "grandfathered" tags defined in Section 2.2.8. >=20 > Redundant tags: az-Arab, az-Cyrl, az-Latn, be-Latn, bs-Cyrl, > bs-Latn, cel-gaulish, de-1901, de-1996, de-AT-1901, de-AT-1996, > de-CH-1901, de-CH-1996, de-DE-1901, de-DE-1996, en-boont, > en-scouse, iu-Cans, iu-Latn, mn-Cyrl, mn-Mong, sgn-BR, sgn-CO, > sgn-DE, sgn-DK, sgn-ES, sgn-FR, sgn-GB, sgn-GR, sgn-IE, sgn-IT, > sgn-JP, sgn-MX, sgn-NI, sgn-NL, sgn-NO, sgn-PT, sgn-SE, sgn-US, > sgn-ZA, sl-nedis, sl-rozaj, sr-Cyrl, sr-Latn, tg-Arab, tg-Cyrl, > uz-Cyrl, uz-Latn, yi-latn, zh-guoyu, zh-hakka, zh-Hans, > zh-Hans-CN, zh-Hans-HK, zh-Hans-MO, zh-Hans-SG, zh-Hans-TW, > zh-Hant, zh-Hant-CN, zh-Hant-HK, zh-Hant-MO, zh-Hant-SG, > zh-Hant-TW, zh-xiang. >=20 > About 25 lines in less than 2 KB text, and no sweat for developers > of 3066bis code. > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 15:24:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgWl-00065t-RJ; Mon, 02 May 2005 15:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgWj-0005oC-0r for ltru@megatron.ietf.org; Mon, 02 May 2005 15:24:21 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22935 for ; Mon, 2 May 2005 15:24:18 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSgQ6-0005bi-Oi for ltru@lists.ietf.org; Mon, 02 May 2005 21:17:31 +0200 Received: from du-001-206.access.de.clara.net ([212.82.227.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 21:17:30 +0200 Received: from nobody by du-001-206.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 21:17:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 02 May 2005 21:19:27 +0200 Organization: Lines: 11 Message-ID: <42767D3F.453@xyzzy.claranet.de> References: <4274D58C.542D@xyzzy.claranet.de> <4275CDDE.F20@xyzzy.claranet.de> <4276750C.2030@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-206.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 3 - Simplified registry ABNF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > tag = ( "Subtag:" / "Tag:" ) 1*SP tagtext Sorry, a stupid last minute change, s/tagtext/value/ > BTW, the draft -01 prefix limit is 71. No, it says *SP, no LWSP, no folding, therefore it's only 51. Recommended-Prefix:lng-ext-ext-ext-ext-ext-ext-ext-ext-ext-ext-ext-Latn ....5...10....5...20....5...30....5...40....5...50....5...60...5...70.. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 16:53:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShud-0000IZ-Pa; Mon, 02 May 2005 16:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DShua-00083y-4P for ltru@megatron.ietf.org; Mon, 02 May 2005 16:53:04 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14279 for ; Mon, 2 May 2005 16:53:00 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DShns-00052C-D4 for ltru@lists.ietf.org; Mon, 02 May 2005 22:46:09 +0200 Received: from du-001-206.access.de.clara.net ([212.82.227.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 22:46:08 +0200 Received: from nobody by du-001-206.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 22:46:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 02 May 2005 22:22:20 +0200 Organization: Lines: 79 Message-ID: <42768BFC.6959@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B3900DB@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-206.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 3 - Simplified registry ABNF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I used the registry format definition over in the section > on the extensions registry. Oops, these are additional registries _also_ in record-jar format. And they are available online at no cost, in the public domain or with a IETF-compatible royalty free license. Quite a lot of details, not only a registered singleton plus an URL with a list of extension tags in any form defined by their own RfC. > It is useful to actually describe record-jar formally. Yes. And your syntax allows e.g. the colon in a fixed column: Type : variant Recommended-Prefix : en-PN I'm a bit confused by the *SP after the colon. How about LWSP after the colon, if and only if you want to allow folding after the colon (resulting in a max. prefix length 71 instead of 51). I would NOT like this. But at the moment it's hard to see that folding directly after the colon is at least utter dubious for a field body with a date or a tag. Is it really illegal ? Where the field body can start with LWSP it's allowed, but is this the case for a type, date, or tag value ? > Perhaps an I-D should be created that does just that so that > no one else need replicate this experience. But IMHO not as separate LTRU I-D referenced by the main I-D. If somebody loves the record-jat format he can copy its ABNF. > I don't care very much for ultra complicated ABNF which is > amply handled by the text. I don't care for verbose explanations if the same idea can be expressed in a single line of syntax. Probably a matter of taste. But it starts to get ugly if editors say A in ABNF and then add barricades of MUST and SHOULD very close to a "not A". No, you haven't done this, I've seen it elsewhere. > I don't think this actually makes writing a registry parser > any easier (the tasks are the same) I've used the "ignore folding" trick to parse the last draft registry based on the idea of "field types" date, value, type, or text. > It makes the registry itself somewhat uglier (whitespace use > is somewhat more constrained). It's just the format created by Doug, I don't see where that's ugly. There's some unnecessary redundancy, even if you want to keep the ABNF as is you could join all Type and (Sub)tag: Type: whatever \ Whatever: value Subtag: value / In theory you'd lose the info Tag vs. Subtag. In practice it's still obvious, anything without a hyphen is a subtag. At the moment you have 11 (or 12) field names, and 6 (or 7) types. If you join them you'd get 14 (or 15) field names. That was an idea in the "-01 nits". > Anything that reduces the ability of humans to use the thing > I'm not wild about. Same here, but some features of the draft registry are not yet documented in the ABNF. My quick and dirty parser shamelessly used the meta-info Type before (Sub)tag before the rest. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 17:14:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiFh-0001WH-Ua; Mon, 02 May 2005 17:14:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSiFg-0001W3-2Q for ltru@megatron.ietf.org; Mon, 02 May 2005 17:14:52 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15829 for ; Mon, 2 May 2005 17:14:49 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSi9C-0002EN-9m for ltru@lists.ietf.org; Mon, 02 May 2005 23:08:10 +0200 Received: from du-001-206.access.de.clara.net ([212.82.227.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 23:08:10 +0200 Received: from nobody by du-001-206.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2005 23:08:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 02 May 2005 23:10:06 +0200 Organization: Lines: 32 Message-ID: <4276972E.60E4@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B3900E1@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-206.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 5 - Appendix D: Redundant Tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > One reason we haven't done this is that there are still tags > getting registered (up to Date B, right?) Doug apparently wants a date B _after_ date Y, where Y is the day whe the IESG moving the registry draft to the queue of the RfC editor. After date Y the old registry is closed. If there's another landrush of redundant tags on day Y-1 you could add them to appendix D in your 48 hours. > Another is that not listing them might lead to the "where > did my registry go?" questions in the future. They are in appendix D. > The redundant entries are not actually useful for anything > other than answering this question, if you think about it. Unfortunately they do require code, copied from a REXX script: if sign( wordpos( Y, 'REDUNDANT GRANDFATHERED' )) then parse upper var REC 'TAG:' X else parse upper var REC 'SUBTAG:' X if Y = 'REDUNDANT' then XREF = XREF + PREF( X ) Okay, I wanted to check all referecend tags. But without any "Redundant:" I'd have done it inline without a procedure PREF, near the place where I see a "Recommended-Prefix". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 21:57:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSmek-0004Y2-Ja; Mon, 02 May 2005 21:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSmej-0004Xt-3D for ltru@megatron.ietf.org; Mon, 02 May 2005 21:57:01 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12255 for ; Mon, 2 May 2005 21:56:59 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503015629.IUVM13270.mta11.adelphia.net@DEWELL> for ; Mon, 2 May 2005 21:56:29 -0400 Message-ID: <003a01c54f83$4e3603c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050501090019.EVU11382.mta7.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 18:56:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Open tickets on initial registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > Some "Added" are newer than the "Deprecated", that's > an odd side-effect, see below. "Added" is the date the subtag was added to the registry. "Deprecated," for those subtags that already have such a field, is the date the underlying ISO code was withdrawn or deprecated in its respective standard. The idea is that the subtag was actually discouraged from use in RFC 1766 or 3066 as of that date, although those RFCs did not have a formal mechanism for deprecating tags or subtags. Future "Deprecated" dates would be equivalent to the "Added" date; that is, the subtag would be considered deprecated at the moment it was added. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 02 22:05:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSmmx-0005lx-4r; Mon, 02 May 2005 22:05:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSmmv-0005lf-6w for ltru@megatron.ietf.org; Mon, 02 May 2005 22:05:29 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12896 for ; Mon, 2 May 2005 22:05:27 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503020457.UKPL8952.mta9.adelphia.net@DEWELL> for ; Mon, 2 May 2005 22:04:57 -0400 Message-ID: <003f01c54f84$7ed6a240$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050501090019.EVU11382.mta7.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 19:04:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: ISO 3166-1 DIS ballot X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > Quite the contrary, the draft demonstrates a complete lack > of understanding of what was wrong with RfC 3066. The draft > indirectly says "tags ougt to be stable, and if ISO 3166-1 > isn't then ISO 3166-1 is wrong". But the opposite is true, > ISO 3166-1 was never stable, will never be stable, is not > meant to be stable, and attempts to abuse it as source for > stable codes are doomed. See CS, GE, SK, etc. No matter how right or wrong the decision may have been to use ISO 3166-1 codes in language tags, that decision was made ten years ago, and it is a primary goal of this project for existing tags to be compatible with the new mechanism. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 00:44:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSpHB-0006Jo-DZ; Tue, 03 May 2005 00:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSpH8-0006Gu-Up for ltru@megatron.ietf.org; Tue, 03 May 2005 00:44:51 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03722 for ; Tue, 3 May 2005 00:44:47 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503044419.YGZ8952.mta9.adelphia.net@DEWELL> for ; Tue, 3 May 2005 00:44:19 -0400 Message-ID: <005101c54f9a$c07cf620$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050502095630.VLJZ17200.mta1.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 21:44:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: regionalisation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > We obviously have a problem of stability. I tend to think E.164 is by > nature more stable than ISO 3166 and it is all numeric. Main area > codes stability is actually to consider: a part from adjustments like > in the US due to the scarcity of number in some zones, or the > reorganisation of the French system adding a regional layer, I tend to > think it is more stable than ISO-3166-2 which keeps fixed location, > while area code and exchanges tend to follow the population (what > interests us in term of language). Sorry, I have to go a little OT here. Apologies in advance. About fourteen years ago, our customer base outside North America began growing rapidly, and we had to adopt a country coding scheme. I didn't know anything about ISO 3166, but I knew E.164 calling codes, and chose that as the basis for our system. We already stored customer telephone numbers, so the country code seemed to fit right in. Of course, there was that nasty problem with the U.S. and Canada having the same code (1). I got around that by adopting the convention Microsoft had used in MS-DOS (remember COUNTRY.SYS?), assigning 2 to Canada. I wonder how well it would go over in this WG to adopt a Microsoft-specific kludge like that. Then there were all the Caribbean island nations that were (and are) also part of the NANP, and also used 1 as their dialing code. Microsoft didn't have a kludge for them, and yes, we did end up having customers in Bermuda and the Dominican Republic. I invented a "clever" scheme for these that incorporated *part* of each country's area code. (Later it turned out that another company, which had chosen a similar E.164-based coding scheme, randomly assigned 101, 102, 103... to these countries.) Of course, the same problem (one code for multiple countries) also existed for a while in the former Soviet Union. Eventually, one by one, most of the CIS countries broke away from 7 and were assigned their own dialing code, although to this day Kazakhstan still shares 7 with Russia. Meanwhile, Czechoslovakia (42) split up into the Czech Republic (420) and Slovakia (421), ending hopes for code stability in that area. Our coding system, which needed the stability, broke ranks with the external standard and retained 42 for the Czech Republic. Sound familiar? The bottom line is that both systems have areas of stability and areas of instability, and neither shows a clear advantage in that respect. The ITU codes indeed are all numeric, as Jefsey said, but I'm not so sure that's a good thing; they have almost no mnemonic value except to people who often make international calls to those countries. Many people who have worked with our coding scheme had no other knowledge of E.164 and thought I invented the whole thing (another "czar" syndrome). To be perfectly honest, the more I think about the telephone-code-based system I did devise, the more I wish I had known about ISO 3166 and used that instead. Area codes are another matter. Jefsey touched briefly on the issue of splits and overlays and area code reforms, but it is a serious stability-breaker. Here in Southern California, I live within 100 km of about 11 different area codes. Fifteen years ago there were fewer than half. And as far as comparisons with ISO 3166-2 are concerned, the two systems have the same faults: very fine granularity for some countries and very coarse for others; good stability for some and terrible stability for others. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ (also a subscriber to TELNUM-L) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 01:08:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSpeQ-0007r8-US; Tue, 03 May 2005 01:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSpeP-0007qr-Jh for ltru@megatron.ietf.org; Tue, 03 May 2005 01:08:53 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05980 for ; Tue, 3 May 2005 01:08:52 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503050821.TKJR4191.mta13.adelphia.net@DEWELL> for ; Tue, 3 May 2005 01:08:21 -0400 Message-ID: <005a01c54f9e$17d6b020$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050502161131.CIEE27459.mta2.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 22:08:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last registry for now X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > What I need (and this is the problem of the whole IANA), is a copy of > the software generator and a reference to your sources. To be able to > run it. To verify that I reach the same file as yours in making a > diff. There is no software generator, as I told Frank. I didn't retype things, but most of the data was copied and pasted and sorted and otherwise manually massaged with text editors and tools like Excel. Building a custom generator would have been too much work, what with the various source formats. > To do that, we need the stable, clear, scalable description (requested > by the Charter) about the way the Internet addresses the ISO and non- > ISO tables variations. This should lead to one or several documented > codes (practice and codes are the basis for IESG approvals) generating > the same registry information from the same sources. I did start to write up a description of the process used to build the initial registry. You can read the first installment at http://users.adelphia.net/~dewell/init-registry.html, or in your LTRU archives. Just as I was starting work on the other parts, the group invented Suppress-Script (the source data for which is already generating controversy), and along the way the Deprecated date field was also added. I decided to wait until things settled down before finishing the process description. > For that your sources must be quoted in your file header (also to > acknowledge the true authors). It's easy to see that there is more to this process than copying a single list from each ISO and UN site. There are change-notice pages and such. > Please provide the trusted URL of the source files you used and the > source code or the code logic you followed. We inspect them, build our > own code and generate a copy. We will check it with yours to verify > that we both/all are right and to understand and correct the possible > discrepancies. Otherwise we will run it by our own, and if there is a > discrepancy we start with another unnecessary dispute on sources and > concepts. The process for primary language subtags, and the relevant URLs, are in the page referenced above. For the ISO 3166, ISO 15924, and UN M.49 codes respectively, you can try: http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1-semic.txt http://www.unicode.org/iso15924/iso15924.txt.zip http://unstats.un.org/unsd/methods/m49/m49alpha.htm http://unstats.un.org/unsd/methods/m49/m49chang.htm but as I said, there is much more to it than this. If you copy the lists blindly, you are *guaranteed* to have discrepancies. I will eventually finish the process description, but once again, the contents of the registry should not distract the group from making progress on the draft itself. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 01:35:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSq4N-00044W-9q; Tue, 03 May 2005 01:35:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSq4K-000441-9H for ltru@megatron.ietf.org; Tue, 03 May 2005 01:35:41 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08363 for ; Tue, 3 May 2005 01:35:38 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503053508.TXMP4191.mta13.adelphia.net@DEWELL> for ; Tue, 3 May 2005 01:35:08 -0400 Message-ID: <00b901c54fa1$d46142c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050502161131.CIEE27459.mta2.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 22:34:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last registry for now X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> the continual updating of the sample registry has become a >> distraction from the overall process of evaluating the draft > > Without your draft registry I wouldn't understand one word in > the registry draft (excl. its ABNF), the draft registry is no > distraction, quite the contrary, it's the essence. I didn't say the registry was a distraction. I said that continually updating the content of the registry, adding this country and changing the punctuation in the name of that script, was a distraction. >> decisions to exclude (or include) certain "useless" or >> "stupid" subtags, usually region subtags. > > Whether it's "stupid" or "useless" is beside the point, but we > cannot get rid of it as soon as it's in. Sorry, my mistake. I thought I was quoting you, but you never used those words to describe the subtags you don't like. The word I was thinking of was "dubious." > Playing with your draft registry allows me to test such ideas, > and maybe the registry draft should say that generic variants > are a bad idea. If that's the case, I'm not at all sure. But you can play with the draft registry, see how things work, without having its content constantly updated. That's what is creating all the list traffic and drawing attention away from the draft. >> I make only those changes that seem to have consensus within >> the group or seem uncontroversial. > > Yes, and if some results are strange it's not your fault, but > a problem in the registry draft or in the source standards. Then let's talk about them directly, not in terms of tweaking the registry to make the draft come out right. >> the time when group members should focus on fine-tuning the >> registry, not now. > > IBTD. Trying to do something with your draft registry is the > best way to find problems in the registry draft. Four of my > five "last points" are a direct consequence of simply trying > to parse lstreg.txt 2005-04-30. These five "last points" are > certainly not about the two obscure region codes 003 and 200. The question of how to populate the Suppress-Script fields is something I warned about, and predicted would be a problem. Everyone wanted to talk about English (one well-known, stable script) and Serbian (two well-known, stable scripts), and now we don't know what to do about hundreds of other languages. There simply is no universally accepted source for this data. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 01:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqK4-0007IC-4R; Tue, 03 May 2005 01:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqK2-0007I3-4E for ltru@megatron.ietf.org; Tue, 03 May 2005 01:51:54 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09752 for ; Tue, 3 May 2005 01:51:52 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503055122.LDCF17140.mta10.adelphia.net@DEWELL> for ; Tue, 3 May 2005 01:51:22 -0400 Message-ID: <00c201c54fa4$18d3ed20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050502192559.TBEY28811.mta8.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 22:51:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last registry for now X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Marion Gunn wrote: >> 2. Underscores in field names are replaced by hyphens. For example, >> "File_Date" is changed to "File-Date"... > > Was there some irresistible reason for that last-minute framework > change, Doug? Yes. It was in the draft, and we had talked about it on the list. As I said, I don't make these changes based on personal whim. > I ask because underscores are linguistically neutral, hyphens not so, > and you just wouldn't want to know what that change would do to some > languages (if ever your registry were to be localized for use on > non-English servers). Addison is 100% correct: the field names should not be translated, regardless of the location of the server. This is a fundamental database concept. Table and column names are to be used internally by the database, not displayed in user interfaces. Having said that, I would add that if you *were* to take the ill-advised step of translating the field names, you would obviously be under no obligation to use hyphens in the translated names. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 01:55:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqNL-00019B-P6; Tue, 03 May 2005 01:55:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqNJ-00017k-MC for ltru@megatron.ietf.org; Tue, 03 May 2005 01:55:17 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10029 for ; Tue, 3 May 2005 01:55:16 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503055446.LFBT17140.mta10.adelphia.net@DEWELL> for ; Tue, 3 May 2005 01:54:46 -0400 Message-ID: <00c701c54fa4$8e5b34e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050502192559.TBEY28811.mta8.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 22:54:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 3 - Simplified registry ABNF (was: Open points before -02) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > 2. It is useful to actually describe record-jar formally. Perhaps an > I-D should be created that does just that so that no one else need > replicate this experience. I think this is a terrific idea. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 02:00:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqSY-0004iH-0G; Tue, 03 May 2005 02:00:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqSW-0004i4-6G for ltru@megatron.ietf.org; Tue, 03 May 2005 02:00:40 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11042 for ; Tue, 3 May 2005 02:00:38 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503060008.LHRO17140.mta10.adelphia.net@DEWELL> for ; Tue, 3 May 2005 02:00:08 -0400 Message-ID: <00d901c54fa5$52a880a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050503055225.BHRT27459.mta2.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 22:59:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 3 - Simplified registry ABNF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> It makes the registry itself somewhat uglier (whitespace use >> is somewhat more constrained). > > It's just the format created by Doug, I don't see where that's > ugly. No, you've got that backwards again. I didn't create the format. We talked about it publicly on the list, and I copied what I saw in the draft. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 02:06:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqYO-00012F-KD; Tue, 03 May 2005 02:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqYN-0000xP-23 for ltru@megatron.ietf.org; Tue, 03 May 2005 02:06:43 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17347 for ; Tue, 3 May 2005 02:06:41 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503060611.LLQG17140.mta10.adelphia.net@DEWELL> for ; Tue, 3 May 2005 02:06:11 -0400 Message-ID: <00de01c54fa6$29bf5e60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050503055225.BHRT27459.mta2.adelphia.net@megatron.ietf.org> Date: Mon, 2 May 2005 23:05:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 5 - Appendix D: Redundant Tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> One reason we haven't done this is that there are still tags >> getting registered (up to Date B, right?) > > Doug apparently wants a date B _after_ date Y, where Y is the > day whe the IESG moving the registry draft to the queue of > the RfC editor. After date Y the old registry is closed. Did I say that? Section 3.7 says that when the draft is published (Date B), the chairs will notify the LTRU and ietf-languages lists about the proposed registry. There is a 4-week Last Call period, after which the registry is sent to IANA and posted (Date Y). If I ever said anything to the contrary, I didn't mean it. http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html#ianaconversion -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 02:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSqlB-0000J1-OS; Tue, 03 May 2005 02:19:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSql9-0000IZ-A0 for ltru@megatron.ietf.org; Tue, 03 May 2005 02:19:55 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00274 for ; Tue, 3 May 2005 02:19:53 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSqeo-0006Qm-90 for ltru@lists.ietf.org; Tue, 03 May 2005 08:13:22 +0200 Received: from c-134-92-43.hh.dial.de.ignite.net ([62.134.92.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 May 2005 08:13:22 +0200 Received: from nobody by c-134-92-43.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 May 2005 08:13:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 03 May 2005 08:16:04 +0200 Organization: Lines: 38 Message-ID: <42771724.6C73@xyzzy.claranet.de> References: <20050502095630.VLJZ17200.mta1.adelphia.net@megatron.ietf.org> <005101c54f9a$c07cf620$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-92-43.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: regionalisation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I got around that by adopting the convention Microsoft had > used in MS-DOS (remember COUNTRY.SYS?), assigning 2 to > Canada. Sure, PC DOS used the same kludge, OS/2 too, in my CONFIG.SYS: CODEPAGE=850,1004 COUNTRY=049,c:\COUNTRY.SYS When I once asked "somebody" (now a WG member ;-) about this bad case of "1004" (which is actually 1252, and the "850" is actually 858) he reacted like I'm an alien. Very embarassing. > I wonder how well it would go over in this WG to adopt a > Microsoft-specific kludge like that. Very badly, probably they have patented it. And we know that it doesn't work as expected. Not much worse than ISO 3166-1. > Our coding system, which needed the stability, broke ranks > with the external standard and retained 42 for the Czech > Republic. Sound familiar? Yes. Moral, don't abuse external sources if you don't know how they are maintained. > the more I think about the telephone-code-based system I did > devise, the more I wish I had known about ISO 3166 and used > that instead. You'd have almost the same problems with 3166-1 alpha-2 codes, we have discussed each and every problem in the past 30 years with this approach. I hope that you're all very sure about these UN numbers. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 02:39:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSr43-0003Pg-1V; Tue, 03 May 2005 02:39:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSr41-0003Mw-Hp for ltru@megatron.ietf.org; Tue, 03 May 2005 02:39:25 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04464 for ; Tue, 3 May 2005 02:39:23 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSqxd-0000bp-2I for ltru@lists.ietf.org; Tue, 03 May 2005 08:32:49 +0200 Received: from c-134-92-43.hh.dial.de.ignite.net ([62.134.92.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 May 2005 08:32:49 +0200 Received: from nobody by c-134-92-43.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 May 2005 08:32:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 03 May 2005 08:38:03 +0200 Organization: Lines: 22 Message-ID: <42771C4B.1C47@xyzzy.claranet.de> References: <20050503055225.BHRT27459.mta2.adelphia.net@megatron.ietf.org> <00d901c54fa5$52a880a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-92-43.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 3 - Simplified registry ABNF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: >> just the format created by Doug, I don't see where that's >> ugly. > No, you've got that backwards again. I didn't create the > format. Of course _you_ have created lstreg.txt. There's absolutely nothing backwards with it. You didn't use a space before the colon (allowed by the draft), you used a space after the colon (not required by the draft), you used a certain natural order of fields per record and of records per type (both AFAIK not required by the draft), and that is all perfect as it is. If you feel better by pretending that somebody else did your work it's okay, but you won't get me to lie about it. And if I see something in your output that I like, but that's not yet _required_ by the draft, and only "allowed", then I'll say so. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 05:29:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DStiJ-0006cL-3M; Tue, 03 May 2005 05:29:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DStiG-0006cC-UH for ltru@megatron.ietf.org; Tue, 03 May 2005 05:29:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18224 for ; Tue, 3 May 2005 05:29:06 -0400 (EDT) Received: from mail12.svc.cra.dublin.eircom.net ([159.134.118.28]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DStw6-0002zw-S8 for ltru@ietf.org; Tue, 03 May 2005 05:43:28 -0400 Received: (qmail 81836 messnum 5763018 invoked from network[194.125.134.223/ts02-096.dublin.indigo.ie]); 3 May 2005 09:28:54 -0000 Received: from ts02-096.dublin.indigo.ie (HELO egt.ie) (194.125.134.223) by mail12.svc.cra.dublin.eircom.net (qp 81836) with SMTP; 3 May 2005 09:28:54 -0000 Message-ID: <427743DA.273E67FE@egt.ie> Date: Tue, 03 May 2005 10:26:50 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: regionalisation References: <20050502095630.VLJZ17200.mta1.adelphia.net@megatron.ietf.org> <005101c54f9a$c07cf620$030aa8c0@DEWELL> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA18224 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Scr=EDobh Doug Ewell: > ... > To be perfectly honest, the more I think about the telephone-code-based > system I did devise, the more I wish I had known about ISO 3166 and use= d > that instead... It was a good decision at the time, Doug, especially since the mystique surrounding Standards and their construction/application is hardly less now than then (at least from the point of view of the busy practitioner, as distinct from their sometimes inexperienced compilers).=20 And again, to be perfectly honest, don't most of us still think instantly of the telephone code for the countries we most visit/contact? I know, I still do. Best, mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 05:33:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DStma-00081x-9r; Tue, 03 May 2005 05:33:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DStmZ-00081H-Es for ltru@megatron.ietf.org; Tue, 03 May 2005 05:33:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19213 for ; Tue, 3 May 2005 05:33:33 -0400 (EDT) Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSu0O-00036Z-H0 for ltru@ietf.org; Tue, 03 May 2005 05:47:53 -0400 Received: (qmail 38044 messnum 11066800 invoked from network[194.125.134.223/ts02-096.dublin.indigo.ie]); 3 May 2005 09:33:22 -0000 Received: from ts02-096.dublin.indigo.ie (HELO egt.ie) (194.125.134.223) by mail11.svc.cra.dublin.eircom.net (qp 38044) with SMTP; 3 May 2005 09:33:22 -0000 Message-ID: <427744E6.AA5C9867@egt.ie> Date: Tue, 03 May 2005 10:31:18 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: Last registry for now References: <20050502192559.TBEY28811.mta8.adelphia.net@megatron.ietf.org> <00c201c54fa4$18d3ed20$030aa8c0@DEWELL> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA19213 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Scr=EDobh Doug Ewell: > ... > Having said that, I would add that if you *were* to take the ill-advise= d > step of translating the field names, you would obviously be under no > obligation to use hyphens in the translated names. Not looking for extra work, having translated enough 'concatenated' (yikes!) strings this year alone to last for a long time to come. If I can quote you as to 'ill-advised' (above), that just lets me off on more = hook.:-) Best, mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 05:37:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DStqb-00021L-5c; Tue, 03 May 2005 05:37:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DStqa-0001zk-HW for ltru@megatron.ietf.org; Tue, 03 May 2005 05:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22013 for ; Tue, 3 May 2005 05:37:41 -0400 (EDT) Received: from mail04.svc.cra.dublin.eircom.net ([159.134.118.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSu4N-0003JO-Re for ltru@ietf.org; Tue, 03 May 2005 05:52:02 -0400 Received: (qmail 29434 messnum 5268896 invoked from network[194.125.134.223/ts02-096.dublin.indigo.ie]); 3 May 2005 09:37:29 -0000 Received: from ts02-096.dublin.indigo.ie (HELO egt.ie) (194.125.134.223) by mail04.svc.cra.dublin.eircom.net (qp 29434) with SMTP; 3 May 2005 09:37:29 -0000 Message-ID: <427745DC.FE35D203@egt.ie> Date: Tue, 03 May 2005 10:35:25 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: 3 - Simplified registry ABNF References: <20050503055225.BHRT27459.mta2.adelphia.net@megatron.ietf.org> <00d901c54fa5$52a880a0$030aa8c0@DEWELL> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA22013 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Please don't blame Frank. There were so many 100s of msgs coming in so fast I certainly could not have given my attention to even half of them, and he is probably working hard (gainfully employed!) on other things, like most of us. As my father would put it, if you need good advice go ask a busy man but don't go bombarding him or you'll forfeit his attn.:-) mg Scr=EDobh Doug Ewell: >=20 > Frank Ellermann wrote: >=20 > >> It makes the registry itself somewhat uglier (whitespace use > >> is somewhat more constrained). > > > > It's just the format created by Doug, I don't see where that's > > ugly. >=20 > No, you've got that backwards again. I didn't create the format. We > talked about it publicly on the list, and I copied what I saw in the > draft. --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 10:44:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSycy-0003DC-72; Tue, 03 May 2005 10:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSycx-0003D7-Ob for ltru@megatron.ietf.org; Tue, 03 May 2005 10:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25311 for ; Tue, 3 May 2005 10:43:57 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSyqq-0002kS-P6 for ltru@ietf.org; Tue, 03 May 2005 10:58:22 -0400 Received: from lns-p19-4-idf-82-65-255-81.adsl.proxad.net ([82.65.255.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DSycl-0002V3-U9; Tue, 03 May 2005 07:43:48 -0700 Message-Id: <6.2.1.2.2.20050503103307.03e0d880@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 03 May 2005 10:39:32 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Last registry for now In-Reply-To: <00c201c54fa4$18d3ed20$030aa8c0@DEWELL> References: <20050502192559.TBEY28811.mta8.adelphia.net@megatron.ietf.org> <00c201c54fa4$18d3ed20$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 07:51 03/05/2005, Doug Ewell wrote: >Addison is 100% correct: the field names should not be translated, >regardless of the location of the server. This is a fundamental >database concept. Table and column names are to be used internally by >the database, not displayed in user interfaces. grrr.... not translated: transcripted or whatever funny term you may use to mean using different scripts. When will you understand that multilingualism means different keyboards first. If you swear me that you are using an Arabic or a Chinese keyboard to contribute to this list and publish your registry file, I will drop this issue. Sorry, but this mental permanent exclusion of 60% of the mankind starts harassing me. There is only one globally acceptable script, it is '0-9'. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 10:44:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSyd5-0003EN-CY; Tue, 03 May 2005 10:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSyd3-0003EF-Pk for ltru@megatron.ietf.org; Tue, 03 May 2005 10:44:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25347 for ; Tue, 3 May 2005 10:44:03 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSyqx-0002lt-Pj for ltru@ietf.org; Tue, 03 May 2005 10:58:28 -0400 Received: from lns-p19-4-idf-82-65-255-81.adsl.proxad.net ([82.65.255.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DSyd1-0002V3-73; Tue, 03 May 2005 07:44:04 -0700 Message-Id: <6.2.1.2.2.20050503104302.03de5eb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 03 May 2005 11:51:10 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: regionalisation In-Reply-To: <005101c54f9a$c07cf620$030aa8c0@DEWELL> References: <20050502095630.VLJZ17200.mta1.adelphia.net@megatron.ietf.org> <005101c54f9a$c07cf620$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The problem is what you want to document. If people have different systems it is because they have different needs. Basically you have two systems: geography and people. And a compromise which is countries as one think that same people assemble themselves on a territory. However even in periods of stability these two basis and their compromise tend to change. There are therefore two problems: stability and proper granularity for the currently discussed issue. 1. stability when proceeding from instable tables is a common problem which is usually addressed in a simple manner: in associating the reference dates of changes. 110/1998 (21-21219)-2002(21-65439) meaning 110 was created in 1998 with meaning 21-21219 and changed meaning to 21-65439) in 2002. Everyone and languages having the possibility to document 21-21219 and 21-65439 in the way they want. To do that there is a need for an accepted universal tag numbering scheme. If IETF does not provide it, we will and support the handle system for its documentation. No big deal. This is a simple system to maintain (it forgets nothing, it just keeps adding date and meanings at incremented addresses; and rebuild what everyone can do and compare) and to read (a few extra bytes in querry telling the considered year). 2. The telephone numbering system is the oldest numbering system routing into Telex and ISO 3166 alpha-2 is the telex code. ITU and ISO tend to consider it quite stabilized in its principle. Its advantage is that it covers everyone down to every individual. It is necessarily related to populations evolution (subscribers) who tend to have a very good knowledge of it. In this it is better than post codes (which also are good candidates except the Bristish alphanumeric system and the geography oriented US system [you have many post codes with no population]). E.164 interest is also that it serves populations wich cannot use the Internet without it, and will therefore adapt to their changes. The problems you rise come from an equivalent ignorance of E.164 and of ISO 3166 and probably of X.121 at that time, and from a non-network point of view. You want to cover languages issues, while we here are to cover network and people issues. People do not think for the world in ASCII as you do, they think for themselves in their own language, with their own needs, and their own numbers they know (usually telephone number and post-code, plus whatever universal number anyone could give them they would really use - experience and studies show that people can collectively remember at least 3 figures, average 5, never more than seven - same for names). This WG has a charter and belongs to the IETF, not to UNICODE nor to W3C. It has to propose Internet standard process solutions which can scale to the whole Internet standard process. Regionalisation is a general need. It must be addressed along with the charter guidelines and with scalability, simplicity and network relevance in mind. Our Charter is here to protect consistency with the other Internet documents. We therefore need first to get a very good command of it, of its requirements and of its possible lacks we would discover and we would have to report: IESG is not God the Father, but we collectively are. Applying for the 11th or 12th time some paint on the W3C rust will neither provide a goo framework for the W3C, will neither make a Last Call and even if the IESG accepted it out of boredom would never make the market call. Our problem is the network consistency with digital and human protocols (languages). This problem is not simple. Infrastructure is fixed and related to geography, market is related to providers and users are mobiles and related to registries, while numbering is in a way related to States which may change. Internet up to now has two responses: RFC 1591 and current ISO 3166 (inherited from Telex and Radio). We face a complex additional issue as languages develop separately with some adherence to geography, policy, market, etc. and have to organise this into an ASCII prototype structure lacking the basic network architectural tools for that. The first work is to establish a chronological correspondance table between all these systems. This is needed in different areas. - universal telephone directory (which is to be multilingual) - same about whois and their convergence - some digital protocol with human protocols implications - multilingual internet or multilingual NGN or whatever avatar IETF/ITU and others may come with - CRC and contexts - applications (operating systems: locales, DNS: mlnames, network control/statistics, mails, web, opes/ones, etc.) This is precisely why ICANN has been admitted in the ISO 3166 committee to represent us. The problem is not with not appropriate standards, the problem is with the fact we do not participate to these standards, but shout at them. Or we should ask ICANN to give its seat to IETF. Or IANA at least to designate a person in charge. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 11:01:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSyuK-0008Qq-CT; Tue, 03 May 2005 11:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSyuJ-0008QL-8s for ltru@megatron.ietf.org; Tue, 03 May 2005 11:01:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27041 for ; Tue, 3 May 2005 11:01:53 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSz8B-0003Dx-Hw for ltru@ietf.org; Tue, 03 May 2005 11:16:17 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j43F1XaI010865; Tue, 3 May 2005 11:01:34 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 3 May 2005 11:01:36 -0400 Date: Tue, 3 May 2005 11:01:35 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Last registry for now Message-ID: <20050503150135.GC27778@skunk.reutershealth.com> References: <20050502192559.TBEY28811.mta8.adelphia.net@megatron.ietf.org> <00c201c54fa4$18d3ed20$030aa8c0@DEWELL> <6.2.1.2.2.20050503103307.03e0d880@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050503103307.03e0d880@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin scripsit: > not translated: transcripted or whatever funny term you may use to mean > using different scripts. When will you understand that multilingualism > means different keyboards first. If you swear me that you are using an > Arabic or a Chinese keyboard to contribute to this list and publish your > registry file, I will drop this issue. It's irrelevant. It may be (just barely) possible to make productive use of a general-purpose computer while never typing a Latin letter. It is not now or in the foreseeable future possible to *program* one without doing so. Nor is there any reason to think that there will ever be a general-purpose computer with no Latin-script capability. > Sorry, but this mental permanent exclusion of 60% of the mankind starts > harassing me. > There is only one globally acceptable script, it is '0-9'. In fact no. There are currently in Unicode 20 other sets of digits used with various scripts, mostly Indic and South-east Asian ones. -- At the end of the Metatarsal Age, the dinosaurs John Cowan abruptly vanished. The theory that a single jcowan@reutershealth.com catastrophic event may have been responsible www.reutershealth.com has been strengthened by the recent discovery of www.ccil.org/~cowan a worldwide layer of whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 11:26:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSzIE-0001ww-HK; Tue, 03 May 2005 11:26:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSzIC-0001wr-Ki for ltru@megatron.ietf.org; Tue, 03 May 2005 11:26:36 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00258 for ; Tue, 3 May 2005 11:26:33 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503152603.DWKQ17140.mta10.adelphia.net@DEWELL> for ; Tue, 3 May 2005 11:26:03 -0400 Message-ID: <00fc01c54ff4$493742a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050503144512.NPUU17200.mta1.adelphia.net@megatron.ietf.org> Date: Tue, 3 May 2005 08:25:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 3 - Simplified registry ABNF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> No, you've got that backwards again. I didn't create the >> format. > > Of course _you_ have created lstreg.txt. There's absolutely > nothing backwards with it. You didn't use a space before the > colon (allowed by the draft), you used a space after the colon > (not required by the draft), you used a certain natural order > of fields per record and of records per type (both AFAIK not > required by the draft), and that is all perfect as it is. I apologize for the tone of my response. Let me put it this way: I didn't dictate that there would be a space here and would not be a space there, when the syntax allows a space but doesn't require it. I hope the syntax of lstreg.txt is correct according to the ABNF; if it isn't, I hope someone will let me know. Beyond that, any discretionary stylistic choices I made were solely based on what I saw in the draft. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 11:36:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSzRW-0004mk-9M; Tue, 03 May 2005 11:36:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSzRV-0004mf-2c for ltru@megatron.ietf.org; Tue, 03 May 2005 11:36:13 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01128 for ; Tue, 3 May 2005 11:36:10 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050503153541.LPIJ4191.mta13.adelphia.net@DEWELL> for ; Tue, 3 May 2005 11:35:41 -0400 Message-ID: <010301c54ff5$a517a820$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050503144512.NPUU17200.mta1.adelphia.net@megatron.ietf.org> Date: Tue, 3 May 2005 08:34:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last registry for now X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: >> Addison is 100% correct: the field names should not be translated, >> regardless of the location of the server. This is a fundamental >> database concept. Table and column names are to be used internally >> by the database, not displayed in user interfaces. > > grrr.... > not translated: transcripted or whatever funny term you may use to > mean using different scripts. Field names in databases should not be: * translated into different languages * transcribed (reversibly) into other scripts * transliterated (non-reversibly) into other languages' writing systems They are fixed. It is the content, the field *values*, that changes in different localized versions. > When will you understand that multilingualism means different > keyboards first. End users don't have to type the field names. Programmers, who do, have access to a Latin-script keyboard. If you can show me a programming language or environment that does not require at least some use of the Latin script, I will re-think my position. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 12:22:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT09u-00058W-6r; Tue, 03 May 2005 12:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT09s-00058O-BX for ltru@megatron.ietf.org; Tue, 03 May 2005 12:22:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06067 for ; Tue, 3 May 2005 12:22:01 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT0Nm-0005eF-D0 for ltru@ietf.org; Tue, 03 May 2005 12:36:27 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j43GLr3c011337 for ; Tue, 3 May 2005 12:21:53 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 3 May 2005 12:21:56 -0400 Date: Tue, 3 May 2005 12:21:56 -0400 From: John Cowan To: ltru@ietf.org Subject: [Ltru] Re: Last registry for now Message-ID: <20050503162156.GI19734@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug has asked me to note that the words "transcribed" and "transliterated" in his last post were interchanged. The text should read: Field names in databases should not be: * translated into different languages * transliterated (reversibly) into other scripts * transcribed (non-reversibly) into other languages' writing systems -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 12:35:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT0N9-0000Zq-Lh; Tue, 03 May 2005 12:35:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT0N8-0000Zl-Tv for ltru@megatron.ietf.org; Tue, 03 May 2005 12:35:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07241 for ; Tue, 3 May 2005 12:35:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT0b3-0005yy-3P for ltru@ietf.org; Tue, 03 May 2005 12:50:10 -0400 Received: from lns-p19-4-idf-82-65-255-81.adsl.proxad.net ([82.65.255.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DT0Mr-000868-BO; Tue, 03 May 2005 09:35:29 -0700 Message-Id: <6.2.1.2.2.20050503181628.04e73b10@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 03 May 2005 18:35:13 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Last registry for now In-Reply-To: <010301c54ff5$a517a820$030aa8c0@DEWELL> References: <20050503144512.NPUU17200.mta1.adelphia.net@megatron.ietf.org> <010301c54ff5$a517a820$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 17:34 03/05/2005, Doug Ewell wrote: > > When will you understand that multilingualism means different > > keyboards first. > >End users don't have to type the field names. Programmers, who do, have >access to a Latin-script keyboard. If you can show me a programming >language or environment that does not require at least some use of the >Latin script, I will re-think my position. Dear Doug. This is shocking under the pen of a global standadizer. I will not comment on the contempt for "end-users", non for the exclusion of non-Latin script programmers. Nor on its political and societal consequences. No on the fact this may be properly in violation of national laws. I will certainly change my position if you can show me a programming language or environment which cannot be translated so it do requires at least some use of the Latin script, I will re-think my position. And please do not quote John's meaningless remark on Unicode coding of "0-9" numbers (did he heard about EBCDIC of too young for that?). ASCII centrism was an old odd Internet feature, I am afraid you are beginning to make it a boring bug. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 13:15:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT103-0007Tu-J7; Tue, 03 May 2005 13:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT101-0007Tp-Bh for ltru@megatron.ietf.org; Tue, 03 May 2005 13:15:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11603 for ; Tue, 3 May 2005 13:15:54 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT1Dv-0007FG-Rf for ltru@ietf.org; Tue, 03 May 2005 13:30:21 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j43HFjgS011544; Tue, 3 May 2005 13:15:45 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 3 May 2005 13:15:49 -0400 Date: Tue, 3 May 2005 13:15:49 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Last registry for now Message-ID: <20050503171548.GJ19734@skunk.reutershealth.com> References: <20050503144512.NPUU17200.mta1.adelphia.net@megatron.ietf.org> <010301c54ff5$a517a820$030aa8c0@DEWELL> <6.2.1.2.2.20050503181628.04e73b10@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050503181628.04e73b10@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin scripsit: > I will not comment > on the contempt for "end-users", There is no contempt here, but a plain statement of fact. > non for the exclusion of non-Latin script > programmers. The needs of "non-Latin script programmers" have about as much weight as the needs of Klingons, and for the same reason. > Nor on its political and societal consequences. No on the fact > this may be properly in violation of national laws. Cite one such law, please. > I will certainly change my position if you can show me a programming > language or environment which cannot be translated so it do requires at > least some use of the Latin script, I will re-think my position. Programming languages *can* be transliterated or transcribed, but no one does that, for sufficient reasons. > And please > do not quote John's meaningless remark on Unicode coding of "0-9" numbers The coding is not the point. Let me put it this way: there are at least 20 writing systems around the world where numbers are not written using "0-9", so they are no more "global" than the Latin alphabet. Your argument proves too much. > (did he heard about EBCDIC of too young for that?). I am quite familiar with it. The repertoire of EBCDIC encodings is still a subset of Unicode, though the encodings are not. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan If a soldier is asked why he kills people who have done him no harm, or a terrorist why he kills innocent people with his bombs, they can always reply that war has been declared, and there are no innocent people in an enemy country in wartime. The answer is psychotic, but it is the answer that humanity has given to every act of aggression in history. --Northrop Frye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 13:59:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1fp-00038X-4V; Tue, 03 May 2005 13:59:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1fn-00038S-0o for ltru@megatron.ietf.org; Tue, 03 May 2005 13:59:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15737 for ; Tue, 3 May 2005 13:59:05 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT1th-0008Pm-Rb for ltru@ietf.org; Tue, 03 May 2005 14:13:31 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 May 2005 10:58:55 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 May 2005 10:58:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Last registry for now Date: Tue, 3 May 2005 10:58:54 -0700 Message-ID: Thread-Topic: [Ltru] Re: Last registry for now Thread-Index: AcVP/pUKssLKYGmzS02D8vSmz/09tAACMb5g From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 03 May 2005 17:58:55.0668 (UTC) FILETIME=[C5FF0740:01C55009] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of JFC > (Jefsey) Morfin > This is shocking under the pen of a global standadizer. I will not comment > on the contempt for "end-users", non for the exclusion of non-Latin script > programmers. Do you make as much fuss about (say) the fact that HTTP headers use Latin characters and that one can't substitute Arabic or other scripts? We're talking about documentation of protocol elements. When end users are involved, I think everyone here would strongly support the need for "multilingualization", but his is not an end-user issue. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 21:38:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT8px-0007Fc-Of; Tue, 03 May 2005 21:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT8pw-0007FX-Pm for ltru@megatron.ietf.org; Tue, 03 May 2005 21:38:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00936 for ; Tue, 3 May 2005 21:38:02 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT93u-0005hq-Fa for ltru@ietf.org; Tue, 03 May 2005 21:52:32 -0400 Received: from lns-p19-8-idf-82-65-78-79.adsl.proxad.net ([82.65.78.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DT8ps-0008SA-Go; Tue, 03 May 2005 18:38:01 -0700 Message-Id: <6.2.1.2.2.20050504021323.0311e500@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 04 May 2005 03:37:55 +0200 To: "Peter Constable" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Last registry for now In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 1.3 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 19:58 03/05/2005, Peter Constable wrote: > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On Behalf Of JFC > > (Jefsey) Morfin > > This is shocking under the pen of a global standadizer. I will not > > comment on the contempt for "end-users", non for the exclusion > > of non-Latin script programmers. > >Do you make as much fuss about (say) the fact that HTTP headers use >Latin characters and that one can't substitute Arabic or other scripts? > >We're talking about documentation of protocol elements. When end users >are involved, I think everyone here would strongly support the need for >"multilingualization", but his is not an end-user issue. Dear Peter, This kind of question is always embarassing, because it shows how much the author do not understand what he discusses. I know this is not on purpose. I will address it to show IESG, and possibly IAB, in appeal that I tried every time I could to explain how much this WG is out of its track. This is not an accademic meeting over three ISO standard's conflicting oddities. This is not a W3C forum trying to patch an XML misconception. This is not a few followers helping with the wording of a twice last-calls denied concept. This is an IETF WG having to study, check and document an Internet and Internet application wide response to the need of identifying and tagging the languages. For and according to the Internet standard process to generate standards, documents, procedures, protocols, best practices. For the Internet to become legally acceptable as a global system. To do that this WG should have attracted enough authoritative experts (or declare itself uncompetent) to study and complet from their own experience, developments and plans, the points in the Charter. I am sure that in this process you would have realized that HTTP is an Internet protocol in the area of this WG as are every Internet protocol. So you would understand that I am making no special, but general, fuss. Your contribution to the WG would have been still more valuable, because you would have learned from seasoned experts that the very basis of a network architecture is consistency and coherence. A coherence with the human protocols (languages) it supports the ASCII Internet has not. A big problem our job is precisely to start addressing. For the rest, I am not in a position to comment: please document (RFC?) what is an "end user" for an IETF WG. I obviously understand what it may mean for an host application designer (like W3C?) but here it does not make any sense to me. all the best. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 03 22:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT9hn-0001u1-4P; Tue, 03 May 2005 22:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT9hc-0001lj-Gr for ltru@megatron.ietf.org; Tue, 03 May 2005 22:33:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05310 for ; Tue, 3 May 2005 22:33:29 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DT9bH-0005Xv-84 for ltru@lists.ietf.org; Wed, 04 May 2005 04:26:59 +0200 Received: from du-001-185.access.de.clara.net ([212.82.227.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 May 2005 04:26:59 +0200 Received: from nobody by du-001-185.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 May 2005 04:26:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 04 May 2005 04:26:25 +0200 Organization: Lines: 14 Message-ID: <427832D0.1A91@xyzzy.claranet.de> References: <6.2.1.2.2.20050504021323.0311e500@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-185.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last registry for now X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > this WG should have attracted enough authoritative experts > (or declare itself uncompetent) It's really sad that this WG only attracted Martin, Mark, and Addison, who know nothing about I18N, isn't it ? And now go and find a forum where you can explain the Web to Sir Tim... > HTTP is an Internet protocol ...yes, he will be very excited about this great news. Good luck with your future endeavours. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 00:33:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTBZT-0003Um-99; Wed, 04 May 2005 00:33:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTBZR-0003Uc-1C for ltru@megatron.ietf.org; Wed, 04 May 2005 00:33:13 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13585 for ; Wed, 4 May 2005 00:33:09 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050504043237.BCXA8952.mta9.adelphia.net@DEWELL> for ; Wed, 4 May 2005 00:32:37 -0400 Message-ID: <013c01c55062$060c1780$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050503144512.NPUU17200.mta1.adelphia.net@megatron.ietf.org> Date: Tue, 3 May 2005 21:30:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: regionalisation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > 2. The telephone numbering system is the oldest numbering system > routing into Telex and ISO 3166 alpha-2 is the telex code. I know this has been said before, but ISO 3166 alpha-2 is much more than just the telex code by now. It has been adopted in numerous contexts, including (of course) TLDs. If a previous solution has worked, choose it again, right? > ITU and ISO tend to consider it quite stabilized in its principle. Its > advantage is that it covers everyone down to every individual. It is > necessarily related to populations evolution (subscribers) who tend to > have a very good knowledge of it. In this it is better than post codes > (which also are good candidates except the Bristish alphanumeric > system and the geography oriented US system [you have many post codes > with no population]). You must be talking about ZIP codes (our term for postal codes) assigned to post office boxes, military bases, and major companies. Those certainly do serve a "population" of sorts. I can't think of any residential ZIP codes assigned to empty areas. Of the 100,000 possible five-digit ZIP codes, less than 43% are assigned. > The problems you rise come from an equivalent ignorance of E.164 and > of ISO 3166 and probably of X.121 at that time, and from a non-network > point of view. My need at the time was for indexing. A "network point of view" would have been completely irrelevant to that project. > People do not think for the world in ASCII as you do, I don't know what brought that on. Are you suggesting that language tags should be localized to other scripts? > they think for themselves in their own language, with their own needs, > and their own numbers they know (usually telephone number and post- > code, plus whatever universal number anyone could give them they would > really use - experience and studies show that people can collectively > remember at least 3 figures, average 5, never more than seven - same > for names). The studies you are thinking of show that people can only remember five to seven *random, meaningless* digits or names. I'm sure that both you and I can recall dozens of 10-digit telephone numbers and street addresses, and know perhaps hundreds of people by name. That doesn't mean we have superior memory skills; it means we have something to connect those numbers and names to. > This WG has a charter and belongs to the IETF, not to UNICODE nor to > W3C. Has anyone suggested otherwise? Where do you get this about Unicode? > The first work is to establish a chronological correspondance table > between all these systems. This is needed in different areas. > - universal telephone directory (which is to be multilingual) > - same about whois and their convergence > - some digital protocol with human protocols implications > - multilingual internet or multilingual NGN or whatever avatar IETF/ > ITU and others may come with > - CRC and contexts > - applications (operating systems: locales, DNS: mlnames, network > control/statistics, mails, web, opes/ones, etc.) This is nice. Over here, we are working on language tagging. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 00:36:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTBcV-0004p9-B5; Wed, 04 May 2005 00:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTBcR-0004o6-RH for ltru@megatron.ietf.org; Wed, 04 May 2005 00:36:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13828 for ; Wed, 4 May 2005 00:36:14 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTBqR-0001Fd-5v for ltru@ietf.org; Wed, 04 May 2005 00:50:47 -0400 Received: from h-68-165-5-39.snvacaid.dynamic.covad.net ([68.165.5.39] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DTBcN-0000T0-00; Tue, 03 May 2005 21:36:15 -0700 Message-ID: <004d01c55063$1dcbb140$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050504021323.0311e500@mail.jefsey.com> Subject: Re: [Ltru] Re: Last registry for now Date: Tue, 3 May 2005 21:38:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - The translation of field identifiers is the registry file is not this WG's problem. If someone want to do it in some file they've generated from the registry, that's *their* (and their users') problem, not ours. Others one this list have already explained why, in general, translating these bits is probably a bad idea. If someone does it anyway, they've simply created their own format, and it's no longer our problem. Jefsey: if you truly believe this merits an appeal to the IESG, please do so *now*. Randy, ltru co-chair > From: "JFC (Jefsey) Morfin" > To: "Peter Constable" ; "LTRU Working Group" > Sent: Tuesday, May 03, 2005 6:37 PM > Subject: RE: [Ltru] Re: Last registry for now > > At 19:58 03/05/2005, Peter Constable wrote: > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > >On Behalf Of JFC > > > (Jefsey) Morfin > > > This is shocking under the pen of a global standadizer. I will not > > > comment on the contempt for "end-users", non for the exclusion > > > of non-Latin script programmers. > > > >Do you make as much fuss about (say) the fact that HTTP headers use > >Latin characters and that one can't substitute Arabic or other scripts? > > > >We're talking about documentation of protocol elements. When end users > >are involved, I think everyone here would strongly support the need for > >"multilingualization", but his is not an end-user issue. > > Dear Peter, > This kind of question is always embarassing, because it shows how much the > author do not understand what he discusses. I know this is not on purpose. > I will address it to show IESG, and possibly IAB, in appeal that I tried > every time I could to explain how much this WG is out of its track. > > This is not an accademic meeting over three ISO standard's conflicting > oddities. This is not a W3C forum trying to patch an XML misconception. > This is not a few followers helping with the wording of a twice last-calls > denied concept. > > This is an IETF WG having to study, check and document an Internet and > Internet application wide response to the need of identifying and tagging > the languages. For and according to the Internet standard process to > generate standards, documents, procedures, protocols, best practices. For > the Internet to become legally acceptable as a global system. > > To do that this WG should have attracted enough authoritative experts (or > declare itself uncompetent) to study and complet from their own experience, > developments and plans, the points in the Charter. > > I am sure that in this process you would have realized that HTTP is an > Internet protocol in the area of this WG as are every Internet protocol. So > you would understand that I am making no special, but general, fuss. Your > contribution to the WG would have been still more valuable, because you > would have learned from seasoned experts that the very basis of a network > architecture is consistency and coherence. A coherence with the human > protocols (languages) it supports the ASCII Internet has not. A big problem > our job is precisely to start addressing. > > For the rest, I am not in a position to comment: please document (RFC?) > what is an "end user" for an IETF WG. I obviously understand what it may > mean for an host application designer (like W3C?) but here it does not make > any sense to me. > > all the best. > jfc > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 01:02:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTC1l-0006sU-PZ; Wed, 04 May 2005 01:02:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTC1k-0006sG-Ey for ltru@megatron.ietf.org; Wed, 04 May 2005 01:02:28 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16060 for ; Wed, 4 May 2005 01:02:27 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050504050157.HLTH13270.mta11.adelphia.net@DEWELL> for ; Wed, 4 May 2005 01:01:57 -0400 Message-ID: <014401c55066$5bd68980$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 3 May 2005 22:01:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last registry for now X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: >> End users don't have to type the field names. Programmers, who do, >> have access to a Latin-script keyboard. If you can show me a >> programming language or environment that does not require at least >> some use of the Latin script, I will re-think my position. > > This is shocking under the pen of a global standadizer. I will not > comment on the contempt for "end-users", Wouldn't it show *more* contempt for end users to make them type the field names? User interfaces should have as little as possible to do with database details such as field names. In particular, users who have to deal with language tags should not have to type anything. My language-tag UI allows the user to pick subtags from a drop-down list. The names of subtag types, and of course the values, can be localized into any language you like (assuming the translations are available). This has nothing to do with changing the field names in the underlying database. > non for the exclusion of non-Latin script programmers. You still haven't shown evidence that any programming languages are translated into other writing systems, only that it is theoretically possible. > Nor on its political and societal consequences. No on the fact this > may be properly in violation of national laws. If this group is violating any national law for defining a database with field names restricted to ASCII, we will be waiting in front of the courthouse at the end of a very, very long line. > ASCII centrism was an old odd Internet feature, I am afraid you are > beginning to make it a boring bug. Wait, so you don't like "ASCII-centrism," but you resent (a) the involvement of Unicode representatives in this WG and (b) people mentioning Unicode when discussing multiple-script issues. Not that it's on-topic or anything, but what *is* your preferred approach to character encoding? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 05:49:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGVF-0002pH-1E; Wed, 04 May 2005 05:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGVD-0002p9-Pl for ltru@megatron.ietf.org; Wed, 04 May 2005 05:49:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12842 for ; Wed, 4 May 2005 05:49:08 -0400 (EDT) Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTGjG-0008PB-Ht for ltru@ietf.org; Wed, 04 May 2005 06:03:43 -0400 Received: (qmail 24872 messnum 6391657 invoked from network[194.125.134.209/ts02-082.dublin.indigo.ie]); 4 May 2005 09:48:58 -0000 Received: from ts02-082.dublin.indigo.ie (HELO egt.ie) (194.125.134.209) by mail00.svc.cra.dublin.eircom.net (qp 24872) with SMTP; 4 May 2005 09:48:58 -0000 Message-ID: <42789A0C.D3A3E955@egt.ie> Date: Wed, 04 May 2005 10:46:52 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: Last registry for now References: <6.2.1.2.2.20050504021323.0311e500@mail.jefsey.com> <004d01c55063$1dcbb140$7f1afea9@oemcomputer> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA12842 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org True. And I regret raising that point (if it was I who first did so). I am happy with Doug's response, and with Randy's (below), and would like to ask for a quick end to this particular thread, so the real work can go on. mg=20 Scr=EDobh Randy Presuhn: >=20 > Hi - >=20 > The translation of field identifiers is the registry file is not this W= G's > problem. If someone want to do it in some file they've generated from > the registry, that's *their* (and their users') problem, not ours... --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 10:25:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKot-0004n3-Vj; Wed, 04 May 2005 10:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKot-0004lh-6O for ltru@megatron.ietf.org; Wed, 04 May 2005 10:25:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14003 for ; Wed, 4 May 2005 10:25:45 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTL2y-00087a-PP for ltru@ietf.org; Wed, 04 May 2005 10:40:22 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 May 2005 07:25:35 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 May 2005 07:25:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Last registry for now Date: Wed, 4 May 2005 07:25:41 -0700 Message-ID: Thread-Topic: [Ltru] Re: Last registry for now Thread-Index: AcVQSe2T85RLKM1VT0afnD8OaFF8cgAarD6Q From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 04 May 2005 14:25:35.0279 (UTC) FILETIME=[22C86BF0:01C550B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > For the rest, I am not in a position to comment: please document (RFC?) > what is an "end user" for an IETF WG.=20 Excuse me, Jefsey, but this is *your* issue. There is *nobody* else here so far saying that end users' needs are not being adequately met. *You* are the one who needs to write an RFC documenting what an "end user" is if you somehow think that their interests are not being adequately met. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 11:05:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRZ-0008LZ-Ir; Wed, 04 May 2005 11:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRW-0008Kb-RB for ltru@megatron.ietf.org; Wed, 04 May 2005 11:05:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18901 for ; Wed, 4 May 2005 11:05:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLfc-0000xE-U0 for ltru@ietf.org; Wed, 04 May 2005 11:20:17 -0400 Received: from lns-p19-8-idf-82-65-78-79.adsl.proxad.net ([82.65.78.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DTLRN-0006uI-F7; Wed, 04 May 2005 08:05:34 -0700 Message-Id: <6.2.1.2.2.20050504115322.03485eb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 04 May 2005 12:43:52 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: regionalisation In-Reply-To: <013c01c55062$060c1780$030aa8c0@DEWELL> References: <20050503144512.NPUU17200.mta1.adelphia.net@megatron.ietf.org> <013c01c55062$060c1780$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.0 (++) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA18901 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 06:30 04/05/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > 2. The telephone numbering system is the oldest numbering system > > routing into Telex and ISO 3166 alpha-2 is the telex code. > >I know this has been said before, but ISO 3166 alpha-2 is much more than >just the telex code by now. It has been adopted in numerous contexts, >including (of course) TLDs. If a previous solution has worked, choose >it again, right? This is why we can expect and work on some convergence. Including in the=20 ISO committees. Again IANA is a dormant Member (ICANN holds the site). Ou= r=20 indications in that area should go to the IANA section for action. > > ITU and ISO tend to consider it quite stabilized in its principle. It= s > > advantage is that it covers everyone down to every individual. It is > > necessarily related to populations evolution (subscribers) who tend t= o > > have a very good knowledge of it. In this it is better than post code= s > > (which also are good candidates except the Bristish alphanumeric > > system and the geography oriented US system [you have many post codes > > with no population]). > >You must be talking about ZIP codes (our term for postal codes) assigned >to post office boxes, military bases, and major companies. Those >certainly do serve a "population" of sorts. I can't think of any >residential ZIP codes assigned to empty areas. Of the 100,000 possible >five-digit ZIP codes, less than 43% are assigned. The official term is "postcode". "postal code" is Franglish (mix of "code= =20 postal" and of "post code"). The fact that you cannot think of something,= =20 does not prevent it to be effective. I suggest that: 1. access the http://www.upu.int site and document yourself on postcodes=20 (in term of density of population, some ISO 3166 aslo have very low=20 densities, I do not understand the remark).=20 http://www.escapeartist.com/global10/zip.htm may also help you. 2. IRT the US zip codes, I suggest you do not just make a quick google=20 search. The issue is more complex and changing. I have enough worked on=20 them a few years ago to risk that suggestion. > > The problems you rise come from an equivalent ignorance of E.164 and > > of ISO 3166 and probably of X.121 at that time, and from a non-networ= k > > point of view. > >My need at the time was for indexing. A "network point of view" would >have been completely irrelevant to that project. If you found interest in E.164 and ISO 3166, DCCs would probably have=20 helped you. Anyway today our interest is in a "network point of view" (network-centri= c)=20 to match the US doctrine. IMHO we should be in a network-user-centric poi= nt=20 of view. > > People do not think for the world in ASCII as you do, > >I don't know what brought that on. Are you suggesting that language >tags should be localized to other scripts? Obviously yes. > > they think for themselves in their own language, with their own needs= , > > and their own numbers they know (usually telephone number and post- > > code, plus whatever universal number anyone could give them they woul= d > > really use - experience and studies show that people can collectively > > remember at least 3 figures, average 5, never more than seven - same > > for names). > >The studies you are thinking of show that people can only remember five >to seven *random, meaningless* digits or names. I'm sure that both you >and I can recall dozens of 10-digit telephone numbers and street >addresses, and know perhaps hundreds of people by name. That doesn't >mean we have superior memory skills; it means we have something to >connect those numbers and names to. I am afraid you use to respond fast. Please reread what I wrote. "collectively adv : in conjunction with; combined; "Our salaries put together couldn't=20 pay for the damage"; "we couldn`t pay for the damages with all out salari= es=20 put together" [syn: jointly, conjointly, together, put together] Source: WordNet =AE 2.0, =A9 2003 Princeton University" > > This WG has a charter and belongs to the IETF, not to UNICODE nor to > > W3C. > >Has anyone suggested otherwise? Everyone which does not does not make sure this WG has collectively=20 understood and accepted the Charter. >Where do you get this about Unicode? Please read the Charter. > > The first work is to establish a chronological correspondance table > > between all these systems. This is needed in different areas. > > - universal telephone directory (which is to be multilingual) > > - same about whois and their convergence > > - some digital protocol with human protocols implications > > - multilingual internet or multilingual NGN or whatever avatar IETF/ > > ITU and others may come with > > - CRC and contexts > > - applications (operating systems: locales, DNS: mlnames, network > > control/statistics, mails, web, opes/ones, etc.) > >This is nice. Over here, we are working on language tagging. Precisely. And if this tagging does not match the above needs the Draft=20 will not be accepted. The Draft did not failed two last calls due to poor= =20 wording on a few points (this can be clarified by the Editor). It has=20 failed because its proposition is not the one applications above (and=20 probably many other ones) expect. Let discuss the Charter first, after having made sure that all the=20 concerned authoritative parties have been made aware of this WG. I sugges= t=20 each of us describes his concerns as I just did. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 11:05:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRZ-0008Lx-O9; Wed, 04 May 2005 11:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRX-0008Kg-6I for ltru@megatron.ietf.org; Wed, 04 May 2005 11:05:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18908 for ; Wed, 4 May 2005 11:05:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLfd-0000xF-55 for ltru@ietf.org; Wed, 04 May 2005 11:20:17 -0400 Received: from lns-p19-8-idf-82-65-78-79.adsl.proxad.net ([82.65.78.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DTLRO-0006uI-Pl; Wed, 04 May 2005 08:05:35 -0700 Message-Id: <6.2.1.2.2.20050504124550.031491b0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 04 May 2005 13:44:00 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Last registry for now In-Reply-To: <014401c55066$5bd68980$030aa8c0@DEWELL> References: <014401c55066$5bd68980$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.0 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 07:01 04/05/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > >> End users don't have to type the field names. Programmers, who do, > >> have access to a Latin-script keyboard. If you can show me a > >> programming language or environment that does not require at least > >> some use of the Latin script, I will re-think my position. > > > > This is shocking under the pen of a global standadizer. I will not > > comment on the contempt for "end-users", > >Wouldn't it show *more* contempt for end users to make them type the >field names? I am afraid you miss the point. There is no end-users as such. Because the technology does not know them. There are end to end connections and users to users relations. They can be machines and humans. If they are machines, IETF protocols and procedures are used, if they are human languages (human protocols) and best practices prevail. The rest is blahblah. The contempt is that you think you are entitled to decide for other users. Your role, and this is why we do not vote but try to reach a consensus, is not to decide but to describe what everyone can agree. You do not invent something new, you uncover what will appear obvious to all. >User interfaces should have as little as possible to do with database >details such as field names. In particular, users who have to deal with >language tags should not have to type anything. My language-tag UI >allows the user to pick subtags from a drop-down list. The names of >subtag types, and of course the values, can be localized into any >language you like (assuming the translations are available). This has >nothing to do with changing the field names in the underlying database. See above. You describe a GUI of your liking/you developped. This very same right must be possible to everyone in every language. > > non for the exclusion of non-Latin script programmers. > >You still haven't shown evidence that any programming languages are >translated into other writing systems, only that it is theoretically >possible. Dear Doug, you are supposed to be an expert on this matter. The first time you asked it I was polite enough to overlook it. I am afraid this time you unconsider yourself as aware of the use of the internet and of computers of the people you want to decide about and make this WG to lose credibility. > > Nor on its political and societal consequences. No on the fact this > > may be properly in violation of national laws. > >If this group is violating any national law for defining a database with >field names restricted to ASCII, we will be waiting in front of the >courthouse at the end of a very, very long line. may be will you want to read the comment above here too. > > ASCII centrism was an old odd Internet feature, I am afraid you are > > beginning to make it a boring bug. > >Wait, so you don't like "ASCII-centrism," but you resent (a) the >involvement of Unicode representatives in this WG Were did you read this??? I am myself an Unicode member. >and (b) people mentioning Unicode when discussing multiple-script issues. Were to you read this??? I am against confusion and layer violation. The Legacy Internet is in many areas an American (language, culture, legal, political, historical) vision of the Global Network. It uses many Amercian/ASCII default (as you may recall A in ASCII stands for American). One character set, one language, one class, one single group structure, one single IANA, one single (lack of) model, one network management, one naming system, one numbering system, one governance, etc. and many parameters to default zero: no economic model, no statistic system, etc. This is normal as this was the purpose of an ARPA/US academic system. It is the well identified interest of everyone, starting with the USA to change that and build a new environment. What the basic Internet concepts by Robert Khan and Louis Pouzin do permit (if you do not believe it, I will be more than happy to give you their mails, but you can just ask the Chair who just spent a WE with ITU on the matter). The transition to the NGN is not simple and cannot be achieved in one day, all the more than Users are asking for more than NGN by ITU/IETF.You cannot use a magick stick to upgrade it. So this must proceed topic by topic. IPv4 Internet must transition to IPv6 Internet, before becomin an Internat. ASCII Internet must transition to Multilingual Internet. DNS Internet must (and is) transion(ning) to a universal numbering intergovernance. And in so doing, these evolutions should converge through scalability. This is the initial bet of Brian Carpenter's RFC 1958, up to now, it seems it works. Don't block it by egocentric concerns on just one or two applications. > Not that it's on-topic or anything, but what *is* your preferred > approach to character encoding? dated ISO 10646 numbers. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 11:05:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRZ-0008MN-T0; Wed, 04 May 2005 11:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRX-0008Kq-AK for ltru@megatron.ietf.org; Wed, 04 May 2005 11:05:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18906 for ; Wed, 4 May 2005 11:05:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLfd-0000xP-Eg for ltru@ietf.org; Wed, 04 May 2005 11:20:17 -0400 Received: from lns-p19-8-idf-82-65-78-79.adsl.proxad.net ([82.65.78.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DTLRU-0006uI-9B; Wed, 04 May 2005 08:05:40 -0700 Message-Id: <6.2.1.2.2.20050504163957.04d50200@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 04 May 2005 17:05:02 +0200 To: "Peter Constable" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Last registry for now In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 1.3 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 16:25 04/05/2005, Peter Constable wrote: > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > > For the rest, I am not in a position to comment: please document >(RFC?) > > what is an "end user" for an IETF WG. > >Excuse me, Jefsey, but this is *your* issue. ???? >There is *nobody* else here so far saying that end users' needs You make a difference and discriminate among IETF users. Not me. Please document that difference or do not make it as it is extermelly hurting. - The Internet has users, full stop. - IETF has users, full stop. BTW the IETF Chair just described them in another mail a few minutes ago. >are not being adequately met. Both IETF and Internet users' multilingual needs are not addressed by this Draft, by simply being ignored. In opposition to what the Charter specifies. "end users" in a distributed network makes no more architectural sense than on the opposite of the Universe in Azimov's Foundation. Since Azimov found a response, may be will you come with an IETF definition of "end user" (you can search the RFC database, you will see there is no "end user" documented). Then you can show the needs of their are satisfied. I will be very happy learning that. I suppose that you actually genuinely confuse with applications/(de)centralized network end-users, as most in here confuse XML needs with Internet needs, and the working initial confort of an exclusive English speaking group with a multilingual interintelligible standard. You should understand this is highly hurting because it either mean you despise them (as a sort of undefined cast - are there middle-users, super-users?) or that you consider that you know better than them what is good for them. While I am sure you mean none of that. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 11:05:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRa-0008Ml-1r; Wed, 04 May 2005 11:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRX-0008Kh-6c for ltru@megatron.ietf.org; Wed, 04 May 2005 11:05:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18907 for ; Wed, 4 May 2005 11:05:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLfd-0000xK-0t for ltru@ietf.org; Wed, 04 May 2005 11:20:17 -0400 Received: from lns-p19-8-idf-82-65-78-79.adsl.proxad.net ([82.65.78.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DTLRR-0006uI-GL; Wed, 04 May 2005 08:05:38 -0700 Message-Id: <6.2.1.2.2.20050504143310.04e7d040@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 04 May 2005 15:01:52 +0200 To: Marion Gunn From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Last registry for now In-Reply-To: <42789A0C.D3A3E955@egt.ie> References: <6.2.1.2.2.20050504021323.0311e500@mail.jefsey.com> <004d01c55063$1dcbb140$7f1afea9@oemcomputer> <42789A0C.D3A3E955@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 1.3 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA18907 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 11:46 04/05/2005, Marion Gunn wrote: >True. And I regret raising that point (if it was I who first did so). I >am happy with Doug's response, and with Randy's (below), and would like >to ask for a quick end to this particular thread, so the real work can >go on. Dear Marion, you did not "rise" that point - you just quoted a necessary issue. The re= al=20 matter of this WG is here and its real work is to address that problem in= a=20 way which addresses the problems met by the whole internet community with= =20 RFC 3066. These problems are at least (there may be others experts of thi= s=20 WG would add from their experience): - Stability and accessibility of the underlying ISO standards - Difficulty with registrations and their acceptance - Lack of clear guidance on how to identify script and region where neces= sary - Lack of parseability and the ability to verify well-formedness. - Lack of specified algorithms, apart from pure prefix matching, for=20 operations on language tags. You will note this means at least three groups of resulting issues: 1. to address these points in the ASCII Internet context, what means a=20 better writting of the previous document. 2. to address these points in a Multilingual Internet context, where most= =20 of the quoted problems results in part or in toto from their non=20 multilingual approach (when you solve a complex problem, you usually find= =20 that you solved also several other smaller problems) 3. to address the legacy of some applications having either or both relie= d=20 on the RFC 3066 limitations or not expected this evolution. Today this WG only really addresses point 3 in the context of XML and may= =20 be (?) CLDR. This should be part of the second document foreseen by the=20 Charter. The Charter and the first document still need to be worked on.=20 Without it, the current proposition has not the necessary framework to st= and. jfc PS. Since you were not involved earlier and you may not have lurked, the=20 disagreement is easy to understand. RFC 3066 is uncertain enough to have=20 statisfied everyone for four years. But Unicode and W3C people have found= =20 that they needed it to be more precise, created a Draft and now a WG. Mos= t=20 of the others are not excited because IETF is not interested in=20 multilingualism (this is documented by IAB RFC 3869 which lists the=20 Internet R&D priorities) and because the ASCII Internet works today. This= =20 disinterest has lead most of the Internet world outside of the IETF (you=20 may have a count of the non English mother tongue participants to this WG= )=20 and because this is a general IETF/ICANN attitude often expressed by Vint= =20 Cerf all over the WSIS process: 'If it ain't broke, don't fix it."=20 http://techrepublic.com.com/5102-7914-5178386.html In reality the Internet does work but does not fit the job. Doug's non=20 corrected lacks of knowledge of the real world internet and programming=20 practices, only shows that IETF members just do not realise it by lack of= =20 basic information (interest?). There are two options (and I think the=20 earliest they converge the best it is): 1. to document and build a Multilingual Internet. This participates from = a=20 common consistent process of Internet technology upgrade. The technical=20 implications on the Internet architecture (externets) is a really major=20 one. But I hardly see how we can spare it. 2. to build a Multilingual New Global Network. ML.NGN. This is also what = we=20 work on. >mg > >Scr=EDobh Randy Presuhn: > > > > Hi - > > > > The translation of field identifiers is the registry file is not this= WG's > > problem. If someone want to do it in some file they've generated from > > the registry, that's *their* (and their users') problem, not ours... >-- > >Marion Gunn * EGTeo (Estab.1991) >27 P=E1irc an Fh=E9ithlinn, Baile an >Bh=F3thair, Co. =C1tha Cliath, =C9ire. >* mgunn@egt.ie * eamonn@egt.ie * > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 04 11:05:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRc-0008Nb-Ft; Wed, 04 May 2005 11:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRZ-0008LS-0r for ltru@megatron.ietf.org; Wed, 04 May 2005 11:05:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18918 for ; Wed, 4 May 2005 11:05:42 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLff-0000xC-UU for ltru@ietf.org; Wed, 04 May 2005 11:20:20 -0400 Received: from lns-p19-8-idf-82-65-78-79.adsl.proxad.net ([82.65.78.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DTLRM-0006uI-4s; Wed, 04 May 2005 08:05:32 -0700 Message-Id: <6.2.1.2.2.20050504112911.0348eeb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 04 May 2005 11:52:20 +0200 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Last registry for now In-Reply-To: <427832D0.1A91@xyzzy.claranet.de> References: <6.2.1.2.2.20050504021323.0311e500@mail.jefsey.com> <427832D0.1A91@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.0 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear WG Members, For the records: since this issue may lead to the further study of our archives by many, I will try to keep the answers on a per mail basis as requested by external readers. Apologies for that. I fully understand that an American/Franglish is already complex for many to follow. At 04:26 04/05/2005, Frank Ellermann wrote: >JFC (Jefsey) Morfin wrote: > > this WG should have attracted enough authoritative experts > > (or declare itself uncompetent) > >It's really sad that this WG only attracted Martin, Mark, and >Addison, who know nothing about I18N, isn't it ? And now go >and find a forum where you can explain the Web to Sir Tim... If you have read the charter I do not understand what this have to do with the first document. It is about networking architecture and administration, stability of foreign table concordance (data base management), presentation of information (programing), etc. I suppose that some in this group need to be explained the web and its daily usage, but there are other more pressing areas to explain to the members of this WG as the purpose of the IETF, what is a protocol, what is the Internet architecture, what is scalability, what is multilingualism, what is a database maintenance, etc. because they are part of our charter. But I must say I am unable to advise the best forum for that. As to "Sir Tim" I am at loss understanding who you refer to? From the 26 persons or avatars who shared in this WG up to now, even with a single mail, none is named "Tim-something" or "Sir"? > > HTTP is an Internet protocol >...yes, he will be very excited about this great news. Good >luck with your future endeavours. I must say I do not understand what you may want to say here? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 05 04:18:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTbZC-0004m4-Ey; Thu, 05 May 2005 04:18:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTbZA-0004lj-DX for ltru@megatron.ietf.org; Thu, 05 May 2005 04:18:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01461 for ; Thu, 5 May 2005 04:18:37 -0400 (EDT) Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTbnP-0004x3-4p for ltru@ietf.org; Thu, 05 May 2005 04:33:24 -0400 Received: (qmail 73557 messnum 2891753 invoked from network[194.125.207.27/ts11-027.dublin.indigo.ie]); 5 May 2005 08:18:26 -0000 Received: from ts11-027.dublin.indigo.ie (HELO egt.ie) (194.125.207.27) by mail07.svc.cra.dublin.eircom.net (qp 73557) with SMTP; 5 May 2005 08:18:26 -0000 Message-ID: <4279D653.1C7B684@egt.ie> Date: Thu, 05 May 2005 09:16:20 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: unicode@unicode.org, ltru@ietf.org Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA01461 Cc: Subject: [Ltru] ISO/TC 46 mtgs in Dublin (Ireland) next week X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Invitation/reminder to participants in mtgs starting Monday next in Dubli= n. There will be small reception hosted by IIB in the bar of the Mont Clare Hotel (where most delegates will be staying) from 17:30 on. Dress informal (most will have just stepped in off planes from US, Australia, Canada, etc.). Because wearing nametags in a public bar is not on, I am giving here (under my title below) a link to a page where you can find a photo of me, to facilitate our finding one another. With best wishes, Marion Gunn Convener of NSAI's ISO/TC 46 Interest Group Photograph link: Hotel telephone: +353 1 607 3800 Mont Clare, Merrion Square, D2 (across from Oscar Wilde's house). --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 05 04:25:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTbfS-0005zO-P2; Thu, 05 May 2005 04:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTbfQ-0005zA-RW for ltru@megatron.ietf.org; Thu, 05 May 2005 04:25:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01950 for ; Thu, 5 May 2005 04:25:06 -0400 (EDT) Received: from mail05.svc.cra.dublin.eircom.net ([159.134.118.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTbtf-0005FJ-RI for ltru@ietf.org; Thu, 05 May 2005 04:39:53 -0400 Received: (qmail 14524 messnum 3317976 invoked from network[194.125.207.27/ts11-027.dublin.indigo.ie]); 5 May 2005 08:24:57 -0000 Received: from ts11-027.dublin.indigo.ie (HELO egt.ie) (194.125.207.27) by mail05.svc.cra.dublin.eircom.net (qp 14524) with SMTP; 5 May 2005 08:24:57 -0000 Message-ID: <4279D7DA.6463E9F4@egt.ie> Date: Thu, 05 May 2005 09:22:50 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: unicode@unicode.org, ltru@ietf.org References: <4279D653.1C7B684@egt.ie> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA01950 Cc: Subject: [Ltru] Re: ISO/TC 46 mtgs in Dublin (Ireland) next week X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org CORRECTION: Sunday night from 19:30 on (as most will be arriving then).=20 mg Marion Gunn wrote: >=20 > Invitation/reminder to participants in mtgs starting Monday next in Dub= lin. >=20 > There will be small reception hosted by IIB in the bar of the Mont Clar= e > Hotel (where most delegates will be staying) from 17:30 on. >=20 > Dress informal (most will have just stepped in off planes from US, > Australia, Canada, etc.). >=20 > Because wearing nametags in a public bar is not on, I am giving here > (under my title below) a link to a page where you can find a photo of > me, to facilitate our finding one another. >=20 > With best wishes, >=20 > Marion Gunn > Convener of NSAI's ISO/TC 46 Interest Group > Photograph link: > Hotel telephone: +353 1 607 3800 Mont Clare, Merrion Square, D2 (across > from Oscar Wilde's house). >=20 > -- >=20 > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 05 11:30:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTiJB-0001XB-Gg; Thu, 05 May 2005 11:30:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTiJ9-0001X6-K8 for ltru@megatron.ietf.org; Thu, 05 May 2005 11:30:35 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09534 for ; Thu, 5 May 2005 11:30:32 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050505153003.VPIS17140.mta10.adelphia.net@DEWELL> for ; Thu, 5 May 2005 11:30:03 -0400 Message-ID: <006301c55187$147d06a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 5 May 2005 08:28:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: John Cowan's substantive comments on draft-ietf-ltru-registry-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Have all of John Cowan's items from April 6 been addressed? http://www1.ietf.org/mail-archive/web/ltru/current/msg00607.html Here's a summary: 1. Require that extension subtags already be sorted by singleton order in well-formed tags. 2. and 3. Disallow "i", "y", and "z" as singletons in extension subtags. 4. Canonicalizing a tag also normalizes the case of the letters in it. 5. and 6. (already resolved) 7. Remove private use tags from the registry, which in turn makes the definition of value ranges superfluous. 8. Reform the language tag registration form, and add information from that form to the registry. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 05 11:53:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTifX-0005lx-Cm; Thu, 05 May 2005 11:53:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTifW-0005lq-9P for ltru@megatron.ietf.org; Thu, 05 May 2005 11:53:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12544 for ; Thu, 5 May 2005 11:53:37 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTitn-0000tY-4T for ltru@ietf.org; Thu, 05 May 2005 12:08:28 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 08:53:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltru-registry-01 Date: Thu, 5 May 2005 08:53:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B44A307@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltru-registry-01 Thread-Index: AcVRh4YQp2wwO/JGQteOORwaq0+XQwAAO0+A From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 05 May 2005 15:53:18.0154 (UTC) FILETIME=[8E1D2AA0:01C5518A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1800202489==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1800202489== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiANCj4gSGF2ZSBhbGwgb2YgSm9obiBDb3dhbidzIGl0ZW1zIGZyb20gQXByaWwgNiBiZWVuIGFk ZHJlc3NlZD8NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KTm8gdGhleSBoYXZlbid0IGJlZW4gaW5z ZXJ0ZWQgYmVjYXVzZSB0aGVyZSB3YXMgbm8gY29uc2Vuc3VzIG9uIHRoZW0uIFllcywgdGhleSB3 ZXJlIGFkZHJlc3NlZDogSSwgYXQgbGVhc3QsIGRpZG4ndCBhZ3JlZSB3aXRoIHNvbWUgb2YgdGhl bS4NCg0KPiANCj4gaHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1 cnJlbnQvbXNnMDA2MDcuaHRtbA0KPiANCj4gSGVyZSdzIGEgc3VtbWFyeToNCj4gDQo+IDEuICBS ZXF1aXJlIHRoYXQgZXh0ZW5zaW9uIHN1YnRhZ3MgYWxyZWFkeSBiZSBzb3J0ZWQgYnkgc2luZ2xl dG9uIG9yZGVyDQo+IGluIHdlbGwtZm9ybWVkIHRhZ3MuDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoN Ck5vLiBJIGZlZWwgdGhhdCBpcyBhIGZ1bmN0aW9uIG9mIGNhbm9uaWNhbGl6YXRpb24sIG5vdCB3 ZWxsZm9ybWVkbmVzcy4NCj4gDQo+IDIuIGFuZCAzLiAgRGlzYWxsb3cgImkiLCAieSIsIGFuZCAi eiIgYXMgc2luZ2xldG9ucyBpbiBleHRlbnNpb24NCj4gc3VidGFncy4NCltBZGRpc29uIFBoaWxs aXBzXSANCg0KTm8uIEkgZmVlbCB0aGVyZSBpcyBubyByZWFzb24gdG8gZnVydGhlciByZXN0cmlj dCB0aGUgYXZhaWxhYmxlIGxldHRlcnMuIEV4dGVuc2lvbnMgY2Fubm90IHN0YXJ0IGEgdGFnICh0 aGUgcGxhY2Ugd2hlcmUgdGhlIHN1YnRhZyAnaScgY3VycmVudGx5IGFwcGVhcnMgaW4gdGFncyku IA0KPiANCj4gNC4gIENhbm9uaWNhbGl6aW5nIGEgdGFnIGFsc28gbm9ybWFsaXplcyB0aGUgY2Fz ZSBvZiB0aGUgbGV0dGVycyBpbiBpdC4NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KVGhlcmUgaXMg bm8gcmVhc29uIHRvIGluc2lzdCBvbiB0aGlzLiBXZSBjYW4gYWRkIGEgbm90ZSBzdWdnZXN0aW5n IGl0Lg0KPiANCj4gNS4gYW5kIDYuICAoYWxyZWFkeSByZXNvbHZlZCkNCj4gDQo+IDcuICBSZW1v dmUgcHJpdmF0ZSB1c2UgdGFncyBmcm9tIHRoZSByZWdpc3RyeSwgd2hpY2ggaW4gdHVybiBtYWtl cyB0aGUNCj4gZGVmaW5pdGlvbiBvZiB2YWx1ZSByYW5nZXMgc3VwZXJmbHVvdXMuDQpbQWRkaXNv biBQaGlsbGlwc10gDQoNCldlIGNvdWxkIGRvIHRoYXQsIGJ1dCBpdCBpcyB1c2VmdWwgdG8gcmVt aW5kIHBlb3BsZSBvZiB0aGUgcHJpdmF0ZSB1c2Ugc3VidGFncy4NCj4gDQo+IDguICBSZWZvcm0g dGhlIGxhbmd1YWdlIHRhZyByZWdpc3RyYXRpb24gZm9ybSwgYW5kIGFkZCBpbmZvcm1hdGlvbiBm cm9tDQo+IHRoYXQgZm9ybSB0byB0aGUgcmVnaXN0cnkuDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoN CkknbSBwYXJ0aWFsIHRvIEpvaG4ncyBzdWdnZXN0aW9uIGhlcmUgYW5kIEkgZGlkIHJlZm9ybSB0 aGUgcmVnaXN0cmF0aW9uIGZvcm0sIGJ1dCB0aGUgZm9sbG93aW5nIGl0ZW1zIGhhdmUgbm8gZmll bGQgZGVmaW5lZCBjdXJyZW50bHk6DQoNCjEuIE5hbWUgb2YgcmVxdWVzdGVyOg0KMi4gRS1tYWls IGFkZHJlc3Mgb2YgcmVxdWVzdGVyOg0KNC4gSW50ZW5kZWQgbWVhbmluZyBvZiB0aGUgc3VidGFn Og0KNS4gUmVmZXJlbmNlIHRvIHB1Ymxpc2hlZCBkZXNjcmlwdGlvbg0Kb2YgdGhlIGxhbmd1YWdl IChib29rIG9yIGFydGljbGUpOg0KNi4gQW55IG90aGVyIHJlbGV2YW50IGluZm9ybWF0aW9uOg0K DQpOYW1lIG9mIHRoZSByZXF1ZXN0ZXIgY291bGQgYmUgZ2l2ZW4gYSBmaWVsZCAoIlJlZ2lzdGVy ZWQtQnkiPz8pDQoNCkVtYWlsIGFkZHJlc3Mgb2YgdGhlIHJlcXVlc3RlciBhbmQgcmVmZXJlbmNl IHRvIHB1Ymxpc2hlZCBkZXNjcmlwdGlvbiB3b3VsZCBwcm9iYWJseSByZXF1aXJlIHVzIHRvIGFk ZCBzdXBwb3J0IGZvciB0aGUgb3RoZXIgdmFsaWQgVVJJIChSRkMzOTg2KSBjaGFyYWN0ZXJzIHRv IGEgZmllbGQtdmFsdWUsIHNpbmNlIGEgY29tbW9uIHdheSB0byByZWZlcmVuY2UgbWF0ZXJpYWxz IGlzIGluIHRoZSBmb3JtIG9mIGEgVVJJLiBPdGhlcndpc2UgdGhlIHJlZmVyZW5jZSBpcyBhIGNv bW1lbnQtbGlrZSBmaWVsZC4gSSdtIG5vdCBzdXJlIHRoYXQgcHV0dGluZyB0aGUgZW1haWwgYWRk cmVzcyBpbnRvIHRoZSByZWdpc3RyeSBpcyBhIGdvb2QgaWRlYTogaXQncyB1c2VmdWwgZHVyaW5n IHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcywgYnV0IG5vdCBuZWNlc3NhcmlseSB1c2VmdWwgYWZ0 ZXJ3YXJkcy4NCg0KIkFueSBvdGhlciByZWxldmFudCBpbmZvcm1hdGlvbiIgY291bGQgYmUgIkNv bW1lbnQiIGFuZCBjYW4gYmUgcmVtb3ZlZC4gSXQgaXMgZ29vZCBmb3JtIHRvIHB1dCBzdWNoIGEg ZmllbGQgaW50byBhIGZvcm0sIHRob3VnaC4NCg0KSSdtIG5vdCBzdXJlIGhvdyAiaW50ZW5kZWQg bWVhbmluZyIgZGlmZmVycyBmcm9tIHRoZSBkZXNjcmlwdGlvbiBmaWVsZCBpbiB0aGUgcmVjb3Jk LiBXZSBjb3VsZCBwcm9iYWJseSByZW1vdmUgdGhhdC4NCg0KW0FkZGlzb24gUGhpbGxpcHNdIA0K DQpUaGFua3MsDQoNCkFkZGlzb24NCg0KDQoNCg== --===============1800202489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1800202489==-- From ltru-bounces@lists.ietf.org Thu May 05 12:01:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTinM-0007u4-83; Thu, 05 May 2005 12:01:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTinL-0007tl-1y for ltru@megatron.ietf.org; Thu, 05 May 2005 12:01:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13187 for ; Thu, 5 May 2005 12:01:43 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTj1b-0001FD-Sc for ltru@ietf.org; Thu, 05 May 2005 12:16:34 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j45G1U4I640892 for ; Thu, 5 May 2005 12:01:31 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j45G1Tna240030 for ; Thu, 5 May 2005 10:01:29 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j45G1R5r007601 for ; Thu, 5 May 2005 10:01:27 -0600 Received: from markdavis (sig-9-48-116-145.mts.ibm.com [9.48.116.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j45G1R7o007536; Thu, 5 May 2005 10:01:27 -0600 Message-ID: <033401c5518b$b0d043b0$727e3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <006301c55187$147d06a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltru-registry-01 Date: Thu, 5 May 2005 09:01:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j45G1U4I640892 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I believe I've responded on all of them. I'll repeat below. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Thursday, May 05, 2005 08:28 Subject: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltru-registry-01 > Have all of John Cowan's items from April 6 been addressed? > > http://www1.ietf.org/mail-archive/web/ltru/current/msg00607.html > > Here's a summary: > > 1. Require that extension subtags already be sorted by singleton order > in well-formed tags. Don't care. > > 2. and 3. Disallow "i", "y", and "z" as singletons in extension > subtags. Definitely not. > > 4. Canonicalizing a tag also normalizes the case of the letters in it. Don't care. > > 5. and 6. (already resolved) > > 7. Remove private use tags from the registry, which in turn makes the > definition of value ranges superfluous. Absolutely not. This would break compatibility. > > 8. Reform the language tag registration form, and add information from > that form to the registry. Disagree. It would be better to archive the registration forms than encum= ber the registry with a lot of information. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 05 12:23:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTj83-0006bD-N9; Thu, 05 May 2005 12:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTj83-0006b8-2F for ltru@megatron.ietf.org; Thu, 05 May 2005 12:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15803 for ; Thu, 5 May 2005 12:23:07 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjML-0002V3-2W for ltru@ietf.org; Thu, 05 May 2005 12:37:59 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 May 2005 09:22:58 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 May 2005 09:22:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Date: Thu, 5 May 2005 09:22:57 -0700 Message-ID: Thread-Topic: [Ltru] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Thread-Index: AcVRh4YQp2wwO/JGQteOORwaq0+XQwAAO0+AAADXhnA= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 05 May 2005 16:22:58.0309 (UTC) FILETIME=[B32B4350:01C5518E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > I'm partial to John's suggestion here and I did reform the registration form, but the > following items have no field defined currently: >=20 > 1. Name of requester: > 2. E-mail address of requester: > 4. Intended meaning of the subtag: > 5. Reference to published description > of the language (book or article): > 6. Any other relevant information: >=20 > Name of the requester could be given a field ("Registered-By"??) >=20 > Email address of the requester and reference to published description would probably > require us to add support for the other valid URI (RFC3986) characters to a field-value, > since a common way to reference materials is in the form of a URI. Otherwise the > reference is a comment-like field. I'm not sure that putting the email address into the > registry is a good idea: it's useful during the registration process, but not necessarily > useful afterwards. >=20 > "Any other relevant information" could be "Comment" and can be removed. It is good > form to put such a field into a form, though. >=20 > I'm not sure how "intended meaning" differs from the description field in the record. > We could probably remove that. I think the name and email address of the requester are administrative items required when processing the registration request, and that are not needed in the registry itself. I'm not enthusiastic about including email addresses in the registry. I note that the present 3066 registry includes a list of contributors with email addresses at the end, but email addresses are not necessarily enduring, and their inclusion constitutes a security issue. As for the "Intended meaning..." and "Reference..." fields, these fall under the problem of how to document the denotation of the tag, a problem that exists in ISO 639 as well. On the one hand, a language name such as "Ndebele" is insufficient for conveying what the denotation is; often a significant amount of additional information is really necessary. On the other hand, you don't really want to include unbounded encyclopaedic information in a machine-readable registry field as normative information: it's not useful to a machine, it can lead to extreme bloating, and it is impossible to characterize what is normative about such content. If the IANA site will continue to store and make available copies of the registration request forms, then these fields do not need to be added to the registry proper. Perhaps a comment at the beginning of the registry file with a reference to the folder containing the request forms would be useful. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 05 12:28:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjDO-0007mB-Qf; Thu, 05 May 2005 12:28:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjDH-0007ae-2b for ltru@megatron.ietf.org; Thu, 05 May 2005 12:28:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16130 for ; Thu, 5 May 2005 12:28:31 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjRV-0002ez-JL for ltru@ietf.org; Thu, 05 May 2005 12:43:23 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j45GRtM5012675; Thu, 5 May 2005 09:27:59 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 5 May 2005 09:27:54 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Doug Ewell , LTRU Working Group Subject: RE: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltr u-registry-01 Date: Thu, 5 May 2005 09:27:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, My comments inline below. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Thursday, May 05, 2005 11:53 AM > To: Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: John Cowan's substantive comments > ondraft-ietf-ltru-registry-01 > > > > > Have all of John Cowan's items from April 6 been addressed? > [Addison Phillips] > > No they haven't been inserted because there was no consensus > on them. Yes, they were addressed: I, at least, didn't agree > with some of them. > > > > > http://www1.ietf.org/mail-archive/web/ltru/current/msg00607.html > > > > Here's a summary: > > > > 1. Require that extension subtags already be sorted by > singleton order > > in well-formed tags. > [Addison Phillips] > > No. I feel that is a function of canonicalization, not wellformedness. > > Agree with Addison. > > 2. and 3. Disallow "i", "y", and "z" as singletons in extension > > subtags. > [Addison Phillips] > > No. I feel there is no reason to further restrict the > available letters. Extensions cannot start a tag (the place > where the subtag 'i' currently appears in tags). > > Agree with Addison - no need for the restriction. > > 4. Canonicalizing a tag also normalizes the case of the > letters in it. > [Addison Phillips] > > There is no reason to insist on this. We can add a note suggesting it. > > Wait - canonicalization should always involve case normalization, if possible, so that the resulting strings can be binary compared. The various cases used for elements currently (e.g., "Latn", "GB", "en", etc.) are coherent with the ISO source standards but are a pain for canonicalization. For what it's worth, all printing industry standards (CIP4 JDF, IEEE PWG PSI, etc.) follow IETF IPP/1.1 (RFC 2911/2910) usage and require that language tags be normalized to lowercase. Since language tags themselves are a subset of ASCII, this is simple and appropriate. > > 5. and 6. (already resolved) > > > > 7. Remove private use tags from the registry, which in > turn makes the > > definition of value ranges superfluous. > [Addison Phillips] > > We could do that, but it is useful to remind people of the > private use subtags. > > Agree with Addison. > > 8. Reform the language tag registration form, and add > information from > > that form to the registry. > [Addison Phillips] > > I'm partial to John's suggestion here and I did reform the > registration form, but the following items have no field > defined currently: > > 1. Name of requester: > 2. E-mail address of requester: > 4. Intended meaning of the subtag: > 5. Reference to published description > of the language (book or article): > 6. Any other relevant information: > > Name of the requester could be given a field ("Registered-By"??) > > Email address of the requester and reference to published > description would probably require us to add support for the > other valid URI (RFC3986) characters to a field-value, since > a common way to reference materials is in the form of a URI. > Otherwise the reference is a comment-like field. I'm not sure > that putting the email address into the registry is a good > idea: it's useful during the registration process, but not > necessarily useful afterwards. > > "Any other relevant information" could be "Comment" and can > be removed. It is good form to put such a field into a form, though. > > I'm not sure how "intended meaning" differs from the > description field in the record. We could probably remove that. > Disagree with Addison - as Mark Davis has replied, we should archive the registration forms and extract only the minimum necessary fields into the registry itself. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 05 12:36:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjKW-0000Zw-OP; Thu, 05 May 2005 12:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjKU-0000Zr-D1 for ltru@megatron.ietf.org; Thu, 05 May 2005 12:36:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16563 for ; Thu, 5 May 2005 12:35:59 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjYn-00030X-RF for ltru@ietf.org; Thu, 05 May 2005 12:50:51 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 09:35:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltru-registry-01 Date: Thu, 5 May 2005 09:35:49 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B44A387@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltru-registry-01 Thread-Index: AcVRj3ylSPFhhhU5RYWSBHyskhJm9gAAH0Lg From: "Addison Phillips" To: "McDonald, Ira" , "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 05 May 2005 16:35:50.0001 (UTC) FILETIME=[7F221E10:01C55190] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1441369443==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1441369443== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBXYWl0IC0gY2Fub25pY2FsaXphdGlvbiBzaG91bGQgYWx3YXlzIGludm9sdmUgY2FzZSBub3Jt YWxpemF0aW9uLA0KPiBpZiBwb3NzaWJsZSwgc28gdGhhdCB0aGUgcmVzdWx0aW5nIHN0cmluZ3Mg Y2FuIGJlIGJpbmFyeSBjb21wYXJlZC4NCj4gVGhlIHZhcmlvdXMgY2FzZXMgdXNlZCBmb3IgZWxl bWVudHMgY3VycmVudGx5IChlLmcuLCAiTGF0biIsICJHQiIsDQo+ICJlbiIsIGV0Yy4pIGFyZSBj b2hlcmVudCB3aXRoIHRoZSBJU08gc291cmNlIHN0YW5kYXJkcyBidXQgYXJlIGENCj4gcGFpbiBm b3IgY2Fub25pY2FsaXphdGlvbi4gIEZvciB3aGF0IGl0J3Mgd29ydGgsIGFsbCBwcmludGluZw0K PiBpbmR1c3RyeSBzdGFuZGFyZHMgKENJUDQgSkRGLCBJRUVFIFBXRyBQU0ksIGV0Yy4pIGZvbGxv dyBJRVRGIElQUC8xLjENCj4gKFJGQyAyOTExLzI5MTApIHVzYWdlIGFuZCByZXF1aXJlIHRoYXQg bGFuZ3VhZ2UgdGFncyBiZSBub3JtYWxpemVkIHRvDQo+IGxvd2VyY2FzZS4gIFNpbmNlIGxhbmd1 YWdlIHRhZ3MgdGhlbXNlbHZlcyBhcmUgYSBzdWJzZXQgb2YgQVNDSUksDQo+IHRoaXMgaXMgc2lt cGxlIGFuZCBhcHByb3ByaWF0ZS4NCg0KQnV0IGxhbmd1YWdlIHRhZ3MgYXJlIGFscmVhZHkgYSBz cGVjaWFsIGNhc2UuIFRoZXJlIGlzIGFtcGxlIHRleHQgaW4gUkZDIDMwNjYgYW5kIDE3NjYgdGhh dCBmb3JiYWRlIGNhc2UgZGlzdGluY3Rpb24gaW4gcHJvY2Vzc29ycy4gQ2Fub25pY2FsaXphdGlv biBhcyBhIHByb2Nlc3MgbWlnaHQgYmUgcmVxdWlyZWQgdG8gcHJvZHVjZSBzcGVjaWZpYyBjYXNp bmcsIGJ1dCBwcm9jZXNzaW5nIGNhbiBuZXZlciwgZXZlciByZWx5IG9uIGJpbmFyeSBjb21wYXJp c29uIGZvciBjb21wYXRpYmlsaXR5IHdpdGggUkZDIDMwNjYuDQoNCkluIGFkZGl0aW9uLCBKb2hu IGlzIHN1Z2dlc3Rpbmcgbm90IGxvd2VyY2FzZSwgYnV0IGNhc2UgYXBwcm9wcmlhdGUgdG8gdGhl IHVuZGVybHlpbmcgc3RhbmRhcmRzLiBJbiBvdGhlciB3b3JkczoNCg0KZW4tTGF0bi1VUw0KDQo+ IERpc2FncmVlIHdpdGggQWRkaXNvbiAtIGFzIE1hcmsgRGF2aXMgaGFzIHJlcGxpZWQsIHdlIHNo b3VsZA0KPiBhcmNoaXZlIHRoZSByZWdpc3RyYXRpb24gZm9ybXMgYW5kIGV4dHJhY3Qgb25seSB0 aGUgbWluaW11bQ0KPiBuZWNlc3NhcnkgZmllbGRzIGludG8gdGhlIHJlZ2lzdHJ5IGl0c2VsZi4N Cg0KQWN0dWFsbHksIHdlIGRvbid0IGRpc2FncmVlLiBJIG1lcmVseSBlbnVtZXJhdGVkIHdoYXQg d291bGQgaGF2ZSB0byBiZSBkb25lIHRvIGluY2x1ZGUgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBy ZWdpc3RyeSAod2hpY2ggSSByZWdhcmQgYXMgYSBjYXNlIGFnYWluc3QgYWRkaW5nIHRoZSBmaWVs ZHMpLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJj aGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBD b3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVy ZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg0K --===============1441369443== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1441369443==-- From ltru-bounces@lists.ietf.org Thu May 05 12:50:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjYw-0003dB-2g; Thu, 05 May 2005 12:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjYu-0003ct-GF for ltru@megatron.ietf.org; Thu, 05 May 2005 12:50:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17613 for ; Thu, 5 May 2005 12:50:53 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjnC-0003fO-4Z for ltru@ietf.org; Thu, 05 May 2005 13:05:45 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j45GobRm024021; Thu, 5 May 2005 12:50:38 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 5 May 2005 12:50:39 -0400 Date: Thu, 5 May 2005 12:50:38 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: John Cowan's substantive comments on draft-ietf-ltru-registry-01 Message-ID: <20050505165038.GP19734@skunk.reutershealth.com> References: <006301c55187$147d06a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006301c55187$147d06a0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell scripsit: > 7. Remove private use tags from the registry, which in turn makes the > definition of value ranges superfluous. I withdraw this one. -- Not to perambulate John Cowan the corridors http://www.reutershealth.com during the hours of repose http://www.ccil.org/~cowan in the boots of ascension. --Sign in Austrian ski-resort hotel _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 05 21:25:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTraX-0003L9-Fh; Thu, 05 May 2005 21:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTraU-0003Kv-SP for ltru@megatron.ietf.org; Thu, 05 May 2005 21:25:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16145 for ; Thu, 5 May 2005 21:25:04 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTrot-000080-ID for ltru@ietf.org; Thu, 05 May 2005 21:39:59 -0400 Received: from lns-p19-8-idf-82-65-72-134.adsl.proxad.net ([82.65.72.134] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DTraK-00055p-2j; Thu, 05 May 2005 18:24:56 -0700 Message-Id: <6.2.1.2.2.20050506013029.03612910@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 06 May 2005 01:52:12 +0200 To: "McDonald, Ira" , "'Addison Phillips'" , Doug Ewell , LTRU Working Group From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltr u-registry-01 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 18:27 05/05/2005, McDonald, Ira wrote:> > Have all of John Cowan's items from April 6 been addressed? > > > 2. and 3. Disallow "i", "y", and "z" as singletons in extension > > > subtags. > > [Addison Phillips] > > > > No. I feel there is no reason to further restrict the > > available letters. Extensions cannot start a tag (the place > > where the subtag 'i' currently appears in tags). > > > > >Agree with Addison - no need for the restriction. "extensions cannot start a tag" should not be taken for granted. The proposed melt langtag (script, language, region, etc.) sustains a confusion in usage that will certainly be used by many to other needs. The same you identified the need this time to insert scripts into langtags, the next RFC 3066 bis reviewer will propose to correct the imposed lack of extensibility resulting from associating a langtag with a identfied language (what is pretty absurd when you consider that we all use polylingual, single script, keyboards). So, you should consider how to reduce the complexity of their task. > > > 4. Canonicalizing a tag also normalizes the case of the > > letters in it. > > [Addison Phillips] > > > > There is no reason to insist on this. We can add a note suggesting it. > > > > >Wait - canonicalization should always involve case normalization, >if possible, so that the resulting strings can be binary compared. >The various cases used for elements currently (e.g., "Latn", "GB", >"en", etc.) are coherent with the ISO source standards but are a >pain for canonicalization. For what it's worth, all printing >industry standards (CIP4 JDF, IEEE PWG PSI, etc.) follow IETF IPP/1.1 >(RFC 2911/2910) usage and require that language tags be normalized to >lowercase. Since language tags themselves are a subset of ASCII, >this is simple and appropriate. RFC 1958. Full stop. Here is IETF and Intenet. If this was not the case, the proposition would not fly. > > > 5. and 6. (already resolved) > > > > > > 7. Remove private use tags from the registry, which in > > turn makes the > > > definition of value ranges superfluous. > > [Addison Phillips] > > > > We could do that, but it is useful to remind people of the > > private use subtags. > > > > >Agree with Addison. I would disagree: reminding people is good. If well worded a ballanced presentation clarifies a presentation. > > > 8. Reform the language tag registration form, and add > > information from > > > that form to the registry. > > [Addison Phillips] > > > > I'm partial to John's suggestion here and I did reform the > > registration form, but the following items have no field > > defined currently: > > > > 1. Name of requester: > > 2. E-mail address of requester: > > 4. Intended meaning of the subtag: > > 5. Reference to published description > > of the language (book or article): > > 6. Any other relevant information: > > > > Name of the requester could be given a field ("Registered-By"??) > > > > Email address of the requester and reference to published > > description would probably require us to add support for the > > other valid URI (RFC3986) characters to a field-value, since > > a common way to reference materials is in the form of a URI. > > Otherwise the reference is a comment-like field. I'm not sure > > that putting the email address into the registry is a good > > idea: it's useful during the registration process, but not > > necessarily useful afterwards. > > > > "Any other relevant information" could be "Comment" and can > > be removed. It is good form to put such a field into a form, though. > > > > I'm not sure how "intended meaning" differs from the > > description field in the record. We could probably remove that. > > > >Disagree with Addison - as Mark Davis has replied, we should >archive the registration forms and extract only the minimum >necessary fields into the registry itself. The IANA registry can only contain the same fields as the completed standard. You would otherwise engineer conflicts. You would also have to document the case where an existing ISO code is to be registered to add information the ISO standard does not contain. Let take an example you love, en-Latn-US. What if someone wants to register it in adding a comment "Internet koine, its command is required to access to the Internet standards and programing environment", the debate will most probably result into an Internet split. Do you really want it? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 06 02:15:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTw7R-0004rn-El; Fri, 06 May 2005 02:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTw7N-0004rU-OF for ltru@megatron.ietf.org; Fri, 06 May 2005 02:15:21 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25947 for ; Fri, 6 May 2005 02:15:19 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050506061448.ILVC13270.mta11.adelphia.net@DEWELL> for ; Fri, 6 May 2005 02:14:48 -0400 Message-ID: <00ac01c55202$d0833880$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B44A307@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltru-registry-01 Date: Thu, 5 May 2005 23:13:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >> Have all of John Cowan's items from April 6 been addressed? > > No they haven't been inserted because there was no consensus on them. I knew they weren't all reflected in the draft; that wasn't my question. Of the ones that weren't, I didn't know which had been rejected and which had not been discussed adequately to determine consensus pro or con. > Yes, they were addressed: I, at least, didn't agree with some of them. I don't either, as seen below. >> 1. Require that extension subtags already be sorted by singleton >> order in well-formed tags. > > No. I feel that is a function of canonicalization, not wellformedness. I agree. Well-formedness is not related to content at all, except for grandfathered tags. "pu-Blaz-FU-scrog" is well-formed. >> 2. and 3. Disallow "i", "y", and "z" as singletons in extension >> subtags. > > No. I feel there is no reason to further restrict the available > letters. Extensions cannot start a tag (the place where the subtag > 'i' currently appears in tags). I agree. The stated benefit of excluding 'i' is that it prevents a "confusing" situation that may not ever actually materialize. IETF can always defer assigning 'i' if they think it will cause confusion. Excluding 'y' and 'z' to preserve alpha order doesn't make things significantly easier for implementers (IMHO as someone who's implemented a validating parser). The order is already alpha "except for x," which isn't that hard to implement. >> 4. Canonicalizing a tag also normalizes the case of the letters in >> it. > > There is no reason to insist on this. We can add a note suggesting it. I actually kind of like this one. Unlike well-formedness, canonicalization does imply something about the content. There might be some trouble with "yi-latn," a grandfathered tag which was registered with that capitalization (lowercase L). It's true that strict binary equivalence is not necessary for matching, but normalizing the case might make things "prettier" in the same way as sorting the extensions. >> 7. Remove private use tags from the registry, which in turn makes >> the definition of value ranges superfluous. Moot since John withdrew the proposal. (I didn't like it because I feel it's important to point out the validity of the private-use tags, which were not valid in RFC 3066.) >> 8. Reform the language tag registration form, and add information >> from that form to the registry. I disagree with adding any more encyclopedic information to the registry. It should only contain the information necessary to implement the tagging mechanism. In particular, registering the name and e-mail address of the requester of a subtag may give the impression that that person is some sort of expert or authority on the language variant (or whatever), which is not necessarily true; he or she may simply have been the one who filled out the form. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 06 03:49:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTxal-00042p-Tc; Fri, 06 May 2005 03:49:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTxak-00042k-Pb for ltru@megatron.ietf.org; Fri, 06 May 2005 03:49:47 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11223 for ; Fri, 6 May 2005 03:49:44 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DTxTh-0007w8-Qu for ltru@lists.ietf.org; Fri, 06 May 2005 09:42:29 +0200 Received: from 212.82.251.5 ([212.82.251.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 May 2005 09:42:29 +0200 Received: from nobody by 212.82.251.5 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 May 2005 09:42:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 06 May 2005 09:46:53 +0200 Organization: Lines: 12 Message-ID: <427B20ED.6E6@xyzzy.claranet.de> References: <006301c55187$147d06a0$030aa8c0@DEWELL> <033401c5518b$b0d043b0$727e3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.5 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Registration forms (was: ...substantive comments on draft-ietf-ltru-registry...) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > It would be better to archive the registration forms than > encumber the registry with a lot of information. Yes, that should continue to work with this clause in 3.4: | All approved registration forms are available online in the | directory http://www.iana.org/numbers.html under "languages". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 06 04:45:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTySB-0005YC-R1; Fri, 06 May 2005 04:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTyS9-0005Y2-Vu for ltru@megatron.ietf.org; Fri, 06 May 2005 04:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15987 for ; Fri, 6 May 2005 04:44:55 -0400 (EDT) Received: from mail12.svc.cra.dublin.eircom.net ([159.134.118.28]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTygZ-0002mO-0z for ltru@ietf.org; Fri, 06 May 2005 04:59:54 -0400 Received: (qmail 94619 messnum 5761856 invoked from network[194.125.220.249/unknown]); 6 May 2005 08:44:39 -0000 Received: from unknown (HELO egt.ie) (194.125.220.249) by mail12.svc.cra.dublin.eircom.net (qp 94619) with SMTP; 6 May 2005 08:44:39 -0000 Message-ID: <427B2DF7.A8D5302C@egt.ie> Date: Fri, 06 May 2005 09:42:30 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 References: <634978A7DF025A40BFEF33EB191E13BC0B44A307@irvmbxw01.quest.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA15987 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Surely one field could contain 1-6 below en bloc (as only useful when taken together).=20 'Reg-background' as field tag?=20 mg Scr=EDobh Addison Phillips: > ... > I'm partial to John's suggestion here and I did reform=20 > the registration form, but the following items have no field defined cu= rrently: >=20 > 1. Name of requester: > 2. E-mail address of requester: > 4. Intended meaning of the subtag: > 5. Reference to published description > of the language (book or article): > 6. Any other relevant information: >=20 > Name of the requester could be given a field ("Registered-By"??)... > Addison --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 07 22:21:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUbPg-0001qp-AO; Sat, 07 May 2005 22:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUbPf-0001qk-EF for ltru@megatron.ietf.org; Sat, 07 May 2005 22:20:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08826 for ; Sat, 7 May 2005 22:20:57 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUbeU-0006Mv-E6 for ltru@ietf.org; Sat, 07 May 2005 22:36:18 -0400 Received: from lns-p19-2-idf-82-251-149-149.adsl.proxad.net ([82.251.149.149] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DUbPd-0000Ha-Pu for ltru@ietf.org; Sat, 07 May 2005 19:20:58 -0700 Message-Id: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 08 May 2005 03:58:53 +0200 To: LTRU Working Group From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Ltru] RFC 2277 - considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is not a position. Just a thinking and a call for comments. ---- RFC 2277 says: "This document uses the term "charset" to mean a set of rules for mapping from a sequence of octets to a sequence of characters, such as the combination of a coded character set and a character encoding scheme; this is also what is used as an identifier in MIME "charset=" parameters, and registered in the IANA charset registry [REG]. (Note that this is NOT a term used by other standards bodies, such as ISO).". The point is that if the term is not used elsewhere, it may mean that the concept is adapted to the network dynamic environment and others are less or not. It charset=encording_scheme+character_set. I first considered that W3C was right in having identified its need of "scripts" support, however the idea of making them dependent from languages seemed to be strange. But the more I think of them, the more I have difficulty understanding what the "script" notion, introduced in the Draft, brings in addition to the charsets: it belongs to it. The more I see sources of conflicts if this is not respected. The more I see that the script is one of the rules which shares in the definition of the charcter set, and the more I fail to see where the W3C has a problem (except may be in confusing charset with encording scheme only, however http://www.w3.org/TR/REC-html40/charset.html starts with a clear "character set" part where it specifically quote Latin and Cyrilic)). I come back to a normal process of access to a page/document. 1. to be able to read it I need to know the charset. This is the first information. It tells me the rules for mapping from a sequence of bytes to a sequence of characters (character encoding scheme: ex. UTF-8 and combination of coded characters, ex: ISO 15924). Ex: UTF-8-Latin 2. then when I read I need to understand. I have the language. And possible region. As per RFC 3066 existing scheme and not calling for a modification of the existing libraries. 3. the interest is that this is compatible with IDN tables (and permits to address the high level IDN homograph problem, since charsets are documented everywhere). I also note that RFC 2277 and 3066 seem to address the locales need (however CLDR may have some proprietary special needs, authors have not documented?) I therefore tend to think the "script" information is to be located in the charset tag. I suppose they are able to understand UTF-8.latin as UTF-8 and that legacy is transparent? Comments? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 09 02:45:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV20x-0003JZ-Ib; Mon, 09 May 2005 02:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV20u-0003JU-OJ for ltru@megatron.ietf.org; Mon, 09 May 2005 02:45:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06430 for ; Mon, 9 May 2005 02:45:11 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV2Fx-0002Co-Jd for ltru@ietf.org; Mon, 09 May 2005 03:00:46 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j496if721764; Mon, 9 May 2005 15:44:41 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id f29974fe_c055_11d9_9392_0030482533a1_17502; Mon, 09 May 2005 15:45:35 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0055BD; 9 May 05 15:47:09 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 9 May 05 15:46:54 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0055B9; 9 May 05 15:46:50 +0900 Message-Id: <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 08 May 2005 16:01:16 +0900 To: "JFC (Jefsey) Morfin" , LTRU Working Group From: Martin Duerst Subject: Re: [Ltru] RFC 2277 - considerations In-Reply-To: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 10:58 05/05/08, JFC (Jefsey) Morfin wrote: >This is not a position. Just a thinking and a call for comments. > >---- > >RFC 2277 says: "This document uses the term "charset" to mean a set of rules for mapping from a sequence of octets to a sequence of characters, such as the combination of a coded character set and a character encoding scheme; this is also what is used as an identifier in MIME "charset=" parameters, and registered in the IANA charset registry [REG]. (Note that this is NOT a term used by other standards bodies, such as ISO).". > >The point is that if the term is not used elsewhere, it may mean that the concept is adapted to the network dynamic environment and others are less or not. It charset=encording_scheme+character_set. The term 'charset' got to where it is because when the MIME spec was created, the people creating it were thinking in terms of 7-bit and 8-bit encodings, and in addition just (most probably inconciously) shortened "coded character set" to "character set". So the term is there mostly by accident. >I first considered that W3C was right in having identified its need of "scripts" support, however the idea of making them dependent from languages seemed to be strange. It wasn't W3C which identified the need for scripts support. Some people that you associate with W3C may have been involved, but that doesn't mean that it was W3C. The need for scripts in language tags (or separate) is an old issue. I remember a discussion with Michael Everson, who proposed an HTTP header Accept-Script (or some such) years ago on the ietf-languages list. The discussion at that time came to the conclusion that this (having script orthogonal to language) might be a nice idea in principle, but that in practice, the connection is extremely strong, and in most cases, script info isn't necessary because it can easily be implied. >But the more I think of them, the more I have difficulty understanding what the "script" notion, introduced in the Draft, brings in addition to the charsets: it belongs to it. There is some connection, in that many "charset"s only encode one script, or to be more precise, one script + basic ASCII + some symbols. But there are some important "charset"s (in particular UTF-8 and UTF-16,...) where this doesn't apply. Also, there are many other encodings that contain multiple scripts (e.g. you can write Greek with iso-2022-jp, and so on). >The more I see sources of conflicts if this is not respected. If you see such conflicts, could you give an actual example? >The more I see that the script is one of the rules which shares in the definition of the charcter set, and the more I fail to see where the W3C has a problem (except may be in confusing charset with encording scheme only, however http://www.w3.org/TR/REC-html40/charset.html starts with a clear "character set" part where it specifically quote Latin and Cyrilic)). > >I come back to a normal process of access to a page/document. > >1. to be able to read it I need to know the charset. This is the first information. It tells me the rules for mapping from a sequence of bytes to a sequence of characters (character encoding scheme: ex. UTF-8 Yes indeed. Having the correct 'charset' is extremely important. >and combination of coded characters, ex: ISO 15924). Ex: UTF-8-Latin No. If you know it's UTF-8, you can just look inside the document, and check what script(s!) are used. >2. then when I read I need to understand. I have the language. And possible region. As per RFC 3066 existing scheme and not calling for a modification of the existing libraries. > >3. the interest is that this is compatible with IDN tables (and permits to address the high level IDN homograph problem, since charsets are documented everywhere). I also note that RFC 2277 and 3066 seem to address the locales need (however CLDR may have some proprietary special needs, authors have not documented?) > >I therefore tend to think the "script" information is to be located in the charset tag. The Web, email, and a lot of other things have worked extremely well without script information in charset tags, and I don't see why this would not continue. >I suppose they are able to understand UTF-8.latin as UTF-8 and that legacy is transparent? Definitely not. For language tags, quite a few applications understand subtag-based prefixes, as the specs have been defined with subtags in mind from the start. For charsets, they do not. Charsets do not have and never had subtags. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 09 06:05:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV58R-0003hf-6S; Mon, 09 May 2005 06:05:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV58Q-0003ha-49 for ltru@megatron.ietf.org; Mon, 09 May 2005 06:05:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22797 for ; Mon, 9 May 2005 06:05:07 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV5NV-0000r0-4p for ltru@ietf.org; Mon, 09 May 2005 06:20:45 -0400 Received: from lns-p19-8-idf-82-65-73-204.adsl.proxad.net ([82.65.73.204] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DV58L-0001dU-J4; Mon, 09 May 2005 03:05:06 -0700 Message-Id: <6.2.1.2.2.20050509095439.04a02eb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 09 May 2005 12:05:03 +0200 To: Martin Duerst From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] RFC 2277 - considerations In-Reply-To: <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Martin, what is confusing with IETF vs. other standardisation organisations is that they deal with networks (what means complexity and changes) and do not produce structured updated documents. So, the only way to deal with its deliverables is to consider them as the center of their own world, with their own logic and to confront their various expressions. Not to dwell on outside considerations, internal arfceology being enough. For thee good reasons: - this network centric approach has done well for the last 30 years and produced a consistent system even if sometimes complex. - the user approach is user-centric. The user has his machine and his ADSL plug, and looks in the manual expecting the authors have resolved all the issues/confusion/conflicts. - this is most probably the secret for scalability. Le reveiw this. There is a concept named "charset", with five understandings plus one comment (may be more ??) : 1. yours: "The term 'charset' got to where it is because when the MIME specifications was created, the people creating it were thinking in terms of 7-bit and 8-bit encodings, and in addition just (most probably unconsciously) shortened "coded character set" to "character set". So the term is there mostly by accident." - unconscious for a particular encoding scheme. 2. one which seems to be the one of the W3C, Unicode, ISO members of this WG. I suppose that Misha will not oppose to my quote of him http://czyborra.com/charsets/iso8859.html#ISO-8859-3 . This quote is independent to this debate, is dated 1998 and covers IMHO the whole issue (charset/ISO 10646). "The ISO 8859 charsets are not even remotely as complete as the truly great Unicode but they have been around and usable for quite a while (first registered Internet charsets for use with MIME) and have already offered a major improvement over the plain 7bit US-ASCII. Unicode (ISO 10646) will make this whole chaos of mutually incompatible charsets superfluous because it unifies a superset of all established charsets and is out to cover all the world's languages. But I still haven't seen any software to display all of Unicode on my Unix screen. We're working on it. " - limited lists of characters, an improvement over US ASCII, but smaller than ISO 19646. 3. RFC 2879 says: The term "charset" (referred to as a "character set" in previous versions of this document) is used here to refer to a method of converting a sequence of octets into a sequence of characters. This conversion may also optionally produce additional control information such as directionality indicators. http://www.iana.org/assignments/character-sets (last updated on January 28th, 2005) - N. Freed (Jon Postel) is consciously defining it as a generally encoding system and implicitly acknowledge the multiplicity of lists in defining a IANA registry for them. 4. RFC 2277 which says: "This document uses the term "charset" to mean a set of rules for mapping from a sequence of octets to a sequence of characters, such as the combination of a coded character set and a character encoding scheme; this is also what is used as an identifier in MIME "charset=" parameters, and registered in the IANA charset registry [REG]. (Note that this is NOT a term used by other standards bodies, such as ISO).". - Harald Alvestrand gives a very clear comprehensive definition: "a set of rules" which permits to build any of them, with examples: your first example (MIME) and the IANA registry. 5. The IANA definition: "These are the official names for character sets that may be used in the Internet and may be referred to in Internet documentation. These names are expressed in ANSI_X3.4-1968 which is commonly called US-ASCII or simply ASCII. The character set most commonly use in the Internet and used especially in protocol standards is US-ASCII, this is strongly encouraged. The use of the name US-ASCII is also encouraged.// The character set names may be up to 40 characters taken from the printable characters of US-ASCII. However, no distinction is made between use of upper and lower case letters." - follows a list of 250 charsets. Comment is by RFC 2130 (a Californian Workshop with Harald, Crispin, +) : "The term 'language tag' should be reserved for the short identifier of RFC 1766 [RFC-1766] that only serves to identify the language. While there may be other text attributes intimately associated with the language of the document, such as desired font or text direction, these should be specified with other identifiers rather than overloading the language tag." It then confirms the duality of: "3.4.2: Default Coded Character Set: The default Coded Character Set is the repertoire of ISO-10646. "3.4.3: Default Character Encoding Scheme: "For text-oriented protocols, new protocols should use UTF-8, and protocols that have a backwards compatibility requirement should use the default of the existing protocol, e.g. US-ASCII for mail, and ISO-8859-1 for HTTP" Further to this I understand the global picture as follows. 1. there are several partial complementary understandings of the term "charset". Harald's is the most comprehensive and interesting one. It does not conflict with any of them and enrich them. I stick to it. 2. there are two approaches: - one is by ISO 10646 which is to get a global charset. - one is by the IANA registry which is the specialised charset. 3. there is a problem which is three consistency between these two approaches which is a flexible partition between these two approaches. I think Harald's definition permits to address this: a global charset results from the application of an encoding rule on every characters (ISO 10646) and a specialised charset results from the application of additional rules. 4. new charsets can be registered through an RFC or through a regstration procedure. - I see no reason why ISO 15924 as well as many other standard character sets could not be registered as UTF-8-15924_CODES/NRs and permit a complete support of the language. - I agree with Harald Alvestrand, M. Crispin, etc. in not overloading the langtag with information which does not really belong here. Actually I do not seen the reason why layout information would be included there. I comment your other remarks in the text: On 09:01 08/05/2005, Martin Duerst said: > >I first considered that W3C was right in having identified its need of > "scripts" support, however the idea of making them dependent from > languages seemed to be strange. > >It wasn't W3C which identified the need for scripts support. Some >people that you associate with W3C may have been involved, but >that doesn't mean that it was W3C. Addison documented the problem he wants to solve as an XML problem and the non discussed charter only quote HTML, XML and CLDR. I see no other documented need. I only see objections from other applications which are responded as "not our concern". I also see a pressure by Unicode for reasons I do not understand since they do not want to document CLDR needs. >The need for scripts in language tags (or separate) is an old issue. Yes. I first had to address it in 1982 for French Videotex, Katakana, etc. This does not make it a good point. It was ruled out by RFC 2130. >I remember a discussion with Michael Everson, who proposed an HTTP >header Accept-Script (or some such) years ago on the ietf-languages >list. His privilege. I understand it since he is the Unicode proponent for ISO 15924. This WG Charter proposed to use ISO 15924, but I do not think it is to be used in the langtag (this calls to replace RFC 227 and 2130, to discuss several other RFC for compatibility etc.). This should be discussed on ietf-charsets@iana.org. >The discussion at that time came to the conclusion that this >(having script orthogonal to language) might be a nice idea in principle, >but that in practice, the connection is extremely strong, and in most >cases, script info isn't necessary because it can easily be implied. There is an obvious confusion between charset and script here (at least if you consider that "script" is attached to a language as you seem to imply it, ISO 15924 does it, and this WG's debate lead to think others do). There may be many different charsets to support a language. In French only I can quote obvious ones: - legal - non-accented upper cases - upper cases only - AFNIC > >But the more I think of them, the more I have difficulty understanding > what the "script" notion, introduced in the Draft, brings in addition to > the charsets: it belongs to it. > >There is some connection, in that many "charset"s only encode one script, >or to be more precise, one script + basic ASCII + some symbols. But there >are some important "charset"s (in particular UTF-8 and UTF-16,...) where >this doesn't apply. Also, there are many other encodings that contain >multiple scripts (e.g. you can write Greek with iso-2022-jp, and so on). We may discuss that at length... the important is that you acknowledge "there is some connection" while langage and scripts are "orthogonal", this can only lead to conflicts ... > >The more I see sources of conflicts if this is not respected. > >If you see such conflicts, could you give an actual example? Latin-1 does not fully support French. There is a conflict between charset: 8859-1 and langtag: fr-Latn-FR. > >The more I see that the script is one of the rules which shares in the > definition of the charcter set, and the more I fail to see where the W3C > has a problem (except may be in confusing charset with encording scheme > only, however http://www.w3.org/TR/REC-html40/charset.html starts with a > clear "character set" part where it specifically quote Latin and Cyrilic)). > > > >I come back to a normal process of access to a page/document. > > > >1. to be able to read it I need to know the charset. This is the first > information. It tells me the rules for mapping from a sequence of bytes > to a sequence of characters (character encoding scheme: ex. UTF-8 > >Yes indeed. Having the correct 'charset' is extremely important. > > >and combination of coded characters, ex: ISO 15924). Ex: UTF-8-Latin > >No. If you know it's UTF-8, you can just look inside the document, and >check what script(s!) are used. Orthogonal to the discussion. You can do that with any RFC 3066 langtag. This is what is supposed to be corrected by the Draft. > >2. then when I read I need to understand. I have the language. And > possible region. As per RFC 3066 existing scheme and not calling for a > modification of the existing libraries. > > > >3. the interest is that this is compatible with IDN tables (and permits > to address the high level IDN homograph problem, since charsets are > documented everywhere). I also note that RFC 2277 and 3066 seem to > address the locales need (however CLDR may have some proprietary special > needs, authors have not documented?) > > > >I therefore tend to think the "script" information is to be located in > the charset tag. > >The Web, email, and a lot of other things have worked extremely well without >script information in charset tags, and I don't see why this would not >continue. True. This is why the question is "what is the script information"? A real novelty, or an additional rule to better tune existing parameters. And which parameter. If a novelty, why to not to discuss the langtag (however opposed by RFC 2031). If an additional rule to refine an existing info, better to put it with that info, rather then in an orthogonal container. > >I suppose they are able to understand UTF-8.latin as UTF-8 and that > legacy is transparent? > >Definitely not. For language tags, quite a few applications understand >subtag-based prefixes, as the specs have been defined with subtags in mind >from the start. For charsets, they do not. Charsets do not have and >never had subtags. OK. Then it is UTF-8-Latn and 100 charset registrations, either through ietf-charsets@iana.org or through an appendix to RFC 2277 bis. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 09 11:40:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAMw-0003Kf-Mm; Mon, 09 May 2005 11:40:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAMt-0003Ju-SF for ltru@megatron.ietf.org; Mon, 09 May 2005 11:40:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27723 for ; Mon, 9 May 2005 11:40:24 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVAbz-0005aF-P2 for ltru@ietf.org; Mon, 09 May 2005 11:56:05 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LNZ2GSU88W00004T@mauve.mrochek.com> for ltru@ietf.org; Mon, 09 May 2005 08:40:19 -0700 (PDT) Date: Mon, 09 May 2005 07:23:16 -0700 (PDT) In-reply-to: "Your message dated Sun, 08 May 2005 16:01:16 +0900" <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> Message-id: <01LO1QSCZ7S800004T@mauve.mrochek.com> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> Subject: Re: [Ltru] RFC 2277 - considerations To: Martin Duerst X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7BIT Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > > RFC 2277 says: "This document uses the term "charset" to mean a set of > > rules for mapping from a sequence of octets to a sequence of characters, > > such as the combination of a coded character set and a character encoding > > scheme; this is also what is used as an identifier in MIME "charset=" > > parameters, and registered in the IANA charset registry [REG]. (Note that > > this is NOT a term used by other standards bodies, such as ISO).". > > The point is that if the term is not used elsewhere, it may mean that the > > concept is adapted to the network dynamic environment and others are less > > or not. It charset=encording_scheme+character_set. > The term 'charset' got to where it is because when the MIME spec was created, > the people creating it were thinking in terms of 7-bit and 8-bit encodings, > and in addition just (most probably inconciously) shortened "coded character > set" to "character set". So the term is there mostly by accident. I'm sorry, but this simply isn't true. The term "charset" was carefuly and intentionlly chosen, as was the way the term is defined. The terms "coded character set" and "character encoding scheme" were just as intentionally rejected for use in MIME. And none of this has anything to do with 7bit versus 8bit encoding issues. I won't bother getting into the hows and whys of this choice since it is in no way relevant to the present discussion on this list, but I did want to point out that this position, although often stated, is incorrect. > ... > > But the more I think of them, the more I have difficulty understanding > > what the "script" notion, introduced in the Draft, brings in addition to > > the charsets: it belongs to it. > There is some connection, in that many "charset"s only encode one script, > or to be more precise, one script + basic ASCII + some symbols. > But there are some important "charset"s (in particular UTF-8 and > UTF-16,...) where this doesn't apply. Also, there are many other > encodings that contain multiple scripts (e.g. you can write > Greek with iso-2022-jp, and so on). And since the trend is (hopefully) towards using all-inclusive charsets like utf-8, the ability to determine script from the charset label alone, which as you say never worked all that well, is going to disappear over time. OTOH, as things coalesce around Unicode (irrespective of encoding), the need to know lots of charsets in order to dig script information out of the actual content is going to decrease. > > I therefore tend to think the "script" information is to be located in > > the charset tag. > The Web, email, and a lot of other things have worked extremely well without > script information in charset tags, and I don't see why this would not > continue. Absolutely. Charsets were carefully defined to provide the information necessary to display or process a given object. It is very intentionally NOT defined to be a label describing the specific content of a particular document. > > I suppose they are able to understand UTF-8.latin as UTF-8 and that > > legacy is transparent? > Definitely not. For language tags, quite a few applications understand > subtag-based prefixes, as the specs have been defined with subtags in mind > from the start. And those which do not at least ignore subtags are therefore broken. For charsets, they do not. Charsets do not have and > never had subtags. Absolutely. And moreover, the rules for what constitutes a "charset" are intentionally pretty narrow, so as to prevent creep of stuff into charset-space that properly belongs elsewhere. (Sadly, there was a period during which the rules weren't being properly applied to the charset registration process, so there is some amount of cruft in the registry.) Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 09 18:53:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVH8A-00011F-M7; Mon, 09 May 2005 18:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVH88-00011A-G9 for ltru@megatron.ietf.org; Mon, 09 May 2005 18:53:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22279 for ; Mon, 9 May 2005 18:53:37 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVHNK-0000Ik-I5 for ltru@ietf.org; Mon, 09 May 2005 19:09:23 -0400 Received: from lns-p19-1-idf-82-251-88-88.adsl.proxad.net ([82.251.88.88] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVH7s-0003XR-KS; Mon, 09 May 2005 15:53:25 -0700 Message-Id: <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 00:53:22 +0200 To: ned.freed@mrochek.com, Martin Duerst From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] RFC 2277 - considerations In-Reply-To: <01LO1QSCZ7S800004T@mauve.mrochek.com> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.2 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1574770498==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1574770498== Content-Type: multipart/alternative; boundary="=====================_62015393==.ALT" --=====================_62015393==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Ned, I thank you to confirm the definition of the charset, as including two information: - coded character set: with the repertoire ISO 10646 as a default - character encoding scheme: with UTF-8 as a default. is a stable and well accepted matter. This means that one can build from here. At 16:23 09/05/2005, ned.freed@mrochek.com wrote: >> > But the more I think of them, the more I have difficulty understanding >> > what the "script" notion, introduced in the Draft, brings in addition to >> > the charsets: it belongs to it. > >>There is some connection, in that many "charset"s only encode one script, >>or to be more precise, one script + basic ASCII + some symbols. >>But there are some important "charset"s (in particular UTF-8 and >>UTF-16,...) where this doesn't apply. >>Also, there are many other >>encodings that contain multiple scripts (e.g. you can write >>Greek with iso-2022-jp, and so on). > >And since the trend is (hopefully) towards using all-inclusive charsets like >utf-8, Yeap. Using a default all-inclusive charsets permits define easily specialised charsets. Scripts.txt (if correct?) documents the ISO 15924 based charsets. >the ability to determine script from the charset label alone, which as >you say never worked all that well, is going to disappear over time. OTOH, as >things coalesce around Unicode (irrespective of encoding), the need to know >lots of charsets in order to dig script information out of the actual content >is going to decrease. Let not confuse standardisation with uniformisation. The strength of ISO 10646 is to permit an unlimited number of charsets without problem. ISO 15924 gives the names of 102 of them. But there are much more. >> > I therefore tend to think the "script" information is to be located in >> > the charset tag. > >>The Web, email, and a lot of other things have worked extremely well without >>script information in charset tags, and I don't see why this would not >>continue. > >Absolutely. Charsets were carefully defined to provide the information >necessary to display or process a given object. It is very intentionally >NOT defined to be a label describing the specific content of a particular >document. Correct. Languages and contents are orthogonal to layout. We have a good example with IDN Tables and the anti-phishing lists discussed on the IDN list. They define charsets. The ietf-languages@alvestrand.no list and RFC 3066 bis, refuse to discuss IDNs however the DNS is affected by the Draft. This is because scripts do not belong to RFC 3066 but to RFC 2277. >> > I suppose they are able to understand UTF-8.latin as UTF-8 and that >> > legacy is transparent? > >>Definitely not. For language tags, quite a few applications understand >>subtag-based prefixes, as the specs have been defined with subtags in mind >>from the start. > >And those which do not at least ignore subtags are therefore broken. We will then have to use registered charsets UTF-8-XXX. It calls for a list of registered charsets. But subtags will be necessary anyway for 3rd level IDNs, to filter out the code points used for phishing. They will be used by some applications. >For charsets, they do not. Charsets do not have and >>never had subtags. > >Absolutely. And moreover, the rules for what constitutes a "charset" are >intentionally pretty narrow, so as to prevent creep of stuff into >charset-space >that properly belongs elsewhere. Right. This is what is good: this is clean. No confusion as trying to locate the information in the langtag. >(Sadly, there was a period during which the rules weren't being properly >applied to the charset registration process, so there is some amount of >cruft in the registry.) The Unicode scripts may not fully match ISO 15924, I quote Mark Davis (http://www.unicode.org/reports/tr24/tr24-7.html) : "In some cases the match between these script values and the ISO 15924 codes is not precise, because the goals are somewhat different. ISO 15924 is aimed primarily at the bibliographic identification of scripts; consequently it occasionally identifies varieties of scripts that may be useful for book cataloging, but which are not considered distinct scripts in the Unicode Standard. For example, ISO 15924 has separate script codes for the Fraktur and Gaelic varieties of the Latin script. Where there are no corresponding ISO 15924 codes, the private use ones starting with Q are used." However, Mark continues "Such values are likely to change in the future. In such a case, the Q-names will be retained as aliases in the [PropValue] for backwards compatibility.". So, we may expect that at the end of the day, Unicode script.txt will exactly define the ISO 15924 described UTF-8 charsets ("partitions" of the UCS in Unicode wording). I therefore have some difficulty to understand why we should discuss non content oriented scripts info within content oriented langtags (while they could not support the content oriented referent/style info?) while users are fully able to understand, chose and document the 102 charsets (i.e. a 102x102 multilingual matrix): UTF-8-ARAB UTF-8-ARMN UTF-8-BALI UTF-8-BATK UTF-8-BENG UTF-8-BLIS UTF-8-BOPO UTF-8-BRAH UTF-8-BRAI UTF-8-BUGI UTF-8-BUHD UTF-8-CANS UTF-8-CHAM UTF-8-CHER UTF-8-CIRT UTF-8-COPT UTF-8-CPRT UTF-8-CYRL UTF-8-CYRS UTF-8-DEVA UTF-8-DSRT UTF-8-EGYD UTF-8-EGYH UTF-8-EGYP UTF-8-ETHI UTF-8-GEOK UTF-8-GEOR UTF-8-GLAG UTF-8-GOTH UTF-8-GREK UTF-8-GUJR UTF-8-GURU UTF-8-HANG UTF-8-HANI UTF-8-HANO UTF-8-HANS UTF-8-HANT UTF-8-HEBR UTF-8-HIRA UTF-8-HMNG UTF-8-HRKT UTF-8-HUNG UTF-8-INDS UTF-8-ITAL UTF-8-JAVA UTF-8-KALI UTF-8-KANA UTF-8-KHAR UTF-8-KHMR UTF-8-KNDA UTF-8-LAOO UTF-8-LATF UTF-8-LATG UTF-8-LATN UTF-8-LEPC UTF-8-LIMB UTF-8-LINA UTF-8-LINB UTF-8-MAND UTF-8-MAYA UTF-8-MERO UTF-8-MLYN UTF-8-MONG UTF-8-MYMR UTF-8-NKOO UTF-8-OGAM UTF-8-ORKH UTF-8-ORYA UTF-8-OSMA UTF-8-PERM UTF-8-PHAG UTF-8-PHNX UTF-8-PLRD UTF-8-QAAA UTF-8-QABX UTF-8-RORO UTF-8-RUNR UTF-8-SARA UTF-8-SHAW UTF-8-SINH UTF-8-SYLO UTF-8-SYRC UTF-8-SYRE UTF-8-SYRJ UTF-8-SYRN UTF-8-TAGB UTF-8-TALE UTF-8-TALU UTF-8-TAML UTF-8-TELU UTF-8-TENG UTF-8-TFNG UTF-8-TGLG UTF-8-THAA UTF-8-THAI UTF-8-TIBT UTF-8-UGAR UTF-8-VAII UTF-8-VISP UTF-8-XPEO UTF-8-XSUX UTF-8-YIII which have no problem of default, implied, etc. ? jfc --=====================_62015393==.ALT Content-Type: text/html; charset="us-ascii" Dear Ned,
I thank you to confirm the definition of the charset, as including two information:
- coded character set: with the repertoire ISO 10646 as a default
- character encoding scheme: with UTF-8 as a default.
is a stable and well accepted matter.

This means that one can build from here.

At 16:23 09/05/2005, ned.freed@mrochek.com wrote:
> But the more I think of them,  the more I have difficulty understanding
> what the "script" notion, introduced in the Draft, brings in addition to
> the charsets: it belongs to it.

There is some connection, in that many "charset"s only encode one script,
or to be more precise, one script + basic ASCII + some symbols.
But there are some important "charset"s (in particular UTF-8 and
UTF-16,...) where this doesn't apply.
Also, there are many other
encodings that contain multiple scripts (e.g. you can write
Greek with iso-2022-jp, and so on).

And since the trend is (hopefully) towards using all-inclusive charsets like
utf-8,

Yeap. Using a default all-inclusive charsets permits define easily specialised charsets. Scripts.txt (if correct?) documents the ISO 15924 based charsets.

the ability to determine script from the charset label alone, which as
you say never worked all that well, is going to disappear over time. OTOH, as
things coalesce around Unicode (irrespective of encoding), the need to know
lots of charsets in order to dig script information out of the actual content
is going to decrease.

Let not confuse standardisation with uniformisation. The strength of ISO 10646 is to permit an unlimited number of charsets without problem. ISO 15924 gives the names of 102 of them. But there are much more.

> I therefore tend to think the "script" information is to be located in
> the charset tag.

The Web, email, and a lot of other things have worked extremely well without
script information in charset tags, and I don't see why this would not
continue.

Absolutely. Charsets were carefully defined to provide the information necessary to display or process a given object. It is very intentionally NOT defined to be a label describing the specific content of a particular document.

Correct. Languages and contents are orthogonal to layout.  We have a good example with IDN Tables and the anti-phishing lists discussed on the IDN list. They define charsets. The ietf-languages@alvestrand.no list and RFC 3066 bis, refuse to discuss IDNs however the DNS is affected by  the Draft.

This is because scripts do not belong to RFC 3066 but to RFC 2277.

> I suppose they are able to understand UTF-8.latin as UTF-8 and that
> legacy is transparent?

Definitely not. For language tags, quite a few applications understand
subtag-based prefixes, as the specs have been defined with subtags in mind
from the start.

And those which do not at least ignore subtags are therefore broken.

We will then have to use registered charsets UTF-8-XXX. It calls for a list of registered charsets. But subtags will be necessary anyway for 3rd level IDNs, to filter out the code points used for phishing. They will be used by some applications.

For charsets, they do not. Charsets do not have and
never had subtags.

Absolutely. And moreover, the rules for what constitutes a "charset" are
intentionally pretty narrow, so as to prevent creep of stuff into charset-space
that properly belongs elsewhere.

Right. This is what is good: this is clean. No confusion as trying to locate the information in the langtag.

(Sadly, there was a period during which the rules weren't being properly applied to the charset registration process, so there is some amount of cruft in the registry.)

The Unicode scripts may not fully match ISO 15924, I quote Mark Davis ( http://www.unicode.org/reports/tr24/tr24-7.html) : "In some cases the match between these script values and the ISO 15924 codes is not precise, because the goals are somewhat different. ISO 15924 is aimed primarily at the bibliographic identification of scripts; consequently it occasionally identifies varieties of scripts that may be useful for book cataloging, but which are not considered distinct scripts in the Unicode Standard. For example, ISO 15924 has separate script codes for the Fraktur and Gaelic varieties of the Latin script. Where there are no corresponding ISO 15924 codes, the private use ones starting with Q are used."

However, Mark continues "Such values are likely to change in the future. In such a case, the Q-names will be retained as aliases in the [PropValue] for backwards compatibility.".

So, we may expect that at the end of the day, Unicode script.txt will exactly define the ISO 15924 described UTF-8 charsets ("partitions" of the UCS in Unicode wording).

I therefore have some difficulty to understand why we should discuss non content oriented scripts info within content oriented langtags (while they could not support the content oriented referent/style info?) while users are fully able to understand, chose and document the 102 charsets (i.e. a 102x102 multilingual matrix):

UTF-8-ARAB
UTF-8-ARMN
UTF-8-BALI
UTF-8-BATK
UTF-8-BENG
UTF-8-BLIS
UTF-8-BOPO
UTF-8-BRAH
UTF-8-BRAI
UTF-8-BUGI
UTF-8-BUHD
UTF-8-CANS
UTF-8-CHAM
UTF-8-CHER
UTF-8-CIRT
UTF-8-COPT
UTF-8-CPRT
UTF-8-CYRL
UTF-8-CYRS
UTF-8-DEVA
UTF-8-DSRT
UTF-8-EGYD
UTF-8-EGYH
UTF-8-EGYP
UTF-8-ETHI
UTF-8-GEOK
UTF-8-GEOR
UTF-8-GLAG
UTF-8-GOTH
UTF-8-GREK
UTF-8-GUJR
UTF-8-GURU
UTF-8-HANG
UTF-8-HANI
UTF-8-HANO
UTF-8-HANS
UTF-8-HANT
UTF-8-HEBR
UTF-8-HIRA
UTF-8-HMNG
UTF-8-HRKT
UTF-8-HUNG
UTF-8-INDS
UTF-8-ITAL
UTF-8-JAVA
UTF-8-KALI
UTF-8-KANA
UTF-8-KHAR
UTF-8-KHMR
UTF-8-KNDA
UTF-8-LAOO
UTF-8-LATF
UTF-8-LATG
UTF-8-LATN
UTF-8-LEPC
UTF-8-LIMB
UTF-8-LINA
UTF-8-LINB
UTF-8-MAND
UTF-8-MAYA
UTF-8-MERO
UTF-8-MLYN
UTF-8-MONG
UTF-8-MYMR
UTF-8-NKOO
UTF-8-OGAM
UTF-8-ORKH
UTF-8-ORYA
UTF-8-OSMA
UTF-8-PERM
UTF-8-PHAG
UTF-8-PHNX
UTF-8-PLRD
UTF-8-QAAA
UTF-8-QABX
UTF-8-RORO
UTF-8-RUNR
UTF-8-SARA
UTF-8-SHAW
UTF-8-SINH
UTF-8-SYLO
UTF-8-SYRC
UTF-8-SYRE
UTF-8-SYRJ
UTF-8-SYRN
UTF-8-TAGB
UTF-8-TALE
UTF-8-TALU
UTF-8-TAML
UTF-8-TELU
UTF-8-TENG
UTF-8-TFNG
UTF-8-TGLG
UTF-8-THAA
UTF-8-THAI
UTF-8-TIBT
UTF-8-UGAR
UTF-8-VAII
UTF-8-VISP
UTF-8-XPEO
UTF-8-XSUX
UTF-8-YIII

which have no problem of default, implied, etc. ?

jfc --=====================_62015393==.ALT-- --===============1574770498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1574770498==-- From ltru-bounces@lists.ietf.org Mon May 09 19:38:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVHpH-00084s-Ud; Mon, 09 May 2005 19:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVHpG-00084n-P0 for ltru@megatron.ietf.org; Mon, 09 May 2005 19:38:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27574 for ; Mon, 9 May 2005 19:38:09 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVI4Q-0002Jj-1d for ltru@ietf.org; Mon, 09 May 2005 19:53:55 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVHp9-0001KI-00 for ltru@ietf.org; Mon, 09 May 2005 16:38:07 -0700 Message-ID: <002a01c55815$27558240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com><6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp><01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> Subject: Re: [Ltru] RFC 2277 - considerations Date: Fri, 13 May 2005 16:40:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "JFC (Jefsey) Morfin" > To: ; "Martin Duerst" > Cc: "LTRU Working Group" > Sent: Monday, May 09, 2005 3:53 PM > Subject: Re: [Ltru] RFC 2277 - considerations ... > This is because scripts do not belong to RFC 3066 but to RFC 2277. ... Our charter clearly directs us to address the question of script identification in our update to 3066. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 09 21:27:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVJXR-0002di-Iy; Mon, 09 May 2005 21:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVJXP-0002da-DU for ltru@megatron.ietf.org; Mon, 09 May 2005 21:27:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05899 for ; Mon, 9 May 2005 21:27:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVJmc-0005tH-7f for ltru@ietf.org; Mon, 09 May 2005 21:43:39 -0400 Received: from lns-p19-1-idf-82-251-88-88.adsl.proxad.net ([82.251.88.88] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVJXL-0005EM-08; Mon, 09 May 2005 18:27:51 -0700 Message-Id: <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 03:27:46 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] RFC 2277 - considerations In-Reply-To: <002a01c55815$27558240$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ned.freed@mrochek.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 01:40 14/05/2005, Randy Presuhn wrote: >Hi - > > > From: "JFC (Jefsey) Morfin" > > To: ; "Martin Duerst" > > Cc: "LTRU Working Group" > > Sent: Monday, May 09, 2005 3:53 PM > > Subject: Re: [Ltru] RFC 2277 - considerations >... > > This is because scripts do not belong to RFC 3066 but to RFC 2277. >... > >Our charter clearly directs us to address the question of script >identification >in our update to 3066. Hi! Randy, Glad you noted that, since the review of the Charter has not been carried yet! The Charter says: "- For extensibility, it is expected that the document will describe how generative mechanisms could use ISO 15924 and UN M.49 codes without explicit registration of all combinations. The current registry contains pairs like uz-Cyrl/uz-Latn and sr-Cyrl/sr-Latn, but RFC 3066 contains no general mechanism or guidance for how scripts should be incorporated into language tags; this replacement document is expected to provide such a mechanism." 1. "extensibility" is a W3C key requirement, where IETF uses more usually "scalability". From what the authors have documented (their initial Draft being the Bible of this WG) they are interested in a single need (other concerns [DNS, Java, OPES, LDAP, etc.] being out of scope) which is a problem of the W3C about XML Addison fully documented. This problem was presented as resulting from the langtag libraries limitations. There may be tens of existing or future applications. IETF being mainly interested in network architecture, I did not pay a special attention, trusting Addison; and trusting Mark when he said CLDR has no problem (but never addressed my questions). My interest is in a multilingual framework, which can be adapted to particular needs, as per the Charter. 2. I now see that that quoted particular problem is not related to the langtags librairies, but to the limitations of the charsets librairies. And that the idea is to use the langtag to carry a payload which does not belong to it, as specified by a previous RFC. This does not change much in terms of architectural framework, since the langtag can be used as a data base for everything missing elsewhere. But it changes the way we are to study and address the Charter request. This is an RFC 2130 violation and an absurd request. Full stop. But it is necessary to address if to an absurd need. This must be made clear to all, if to reach a consensus, and why it is not possible to do in the normal way. Otherwise no one will ever understand why, when the charset, the language, the region, the referent and the style are at least necessary to document the linguistic aspects of a document (together with a reference to the date of generation to know the used ersion of the standard), you want to have two possibly different or even conflicting charsets defined and no referent and no style. Very interesting. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 09 22:03:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVK6G-00016D-Nz; Mon, 09 May 2005 22:03:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVK6F-000168-GG for ltru@megatron.ietf.org; Mon, 09 May 2005 22:03:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08427 for ; Mon, 9 May 2005 22:03:53 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVKLR-00074n-3b for ltru@ietf.org; Mon, 09 May 2005 22:19:39 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVK6A-00038G-00 for ltru@ietf.org; Mon, 09 May 2005 19:03:50 -0700 Message-ID: <001001c55829$830b81c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> Subject: Re: [Ltru] RFC 2277 - considerations Date: Fri, 13 May 2005 19:05:46 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Could you *please* identify the *specific* text in the draft you would like to add / remove / replace? The IESG reviewed our charter before approving it. You even commented on the proposed charter while the IESG was reviewing it, so if anything was unclear, you certainly had opportunity to make your view heard at that time. This working group's job is to produce two documents, as spelled out in the charter. You are the only participant who seems to have any difficulty understanding the charter. No one else on this mailing list has expressed any confusion as to what our deliverables are. Given the depth and breadth of expertise of the participants, I'm willing to take their lack of confusion as a sign that we know what we need to do. Randy > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" ; "LTRU Working Group" > Cc: ; "Martin Duerst" > Sent: Monday, May 09, 2005 6:27 PM > Subject: Re: [Ltru] RFC 2277 - considerations > > At 01:40 14/05/2005, Randy Presuhn wrote: > >Hi - > > > > > From: "JFC (Jefsey) Morfin" > > > To: ; "Martin Duerst" > > > Cc: "LTRU Working Group" > > > Sent: Monday, May 09, 2005 3:53 PM > > > Subject: Re: [Ltru] RFC 2277 - considerations > >... > > > This is because scripts do not belong to RFC 3066 but to RFC 2277. > >... > > > >Our charter clearly directs us to address the question of script > >identification > >in our update to 3066. > > Hi! Randy, > Glad you noted that, since the review of the Charter has not been carried yet! > > The Charter says: > "- For extensibility, it is expected that the document will describe how > generative mechanisms could use ISO 15924 and UN M.49 codes without > explicit registration of all combinations. The current registry contains > pairs like uz-Cyrl/uz-Latn and sr-Cyrl/sr-Latn, but RFC 3066 contains no > general mechanism or guidance for how scripts should be incorporated into > language tags; this replacement document is expected to provide such a > mechanism." > > 1. "extensibility" is a W3C key requirement, where IETF uses more usually > "scalability". From what the authors have documented (their initial Draft > being the Bible of this WG) they are interested in a single need (other > concerns [DNS, Java, OPES, LDAP, etc.] being out of scope) which is a > problem of the W3C about XML Addison fully documented. This problem was > presented as resulting from the langtag libraries limitations. There may be > tens of existing or future applications. IETF being mainly interested in > network architecture, I did not pay a special attention, trusting Addison; > and trusting Mark when he said CLDR has no problem (but never addressed my > questions). My interest is in a multilingual framework, which can be > adapted to particular needs, as per the Charter. > > 2. I now see that that quoted particular problem is not related to the > langtags librairies, but to the limitations of the charsets librairies. And > that the idea is to use the langtag to carry a payload which does not > belong to it, as specified by a previous RFC. > > This does not change much in terms of architectural framework, since the > langtag can be used as a data base for everything missing elsewhere. But it > changes the way we are to study and address the Charter request. This is an > RFC 2130 violation and an absurd request. Full stop. But it is necessary to > address if to an absurd need. > > This must be made clear to all, if to reach a consensus, and why it is not > possible to do in the normal way. Otherwise no one will ever understand > why, when the charset, the language, the region, the referent and the style > are at least necessary to document the linguistic aspects of a document > (together with a reference to the date of generation to know the used > ersion of the standard), you want to have two possibly different or even > conflicting charsets defined and no referent and no style. > > Very interesting. > jfc > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:25:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOBE-0006HU-Iu; Tue, 10 May 2005 02:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOBD-0006HP-3v for ltru@megatron.ietf.org; Tue, 10 May 2005 02:25:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17842 for ; Tue, 10 May 2005 02:25:16 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOQR-0008HB-8A for ltru@ietf.org; Tue, 10 May 2005 02:41:04 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOB7-00044p-00 for ltru@ietf.org; Mon, 09 May 2005 23:25:14 -0700 Message-ID: <005901c5584e$0187d660$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:27:25 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Ltru] Another batch of ltru tickets in RT X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've entered another batch of tickets into the RT system. Public access to the system is via an account named "ietf" with password "ietf" at the URL https://rt.psg.com There are separate queues for the ltru-registry and ltru-matching drafts. Several of these items I've entered with an initial status of "rejected" because I think the mailing list discussion has clearly indicated that the proposal was not accepted. If you think I've misread or misunderstood, *please* speak up now and I'll happily re-open those items for further discussion. If something has been overtaken by events or made moot by other changes (most of these comments were with respect to -00), let me know. Likewise, if you think we do have a consensus resolution for an item, let me know so we can mark it "resolved". In any case, *PLEASE* include the issue number if you're posting regarding an issue, and *don't* use issue threads for other topics. I'll forward each of the issues to this list, so you can reply to the forwarded messages for followups. This is an unusually verbose mailing list - sorting through messages is hard enough as it is, so *PLEASE* keep the issue numbers. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:27:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOCx-0006Wq-Uq; Tue, 10 May 2005 02:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOCv-0006Wi-HO for ltru@megatron.ietf.org; Tue, 10 May 2005 02:27:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18628 for ; Tue, 10 May 2005 02:27:04 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOSA-0008Ii-V4 for ltru@ietf.org; Tue, 10 May 2005 02:42:52 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOCt-0004cH-00 for ltru@ietf.org; Mon, 09 May 2005 23:27:03 -0700 Message-ID: <005e01c5584e$46f853a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:29:25 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] [psg.com #933] Java support X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - In the mail thread beginning with http://www.ietf.org/mail-archive/web/ltru/current/msg01348.html the question was raised regarding compatibility of the structure of language tags with Java. Subsequent discussion led to the conclusion that no action was needed, that Java locales and language tags are very different things. Consequently, this item is marked "rejected" Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:30:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOFn-0006yv-FH; Tue, 10 May 2005 02:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOFl-0006yG-TB for ltru@megatron.ietf.org; Tue, 10 May 2005 02:30:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18939 for ; Tue, 10 May 2005 02:30:00 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOV1-0008RW-Ad for ltru@ietf.org; Tue, 10 May 2005 02:45:48 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOFj-0005BT-00 for ltru@ietf.org; Mon, 09 May 2005 23:29:59 -0700 Message-ID: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:32:23 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] [psg.com #934] repertoire for descriptions in registry entries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This thread started with message http://www.ietf.org/mail-archive/web/ltru/current/msg01321.html The two key components of this problem are: (1) whether to limit the repertoire that can be used (a) to basic latin (b) latin-1 (2) whether to "correct" data brought over from ISO, such as the use of an incorrect character reference for glottal stop. I don't see a clear consensus on this item yet. Now that we've had some "think time", would someone care to make a proposal? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:31:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOHK-00077Q-VN; Tue, 10 May 2005 02:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOHJ-00077L-LI for ltru@megatron.ietf.org; Tue, 10 May 2005 02:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19111 for ; Tue, 10 May 2005 02:31:36 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOWa-00006a-2S for ltru@ietf.org; Tue, 10 May 2005 02:47:24 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOHH-0005fq-00 for ltru@ietf.org; Mon, 09 May 2005 23:31:35 -0700 Message-ID: <006801c5584e$ea01b140$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:33:59 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] [psg.com #935] is the word "indicate" in the abstract unclear? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This was raised as comments #1 and #4 in http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html No one else had any trouble with the word "indicate" in the abstract of the -00- i-d, and no replacement text was agreed, so no change appears to be needed. Consequently, I've marked this one "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:32:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOIT-0007SF-ER; Tue, 10 May 2005 02:32:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOIR-0007S9-K6 for ltru@megatron.ietf.org; Tue, 10 May 2005 02:32:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19237 for ; Tue, 10 May 2005 02:32:46 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOXi-000082-2q for ltru@ietf.org; Tue, 10 May 2005 02:48:34 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOIQ-00060l-00 for ltru@ietf.org; Mon, 09 May 2005 23:32:46 -0700 Message-ID: <006d01c5584f$152787a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:35:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] [psg.com #936] is the phrase "information object" in the abstract unclear? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This was raised in comment #2 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html No one else had any problem with the phrase "information object", and no alternative proposal was agreed, so I've marked this item as "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:33:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOJb-0007aF-Rx; Tue, 10 May 2005 02:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOJa-0007aA-RJ for ltru@megatron.ietf.org; Tue, 10 May 2005 02:33:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19399 for ; Tue, 10 May 2005 02:33:57 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOYq-0000Fd-Bo for ltru@ietf.org; Tue, 10 May 2005 02:49:45 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOJY-00069i-00 for ltru@ietf.org; Mon, 09 May 2005 23:33:56 -0700 Message-ID: <007201c5584f$3eab46c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:36:21 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] [psg.com #937] is the word "interchange" in the abstract unclear? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment #3 in http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html asks whether the word "interchange" in the abstract of the -00 registry draft is unclear. No one else on the WG mailing list had a problem with the word, and no proposal for an alternative wording found support, so I've marked this item as "rejected". Randy ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:35:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOLB-0007gA-Ci; Tue, 10 May 2005 02:35:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOL9-0007g4-K0 for ltru@megatron.ietf.org; Tue, 10 May 2005 02:35:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19542 for ; Tue, 10 May 2005 02:35:34 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOaQ-0000H6-45 for ltru@ietf.org; Tue, 10 May 2005 02:51:22 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOL8-0006W2-00 for ltru@ietf.org; Mon, 09 May 2005 23:35:34 -0700 Message-ID: <007701c5584f$76cf87a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:37:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] [psg.com #938] should introduction allude to intended bcp status? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - The question of whether the introduction to the registry draft should allude to its intended BCP status was raised in comment #9 in http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html There was no support on the mailing list for this proposed change, so the proposal is marked "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:37:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOMi-0007rW-Hy; Tue, 10 May 2005 02:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOMh-0007rR-CN for ltru@megatron.ietf.org; Tue, 10 May 2005 02:37:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19609 for ; Tue, 10 May 2005 02:37:10 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVObw-0000Oe-RW for ltru@ietf.org; Tue, 10 May 2005 02:52:58 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOMd-0006qY-00 for ltru@ietf.org; Mon, 09 May 2005 23:37:07 -0700 Message-ID: <007c01c5584f$b04ca1c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:39:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] [psg.com #939] explain difference between tags and labels X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment #10 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html requested an explanation of the difference between the words "tag" and "label". No one else seems to have trouble with these words, and no replacement text was proposed, so I've marked this item "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:40:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOQL-0008IA-R2; Tue, 10 May 2005 02:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOQL-0008I5-6o for ltru@megatron.ietf.org; Tue, 10 May 2005 02:40:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19793 for ; Tue, 10 May 2005 02:40:56 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOfa-0000YE-Pp for ltru@ietf.org; Tue, 10 May 2005 02:56:44 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOQI-0007eq-00 for ltru@ietf.org; Mon, 09 May 2005 23:40:54 -0700 Message-ID: <009101c55850$35ad3960$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:43:13 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] [psg.com #940] is the word "recognized" unclear in the syntax section? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This question was issue number 11 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html There was no support on the mailing list for a change, so this item is marked "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:43:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOSm-0000Qj-Mk; Tue, 10 May 2005 02:43:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOSk-0000Qd-JU for ltru@megatron.ietf.org; Tue, 10 May 2005 02:43:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20034 for ; Tue, 10 May 2005 02:43:25 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOi1-0000gI-5g for ltru@ietf.org; Tue, 10 May 2005 02:59:13 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOSh-0000Eg-00 for ltru@ietf.org; Mon, 09 May 2005 23:43:23 -0700 Message-ID: <009601c55850$9021f660$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:45:45 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] [psg.com #941] determining currency of registry versions X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This issue was raised in item 12 in http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html A mechanism describing how one determines whether a registry version is "current" needs to be spelled out. This is related to the charter requirement "For accessibility, it is to provide a mechanism for easily determining whether a particular subtag is valid as of a given date, without onerous reconstruction of the state of the underlying standard as of that time." This is also somewhat related to the charter requirement "It is expected to specify a mechanism for easily identifying the role of each subtag in the language tag, so that, for example, whenever a script code or country code is present in the tag it can be extracted, even without access to a current version of the registry." (This last phrase naturally leads one to ask the question, "how do I know whether what I have is current.") Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:45:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOUk-0000Ym-UA; Tue, 10 May 2005 02:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOTo-0000TC-H9 for ltru@megatron.ietf.org; Tue, 10 May 2005 02:44:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20139 for ; Tue, 10 May 2005 02:44:31 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOj5-0000hi-4x for ltru@ietf.org; Tue, 10 May 2005 03:00:19 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOTn-0000NS-00 for ltru@ietf.org; Mon, 09 May 2005 23:44:31 -0700 Message-ID: <009b01c55850$b97afc00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:46:57 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] [psg.com #942] clarify advice on use of subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment #13 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html requests clarification of the advice on the use of subtags in section 2.1.1 (of draft -00-) Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:47:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOWF-0000ec-0f; Tue, 10 May 2005 02:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOWD-0000eX-9T for ltru@megatron.ietf.org; Tue, 10 May 2005 02:47:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20348 for ; Tue, 10 May 2005 02:46:59 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOlT-0000rl-OA for ltru@ietf.org; Tue, 10 May 2005 03:02:48 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOWB-0000qd-00 for ltru@ietf.org; Mon, 09 May 2005 23:46:59 -0700 Message-ID: <00a401c55851$0fe83a80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:48:39 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] [psg.com #943] number of subtags SHOULD be limited to four X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment #14 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html requests that there should be language stating that the number of subtags SHOULD be limited to four. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:47:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOWR-0000gf-5v; Tue, 10 May 2005 02:47:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOWQ-0000ga-Aj for ltru@megatron.ietf.org; Tue, 10 May 2005 02:47:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20403 for ; Tue, 10 May 2005 02:47:13 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOlg-0000s4-Sc for ltru@ietf.org; Tue, 10 May 2005 03:03:01 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOWO-0000wW-00 for ltru@ietf.org; Mon, 09 May 2005 23:47:12 -0700 Message-ID: <00a501c55851$196e9540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:49:37 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] [psg.com #944] MAY a conformant implementation impose length constraints? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment #15 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html asks whether an implementation that imposes length constraints would still be considered conformant, and, if so, what constraints would be permissible. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:49:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOYi-0000r7-RU; Tue, 10 May 2005 02:49:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOYh-0000r2-KE for ltru@megatron.ietf.org; Tue, 10 May 2005 02:49:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20706 for ; Tue, 10 May 2005 02:49:34 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOny-00010i-7A for ltru@ietf.org; Tue, 10 May 2005 03:05:22 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOYf-0001IH-00 for ltru@ietf.org; Mon, 09 May 2005 23:49:33 -0700 Message-ID: <00b201c55851$6d03fba0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:51:58 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] [psg.com #945] use "." to separate subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment #16 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html suggests that "." should be used as a separater. Subsequent discussion found no support for and much opposition to this proposal. A detailed response is in message http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html Consequently, I've marked this item "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:51:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOaU-0000zo-8L; Tue, 10 May 2005 02:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOaT-0000zj-Ez for ltru@megatron.ietf.org; Tue, 10 May 2005 02:51:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20897 for ; Tue, 10 May 2005 02:51:24 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOpk-00012m-4q for ltru@ietf.org; Tue, 10 May 2005 03:07:12 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOaS-0001ie-00 for ltru@ietf.org; Mon, 09 May 2005 23:51:24 -0700 Message-ID: <00b701c55851$adefdb20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:53:47 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] [psg.com #946] use of both length and position to identify subtag problematic X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment #17 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html states that the use of both length and position to identify subtags would be problematic. A response to this concern is in message http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html No alternative garnered significant support. Can we mark this one "rejected"? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:53:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOcw-0002Kg-L7; Tue, 10 May 2005 02:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOcu-0002JL-IH for ltru@megatron.ietf.org; Tue, 10 May 2005 02:53:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21228 for ; Tue, 10 May 2005 02:53:55 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOsA-0001Df-8s for ltru@ietf.org; Tue, 10 May 2005 03:09:43 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOcs-00022g-00 for ltru@ietf.org; Mon, 09 May 2005 23:53:54 -0700 Message-ID: <00bc01c55852$08078400$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:56:18 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] [psg.com #947] is set of possible primary languages too constrained? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment number 18 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html asks whether the set of possible primary languages is too constrained. Message http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html indicates that the question might be based on a misunderstanding; subsequently no changes were agreed in response to this item. I've marked this rejected, ok? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:56:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOfC-0002dz-TM; Tue, 10 May 2005 02:56:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOfB-0002dK-IX for ltru@megatron.ietf.org; Tue, 10 May 2005 02:56:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21345 for ; Tue, 10 May 2005 02:56:16 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOuS-0001M7-4r for ltru@ietf.org; Tue, 10 May 2005 03:12:04 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOf8-0002YL-00 for ltru@ietf.org; Mon, 09 May 2005 23:56:15 -0700 Message-ID: <00cd01c55852$5c2ad280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:58:39 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] [psg.com #948] deprecate two-letter language codes in favor of three-letter ones X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comment number 19 in message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html suggests deprecating two-letter primary language codes in favor of three-letter ones. Discussion of why it is necessary to have both the two- and three-letter codes is in http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html This proposal was withdrawn in message http://www.ietf.org/mail-archive/web/ltru/current/msg00717.html Consequently, I've marked it "rejected." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 02:57:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOgM-0002lo-2K; Tue, 10 May 2005 02:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOgK-0002lQ-Rs for ltru@megatron.ietf.org; Tue, 10 May 2005 02:57:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21400 for ; Tue, 10 May 2005 02:57:26 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOva-0001Nj-Fu for ltru@ietf.org; Tue, 10 May 2005 03:13:14 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVOgI-0002jF-00 for ltru@ietf.org; Mon, 09 May 2005 23:57:26 -0700 Message-ID: <00d201c55852$86e45280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 13 May 2005 23:59:51 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] [psg.com #949] remove three-character limit in sections 2.2.2, 2.2.3 (of -00) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Comments 20 and 21 of message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html both focus on the length constraints in sections 2.2.2 and 2.2.3 of the -00 draft. There is some followup on this question in message http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 06:34:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS4P-0002dR-2C; Tue, 10 May 2005 06:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS4N-0002d6-Pb for ltru@megatron.ietf.org; Tue, 10 May 2005 06:34:32 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05968 for ; Tue, 10 May 2005 06:34:27 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVRvF-0006z2-Nk for ltru@lists.ietf.org; Tue, 10 May 2005 12:25:05 +0200 Received: from 212.82.251.128 ([212.82.251.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 May 2005 12:25:05 +0200 Received: from nobody by 212.82.251.128 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 May 2005 12:25:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 10 May 2005 12:20:45 +0200 Organization: Lines: 16 Message-ID: <42808AFD.3198@xyzzy.claranet.de> References: <00b701c55851$adefdb20$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.128 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #946] use of both length and position to identify subtag problematic X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: [psg.com #946] > Can we mark this one "rejected"? I've found that splitting tags before the hyphen (excl. any stuff introduced by a singleton) results in a set of unique "tokens", and it's possible to identify the type of these "tokens" without noting their former position. With several extlang "tokens", and if the order of extlang "tokens" is significant, it starts to get ugly. If you have a separate ticket for extlang I've no problem with rejecting [psg.com #946] Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 10:03:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVK9-0004cC-Ds; Tue, 10 May 2005 10:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVK5-0004bu-TC for ltru@megatron.ietf.org; Tue, 10 May 2005 10:03:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27821 for ; Tue, 10 May 2005 10:02:56 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVVZP-00024T-TR for ltru@ietf.org; Tue, 10 May 2005 10:18:48 -0400 Received: from lns-p19-1-idf-82-251-88-88.adsl.proxad.net ([82.251.88.88] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVVK3-0004ry-3m; Tue, 10 May 2005 07:02:56 -0700 Message-Id: <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 16:02:51 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] RFC 2277 - considerations In-Reply-To: <001001c55829$830b81c0$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> <001001c55829$830b81c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Randy, it is always a pleasure to repeat the same thing to you. So I will do it again. At 04:05 14/05/2005, Randy Presuhn wrote: >Given the depth and breadth of expertise of the participants, I'm willing >to take their lack of confusion as a sign that we know what we need to do. Never thought a WG was a resume contest, but I suppose I have no problem with that. Now, it would be surprising that people who came for a purpose (which will never be globally consensual, two negative Last Calls), would be confused on what they want to achieve. Those who disagreed but me gave up. >Could you *please* identify the *specific* text in the draft you would >like to add / remove / replace? I thought it was clear to you, since end of December. Remove: the whole draft. Add: the XML oriented parts of the Draft in the second document where they belong, together with a consistent documentation of its filters and working tools (you oddily have no problem to add them to langtag libraries but you cannot add them to charset libraries?), a good explanation of the charset violation needs, a clear assessment/commitment of the resources required from IANA Replace: make BCP 47 an Internet technology (RFC 1591, 1958, 2277, 2301, 3066, etc., etc.) consistent framework for the support of language context identification as one of the Multilingual Internet building blocks, together with others works such: within IETF (OPES, IDN, LDAP, PPP, SNMP, etc.), outside (for the time being) the IETF (those I know of: classes, groups, externets, CRC, ISO 639-X, UNITAG). And let document a consistent IANA external tables and values management consistent or aggregating the current registries. >The IESG reviewed our charter before approving it. IESG will also review the deliverables of this WG before accepting them for a Last Call and then after the Last Call. And during an appeal if they approved it. So would IAB after that if they confirmed. What is the interest to have something which pleases a small score of supporters and is defeated by lack of global consensus? If the problem is a IANA registry conflict please tell us. If the problem is to ascertain the Unicode table vs. ISO 10646 please tell us. If the problem is to make ISO 15924 the center of the world please tell us. If the problem are W3C analysis difficulties please tell us. If the problem is rooted in the CLDR structures please tell us. Your problem is neither to produce a Draft, nor to shut my mouth. Your target is to address a problem. Either it is the one written in the Charter and IMHO its is partly erroneously worded the way you seem to read it. Or it is another one, and I doubt you can solve it if you do not spell it. If it is part of both, let sort it out first. >You even commented on the proposed charter while the IESG was reviewing >it, so if anything was unclear, you certainly had opportunity to make your >view heard at that time. I commented positively on your proposition to have a WG. This is what I asked for early January. I had proposed the creation of a WG-TAGs because this is what I am working on in a much broader scope. I was not opposed on a WG on language and I detailed my conditions a minima. These conditions are not spelled out in the Charter, but since the Charter has been submitted/reviewed to/by the IESG it is mostly consistent with the whole Internet architecture (all the more that it MUST be read in its perspective). >This working group's job is to produce two documents, as spelled out in >the charter. You are the only participant who seems to have any >difficulty understanding the charter. May be I am the only one with a very low IQ? Did you forget one thing, I am also the only one who does not to speak English. That alone should be an alarm for you when addressing a multilingual issue. I am also the only one in various areas of importance to this topic (a ccTLD registry, the founder of the oldest user/operator structure, a former @large panelist, an active contributor to the WSIS process where multilingualism is a priority, etc.). I only think there is a qui pro quo you should have resolved first. You proposed a text with a W3C/Unicode culture, it was read by the IESG with an Internet culture. I read it with another more global network culture. All this makes the Internet, but one has to accept to have a limited methodology. This starts with reviewing what all the participants have read and accept in your text, not to end with it when everyone is gone. You said there were thorny points in the charter. There are. I am not sure you saw them all. I just waited for the list to be calm enough to rise the charset issue. Please understand, as I mentioned it in my response to the Chairs and ADs, I am as everyone else entitled to a Charter review by the WG to make sure I am not wrong, before producing my own Draft. Having a fragmented review of the Charter while most of the people disappointed with the Draft are gone, only delays the whole process and does not help. Neither me, nor the current Draft. >No one else on this mailing list has expressed any confusion as to what >our deliverables are. This is precisely the problem. On such a matter, there should have been much more. This only means they are not here. Language tags, the way authors see them, are a deep change in the Internet architecture. This has lead to the opposition met during the first two last calls. This WG should have started in assessing that change. Its reasons, its implications. debreifing the opposition, not just jumping at an 11th and 12th version of the same proposition with the same text. - They want a change which affects/opposes a consistent corpus RFC. - I see one of the seeds of the response to an urgent market and political demand not addressed until now. Both have to be discussed. Better here than on the general list during the third Last Call, all the more if it is opposed by a short Draft of mine. You just start listing some of the points of my last month review (delay is not on my side) on the management system you chose. Thank you: this will save me the time of listing during the Last Calls all the points I rose which have not been discussed - what would have been poor (I am not sure however you will list them all?). Now they have to be addressed. But not all them are listed and most are listed in a way no one can understand what it refers to without accessing the whole review each time and to figure out where it is. I gave each point a "#" number (there are 55 of them). Why not just to paste them into your system before commenting them? Also, in the follow-up, why to assume people agree with you (and not me) because they did not comment? Think that my draft would use the Charter framework and quotes the concerned RFCs, documenting how to support the XML, DNS, IDNA, OPES, LDAP, PPP, etc. etc. needs (even the non documented ones of CLDR) in the scalable way the Internet has always supported them with success up to now. Discussing the reducing ways others may have proposed over time which have been opposed with that success. Scalable, simple, robust, stable, secure will be the keywords. I could also propose a F2F meeting before the Paris meeting. I would propose people from the MINC, UNESCO, WSIS, Francophonie, etc. to attend. I accept there will be lacks in such a document of mine as I lack inputs from the WG debate on the charter, and I have not the time, the expertise and the interest to became a specialist of all the IETF oddities it should aggregate and consolidate, such as the RFC of Ira McDonnald, and all the times the internationalisation of the ASCII Internet is considered in RFCs. IMHO what you miss is that what you made at stake is the transition from internationalisation to multilingualisation (actually to vernacularisation) - user to user relations, over brain to brain, over end to end. I accept this is beyond what this WG is able to discuss, but this This is _your_ decision in wanting to replace BCP 47. I frankly prefer focusing on the Multilingual Global Network (MGN) - as it should progressively result from our current work, the WSIS, the dialog between ITU, WSIS and the operators efforts (currently engaged). Let be candid: if this WG does not produce a Draft along that lines, the Draft (or eventually an RFC) and the IANA registry will only be a problem to forget. Is that what you really want? Here is what I propose for a serious review of the topic: 1. what I had not time to do it yet: a dump of the whole IETF corpus and a grep on "international" and "lingual" to know which RFC can be affected and which experience has been gathered in there. There are more than you thought in preparing the Charter. 2. to seriously review the problems, starting with those quoted by the charter. What they really mean. What are the architectural implications they may have in an MGN framework. They are not perfect, but they will lead to most of them. 3. what architectural responses they may call for and what this implies on the structures of the contents' containers. 4. _IF_ there are architectural changes (I doubt there are much, as the MGN IMHO concerns higher layers than the end to end architecture) what are they? IMHO they concerns mainly the way to use IPv6, OPES and the DNS due to current implication of the DNS in the architecture of usage and hyperlinks. 5. what is the stable, simple, robust framework the IETF technology should provide to the applications designers. 6. to seriously review the way this can be made supported by IANA and CRCs. And let implement test applications. 7. let discuss how to address the evolutions/trasnsitions possibly implied at a network level. This makes the first document. Then a second document should use that stable foundations to write the specific solution called by the documentation of the charset in the W3C containers and the stabilisation of the XML langtag, its filtering, sorting etc. Another document could be proposed by Unicode (if free of IPRs) to document the CLDR approach, propositions and specific own usage (if any) of this framework. I accept that the expertise of this WG is more oriented towards the second document and I am more interested in the first one. There are two possible responses to that: 1. either to follow my proposition above and make the general list aware of what we plan to discuss. I bet there will be new comers with depth and breadth of expertise in the concerned areas (even if IETF, IAB and IESG is not much aware/motivated in the lingual areas). 2. or to follow the recommendations received on the general list during the Last Call. Let us stop pretending changing BCP 47: let consolidate RFC 3066 as it is today, with its relations to RFC 2277 and 2301, and publish a specific solution for XML. I do not think anyone will oppose this. Only some people will find it odd if you document IETF values violation they may want the IETF/W3C liaison committee to approve. This is the RFC 3066 bis/ter option. The real work will be carried afterward. And your problem will be quickly fixed. This is what I proposed the day we started the WG and to work with the Authors on that. We could be done for a long. Actually the WG was even not necessary. I fully understand this is does not make things simple for you. But you decided that the most complex issue Internet is to face since its inception, and delayed for 20 years, was something simple. It is not. All the best. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 10:42:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVw5-0002kg-I4; Tue, 10 May 2005 10:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVw4-0002kb-5O for ltru@megatron.ietf.org; Tue, 10 May 2005 10:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02493 for ; Tue, 10 May 2005 10:42:10 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVWBN-0004ji-K8 for ltru@ietf.org; Tue, 10 May 2005 10:58:03 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4AEg0T9021850 for ; Tue, 10 May 2005 10:42:00 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4AEfu6d239158 for ; Tue, 10 May 2005 08:42:00 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4AEftDm015360 for ; Tue, 10 May 2005 08:41:55 -0600 Received: from markdavis (sig-9-48-113-204.mts.ibm.com [9.48.113.204]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4AEfsA3015291; Tue, 10 May 2005 08:41:55 -0600 Message-ID: <12d501c5556e$6774ab70$217a3009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <00a401c55851$0fe83a80$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #943] number of subtags SHOULD be limited to four Date: Tue, 10 May 2005 07:41:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j4AEg0T9021850 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Disagree. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Friday, May 13, 2005 23:48 Subject: [Ltru] [psg.com #943] number of subtags SHOULD be limited to fou= r > Hi - > > Comment #14 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > requests that there should be language stating that the number > of subtags SHOULD be limited to four. > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 10:42:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVwF-0002lE-Mg; Tue, 10 May 2005 10:42:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVwE-0002l8-08 for ltru@megatron.ietf.org; Tue, 10 May 2005 10:42:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02506 for ; Tue, 10 May 2005 10:42:19 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVWBX-0004jl-JH for ltru@ietf.org; Tue, 10 May 2005 10:58:12 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4AEgB0c556120 for ; Tue, 10 May 2005 10:42:11 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4AEgA6d259826 for ; Tue, 10 May 2005 08:42:11 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4AEgAPf016424 for ; Tue, 10 May 2005 08:42:10 -0600 Received: from markdavis (sig-9-48-113-204.mts.ibm.com [9.48.113.204]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4AEg96R016333; Tue, 10 May 2005 08:42:10 -0600 Message-ID: <12d601c5556e$703c7120$217a3009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <00b701c55851$adefdb20$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #946] use of both length and position to identifysubtag problematic Date: Tue, 10 May 2005 07:42:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id j4AEgB0c556120 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Agree to reject. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Friday, May 13, 2005 23:53 Subject: [Ltru] [psg.com #946] use of both length and position to identifysubtag problematic > Hi - > > Comment #17 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > states that the use of both length and position to identify > subtags would be problematic. > > A response to this concern is in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > No alternative garnered significant support. > > Can we mark this one "rejected"? > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 10:43:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVxM-0002rz-VS; Tue, 10 May 2005 10:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVxL-0002rm-Fy for ltru@megatron.ietf.org; Tue, 10 May 2005 10:43:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02623 for ; Tue, 10 May 2005 10:43:29 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVWCf-0004td-Jf for ltru@ietf.org; Tue, 10 May 2005 10:59:22 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4AEhK0c589986 for ; Tue, 10 May 2005 10:43:20 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4AEhJ6d208362 for ; Tue, 10 May 2005 08:43:20 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4AEhJGm020551 for ; Tue, 10 May 2005 08:43:19 -0600 Received: from markdavis (sig-9-48-113-204.mts.ibm.com [9.48.113.204]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4AEhGqi020351; Tue, 10 May 2005 08:43:18 -0600 Message-ID: <12d701c5556e$98b35420$217a3009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <009b01c55850$b97afc00$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #942] clarify advice on use of subtags Date: Tue, 10 May 2005 07:43:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id j4AEhK0c589986 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org No action needed, reject. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Friday, May 13, 2005 23:46 Subject: [Ltru] [psg.com #942] clarify advice on use of subtags > Hi - > > Comment #13 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > requests clarification of the advice on the use of subtags > in section 2.1.1 (of draft -00-) > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 10:44:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVy1-0002zS-4o; Tue, 10 May 2005 10:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVxz-0002zN-Nj for ltru@megatron.ietf.org; Tue, 10 May 2005 10:44:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02715 for ; Tue, 10 May 2005 10:44:09 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVWDF-0004uV-RK for ltru@ietf.org; Tue, 10 May 2005 11:00:02 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4AEhqT9595252 for ; Tue, 10 May 2005 10:43:53 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4AEhn6d098470 for ; Tue, 10 May 2005 08:43:49 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4AEhnUq022369 for ; Tue, 10 May 2005 08:43:49 -0600 Received: from markdavis (sig-9-48-113-204.mts.ibm.com [9.48.113.204]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4AEhkiu022099; Tue, 10 May 2005 08:43:48 -0600 Message-ID: <12d801c5556e$aa819630$217a3009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <00a501c55851$196e9540$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #944] MAY a conformant implementation impose lengthconstraints? Date: Tue, 10 May 2005 07:43:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j4AEhqT9595252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org >an implementation that imposes length constraints > would still be considered conformant, and, if so, what constraints > would be permissible. This information is already in the current draft, so no action is needed. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Friday, May 13, 2005 23:49 Subject: [Ltru] [psg.com #944] MAY a conformant implementation impose lengthconstraints? > Hi - > > Comment #15 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > asks whether an implementation that imposes length constraints > would still be considered conformant, and, if so, what constraints > would be permissible. > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 10:45:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVzR-0003JX-MG; Tue, 10 May 2005 10:45:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVzQ-0003EH-7Y for ltru@megatron.ietf.org; Tue, 10 May 2005 10:45:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02844 for ; Tue, 10 May 2005 10:45:37 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVWEV-0004x3-QC for ltru@ietf.org; Tue, 10 May 2005 11:01:31 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4AEjBIX283356 for ; Tue, 10 May 2005 10:45:11 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4AEjAh3358134 for ; Tue, 10 May 2005 08:45:11 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4AEj0aI026266 for ; Tue, 10 May 2005 08:45:00 -0600 Received: from markdavis (sig-9-48-113-204.mts.ibm.com [9.48.113.204]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4AEixtR025961; Tue, 10 May 2005 08:45:00 -0600 Message-ID: <12d901c5556e$d5c38010$217a3009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <009601c55850$9021f660$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #941] determining currency of registry versions Date: Tue, 10 May 2005 07:44:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j4AEjBIX283356 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The date in the registry, plus the dates on the records, can be used to determine validity as of a given date. No action needs to be taken. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Friday, May 13, 2005 23:45 Subject: [Ltru] [psg.com #941] determining currency of registry versions > Hi - > > This issue was raised in item 12 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > A mechanism describing how one determines whether a registry > version is "current" needs to be spelled out. > > This is related to the charter requirement "For accessibility, > it is to provide a mechanism for easily > determining whether a particular subtag is valid as of a given date, > without onerous reconstruction of the state of the underlying standard > as of that time." > > This is also somewhat related to the charter requirement > "It is expected to specify a mechanism for easily identifying the role > of each subtag in the language tag, so that, for example, whenever a > script code or country code is present in the tag it can be extracted, > even without access to a current version of the registry." > (This last phrase naturally leads one to ask the question, "how do I kn= ow > whether what I have is current.") > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 10:47:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVW1R-0003PA-LS; Tue, 10 May 2005 10:47:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVW1P-0003P5-Gk for ltru@megatron.ietf.org; Tue, 10 May 2005 10:47:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03002 for ; Tue, 10 May 2005 10:47:41 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVWGj-00057e-98 for ltru@ietf.org; Tue, 10 May 2005 11:03:34 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4AElW0c701754 for ; Tue, 10 May 2005 10:47:32 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4AElW6d240078 for ; Tue, 10 May 2005 08:47:32 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4AElViA002243 for ; Tue, 10 May 2005 08:47:31 -0600 Received: from markdavis (sig-9-48-113-204.mts.ibm.com [9.48.113.204]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4AElUhU002165; Tue, 10 May 2005 08:47:31 -0600 Message-ID: <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions in registryentries Date: Tue, 10 May 2005 07:47:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id j4AElW0c701754 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I propose: 1. That we not limit the repertoire. 2. The data from ISO is a source. The purpose is identification, so additions, clarifications or corrections are possible. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Friday, May 13, 2005 23:32 Subject: [Ltru] [psg.com #934] repertoire for descriptions in registryentries > Hi - > > This thread started with message > http://www.ietf.org/mail-archive/web/ltru/current/msg01321.html > > The two key components of this problem are: > (1) whether to limit the repertoire that can be used > (a) to basic latin > (b) latin-1 > > (2) whether to "correct" data brought over from ISO, such as > the use of an incorrect character reference for glottal stop. > > I don't see a clear consensus on this item yet. Now that we've had > some "think time", would someone care to make a proposal? > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 11:26:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVWcq-0000YP-CC; Tue, 10 May 2005 11:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVWco-0000YK-Ke for ltru@megatron.ietf.org; Tue, 10 May 2005 11:26:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05925 for ; Tue, 10 May 2005 11:26:20 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVWs8-0007hS-HV for ltru@ietf.org; Tue, 10 May 2005 11:42:14 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4AFQ91x025473; Tue, 10 May 2005 11:26:10 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 10 May 2005 11:26:19 -0400 Date: Tue, 10 May 2005 11:26:19 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #946] use of both length and position to identify subtag problematic Message-ID: <20050510152618.GC4923@skunk.reutershealth.com> References: <00b701c55851$adefdb20$7f1afea9@oemcomputer> <42808AFD.3198@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42808AFD.3198@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > I've found that splitting tags before the hyphen (excl. any > stuff introduced by a singleton) results in a set of unique > "tokens", and it's possible to identify the type of these > "tokens" without noting their former position. > With several extlang "tokens", and if the order of extlang > "tokens" is significant, it starts to get ugly. If you have A good insight. > a separate ticket for extlang I've no problem with rejecting > [psg.com #946] I agree on both counts: we need a ticket for the issue "Shall multiple extlang tags be permitted in the syntax?" -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan "The exception proves the rule." Dimbulbs think: "Your counterexample proves my theory." Latin students think "'Probat' means 'tests': the exception puts the rule to the proof." But legal historians know it means "Evidence for an exception is evidence of the existence of a rule in cases not excepted from." _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 11:27:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVWdQ-0000kR-K8; Tue, 10 May 2005 11:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVWdP-0000jg-Uw for ltru@megatron.ietf.org; Tue, 10 May 2005 11:27:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05963 for ; Tue, 10 May 2005 11:26:57 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVWsk-0007iA-Sa for ltru@ietf.org; Tue, 10 May 2005 11:42:51 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4AFQnsY025479; Tue, 10 May 2005 11:26:50 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 10 May 2005 11:26:55 -0400 Date: Tue, 10 May 2005 11:26:55 -0400 From: John Cowan To: Mark Davis Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions in registryentries Message-ID: <20050510152655.GD4923@skunk.reutershealth.com> References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis scripsit: > I propose: > > 1. That we not limit the repertoire. +1 > 2. The data from ISO is a source. The purpose is identification, so > additions, clarifications or corrections are possible. I'd rather solve this problem by pushing on the upstream site. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan "The exception proves the rule." Dimbulbs think: "Your counterexample proves my theory." Latin students think "'Probat' means 'tests': the exception puts the rule to the proof." But legal historians know it means "Evidence for an exception is evidence of the existence of a rule in cases not excepted from." _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 12:04:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVXDM-0007Ew-HM; Tue, 10 May 2005 12:04:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVXDK-0007Eq-UN for ltru@megatron.ietf.org; Tue, 10 May 2005 12:04:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08575 for ; Tue, 10 May 2005 12:04:04 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVXSc-0001mb-VA for ltru@ietf.org; Tue, 10 May 2005 12:19:58 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 09:03:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #941] determining currency of registry versions Date: Tue, 10 May 2005 09:03:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B4ECCB7@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #941] determining currency of registry versions Thread-Index: AcVVK8IJszPp6budSCytCO9jl3oGBgATeimg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 10 May 2005 16:03:50.0722 (UTC) FILETIME=[DB382220:01C55579] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org You can extract the codes without any reference to the registry (current = or otherwise) based on length and position. The currency of the registry is determined by the File-Date field. The = one on the IANA website is the most current. Ones with an older date = than that one are not current. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?13? 23:46 > To: LTRU Working Group > Subject: [Ltru] [psg.com #941] determining currency of registry = versions >=20 > Hi - >=20 > This issue was raised in item 12 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html >=20 > A mechanism describing how one determines whether a registry > version is "current" needs to be spelled out. >=20 > This is related to the charter requirement "For accessibility, > it is to provide a mechanism for easily > determining whether a particular subtag is valid as of a given date, > without onerous reconstruction of the state of the underlying standard > as of that time." >=20 > This is also somewhat related to the charter requirement > "It is expected to specify a mechanism for easily identifying the role > of each subtag in the language tag, so that, for example, whenever a > script code or country code is present in the tag it can be extracted, > even without access to a current version of the registry." > (This last phrase naturally leads one to ask the question, "how do I = know > whether what I have is current.") >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 12:05:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVXEJ-0007Ow-Dn; Tue, 10 May 2005 12:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVXEH-0007Ol-UY for ltru@megatron.ietf.org; Tue, 10 May 2005 12:05:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08649 for ; Tue, 10 May 2005 12:05:03 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVXTc-0001o5-FK for ltru@ietf.org; Tue, 10 May 2005 12:20:57 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 09:04:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation impose lengthconstraints? Date: Tue, 10 May 2005 09:04:55 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B4ECCBE@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #944] MAY a conformant implementation impose lengthconstraints? Thread-Index: AcVVLJP/1/Jmk7ELRtOXUkWZG+X3nwATV/Iw From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 10 May 2005 16:04:55.0837 (UTC) FILETIME=[0207E4D0:01C5557A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org A conformant implementation MAY refuse to support the storage of = language tags which exceed a specified length. For an example, see [RFC = 2231] (Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word = Extensions: Character Sets, Languages, and Continuations," November = 1997.)[22]. Any such limitation MUST be clearly documented, and such = documentation SHOULD include the disposition of any longer tags (for = example, whether an error value is generated or the language tag is = truncated). If truncation is permitted it SHOULD NOT permit a subtag to = be divided. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?13? 23:50 > To: LTRU Working Group > Subject: [Ltru] [psg.com #944] MAY a conformant implementation impose > lengthconstraints? >=20 > Hi - >=20 > Comment #15 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > asks whether an implementation that imposes length constraints > would still be considered conformant, and, if so, what constraints > would be permissible. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 12:06:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVXFg-0007Xi-QA; Tue, 10 May 2005 12:06:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVXFf-0007XY-JR for ltru@megatron.ietf.org; Tue, 10 May 2005 12:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08687 for ; Tue, 10 May 2005 12:06:29 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVXV1-0001pK-3b for ltru@ietf.org; Tue, 10 May 2005 12:22:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 09:06:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #943] number of subtags SHOULD be limited to four Date: Tue, 10 May 2005 09:06:21 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B4ECCC3@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #943] number of subtags SHOULD be limited to four Thread-Index: AcVVLL8GNqkXTkFVTxSTetSGt8Q3IwATVBuQ From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 10 May 2005 16:06:22.0314 (UTC) FILETIME=[35933CA0:01C5557A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org There should not be such a limitation: it makes no sense given that = extlangs are a fifth subtag that can appear in the future. And that's = not even considering extensions and private use. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?13? 23:49 > To: LTRU Working Group > Subject: [Ltru] [psg.com #943] number of subtags SHOULD be limited to = four >=20 > Hi - >=20 > Comment #14 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > requests that there should be language stating that the number > of subtags SHOULD be limited to four. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 13:06:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYBP-0003Cd-Qm; Tue, 10 May 2005 13:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYBN-0003BY-Ho for ltru@megatron.ietf.org; Tue, 10 May 2005 13:06:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16345 for ; Tue, 10 May 2005 13:06:06 -0400 (EDT) Received: from mail08.svc.cra.dublin.eircom.net ([159.134.118.24]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVYQi-00064q-9o for ltru@ietf.org; Tue, 10 May 2005 13:22:01 -0400 Received: (qmail 43116 messnum 5385543 invoked from network[194.125.148.214/ts04-087.dublin.indigo.ie]); 10 May 2005 17:05:52 -0000 Received: from ts04-087.dublin.indigo.ie (HELO egt.ie) (194.125.148.214) by mail08.svc.cra.dublin.eircom.net (qp 43116) with SMTP; 10 May 2005 17:05:52 -0000 Message-ID: <4280E96D.A33C1DCF@egt.ie> Date: Tue, 10 May 2005 18:03:41 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #946] use of both length and position toidentify subtag problematic References: <00b701c55851$adefdb20$7f1afea9@oemcomputer> <42808AFD.3198@xyzzy.claranet.de> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA16345 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Is that an argument for replacing hypens with underlines?=20 If so, I agree.=20 (Attending ISO conf. all this wk, with no time to check ref. given below, and v. little time for e-mail, and offering apol's if this is not what you meant, Frank.) mg Scr=EDobh. Frank Ellermann: >=20 > Randy Presuhn wrote: >=20 > [psg.com #946] > > Can we mark this one "rejected"? >=20 > I've found that splitting tags before the hyphen (excl. any > stuff introduced by a singleton) results in a set of unique > "tokens"... --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 13:18:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYNX-0000Nx-Ak; Tue, 10 May 2005 13:18:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYNW-0000Ni-By for ltru@megatron.ietf.org; Tue, 10 May 2005 13:18:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21767 for ; Tue, 10 May 2005 13:18:39 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVYcs-0007on-7B for ltru@ietf.org; Tue, 10 May 2005 13:34:34 -0400 Received: by wproxy.gmail.com with SMTP id 49so143811wri for ; Tue, 10 May 2005 10:18:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=op2q0fzusyI7CXj5g8lDSW+q6/HBhbFVhfI8bNQz4jlWDrC32FizabMHYlKPFyd2KD/tazrhYxrVqLm9AupRn1cus/2dRIjnJLQjLexdrncgZEO00DrSmBW4jEXRBMChUZVPBdmQ5yOp53kVl7D8q7rSozRLkBivl+3lE9KY56o= Received: by 10.54.20.40 with SMTP id 40mr441774wrt; Tue, 10 May 2005 10:18:32 -0700 (PDT) Received: by 10.54.59.4 with HTTP; Tue, 10 May 2005 10:18:32 -0700 (PDT) Message-ID: <6bb0284905051010181e20cc27@mail.gmail.com> Date: Tue, 10 May 2005 10:18:32 -0700 From: Markus Scherer To: ltru@ietf.org Subject: Re: [Ltru] [psg.com #949] remove three-character limit in sections 2.2.2, 2.2.3 (of -00) In-Reply-To: <00d201c55852$86e45280$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <00d201c55852$86e45280$7f1afea9@oemcomputer> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Markus Scherer List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The fixed subtag lengths are carefully chosen to allow for parsing of language tags. In particular, "memory waste" for script subtags is irrelevant: Language tags are not designed to use the fewest bits imaginable. "another code element" will not have "a fixed 4 characters length in the future" precisely because of the parsing of language tags. See also John Cowan's reply, especially on point 21. It seems like 949 should be rejected. markus On 5/13/05, Randy Presuhn wrote: > Comments 20 and 21 of message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > both focus on the length constraints in sections 2.2.2 and 2.2.3 of > the -00 draft. >=20 > There is some followup on this question in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html --=20 Opinions expressed here may not reflect my company's positions unless otherwise noted. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 13:20:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYP7-0000Zr-5f; Tue, 10 May 2005 13:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYP5-0000Zm-LI for ltru@megatron.ietf.org; Tue, 10 May 2005 13:20:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22035 for ; Tue, 10 May 2005 13:20:16 -0400 (EDT) Received: from mail02.svc.cra.dublin.eircom.net ([159.134.118.18]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVYeP-0007tA-Qc for ltru@ietf.org; Tue, 10 May 2005 13:36:12 -0400 Received: (qmail 21594 messnum 5253847 invoked from network[194.125.148.214/ts04-087.dublin.indigo.ie]); 10 May 2005 17:20:06 -0000 Received: from ts04-087.dublin.indigo.ie (HELO egt.ie) (194.125.148.214) by mail02.svc.cra.dublin.eircom.net (qp 21594) with SMTP; 10 May 2005 17:20:06 -0000 Message-ID: <4280ECC3.C347EEB2@egt.ie> Date: Tue, 10 May 2005 18:17:55 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions inregistryentries References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> <20050510152655.GD4923@skunk.reutershealth.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA22035 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Scr=EDobh John Cowan: >=20 > I'd rather solve this problem by pushing on the upstream site. My command of English is excellent, but I do not understand the above expression at all. Would somebody care to explain it, or is it not relevant (better ignored)? If so, there is no need to reply. mg=20 --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 13:24:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYT1-0001pF-Kh; Tue, 10 May 2005 13:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYT0-0001pA-1y for ltru@megatron.ietf.org; Tue, 10 May 2005 13:24:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22384 for ; Tue, 10 May 2005 13:24:19 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVYiL-000899-8v for ltru@ietf.org; Tue, 10 May 2005 13:40:14 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4AHO9T6026086; Tue, 10 May 2005 13:24:09 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 10 May 2005 13:24:19 -0400 Date: Tue, 10 May 2005 13:24:18 -0400 From: John Cowan To: Marion Gunn Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions inregistryentries Message-ID: <20050510172418.GG26704@skunk.reutershealth.com> References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> <20050510152655.GD4923@skunk.reutershealth.com> <4280ECC3.C347EEB2@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4280ECC3.C347EEB2@egt.ie> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Marion Gunn scripsit: > > I'd rather solve this problem by pushing on the upstream site. > > My command of English is excellent, but I do not understand the above > expression at all. Would somebody care to explain it, or is it not > relevant (better ignored)? If so, there is no need to reply. That is to say: if we think an ISO or UN standard has used the wrong Unicode character (or some such minor problem) in an on-line document, we should urge them to change the document themselves rather than introducing a correction into our copy of it. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com Linguistics is arguably the most hotly contested property in the academic realm. It is soaked with the blood of poets, theologians, philosophers, philologists, psychologists, biologists and neurologists, along with whatever blood can be got out of grammarians. - Russ Rymer _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 13:24:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYTA-0001rW-Og; Tue, 10 May 2005 13:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYT9-0001rR-18 for ltru@megatron.ietf.org; Tue, 10 May 2005 13:24:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22391 for ; Tue, 10 May 2005 13:24:27 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVYiT-00089F-B9 for ltru@ietf.org; Tue, 10 May 2005 13:40:22 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4AHOHT9248794 for ; Tue, 10 May 2005 13:24:17 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4AHOH6d218590 for ; Tue, 10 May 2005 11:24:17 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4AHOHY6019724 for ; Tue, 10 May 2005 11:24:17 -0600 Received: from markdavis (sig-9-48-113-204.mts.ibm.com [9.48.113.204]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4AHOF73019651; Tue, 10 May 2005 11:24:16 -0600 Message-ID: <132501c55585$17743430$217a3009@sanjose.ibm.com> From: "Mark Davis" To: "John Cowan" References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> <20050510152655.GD4923@skunk.reutershealth.com> Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions in registryentries Date: Tue, 10 May 2005 10:24:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j4AHOHT9248794 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > I'd rather solve this problem by pushing on the upstream site. I would too, but the process should allow for corrections / clarification= s. What we can do is add to the text a recommend that all corrections / clarifications be communicated to the relevant source authority. =E2=80=8EMark ----- Original Message -----=20 From: "John Cowan" To: "Mark Davis" Cc: "Randy Presuhn" ; "LTRU Working Group" Sent: Tuesday, May 10, 2005 08:26 Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions in registryentries > Mark Davis scripsit: > > > I propose: > > > > 1. That we not limit the repertoire. > > +1 > > > 2. The data from ISO is a source. The purpose is identification, so > > additions, clarifications or corrections are possible. > > I'd rather solve this problem by pushing on the upstream site. > > --=20 > John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan > "The exception proves the rule." Dimbulbs think: "Your counterexample proves > my theory." Latin students think "'Probat' means 'tests': the exceptio= n puts > the rule to the proof." But legal historians know it means "Evidence f= or an > exception is evidence of the existence of a rule in cases not excepted from." > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 13:28:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYWX-0002WL-Hc; Tue, 10 May 2005 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYWW-0002WF-Sd for ltru@megatron.ietf.org; Tue, 10 May 2005 13:28:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22664 for ; Tue, 10 May 2005 13:27:57 -0400 (EDT) Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVYls-0008V3-4T for ltru@ietf.org; Tue, 10 May 2005 13:43:53 -0400 Received: (qmail 56801 messnum 2893474 invoked from network[194.125.148.214/ts04-087.dublin.indigo.ie]); 10 May 2005 17:27:49 -0000 Received: from ts04-087.dublin.indigo.ie (HELO egt.ie) (194.125.148.214) by mail07.svc.cra.dublin.eircom.net (qp 56801) with SMTP; 10 May 2005 17:27:49 -0000 Message-ID: <4280EE91.68EF080F@egt.ie> Date: Tue, 10 May 2005 18:25:38 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions inregistryentries References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> <20050510152655.GD4923@skunk.reutershealth.com> <4280ECC3.C347EEB2@egt.ie> <20050510172418.GG26704@skunk.reutershealth.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA22664 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Thank you. And what is your mechanism for doing so (for conveying that opinion to ISO and/or UN)? mg Scr=EDobh John Cowan: >=20 > Marion Gunn scripsit: >=20 > > > I'd rather solve this problem by pushing on the upstream site. > > > > My command of English is excellent, but I do not understand the above > > expression at all. Would somebody care to explain it, or is it not > > relevant (better ignored)? If so, there is no need to reply. >=20 > That is to say: if we think an ISO or UN standard has used the wrong > Unicode character (or some such minor problem) in an on-line document, > we should urge them to change the document themselves rather than > introducing a correction into our copy of it. --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 13:32:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYb6-0003Xq-EJ; Tue, 10 May 2005 13:32:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYb4-0003Xb-KQ for ltru@megatron.ietf.org; Tue, 10 May 2005 13:32:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23376 for ; Tue, 10 May 2005 13:32:39 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVYqO-0000OO-HS for ltru@ietf.org; Tue, 10 May 2005 13:48:34 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 10:32:30 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 10:32:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #934] repertoire for descriptions inregistryentries Date: Tue, 10 May 2005 10:32:33 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #934] repertoire for descriptions inregistryentries Thread-Index: AcVVdLq+7xWs6WBzQPy1zBoDTgQr8wAEOvcA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 10 May 2005 17:32:30.0472 (UTC) FILETIME=[3E099080:01C55586] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > > 2. The data from ISO is a source. The purpose is identification, so > > additions, clarifications or corrections are possible. >=20 > I'd rather solve this problem by pushing on the upstream site. If by this you mean get the ISO 639 RAs to make corrections, I'd support that. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 13:53:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYus-0007MW-7a; Tue, 10 May 2005 13:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVYur-0007MM-6S for ltru@megatron.ietf.org; Tue, 10 May 2005 13:53:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26444 for ; Tue, 10 May 2005 13:53:08 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVZAD-0002HR-4b for ltru@ietf.org; Tue, 10 May 2005 14:09:01 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVYul-0005V6-00 for ltru@ietf.org; Tue, 10 May 2005 10:53:03 -0700 Message-ID: <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> <001001c55829$830b81c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> Subject: Re: [Ltru] RFC 2277 - considerations Date: Sat, 14 May 2005 10:55:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Rather than addressing the numerous points and assertions individually, I'd like to get a hum from the working group: Should we adopt the general course of action outlined below by Jefsey? I'm not looking for point-by-point responses at this time, just a succinct "yes, let's adopt the general approach Jefsey proposed," "no, let's not go down that path," or "I'd like to hear more discussion of his proposal before deciding." Randy, ltru co-chair > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, May 10, 2005 7:02 AM > Subject: Re: [Ltru] RFC 2277 - considerations > > Dear Randy, > it is always a pleasure to repeat the same thing to you. So I will do it again. > > At 04:05 14/05/2005, Randy Presuhn wrote: > >Given the depth and breadth of expertise of the participants, I'm willing > >to take their lack of confusion as a sign that we know what we need to do. > > Never thought a WG was a resume contest, but I suppose I have no problem > with that. > > Now, it would be surprising that people who came for a purpose (which will > never be globally consensual, two negative Last Calls), would be confused > on what they want to achieve. Those who disagreed but me gave up. > > >Could you *please* identify the *specific* text in the draft you would > >like to add / remove / replace? > > I thought it was clear to you, since end of December. > > Remove: the whole draft. > > Add: the XML oriented parts of the Draft in the second document where they > belong, together with a consistent documentation of its filters and working > tools (you oddily have no problem to add them to langtag libraries but you > cannot add them to charset libraries?), a good explanation of the charset > violation needs, a clear assessment/commitment of the resources required > from IANA > > Replace: make BCP 47 an Internet technology (RFC 1591, 1958, 2277, 2301, > 3066, etc., etc.) consistent framework for the support of language context > identification as one of the Multilingual Internet building blocks, > together with others works such: within IETF (OPES, IDN, LDAP, PPP, SNMP, > etc.), outside (for the time being) the IETF (those I know of: classes, > groups, externets, CRC, ISO 639-X, UNITAG). And let document a consistent > IANA external tables and values management consistent or aggregating the > current registries. > > >The IESG reviewed our charter before approving it. > > IESG will also review the deliverables of this WG before accepting them for > a Last Call and then after the Last Call. And during an appeal if they > approved it. So would IAB after that if they confirmed. > > What is the interest to have something which pleases a small score of > supporters and is defeated by lack of global consensus? If the problem is a > IANA registry conflict please tell us. If the problem is to ascertain the > Unicode table vs. ISO 10646 please tell us. If the problem is to make ISO > 15924 the center of the world please tell us. If the problem are W3C > analysis difficulties please tell us. If the problem is rooted in the CLDR > structures please tell us. > > Your problem is neither to produce a Draft, nor to shut my mouth. Your > target is to address a problem. Either it is the one written in the Charter > and IMHO its is partly erroneously worded the way you seem to read it. Or > it is another one, and I doubt you can solve it if you do not spell it. If > it is part of both, let sort it out first. > > >You even commented on the proposed charter while the IESG was reviewing > >it, so if anything was unclear, you certainly had opportunity to make your > >view heard at that time. > > I commented positively on your proposition to have a WG. This is what I > asked for early January. I had proposed the creation of a WG-TAGs because > this is what I am working on in a much broader scope. I was not opposed on > a WG on language and I detailed my conditions a minima. These conditions > are not spelled out in the Charter, but since the Charter has been > submitted/reviewed to/by the IESG it is mostly consistent with the whole > Internet architecture (all the more that it MUST be read in its perspective). > > >This working group's job is to produce two documents, as spelled out in > >the charter. You are the only participant who seems to have any > >difficulty understanding the charter. > > May be I am the only one with a very low IQ? Did you forget one thing, I am > also the only one who does not to speak English. That alone should be an > alarm for you when addressing a multilingual issue. I am also the only one > in various areas of importance to this topic (a ccTLD registry, the founder > of the oldest user/operator structure, a former @large panelist, an active > contributor to the WSIS process where multilingualism is a priority, etc.). > > I only think there is a qui pro quo you should have resolved first. You > proposed a text with a W3C/Unicode culture, it was read by the IESG with an > Internet culture. I read it with another more global network culture. All > this makes the Internet, but one has to accept to have a limited > methodology. This starts with reviewing what all the participants have read > and accept in your text, not to end with it when everyone is gone. > > You said there were thorny points in the charter. There are. I am not sure > you saw them all. I just waited for the list to be calm enough to rise the > charset issue. > > Please understand, as I mentioned it in my response to the Chairs and ADs, > I am as everyone else entitled to a Charter review by the WG to make sure I > am not wrong, before producing my own Draft. Having a fragmented review of > the Charter while most of the people disappointed with the Draft are gone, > only delays the whole process and does not help. Neither me, nor the > current Draft. > > >No one else on this mailing list has expressed any confusion as to what > >our deliverables are. > > This is precisely the problem. On such a matter, there should have been > much more. This only means they are not here. > > Language tags, the way authors see them, are a deep change in the Internet > architecture. This has lead to the opposition met during the first two last > calls. This WG should have started in assessing that change. Its reasons, > its implications. debreifing the opposition, not just jumping at an 11th > and 12th version of the same proposition with the same text. > > - They want a change which affects/opposes a consistent corpus RFC. > - I see one of the seeds of the response to an urgent market and political > demand not addressed until now. > > Both have to be discussed. Better here than on the general list during the > third Last Call, all the more if it is opposed by a short Draft of mine. > > You just start listing some of the points of my last month review (delay is > not on my side) on the management system you chose. Thank you: this will > save me the time of listing during the Last Calls all the points I rose > which have not been discussed - what would have been poor (I am not sure > however you will list them all?). Now they have to be addressed. But not > all them are listed and most are listed in a way no one can understand what > it refers to without accessing the whole review each time and to figure out > where it is. I gave each point a "#" number (there are 55 of them). Why not > just to paste them into your system before commenting them? Also, in the > follow-up, why to assume people agree with you (and not me) because they > did not comment? > > Think that my draft would use the Charter framework and quotes the > concerned RFCs, documenting how to support the XML, DNS, IDNA, OPES, LDAP, > PPP, etc. etc. needs (even the non documented ones of CLDR) in the scalable > way the Internet has always supported them with success up to > now. Discussing the reducing ways others may have proposed over time which > have been opposed with that success. Scalable, simple, robust, stable, > secure will be the keywords. I could also propose a F2F meeting before the > Paris meeting. I would propose people from the MINC, UNESCO, WSIS, > Francophonie, etc. to attend. > > I accept there will be lacks in such a document of mine as I lack inputs > from the WG debate on the charter, and I have not the time, the expertise > and the interest to became a specialist of all the IETF oddities it should > aggregate and consolidate, such as the RFC of Ira McDonnald, and all the > times the internationalisation of the ASCII Internet is considered in RFCs. > IMHO what you miss is that what you made at stake is the transition from > internationalisation to multilingualisation (actually to vernacularisation) > - user to user relations, over brain to brain, over end to end. I accept > this is beyond what this WG is able to discuss, but this This is _your_ > decision in wanting to replace BCP 47. > > I frankly prefer focusing on the Multilingual Global Network (MGN) - as it > should progressively result from our current work, the WSIS, the dialog > between ITU, WSIS and the operators efforts (currently engaged). Let be > candid: if this WG does not produce a Draft along that lines, the Draft (or > eventually an RFC) and the IANA registry will only be a problem to forget. > Is that what you really want? > > Here is what I propose for a serious review of the topic: > > 1. what I had not time to do it yet: a dump of the whole IETF corpus and a > grep on "international" and "lingual" to know which RFC can be affected and > which experience has been gathered in there. There are more than you > thought in preparing the Charter. > > 2. to seriously review the problems, starting with those quoted by the > charter. What they really mean. What are the architectural implications > they may have in an MGN framework. They are not perfect, but they will lead > to most of them. > > 3. what architectural responses they may call for and what this implies on > the structures of the contents' containers. > > 4. _IF_ there are architectural changes (I doubt there are much, as the MGN > IMHO concerns higher layers than the end to end architecture) what are > they? IMHO they concerns mainly the way to use IPv6, OPES and the DNS due > to current implication of the DNS in the architecture of usage and hyperlinks. > > 5. what is the stable, simple, robust framework the IETF technology should > provide to the applications designers. > > 6. to seriously review the way this can be made supported by IANA and CRCs. > And let implement test applications. > > 7. let discuss how to address the evolutions/trasnsitions possibly implied > at a network level. > > This makes the first document. > > > Then a second document should use that stable foundations to write the > specific solution called by the documentation of the charset in the W3C > containers and the stabilisation of the XML langtag, its filtering, sorting > etc. Another document could be proposed by Unicode (if free of IPRs) to > document the CLDR approach, propositions and specific own usage (if any) of > this framework. > > I accept that the expertise of this WG is more oriented towards the second > document and I am more interested in the first one. There are two possible > responses to that: > > 1. either to follow my proposition above and make the general list aware of > what we plan to discuss. I bet there will be new comers with depth and > breadth of expertise in the concerned areas (even if IETF, IAB and IESG is > not much aware/motivated in the lingual areas). > > 2. or to follow the recommendations received on the general list during the > Last Call. Let us stop pretending changing BCP 47: let consolidate RFC 3066 > as it is today, with its relations to RFC 2277 and 2301, and publish a > specific solution for XML. I do not think anyone will oppose this. Only > some people will find it odd if you document IETF values violation they may > want the IETF/W3C liaison committee to approve. This is the RFC 3066 > bis/ter option. The real work will be carried afterward. And your problem > will be quickly fixed. This is what I proposed the day we started the WG > and to work with the Authors on that. We could be done for a long. Actually > the WG was even not necessary. > > I fully understand this is does not make things simple for you. But you > decided that the most complex issue Internet is to face since its > inception, and delayed for 20 years, was something simple. It is not. > All the best. > jfc > > > > > > > > > > > > > > > > > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 14:00:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZ2N-0002FG-Ac; Tue, 10 May 2005 14:00:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZ2M-0002F9-Dl for ltru@megatron.ietf.org; Tue, 10 May 2005 14:00:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27251 for ; Tue, 10 May 2005 14:00:53 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVZHi-0002uZ-Bj for ltru@ietf.org; Tue, 10 May 2005 14:16:47 -0400 Received: from eupig1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 10 May 2005 18:00:35 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IGA00LLPCOZTQ@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Tue, 10 May 2005 18:00:35 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Tue, 10 May 2005 19:00:34 +0100 Date: Tue, 10 May 2005 19:00:34 +0100 From: Misha Wolf Subject: RE: [Ltru] RFC 2277 - considerations To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] RFC 2277 - considerations thread-index: AcVViSnRjGUVb5vxSgexzIlVM168uQAAH7eA Content-Class: urn:content-classes:message X-OriginalArrivalTime: 10 May 2005 18:00:34.0739 (UTC) FILETIME=[29F05030:01C5558A] X-Spam-Score: 0.8 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org -> no, let's not go down that path (*please*) and (modifying your 3rd option): -> I'd *not* like to hear more discussion of his proposal and a suggestion: Could we set up a separate list called, say, ltru-jfc,=20 where Jefsey could talk to himself? Thanks, Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Randy Presuhn Sent: 14 May 2005 18:55 To: LTRU Working Group Subject: Re: [Ltru] RFC 2277 - considerations Hi - Rather than addressing the numerous points and assertions individually, I'd like to get a hum from the working group: Should we adopt the general course of action outlined below by Jefsey? I'm not looking for point-by-point responses at this time, just a succinct "yes, let's adopt the general approach Jefsey proposed," "no, let's not go down that path," or "I'd like to hear more discussion of his proposal before deciding." Randy, ltru co-chair > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, May 10, 2005 7:02 AM > Subject: Re: [Ltru] RFC 2277 - considerations > > Dear Randy, > it is always a pleasure to repeat the same thing to you. So I will do it again. > > At 04:05 14/05/2005, Randy Presuhn wrote: > >Given the depth and breadth of expertise of the participants, I'm willing > >to take their lack of confusion as a sign that we know what we need to do. > > Never thought a WG was a resume contest, but I suppose I have no problem > with that. > > Now, it would be surprising that people who came for a purpose (which will > never be globally consensual, two negative Last Calls), would be confused > on what they want to achieve. Those who disagreed but me gave up. > > >Could you *please* identify the *specific* text in the draft you would > >like to add / remove / replace? > > I thought it was clear to you, since end of December. > > Remove: the whole draft. > > Add: the XML oriented parts of the Draft in the second document where they > belong, together with a consistent documentation of its filters and working > tools (you oddily have no problem to add them to langtag libraries but you > cannot add them to charset libraries?), a good explanation of the charset > violation needs, a clear assessment/commitment of the resources required > from IANA > > Replace: make BCP 47 an Internet technology (RFC 1591, 1958, 2277, 2301, > 3066, etc., etc.) consistent framework for the support of language context > identification as one of the Multilingual Internet building blocks, > together with others works such: within IETF (OPES, IDN, LDAP, PPP, SNMP, > etc.), outside (for the time being) the IETF (those I know of: classes, > groups, externets, CRC, ISO 639-X, UNITAG). And let document a consistent > IANA external tables and values management consistent or aggregating the > current registries. > > >The IESG reviewed our charter before approving it. > > IESG will also review the deliverables of this WG before accepting them for > a Last Call and then after the Last Call. And during an appeal if they > approved it. So would IAB after that if they confirmed. > > What is the interest to have something which pleases a small score of > supporters and is defeated by lack of global consensus? If the problem is a > IANA registry conflict please tell us. If the problem is to ascertain the > Unicode table vs. ISO 10646 please tell us. If the problem is to make ISO > 15924 the center of the world please tell us. If the problem are W3C > analysis difficulties please tell us. If the problem is rooted in the CLDR > structures please tell us. > > Your problem is neither to produce a Draft, nor to shut my mouth. Your > target is to address a problem. Either it is the one written in the Charter > and IMHO its is partly erroneously worded the way you seem to read it. Or > it is another one, and I doubt you can solve it if you do not spell it. If > it is part of both, let sort it out first. > > >You even commented on the proposed charter while the IESG was reviewing > >it, so if anything was unclear, you certainly had opportunity to make your > >view heard at that time. > > I commented positively on your proposition to have a WG. This is what I > asked for early January. I had proposed the creation of a WG-TAGs because > this is what I am working on in a much broader scope. I was not opposed on > a WG on language and I detailed my conditions a minima. These conditions > are not spelled out in the Charter, but since the Charter has been > submitted/reviewed to/by the IESG it is mostly consistent with the whole > Internet architecture (all the more that it MUST be read in its perspective). > > >This working group's job is to produce two documents, as spelled out in > >the charter. You are the only participant who seems to have any > >difficulty understanding the charter. > > May be I am the only one with a very low IQ? Did you forget one thing, I am > also the only one who does not to speak English. That alone should be an > alarm for you when addressing a multilingual issue. I am also the only one > in various areas of importance to this topic (a ccTLD registry, the founder > of the oldest user/operator structure, a former @large panelist, an active > contributor to the WSIS process where multilingualism is a priority, etc.). > > I only think there is a qui pro quo you should have resolved first. You > proposed a text with a W3C/Unicode culture, it was read by the IESG with an > Internet culture. I read it with another more global network culture. All > this makes the Internet, but one has to accept to have a limited > methodology. This starts with reviewing what all the participants have read > and accept in your text, not to end with it when everyone is gone. > > You said there were thorny points in the charter. There are. I am not sure > you saw them all. I just waited for the list to be calm enough to rise the > charset issue. > > Please understand, as I mentioned it in my response to the Chairs and ADs, > I am as everyone else entitled to a Charter review by the WG to make sure I > am not wrong, before producing my own Draft. Having a fragmented review of > the Charter while most of the people disappointed with the Draft are gone, > only delays the whole process and does not help. Neither me, nor the > current Draft. > > >No one else on this mailing list has expressed any confusion as to what > >our deliverables are. > > This is precisely the problem. On such a matter, there should have been > much more. This only means they are not here. > > Language tags, the way authors see them, are a deep change in the Internet > architecture. This has lead to the opposition met during the first two last > calls. This WG should have started in assessing that change. Its reasons, > its implications. debreifing the opposition, not just jumping at an 11th > and 12th version of the same proposition with the same text. > > - They want a change which affects/opposes a consistent corpus RFC. > - I see one of the seeds of the response to an urgent market and political > demand not addressed until now. > > Both have to be discussed. Better here than on the general list during the > third Last Call, all the more if it is opposed by a short Draft of mine. > > You just start listing some of the points of my last month review (delay is > not on my side) on the management system you chose. Thank you: this will > save me the time of listing during the Last Calls all the points I rose > which have not been discussed - what would have been poor (I am not sure > however you will list them all?). Now they have to be addressed. But not > all them are listed and most are listed in a way no one can understand what > it refers to without accessing the whole review each time and to figure out > where it is. I gave each point a "#" number (there are 55 of them). Why not > just to paste them into your system before commenting them? Also, in the > follow-up, why to assume people agree with you (and not me) because they > did not comment? > > Think that my draft would use the Charter framework and quotes the > concerned RFCs, documenting how to support the XML, DNS, IDNA, OPES, LDAP, > PPP, etc. etc. needs (even the non documented ones of CLDR) in the scalable > way the Internet has always supported them with success up to > now. Discussing the reducing ways others may have proposed over time which > have been opposed with that success. Scalable, simple, robust, stable, > secure will be the keywords. I could also propose a F2F meeting before the > Paris meeting. I would propose people from the MINC, UNESCO, WSIS, > Francophonie, etc. to attend. > > I accept there will be lacks in such a document of mine as I lack inputs > from the WG debate on the charter, and I have not the time, the expertise > and the interest to became a specialist of all the IETF oddities it should > aggregate and consolidate, such as the RFC of Ira McDonnald, and all the > times the internationalisation of the ASCII Internet is considered in RFCs. > IMHO what you miss is that what you made at stake is the transition from > internationalisation to multilingualisation (actually to vernacularisation) > - user to user relations, over brain to brain, over end to end. I accept > this is beyond what this WG is able to discuss, but this This is _your_ > decision in wanting to replace BCP 47. > > I frankly prefer focusing on the Multilingual Global Network (MGN) - as it > should progressively result from our current work, the WSIS, the dialog > between ITU, WSIS and the operators efforts (currently engaged). Let be > candid: if this WG does not produce a Draft along that lines, the Draft (or > eventually an RFC) and the IANA registry will only be a problem to forget. > Is that what you really want? > > Here is what I propose for a serious review of the topic: > > 1. what I had not time to do it yet: a dump of the whole IETF corpus and a > grep on "international" and "lingual" to know which RFC can be affected and > which experience has been gathered in there. There are more than you > thought in preparing the Charter. > > 2. to seriously review the problems, starting with those quoted by the > charter. What they really mean. What are the architectural implications > they may have in an MGN framework. They are not perfect, but they will lead > to most of them. > > 3. what architectural responses they may call for and what this implies on > the structures of the contents' containers. > > 4. _IF_ there are architectural changes (I doubt there are much, as the MGN > IMHO concerns higher layers than the end to end architecture) what are > they? IMHO they concerns mainly the way to use IPv6, OPES and the DNS due > to current implication of the DNS in the architecture of usage and hyperlinks. > > 5. what is the stable, simple, robust framework the IETF technology should > provide to the applications designers. > > 6. to seriously review the way this can be made supported by IANA and CRCs. > And let implement test applications. > > 7. let discuss how to address the evolutions/trasnsitions possibly implied > at a network level. > > This makes the first document. > > > Then a second document should use that stable foundations to write the > specific solution called by the documentation of the charset in the W3C > containers and the stabilisation of the XML langtag, its filtering, sorting > etc. Another document could be proposed by Unicode (if free of IPRs) to > document the CLDR approach, propositions and specific own usage (if any) of > this framework. > > I accept that the expertise of this WG is more oriented towards the second > document and I am more interested in the first one. There are two possible > responses to that: > > 1. either to follow my proposition above and make the general list aware of > what we plan to discuss. I bet there will be new comers with depth and > breadth of expertise in the concerned areas (even if IETF, IAB and IESG is > not much aware/motivated in the lingual areas). > > 2. or to follow the recommendations received on the general list during the > Last Call. Let us stop pretending changing BCP 47: let consolidate RFC 3066 > as it is today, with its relations to RFC 2277 and 2301, and publish a > specific solution for XML. I do not think anyone will oppose this. Only > some people will find it odd if you document IETF values violation they may > want the IETF/W3C liaison committee to approve. This is the RFC 3066 > bis/ter option. The real work will be carried afterward. And your problem > will be quickly fixed. This is what I proposed the day we started the WG > and to work with the Authors on that. We could be done for a long. Actually > the WG was even not necessary. > > I fully understand this is does not make things simple for you. But you > decided that the most complex issue Internet is to face since its > inception, and delayed for 20 years, was something simple. It is not. > All the best. > jfc > > > > > > > > > > > > > > > > > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 14:03:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZ58-0002SD-De; Tue, 10 May 2005 14:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZ57-0002S6-Bj for ltru@megatron.ietf.org; Tue, 10 May 2005 14:03:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27432 for ; Tue, 10 May 2005 14:03:44 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVZKR-000366-Vt for ltru@ietf.org; Tue, 10 May 2005 14:19:38 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4AI3UjM026298; Tue, 10 May 2005 14:03:30 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 10 May 2005 14:03:34 -0400 Date: Tue, 10 May 2005 14:03:33 -0400 From: John Cowan To: Marion Gunn Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions inregistryentries Message-ID: <20050510180333.GA5967@skunk.reutershealth.com> References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> <20050510152655.GD4923@skunk.reutershealth.com> <4280ECC3.C347EEB2@egt.ie> <20050510172418.GG26704@skunk.reutershealth.com> <4280EE91.68EF080F@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4280EE91.68EF080F@egt.ie> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Marion Gunn scripsit: > Thank you. And what is your mechanism for doing so (for conveying that > opinion to ISO and/or UN)? The contact details of the ISO 639 and 15924 Registration Authorities, the ISO 3166 Maintenance Authority, and the UN Statistics Division are readily available on the Web. These are the agencies responsible for maintaining the content on which the registry draws. -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing jcowan@reutershealth.com has so much been paid by so many http://www.ccil.org/~cowan to so few! (pace Winston Churchill) http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 14:04:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZ5o-0002TU-Iw; Tue, 10 May 2005 14:04:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZ5n-0002TP-Ck for ltru@megatron.ietf.org; Tue, 10 May 2005 14:04:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27459 for ; Tue, 10 May 2005 14:04:26 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVZLA-00037G-08 for ltru@ietf.org; Tue, 10 May 2005 14:20:20 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4AI4HKn026302; Tue, 10 May 2005 14:04:18 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 10 May 2005 14:04:25 -0400 Date: Tue, 10 May 2005 14:04:25 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] RFC 2277 - considerations Message-ID: <20050510180425.GB5967@skunk.reutershealth.com> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> <001001c55829$830b81c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > Should we adopt the general course of action outlined below by > Jefsey? I'm not looking for point-by-point responses at this time, > just a succinct "yes, let's adopt the general approach Jefsey > proposed," "no, let's not go down that path," or "I'd like to hear > more discussion of his proposal before deciding." Let's not go down that path. -- What has four pairs of pants, lives John Cowan in Philadelphia, and it never rains http://www.reutershealth.com but it pours? jcowan@reutershealth.com --Rufus T. Firefly http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 14:16:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZHF-0005gL-Tp; Tue, 10 May 2005 14:16:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZHD-0005gG-2X for ltru@megatron.ietf.org; Tue, 10 May 2005 14:16:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28652 for ; Tue, 10 May 2005 14:16:13 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVZWX-0003yE-P3 for ltru@ietf.org; Tue, 10 May 2005 14:32:07 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4AIG2IX556444 for ; Tue, 10 May 2005 14:16:02 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4AIG2h3365292 for ; Tue, 10 May 2005 12:16:02 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4AIG2m3011010 for ; Tue, 10 May 2005 12:16:02 -0600 Received: from markdavis (sig-9-48-113-204.mts.ibm.com [9.48.113.204]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4AIG0FV010894; Tue, 10 May 2005 12:16:01 -0600 Message-ID: <138901c5558c$524e6920$217a3009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com><6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp><01LO1QSCZ7S800004T@mauve.mrochek.com><6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com><002a01c55815$27558240$7f1afea9@oemcomputer><6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com><001001c55829$830b81c0$7f1afea9@oemcomputer><6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> Subject: Re: [Ltru] RFC 2277 - considerations Date: Tue, 10 May 2005 11:16:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j4AIG2IX556444 X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Should we adopt the general course of action outlined below by > Jefsey? Absolutely not. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Saturday, May 14, 2005 10:55 Subject: Re: [Ltru] RFC 2277 - considerations > Hi - > > Rather than addressing the numerous points and assertions > individually, I'd like to get a hum from the working group: > > Should we adopt the general course of action outlined below by > Jefsey? I'm not looking for point-by-point responses at this time, > just a succinct "yes, let's adopt the general approach Jefsey > proposed," "no, let's not go down that path," or "I'd like to hear > more discussion of his proposal before deciding." > > Randy, ltru co-chair > > > From: "JFC (Jefsey) Morfin" > > To: "Randy Presuhn" ; "LTRU Working Gro= up" > > Sent: Tuesday, May 10, 2005 7:02 AM > > Subject: Re: [Ltru] RFC 2277 - considerations > > > > > Dear Randy, > > it is always a pleasure to repeat the same thing to you. So I will do= it again. > > > > At 04:05 14/05/2005, Randy Presuhn wrote: > > >Given the depth and breadth of expertise of the participants, I'm willing > > >to take their lack of confusion as a sign that we know what we need = to do. > > > > Never thought a WG was a resume contest, but I suppose I have no prob= lem > > with that. > > > > Now, it would be surprising that people who came for a purpose (which will > > never be globally consensual, two negative Last Calls), would be confused > > on what they want to achieve. Those who disagreed but me gave up. > > > > >Could you *please* identify the *specific* text in the draft you wou= ld > > >like to add / remove / replace? > > > > I thought it was clear to you, since end of December. > > > > Remove: the whole draft. > > > > Add: the XML oriented parts of the Draft in the second document where they > > belong, together with a consistent documentation of its filters and working > > tools (you oddily have no problem to add them to langtag libraries bu= t you > > cannot add them to charset libraries?), a good explanation of the charset > > violation needs, a clear assessment/commitment of the resources requi= red > > from IANA > > > > Replace: make BCP 47 an Internet technology (RFC 1591, 1958, 2277, 23= 01, > > 3066, etc., etc.) consistent framework for the support of language context > > identification as one of the Multilingual Internet building blocks, > > together with others works such: within IETF (OPES, IDN, LDAP, PPP, SNMP, > > etc.), outside (for the time being) the IETF (those I know of: classe= s, > > groups, externets, CRC, ISO 639-X, UNITAG). And let document a consistent > > IANA external tables and values management consistent or aggregating = the > > current registries. > > > > >The IESG reviewed our charter before approving it. > > > > IESG will also review the deliverables of this WG before accepting th= em for > > a Last Call and then after the Last Call. And during an appeal if the= y > > approved it. So would IAB after that if they confirmed. > > > > What is the interest to have something which pleases a small score of > > supporters and is defeated by lack of global consensus? If the proble= m is a > > IANA registry conflict please tell us. If the problem is to ascertain the > > Unicode table vs. ISO 10646 please tell us. If the problem is to make ISO > > 15924 the center of the world please tell us. If the problem are W3C > > analysis difficulties please tell us. If the problem is rooted in the CLDR > > structures please tell us. > > > > Your problem is neither to produce a Draft, nor to shut my mouth. You= r > > target is to address a problem. Either it is the one written in the Charter > > and IMHO its is partly erroneously worded the way you seem to read it. Or > > it is another one, and I doubt you can solve it if you do not spell i= t. If > > it is part of both, let sort it out first. > > > > >You even commented on the proposed charter while the IESG was review= ing > > >it, so if anything was unclear, you certainly had opportunity to mak= e your > > >view heard at that time. > > > > I commented positively on your proposition to have a WG. This is what= I > > asked for early January. I had proposed the creation of a WG-TAGs because > > this is what I am working on in a much broader scope. I was not oppos= ed on > > a WG on language and I detailed my conditions a minima. These conditi= ons > > are not spelled out in the Charter, but since the Charter has been > > submitted/reviewed to/by the IESG it is mostly consistent with the wh= ole > > Internet architecture (all the more that it MUST be read in its perspective). > > > > >This working group's job is to produce two documents, as spelled out= in > > >the charter. You are the only participant who seems to have any > > >difficulty understanding the charter. > > > > May be I am the only one with a very low IQ? Did you forget one thing= , I am > > also the only one who does not to speak English. That alone should be= an > > alarm for you when addressing a multilingual issue. I am also the onl= y one > > in various areas of importance to this topic (a ccTLD registry, the founder > > of the oldest user/operator structure, a former @large panelist, an active > > contributor to the WSIS process where multilingualism is a priority, etc.). > > > > I only think there is a qui pro quo you should have resolved first. Y= ou > > proposed a text with a W3C/Unicode culture, it was read by the IESG w= ith an > > Internet culture. I read it with another more global network culture. All > > this makes the Internet, but one has to accept to have a limited > > methodology. This starts with reviewing what all the participants hav= e read > > and accept in your text, not to end with it when everyone is gone. > > > > You said there were thorny points in the charter. There are. I am not sure > > you saw them all. I just waited for the list to be calm enough to ris= e the > > charset issue. > > > > Please understand, as I mentioned it in my response to the Chairs and ADs, > > I am as everyone else entitled to a Charter review by the WG to make sure I > > am not wrong, before producing my own Draft. Having a fragmented revi= ew of > > the Charter while most of the people disappointed with the Draft are gone, > > only delays the whole process and does not help. Neither me, nor the > > current Draft. > > > > >No one else on this mailing list has expressed any confusion as to w= hat > > >our deliverables are. > > > > This is precisely the problem. On such a matter, there should have be= en > > much more. This only means they are not here. > > > > Language tags, the way authors see them, are a deep change in the Internet > > architecture. This has lead to the opposition met during the first tw= o last > > calls. This WG should have started in assessing that change. Its reasons, > > its implications. debreifing the opposition, not just jumping at an 1= 1th > > and 12th version of the same proposition with the same text. > > > > - They want a change which affects/opposes a consistent corpus RFC. > > - I see one of the seeds of the response to an urgent market and political > > demand not addressed until now. > > > > Both have to be discussed. Better here than on the general list durin= g the > > third Last Call, all the more if it is opposed by a short Draft of mi= ne. > > > > You just start listing some of the points of my last month review (de= lay is > > not on my side) on the management system you chose. Thank you: this w= ill > > save me the time of listing during the Last Calls all the points I ro= se > > which have not been discussed - what would have been poor (I am not s= ure > > however you will list them all?). Now they have to be addressed. But = not > > all them are listed and most are listed in a way no one can understan= d what > > it refers to without accessing the whole review each time and to figu= re out > > where it is. I gave each point a "#" number (there are 55 of them). W= hy not > > just to paste them into your system before commenting them? Also, in = the > > follow-up, why to assume people agree with you (and not me) because t= hey > > did not comment? > > > > Think that my draft would use the Charter framework and quotes the > > concerned RFCs, documenting how to support the XML, DNS, IDNA, OPES, LDAP, > > PPP, etc. etc. needs (even the non documented ones of CLDR) in the scalable > > way the Internet has always supported them with success up to > > now. Discussing the reducing ways others may have proposed over time which > > have been opposed with that success. Scalable, simple, robust, stable= , > > secure will be the keywords. I could also propose a F2F meeting befor= e the > > Paris meeting. I would propose people from the MINC, UNESCO, WSIS, > > Francophonie, etc. to attend. > > > > I accept there will be lacks in such a document of mine as I lack inp= uts > > from the WG debate on the charter, and I have not the time, the expertise > > and the interest to became a specialist of all the IETF oddities it should > > aggregate and consolidate, such as the RFC of Ira McDonnald, and all = the > > times the internationalisation of the ASCII Internet is considered in RFCs. > > IMHO what you miss is that what you made at stake is the transition f= rom > > internationalisation to multilingualisation (actually to vernacularisation) > > - user to user relations, over brain to brain, over end to end. I acc= ept > > this is beyond what this WG is able to discuss, but this This is _you= r_ > > decision in wanting to replace BCP 47. > > > > I frankly prefer focusing on the Multilingual Global Network (MGN) - = as it > > should progressively result from our current work, the WSIS, the dial= og > > between ITU, WSIS and the operators efforts (currently engaged). Let = be > > candid: if this WG does not produce a Draft along that lines, the Dra= ft (or > > eventually an RFC) and the IANA registry will only be a problem to forget. > > Is that what you really want? > > > > Here is what I propose for a serious review of the topic: > > > > 1. what I had not time to do it yet: a dump of the whole IETF corpus = and a > > grep on "international" and "lingual" to know which RFC can be affect= ed and > > which experience has been gathered in there. There are more than you > > thought in preparing the Charter. > > > > 2. to seriously review the problems, starting with those quoted by th= e > > charter. What they really mean. What are the architectural implicatio= ns > > they may have in an MGN framework. They are not perfect, but they wil= l lead > > to most of them. > > > > 3. what architectural responses they may call for and what this impli= es on > > the structures of the contents' containers. > > > > 4. _IF_ there are architectural changes (I doubt there are much, as t= he MGN > > IMHO concerns higher layers than the end to end architecture) what ar= e > > they? IMHO they concerns mainly the way to use IPv6, OPES and the DNS due > > to current implication of the DNS in the architecture of usage and hyperlinks. > > > > 5. what is the stable, simple, robust framework the IETF technology should > > provide to the applications designers. > > > > 6. to seriously review the way this can be made supported by IANA and CRCs. > > And let implement test applications. > > > > 7. let discuss how to address the evolutions/trasnsitions possibly implied > > at a network level. > > > > This makes the first document. > > > > > > Then a second document should use that stable foundations to write th= e > > specific solution called by the documentation of the charset in the W= 3C > > containers and the stabilisation of the XML langtag, its filtering, sorting > > etc. Another document could be proposed by Unicode (if free of IPRs) = to > > document the CLDR approach, propositions and specific own usage (if a= ny) of > > this framework. > > > > I accept that the expertise of this WG is more oriented towards the second > > document and I am more interested in the first one. There are two possible > > responses to that: > > > > 1. either to follow my proposition above and make the general list aw= are of > > what we plan to discuss. I bet there will be new comers with depth an= d > > breadth of expertise in the concerned areas (even if IETF, IAB and IE= SG is > > not much aware/motivated in the lingual areas). > > > > 2. or to follow the recommendations received on the general list duri= ng the > > Last Call. Let us stop pretending changing BCP 47: let consolidate RF= C 3066 > > as it is today, with its relations to RFC 2277 and 2301, and publish = a > > specific solution for XML. I do not think anyone will oppose this. On= ly > > some people will find it odd if you document IETF values violation th= ey may > > want the IETF/W3C liaison committee to approve. This is the RFC 3066 > > bis/ter option. The real work will be carried afterward. And your problem > > will be quickly fixed. This is what I proposed the day we started the= WG > > and to work with the Authors on that. We could be done for a long. Actually > > the WG was even not necessary. > > > > I fully understand this is does not make things simple for you. But y= ou > > decided that the most complex issue Internet is to face since its > > inception, and delayed for 20 years, was something simple. It is not. > > All the best. > > jfc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 14:31:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZVy-0008QK-Mv; Tue, 10 May 2005 14:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZVw-0008Pt-VH for ltru@megatron.ietf.org; Tue, 10 May 2005 14:31:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00073 for ; Tue, 10 May 2005 14:31:27 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVZlI-00050u-IQ for ltru@ietf.org; Tue, 10 May 2005 14:47:21 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LO3AI1PPA800004T@mauve.mrochek.com> for ltru@ietf.org; Tue, 10 May 2005 11:31:21 -0700 (PDT) Date: Tue, 10 May 2005 11:26:44 -0700 (PDT) In-reply-to: "Your message dated Tue, 10 May 2005 00:53:22 +0200" <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> Message-id: <01LO3B1RSJSY00004T@mauve.mrochek.com> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> Subject: Re: [Ltru] RFC 2277 - considerations To: JFC Jefsey Morfin X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT Cc: LTRU Working Group , ned.freed@mrochek.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Dear Ned, > I thank you to confirm the definition of the charset, as including two > information: > - coded character set: with the repertoire ISO 10646 as a default > - character encoding scheme: with UTF-8 as a default. > is a stable and well accepted matter. Your previous message quoted the definition of a charset. This isn't it. > This means that one can build from here. If by "build" you mean add script tags, the answer is no, you cannot. > We will then have to use registered charsets UTF-8-XXX. It calls for a list > of registered charsets. But subtags will be necessary anyway for 3rd level > IDNs, to filter out the code points used for phishing. They will be used by > some applications. This is both unnecessary and unacceptable. It also far exceeds the charter of this group and is therefore inapppropriate even as a topic of discussion here. And since this list is noisy enough while dealing with relevant matters, this will be my final posting on this topic. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 14:35:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZZP-0001CR-52; Tue, 10 May 2005 14:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZZN-0001Bh-Ro for ltru@megatron.ietf.org; Tue, 10 May 2005 14:35:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00424 for ; Tue, 10 May 2005 14:35:00 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVZok-0005Eb-Mp for ltru@ietf.org; Tue, 10 May 2005 14:50:55 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LO3AI1PPA800004T@mauve.mrochek.com> for ltru@ietf.org; Tue, 10 May 2005 11:34:58 -0700 (PDT) Date: Tue, 10 May 2005 11:34:11 -0700 (PDT) In-reply-to: "Your message dated Tue, 10 May 2005 11:16:00 -0700" <138901c5558c$524e6920$217a3009@sanjose.ibm.com> Message-id: <01LO3B69GGDS00004T@mauve.mrochek.com> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> <001001c55829$830b81c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> <138901c5558c$524e6920$217a3009@sanjose.ibm.com> Subject: Re: [Ltru] RFC 2277 - considerations To: Mark Davis X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7BIT Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > > Should we adopt the general course of action outlined below by > > Jefsey? > Absolutely not. In case it wasn't obvious from my earlier response, I also reject this proposal. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 15:46:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVagX-0004f1-2p; Tue, 10 May 2005 15:46:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVagV-0004ew-Px for ltru@megatron.ietf.org; Tue, 10 May 2005 15:46:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06981 for ; Tue, 10 May 2005 15:46:25 -0400 (EDT) Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVavr-0001H6-0v for ltru@ietf.org; Tue, 10 May 2005 16:02:21 -0400 Received: (qmail 74511 messnum 2895721 invoked from network[194.125.207.4/ts11-004.dublin.indigo.ie]); 10 May 2005 19:46:12 -0000 Received: from ts11-004.dublin.indigo.ie (HELO egt.ie) (194.125.207.4) by mail07.svc.cra.dublin.eircom.net (qp 74511) with SMTP; 10 May 2005 19:46:12 -0000 Message-ID: <42810F00.83633A32@egt.ie> Date: Tue, 10 May 2005 20:44:01 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions inregistryentries References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> <20050510152655.GD4923@skunk.reutershealth.com> <4280ECC3.C347EEB2@egt.ie> <20050510172418.GG26704@skunk.reutershealth.com> <4280EE91.68EF080F@egt.ie> <20050510180333.GA5967@skunk.reutershealth.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA06981 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Scr=EDobh John Cowan: > That is to say: if we think an ISO or UN standard has used the wrong > Unicode character (or some such minor problem) in an on-line document, > we should urge them to change the document themselves rather than > introducing a correction into our copy of it. Now, let's try that again, shall we?=20 What is the mechanism you actually use/have actually used to deal with the problem you described in your original msg (copied again above) John?=20 That is to say, _which_ ISO or UN standards do you have in mind, precisely, in writing the above?=20 A waste of time your posting here (as you have done below) info most of us already have.:-) mg Scr=EDobh John Cowan: >=20 > The contact details of the ISO 639 and 15924 Registration Authorities, > the ISO 3166 Maintenance Authority, and the UN Statistics Division are > readily available on the Web. These are the agencies responsible for > maintaining the content on which the registry draws. --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:42:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcUT-0000Ax-OE; Tue, 10 May 2005 17:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcUS-0000Ag-9B for ltru@megatron.ietf.org; Tue, 10 May 2005 17:42:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23949 for ; Tue, 10 May 2005 17:42:05 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcjq-0001V8-Pp for ltru@ietf.org; Tue, 10 May 2005 17:58:03 -0400 Received: from lns-p19-4-idf-82-65-244-40.adsl.proxad.net ([82.65.244.40] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVcUQ-0005NK-Nd; Tue, 10 May 2005 14:42:07 -0700 Message-Id: <6.2.1.2.2.20050510214414.02d7bce0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 22:10:04 +0200 To: ned.freed@mrochek.com From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] RFC 2277 - considerations In-Reply-To: <01LO3B1RSJSY00004T@mauve.mrochek.com> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <01LO3B1RSJSY00004T@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 20:26 10/05/2005, ned.freed@mrochek.com said: >>Dear Ned, >>I thank you to confirm the definition of the charset, as including two >>information: >>- coded character set: with the repertoire ISO 10646 as a default >>- character encoding scheme: with UTF-8 as a default. >>is a stable and well accepted matter. > >Your previous message quoted the definition of a charset. This isn't it. > >>This means that one can build from here. > >If by "build" you mean add script tags, the answer is no, you cannot. Dear Fred, I do not know you, so I can only try to guess what you mean by "no, you cannot". - if you mean you technically cannot: the response is obviously yes I can, I did, I tested and it works well thank you. - if you mean "I will not register them in the IANA", this is sad, I cannot do anything about it, except to forget about IANA in that part of generic CRCs development. - if you mean that I miss some elements to do so. You are right (I documented that). But the advantages are so interesting that it is worth at this stage to go ahead. And I welcome every help. - if you mean XML will not understand it. I agree, but it will not understand either (libraries) what the Draft or what the Draft after the Draft will chose to implement. We will do for XML what the XML people say, but for our applications we will do what is consistent with the Internet technology. No worry here. >>We will then have to use registered charsets UTF-8-XXX. It calls for a list >>of registered charsets. But subtags will be necessary anyway for 3rd level >>IDNs, to filter out the code points used for phishing. They will be used by >>some applications. > >This is both unnecessary and unacceptable. I am interested in why this would be unnecessary because this is what we are supposed to address. Letting know the receiving party what the content layout is. Also to know what you mean by unacceptable: is that technical or because you would so decide? >It also far exceeds the charter of this group and is therefore >inapppropriate even as a topic of discussion here. I fully documented that it does not exceed (and even then?) the charter of this group which has to document why it wants to document what I (many will) consider to be a charset violation. >And since this list is noisy enough while dealing with relevant matters, >this will be my final posting on this topic. OK. No problem. But you obviously realise that all the issues which will have not been sorted out within this WG, will have to be addressed during the general Last Call. I have no problem with that: I just want the final result not to create me more problem. There are many people and applications around more happy with RFC 2277/2301/3066 as they are (how imperfect they may be) than in seing them challenged and confused. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:42:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcUW-0000BV-Ul; Tue, 10 May 2005 17:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcUT-0000An-Ih for ltru@megatron.ietf.org; Tue, 10 May 2005 17:42:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23952 for ; Tue, 10 May 2005 17:42:07 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcjs-0001VC-0h for ltru@ietf.org; Tue, 10 May 2005 17:58:04 -0400 Received: from lns-p19-4-idf-82-65-244-40.adsl.proxad.net ([82.65.244.40] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVcUR-0005NK-QB; Tue, 10 May 2005 14:42:08 -0700 Message-Id: <6.2.1.2.2.20050510221108.037a5b50@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 22:25:05 +0200 To: Marion Gunn From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [psg.com #934] repertoire for descriptions inregistryentries In-Reply-To: <42810F00.83633A32@egt.ie> References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> <20050510152655.GD4923@skunk.reutershealth.com> <4280ECC3.C347EEB2@egt.ie> <20050510172418.GG26704@skunk.reutershealth.com> <4280EE91.68EF080F@egt.ie> <20050510180333.GA5967@skunk.reutershealth.com> <42810F00.83633A32@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA23952 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Marion, I can only comment on ISO 3166 and UN. - for ISO 3166 you should escalate the problem in the proper way: ask the= =20 IANA. They have been made a member of the ISO 3166 committee to that end=20 through ICANN (cf. IETF/ICANN/IANA MoU). The problem is that ICANN has no= t=20 yet designated a person to represent it. This is a point I made among=20 ccTLDs as ccTLDs are the first concerned by the issue. We have a possible= =20 excellent candidate which would get the support of the whole community fo= r=20 her dedication to this kind of issues. - for UN, this kind of matter has currently the whole attention of the WS= IS=20 WGIG. If there is a policy decided by this WG, it would be advisable to=20 send a mail to its secretary, Mr. Kummer and ask that problem to be part = of=20 the WGIG propositions which must rule the relations between ITU and UN an= d=20 the Information Society we (IETF) are part of. You may also send a mail t= o=20 Avri, she is part of the WGIG, or to the IETF Chair who might help. jfc PS. IRT dash and underscore, I agree with you. The problem is to make the= =20 writing consistent with others. Dash is also minus. We may very well have= =20 to operate list operations on charsets and tag content, now or in the=20 future. Dash is confusing. But my point is obvsiously not for the case at= =20 hand where they just want to address a application related problem. It is= =20 more to give general guidelines to the authors of protocol/applications=20 oriented RFC when dealing with langtags and charsets. On 21:44 10/05/2005, Marion Gunn said: >Scr=EDobh John Cowan: > > That is to say: if we think an ISO or UN standard has used the wrong > > Unicode character (or some such minor problem) in an on-line document= , > > we should urge them to change the document themselves rather than > > introducing a correction into our copy of it. > >Now, let's try that again, shall we? > >What is the mechanism you actually use/have actually used to deal with >the problem you described in your original msg (copied again above) >John? > >That is to say, _which_ ISO or UN standards do you have in mind, >precisely, in writing the above? > >A waste of time your posting here (as you have done below) info most of >us already have.:-) >mg > > >Scr=EDobh John Cowan: > > > > The contact details of the ISO 639 and 15924 Registration Authorities= , > > the ISO 3166 Maintenance Authority, and the UN Statistics Division ar= e > > readily available on the Web. These are the agencies responsible for > > maintaining the content on which the registry draws. > >-- > >Marion Gunn * EGTeo (Estab.1991) >27 P=E1irc an Fh=E9ithlinn, Baile an >Bh=F3thair, Co. =C1tha Cliath, =C9ire. >* mgunn@egt.ie * eamonn@egt.ie * > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:42:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcUZ-0000C3-8W; Tue, 10 May 2005 17:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcUW-0000BQ-Jr for ltru@megatron.ietf.org; Tue, 10 May 2005 17:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23961 for ; Tue, 10 May 2005 17:42:10 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcjt-0001VP-4s for ltru@ietf.org; Tue, 10 May 2005 17:58:07 -0400 Received: from lns-p19-4-idf-82-65-244-40.adsl.proxad.net ([82.65.244.40] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVcUS-0005NK-TT; Tue, 10 May 2005 14:42:09 -0700 Message-Id: <6.2.1.2.2.20050510222929.038377d0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 23:13:02 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] RFC 2277 - considerations In-Reply-To: <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> <001001c55829$830b81c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 19:55 14/05/2005, Randy Presuhn wrote: >Hi - >Rather than addressing the numerous points and assertions >individually, I'd like to get a hum from the working group: > >Should we adopt the general course of action outlined below by >Jefsey? I'm not looking for point-by-point responses at this time, >just a succinct "yes, let's adopt the general approach Jefsey >proposed," "no, let's not go down that path," or "I'd like to hear >more discussion of his proposal before deciding." Dear Randy, I am not sure which of the three courses of action I list you allude to. Let me quote them so the ones who said they "oppose" may not look a fool of opposing again what they support: 1. to follow the charter, understanding what it means and studying seriously what it calls for, what will probably get more people involved for a better legitimacy of a resulting clean sheet draft, reviewing all the impacted RFCs. 2. to follow the Last Call advise: to fix the XML problem without wanting to fix the Internet (replacing BCP 47) against RFC 2301. 3. to continue as per today and to address, during the general Last Call, all what has not been sorted out within the WG. (you have currently entered only a very few of the 55 points of my Draft-11.txt review). Obviously, if some oppose the three of them and have another one, I am more that interested. I suppose the current mood being what it is, 3 will be favored, the last call will fail again on the grounds of 2, what will lead 1 to be the end result, next year or outside the IETF. This will be good for the Internet, but will represent a certain waste of efforts and time for all of us. Obviously I will not complain to get a good result addressing the real world's needs, but could not some common sense and humility help us doing better and faster. After all, this approach will have delayed the odd XML solution the W3C wants by two years (counting the last 2 failed Last Calls). What is too bad if they really want it (I do not use XML much) because 2 would have made an RFC of it by now. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:48:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcal-0001Bj-RB; Tue, 10 May 2005 17:48:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcal-0001Bc-2f for ltru@megatron.ietf.org; Tue, 10 May 2005 17:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24627 for ; Tue, 10 May 2005 17:48:36 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcq8-0001yq-Er for ltru@ietf.org; Tue, 10 May 2005 18:04:33 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVcah-0002cQ-00 for ltru@ietf.org; Tue, 10 May 2005 14:48:35 -0700 Message-ID: <005501c555aa$54c009c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 14:50:49 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] [psg.com #950] iso 3166 inadequate for regional variants X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > This comes from comment 22 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > which states: > > "22. 2.2.4: I understand that all the regional language differences of > the > world are to be supported by the ISO 3166 alpha-3/digit-3 list. This > means > that regions like NY, TX or California are not entitled a code but the > 56 > persons of Pitcairn Island yes? I doubt that disparity can hold very > long, > all the more than ISO 3166-2 provides all the possibilities for a far > more > adequate granularity." > > As pointed out in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > the draft also supports UN M.49 digit-3 codes Based on recent discussion, can I close this with a "reject"? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:52:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVce2-000202-Ez; Tue, 10 May 2005 17:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVce1-0001zu-7F for ltru@megatron.ietf.org; Tue, 10 May 2005 17:52:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24951 for ; Tue, 10 May 2005 17:51:58 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVctP-0002B1-PK for ltru@ietf.org; Tue, 10 May 2005 18:07:56 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVcdz-0003tR-00 for ltru@ietf.org; Tue, 10 May 2005 14:51:59 -0700 Message-ID: <005e01c555aa$cf39cc40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 14:53:58 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] [psg.com #951] extensibility via codes not maintained by ISO X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comments 45 and 53 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > raise the question of supporting language, country, and region > codes not maintained by ISO. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:52:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVceS-00022k-UE; Tue, 10 May 2005 17:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVceR-00022A-CW for ltru@megatron.ietf.org; Tue, 10 May 2005 17:52:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25019 for ; Tue, 10 May 2005 17:52:24 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcto-0002Bl-Uy for ltru@ietf.org; Tue, 10 May 2005 18:08:22 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVceP-00040r-00 for ltru@ietf.org; Tue, 10 May 2005 14:52:25 -0700 Message-ID: <005f01c555aa$de2fc100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 14:54:40 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] [psg.com #952] how to determine whether an ISO 639 registration request has been processed? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment number 23 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > says: > "23. 2.2.9: There is a MUST in "there MUST be an attempt to register" > which > cannot be enforced if there is not a non-delaying procedure to verify > that > a language was attempted to be registered with ISO 639. Otherwise this > part > is to be understood as a disguised way, concerted with ISO, to block > names. > The concern on this point is high enough to see the Draft blocked. It > seems > that the second paragraph is a smoky verbose replay of the same idea, > without any procedural description nor request/provision of formal > proof. > The general idea is precisely in opposition with the purpose of the > proposed RFC: to be able to register names not registered by ISO. This > amount to a legitimisation of censoring, and censoring against the very > intent of this document." > > Subsequent discussion on the WG mailing list (see > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html and > http://www.ietf.org/mail-archive/web/ltru/current/msg00717.html ) > indicates that that the registration authority has been responsive > to requests, and that there is no need for additional mechanisms > to be specified, so this item is marked "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:53:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcfD-0002FJ-2Y; Tue, 10 May 2005 17:53:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcfB-0002F4-W0 for ltru@megatron.ietf.org; Tue, 10 May 2005 17:53:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25068 for ; Tue, 10 May 2005 17:53:11 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcuZ-0002CM-4n for ltru@ietf.org; Tue, 10 May 2005 18:09:08 -0400 Received: from h-68-166-37-119.snvacaid.dynamic.covad.net ([68.166.37.119] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVcf1-0004GP-00 for ltru@ietf.org; Tue, 10 May 2005 14:53:03 -0700 Message-ID: <006401c555aa$f4bdae00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 14:55:18 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] [psg.com #953] change process for handling registration requests X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > comment 24 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > says: "24. 2.2.9: registrations are left to a decision of > appropriateness by > someone debating with undefined others for a matter without any > importance > on the network stability and security (documented in in part 4) non on > the > end to end interoperability. This seems to amount to pure intellectual > censoring." > > There was no support for this proposal, so it is marked "rejected." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:54:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcgn-0002Y2-HW; Tue, 10 May 2005 17:54:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcgm-0002Xo-I1 for ltru@megatron.ietf.org; Tue, 10 May 2005 17:54:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25216 for ; Tue, 10 May 2005 17:54:50 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcwA-0002Kx-61 for ltru@ietf.org; Tue, 10 May 2005 18:10:47 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4ALseL7027509; Tue, 10 May 2005 17:54:41 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 10 May 2005 17:54:49 -0400 Date: Tue, 10 May 2005 17:54:48 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] [psg.com #950] iso 3166 inadequate for regional variants Message-ID: <20050510215448.GB6864@skunk.reutershealth.com> References: <005501c555aa$54c009c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005501c555aa$54c009c0$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > Based on recent discussion, can I close this with a "reject"? Yes. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 17:59:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVclP-0005Sy-5j; Tue, 10 May 2005 17:59:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVclN-0005Nx-I3 for ltru@megatron.ietf.org; Tue, 10 May 2005 17:59:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25967 for ; Tue, 10 May 2005 17:59:34 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVd0k-0002dp-G6 for ltru@ietf.org; Tue, 10 May 2005 18:15:31 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVclI-0003YW-00 for ltru@ietf.org; Tue, 10 May 2005 14:59:32 -0700 Message-ID: <000401c555ab$ddce98c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 15:01:48 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 25 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > says: "25. 2.3: recommendation 3 seems inappropriate. Aliases are > aliases. All the > aliases must be equally supported because (a) they are aliases (b) to > make > sure developers develops correct code." > > Discussion clarified that the intent is > "All aliases are equally supported. Not all aliases are equally > recommended." > see http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 18:02:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcoO-000788-M7; Tue, 10 May 2005 18:02:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcoN-00076y-Cw for ltru@megatron.ietf.org; Tue, 10 May 2005 18:02:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26260 for ; Tue, 10 May 2005 18:02:40 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVd3l-0002p6-1Q for ltru@ietf.org; Tue, 10 May 2005 18:18:38 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVcoL-0004qN-00 for ltru@ietf.org; Tue, 10 May 2005 15:02:41 -0700 Message-ID: <000901c555ac$4f4fe8a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 15:04:59 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] [psg.com #955] expand scope to include computer languages X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 26 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > says: > "26. 2.4. "language tags always define a language as spoken by human > being > for communications of information to other human beings. Computer > languages > . are explicitly excluded" has no ground in the Charter and in reality. > Web > Services relations are excluded which may speak limited languages. > Coded > human languages should be supported: they fit the definition." > > Discussion on the mailing list found no support for this proposal, > so it is marked "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 18:03:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcp4-0007Ef-96; Tue, 10 May 2005 18:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcp2-0007Br-67 for ltru@megatron.ietf.org; Tue, 10 May 2005 18:03:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26349 for ; Tue, 10 May 2005 18:03:21 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVd4Q-0002pe-P5 for ltru@ietf.org; Tue, 10 May 2005 18:19:19 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVcp0-00053D-00 for ltru@ietf.org; Tue, 10 May 2005 15:03:22 -0700 Message-ID: <000e01c555ac$6884d9c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 15:05:42 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Ltru] [psg.com #956] document use of "" as deprecation indicator X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comments 27 and 47 of > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > say: > "27. 2.4.1: in the canonicalization part "" is reminded as a > deprecation > indicator, yet this is not documented earlier. It seems this is an > external > ISO practice. This should be documented in the format description part. > All > the more than this practice is counter intuitive "" being understood > intuitively as "-(nul)-". And the "" being used in IDN there could be > some > homograph confusion to investigate." and > "47. 6. last: added text for "" is not sufficient enough, or is missing > in > my version." > > Discussion revealed that the comment was based on a mis-understanding, > according to message > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > > Consequently, this item is marked "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 18:04:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcpp-0007MK-H0; Tue, 10 May 2005 18:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcpo-0007M4-E6 for ltru@megatron.ietf.org; Tue, 10 May 2005 18:04:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26456 for ; Tue, 10 May 2005 18:04:09 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVd5C-0002wa-Uc for ltru@ietf.org; Tue, 10 May 2005 18:20:07 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVcpm-0005Hr-00 for ltru@ietf.org; Tue, 10 May 2005 15:04:10 -0700 Message-ID: <001301c555ac$84cd2560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 15:06:29 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] [psg.com #957] compatibility of description format with ISO table format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 29 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > reads > "29. 3.1: Description of "description" is clueless. It is a description > but > does not intend to be an English description but it is one. The > addition > made in the IANA file are intended to be additions to corresponding > documented ISO tables. They MUST comply with the format of these tables > otherwise they add a disparity between the table and their > IANA "appendix"." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 18:04:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcqT-0007bE-Hh; Tue, 10 May 2005 18:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcqS-0007b4-D9 for ltru@megatron.ietf.org; Tue, 10 May 2005 18:04:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26552 for ; Tue, 10 May 2005 18:04:49 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVd5r-0002xZ-3a for ltru@ietf.org; Tue, 10 May 2005 18:20:47 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVcqQ-0005ZH-00 for ltru@ietf.org; Tue, 10 May 2005 15:04:50 -0700 Message-ID: <001801c555ac$9ce64640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 15:07:09 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] [psg.com #958] move tag formation rules X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment number 30 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > (referring to the -00- draft) > "30. 3.1. includes a registry format description (OK) but also > considerations on the way the tags should be formed which have nothing > to > do in a file description. They should be moved into 2.4.1" Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 18:05:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcr3-0007sr-Vs; Tue, 10 May 2005 18:05:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcr2-0007sm-Kb for ltru@megatron.ietf.org; Tue, 10 May 2005 18:05:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26670 for ; Tue, 10 May 2005 18:05:26 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVd6R-0002yp-8E for ltru@ietf.org; Tue, 10 May 2005 18:21:23 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVcr1-0005uB-00 for ltru@ietf.org; Tue, 10 May 2005 15:05:27 -0700 Message-ID: <001d01c555ac$b2bb91a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 10 May 2005 15:07:46 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] [psg.com #959] consolidate review process instructions X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comments 31 and 32 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > suggest separating instructions to the reviewer and the review > process participants from the registry format and IANA procedure > sections. > > "31. 3.1. also includes direction to the Reviewer which should be > presented > in a separate part from the format description. > > 32. 3.2. this part is not a IANA procedure but a long guidance for the > Reviewer and the Reviewing process participants, limited to current > possible cases" Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 19:36:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVeGp-00039L-S9; Tue, 10 May 2005 19:36:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVeGp-00039G-Cg for ltru@megatron.ietf.org; Tue, 10 May 2005 19:36:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03917 for ; Tue, 10 May 2005 19:36:08 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVeWD-0007ej-Rz for ltru@ietf.org; Tue, 10 May 2005 19:52:07 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 16:36:00 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 16:36:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #946] use of both length and positiontoidentify subtag problematic Date: Tue, 10 May 2005 16:36:03 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #946] use of both length and positiontoidentify subtag problematic Thread-Index: AcVVgqT878FBtV/hQfKNfWEMjZvhfAANhmfg From: "Peter Constable" To: X-OriginalArrivalTime: 10 May 2005 23:36:00.0189 (UTC) FILETIME=[05A446D0:01C555B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Marion Gunn > Is that an argument for replacing hypens with underlines? >=20 > If so, I agree. Replacing hyphens with underlines would create confusion with locale IDs used in various software implementations, and would be incompatible with RFC 1766 and RFC 3066 implementations -- that is a no-go. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 20:29:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVf6q-0005KO-OG; Tue, 10 May 2005 20:29:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVf6o-0005Ju-St for ltru@megatron.ietf.org; Tue, 10 May 2005 20:29:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07345 for ; Tue, 10 May 2005 20:29:50 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVfMA-0001rn-RQ for ltru@ietf.org; Tue, 10 May 2005 20:45:48 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 17:29:40 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 17:29:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] RFC 2277 - considerations Date: Tue, 10 May 2005 17:29:44 -0700 Message-ID: Thread-Topic: [Ltru] RFC 2277 - considerations Thread-Index: AcVViShPytZhKaL8TiyGWochvQQCRgANyNJQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 00:29:40.0454 (UTC) FILETIME=[8511B860:01C555C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Should we adopt the general course of action outlined below by > Jefsey? I'm not looking for point-by-point responses at this time, > just a succinct "yes, let's adopt the general approach Jefsey > proposed," "no, let's not go down that path," or "I'd like to hear > more discussion of his proposal before deciding." > > >Could you *please* identify the *specific* text in the draft you would > > >like to add / remove / replace? > > > > I thought it was clear to you, since end of December. > > > > Remove: the whole draft. ... No!=20 This appears to be one person wishing to obstruct the consensus developed of the remainder of the WG. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 20:49:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVfPQ-0001JZ-DD; Tue, 10 May 2005 20:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVfPN-0001J1-2D for ltru@megatron.ietf.org; Tue, 10 May 2005 20:49:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08694 for ; Tue, 10 May 2005 20:49:03 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVfen-0002tC-8Q for ltru@ietf.org; Tue, 10 May 2005 21:05:01 -0400 Received: from lns-p19-4-idf-82-65-244-40.adsl.proxad.net ([82.65.244.40] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVfPL-00022d-J2; Tue, 10 May 2005 17:49:04 -0700 Message-Id: <6.2.1.2.2.20050511024255.03848da0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 02:44:53 +0200 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: [psg.com #946] use of both length and positiontoidentify subtag problematic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 01:36 11/05/2005, Peter Constable wrote: > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On > > Behalf Of Marion Gunn > > > > Is that an argument for replacing hypens with underlines? > > > > If so, I agree. > >Replacing hyphens with underlines would create confusion with locale IDs >used in various software implementations, Dear Peter, this is an important element you never explained. Can you document this with examples? thank you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 22:29:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVgyW-0004A9-W9; Tue, 10 May 2005 22:29:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVgyW-000490-EO for ltru@megatron.ietf.org; Tue, 10 May 2005 22:29:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14504 for ; Tue, 10 May 2005 22:29:26 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVhDw-0007gi-EY for ltru@ietf.org; Tue, 10 May 2005 22:45:25 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 19:29:17 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 19:29:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #946] use of both length and positiontoidentify subtag problematic Date: Tue, 10 May 2005 19:28:47 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #946] use of both length and positiontoidentify subtag problematic Thread-Index: AcVVwzyBVoCJG5g1TTGt14LUPaAfEQADNyGA From: "Peter Constable" To: X-OriginalArrivalTime: 11 May 2005 02:29:16.0885 (UTC) FILETIME=[3A8E3050:01C555D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > >Replacing hyphens with underlines would create confusion with locale IDs > >used in various software implementations, POSIX / Unix locales have typically used locale IDs of the form ll_CC. Language tags serve a different purpose and have different requirements than locale tags. (There are important areas of overlap, but they are ultimately distinct.) There is some confusion out there between the two, and changing language tags to use underlines rather than hyphens would only make it harder to educate. Whether or not you accept this, the back compat problem makes such a change impossible. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 22:53:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVhLc-0000XF-7X; Tue, 10 May 2005 22:53:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVhLa-0000X0-5C for ltru@megatron.ietf.org; Tue, 10 May 2005 22:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15931 for ; Tue, 10 May 2005 22:53:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVhaz-0000QJ-A5 for ltru@ietf.org; Tue, 10 May 2005 23:09:15 -0400 Received: from lns-p19-4-idf-82-65-244-40.adsl.proxad.net ([82.65.244.40] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVhLV-0002xp-UL; Tue, 10 May 2005 19:53:14 -0700 Message-Id: <6.2.1.2.2.20050511040248.03ee8440@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 04:35:39 +0200 To: Markus Scherer , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [psg.com #949] remove three-character limit in sections 2.2.2, 2.2.3 (of -00) In-Reply-To: <6bb0284905051010181e20cc27@mail.gmail.com> References: <00d201c55852$86e45280$7f1afea9@oemcomputer> <6bb0284905051010181e20cc27@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 19:18 10/05/2005, Markus Scherer wrote: >The fixed subtag lengths are carefully chosen to allow for parsing of >language tags. In particular, "memory waste" for script subtags is >irrelevant: Language tags are not designed to use the fewest bits >imaginable. "another code element" will not have "a fixed 4 characters >length in the future" precisely because of the parsing of language >tags. If you like it, I obviously have no problem with that if the Draft drops its claim to be BCP 47. It will be a language oriented XML unable to document the script alone. Imagine you travel around and you only see the signs, the labels, the books, the newspapers if you can _first_ say in which language they are printed. Good luck :-) jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 22:53:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVhLc-0000Xd-GU; Tue, 10 May 2005 22:53:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVhLa-0000X2-9H for ltru@megatron.ietf.org; Tue, 10 May 2005 22:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15934 for ; Tue, 10 May 2005 22:53:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVhay-0000QH-DH for ltru@ietf.org; Tue, 10 May 2005 23:09:15 -0400 Received: from lns-p19-4-idf-82-65-244-40.adsl.proxad.net ([82.65.244.40] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVhLU-0002xp-9d for ltru@ietf.org; Tue, 10 May 2005 19:53:12 -0700 Message-Id: <6.2.1.2.2.20050511034921.03850200@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 04:53:06 +0200 To: "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: jamais deux sans trois ? (was RE: [Ltru] RFC 2277 - considerations) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 02:29 11/05/2005, Peter Constable said: > > > >Could you *please* identify the *specific* text in the draft you would > > > >like to add / remove / replace? > > > > > > I thought it was clear to you, since end of December. > > > > > > Remove: the whole draft. >... > >No! > >This appears to be one person wishing to obstruct the consensus >developed of the remainder of the WG.. Dear Peter, 1. this is what what _I_ would like add/remove/replace that Randy asked. This is not what I propose the WG to do and Randy asks about. I documented it again so you can avoid to say "no", because I propose it, to what you are just wanting to do. 2. I certainly want to save time and stop a "consensus developped of the remainder of the WG": this same residual reached the same "consensus" on another list for the same proposition. Do you really want the same result? Cheers. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 23:45:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVi9u-00016C-T9; Tue, 10 May 2005 23:45:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVi9q-000167-U8 for ltru@megatron.ietf.org; Tue, 10 May 2005 23:45:17 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19094 for ; Tue, 10 May 2005 23:45:11 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVi1z-0002Ze-Vw for ltru@lists.ietf.org; Wed, 11 May 2005 05:37:07 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 05:37:07 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 05:37:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 05:43:28 +0200 Organization: Lines: 13 Message-ID: <42817F60.2DD0@xyzzy.claranet.de> References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer> <12da01c5556f$2fab6660$217a3009@sanjose.ibm.com> <20050510152655.GD4923@skunk.reutershealth.com> <4280ECC3.C347EEB2@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #934] repertoire for descriptions inregistryentries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Marion Gunn wrote: > Would somebody care to explain it If ISO broke it let ISO fix it, dito UN. I'd rather not burden the tag reviewer with this job, and not add text about it to the draft. If text is added a "MAY" authorizing the tag reviewer is enough. We already have a "SHALL petition the UN" in the text, maybe it's only me, but IMNSHO that's ridiclous. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 23:52:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DViHE-0002Rq-GO; Tue, 10 May 2005 23:52:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DViHC-0002Q3-H1 for ltru@megatron.ietf.org; Tue, 10 May 2005 23:52:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19537 for ; Tue, 10 May 2005 23:52:47 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DViWc-0003QO-Sb for ltru@ietf.org; Wed, 11 May 2005 00:08:48 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DViH5-0000nE-00 for ltru@ietf.org; Tue, 10 May 2005 20:52:43 -0700 Message-ID: <004f01c555dd$36b397c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B4ECCB7@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #941] determining currency of registry versions Date: Tue, 10 May 2005 20:54:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - (as a technical contributor) > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, May 10, 2005 9:03 AM > Subject: RE: [Ltru] [psg.com #941] determining currency of registry versions > > You can extract the codes without any reference to the registry > (current or otherwise) based on length and position. This still doesn't address the requirement from the charter that "it is to provide a mechanism for easily determining whether a particular subtag is valid as of a given date, without onerous reconstruction of the state of the underlying standard as of that time" > The currency of the registry is determined by the File-Date field. > The one on the IANA website is the most current. Ones with an > older date than that one are not current. The current (-01) text says: The first record in the file contains the single field whose field- name is "File-Date" and whose field-body contains the last modification date of the registry: Would it make sense to amend it to say something like: The first record in the file contains the single field whose field- name is "File-Date". The field-body contains the last modification date of the registry. The currency of the registry is determined by this field. The registry on the IANA website is the most current. Versions with an older date than that one are not current. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 23:55:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DViK1-0002o3-TA; Tue, 10 May 2005 23:55:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DViK0-0002ny-52 for ltru@megatron.ietf.org; Tue, 10 May 2005 23:55:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19691 for ; Tue, 10 May 2005 23:55:41 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DViZR-0003ZC-U1 for ltru@ietf.org; Wed, 11 May 2005 00:11:42 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DViJy-0001Ln-00 for ltru@ietf.org; Tue, 10 May 2005 20:55:42 -0700 Message-ID: <005601c555dd$a215d3c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B4ECCC3@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #943] number of subtags SHOULD be limited to four Date: Tue, 10 May 2005 20:58:04 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Ok, I'll mark this one as a "reject." Randy, ltru co-chair ----- Original Message ----- From: "Addison Phillips" To: "Randy Presuhn" ; "LTRU Working Group" Sent: Tuesday, May 10, 2005 9:06 AM Subject: RE: [Ltru] [psg.com #943] number of subtags SHOULD be limited to four There should not be such a limitation: it makes no sense given that extlangs are a fifth subtag that can appear in the future. And that's not even considering extensions and private use. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: 2005?5?13? 23:49 > To: LTRU Working Group > Subject: [Ltru] [psg.com #943] number of subtags SHOULD be limited to four > > Hi - > > Comment #14 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > requests that there should be language stating that the number > of subtags SHOULD be limited to four. > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 10 23:56:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DViKq-00031k-Ow; Tue, 10 May 2005 23:56:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DViKp-00031f-0A for ltru@megatron.ietf.org; Tue, 10 May 2005 23:56:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19746 for ; Tue, 10 May 2005 23:56:31 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DViaB-0003Zv-VO for ltru@ietf.org; Wed, 11 May 2005 00:12:32 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4B3uBT9499384 for ; Tue, 10 May 2005 23:56:12 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4B3uBh3323888 for ; Tue, 10 May 2005 21:56:11 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4B3u8sj020695 for ; Tue, 10 May 2005 21:56:08 -0600 Received: from markdavis (sig-9-48-120-237.mts.ibm.com [9.48.120.237]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4B3u7ei020680; Tue, 10 May 2005 21:56:08 -0600 Message-ID: <024d01c555dd$5d29efd0$b9703009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <006301c5584e$b0a628e0$7f1afea9@oemcomputer><12da01c5556f$2fab6660$217a3009@sanjose.ibm.com><20050510152655.GD4923@skunk.reutershealth.com><4280ECC3.C347EEB2@egt.ie> <42817F60.2DD0@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #934] repertoire for descriptionsinregistryentries Date: Tue, 10 May 2005 20:55:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j4B3uBT9499384 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I don't think I made my position clear. Yes, fine we can petition the sou= rce standard to change. But we should also have the *ability* to make a necessary change without waiting for the source standard. I'm sure the process and registrar will discourage pointless changes. =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Tuesday, May 10, 2005 20:43 Subject: [Ltru] Re: [psg.com #934] repertoire for descriptionsinregistryentries > Marion Gunn wrote: > > > Would somebody care to explain it > > If ISO broke it let ISO fix it, dito UN. > > I'd rather not burden the tag reviewer with this job, > and not add text about it to the draft. If text is > added a "MAY" authorizing the tag reviewer is enough. > > We already have a "SHALL petition the UN" in the text, > maybe it's only me, but IMNSHO that's ridiclous. Bye. > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:03:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DViRw-0004ZO-UL; Wed, 11 May 2005 00:03:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DViRu-0004Xk-Pt for ltru@megatron.ietf.org; Wed, 11 May 2005 00:03:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20128 for ; Wed, 11 May 2005 00:03:52 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVihM-0003ym-JU for ltru@ietf.org; Wed, 11 May 2005 00:19:52 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DViRs-0003Ie-00 for ltru@ietf.org; Tue, 10 May 2005 21:03:52 -0700 Message-ID: <005d01c555de$c602cc60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B4ECCBE@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #944] MAY a conformant implementation impose lengthconstraints? Date: Tue, 10 May 2005 21:06:10 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - (as a technical contributor) > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, May 10, 2005 9:04 AM > Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation impose lengthconstraints? > > > A conformant implementation MAY refuse to support the storage of language > tags which exceed a specified length. For an example, see [RFC 2231] (Freed, > N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: > Character Sets, Languages, and Continuations," November 1997.)[22]. Any > such limitation MUST be clearly documented, and such documentation > SHOULD include the disposition of any longer tags (for example, whether > an error value is generated or the language tag is truncated). If truncation > is permitted it SHOULD NOT permit a subtag to be divided. > ... Thinking like an implementor, I'd find this of little help. I don't see how permitting truncation and permitting subtag division could possibly help interoperability. I'd be more comfortable with "If truncation is permitted, it MUST NOT permit a subtag to be divided." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:16:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVieN-0006Vn-00; Wed, 11 May 2005 00:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVieK-0006Vi-OJ for ltru@megatron.ietf.org; Wed, 11 May 2005 00:16:44 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20948 for ; Wed, 11 May 2005 00:16:41 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DViWs-0004tN-DU for ltru@lists.ietf.org; Wed, 11 May 2005 06:09:02 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 06:09:02 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 06:09:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 06:03:28 +0200 Organization: Lines: 30 Message-ID: <42818410.38B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B4ECCBE@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #944] MAY a conformant implementation impose length constraints? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > A conformant implementation MAY refuse to support the storage > of language tags which exceed a specified length. For an > example, see [RFC 2231] (Freed, N. and K. Moore, "MIME > Parameter Value and Encoded Word Extensions: Character Sets, > Languages, and Continuations," November 1997.)[22]. The real problem is 2231 in conjunction with 2047 encoded words, the 2047 limit 76 is not mentioned in 2231. Please add RfC 2047. While 2231 multiline-parameters are a pain they have almost no length problems - in fact that's the idea of multiline parameters, and any remaining limit 9?? (below 998) is no real problem for LTRU. BTW, 998 is documented in RfC 2045, not in RfC 2231. > Any such limitation MUST be clearly documented, and such > documentation SHOULD include the disposition of any longer > tags (for example, whether an error value is generated or > the language tag is truncated). If truncation is permitted > it SHOULD NOT permit a subtag to be divided. Please swap the MUST and the second SHOULD. It SHOULD be clearly documented (and we know that this is not the case from our POV for 2231 + 2047), and any truncation MUST at least syntactically make sense, Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:16:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVieY-0006WI-7s; Wed, 11 May 2005 00:16:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVieV-0006WD-Tx for ltru@megatron.ietf.org; Wed, 11 May 2005 00:16:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20952 for ; Wed, 11 May 2005 00:16:53 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVitw-0004Zg-Mm for ltru@ietf.org; Wed, 11 May 2005 00:32:54 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 21:16:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #941] determining currency of registry versions Date: Tue, 10 May 2005 21:16:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6849@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #941] determining currency of registry versions Thread-Index: AcVV3Sb1v9yBI5u9TkKxn8M+ZYGL1gAAnb4g From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 04:16:42.0849 (UTC) FILETIME=[3CA63D10:01C555E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org See below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?10? 20:55 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #941] determining currency of registry > versions >=20 > Hi - >=20 > (as a technical contributor) >=20 > > From: "Addison Phillips" > > To: "Randy Presuhn" ; "LTRU Working = Group" > > > Sent: Tuesday, May 10, 2005 9:03 AM > > Subject: RE: [Ltru] [psg.com #941] determining currency of registry > versions > > >=20 > > You can extract the codes without any reference to the registry > > (current or otherwise) based on length and position. >=20 > This still doesn't address the requirement from the charter that > "it is to provide a mechanism for easily determining whether a > particular subtag is valid as of a given date, without onerous > reconstruction of the state of the underlying standard > as of that time" [Addison Phillips]=20 Yes, it does. If you have a registry as of some date (File-Date record), = you can determine if a subtag is valid as at that date (or not)--or any = given date prior to that date. Subtags invalid as at that date may still = be well-formed. Note the careful use of the terms 'valid' and = 'well-formed'. An implementation CAN determine whether a subtag is valid = as of some given date prior to the registry date (the records in the = registry are dated, please note). You don't have to reconstruct ISO-xxxx = as you do today. >=20 > > The currency of the registry is determined by the File-Date field. > > The one on the IANA website is the most current. Ones with an > > older date than that one are not current. >=20 > The current (-01) text says: > The first record in the file contains the single field whose field- > name is "File-Date" and whose field-body contains the last > modification date of the registry: >=20 > Would it make sense to amend it to say something like: > The first record in the file contains the single field whose field- > name is "File-Date". The field-body contains the last > modification date of the registry. The currency of the registry > is determined by this field. The registry on the IANA website is > the most current. Versions with an older date than that one > are not current. [Addison Phillips]=20 We could do that, but it is redundant to do so, don't you think? What = version of the registry would be on the IANA website besides the most = current?!? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:25:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVimU-00089X-7q; Wed, 11 May 2005 00:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVimS-00089M-48 for ltru@megatron.ietf.org; Wed, 11 May 2005 00:25:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21575 for ; Wed, 11 May 2005 00:25:05 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVj1u-000515-6A for ltru@ietf.org; Wed, 11 May 2005 00:41:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 21:24:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation imposelengthconstraints? Date: Tue, 10 May 2005 21:24:58 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A684A@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #944] MAY a conformant implementation imposelengthconstraints? Thread-Index: AcVV3p04DNr7GREdQAmgIOxaGinRYwAAh4mw From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 04:24:58.0861 (UTC) FILETIME=[644BA9D0:01C555E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org MUST NOT would certainly be better IMO.=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?10? 21:06 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #944] MAY a conformant implementation > imposelengthconstraints? >=20 > Hi - >=20 > (as a technical contributor) >=20 > > From: "Addison Phillips" > > To: "Randy Presuhn" ; "LTRU Working = Group" > > > Sent: Tuesday, May 10, 2005 9:04 AM > > Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation > impose lengthconstraints? > > >=20 > > > > A conformant implementation MAY refuse to support the storage of > language > > tags which exceed a specified length. For an example, see [RFC 2231] > (Freed, > > N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: > > Character Sets, Languages, and Continuations," November 1997.)[22]. = Any > > such limitation MUST be clearly documented, and such documentation > > SHOULD include the disposition of any longer tags (for example, = whether > > an error value is generated or the language tag is truncated). If > truncation > > is permitted it SHOULD NOT permit a subtag to be divided. > > > ... >=20 > Thinking like an implementor, I'd find this of little help. I don't = see > how permitting truncation and permitting subtag division could = possibly > help interoperability. >=20 > I'd be more comfortable with "If truncation is permitted, it MUST NOT > permit a > subtag to be divided." >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:26:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVinI-0008Ak-Gf; Wed, 11 May 2005 00:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVinG-0008Af-VR for ltru@megatron.ietf.org; Wed, 11 May 2005 00:25:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21615 for ; Wed, 11 May 2005 00:25:56 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVj2j-000523-1g for ltru@ietf.org; Wed, 11 May 2005 00:41:57 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 21:25:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #944] MAY a conformant implementation impose length constraints? Date: Tue, 10 May 2005 21:25:49 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A684C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #944] MAY a conformant implementation impose length constraints? Thread-Index: AcVV4F5AXo/cTdWDTLOyHOKMDZgH4AAASEyA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 11 May 2005 04:25:49.0814 (UTC) FILETIME=[82AA7960:01C555E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org That makes sense. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?5?10? 21:03 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #944] MAY a conformant implementation = impose > length constraints? >=20 > Addison Phillips wrote: >=20 > > A conformant implementation MAY refuse to support the storage > > of language tags which exceed a specified length. For an > > example, see [RFC 2231] (Freed, N. and K. Moore, "MIME > > Parameter Value and Encoded Word Extensions: Character Sets, > > Languages, and Continuations," November 1997.)[22]. >=20 > The real problem is 2231 in conjunction with 2047 encoded > words, the 2047 limit 76 is not mentioned in 2231. Please > add RfC 2047. >=20 > While 2231 multiline-parameters are a pain they have almost > no length problems - in fact that's the idea of multiline > parameters, and any remaining limit 9?? (below 998) is no > real problem for LTRU. BTW, 998 is documented in RfC 2045, > not in RfC 2231. >=20 > > Any such limitation MUST be clearly documented, and such > > documentation SHOULD include the disposition of any longer > > tags (for example, whether an error value is generated or > > the language tag is truncated). If truncation is permitted > > it SHOULD NOT permit a subtag to be divided. >=20 > Please swap the MUST and the second SHOULD. It SHOULD be > clearly documented (and we know that this is not the case > from our POV for 2231 + 2047), and any truncation MUST at > least syntactically make sense, > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:36:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVixa-0001YI-KZ; Wed, 11 May 2005 00:36:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVixY-0001Vq-QB for ltru@megatron.ietf.org; Wed, 11 May 2005 00:36:36 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22367 for ; Wed, 11 May 2005 00:36:33 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVipy-0006Fe-TO for ltru@lists.ietf.org; Wed, 11 May 2005 06:28:47 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 06:28:46 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 06:28:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 06:35:19 +0200 Organization: Lines: 19 Message-ID: <42818B87.4C0A@xyzzy.claranet.de> References: <000401c555ab$ddce98c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> "All aliases are equally supported. Not all aliases are >> equally recommended." Unfortunately the draft does not yet follow what its sources recommend, it freezes not only registered tags, but also the status of their recommendation (aka "Canonical") in certain cases. The "canonical forever" concept is unnecessary and potentially harmful: If long deprecated 3166-1 tags are reused, but the registry still propagates some obsolete values as "canonical". "Canonical" and "Deprecated" should a far as possible reflect what the source standards define. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:47:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVj8N-0003Om-0T; Wed, 11 May 2005 00:47:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVj8K-0003O6-RF for ltru@megatron.ietf.org; Wed, 11 May 2005 00:47:44 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22997 for ; Wed, 11 May 2005 00:47:41 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511044713.YMHP13270.mta11.adelphia.net@DEWELL> for ; Wed, 11 May 2005 00:47:13 -0400 Message-ID: <002701c555e4$7b367c80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 21:47:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #933] Java support X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Consequently, this item is marked "rejected" I agree. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:48:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVj8z-0003PO-0X; Wed, 11 May 2005 00:48:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVj8s-0003PJ-Ew for ltru@megatron.ietf.org; Wed, 11 May 2005 00:48:18 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23013 for ; Wed, 11 May 2005 00:48:14 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVj1G-00071E-O0 for ltru@lists.ietf.org; Wed, 11 May 2005 06:40:26 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 06:40:26 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 06:40:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 06:46:55 +0200 Organization: Lines: 14 Message-ID: <42818E3F.65D6@xyzzy.claranet.de> References: <001301c555ac$84cd2560$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #957] compatibility of description format with ISO table format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> Comment 29 in message >> http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html Apparently that's something you already have as two separate issues, and if that's the case this ticket is "redundant": 1 - use source description as is not restricted to Latin-1 or Latn (IMHO we have rough consensus for this) 2 - use also the French names. After a poll you have already decided what to do with this part of the problem. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:51:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjBr-0003lx-6f; Wed, 11 May 2005 00:51:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjBp-0003ls-Hz for ltru@megatron.ietf.org; Wed, 11 May 2005 00:51:21 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23155 for ; Wed, 11 May 2005 00:51:18 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511045050.VRM8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 00:50:50 -0400 Message-ID: <002c01c555e4$fe765700$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 21:50:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA23155 Cc: Subject: [Ltru] Re: [psg.com #934] repertoire for descriptions in registry entries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > (1) whether to limit the repertoire that can be used > (a) to basic latin > (b) latin-1 I've changed my mind about this, and now support the ability to include any Latin-script letter in the registry. This topic always seems to lead to discussions about turning the registry into a comprehensive reference of localized names of languages and countries, so just in case it needs to be said, I reiterate my objection to that. > (2) whether to "correct" data brought over from ISO, such as > the use of an incorrect character reference for glottal stop. I remain convinced that the spacing acute accent in the official ISO 639 name "Gwich=C2=B4in" is an error, but I won't pursue the matter further. Frank is correct that if we start trying to "fix" these, it will be hard to know when to stop. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:52:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjDI-0003zk-5g; Wed, 11 May 2005 00:52:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjDG-0003xb-8O for ltru@megatron.ietf.org; Wed, 11 May 2005 00:52:50 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23233 for ; Wed, 11 May 2005 00:52:47 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511045219.YDM8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 00:52:19 -0400 Message-ID: <003101c555e5$3510eaa0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 21:52:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #935] is the word "indicate" in the abstract unclear? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Consequently, I've marked this one "rejected". I agree. The phrase "indicate the language" in the abstract has been there since RFC 1766 with no apparent widespread confusion. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:53:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjDX-000485-5i; Wed, 11 May 2005 00:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjDT-00047y-VB for ltru@megatron.ietf.org; Wed, 11 May 2005 00:53:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23268 for ; Wed, 11 May 2005 00:52:58 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVjSs-0006KY-SW for ltru@ietf.org; Wed, 11 May 2005 01:09:00 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVjDN-0006F4-00 for ltru@ietf.org; Tue, 10 May 2005 21:52:57 -0700 Message-ID: <002a01c555e5$a14d5a00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <000401c555ab$ddce98c0$7f1afea9@oemcomputer> <42818B87.4C0A@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally supported Date: Tue, 10 May 2005 21:54:53 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Could you suggest some specific replacement text that would address your concerns? Randy > From: "Frank Ellermann" > To: > Sent: Tuesday, May 10, 2005 9:35 PM > Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported > > Randy Presuhn wrote: > > >> "All aliases are equally supported. Not all aliases are > >> equally recommended." > > Unfortunately the draft does not yet follow what its sources > recommend, it freezes not only registered tags, but also the > status of their recommendation (aka "Canonical") in certain > cases. > > The "canonical forever" concept is unnecessary and potentially > harmful: If long deprecated 3166-1 tags are reused, but the > registry still propagates some obsolete values as "canonical". > > "Canonical" and "Deprecated" should a far as possible reflect > what the source standards define. > > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:54:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjEO-0004SV-1Q; Wed, 11 May 2005 00:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjEK-0004Qj-TW for ltru@megatron.ietf.org; Wed, 11 May 2005 00:53:58 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23414 for ; Wed, 11 May 2005 00:53:53 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511045325.LENW4191.mta13.adelphia.net@DEWELL> for ; Wed, 11 May 2005 00:53:25 -0400 Message-ID: <003601c555e5$5c6323c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 21:53:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #936] is the phrase "information object" in the abstract unclear? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > No one else had any problem with the phrase "information object", > and no alternative proposal was agreed, so I've marked this item > as "rejected". I agree. This term is intentionally general, and has been there since RFC 1766. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:55:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjFZ-0004gV-3N; Wed, 11 May 2005 00:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjFU-0004gC-3V for ltru@megatron.ietf.org; Wed, 11 May 2005 00:55:08 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23598 for ; Wed, 11 May 2005 00:55:04 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511045437.BAYJ8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 00:54:37 -0400 Message-ID: <003b01c555e5$87350dc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 21:54:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #937] is the word "interchange" in the abstract unclear? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > No one else on the WG mailing list had a problem with the word, > and no proposal for an alternative wording found support, so > I've marked this item as "rejected". I agree. "Interchange" is a common data-processing word, and not normally considered a source of confusion or ambiguity. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:56:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjH5-000516-3N; Wed, 11 May 2005 00:56:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjH3-00050y-Gi for ltru@megatron.ietf.org; Wed, 11 May 2005 00:56:45 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23716 for ; Wed, 11 May 2005 00:56:42 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511045614.GUDY17140.mta10.adelphia.net@DEWELL> for ; Wed, 11 May 2005 00:56:14 -0400 Message-ID: <004001c555e5$bfaec1a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 21:56:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #938] should introduction allude to intended bcp status? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > The question of whether the introduction to the registry draft > should allude to its intended BCP status was raised in comment #9 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > There was no support on the mailing list for this proposed change, > so the proposal is marked "rejected". No opinion. This is a process question, best settled between the chairs and editors. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:58:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjIp-0005GO-DX; Wed, 11 May 2005 00:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjIk-0005Fl-3X for ltru@megatron.ietf.org; Wed, 11 May 2005 00:58:32 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23767 for ; Wed, 11 May 2005 00:58:26 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511045758.LLTO4191.mta13.adelphia.net@DEWELL> for ; Wed, 11 May 2005 00:57:58 -0400 Message-ID: <004501c555e5$feb3dfc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 21:57:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #939] explain difference between tags and labels X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Comment #10 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > requested an explanation of the difference between the words > "tag" and "label". > > No one else seems to have trouble with these words, and no > replacement text was proposed, so I've marked this item "rejected". I agree. Neither the Introduction nor any other part of draft-00 or -01 "talks about labels" as stated. The draft does refer to using tags to "label" content, but that is hardly a confusing or inconsistent usage. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 00:59:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjK6-0005Ks-Sy; Wed, 11 May 2005 00:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjK2-0005Km-SM for ltru@megatron.ietf.org; Wed, 11 May 2005 00:59:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23843 for ; Wed, 11 May 2005 00:59:46 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVjZT-0006ex-QA for ltru@ietf.org; Wed, 11 May 2005 01:15:48 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVjJz-0007Z3-00 for ltru@ietf.org; Tue, 10 May 2005 21:59:47 -0700 Message-ID: <003501c555e6$957d8f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <001301c555ac$84cd2560$7f1afea9@oemcomputer> <42818E3F.65D6@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #957] compatibility of description format withISO table format Date: Tue, 10 May 2005 22:02:08 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Tuesday, May 10, 2005 9:46 PM > Subject: [Ltru] Re: [psg.com #957] compatibility of description format withISO table format > > Randy Presuhn wrote: > > >> Comment 29 in message > >> http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > Apparently that's something you already have as two separate > issues, and if that's the case this ticket is "redundant": > > 1 - use source description as is not restricted to Latin-1 or > Latn (IMHO we have rough consensus for this) > > 2 - use also the French names. After a poll you have already > decided what to do with this part of the problem. ... I thought the comment was about *format* compatibility, since it was in terms of the (IMO mistaken) notion that this information was an extension to the ISO specifications. The other two issues were about repertoire and translations. That's why I made it a separate item. However, I freely admit that figuring out the commits involved considerable guesswork, so I could well have gotten it wrong. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:00:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjKc-0005S8-JF; Wed, 11 May 2005 01:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjKZ-0005Rm-At for ltru@megatron.ietf.org; Wed, 11 May 2005 01:00:23 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23887 for ; Wed, 11 May 2005 01:00:22 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511045952.GXCO17140.mta10.adelphia.net@DEWELL> for ; Wed, 11 May 2005 00:59:52 -0400 Message-ID: <004a01c555e6$42babae0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 21:59:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #940] is the word "recognized" unclear in the syntax section? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > This question was issue number 11 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > There was no support on the mailing list for a change, so > this item is marked "rejected". I agree. The concept of a parser "recognizing" tokens is well-known, and would never be interpreted as "authoritative" except by intentional misreading. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:06:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjQE-0006Pw-0P; Wed, 11 May 2005 01:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjQ9-0006Nw-Fr for ltru@megatron.ietf.org; Wed, 11 May 2005 01:06:11 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24309 for ; Wed, 11 May 2005 01:06:08 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511050538.BLQM8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:05:38 -0400 Message-ID: <004f01c555e7$110b80a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:05:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #941] determining currency of registry versions X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > This issue was raised in item 12 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > A mechanism describing how one determines whether a registry > version is "current" needs to be spelled out. The registry contains a date *as of which* it is current. The only way to determine, just by looking at a registry version, whether it is "current" or whether it has been superseded would be to go back and mark it as such. While it would be possible to do this for files hosted by IANA (if non-current versions are made available there at all), it would be quite impossible for locally downloaded versions, which are implicitly encouraged in the last sentence of Section 6. > This is related to the charter requirement "For accessibility, > it is to provide a mechanism for easily > determining whether a particular subtag is valid as of a given date, > without onerous reconstruction of the state of the underlying standard > as of that time." Since this requirement refers to validity "as of a given date," the identification of each registry version by date seems sufficient. As stated above, it would be hard to imagine how anything beyond this could even be accomplished. > This is also somewhat related to the charter requirement > "It is expected to specify a mechanism for easily identifying the role > of each subtag in the language tag, so that, for example, whenever a > script code or country code is present in the tag it can be extracted, > even without access to a current version of the registry." > (This last phrase naturally leads one to ask the question, "how do I > know whether what I have is current.") It actually begs the question, since the whole premise is that you don't *need* to know whether what you have is current in order to classify the subtags. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:08:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjSd-0007Ts-VF; Wed, 11 May 2005 01:08:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjSc-0007Rb-MG for ltru@megatron.ietf.org; Wed, 11 May 2005 01:08:42 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24559 for ; Wed, 11 May 2005 01:08:41 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511050811.BOND8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:08:11 -0400 Message-ID: <005401c555e7$6bb29840$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:08:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #942] clarify advice on use of subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Comment #13 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > requests clarification of the advice on the use of subtags > in section 2.1.1 (of draft -00-) No comment. I've already expressed my objection to restrictions on the recommended use of subtags. The group's consensus was to recommend certain restrictions, and in particular to implement Suppress-Script, so I've accepted that and moved on. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:10:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjTw-0007rP-7o; Wed, 11 May 2005 01:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjTu-0007rE-56 for ltru@megatron.ietf.org; Wed, 11 May 2005 01:10:02 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24630 for ; Wed, 11 May 2005 01:10:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511050930.LSTR4191.mta13.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:09:30 -0400 Message-ID: <005901c555e7$9b4c4380$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:09:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #943] number of subtags SHOULD be limited to four X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Comment #14 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > requests that there should be language stating that the number > of subtags SHOULD be limited to four. I oppose any such limit as unnecessary and arbitrary. There is already wording in the draft to deal with situations where an application must truncate a tag due to space constraints. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:13:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjWq-0008Sw-Gr; Wed, 11 May 2005 01:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjWo-0008So-Rk for ltru@megatron.ietf.org; Wed, 11 May 2005 01:13:03 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24812 for ; Wed, 11 May 2005 01:13:01 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVjPF-0000En-Sv for ltru@lists.ietf.org; Wed, 11 May 2005 07:05:13 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 07:05:13 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 07:05:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 07:11:57 +0200 Organization: Lines: 13 Message-ID: <4281941D.41E8@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: RFC 2277 - considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Misha Wolf wrote: > Could we set up a separate list called, say, ltru-jfc, > where Jefsey could talk to himself? Apparently at least Randy would have to read this list, because these points will be rehashed in Jefsey's future appeal. Randy and Martin need to know where the WG will support their decisions. Let them just share this "fun" as they see fit, it could be worse. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:14:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjYM-0000Df-Nb; Wed, 11 May 2005 01:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjYI-0000BX-Kv for ltru@megatron.ietf.org; Wed, 11 May 2005 01:14:36 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25036 for ; Wed, 11 May 2005 01:14:33 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511051403.HOPL17140.mta10.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:14:03 -0400 Message-ID: <005e01c555e8$3dc7b900$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:13:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #944] MAY a conformant implementation impose length constraints? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Comment #15 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > asks whether an implementation that imposes length constraints > would still be considered conformant, and, if so, what constraints > would be permissible. Actually, it does not ask that. This comment is simply playing with words, and should be rejected as frivolous. Draft-00 says, "A conformant implementation need not support the storage of tags which exceed a specified length." Comment #15 asks about "an application not supporting a NON specified length" (my emphasis). Obviously the burden of specifying a maximum supported length is on the application itself, and any application that truncates tags arbitrarily, at a length known only to itself, violates the "clearly documented" provision of Section 2.1.1. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:16:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjZt-0000bj-3X; Wed, 11 May 2005 01:16:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjZr-0000be-On for ltru@megatron.ietf.org; Wed, 11 May 2005 01:16:11 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25161 for ; Wed, 11 May 2005 01:16:10 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511051540.HQPW17140.mta10.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:15:40 -0400 Message-ID: <006301c555e8$7798bf80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:15:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #945] use "." to separate subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Comment #16 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > suggests that "." should be used as a separater. > > Subsequent discussion found no support for and much opposition to > this proposal. A detailed response is in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html I agree. Changing the hyphen separator to a dot or anything else would break all compatibility with RFC 1766 and 3066, which would be a critical violation of both the charter and common sense. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:18:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjcX-00014i-1k; Wed, 11 May 2005 01:18:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjcV-00014W-9Z for ltru@megatron.ietf.org; Wed, 11 May 2005 01:18:55 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25394 for ; Wed, 11 May 2005 01:18:53 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511051823.LYNA4191.mta13.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:18:23 -0400 Message-ID: <006801c555e8$d906c3c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510144234.LCSR17200.mta1.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:18:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #946] use of both length and position to identify subtag problematic X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org [psg.com #946] use of both length and position to identify subtag problematic > Comment #17 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > states that the use of both length and position to identify > subtags would be problematic. It's not hard at all. > A response to this concern is in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > No alternative garnered significant support. No alternative was even proposed. > Can we mark this one "rejected"? Please do. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:19:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjdG-0001Af-Kr; Wed, 11 May 2005 01:19:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjdF-0001AS-1x for ltru@megatron.ietf.org; Wed, 11 May 2005 01:19:41 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25425 for ; Wed, 11 May 2005 01:19:39 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511051909.LYXU4191.mta13.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:19:09 -0400 Message-ID: <006d01c555e8$f4534a40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510144234.LCSR17200.mta1.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:19:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #947] is set of possible primary languages too constrained? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > I've marked this rejected, ok? Agreed. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:21:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjeh-0001L9-Jr; Wed, 11 May 2005 01:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjeg-0001L1-6s for ltru@megatron.ietf.org; Wed, 11 May 2005 01:21:10 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25513 for ; Wed, 11 May 2005 01:21:08 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511052039.HWWY17140.mta10.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:20:39 -0400 Message-ID: <007201c555e9$29874900$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510144234.LCSR17200.mta1.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:20:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #948] deprecate two-letter language codes in favor of three-letter ones X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > This proposal was withdrawn in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00717.html > > Consequently, I've marked it "rejected." I don't see the part where the proposal was withdrawn, but I agree very strongly with rejecting it. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:25:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjiV-000271-Dd; Wed, 11 May 2005 01:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjiU-00026s-8A for ltru@megatron.ietf.org; Wed, 11 May 2005 01:25:06 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25837 for ; Wed, 11 May 2005 01:25:04 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511052434.MBKH4191.mta13.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:24:34 -0400 Message-ID: <007701c555e9$b61b23a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510144234.LCSR17200.mta1.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:24:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #949] remove three-character limit in sections 2.2.2, 2.2.3 (of -00) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Comments 20 and 21 of message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > both focus on the length constraints in sections 2.2.2 and 2.2.3 of > the -00 draft. > > There is some followup on this question in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html No opinion on Comment 20, since I'm in no position to judge the stability of the 3-character architecture in the ISO 639-3 draft. Others who are in a better position to judge have told us it is very stable. I strongly disagree with Comment 21. There is no evidence that the syntactical structure of ISO 15924 or any of the other core standards is likely to change. The remark about "the memory waste of ISO 15924 (3 bytes lost)" is particularly confusing, since there are already more than 100 assigned code elements in ISO 15924 and the code elements are limited to A through Z (so at least 2 letters would be needed in any event). -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:28:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjlx-0002s9-04; Wed, 11 May 2005 01:28:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjlv-0002s1-2E for ltru@megatron.ietf.org; Wed, 11 May 2005 01:28:39 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25950 for ; Wed, 11 May 2005 01:28:37 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511052807.IJPP17140.mta10.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:28:07 -0400 Message-ID: <008201c555ea$34d4d9c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510180743.JSWJ13001.mta6.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:28:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: RFC 2277 - considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > Should we adopt the general course of action outlined below by > Jefsey? I'm not looking for point-by-point responses at this time, > just a succinct "yes, let's adopt the general approach Jefsey > proposed," "no, let's not go down that path," or "I'd like to hear > more discussion of his proposal before deciding." No, let's not go down that path. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:34:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjs1-000406-FA; Wed, 11 May 2005 01:34:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjrz-0003zK-0Z for ltru@megatron.ietf.org; Wed, 11 May 2005 01:34:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26358 for ; Wed, 11 May 2005 01:34:50 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVk7O-0008QW-9P for ltru@ietf.org; Wed, 11 May 2005 01:50:50 -0400 Received: from lns-p19-4-idf-82-65-244-40.adsl.proxad.net ([82.65.244.40] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVjru-0006dp-8n for ltru@ietf.org; Tue, 10 May 2005 22:34:50 -0700 Message-Id: <6.2.1.2.2.20050511072811.057fa130@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 07:29:18 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #937] is the word "interchange" in the abstract unclear? In-Reply-To: <003b01c555e5$87350dc0$030aa8c0@DEWELL> References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> <003b01c555e5$87350dc0$030aa8c0@DEWELL> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2025457044==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============2025457044== Content-Type: multipart/alternative; boundary="=====================_101877552==.ALT" --=====================_101877552==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed On 06:54 11/05/2005, Doug Ewell said: > > No one else on the WG mailing list had a problem with the word, > > and no proposal for an alternative wording found support, so > > I've marked this item as "rejected". > >I agree. "Interchange" is a common data-processing word, and not >normally considered a source of confusion or ambiguity. 1: a junction of highways on different levels that permits traffic to move from one to another without crossing traffic streams 2: mutual interaction; the activity of interchanging or reciprocating [syn: reciprocation, give-and-take] 3: reciprocal transfer of equivalent sums of money especially the currencies of different countries; "he earns his living from the interchange of currency" [syn: exchange] --=====================_101877552==.ALT Content-Type: text/html; charset="us-ascii" On 06:54 11/05/2005, Doug Ewell said:
> No one else on the WG mailing list had a problem with the word,
> and no proposal for an alternative wording found support, so
> I've marked this item as "rejected".

I agree.  "Interchange" is a common data-processing word, and not
normally considered a source of confusion or ambiguity.


1: a junction of highways on different levels that permits traffic to move from one to another without crossing traffic streams
2: mutual interaction; the activity of interchanging or reciprocating [syn: reciprocation, give-and-take]
3: reciprocal transfer of equivalent sums of money especially the currencies of different countries; "he earns his living from the interchange of currency" [syn: exchange ]
--=====================_101877552==.ALT-- --===============2025457044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2025457044==-- From ltru-bounces@lists.ietf.org Wed May 11 01:45:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVk2P-0006UE-3t; Wed, 11 May 2005 01:45:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVk2N-0006Tv-Nz for ltru@megatron.ietf.org; Wed, 11 May 2005 01:45:39 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27461 for ; Wed, 11 May 2005 01:45:38 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511054501.IYMG17140.mta10.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:45:01 -0400 Message-ID: <008901c555ec$8707b800$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:44:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #950] iso 3166 inadequate for regional variants X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > This comes from comment 22 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > which states: > > "22. 2.2.4: I understand that all the regional language differences of > the world are to be supported by the ISO 3166 alpha-3/digit-3 list. > This means that regions like NY, TX or California are not entitled a > code but the 56 persons of Pitcairn Island yes? I doubt that disparity > can hold very long, all the more than ISO 3166-2 provides all the > possibilities for a far more adequate granularity." > > As pointed out in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > the draft also supports UN M.49 digit-3 codes > > Based on recent discussion, can I close this with a "reject"? I agree to reject. But I think this one needs some comment, since I was once a supporter of ISO 3166-2 in language tags, and have often cited regional differences in en-US as potentially worthy of tagging. Neither ISO 3166-2 nor any other geographic coding system -- UN/LOCODE, MARC 21, FIPS 10-4, HASC, any of them -- can partition the world perfectly and unequivocally in terms of language variation, partly because experts will never agree completely on what constitutes a "significant" language variation, and partly because such systems never guarantee equality as to the area or population of the encoded regions. ISO 3166-2 assigns a single code to California (population 33 million) and another to New York state (population 19 million), but it also assigns 21 codes to the Bahamas (population 303,000) -- one for each of the pre-1996 districts. This is far from ideal in terms of providing consistent coding granularity. Other geocoding systems have similar limitations. ISO 3166-2 also suffers from inadequate stability for the type of tagging mechanism described in the draft. Code elements are added, removed, and changed (both description and code element) with little or no publicity. Occasionally the entire subdivision structure on which ISO 3166-2 code elements are based is thrown out and replaced with a new one; this happened with Libya in 2003 and Slovenia in 2002. Variant subtags can always be proposed to distinguish regional differences in language that cannot be described adequately with ISO 3166-1 and UN M.49 region subtags. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:47:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVk3x-0007CW-9J; Wed, 11 May 2005 01:47:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVk3u-0007BF-Pb for ltru@megatron.ietf.org; Wed, 11 May 2005 01:47:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27626 for ; Wed, 11 May 2005 01:47:13 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVkJA-0000fi-BF for ltru@ietf.org; Wed, 11 May 2005 02:03:01 -0400 Received: from h-68-164-241-240.snvacaid.dynamic.covad.net ([68.164.241.240] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVk3f-0003hF-00 for ltru@ietf.org; Tue, 10 May 2005 22:46:59 -0700 Message-ID: <000b01c555ed$2d818440$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B5A6849@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #941] determining currency of registry versions Date: Tue, 10 May 2005 22:49:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, May 10, 2005 9:16 PM > Subject: RE: [Ltru] [psg.com #941] determining currency of registry versions ... > An implementation > CAN determine whether a subtag is valid as of some given date prior to the > registry date (the records in the registry are dated, please note). > You don't have to reconstruct ISO-xxxx as you do today. This is the important point, and satisfies my query. ... >> Would it make sense to amend it to say something like: >> The first record in the file contains the single field whose field- >> name is "File-Date". The field-body contains the last >> modification date of the registry. The currency of the registry >> is determined by this field. The registry on the IANA website is >> the most current. Versions with an older date than that one >> are not current. >[Addison Phillips] > > We could do that, but it is redundant to do so, don't you think? > What version of the registry would be on the IANA website besides > the most current?!? The last sentence was intended to include not only versions on the IANA website, but those that might end up on mirrors and the like. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:49:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVk6J-0007h8-JJ; Wed, 11 May 2005 01:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVk6H-0007h0-Pf for ltru@megatron.ietf.org; Wed, 11 May 2005 01:49:41 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27744 for ; Wed, 11 May 2005 01:49:37 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511054907.JBFS17140.mta10.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:49:07 -0400 Message-ID: <008e01c555ed$1fd21940$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:48:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #951] extensibility via codes not maintained by ISO X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Comments 45 and 53 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > raise the question of supporting language, country, and region > codes not maintained by ISO. I propose rejecting this item. Language subtags can be registered in the unlikely event that the various flavors of ISO 639 completely miss a language. Variant subtags can be registered to capture scripts or regions that are inexplicably not covered by ISO 15924, ISO 3166, or UN M.49. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:53:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVk9X-0008Gx-1D; Wed, 11 May 2005 01:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVk9U-0008Gp-RA for ltru@megatron.ietf.org; Wed, 11 May 2005 01:53:00 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27908 for ; Wed, 11 May 2005 01:52:59 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511055229.DRJA8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:52:29 -0400 Message-ID: <009301c555ed$9957b7c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:52:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This proposal should be rejected. In addition, the accusations of treachery and skulduggery are completely uncalled for. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkAR-00006D-Kx; Wed, 11 May 2005 01:53:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkAQ-000061-Gj for ltru@megatron.ietf.org; Wed, 11 May 2005 01:53:58 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28020 for ; Wed, 11 May 2005 01:53:56 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511055327.DSDW8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:53:27 -0400 Message-ID: <009801c555ed$bd31e120$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:53:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #953] change process for handling registration requests X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > There was no support for this proposal, so it is marked "rejected." I agree. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:58:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkF8-0000kY-F9; Wed, 11 May 2005 01:58:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkF7-0000kP-8O for ltru@megatron.ietf.org; Wed, 11 May 2005 01:58:49 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28309 for ; Wed, 11 May 2005 01:58:47 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511055817.BDQZ13270.mta11.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:58:17 -0400 Message-ID: <009d01c555ee$67fc69e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:58:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Comment 25 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > says: "25. 2.3: recommendation 3 seems inappropriate. Aliases are > aliases. All the > aliases must be equally supported because (a) they are aliases (b) to > make > sure developers develops correct code." > > Discussion clarified that the intent is > "All aliases are equally supported. Not all aliases are equally > recommended." > see http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html I agree with the clarified intent. Tag parsers must recognize all aliases as equivalent. Tag generators, however, may be required to generate canonical subtags rather than aliases. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 01:59:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkGB-0000wW-VF; Wed, 11 May 2005 01:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkGA-0000wH-4c for ltru@megatron.ietf.org; Wed, 11 May 2005 01:59:54 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28395 for ; Wed, 11 May 2005 01:59:52 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511055922.NFXN4191.mta13.adelphia.net@DEWELL> for ; Wed, 11 May 2005 01:59:22 -0400 Message-ID: <00a201c555ee$90520940$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 22:59: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #955] expand scope to include computer languages X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Reject, reject, reject. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 02:02:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkIf-0001w3-NS; Wed, 11 May 2005 02:02:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkIe-0001vy-2w for ltru@megatron.ietf.org; Wed, 11 May 2005 02:02:28 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01009 for ; Wed, 11 May 2005 02:02:26 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511060156.NIAW4191.mta13.adelphia.net@DEWELL> for ; Wed, 11 May 2005 02:01:56 -0400 Message-ID: <00a701c555ee$eb7f67e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050511035558.NWOB28811.mta8.adelphia.net@megatron.ietf.org> Date: Tue, 10 May 2005 23:01:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #956] document use of "" as deprecation indicator X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This item is moot, since the dash-dash convention to indicate a deprecated subtag with no canonical equivalent did not survive the transition to record-jar. Well, that should be enough to fill a couple of digests. More later. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 02:44:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkxd-0001tS-GB; Wed, 11 May 2005 02:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkxb-0001tJ-8w for ltru@megatron.ietf.org; Wed, 11 May 2005 02:44:47 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06671 for ; Wed, 11 May 2005 02:44:44 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVkq5-00081G-EZ for ltru@lists.ietf.org; Wed, 11 May 2005 08:37:01 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 08:37:01 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 08:37:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 08:38:49 +0200 Organization: Lines: 94 Message-ID: <4281A879.12A2@xyzzy.claranet.de> References: <000401c555ab$ddce98c0$7f1afea9@oemcomputer> <42818B87.4C0A@xyzzy.claranet.de> <002a01c555e5$a14d5a00$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > Could you suggest some specific replacement text that would > address your concerns? It was point (4) of five on my ToDo list in: For point (1) Doug and Addison apparently prefer to get an RfC for the registry draft _before_ discussing the final draft registry (i.e. determine more / other Suppress-Scripts). That strategy surprised me, but it could be a good idea for my point (5) in: Point (2) is actually something for you, I wanted a SHOULD with rationale for the Suppress-Script issue, you found that what I want is in fact a "MUST NOT unless" with rationale, and that's still missing in draft -01. That leaves point (4) "canonical", and admittedly I was too lazy to find all occurences of "canonical" in the text so far. An incomplete attempt: Line 512, stick to canonical alpha-3 tag even if an alpha-2 is added => no problem, that only tries to avoid unnecessary aliases. Line 630, UN region numbers are the final canonical value for any given region with "ambiguous" alpha-2 codes => okay. Line 1088, never add Canonical => delete Line 1089, never modify Canonical => delete That's the paragraph defining the problematic "canonical forever" concept, it should be deleted. Line 1095: get rid of "STRONGLY" (fourth reminder, IIRC) Line 1112: - Although valid in language tags, subtags and tags with a 'Deprecated' - field are deprecated and validating processors SHOULD NOT generate - these subtags. Note that a record that contains a 'Deprecated' field - and no corresponding 'Canonical' field has no replacement mapping. + + Although valid in language tags, subtags and tags with a 'Deprecated' + field SHOULD NOT be generated by validating processor. Note hat a + record that contains a 'Deprecated' field and no corresponding + 'Canonical' field has no replacement mapping. + + Future updates of the source standards may replace former canonical + tags by new tags. In that case the old tag is marked as 'Deprecated' + with a pointer to the the new tag in the 'Canonical' field. Pointers + to the old canonical value in other tags are updated. Validating + processors SHOULD use the the most recent registry. The latter SHOULD is no new restriction, it was always implied. Line 1242: | Values in the fields 'Type', 'Subtag', 'Tag', 'Added' and | 'Canonical' MUST NOT be changed and are guaranteed to be | stable over time. s/'Added' and 'Canonical'/and 'Added'/ In theory we hope that that 'Deprecated' is guaranteed to be stable, but in practice not mentioning this allows Murphy to rule and SNAFU on the side of the source standards. Line 1277 - 1297: Modify the procedures for withdrawn / added tags to be reflected as deprecated / canonical in the registry. Remove IM example (it could be still correct dependig on how we want to handle the introduction of alpha-2 codes for regions formerly only known by their number, but it's no example for "canonical reflects the sources"). BTW, if GG and JE would be added this cries for a judgement call. Insisting on 830 as a canonical value for both GG and JE would be ridiculous. And not reflect Doug's undocumented "same piece of land" concept. Etc., e.g. line 1355, there are more lies, where the "canonical forever" concept is just wrong, forcing users to consider an obsolete tag for their region as "canonical" will never fly. I would never follow this idea no matter what any "least common practice" states. It's ZW, not RH. If I look into the source standard I want a decent chance to guess what the canonical tag might be without unnecessary surprises in the 3066bis registry. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 03:48:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVlxT-0004FJ-4c; Wed, 11 May 2005 03:48:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVlxR-0004E3-EY for ltru@megatron.ietf.org; Wed, 11 May 2005 03:48:41 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10729 for ; Wed, 11 May 2005 03:48:38 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVlpx-0006tE-Lf for ltru@lists.ietf.org; Wed, 11 May 2005 09:40:57 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 09:40:57 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 09:40:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 09:42:12 +0200 Organization: Lines: 31 Message-ID: <4281B754.676B@xyzzy.claranet.de> References: <001301c555ac$84cd2560$7f1afea9@oemcomputer> <42818E3F.65D6@xyzzy.claranet.de> <003501c555e6$957d8f00$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] BCP forever (was: [psg.com #957]) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I freely admit that figuring out the commits involved > considerable guesswork, so I could well have gotten it wrong. You extracted sense out of what I considered as nebulous rants. It's not that I generally disagree with Jefsey: Of course homographs in IDNs are bad, but that's irrelevant here. Of course a concept of regions based only on country codes is stupid for say the US or GB, but if we want to be compatible with 3066 we're damned to stick to it. Of course before Unicode scripts where less important, but now is now, and all these funny charsets will be soon only "legacy" - in HTML 4 and later that's already the case. In theory I could create a text/html mail, declare a Greek or Cyril charset, and then use only NCRs for Korean. Not exactly conforming to "W3C charmod", but otherwise perfectly legal and valid. But for one point in Jefsey's numerous objections I'm still curious: If we already know that there will be a 3066ter to get the 7000+ languages, is it really necessary to stick to the "BCP 47" concept ? The normal standards track procedure would allow 3066bis = proposed, 3066ter = draft, and if they still like it a full standard later. I've a serious problem with all kinds of "forever", a "once BCP, always BCP" strikes me as odd for something that didn't survive five years like 3066. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 04:30:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVmbv-0003DN-2W; Wed, 11 May 2005 04:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVmbt-0003DF-6b for ltru@megatron.ietf.org; Wed, 11 May 2005 04:30:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12787 for ; Wed, 11 May 2005 04:30:26 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVmTl-0003H2-Dq for ltru@lists.ietf.org; Wed, 11 May 2005 10:22:10 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 10:22:05 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 10:22:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 10:26:17 +0200 Organization: Lines: 34 Message-ID: <4281C1A9.1093@xyzzy.claranet.de> References: <00b701c55851$adefdb20$7f1afea9@oemcomputer> <42808AFD.3198@xyzzy.claranet.de> <4280E96D.A33C1DCF@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #946] use of both length and position toidentify subtag problematic X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Marion Gunn wrote: > Is that an argument for replacing hypens with underlines? No. Or is this an idea to build groups of sub-subtags with an intra-subtag separator ? That could make sense for the case "one or more extlang". What we have is (example): lng-exa-exb-exc-exd-Latn-ZZ With an "extlang group": lng-exa:exb:exc:exd-Latn-ZZ One consequence would be, that the subtag length limit is then 15 for a maximum four extlang sub-substags. For an "extlang group" the lenghts are 3, 7, 11, and 15. No problem if we disallow length 7 for variants and any future registered-lang. One variant "gaulish" already has length 7, so we better pick an unambiguous sub-separator, anything is possible, colon, dot, underscore, etc. (excl. hyphen/alpha/digit). But that's then unfortuately not more 3066 compatible. Dreaming about simply declaring 3066 as historic FUBAR. Okay, back to reality, one of the ugly like hell hacks, the only interesting "group" are the extlangs. That's 3ALPHA. So we could abuse "0" as sub-separator: lng-exa0exb0exc0exd-Latn-ZZ But then we would have a serious problem with "gaulish". Sigh, I give up. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 04:49:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVmul-00074v-9F; Wed, 11 May 2005 04:49:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVmuk-00074q-1O for ltru@megatron.ietf.org; Wed, 11 May 2005 04:49:58 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14027 for ; Wed, 11 May 2005 04:49:54 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVmml-0005ZY-8V for ltru@lists.ietf.org; Wed, 11 May 2005 10:41:43 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 10:41:43 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 10:41:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 10:46:40 +0200 Organization: Lines: 15 Message-ID: <4281C670.5896@xyzzy.claranet.de> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <009301c555ed$9957b7c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > the accusations of treachery and skulduggery are completely > uncalled for. What are you talking about ? You haven't quoted any context, and I don't find the Message-ID in the References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> Outlook isn't suited for Internet usage, but this References issue must be something else, a broken gateway somewhere (?) Puzzled, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 08:13:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVq44-0003FM-VH; Wed, 11 May 2005 08:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVq43-0003FF-H5 for ltru@megatron.ietf.org; Wed, 11 May 2005 08:11:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27374 for ; Wed, 11 May 2005 08:11:45 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVqJY-00034R-JH for ltru@ietf.org; Wed, 11 May 2005 08:27:49 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4BCBVHL001295; Wed, 11 May 2005 08:11:32 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 11 May 2005 08:11:27 -0400 Date: Wed, 11 May 2005 08:11:27 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] BCP forever (was: [psg.com #957]) Message-ID: <20050511121126.GA14557@skunk.reutershealth.com> References: <001301c555ac$84cd2560$7f1afea9@oemcomputer> <42818E3F.65D6@xyzzy.claranet.de> <003501c555e6$957d8f00$7f1afea9@oemcomputer> <4281B754.676B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4281B754.676B@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > But for one point in Jefsey's numerous objections I'm still > curious: If we already know that there will be a 3066ter to > get the 7000+ languages, is it really necessary to stick to > the "BCP 47" concept ? The normal standards track procedure > would allow 3066bis = proposed, 3066ter = draft, and if they > still like it a full standard later. It's not really necessary to use the draft/proposed/full standard machinery just to add stuff to a registry, even a whole mountain of stuff. Nothing really changes except for activating the extlang option, which we are already discussing. > I've a serious problem with all kinds of "forever", a "once > BCP, always BCP" strikes me as odd for something that didn't > survive five years like 3066. The point of a BCP is that no staged implementation is necessary. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com And now here I was, in a country where a right to say how the country should be governed was restricted to six persons in each thousand of its population. For the nine hundred and ninety-four to express dissatisfaction with the regnant system and propose to change it, would have made the whole six shudder as one man, it would have been so disloyal, so dishonorable, such putrid black treason. --Mark Twain's Connecticut Yankee _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 08:31:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVqNE-0007Ln-48; Wed, 11 May 2005 08:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVqNC-0007If-4k for ltru@megatron.ietf.org; Wed, 11 May 2005 08:31:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29312 for ; Wed, 11 May 2005 08:31:32 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVqch-0004D6-KF for ltru@ietf.org; Wed, 11 May 2005 08:47:36 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4BCVLKO001398; Wed, 11 May 2005 08:31:21 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 11 May 2005 08:31:18 -0400 Date: Wed, 11 May 2005 08:31:18 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #946] use of both length and position toidentify subtag problematic Message-ID: <20050511123118.GB14557@skunk.reutershealth.com> References: <00b701c55851$adefdb20$7f1afea9@oemcomputer> <42808AFD.3198@xyzzy.claranet.de> <4280E96D.A33C1DCF@egt.ie> <4281C1A9.1093@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4281C1A9.1093@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > What we have is (example): lng-exa-exb-exc-exd-Latn-ZZ > With an "extlang group": lng-exa:exb:exc:exd-Latn-ZZ > > One consequence would be, that the subtag length limit > is then 15 for a maximum four extlang sub-substags. And unfortunately RFC 3066 limits us to 8 characters per subtag. One of our constraints is RFC 3066 compatibility, so all such tricks involving ad hoc separators are out. In any case, I think four extlang tags is well beyond the limit of plausibility. Even two is unlikely: that would require that one of the 360+ 639-3 individual languages that are encompassed by a macrolanguage is changed in the future to itself be a macrolanguage. As I have noted, ISO 639-3 is based on an extreme "splitter" (as opposed to "lumper") view of language distinctions, so further splits are unlikely. -- Knowledge studies others / Wisdom is self-known; John Cowan Muscle masters brothers / Self-mastery is bone; jcowan@reutershealth.com Content need never borrow / Ambition wanders blind; www.ccil.org/~cowan Vitality cleaves to the marrow / Leaving death behind. --Tao 33 (Bynner) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 08:35:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVqQg-0007fb-Fr; Wed, 11 May 2005 08:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVqQf-0007fW-55 for ltru@megatron.ietf.org; Wed, 11 May 2005 08:35:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29480 for ; Wed, 11 May 2005 08:35:07 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVqgB-0004Lv-Gw for ltru@ietf.org; Wed, 11 May 2005 08:51:11 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4BCYx5t001416; Wed, 11 May 2005 08:34:59 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 11 May 2005 08:35:01 -0400 Date: Wed, 11 May 2005 08:35:00 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed? Message-ID: <20050511123500.GC14557@skunk.reutershealth.com> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <009301c555ed$9957b7c0$030aa8c0@DEWELL> <4281C670.5896@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4281C670.5896@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > Doug Ewell wrote: > > > the accusations of treachery and skulduggery are completely > > uncalled for. > > What are you talking about ? You haven't quoted any context, > and I don't find the Message-ID in the References: See http://www1.ietf.org/mail-archive/web/ltru/current/msg01571.html , which quotes the relevant bit of http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html . -- John Cowan http://www.ccil.org/~cowan You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! `Tis a Jute.... (Finnegans Wake 16.5) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 09:51:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrc8-00068Q-SO; Wed, 11 May 2005 09:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrc6-00068L-W3 for ltru@megatron.ietf.org; Wed, 11 May 2005 09:51:03 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04896 for ; Wed, 11 May 2005 09:51:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511135030.ZONZ8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 09:50:30 -0400 Message-ID: <019501c55630$56c38400$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050511121435.QAUT13001.mta6.adelphia.net@megatron.ietf.org> Date: Wed, 11 May 2005 06:50:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > For point (1) Doug and Addison apparently prefer to get an > RfC for the registry draft _before_ discussing the final > draft registry (i.e. determine more / other Suppress-Scripts). I have never, ever argued in favor of making the registry draft an RFC. Check the archives. At some times I have argued against it; at other times I have shrugged and said "whatever." What I did propose is that we stop fussing over the minute details of the contents of the registry and focus on the draft itself, as we are doing right now. If we wait until the Suppress-Script entries are perfect before moving the draft to Last Call, we'll never get done. > BTW, if GG and JE would be > added this cries for a judgement call. Insisting on 830 as a > canonical value for both GG and JE would be ridiculous. And > not reflect Doug's undocumented "same piece of land" concept. You still haven't read what I wrote on 2005-04-24: http://www1.ietf.org/mail-archive/web/ltru/current/msg01389.html To repeat, the "same piece of land" concept I mentioned months ago was ONLY meant for establishing the relationship between deprecated region subtags and their canonical equivalents (if any). It explained why BU was mapped to MM but DD was not mapped to DE. You convinced us that following ISO 3166-3 strictly was a better idea, and that is what the registry now does. Please do not bring up this historical relic again. Thank you. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 10:03:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrnp-00009Q-Jl; Wed, 11 May 2005 10:03:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrno-00009L-5k for ltru@megatron.ietf.org; Wed, 11 May 2005 10:03:08 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05716 for ; Wed, 11 May 2005 10:03:05 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050511140236.GSK8952.mta9.adelphia.net@DEWELL> for ; Wed, 11 May 2005 10:02:36 -0400 Message-ID: <01b001c55632$024a3b60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050511121435.QAUT13001.mta6.adelphia.net@megatron.ietf.org> Date: Wed, 11 May 2005 07:02:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> the accusations of treachery and skulduggery are completely >> uncalled for. > > What are you talking about ? You haven't quoted any context, I'm deliberately trying to keep the responses short. They can be identified by ticket number (952 in this case). I thought this was what Randy wanted, and I'm certainly trying not to contribute to the quotational overload. The message I was responding to is at http://www1.ietf.org/mail-archive/web/ltru/current/msg01571.html. > and I don't find the Message-ID in the References: > > <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> > > Outlook isn't suited for Internet usage, but this References > issue must be something else, a broken gateway somewhere (?) I receive and reply to the Digest. If you see a mysterious Message-ID, it probably refers to the Digest, not an individual message. In the case of my responses to these tickets, just look for Randy's original message, where the Subject line starts with "[psg.com #xxx]" with no "Re:". -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 10:04:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrpO-0000H7-09; Wed, 11 May 2005 10:04:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrpL-0000Gt-P5 for ltru@megatron.ietf.org; Wed, 11 May 2005 10:04:44 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05949 for ; Wed, 11 May 2005 10:04:40 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVrg9-0003db-Ry for ltru@lists.ietf.org; Wed, 11 May 2005 15:55:13 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 15:55:13 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 15:55:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 15:57:17 +0200 Organization: Lines: 15 Message-ID: <42820F3D.2C9F@xyzzy.claranet.de> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <009301c555ed$9957b7c0$030aa8c0@DEWELL> <4281C670.5896@xyzzy.claranet.de> <20050511123500.GC14557@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > See > http://www1.ietf.org/mail-archive/web/ltru/current/msg01571.html Tnx, the (quote) "disguised way, concerted with ISO, to block names" (unquote). For more "fun" see the general IETF list: Fortunately Randy commented this [***] before I had a chance to post an article about the resident [***] in every WG, and that it could be worse. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 10:59:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgf-0002zv-Ai; Wed, 11 May 2005 10:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgd-0002zI-41 for ltru@megatron.ietf.org; Wed, 11 May 2005 10:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10917 for ; Wed, 11 May 2005 10:59:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVsw8-0003IM-ET for ltru@ietf.org; Wed, 11 May 2005 11:15:50 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVsgU-0006W0-ME; Wed, 11 May 2005 07:59:39 -0700 Message-Id: <6.2.1.2.2.20050511143942.05802c30@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 14:42:25 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #955] expand scope to include computer languages In-Reply-To: <00a201c555ee$90520940$030aa8c0@DEWELL> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <00a201c555ee$90520940$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 07:59 11/05/2005, Doug Ewell wrote: >Reject, reject, reject. Great. Then please stop this "Doug Ewell wrote:" computer originated script. In case you did not bother to read the comment ill quoted by Randy, this is what you reject^3. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 10:59:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgf-00030O-JJ; Wed, 11 May 2005 10:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgd-0002zJ-An for ltru@megatron.ietf.org; Wed, 11 May 2005 10:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10920 for ; Wed, 11 May 2005 10:59:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVsw8-0003IA-J9 for ltru@ietf.org; Wed, 11 May 2005 11:15:50 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVsgR-0006W0-OL; Wed, 11 May 2005 07:59:36 -0700 Message-Id: <6.2.1.2.2.20050511143223.05800580@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 14:36:46 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #951] extensibility via codes not maintained by ISO In-Reply-To: <008e01c555ed$1fd21940$030aa8c0@DEWELL> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <008e01c555ed$1fd21940$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 07:48 11/05/2005, Doug Ewell wrote: > > Comments 45 and 53 in message > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > raise the question of supporting language, country, and region > > codes not maintained by ISO. > >I propose rejecting this item. Good! A part from opposing the charter, it definitly deprecates this WG proposition. This clarifies the issue. FYI there are three international standardisation organisations, where ISO if for everything but Electricity and Communications. We will therefore be able to resort to ITU standards. >Language subtags can be registered in the unlikely event that the various >flavors of ISO 639 completely miss a language. Variant subtags can be >registered to capture scripts or regions that are inexplicably not covered >by ISO 15924, ISO 3166, or UN M.49. Most of the used charsets (sorry, "scripts") in use and part of the Internet world are not documented by ISO 19524. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 10:59:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgf-00030s-PO; Wed, 11 May 2005 10:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgd-0002zT-Gb for ltru@megatron.ietf.org; Wed, 11 May 2005 10:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10925 for ; Wed, 11 May 2005 10:59:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVsw8-0003IS-Qj for ltru@ietf.org; Wed, 11 May 2005 11:15:51 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVsgX-0006W0-9S; Wed, 11 May 2005 07:59:41 -0700 Message-Id: <6.2.1.2.2.20050511150001.0493aa40@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 15:01:32 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" In-Reply-To: <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> <001001c55829$830b81c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [Ltru] date problem X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy, I do not know if you are testing Marks date validation system, but you are creating a problem: when the reference date is in the futur, what should we do? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 10:59:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgg-00031L-03; Wed, 11 May 2005 10:59:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgd-0002zO-EM for ltru@megatron.ietf.org; Wed, 11 May 2005 10:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10915 for ; Wed, 11 May 2005 10:59:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVsw8-0003IU-9r for ltru@ietf.org; Wed, 11 May 2005 11:15:50 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVsgW-0006W0-47; Wed, 11 May 2005 07:59:40 -0700 Message-Id: <6.2.1.2.2.20050511144726.049779d0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 14:55:30 +0200 To: John Cowan , Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed? In-Reply-To: <20050511123500.GC14557@skunk.reutershealth.com> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <009301c555ed$9957b7c0$030aa8c0@DEWELL> <4281C670.5896@xyzzy.claranet.de> <20050511123500.GC14557@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 14:35 11/05/2005, John Cowan wrote: >Frank Ellermann scripsit: > > Doug Ewell wrote: > > > > > the accusations of treachery and skulduggery are completely > > > uncalled for. > > > > What are you talking about ? You haven't quoted any context, > > and I don't find the Message-ID in the References: > >See http://www1.ietf.org/mail-archive/web/ltru/current/msg01571.html , >which quotes the relevant bit of >http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html . This does not document "treachery and skulduggery". I see that you use your professional mailname and have no footer indicating this is a private position. If this is an official company position this is an interesting piece of news. As you know I favor IETF Members exposure and recognition through a better press coverage, because I sincerely hope it would prevent that kind of wording. But if this is a dominant company political attitude, it conforts some prior assesments that some have sided motivations. We are to live with it. But we do not forget it. jfc >-- >John Cowan http://www.ccil.org/~cowan > You tollerday donsk? N. You tolkatiff scowegian? Nn. > You spigotty anglease? Nnn. You phonio saxo? Nnnn. > Clear all so! `Tis a Jute.... (Finnegans Wake 16.5) > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 10:59:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgg-00031j-73; Wed, 11 May 2005 10:59:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsge-0002zc-7p for ltru@megatron.ietf.org; Wed, 11 May 2005 10:59:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10935 for ; Wed, 11 May 2005 10:59:45 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVsw8-0003IE-8l for ltru@ietf.org; Wed, 11 May 2005 11:15:51 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVsgT-0006W0-FV; Wed, 11 May 2005 07:59:37 -0700 Message-Id: <6.2.1.2.2.20050511143753.05735eb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 14:38:18 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed? In-Reply-To: <009301c555ed$9957b7c0$030aa8c0@DEWELL> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <009301c555ed$9957b7c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 07:52 11/05/2005, Doug Ewell wrote: >This proposal should be rejected. In addition, the accusations of >treachery and skulduggery are completely uncalled for. ??? document this please. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 11:00:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgq-00032r-QW; Wed, 11 May 2005 11:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsge-0002zd-92; Wed, 11 May 2005 10:59:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10931; Wed, 11 May 2005 10:59:45 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVsw8-0003IV-S3; Wed, 11 May 2005 11:15:51 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVsgY-0006W0-VJ; Wed, 11 May 2005 07:59:43 -0700 Message-Id: <6.2.1.2.2.20050511151324.0492ceb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 16:06:35 +0200 To: "Randy Presuhn" , ietf@ietf.org From: "JFC (Jefsey) Morfin" In-Reply-To: <004c01c555f1$462471c0$7f1afea9@oemcomputer> References: <198A730C2044DE4A96749D13E167AD37250259@MOU1WNEXMB04.vcorp.ad.vrsn.com> <6.2.1.2.2.20050511021431.048f8060@mail.jefsey.com> <001601c555d3$453fd9c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050511050500.045cf140@mail.jefsey.com> <004c01c555f1$462471c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: LTRU Working Group Subject: [Ltru] Re: a way toward homograph resolution ? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 08:18 11/05/2005, Randy Presuhn said on the ietf@ietf.org list >Hi - >Let it suffice for me to say that I believe the gentleman is mistaken. >I do not intend to waste additional bandwidth on this thread. >Those interested in ltru and its work will find our charter at >http://www.ietf.org/html.charters/ltru-charter.html and our archives at >http://www.ietf.org/mail-archive/web/ltru/index.html Bravo, Randy! This is the good spirit. I fully agree we need there a few people more who know and care about the network architecture and who have read the charter. We will soon discuss the charter, so now is a good time to join. Every point which can be addressed/clarified within the WG will not have to be addressed during the Last Call, or will permit to speed up the Last Call. FYI I, I consider hosting a one/two day(s) concertation meeting on Multilingual Internet and MGN (multilingual generalized/global network) in Versailles. After the UNESCO Bamako meeting on Multilingual Cyberspace, and the Paris EGENI meeting on July 2nd. I have here access to a prestigious XVIIIth century lounge (Chamber of Commerce). I plan informally inviting people from MINC, ISO, UNESCO, ITU, Eurolinc, AFRAC, WSIS, GAC, etc. Every IETF interested member would be welcome. This could be at the occasion of the IETF meeting (days before or the day after). The room can accept 30 persons on a table and 100 otherwise. A 200 cosy seats room at the Town Hall (on the Castle Avenue) could also be used. This would be for some brain storming before Tunis. Topics could include: - a Network Technical Document (could also be an IETF draft?) on a "MGN languages and cultures identification framework" - IPv6 international divide. Sovereignty over national naming and numbering spaces. National intelligence protection. - technical support of the regalian services. - IDN vs. ML.ML names and multilingual grassroots international efforts and deployment - international classes and groups - multilingual keyboards and panel to support universal applications propositions. - CRC (context reference centers) and decentralised universal root and Identification Grids. - participation to ISO committees, and international structures - consideration of IAB RFC 3869, and R&D strategies of the different governments - MLTF project and directory - report on MGN applications and project and on SNHN support. I am ready to include some form of F2F preparation of the WG-ltru current Draft being hold there (I informed of my invitation of the WG for a F2F meeting). May be over a diner (?). To try to settle at least a few points in a more general architectural and consensual perspective, with the legitimacy of the leading concerned parties being involved (I note that I am the only non-English speaker at the WG-ltru, what is preoccupying when dealing with a change in the Internet support of languages, and a responsibility I would love to share with other non-English speakers. I am very concerned by the IETF deliverables being deprecated by reality before being published). I suggest that those who are interested contact me off-line not to overload the IETF general mailing list. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 11:00:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsgr-00033C-0k; Wed, 11 May 2005 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVsge-0002zm-JB for ltru@megatron.ietf.org; Wed, 11 May 2005 10:59:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10932 for ; Wed, 11 May 2005 10:59:45 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVsw8-0003I9-TB for ltru@ietf.org; Wed, 11 May 2005 11:15:51 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DVsgQ-0006W0-78; Wed, 11 May 2005 07:59:35 -0700 Message-Id: <6.2.1.2.2.20050511140208.0585a100@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 16:59:28 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #950] iso 3166 inadequate for regional variants In-Reply-To: <008901c555ec$8707b800$030aa8c0@DEWELL> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <008901c555ec$8707b800$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is why I work on a stabilisation of E.164. The problem of stabilisation is however not really important if there is a good support of the versions of a standard, what is obviously not what Mark and Addison have in mind from their recent responses. E.164 has several advantages: - it is network oriented - area codes are highly granular and documented - it is population oriented as more and more people get a phone or a mobile, even in difficult countries like Ertihrea ... and we work on a reference grid which will address this which makes me biaised. jfc At 07:44 11/05/2005, Doug Ewell wrote: > > This comes from comment 22 in > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > which states: > > > > "22. 2.2.4: I understand that all the regional language differences of > > the world are to be supported by the ISO 3166 alpha-3/digit-3 list. > > This means that regions like NY, TX or California are not entitled a > > code but the 56 persons of Pitcairn Island yes? I doubt that disparity > > can hold very long, all the more than ISO 3166-2 provides all the > > possibilities for a far more adequate granularity." > > > > As pointed out in message > > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > > the draft also supports UN M.49 digit-3 codes > > > > Based on recent discussion, can I close this with a "reject"? > >I agree to reject. But I think this one needs some comment, since I was >once a supporter of ISO 3166-2 in language tags, and have often cited >regional differences in en-US as potentially worthy of tagging. > >Neither ISO 3166-2 nor any other geographic coding system -- UN/LOCODE, >MARC 21, FIPS 10-4, HASC, any of them -- can partition the world >perfectly and unequivocally in terms of language variation, partly >because experts will never agree completely on what constitutes a >"significant" language variation, and partly because such systems never >guarantee equality as to the area or population of the encoded regions. > >ISO 3166-2 assigns a single code to California (population 33 million) >and another to New York state (population 19 million), but it also >assigns 21 codes to the Bahamas (population 303,000) -- one for each of >the pre-1996 districts. This is far from ideal in terms of providing >consistent coding granularity. Other geocoding systems have similar >limitations. > >ISO 3166-2 also suffers from inadequate stability for the type of >tagging mechanism described in the draft. Code elements are added, >removed, and changed (both description and code element) with little or >no publicity. Occasionally the entire subdivision structure on which >ISO 3166-2 code elements are based is thrown out and replaced with a new >one; this happened with Libya in 2003 and Slovenia in 2002. > >Variant subtags can always be proposed to distinguish regional >differences in language that cannot be described adequately with ISO >3166-1 and UN M.49 region subtags. > >-- >Doug Ewell >Fullerton, California >http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 11:19:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVt00-00083t-AV; Wed, 11 May 2005 11:19:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVszy-00082d-VV for ltru@megatron.ietf.org; Wed, 11 May 2005 11:19:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13055 for ; Wed, 11 May 2005 11:19:44 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVtFU-0004Wf-OP for ltru@ietf.org; Wed, 11 May 2005 11:35:51 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4BFJYjH002160; Wed, 11 May 2005 11:19:35 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 11 May 2005 11:19:32 -0400 Date: Wed, 11 May 2005 11:19:32 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #951] extensibility via codes not maintained by ISO Message-ID: <20050511151931.GE6864@skunk.reutershealth.com> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <008e01c555ed$1fd21940$030aa8c0@DEWELL> <6.2.1.2.2.20050511143223.05800580@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050511143223.05800580@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin scripsit: > Most of the used charsets (sorry, "scripts") in use and part of the > Internet world are not documented by ISO 19524. Charsets and scripts are distinct concepts. Charsets are encodings of characters into octets. Scripts are collections of characters used in writing systems, and have no connection with encoding. ISO 8859-1 and Win-1252 are charsets. Latin, Greek, and Cherokee are scripts. -- I don't know half of you half as well John Cowan as I should like, and I like less than half jcowan@reutershealth.com of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 11:26:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVt6e-0000hI-0k; Wed, 11 May 2005 11:26:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVt6d-0000hD-6Z for ltru@megatron.ietf.org; Wed, 11 May 2005 11:26:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13590 for ; Wed, 11 May 2005 11:26:36 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVtM8-0004pr-Th for ltru@ietf.org; Wed, 11 May 2005 11:42:43 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 May 2005 08:26:26 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 May 2005 08:26:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #941] determining currency of registry versions Date: Wed, 11 May 2005 08:26:29 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #941] determining currency of registry versions Thread-Index: AcVV7S5hgvhqKAWZRCeamI62wtfNJAAUGl0w From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 15:26:26.0097 (UTC) FILETIME=[CBBB4A10:01C5563D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I think Randy's suggestion revision is reasonable. It's a small change with no negative side effects, and making the change will bring closure to this particular issue quickly. Peter > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: Tuesday, May 10, 2005 10:49 PM > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #941] determining currency of registry > versions >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Randy Presuhn" ; "LTRU Working Group" > > > Sent: Tuesday, May 10, 2005 9:16 PM > > Subject: RE: [Ltru] [psg.com #941] determining currency of registry > versions > ... > > An implementation > > CAN determine whether a subtag is valid as of some given date prior to > the > > registry date (the records in the registry are dated, please note). > > You don't have to reconstruct ISO-xxxx as you do today. >=20 > This is the important point, and satisfies my query. >=20 > ... > >> Would it make sense to amend it to say something like: > >> The first record in the file contains the single field whose field- > >> name is "File-Date". The field-body contains the last > >> modification date of the registry. The currency of the registry > >> is determined by this field. The registry on the IANA website is > >> the most current. Versions with an older date than that one > >> are not current. > >[Addison Phillips] > > > > We could do that, but it is redundant to do so, don't you think? > > What version of the registry would be on the IANA website besides > > the most current?!? >=20 > The last sentence was intended to include not only versions on the > IANA website, but those that might end up on mirrors and the like. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 11:38:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVtIV-0003gU-2w; Wed, 11 May 2005 11:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVtIS-0003gI-D4 for ltru@megatron.ietf.org; Wed, 11 May 2005 11:38:53 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14496 for ; Wed, 11 May 2005 11:38:48 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVtAP-0003Ey-Sj for ltru@lists.ietf.org; Wed, 11 May 2005 17:30:33 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 17:30:33 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 17:30:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 17:24:20 +0200 Organization: Lines: 79 Message-ID: <428223A4.51D3@xyzzy.claranet.de> References: <20050511121435.QAUT13001.mta6.adelphia.net@megatron.ietf.org> <019501c55630$56c38400$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I have never, ever argued in favor of making the registry > draft an RFC. Registry draft => Addison and Mark, draft registry => you. Addison and you want the "last call" for the registry draft (3066bis) before "whatever" happens with the draft registry. My original idea was that it's more or less simultaneous. > Check the archives. The last discussion about this issue was in conjunction with the idea to move the redundant tags to an appendix D in the registry draft, because they are irrelevant in the draft registry. I don't need to check this, I still recall it. We found that that's possible, because the old 3066 registry is closed as soon as the 3066bis registry draft is approved. Last minute registrations could be added to an appendix D in the "48 hours". It doesn't affect "whatever procedure" for the draft registry, as long as "whatever" is NOT what I thought, i.e. simultaneously. > If we wait until the Suppress-Script entries are perfect > before moving the draft to Last Call, we'll never get done. IBTD. But that's not more relevant at the moment, because it's already clear that the registry draft gets its "last call" before "whatever". Where "whatever" is simply another "last call" for the draft registry after filling the Suppress-Script gaps. You only supported the "separate last call before whatever" part, not its "whatever = another last call" incarnation, I know this. > the "same piece of land" concept I mentioned months ago > was ONLY meant for establishing the relationship between > deprecated region subtags and their canonical equivalents > (if any). 830 is the "same piece of land" as GG + JE, so if GG + JE are introduced after the final date-B there's a potential problem. This is true no matter who said it why and where first, it has to work. Deprecating 830 is not allowed under the -01 rules. Even if the UN invents 838 (GG) + 839 (JE) it's not allowed, but that's already the second problem. The first problem is adding GG + JE. Adding them as "deprecated" right from the start with a "canonical: 830" makes no sense. Therefore they are added as is, after all GG alone is not 830, dito JE. So then some old content is tagged ??-830, new content could use ??-GG or ??-JE. That's not optimal, for starters I very much doubt that there are interesting differences between GG and JE for any language ?? (en, fr, br (?)). In theory each region can only have one non-deprecated tag. Won't work for GG + JE, 830 cannot be deprecated. One chance is "let's pretend that 830 is a macro-geographical region", that's allowed. | For ISO 3166 codes, if the newly assigned code's meaning is | associated with the same UN M.49 code as another 'region' | subtag, then the existing region subtag remains as the | canonical entry for that region and no new entry is created. That's the "same piece of land" defined by UN numbers, it's in the *actual* draft -01. It's used in several rules to resolve conflicts. > Please do not bring up this historical relic again. That's no "historic relic", it's in -01 chapter 3.3 section 11, clauses 4, 5, and 6. BTW, for a very long chapter like 3.3 a numbered list instead of a bullet list might be better. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 12:34:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuAe-0000uf-64; Wed, 11 May 2005 12:34:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuAb-0000t7-VU for ltru@megatron.ietf.org; Wed, 11 May 2005 12:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21900 for ; Wed, 11 May 2005 12:34:45 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVuPC-0000PO-Em for ltru@ietf.org; Wed, 11 May 2005 12:49:54 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 09:33:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally supported Date: Wed, 11 May 2005 09:33:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6AB3@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally supported Thread-Index: AcVV9QqmRoKmLGG5SY6UhUL6mIRTOwATP0LQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 11 May 2005 16:33:18.0249 (UTC) FILETIME=[23291990:01C55647] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is very hard to follow. I think that it would be better to spell = out the principles and enshrine those in the text. Basically this is the = problem we've been using NH->VU to illustrate. Again, I see several options. 1. The draft currently says that "once canonical/always canonical" and = spells out how to determine whether to add a new ISO 3166 code or not. = In this set of rules, if the NH->VU transition occurred today then the = registry would look like: Subtag: NH Description: Vanuatu 2. The registry could do as Frank suggests and track changes to ISO = 3166, making codes non-canonical as country names evolve. In this case = the registry would look like: Subtag: NH Description: New Hebrides Deprecated: yyyy-mm-dd Canonical: VU %% Subtag: VU Description: Vanuatu This has the effect of "invalidating" tags in existing content in = canonical processors. 3. The registry could also do as I've suggested and deprecate but not = map. Subtag: NH Description: New Hebrides Deprecated: yyyy-mm-dd %% Subtag: VU Description: Vanuatu 4. The registry, finally, could deprecate and map, but not using the = canonical mechanism (once canonical, always canonical): Subtag: NH Description: New Hebrides Deprecated: yyyy-mm-dd Use: VU %% Subtag: VU Description: Vanuatu Personally, I don't think there is much to recommend #1 aside for = absolute stability of codes. I don't care for #2 because I *do* want = codes to remain canonical for their given meaning. Either #3 or #4 seem = like good choices to me. (Frank has previously argued that #3 is not a = good choice because there is no machine readable mechanism for = indicating what to use) Some comments below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?5?10? 23:39 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #954] all aliases must be equally = supported >=20 > Randy Presuhn wrote: >=20 > > Could you suggest some specific replacement text that would > > address your concerns? >=20 > It was point (4) of five on my ToDo list in: >=20 > >=20 > For point (1) Doug and Addison apparently prefer to get an > RfC for the registry draft _before_ discussing the final > draft registry (i.e. determine more / other Suppress-Scripts). [Addison Phillips]=20 Speaking for myself: I would prefer to see the draft registry track text = in the registry draft and not the other way around. Because the rules in = the text above are all "after Date B" rules, this particular item = doesn't affect the registry (although one might apply these rules to = existing deprecated codes from the post-Date A era) >=20 > That strategy surprised me, but it could be a good idea for > my point (5) in: >=20 > >=20 > Point (2) is actually something for you, I wanted a SHOULD > with rationale for the Suppress-Script issue, you found that > what I want is in fact a "MUST NOT unless" with rationale, > and that's still missing in draft -01. [Addison Phillips]=20 You refer to the text: Suppress-Script contains a script subtag that SHOULD NOT be used to form = language tags with the associated primary language subtag. This field = MUST only appear in records whose 'Type' field-value is 'language'. See = Section 4.1 (Choice of Language Tag). But, in fact, the rationale appears slightly lower in the document: The field 'Suppress-Script' MUST only appear in records whose 'Type' = field-value is 'language'. This field may appear at most one time in a = record. This field indicates a script used to write the overwhelming = majority of documents for the given language and which therefore adds no = distinguishing information to a language tag. For example, virtually all = Icelandic documents are written in the Latin script, making the subtag = 'Latn' redundant in the tag "is-Latn". Additional explanatory text about Suppress-Script could be added, but = this is really a separate item from issue #954. >=20 > That leaves point (4) "canonical", and admittedly I was too > lazy to find all occurences of "canonical" in the text so > far. An incomplete attempt: >=20 > Line 512, stick to canonical alpha-3 tag even if an alpha-2 > is added =3D> no problem, that only tries to avoid unnecessary > aliases. >=20 > Line 630, UN region numbers are the final canonical value > for any given region with "ambiguous" alpha-2 codes =3D> okay. >=20 > Line 1088, never add Canonical =3D> delete > Line 1089, never modify Canonical =3D> delete >=20 > That's the paragraph defining the problematic "canonical > forever" concept, it should be deleted. >=20 > Line 1095: get rid of "STRONGLY" (fourth reminder, IIRC) >=20 > Line 1112: > - Although valid in language tags, subtags and tags with a = 'Deprecated' > - field are deprecated and validating processors SHOULD NOT generate > - these subtags. Note that a record that contains a 'Deprecated' = field > - and no corresponding 'Canonical' field has no replacement mapping. > + > + Although valid in language tags, subtags and tags with a = 'Deprecated' > + field SHOULD NOT be generated by validating processor. Note hat a > + record that contains a 'Deprecated' field and no corresponding > + 'Canonical' field has no replacement mapping. > + > + Future updates of the source standards may replace former canonical > + tags by new tags. In that case the old tag is marked as = 'Deprecated' > + with a pointer to the the new tag in the 'Canonical' field. = Pointers > + to the old canonical value in other tags are updated. Validating > + processors SHOULD use the the most recent registry. >=20 > The latter SHOULD is no new restriction, it was always implied. >=20 > Line 1242: >=20 > | Values in the fields 'Type', 'Subtag', 'Tag', 'Added' and > | 'Canonical' MUST NOT be changed and are guaranteed to be > | stable over time. >=20 > s/'Added' and 'Canonical'/and 'Added'/ > In theory we hope that that 'Deprecated' is guaranteed to be > stable, but in practice not mentioning this allows Murphy to > rule and SNAFU on the side of the source standards. [Addison Phillips]=20 Good catch. >=20 > Line 1277 - 1297: Modify the procedures for withdrawn / added > tags to be reflected as deprecated / canonical in the registry. >=20 > Remove IM example (it could be still correct dependig on how > we want to handle the introduction of alpha-2 codes for regions > formerly only known by their number, but it's no example for > "canonical reflects the sources"). BTW, if GG and JE would be > added this cries for a judgement call. Insisting on 830 as a > canonical value for both GG and JE would be ridiculous. And > not reflect Doug's undocumented "same piece of land" concept. >=20 > Etc., e.g. line 1355, there are more lies, where the "canonical > forever" concept is just wrong, forcing users to consider an > obsolete tag for their region as "canonical" will never fly. >=20 > I would never follow this idea no matter what any "least common > practice" states. It's ZW, not RH. If I look into the source > standard I want a decent chance to guess what the canonical tag > might be without unnecessary surprises in the 3066bis registry. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 12:43:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuIw-0003uh-BH; Wed, 11 May 2005 12:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuIu-0003uY-PX for ltru@megatron.ietf.org; Wed, 11 May 2005 12:43:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22656 for ; Wed, 11 May 2005 12:43:21 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVuYR-0000zt-AU for ltru@ietf.org; Wed, 11 May 2005 12:59:29 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 09:43:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #951] extensibility via codes not maintained byISO Date: Wed, 11 May 2005 09:43:12 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6ACD@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #951] extensibility via codes not maintained byISO Thread-Index: AcVV7VJ6fOXwU1FfTfaO0MxbBN+JfQAWt+6g From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 16:43:13.0276 (UTC) FILETIME=[85D303C0:01C55648] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2089212083==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============2089212083== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBhZ3JlZSwgYWx0aG91Z2ggSSB3b3VsZCBhZGQgdG8gRG91ZydzIGxhc3Qgc2VudGVuY2UgdGh1 c2x5Og0KDQpWYXJpYW50IHN1YnRhZ3MNCmNhbiBiZSByZWdpc3RlcmVkIHRvIGNhcHR1cmUgc2Ny aXB0cyBvciByZWdpb25zIHRoYXQgYXJlIGluZXhwbGljYWJseQ0Kbm90IGNvdmVyZWQgYnkgSVNP IDE1OTI0LCBJU08gMzE2Niwgb3IgVU4gTS40OSBhbmQgd2hpY2ggdGhvc2Ugc3RhbmRhcmRzIGJv ZGllcyBzb21laG93IHJlZnVzZSB0byBjb25zaWRlci4NCg0KVGhlIGRyYWZ0IGhhcyBhIHByZWZl cmVuY2UgYnVpbHQgaW50byBpdCBmb3IgbGFuZ3VhZ2UsIHNjcmlwdCwgYW5kIHJlZ2lvbiBjb2Rl cyBjb21pbmcgZnJvbSB0aGUgcmVsZXZhbnQgbWFpbnRlbmFuY2Ugb3JnYW5pemF0aW9ucy4gVmFy aWFudHMgYXJlIGEga2luZCBvZiBsYXN0IHJlc29ydCBhbmQgbW9zdGx5IGZvciBpdGVtcyAoZGlh bGVjdHMsIGV0Yy4pIHRoYXQgYXJlIG5vdCBzY3JpcHRzIG9yIHJlZ2lvbnMuIExpa2UgdGhlIFNs b3ZlbmlhbiBkaWFsZWN0IHZhcmlhbnQgc3VidGFncy4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAu IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWly LCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0 aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0 cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVo YWxmIE9mIERvdWcgRXdlbGwNCj4gU2VudDogMjAwNeW5tDXmnIgxMOaXpSAyMjo0OQ0KPiBUbzog TFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFtMdHJ1XSBSZTogW3BzZy5jb20gIzk1MV0g ZXh0ZW5zaWJpbGl0eSB2aWEgY29kZXMgbm90IG1haW50YWluZWQNCj4gYnlJU08NCj4gDQo+ID4g Q29tbWVudHMgNDUgYW5kIDUzIGluIG1lc3NhZ2UNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvbHRydS9jdXJyZW50L21zZzAwNTQwLmh0bWwNCj4gPiByYWlzZSB0aGUg cXVlc3Rpb24gb2Ygc3VwcG9ydGluZyBsYW5ndWFnZSwgY291bnRyeSwgYW5kIHJlZ2lvbg0KPiA+ IGNvZGVzIG5vdCBtYWludGFpbmVkIGJ5IElTTy4NCj4gDQo+IEkgcHJvcG9zZSByZWplY3Rpbmcg dGhpcyBpdGVtLg0KPiANCj4gTGFuZ3VhZ2Ugc3VidGFncyBjYW4gYmUgcmVnaXN0ZXJlZCBpbiB0 aGUgdW5saWtlbHkgZXZlbnQgdGhhdCB0aGUNCj4gdmFyaW91cyBmbGF2b3JzIG9mIElTTyA2Mzkg Y29tcGxldGVseSBtaXNzIGEgbGFuZ3VhZ2UuICBWYXJpYW50IHN1YnRhZ3MNCj4gY2FuIGJlIHJl Z2lzdGVyZWQgdG8gY2FwdHVyZSBzY3JpcHRzIG9yIHJlZ2lvbnMgdGhhdCBhcmUgaW5leHBsaWNh Ymx5DQo+IG5vdCBjb3ZlcmVkIGJ5IElTTyAxNTkyNCwgSVNPIDMxNjYsIG9yIFVOIE0uNDkuDQo+ IA0KPiAtLQ0KPiBEb3VnIEV3ZWxsDQo+IEZ1bGxlcnRvbiwgQ2FsaWZvcm5pYQ0KPiBodHRwOi8v dXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+ IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbHRydQ0KDQo= --===============2089212083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2089212083==-- From ltru-bounces@lists.ietf.org Wed May 11 12:45:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuLO-0004XC-PC; Wed, 11 May 2005 12:45:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuLM-0004X7-Lw for ltru@megatron.ietf.org; Wed, 11 May 2005 12:45:57 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22906 for ; Wed, 11 May 2005 12:45:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVuD1-0006VT-BU for ltru@lists.ietf.org; Wed, 11 May 2005 18:37:19 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 18:37:19 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 18:37:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 18:41:14 +0200 Organization: Lines: 39 Message-ID: <428235AA.2F18@xyzzy.claranet.de> References: <20050511121435.QAUT13001.mta6.adelphia.net@megatron.ietf.org> <01b001c55632$024a3b60$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] meta (was: [psg.com #952] how to determine whether an ISO 639 registration request has been processed?) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > identified by ticket number (952 in this case). That doesn't work for me, I read the list "online", like a news group, only the unread articles. If "threading" by references doesn't work I'd still see a "same subject" in the relevant thread of unread articles. But in that case Randy's article was not more visible from my POV because I read it before. Still no problem if the references are okay, I could get the original article with a sigle click. But in that case your references pointed to the digest and not an article on the list. Of course I could reload old articles and try to find the same subject, but that's a major effort (= load the last say 100 read articles, disable threading, sort by subject instead of date, and later reset sorting and threading to normal). > I thought this was what Randy wanted Yes, he said "keep the subject". Tricky, normally replies to a digest are obvious, with a special subject. But you fix these subjects, and so I was confused what's going on. > I'm certainly trying not to contribute to the quotational > overload. Normally I'd second this, but if your References point to the digest Message-IDs I don't "see" what you're quoting. > http://www1.ietf.org/mail-archive/web/ltru/current/msg01571.html Yes, thanks, John also found it for me. With this context I've no further questions about what you said. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 12:50:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuPR-0005g1-2u; Wed, 11 May 2005 12:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuPP-0005fw-Pn for ltru@megatron.ietf.org; Wed, 11 May 2005 12:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23304 for ; Wed, 11 May 2005 12:50:04 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVuet-0001KH-9D for ltru@ietf.org; Wed, 11 May 2005 13:06:12 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4BGnl0c092964 for ; Wed, 11 May 2005 12:49:47 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4BGnZAp295814 for ; Wed, 11 May 2005 10:49:47 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4BGnY2L011545 for ; Wed, 11 May 2005 10:49:34 -0600 Received: from markdavis (sig-9-48-116-165.mts.ibm.com [9.48.116.165]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4BGnXqJ011466; Wed, 11 May 2005 10:49:34 -0600 Message-ID: <03aa01c55649$68c3c930$b9703009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <000401c555ab$ddce98c0$7f1afea9@oemcomputer> <42818B87.4C0A@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally supported Date: Wed, 11 May 2005 09:01:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id j4BGnl0c092964 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Although I agree with Frank on many other items, I disagree strongly on t= his one. It is very important for people to be able to depend on stability in IDs, and the whole purpose of a canonical ID would be subverted if we allowed it to be unstable. Stability gives implementations the assurance that once an ID is transformed into a canonical form, you can store it an= d always be assured that a comparison of the same ID put in canonical form = by any other conformant implementation, at any other time, will match. If no= t, then it's only "mostly-canonical", and that is of limited use. I think part of the issue is that the *presentation* of language tags may not want to be the canonical form. That is, the UI for presentation to us= ers should use whichever variant makes the most sense. But that doesn't have = to be the canonical form. In reality, that wants to use native names that ma= ke sense to end users anyway, eg. in Russian the following (fake) tag: aa-Arab-AD presented to the user as "=D0=90=D1=84=D0=B0=D1=80 (=D0=90=D1=80= =D0=B0=D0=B1=D1=81=D0=BA=D0=B0=D1=8F, =D0=90=D0=BD=D0=B4=D0=BE=D1=80=D1=80= =D0=B0)" etc. If we do anything, it should be to add a note to that effect. =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Tuesday, May 10, 2005 21:35 Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported > Randy Presuhn wrote: > > >> "All aliases are equally supported. Not all aliases are > >> equally recommended." > > Unfortunately the draft does not yet follow what its sources > recommend, it freezes not only registered tags, but also the > status of their recommendation (aka "Canonical") in certain > cases. > > The "canonical forever" concept is unnecessary and potentially > harmful: If long deprecated 3166-1 tags are reused, but the > registry still propagates some obsolete values as "canonical". > > "Canonical" and "Deprecated" should a far as possible reflect > what the source standards define. > > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 12:56:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuVi-0006Wf-Ko; Wed, 11 May 2005 12:56:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuVh-0006Wa-UD for ltru@megatron.ietf.org; Wed, 11 May 2005 12:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23719 for ; Wed, 11 May 2005 12:56:34 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVulF-0001dS-CA for ltru@ietf.org; Wed, 11 May 2005 13:12:42 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4BGuPXK002767; Wed, 11 May 2005 12:56:26 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 11 May 2005 12:56:24 -0400 Date: Wed, 11 May 2005 12:56:24 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally supported Message-ID: <20050511165624.GG6864@skunk.reutershealth.com> References: <20050511121435.QAUT13001.mta6.adelphia.net@megatron.ietf.org> <019501c55630$56c38400$030aa8c0@DEWELL> <428223A4.51D3@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <428223A4.51D3@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.reutershealth.com id j4BGuPXK002767 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > So then some old content is tagged ??-830, new content could > use ??-GG or ??-JE. That's not optimal, for starters I very > much doubt that there are interesting differences between GG > and JE for any language ?? (en, fr, br (?)). There are indeed differences between Dg=E8rn=E9siais and J=E8rriais, thou= gh the Ethnologue (rather surprisingly, to me) treats all the _langues d'o=EFl_ as simply dialects of French, except for Picard and Walloon (probably because they are recognized as distinct in Belgium). In contrast, no less than five _langues d'oc_ are recognized. > In theory each region can only have one non-deprecated tag. > Won't work for GG + JE, 830 cannot be deprecated. One chance > is "let's pretend that 830 is a macro-geographical region", > that's allowed. It clearly is. Juridically there is no connection between Guernsey and Jersey at all, except that they share the same Duke, namely Elizabeth II. Economically (and the M.49 codes are fundamentally economic/statistical in purpose) they can be treated jointly, and are. In order for them to be assigned distinct ISO 639-1 codes, they would have to have distinct M.49 codes first, and that strikes me as unlikely to happen. Still, if it did happen, we would have the three distinct region codes GG, JE, and 830, all valid. (The whole business is horridly arbitrary. Pitcairn has far less juridic= al independence than either Guernsey or Jersey, but it gets its own M.49 and ISO 3166-1 codes due to its physically remote location in Oceania.) --=20 A witness cannot give evidence of his John Cowan age unless he can remember being born. jcowan@reutershealth.com --Judge Blagden http://www.ccil.org/~cowa= n _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 13:55:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvQb-0001N7-76; Wed, 11 May 2005 13:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvQY-0001Lh-KZ for ltru@megatron.ietf.org; Wed, 11 May 2005 13:55:23 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27797 for ; Wed, 11 May 2005 13:55:19 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVvIT-0001Ey-SN for ltru@lists.ietf.org; Wed, 11 May 2005 19:47:01 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 19:47:01 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 19:47:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 19:49:15 +0200 Organization: Lines: 120 Message-ID: <4282459B.5DF7@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B5A6AB3@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I think that it would be better to spell out the principles > and enshrine those in the text. ACK. > Basically this is the problem we've been using NH->VU to > illustrate. Also fine, nothing so exotic as CS. [scenario 1] > then the registry would look like: > Subtag: NH > Description: Vanuatu Why didn't you add VU as in (4) ? In 3.3 "rule 9" you say "add" if there's no conflict. So scenario (1) reflecting draft -01 should be: | Subtag: NH | Description: Vanuatu | %% | Subtag: VU | Description: Vanuatu | Canonical: NH "Rule 9" is the item with example IM. Read NH for 833, and VU for IM. [scenario 2] > Subtag: NH > Description: New Hebrides > Deprecated: yyyy-mm-dd > Canonical: VU > %% > Subtag: VU > Description: Vanuatu Yes, that's what I'd prefer. Updating any old Canonical: NH elsewhere to Canonical: VU, because the registry is no lesson in graph theory. > This has the effect of "invalidating" tags in existing > content in canonical processors. No, not "invalidating", NH is still valid, in all scenarios. Maybe "decanonalizing", but a validating processor using an obsoleted registry is always in trouble, not only for this scenario, also for completely new entries. [scenario 3] > Subtag: NH > Description: New Hebrides > Deprecated: yyyy-mm-dd > %% > Subtag: VU > Description: Vanuatu That's almost the same as (2), but no pointer from NH to VU or v.v., so that would be worse than (1) or (2). All aliases should have exactly one canonical value. [scenario 4] > Subtag: NH > Description: New Hebrides > Deprecated: yyyy-mm-dd > Use: VU > %% > Subtag: VU > Description: Vanuatu Same problem as (3), unless "Use: VU" is a new kind of pointer in addition to "Canonical:". Then it's almost the same (2). I don't see any advantage in comparison with (2), but (4) is better than (1). The "validating processors need a 'canonical forever' value" argument is IMHO wrong, a validating processor always works on its own old, potentially obsolete, view of the registry. And if it's updated with a new registry it can as well integrate the complete diif, not only new records. What you lose in (2) is "once tagged canonically as long as possible canonical". I don't see where that's a problem. If it really is a problem, (4) with an ersatz-canonical "Use: VU" could solve it. > I don't care for #2 because I *do* want codes to remain > canonical for their given meaning. But why ? Who needs this, it's only confusing if "canonical" differs from the source standard, and otherwise irrelevant, because NH -> VU or VU -> NH establishs the "alias" relation. > Either #3 or #4 seem like good choices to me. (Frank has > previously argued that #3 is not a good choice because there > is no machine readable mechanism for indicating what to use) (3) is the only scenario without a documented alias relation, therefore it's the worst scenario, (2) is more or less what we do for all existing records before the final date-B. If it is what we want before date-B I don't see why we should stop to want it after date-B. [missing MUST NOT Suppress-Script and rationale] > the rationale appears slightly lower in the document: The reason for this ugly kludge is backwards compatibility. That reason is not stated in what you have. It's not only Doug who sees that it's ugly like hell, I see it too. But unfortunately it's necessary. Otherwise the effects with legacy tools and/or for legacy content are hard to predict. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 14:26:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvur-0007XF-Cp; Wed, 11 May 2005 14:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvuq-0007X5-4c for ltru@megatron.ietf.org; Wed, 11 May 2005 14:26:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00771 for ; Wed, 11 May 2005 14:26:38 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwAO-0006Pp-Hd for ltru@ietf.org; Wed, 11 May 2005 14:42:45 -0400 Received: from h-64-105-136-254.snvacaid.dynamic.covad.net ([64.105.136.254] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVvuj-0001Ao-00 for ltru@ietf.org; Wed, 11 May 2005 11:26:33 -0700 Message-ID: <001201c55657$48ffe300$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 11:28:52 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] [psg.com #960] use ITU E.164 calling codes instead of ISO 3166 country codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > In message > http://www1.ietf.org/mail-archive/web/ltru/current/msg01643.html > it was proposed to use ITU E.164 calling codes instead of ISO 3166 > country codes. I haven't seen much support for this proposal, and some rather compelling arguments against it, so unless I see a groundswell of support, I plan to mark this one "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 15:07:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVwYY-0001IQ-Hm; Wed, 11 May 2005 15:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVwYX-0001IE-Ju for ltru@megatron.ietf.org; Wed, 11 May 2005 15:07:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09307 for ; Wed, 11 May 2005 15:07:38 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwo5-0000g0-Ls for ltru@ietf.org; Wed, 11 May 2005 15:23:46 -0400 Received: from h-64-105-136-254.snvacaid.dynamic.covad.net ([64.105.136.254] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVwYS-0006u1-00 for ltru@ietf.org; Wed, 11 May 2005 12:07:36 -0700 Message-ID: <002101c5565d$05a25880$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <198A730C2044DE4A96749D13E167AD37250259@MOU1WNEXMB04.vcorp.ad.vrsn.com> <6.2.1.2.2.20050511021431.048f8060@mail.jefsey.com> <001601c555d3$453fd9c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050511050500.045cf140@mail.jefsey.com> <004c01c555f1$462471c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050511151324.0492ceb0@mail.jefsey.com> Date: Wed, 11 May 2005 12:09:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [Ltru] Interim and Paris? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I'd like to thank Jefsey for the generous offer. The date proposed is too close to the Paris IETF meeting. We would not be able to make it an official ltru WG interim meeting. There is currently no plan for the WG to meet in Paris, which would make scheduling an interim in July even more unlikely. If members of the working group believe it would be useful to have a face-to-face WG session during the Paris IETF, they need to speak up now, since Martin and I would need to request a meeting slot and get our AD's approval to meet. Randy, ltru co-chair OT: I am intrigued by the statement "I note that I am the only non-English speaker at the WG-ltru". Grammar aside, it can be read several ways: (1) All members except Jefsey are proficient in English. (2) Jefsey is the only member proficient in a language other than English. (3) All members except Jefsey have English as their native tongue. (4) All who have spoken on the ltru list, except Jefsey, are English. (5) All posters except Jefsey have posted only in English. I know that (2), (3), and (4) are demonstrably false; one needs go no further than the WG co-chairs to find the counter-examples. > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" ; > Cc: "LTRU Working Group" > Sent: Wednesday, May 11, 2005 7:06 AM > Subject: Re: a way toward homograph resolution ? > > On 08:18 11/05/2005, Randy Presuhn said on the ietf@ietf.org list > >Hi - > >Let it suffice for me to say that I believe the gentleman is mistaken. > >I do not intend to waste additional bandwidth on this thread. > >Those interested in ltru and its work will find our charter at > >http://www.ietf.org/html.charters/ltru-charter.html and our archives at > >http://www.ietf.org/mail-archive/web/ltru/index.html > > Bravo, Randy! This is the good spirit. > > I fully agree we need there a few people more who know and care about the > network architecture and who have read the charter. We will soon discuss > the charter, so now is a good time to join. Every point which can be > addressed/clarified within the WG will not have to be addressed during the > Last Call, or will permit to speed up the Last Call. > > FYI I, I consider hosting a one/two day(s) concertation meeting on > Multilingual Internet and MGN (multilingual generalized/global network) in > Versailles. After the UNESCO Bamako meeting on Multilingual Cyberspace, and > the Paris EGENI meeting on July 2nd. > > I have here access to a prestigious XVIIIth century lounge (Chamber of > Commerce). I plan informally inviting people from MINC, ISO, UNESCO, ITU, > Eurolinc, AFRAC, WSIS, GAC, etc. Every IETF interested member would be > welcome. This could be at the occasion of the IETF meeting (days before or > the day after). The room can accept 30 persons on a table and 100 > otherwise. A 200 cosy seats room at the Town Hall (on the Castle Avenue) > could also be used. This would be for some brain storming before Tunis. > > Topics could include: > > - a Network Technical Document (could also be an IETF draft?) on a "MGN > languages and cultures identification framework" > - IPv6 international divide. Sovereignty over national naming and numbering > spaces. National intelligence protection. > - technical support of the regalian services. > - IDN vs. ML.ML names and multilingual grassroots international efforts and > deployment > - international classes and groups > - multilingual keyboards and panel to support universal applications > propositions. > - CRC (context reference centers) and decentralised universal root and > Identification Grids. > - participation to ISO committees, and international structures > - consideration of IAB RFC 3869, and R&D strategies of the different > governments > - MLTF project and directory > - report on MGN applications and project and on SNHN support. > > I am ready to include some form of F2F preparation of the WG-ltru current > Draft being hold there (I informed of my invitation of the WG for a F2F > meeting). May be over a diner (?). To try to settle at least a few points > in a more general architectural and consensual perspective, with the > legitimacy of the leading concerned parties being involved (I note that I > am the only non-English speaker at the WG-ltru, what is preoccupying when > dealing with a change in the Internet support of languages, and a > responsibility I would love to share with other non-English speakers. I am > very concerned by the IETF deliverables being deprecated by reality before > being published). > > I suggest that those who are interested contact me off-line not to overload > the IETF general mailing list. > jfc > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 15:13:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVweP-0002Tw-2l; Wed, 11 May 2005 15:13:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVweO-0002Tp-Id for ltru@megatron.ietf.org; Wed, 11 May 2005 15:13:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10068 for ; Wed, 11 May 2005 15:13:41 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwtw-0000t4-GX for ltru@ietf.org; Wed, 11 May 2005 15:29:49 -0400 Received: from h-64-105-136-254.snvacaid.dynamic.covad.net ([64.105.136.254] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVweJ-0000kx-00 for ltru@ietf.org; Wed, 11 May 2005 12:13:39 -0700 Message-ID: <004c01c5565d$de8da820$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> <001001c55829$830b81c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> <6.2.1.2.2.20050511150001.0493aa40@mail.jefsey.com> Date: Wed, 11 May 2005 12:15:37 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: date problem X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Wednesday, May 11, 2005 6:01 AM > Subject: date problem > > Randy, > I do not know if you are testing Marks date validation system, but you are > creating a problem: when the reference date is in the futur, what should we do? > jfc ??? What text in the i-d concerns you? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 15:28:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVwsM-0005SR-Ja; Wed, 11 May 2005 15:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVwsK-0005Rr-SP for ltru@megatron.ietf.org; Wed, 11 May 2005 15:28:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11461 for ; Wed, 11 May 2005 15:28:06 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVx7q-0001YR-K8 for ltru@ietf.org; Wed, 11 May 2005 15:44:11 -0400 Received: from h-64-105-136-254.snvacaid.dynamic.covad.net ([64.105.136.254] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVwsA-0004Ed-00 for ltru@ietf.org; Wed, 11 May 2005 12:27:58 -0700 Message-ID: <007301c5565f$decebde0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org><009301c555ed$9957b7c0$030aa8c0@DEWELL><4281C670.5896@xyzzy.claranet.de><20050511123500.GC14557@skunk.reutershealth.com> <6.2.1.2.2.20050511144726.049779d0@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #952] how to determine whether an ISO 639 registration request has been processed? Date: Wed, 11 May 2005 12:30:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "JFC (Jefsey) Morfin" > To: "John Cowan" ; "Frank Ellermann" Cc: > Sent: Wednesday, May 11, 2005 5:55 AM > Subject: Re: [Ltru] Re: [psg.com #952] how to determine whether an ISO639 registration request has been processed? ... > I see that you use your > professional mailname and have no footer indicating this is a private > position. ... New Flash: Participation in the IETF is by *individuals*. Everyone: *please* stop wasting time and energy on the non-technical cr*p that some insist on injecting into the mailing list, in the hope of derailing our work. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:16:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxbe-0001Zf-Ow; Wed, 11 May 2005 16:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxbd-0001Xn-Tj for ltru@megatron.ietf.org; Wed, 11 May 2005 16:14:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19768 for ; Wed, 11 May 2005 16:14:55 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVxrE-0005Yn-1f for ltru@ietf.org; Wed, 11 May 2005 16:31:04 -0400 Received: from h-64-105-136-254.snvacaid.dynamic.covad.net ([64.105.136.254] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVxbW-0005Jr-00 for ltru@ietf.org; Wed, 11 May 2005 13:14:50 -0700 Message-ID: <001c01c55666$6ab49680$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> <004001c555e5$bfaec1a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #938] should introduction allude to intended bcp status? Date: Wed, 11 May 2005 13:17:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, May 10, 2005 9:56 PM > Subject: [Ltru] Re: [psg.com #938] should introduction allude to intendedbcp status? > > > The question of whether the introduction to the registry draft > > should allude to its intended BCP status was raised in comment #9 in > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > > > There was no support on the mailing list for this proposed change, > > so the proposal is marked "rejected". > > No opinion. This is a process question, best settled between the chairs > and editors. ... The last paragraph of section 2 of http://www.ietf.org/ietf/1id-guidelines.html states: | The Internet-Draft should neither state nor imply that it has any standards status; | to do so conflicts with the role of the RFC Editor and the IESG. The title of the | document should not imply a status. Avoid the use of the terms Standard, Proposed, | Draft, Experimental, Historic, Required, Recommended, Elective, or Restricted in | the title of the Internet-Draft. Indicating what status the document is aimed for | is OK, but should be done with the words "Intended status: ". With nroff, it would be easy to put "Intended status: BCP" among the items in the upper left corner of the first page. I don't know how to do it with xml2rfc. I encourage the editors to include "Intended status: BCP" if they can do so without expending too much time (more than five minutes) on figuring out how to get the tools to do it. The abstract already (-01) states "This document obsoletes RFC 3066 (which replaced RFC 1766)." That's the important part, which I believe satisfies the heart of the comment. Whether this ultimately becomes a BCP or not is up to the IESG; we as a WG will only make a recommendation. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:26:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxn7-0008KP-1z; Wed, 11 May 2005 16:26:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxn5-0008JW-LY for ltru@megatron.ietf.org; Wed, 11 May 2005 16:26:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22522 for ; Wed, 11 May 2005 16:26:45 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVy2f-0006lM-QF for ltru@ietf.org; Wed, 11 May 2005 16:42:54 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 13:26:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally supported Date: Wed, 11 May 2005 13:26:32 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6C3F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally supported Thread-Index: AcVWUrhK8Wi1Th8zSmqlJcMt+ES+tAAAFMLw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 11 May 2005 20:26:33.0456 (UTC) FILETIME=[B8F43700:01C55667] X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org >=20 > > I think that it would be better to spell out the principles > > and enshrine those in the text. >=20 > ACK. [Addison Phillips]=20 I take that as the converse of NACK, that is, U+0006? >=20 > > Basically this is the problem we've been using NH->VU to > > illustrate. >=20 > Also fine, nothing so exotic as CS. [Addison Phillips]=20 CS wouldn't make a good example for obvious reasons :-). >=20 > [scenario 1] > > then the registry would look like: >=20 > > Subtag: NH > > Description: Vanuatu >=20 > Why didn't you add VU as in (4) ? In 3.3 "rule 9" you say > "add" if there's no conflict. So scenario (1) reflecting > draft -01 should be: [Addison Phillips]=20 I was trying to create a future tense example (if NH were to change to = VU after Date B, as opposed to before Date B...). I read rule (4) to = mean that VU would not be added, which is one thing you have objected = to. Here is the rule I mean: For ISO 3166 codes, if the newly assigned code's meaning is = associated with the same UN M.49 code as another 'region' subtag, then = the existing region subtag remains as the canonical entry for that = region and no new entry is created. A comment MAY be added to the = existing region subtag indicating the relationship to the new ISO 3166 = code. The phrase "no new entry is created" seems to forbid the creation of = 'VU'. That could be changed to produce your following example, of = course. It does also seem to conflict with the "rule 9" you cite: Codes assigned by ISO 639, ISO 15924, or ISO 3166 that do not = conflict with existing subtags of the associated type but which = represent the same meaning as an existing subtag of that type are = entered into the IANA registry as new records. The field 'canonical = value' for that record MUST contain the existing subtag of the same = meaning >=20 > | Subtag: NH > | Description: Vanuatu > | %% > | Subtag: VU > | Description: Vanuatu > | Canonical: NH >=20 > "Rule 9" is the item with example IM. Read NH for 833, and > VU for IM. >=20 > [scenario 2] > > Subtag: NH > > Description: New Hebrides > > Deprecated: yyyy-mm-dd > > Canonical: VU > > %% > > Subtag: VU > > Description: Vanuatu >=20 > Yes, that's what I'd prefer. Updating any old Canonical: NH > elsewhere to Canonical: VU, because the registry is no lesson > in graph theory. [Addison Phillips]=20 Yes, but it conflicts with guarantees of stability for tags. You are = correct that a tag such as "en-NH" would still be "valid", but it would = not be canonical and thus certain processors might transform tags from = "en-NH" to "en-VU" per this text in Section 2.2.9: If the processor generates tags, it MUST do so in canonical form, = including any supported extensions, as defined in Section 4.3 = (Canonicalization of Language Tags). >=20 > > This has the effect of "invalidating" tags in existing > > content in canonical processors. >=20 > No, not "invalidating", NH is still valid, in all scenarios. [Addison Phillips]=20 You are correct. >=20 > Maybe "decanonalizing", but a validating processor using an > obsoleted registry is always in trouble, not only for this > scenario, also for completely new entries. [Addison Phillips]=20 The trouble is more for validating processors using the newer registry = (changing the tag) and for content authors having to choose a different = tag than previously. Old implementations generate what they generate. >=20 > [scenario 3] > > Subtag: NH > > Description: New Hebrides > > Deprecated: yyyy-mm-dd > > %% > > Subtag: VU > > Description: Vanuatu >=20 > That's almost the same as (2), but no pointer from NH to VU > or v.v., so that would be worse than (1) or (2). All aliases > should have exactly one canonical value. [Addison Phillips]=20 I agree. I included it for completeness. >=20 > [scenario 4] > > Subtag: NH > > Description: New Hebrides > > Deprecated: yyyy-mm-dd > > Use: VU > > %% > > Subtag: VU > > Description: Vanuatu >=20 > Same problem as (3), unless "Use: VU" is a new kind of pointer > in addition to "Canonical:". Then it's almost the same (2). [Addison Phillips]=20 It is different than 'Canonical': it could be informative, for example, = instead of normative (as canonical is). In the end, users choose tags, = wisely or otherwise. This documents changes in country names, regimes, = borders, and the like without requiring (as in #1) that ietf-languages = prefer the original and without violating stability of canonical tags. >=20 > I don't see any advantage in comparison with (2), but (4) is > better than (1). The "validating processors need a 'canonical > forever' value" argument is IMHO wrong, a validating processor > always works on its own old, potentially obsolete, view of the > registry. And if it's updated with a new registry it can as > well integrate the complete diif, not only new records. >=20 > What you lose in (2) is "once tagged canonically as long as > possible canonical". I don't see where that's a problem. If > it really is a problem, (4) with an ersatz-canonical "Use: VU" > could solve it. [Addison Phillips]=20 Exactly the point of that example. >=20 > > I don't care for #2 because I *do* want codes to remain > > canonical for their given meaning. >=20 > But why ? Who needs this, it's only confusing if "canonical" > differs from the source standard, and otherwise irrelevant, > because NH -> VU or VU -> NH establishs the "alias" relation. >=20 > > Either #3 or #4 seem like good choices to me. (Frank has > > previously argued that #3 is not a good choice because there > > is no machine readable mechanism for indicating what to use) >=20 > (3) is the only scenario without a documented alias relation, > therefore it's the worst scenario, [Addison Phillips]=20 Well... (1) doesn't create an alias but does get ietf-languages into the = tricky business of having to track the UN M.49 numbers and having to = apply brainpower to new ISO 3166 assignments. Ideally we want to apply = brainpower to assignments that exhibit obvious problems (e.g. the 'CS' = mess or events such as the break-up of 'SU'). Really there are different = kinds of events and the ones that we're discussing here only deal with a = country changing names but not borders. When borders change (joins, = splits, etc.) then a different set of problems may ensue. >=20 > (2) is more or less what we do for all existing records before > the final date-B. If it is what we want before date-B I don't > see why we should stop to want it after date-B. [Addison Phillips]=20 The assertion is true. The question is whether we want to continue it = post-Date-B. >=20 > [missing MUST NOT Suppress-Script and rationale] > > the rationale appears slightly lower in the document: >=20 > The reason for this ugly kludge is backwards compatibility. [Addison Phillips]=20 Yes. >=20 > That reason is not stated in what you have. It's not only > Doug who sees that it's ugly like hell, I see it too. But > unfortunately it's necessary. Otherwise the effects with > legacy tools and/or for legacy content are hard to predict. [Addison Phillips]=20 You will recall that I argued against Suppress-Script (even though I = *also* thought of it and named it). Personally, I think that = Suppress-Script will be harder to maintain than Require-Script... but I = lost that argument. Okay, the reason for the field is somewhat oblique. How about adding = this text to Section 3.1 and to Section 4.1 (Choice): "This field helps ensure greater compatibility between the language tags = generated according to the rules in this document and language tags and = tag processors or consumers based on RFC 3066." _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:27:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxnV-0000Sj-KB; Wed, 11 May 2005 16:27:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxnU-0000Ok-3k for ltru@megatron.ietf.org; Wed, 11 May 2005 16:27:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22592 for ; Wed, 11 May 2005 16:27:09 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVy33-0006mF-Jl for ltru@ietf.org; Wed, 11 May 2005 16:43:18 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 May 2005 13:27:01 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 May 2005 13:27:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #952] how to determine whether an ISO 639registration request has been processed? Date: Wed, 11 May 2005 13:27:05 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #952] how to determine whether an ISO 639registration request has been processed? Thread-Index: AcVVqySr7Q9CkRPBQgeciwJhMJ7GzQAul8Zw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 20:27:01.0440 (UTC) FILETIME=[C9A23C00:01C55667] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org In answer to the question, "how to determine...?", I believe there is a liaison between IETF and the ISO 639/RA-JAC in the person of Michael Everson, the Language Tag Reviewer. If I'm right, then it would certainly be appropriate that one of his responsibilities would be to report when an ISO 639 registration request has been processed. I don't know if you think that needs to be formalized in the draft somehow. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:35:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxvw-000466-Jl; Wed, 11 May 2005 16:35:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxvu-00045w-Ts for ltru@megatron.ietf.org; Wed, 11 May 2005 16:35:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23244 for ; Wed, 11 May 2005 16:35:52 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyBV-0007Ee-F0 for ltru@ietf.org; Wed, 11 May 2005 16:52:01 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 13:35:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude to intendedbcp status? Date: Wed, 11 May 2005 13:35:43 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6C4E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #938] should introduction allude to intendedbcp status? Thread-Index: AcVWZnnPi8EkXrs3QuitT3bqj8WXtAAAXWLg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 20:35:44.0584 (UTC) FILETIME=[0173AC80:01C55669] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org There is no way that I know of to insert this value except by editing = the generated document by hand. I'm not sure that I would *want* to insert it. We allude only to RFC = status in the document. Surely RFC 3066's successor, whatever track the = IESG puts it on, will obsolete the current BCP 47 too. Debate about = whether to pursue the STD track or not might be interesting to have in = this WG, but has no practical effect on the contents of the document = except for that one phrase, no? And in practice, the track the document = follows has no impact on what we put into it either. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?11? 13:17 > To: LTRU Working Group > Subject: Re: [Ltru] Re: [psg.com #938] should introduction allude to > intendedbcp status? >=20 > Hi - >=20 > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Tuesday, May 10, 2005 9:56 PM > > Subject: [Ltru] Re: [psg.com #938] should introduction allude to > intendedbcp status? > > >=20 > > > The question of whether the introduction to the registry draft > > > should allude to its intended BCP status was raised in comment #9 = in > > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > > > > > There was no support on the mailing list for this proposed change, > > > so the proposal is marked "rejected". > > > > No opinion. This is a process question, best settled between the = chairs > > and editors. > ... >=20 > The last paragraph of section 2 of http://www.ietf.org/ietf/1id- > guidelines.html > states: >=20 > | The Internet-Draft should neither state nor imply that it has any > standards status; > | to do so conflicts with the role of the RFC Editor and the IESG. The > title of the > | document should not imply a status. Avoid the use of the terms = Standard, > Proposed, > | Draft, Experimental, Historic, Required, Recommended, Elective, or > Restricted in > | the title of the Internet-Draft. Indicating what status the document = is > aimed for > | is OK, but should be done with the words "Intended status: = ". >=20 > With nroff, it would be easy to put "Intended status: BCP" among the = items > in the > upper left corner of the first page. I don't know how to do it with > xml2rfc. > I encourage the editors to include "Intended status: BCP" if they can = do > so > without expending too much time (more than five minutes) on figuring = out > how > to get the tools to do it. >=20 > The abstract already (-01) states "This document obsoletes RFC 3066 = (which > replaced RFC 1766)." That's the important part, which I believe = satisfies > the heart of the comment. Whether this ultimately becomes a BCP or = not is > up to the IESG; we as a WG will only make a recommendation. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:44:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVy4W-0005zl-56; Wed, 11 May 2005 16:44:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVy4S-0005zg-G7 for ltru@megatron.ietf.org; Wed, 11 May 2005 16:44:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23884 for ; Wed, 11 May 2005 16:44:41 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyK1-0007e6-R2 for ltru@ietf.org; Wed, 11 May 2005 17:00:51 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVy4L-0001pa-00 for ltru@ietf.org; Wed, 11 May 2005 13:44:37 -0700 Message-ID: <001201c5566a$916ba440$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] [psg.com #952] how to determine whether an ISO 639 registration request has been processed? Date: Wed, 11 May 2005 13:46:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Wednesday, May 11, 2005 1:27 PM > Subject: RE: [Ltru] [psg.com #952] how to determine whether an ISO639registration request has been processed? > > In answer to the question, "how to determine...?", I believe there is a > liaison between IETF and the ISO 639/RA-JAC in the person of Michael > Everson, the Language Tag Reviewer. If I'm right, then it would > certainly be appropriate that one of his responsibilities would be to > report when an ISO 639 registration request has been processed. I don't > know if you think that needs to be formalized in the draft somehow. ... My personal opinion is that there is no need to formalize it. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:46:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVy6O-0006Bx-Ak; Wed, 11 May 2005 16:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVy6M-0006Bs-Cw for ltru@megatron.ietf.org; Wed, 11 May 2005 16:46:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24023 for ; Wed, 11 May 2005 16:46:39 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyLx-0007n4-1J for ltru@ietf.org; Wed, 11 May 2005 17:02:49 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVy6K-0002Oq-00 for ltru@ietf.org; Wed, 11 May 2005 13:46:40 -0700 Message-ID: <001901c5566a$dc8edf00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> <005401c555e7$6bb29840$030aa8c0@DEWELL> Subject: Re: [Ltru] [psg.com #942] clarify advice on use of subtags Date: Wed, 11 May 2005 13:49:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, May 10, 2005 10:08 PM > Subject: [Ltru] Re: [psg.com #942] clarify advice on use of subtags > > > Comment #13 in message > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > requests clarification of the advice on the use of subtags > > in section 2.1.1 (of draft -00-) > > No comment. I've already expressed my objection to restrictions on the > recommended use of subtags. The group's consensus was to recommend > certain restrictions, and in particular to implement Suppress-Script, so > I've accepted that and moved on. ... Ok, so I've marked this one "rejected", in the expectation that it can be re-opened if we find problems in the text. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:48:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVy7u-0006ZF-CY; Wed, 11 May 2005 16:48:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVy7o-0006Z8-TE for ltru@megatron.ietf.org; Wed, 11 May 2005 16:48:13 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24156 for ; Wed, 11 May 2005 16:48:08 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVxz9-0007GN-R8 for ltru@lists.ietf.org; Wed, 11 May 2005 22:39:15 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 22:39:15 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 22:39:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 11 May 2005 22:44:05 +0200 Organization: Lines: 54 Message-ID: <42826E95.1AFD@xyzzy.claranet.de> References: <000401c555ab$ddce98c0$7f1afea9@oemcomputer> <42818B87.4C0A@xyzzy.claranet.de> <03aa01c55649$68c3c930$b9703009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > I disagree strongly on this one. It is very important for > people to be able to depend on stability in IDs, and the > whole purpose of a canonical ID would be subverted if we > allowed it to be unstable. You identify "stable" and "canonical". As soon as you've done this it's clear that we come to different conclusions, because my premise is "stable" != "canonical". We both see "canonical" as an equivalence class, where the canonical value represents the class. You want always the same "oldest" representantive, I want something like the "newest" representantive. > once an ID is transformed into a canonical form, you can > store it and always be assured that a comparison of the > same ID put in canonical form by any other conformant > implementation, at any other time, will match. Makes sense. It's a conflict of interests, because these classes change over time. New items are added, others are "removed" (not in the registry, but in the source standards). > "mostly-canonical", and that is of limited use. The "newest" approach is useful as soon as ISO 3166-1 reuses an "oldest" alpha-2 tag for a completely different region. Otherwise it has no real advantage, maybe it simplifies the job of the tag reviewer, "just do what the sources say if there's no conflict" is a pretty simple rule. And we are almost sure that there never will be any conflict, except from these funny region codes. But in theory Addison's NH -> VU example would be exactly the same for future cases of iw -> he, ji -> yi, jw -> jv, With your choice you'd get "canonical" subtags iw, ji, jw. And IMHO you couldn't declare he, yi, jv as "deprecated", that would be too obviously backwards. You also can't declare iw, ji, jw as "deprecated" if they are at the same time "canonical". The whole concept of a "deprecated" tag does not work as I'd expect it for your "canonical" iw, ji. jw. Of course it's nice to have always the same representantive, e.g. the smallest number in sets of numbers. Less so if new arbitrary negative values could be added to these sets. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:54:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyDk-0007uV-3p; Wed, 11 May 2005 16:54:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyDf-0007tW-3g for ltru@megatron.ietf.org; Wed, 11 May 2005 16:54:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24734 for ; Wed, 11 May 2005 16:54:12 -0400 (EDT) Received: from lakermmtao10.cox.net ([68.230.240.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyTC-0008Ap-EN for ltru@ietf.org; Wed, 11 May 2005 17:10:22 -0400 Received: from A31P ([68.100.55.187]) by lakermmtao10.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050511205349.PODK7787.lakermmtao10.cox.net@A31P>; Wed, 11 May 2005 16:53:49 -0400 From: "Scott Hollenbeck" To: "'Addison Phillips'" , "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude tointendedbcp status? Date: Wed, 11 May 2005 16:53:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVWZnnPi8EkXrs3QuitT3bqj8WXtAAAXWLgAADdV/A= In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B5A6C4E@irvmbxw01.quest.com> Message-Id: <20050511205349.PODK7787.lakermmtao10.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > There is no way that I know of to insert this value except by > editing the generated document by hand. Actually, I believe it *is* doable with xml2rfc. I don't have access to my references to confirm my suspicion, but I can check in the morning. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:56:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyFj-000070-AA; Wed, 11 May 2005 16:56:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyFg-000069-9i for ltru@megatron.ietf.org; Wed, 11 May 2005 16:56:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24996 for ; Wed, 11 May 2005 16:56:17 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyVF-0008LS-S2 for ltru@ietf.org; Wed, 11 May 2005 17:12:27 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVyFb-00052Y-00 for ltru@ietf.org; Wed, 11 May 2005 13:56:15 -0700 Message-ID: <001e01c5566c$32d4f100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B5A6C4E@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: [psg.com #938] should introduction allude to intended bcp status? Date: Wed, 11 May 2005 13:58:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Wednesday, May 11, 2005 1:35 PM > Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude to intendedbcp status? > > There is no way that I know of to insert this value except by editing the generated document by hand. It's not worth the effort. > I'm not sure that I would *want* to insert it. We allude only to RFC status in the document. > Surely RFC 3066's successor, whatever track the IESG puts it on, will obsolete the current > BCP 47 too. Debate about whether to pursue the STD track or not might be interesting to > have in this WG, but has no practical effect on the contents of the document except for > that one phrase, no? And in practice, the track the document follows has no impact on > what we put into it either. All true. That's why the comment is marked "rejected". As I wronte earlier: > The abstract already (-01) states "This document obsoletes RFC 3066 (which > replaced RFC 1766)." That's the important part, which I believe satisfies > the heart of the comment. Whether this ultimately becomes a BCP or not is > up to the IESG; we as a WG will only make a recommendation. The BCP vs STD debate isn't really ours to have. We can make a recommendation when we pass it to the IESG, but the decision is theirs to make. Since the technical content is already out there as a BCP, I think we'd need a fairly compelling argument to ask for something else. In any case, I'd prefer to defer discussion of BCP/STD until all other issues are resolved, since it really doesn't impact the content of the document. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 16:59:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyIX-00016f-2f; Wed, 11 May 2005 16:59:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyIW-00016X-CJ for ltru@megatron.ietf.org; Wed, 11 May 2005 16:59:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25475 for ; Wed, 11 May 2005 16:59:13 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyY5-00005w-Sv for ltru@ietf.org; Wed, 11 May 2005 17:15:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 13:58:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude to intendedbcp status? Date: Wed, 11 May 2005 13:58:58 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6C80@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #938] should introduction allude to intendedbcp status? Thread-Index: AcVWa/GWfibu4ZAERLO5H1MYHL6KQgAACxqw From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 20:58:59.0514 (UTC) FILETIME=[40E519A0:01C5566C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I experimented with changing the rfc element's type attribute to 'bcp' = with no effect on the content of the I-D xml2rfc generates. So let's = skip it. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?11? 13:59 > To: LTRU Working Group > Subject: Re: [Ltru] Re: [psg.com #938] should introduction allude to > intendedbcp status? >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Randy Presuhn" ; "LTRU Working = Group" > > > Sent: Wednesday, May 11, 2005 1:35 PM > > Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude to > intendedbcp status? > > >=20 > > There is no way that I know of to insert this value except by = editing > the generated document by hand. >=20 > It's not worth the effort. >=20 > > I'm not sure that I would *want* to insert it. We allude only to RFC > status in the document. > > Surely RFC 3066's successor, whatever track the IESG puts it on, = will > obsolete the current > > BCP 47 too. Debate about whether to pursue the STD track or not = might be > interesting to > > have in this WG, but has no practical effect on the contents of the > document except for > > that one phrase, no? And in practice, the track the document follows = has > no impact on > > what we put into it either. >=20 > All true. That's why the comment is marked "rejected". As I wronte > earlier: >=20 > > The abstract already (-01) states "This document obsoletes RFC 3066 > (which > > replaced RFC 1766)." That's the important part, which I believe > satisfies > > the heart of the comment. Whether this ultimately becomes a BCP or = not > is > > up to the IESG; we as a WG will only make a recommendation. >=20 > The BCP vs STD debate isn't really ours to have. We can make a > recommendation > when we pass it to the IESG, but the decision is theirs to make. = Since > the technical > content is already out there as a BCP, I think we'd need a fairly > compelling argument > to ask for something else. In any case, I'd prefer to defer = discussion of > BCP/STD > until all other issues are resolved, since it really doesn't impact = the > content of the > document. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 17:00:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyJZ-0001FG-LZ; Wed, 11 May 2005 17:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyJX-0001Et-ET for ltru@megatron.ietf.org; Wed, 11 May 2005 17:00:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25621 for ; Wed, 11 May 2005 17:00:16 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyZ7-00008w-6J for ltru@ietf.org; Wed, 11 May 2005 17:16:26 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 14:00:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude tointendedbcp status? Date: Wed, 11 May 2005 13:59:56 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6C84@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #938] should introduction allude tointendedbcp status? Thread-Index: AcVWZnnPi8EkXrs3QuitT3bqj8WXtAAAXWLgAADdV/AAAD4v0A== From: "Addison Phillips" To: "Scott Hollenbeck" , "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 11 May 2005 21:00:08.0966 (UTC) FILETIME=[6A4AA260:01C5566C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Thanks. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Scott Hollenbeck [mailto:sah@428cobrajet.net] > Sent: 2005?5?11? 13:54 > To: Addison Phillips; 'Randy Presuhn'; 'LTRU Working Group' > Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude > tointendedbcp status? >=20 > > There is no way that I know of to insert this value except by > > editing the generated document by hand. >=20 > Actually, I believe it *is* doable with xml2rfc. I don't have access = to > my > references to confirm my suspicion, but I can check in the morning. >=20 > -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 17:04:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyNM-00023R-NR; Wed, 11 May 2005 17:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyNL-00023J-A2 for ltru@megatron.ietf.org; Wed, 11 May 2005 17:04:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26209 for ; Wed, 11 May 2005 17:04:12 -0400 (EDT) Received: from lakermmtao12.cox.net ([68.230.240.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVycu-0000US-Vy for ltru@ietf.org; Wed, 11 May 2005 17:20:22 -0400 Received: from A31P ([68.100.55.187]) by lakermmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050511210359.BCFV10612.lakermmtao12.cox.net@A31P>; Wed, 11 May 2005 17:03:59 -0400 From: "Scott Hollenbeck" To: "'Addison Phillips'" , "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude tointendedbcp status? Date: Wed, 11 May 2005 17:04:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVWZnnPi8EkXrs3QuitT3bqj8WXtAAAXWLgAADdV/AAAD4v0AAAEIZA In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B5A6C84@irvmbxw01.quest.com> Message-Id: <20050511210359.BCFV10612.lakermmtao12.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Ah, I see it in the rfc2629 DTD. In the element, add a 'category=' attribute. Valid values: std|bcp|info|exp|historic. -Scott- > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Wednesday, May 11, 2005 5:00 PM > To: Scott Hollenbeck; Randy Presuhn; LTRU Working Group > Subject: RE: [Ltru] Re: [psg.com #938] should introduction > allude tointendedbcp status? > > Thanks. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: Scott Hollenbeck [mailto:sah@428cobrajet.net] > > Sent: 2005?5?11? 13:54 > > To: Addison Phillips; 'Randy Presuhn'; 'LTRU Working Group' > > Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude > > tointendedbcp status? > > > > > There is no way that I know of to insert this value except by > > > editing the generated document by hand. > > > > Actually, I believe it *is* doable with xml2rfc. I don't > have access > > to my references to confirm my suspicion, but I can check in the > > morning. > > > > -Scott- > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 17:07:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyQN-0003FJ-Le; Wed, 11 May 2005 17:07:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyQM-0003Bk-41 for ltru@megatron.ietf.org; Wed, 11 May 2005 17:07:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26426 for ; Wed, 11 May 2005 17:07:18 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyfu-0000gI-PD for ltru@ietf.org; Wed, 11 May 2005 17:23:28 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVyQI-00008B-00 for ltru@ietf.org; Wed, 11 May 2005 14:07:18 -0700 Message-ID: <003201c5566d$be4f01c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <008901c555ec$8707b800$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #950] iso 3166 inadequate for regional variants Date: Wed, 11 May 2005 14:09:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Ok, I've marked this one "rejected", but included a pointer to Doug's message in the archive. http://www1.ietf.org/mail-archive/web/ltru/current/msg01619.html Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 17:14:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyXA-0004bD-HV; Wed, 11 May 2005 17:14:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyX8-0004b4-4S for ltru@megatron.ietf.org; Wed, 11 May 2005 17:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26842 for ; Wed, 11 May 2005 17:14:19 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVymi-000101-GO for ltru@ietf.org; Wed, 11 May 2005 17:30:28 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVyX5-00028H-00 for ltru@ietf.org; Wed, 11 May 2005 14:14:19 -0700 Message-ID: <005f01c5566e$b9048680$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B5A6ACD@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #951] extensibility via codes not maintained by ISO Date: Wed, 11 May 2005 14:16:39 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Ok, I've marked this one "rejected". Randy, ltru co-chair > From: "Addison Phillips" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Wednesday, May 11, 2005 9:43 AM > Subject: RE: [Ltru] Re: [psg.com #951] extensibility via codes not maintainedbyISO > > I agree, although I would add to Doug's last sentence thusly: > > Variant subtags > can be registered to capture scripts or regions that are inexplicably > not covered by ISO 15924, ISO 3166, or UN M.49 and which those standards bodies somehow refuse to consider. > > The draft has a preference built into it for language, script, and region codes coming from the relevant maintenance organizations. Variants are a kind of last resort and mostly for items (dialects, etc.) that are not scripts or regions. Like the Slovenian dialect variant subtags. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Doug Ewell > > Sent: 2005?5?10? 22:49 > > To: LTRU Working Group > > Subject: [Ltru] Re: [psg.com #951] extensibility via codes not maintained > > byISO > > > > > Comments 45 and 53 in message > > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > > raise the question of supporting language, country, and region > > > codes not maintained by ISO. > > > > I propose rejecting this item. > > > > Language subtags can be registered in the unlikely event that the > > various flavors of ISO 639 completely miss a language. Variant subtags > > can be registered to capture scripts or regions that are inexplicably > > not covered by ISO 15924, ISO 3166, or UN M.49. > > > > -- > > Doug Ewell > > Fullerton, California > > http://users.adelphia.net/~dewell/ > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -------------------------------------------------------------------------------- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 17:33:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVypi-00006A-1x; Wed, 11 May 2005 17:33:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVypf-000062-A6 for ltru@megatron.ietf.org; Wed, 11 May 2005 17:33:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28282 for ; Wed, 11 May 2005 17:33:26 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVz5D-00026z-FX for ltru@ietf.org; Wed, 11 May 2005 17:49:36 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DVypX-0007ju-00 for ltru@ietf.org; Wed, 11 May 2005 14:33:23 -0700 Message-ID: <007201c55671$62a80980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <001301c555ac$84cd2560$7f1afea9@oemcomputer><42818E3F.65D6@xyzzy.claranet.de> <003501c555e6$957d8f00$7f1afea9@oemcomputer> Subject: Re: [Ltru] Re: [psg.com #957] compatibility of description format with ISO table format Date: Wed, 11 May 2005 14:35:43 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Randy Presuhn" > To: > Sent: Tuesday, May 10, 2005 10:02 PM > Subject: Re: [Ltru] Re: [psg.com #957] compatibility of description formatwithISO table format ... The original comment reads: | 29. 3.1: Description of "description" is clueless. It is a description | but does not intend to be an English description but it is one. | The addition made in the IANA file are intended to be additions | to corresponding documented ISO tables. They MUST comply with the format | of these tables otherwise they add a disparity between the table and | their IANA "appendix". As a technical contributor: I believe the comment represents a fundamental misunderstanding of the registry and its fields. Just as the use of a foreign key in a relational database table does not constrain the type or content of that table's columns, we are not making additions to the ISO tables, and are not constrained by their format. As WG co-chair: I've seen no support for this proposal, and there are arguments against it, so I plan to mark it "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:15:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVzQg-0002i1-NT; Wed, 11 May 2005 18:11:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVzQe-0002hA-BF for ltru@megatron.ietf.org; Wed, 11 May 2005 18:11:44 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02104 for ; Wed, 11 May 2005 18:11:40 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVzIH-0005SC-4H for ltru@lists.ietf.org; Thu, 12 May 2005 00:03:05 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 00:03:05 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 00:03:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 12 May 2005 00:08:57 +0200 Organization: Lines: 13 Message-ID: <42828279.45F9@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B5A6C84@irvmbxw01.quest.com> <20050511210359.BCFV10612.lakermmtao12.cox.net@A31P> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #938] should introduction allude tointendedbcp status? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Scott Hollenbeck wrote: > I see it in the rfc2629 DTD. In the element, add a > 'category=' attribute. Valid values:std|bcp|info|exp|historic. No effect with my test document. Adding seriesNo="47" also has no effect. With number="XXXX" it's RfC XXXX and no I-D. More than one also had no visible effect in the TXT output => DTD workgroup* vs. ? posted no the xml2rfc list. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:23:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVzc6-0005Q6-4v; Wed, 11 May 2005 18:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVzc4-0005Px-Uq for ltru@megatron.ietf.org; Wed, 11 May 2005 18:23:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03853 for ; Wed, 11 May 2005 18:23:29 -0400 (EDT) Received: from lakermmtao05.cox.net ([68.230.240.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVzrf-00057U-D7 for ltru@ietf.org; Wed, 11 May 2005 18:39:40 -0400 Received: from A31P ([68.100.55.187]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050511222318.ESZC13442.lakermmtao05.cox.net@A31P>; Wed, 11 May 2005 18:23:18 -0400 From: "Scott Hollenbeck" To: "'Frank Ellermann'" , Subject: xml2rfc category (was RE: [Ltru] Re: [psg.com #938] should introduction alludetointendedbcp status?) Date: Wed, 11 May 2005 18:23:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <42828279.45F9@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVWdwvc2b0kh9a7Su2dA+yYb2JCRQAAJY0A Message-Id: <20050511222318.ESZC13442.lakermmtao05.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Wednesday, May 11, 2005 6:09 PM > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #938] should introduction > alludetointendedbcp status? > > Scott Hollenbeck wrote: > > > I see it in the rfc2629 DTD. In the element, add a > 'category=' > > attribute. Valid values:std|bcp|info|exp|historic. > > No effect with my test document. Adding seriesNo="47" also > has no effect. With number="XXXX" it's RfC XXXX and no I-D. Are you using the most recent version of xml2rfc? I'm pretty sure I've used this before without any trouble. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:48:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00G-0005JZ-0v; Wed, 11 May 2005 18:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00E-0005JO-5v for ltru@megatron.ietf.org; Wed, 11 May 2005 18:48:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06423 for ; Wed, 11 May 2005 18:48:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0Fp-00070x-Av for ltru@ietf.org; Wed, 11 May 2005 19:04:37 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW007-0003hA-M3; Wed, 11 May 2005 15:48:24 -0700 Message-Id: <6.2.1.2.2.20050511201437.056d2240@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 20:49:50 +0200 To: "Mark Davis" , , "Frank Ellermann" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally supported In-Reply-To: <03aa01c55649$68c3c930$b9703009@sanjose.ibm.com> References: <000401c555ab$ddce98c0$7f1afea9@oemcomputer> <42818B87.4C0A@xyzzy.claranet.de> <03aa01c55649$68c3c930$b9703009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 18:01 11/05/2005, Mark Davis wrote: >Although I agree with Frank on many other items, I disagree strongly on this >one. It is very important for people to be able to depend on stability in >IDs, and the whole purpose of a canonical ID would be subverted if we >allowed it to be unstable. Stability gives implementations the assurance >that once an ID is transformed into a canonical form, you can store it and >always be assured that a comparison of the same ID put in canonical form by >any other conformant implementation, at any other time, will match. If not, >then it's only "mostly-canonical", and that is of limited use. Mark, I am sorry, Frank is right. You cannot be cannonical with tables you do not control. This is precisely the problem the charter wants us to address. Stability is not in the ID but in the documented object. You have two possibilities: to attach a date to the ID or to define your own canonical table and relate it to the ID. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:48:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00G-0005Jx-7O; Wed, 11 May 2005 18:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00E-0005JP-5q for ltru@megatron.ietf.org; Wed, 11 May 2005 18:48:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06426 for ; Wed, 11 May 2005 18:48:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0Fp-00070r-Az for ltru@ietf.org; Wed, 11 May 2005 19:04:37 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW003-0003hA-Gx for ltru@ietf.org; Wed, 11 May 2005 15:48:19 -0700 Message-Id: <6.2.1.2.2.20050511172503.056d4b80@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 17:37:48 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #951] extensibility via codes not maintained by ISO In-Reply-To: <20050511151931.GE6864@skunk.reutershealth.com> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <008e01c555ed$1fd21940$030aa8c0@DEWELL> <6.2.1.2.2.20050511143223.05800580@mail.jefsey.com> <20050511151931.GE6864@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 17:19 11/05/2005, John Cowan said: >JFC (Jefsey) Morfin scripsit: > > > Most of the used charsets (sorry, "scripts") in use and part of the > > Internet world are not documented by ISO 19524. > >Charsets and scripts are distinct concepts. Charsets are encodings of >characters into octets. Scripts are collections of characters used in >writing systems, and have no connection with encoding. ISO 8859-1 and >Win-1252 are charsets. Latin, Greek, and Cherokee are scripts. Frank documented what you can do with this mental twist. Scripts are named in ISO 15924 ane are collections of characters documented in ISO 10646 with their digital value. Charsets are collections of characters with their digital encoding, which can be documented in various ISO or non ISO documents like ISO 10646, ISO 8859-1, etc. Default Internet charset is the UTF-8 global script. Anyway, non of them gives me a correct French keyboard :-) As long as I have not one, and all the people of the world do not have a collections of characters to produce a keyboard respecting their language, I am sorry but all this will call for more than a mental twist to satisfies me. BTW , I always wander (and nobody answered) what is going to be the use for your browser to know the name of the Script? Will it tell you "Hi! John, you entered Mongolian script", or will it call a collection of digital records to do someting with them? Or is it just for statistics? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:48:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00L-0005LK-ET; Wed, 11 May 2005 18:48:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00E-0005JN-1S for ltru@megatron.ietf.org; Wed, 11 May 2005 18:48:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06421 for ; Wed, 11 May 2005 18:48:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0Fp-000717-Ar for ltru@ietf.org; Wed, 11 May 2005 19:04:37 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW00B-0003hA-Rz; Wed, 11 May 2005 15:48:28 -0700 Message-Id: <6.2.1.2.2.20050511222907.05def740@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 22:30:49 +0200 To: "Randy Presuhn" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [psg.com #952] how to determine whether an ISO 639 registration request has been processed? In-Reply-To: <007301c5565f$decebde0$7f1afea9@oemcomputer> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <009301c555ed$9957b7c0$030aa8c0@DEWELL> <4281C670.5896@xyzzy.claranet.de> <20050511123500.GC14557@skunk.reutershealth.com> <6.2.1.2.2.20050511144726.049779d0@mail.jefsey.com> <007301c5565f$decebde0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 21:30 11/05/2005, Randy Presuhn said: >New Flash: Participation in the IETF is by *individuals*. > >Everyone: *please* stop wasting time and energy on the non-technical >cr*p that some insist on injecting into the mailing list, in the hope of >derailing our work. I am not sure this is a call of order in reference to the insults I must accept. But I agree that there is a lot of work made on this WG to derail the Charter. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:48:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00L-0005Li-Ie; Wed, 11 May 2005 18:48:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00E-0005JQ-79 for ltru@megatron.ietf.org; Wed, 11 May 2005 18:48:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06424 for ; Wed, 11 May 2005 18:48:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0Fp-000711-B3 for ltru@ietf.org; Wed, 11 May 2005 19:04:37 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW009-0003hA-KB; Wed, 11 May 2005 15:48:26 -0700 Message-Id: <6.2.1.2.2.20050511205732.04972090@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 21:00:01 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [psg.com #960] use ITU E.164 calling codes instead of ISO 3166 country codes In-Reply-To: <001201c55657$48ffe300$7f1afea9@oemcomputer> References: <001201c55657$48ffe300$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.8 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 20:28 11/05/2005, Randy Presuhn wrote: >Hi - > > In message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg01643.html > > it was proposed to use ITU E.164 calling codes instead of ISO 3166 > > country codes. > >I haven't seen much support for this proposal, and some rather compelling >arguments against it, so unless I see a groundswell of support, I plan to >mark this one "rejected". Where did you read _instead_?? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:48:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00V-0005Mb-My; Wed, 11 May 2005 18:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW00U-0005MV-DB for ltru@megatron.ietf.org; Wed, 11 May 2005 18:48:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06437 for ; Wed, 11 May 2005 18:48:43 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0G6-00071e-3A for ltru@ietf.org; Wed, 11 May 2005 19:04:54 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW00T-0003pj-0D for ltru@ietf.org; Wed, 11 May 2005 15:48:45 -0700 Message-Id: <6.2.1.2.2.20050511223120.05df74f0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 00:48:39 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Interim and Paris? In-Reply-To: <002101c5565d$05a25880$7f1afea9@oemcomputer> References: <198A730C2044DE4A96749D13E167AD37250259@MOU1WNEXMB04.vcorp.ad.vrsn.com> <6.2.1.2.2.20050511021431.048f8060@mail.jefsey.com> <001601c555d3$453fd9c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050511050500.045cf140@mail.jefsey.com> <004c01c555f1$462471c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050511151324.0492ceb0@mail.jefsey.com> <002101c5565d$05a25880$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 21:09 11/05/2005, Randy Presuhn said: >I am intrigued by the statement "I note that I am the only non-English >speaker at the WG-ltru". Grammar aside, it can be read several ways: > (1) All members except Jefsey are proficient in English. Please stop this non-technical .... It seems that as you document it with your "Grammar aside": (1) is the only correct solution jfc BTW, thank you to tell me what is grammatically wrong in my sentence, since it was not intended. ---- On 21:09 11/05/2005, Randy Presuhn said: >There is currently no plan for the WG to meet in Paris, which would make >scheduling an interim in July even more unlikely. dear!!! I hoped this WG would be fully closed by then!!! So, I was proposing to have a drink over a way to speed up the resolution process before disputing again over the Last Round. I am sure that if we could agree on what I propose (a non BCP RFC, respecting RFC 3066 and but your text otherwise, documenting your langtag "script" extensions) IESG would consider accepting it much faster. But if you want to delay the things that long, we will keep going. Don't be afraid, it would be too harmfull otherwise. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:54:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW06T-0007Qv-I7; Wed, 11 May 2005 18:54:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW06S-0007Qq-Rx for ltru@megatron.ietf.org; Wed, 11 May 2005 18:54:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06935 for ; Wed, 11 May 2005 18:54:51 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0M1-0007Mp-Ke for ltru@ietf.org; Wed, 11 May 2005 19:11:02 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW06H-0006cv-00 for ltru@ietf.org; Wed, 11 May 2005 15:54:45 -0700 Message-ID: <000a01c5567c$c135f740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001201c55657$48ffe300$7f1afea9@oemcomputer> <6.2.1.2.2.20050511205732.04972090@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #960] use ITU E.164 calling codes instead of ISO 3166 country codes Date: Wed, 11 May 2005 15:57:05 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Wednesday, May 11, 2005 12:00 PM > Subject: Re: [Ltru] [psg.com #960] use ITU E.164 calling codes instead of ISO 3166 country codes > > > At 20:28 11/05/2005, Randy Presuhn wrote: > >Hi - > > > In message > > > http://www1.ietf.org/mail-archive/web/ltru/current/msg01643.html > > > it was proposed to use ITU E.164 calling codes instead of ISO 3166 > > > country codes. > > > >I haven't seen much support for this proposal, and some rather compelling > >arguments against it, so unless I see a groundswell of support, I plan to > >mark this one "rejected". > > Where did you read _instead_?? ... Please, then, state just what your proposal is. Showing what the changes to the ABNF would be might help. In the meantime, pending discussion of your proposal, I've re-opened the issue. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 18:59:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0Ai-0000II-FM; Wed, 11 May 2005 18:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0Ag-0000IA-Lp for ltru@megatron.ietf.org; Wed, 11 May 2005 18:59:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07192 for ; Wed, 11 May 2005 18:59:13 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0QF-0007YF-Bx for ltru@ietf.org; Wed, 11 May 2005 19:15:24 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 15:59:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: xml2rfc category (was RE: [Ltru] Re: [psg.com #938] shouldintroduction alludetointendedbcp status?) Date: Wed, 11 May 2005 15:59:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6CEF@irvmbxw01.quest.com> Thread-Topic: xml2rfc category (was RE: [Ltru] Re: [psg.com #938] shouldintroduction alludetointendedbcp status?) Thread-Index: AcVWdwvc2b0kh9a7Su2dA+yYb2JCRQAAJY0AAAFPKoA= From: "Addison Phillips" To: "Scott Hollenbeck" , "Frank Ellermann" , X-OriginalArrivalTime: 11 May 2005 22:59:01.0910 (UTC) FILETIME=[05DB8360:01C5567D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I know that I am: I had to download it to get the updates that reference = RFC 3978 just a few weeks ago. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Scott Hollenbeck > Sent: 2005?5?11? 15:23 > To: 'Frank Ellermann'; ltru@ietf.org > Subject: xml2rfc category (was RE: [Ltru] Re: [psg.com #938] > shouldintroduction alludetointendedbcp status?) >=20 > > -----Original Message----- > > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > > Sent: Wednesday, May 11, 2005 6:09 PM > > To: ltru@ietf.org > > Subject: [Ltru] Re: [psg.com #938] should introduction > > alludetointendedbcp status? > > > > Scott Hollenbeck wrote: > > > > > I see it in the rfc2629 DTD. In the element, add a > > 'category=3D' > > > attribute. Valid values:std|bcp|info|exp|historic. > > > > No effect with my test document. Adding seriesNo=3D"47" also > > has no effect. With number=3D"XXXX" it's RfC XXXX and no I-D. >=20 > Are you using the most recent version of xml2rfc? I'm pretty sure = I've > used > this before without any trouble. >=20 > -Scott- >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 19:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0CG-0000c2-RN; Wed, 11 May 2005 19:00:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0CF-0000bk-J4 for ltru@megatron.ietf.org; Wed, 11 May 2005 19:00:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07309 for ; Wed, 11 May 2005 19:00:52 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0Rq-0007gb-9F for ltru@ietf.org; Wed, 11 May 2005 19:17:03 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4BN0dL5004572; Wed, 11 May 2005 19:00:40 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 11 May 2005 19:00:38 -0400 Date: Wed, 11 May 2005 19:00:38 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #951] extensibility via codes not maintained by ISO Message-ID: <20050511230038.GJ6864@skunk.reutershealth.com> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <008e01c555ed$1fd21940$030aa8c0@DEWELL> <6.2.1.2.2.20050511143223.05800580@mail.jefsey.com> <20050511151931.GE6864@skunk.reutershealth.com> <6.2.1.2.2.20050511172503.056d4b80@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050511172503.056d4b80@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin scripsit: > Frank documented what you can do with this mental twist. Scripts are named > in ISO 15924 ane are collections of characters documented in ISO 10646 with > their digital value. Many ISO 15924 scripts are not presently encoded, and ISO 15924 in no way depends on ISO 10646. > UTF-8 global script. UTF-8 is not a script. > Anyway, non of them gives me a correct French keyboard :-) Keyboards are neither scripts nor encodings. > BTW , I always wander (and nobody answered) what is going to be the use for > your browser to know the name of the Script? Will it tell you "Hi! John, > you entered Mongolian script", or will it call a collection of digital > records to do someting with them? Or is it just for statistics? A browser could look for a Mongolian font, or could replace the document with a note that it is in a script you don't understand, or transliterate it into a script you do understand. But of course language tags are not confined to browsers: they can also be used, for example, to catalogue resources. -- Babies are born as a result of the John Cowan mating between men and women, and most http://www.reutershealth.com men and women enjoy mating. http://www.ccil.org/~cowan --Isaac Asimov in Earth: Our Crowded Spaceship jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 19:10:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0LX-0001RE-Gi; Wed, 11 May 2005 19:10:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0LX-0001R9-16 for ltru@megatron.ietf.org; Wed, 11 May 2005 19:10:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07925 for ; Wed, 11 May 2005 19:10:27 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0b8-0008BA-L6 for ltru@ietf.org; Wed, 11 May 2005 19:26:38 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW00F-0003hA-41 for ltru@ietf.org; Wed, 11 May 2005 15:48:31 -0700 Message-Id: <6.2.1.2.2.20050511231606.05803c10@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 23:17:28 +0200 To: "'LTRU Working Group'" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude tointendedbcp status? In-Reply-To: <20050511210359.BCFV10612.lakermmtao12.cox.net@A31P> References: <634978A7DF025A40BFEF33EB191E13BC0B5A6C84@irvmbxw01.quest.com> <20050511210359.BCFV10612.lakermmtao12.cox.net@A31P> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 23:04 11/05/2005, Scott Hollenbeck wrote: >Ah, I see it in the rfc2629 DTD. In the element, add a 'category=' >attribute. Valid values: std|bcp|info|exp|historic. Addison, did you try "historic"? If it worked it would save our vacations. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 19:12:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0Nc-0001Ww-DW; Wed, 11 May 2005 19:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0Na-0001W5-Ug for ltru@megatron.ietf.org; Wed, 11 May 2005 19:12:39 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08078 for ; Wed, 11 May 2005 19:12:34 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DW0Fq-0005r2-L3 for ltru@lists.ietf.org; Thu, 12 May 2005 01:04:38 +0200 Received: from 212.82.251.9 ([212.82.251.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 01:04:38 +0200 Received: from nobody by 212.82.251.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 01:04:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 12 May 2005 01:11:05 +0200 Organization: Lines: 93 Message-ID: <42829109.2E72@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B5A6C3F@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.9 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >> ACK. > I take that as the converse of NACK, that is, U+0006? ACK  NAK NACK ;-) > I read rule (4) to mean that VU would not be added, which is > one thing you have objected to. Oops, I was counting bullets, and the 4th bullet discusses the Recommended-Prefix. And the IM example is not the 9th bullet but the 10th: | Codes assigned by ISO 639, ISO 15924, or ISO 3166 that do not | conflict with existing subtags of the associated type but | which represent the same meaning as an existing subtag of | that type are entered into the IANA registry as new records. | The field 'canonical value' for that record MUST contain the | existing subtag of the same meaning For some obscure reasons I thought that that's the "no problem" rule. But you see "new tag for an already registered entity" as conflict / problem. Therefore you skip the 10th bullet and arrive at number 11, the "conflict" rule. Maybe you should define "conflict", I thought that it's only about collisions. Yes, and 3.3.11.4 says "don't register if it's unnecessary". > The phrase "no new entry is created" seems to forbid the > creation of 'VU'. That could be changed to produce your > following example, of course. It does also seem to conflict > with the "rule 9" you cite Now identified as 3.3.10. ["decanonicalization"] > it conflicts with guarantees of stability for tags. "Stable" means that NH is always what NH stood for, that's the same piece of land no matter what its actual name (e.g.Vanuatu) or canonical tag (either NH or VU) might be. Forever. Stable. But maybe you have another idea of "stable" (?) > thus certain processors might transform tags from "en-NH" to > "en-VU" per this text in Section 2.2.9: Yes, and that sounds like a good idea. Like jw -> jv etc. > content authors having to choose a different tag than > previously If they love NH they are free to stick to it. If they insist on canonical the are forced to adapt. Like everybody else in Vanuatu. It's not that bad, I'm almost used to EUR instead of DEM after some years. [scenario 4, Use: VU] > It is different than 'Canonical': it could be informative, > for example, instead of normative (as canonical is) This "normative vs. informative" is W3C magic, it's not worse than IETF magic, but, hm... okay, I get what you mean. It's a bit strange to say "Use: VU" but "Canonical: NH" for the same piece of [***] Or "Use: yi" but "Canonical: ji" for the same language. If what you propose is to replace the "normative Canonical" by an "informative Use" everywhere it's okay, as I said W3C magic. [missing MUST NOT Suppress-Script and rationale] > You will recall that I argued against Suppress-Script (even > though I *also* thought of it and named it). | when X = 'SUPPRESS-SCRIPT' then do | if DEFS.N <> '' then exit TRAP( LINE REC ) | DEFS.N = '-' || YY ; XREF = XREF + 1 | end Names. If I want a DEFS DEFault-Script" I just do it ;-) > "This field helps ensure greater compatibility between the > language tags generated according to the rules in this > document and language tags and tag processors or consumers > based on RFC 3066." I like it. Randy, Ira, and others wanted a "MUST NOT unless" instead of the SHOULD NOT in 3.1 and 4.1.2, but as it is the SHOULD NOT is clear from my POV. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 19:22:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0XO-0006Kn-4e; Wed, 11 May 2005 19:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0XN-0006KZ-GE for ltru@megatron.ietf.org; Wed, 11 May 2005 19:22:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09181 for ; Wed, 11 May 2005 19:22:42 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0my-0000Wt-Gi for ltru@ietf.org; Wed, 11 May 2005 19:38:53 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 16:22:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally supported Date: Wed, 11 May 2005 16:22:34 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6CFC@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally supported Thread-Index: AcVWe5Ixt9d9yXUUT3S0jwUXD/Fe7QAAlsQw From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "Mark Davis" , , "Frank Ellermann" X-OriginalArrivalTime: 11 May 2005 23:22:35.0231 (UTC) FILETIME=[50432EF0:01C55680] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Mark, > I am sorry, Frank is right. You cannot be cannonical with tables you = do > not > control. This is precisely the problem the charter wants us to = address. > Stability is not in the ID but in the documented object. You have two > possibilities: to attach a date to the ID or to define your own = canonical > table and relate it to the ID. > jfc Uh... The items in the registry all have dates attached to them. And = they are in their own canonical table over which the registry draft has = ironclad control. We are discussing rules for the maintenance of = canonical values and stability of those values in that registry. The use = of ISO 3166 to provide some of the values in that table does not mean = that the registry cedes control to the ISO 3166 MA. Defining rules for = how the registry tracks ISO 3166 is what we are about here, since = creating separate standards for these things is unappealing. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 19:37:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0m3-0008Vp-33; Wed, 11 May 2005 19:37:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0m1-0008Vh-3t for ltru@megatron.ietf.org; Wed, 11 May 2005 19:37:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09893 for ; Wed, 11 May 2005 19:37:49 -0400 (EDT) Received: from gundel.de.clara.net ([212.82.225.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW11Y-0001H4-Cd for ltru@ietf.org; Wed, 11 May 2005 19:53:57 -0400 Received: from [212.82.251.9] (helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1DW0z1-000KjM-EE; Thu, 12 May 2005 01:51:19 +0200 Message-ID: <4282971B.527D@xyzzy.claranet.de> Date: Thu, 12 May 2005 01:36:59 +0200 From: Frank Ellermann Organization: X-Mailer: Mozilla 3.0 (OS/2; U) MIME-Version: 1.0 To: Scott Hollenbeck Subject: Re: xml2rfc category (was RE: [Ltru] Re: [psg.com #938] should introduction alludetointendedbcp status?) References: <20050511222318.ESZC13442.lakermmtao05.cox.net@A31P> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Scott Hollenbeck wrote: > Are you using the most recent version of xml2rfc? I use the Web interface (1.29) http://xml.resource.org/ and for the validation http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ > I'm pretty sure I've used this before without any trouble. Maybe you prepared an RfC for the in-queue with number="XXXX" and say seriesNo="100" for BCP 100, that has visible effects, Or you used , that's something I've not tested. More than one isn't the trick to add text below the WG. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 19:39:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0nA-0000FQ-Ez; Wed, 11 May 2005 19:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0n9-0000FL-F9 for ltru@megatron.ietf.org; Wed, 11 May 2005 19:39:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09929 for ; Wed, 11 May 2005 19:38:58 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW12j-0001I3-PH for ltru@ietf.org; Wed, 11 May 2005 19:55:10 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW0n1-0004qo-00 for ltru@ietf.org; Wed, 11 May 2005 16:38:55 -0700 Message-ID: <001301c55682$ed0e4600$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <009301c555ed$9957b7c0$030aa8c0@DEWELL> <4281C670.5896@xyzzy.claranet.de> <20050511123500.GC14557@skunk.reutershealth.com> <6.2.1.2.2.20050511144726.049779d0@mail.jefsey.com> <007301c5565f$decebde0$7f1afea9@oemcomputer> <6.2.1.2.2.20050511222907.05def740@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #952] how to determine whether an ISO 639 registration request has been processed? Date: Wed, 11 May 2005 16:41:16 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, May 11, 2005 1:30 PM > Subject: Re: [Ltru] [psg.com #952] how to determine whether an ISO 639 registration request has been processed? > > On 21:30 11/05/2005, Randy Presuhn said: > >New Flash: Participation in the IETF is by *individuals*. > > > >Everyone: *please* stop wasting time and energy on the non-technical > >cr*p that some insist on injecting into the mailing list, in the hope of > >derailing our work. > > I am not sure this is a call of order in reference to the insults I must > accept. ... It is, though it is primarily a call to order in reference to the counterproductive material present in many of Jefsey's postings. I call upon Jefsey to stick to the technical problems at hand, and I call upon the rest of the WG to do likewise. Doug's response about "treachery and skulduggery" was unhelpful, but understandable in light of Jefsey's patently offensive initial comment. (number 23 in http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html ) Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 20:05:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1CJ-00075n-Ge; Wed, 11 May 2005 20:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1CI-00073r-6C for ltru@megatron.ietf.org; Wed, 11 May 2005 20:05:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11567 for ; Wed, 11 May 2005 20:04:58 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW1Rt-0002hS-8p for ltru@ietf.org; Wed, 11 May 2005 20:21:10 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW1CF-0003b7-00 for ltru@ietf.org; Wed, 11 May 2005 17:04:59 -0700 Message-ID: <002d01c55686$90faf760$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <198A730C2044DE4A96749D13E167AD37250259@MOU1WNEXMB04.vcorp.ad.vrsn.com><6.2.1.2.2.20050511021431.048f8060@mail.jefsey.com><001601c555d3$453fd9c0$7f1afea9@oemcomputer><6.2.1.2.2.20050511050500.045cf140@mail.jefsey.com><004c01c555f1$462471c0$7f1afea9@oemcomputer><6.2.1.2.2.20050511151324.0492ceb0@mail.jefsey.com><002101c5565d$05a25880$7f1afea9@oemcomputer> <6.2.1.2.2.20050511223120.05df74f0@mail.jefsey.com> Subject: Re: [Ltru] Interim and Paris? Date: Wed, 11 May 2005 17:07:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "JFC (Jefsey) Morfin" > To: > Sent: Wednesday, May 11, 2005 3:48 PM > Subject: Re: [Ltru] Interim and Paris? > > On 21:09 11/05/2005, Randy Presuhn said: > >I am intrigued by the statement "I note that I am the only non-English > >speaker at the WG-ltru". Grammar aside, it can be read several ways: > > (1) All members except Jefsey are proficient in English. > > Please stop this non-technical .... > > It seems that as you document it with your "Grammar aside": (1) is the only > correct solution > jfc > > > BTW, thank you to tell me what is grammatically wrong in my sentence, since > it was not intended. ... The word "at" should have been "in", and "WG-ltru" should have been "ltru WG". Even with those corrections, the sentence is still odd, as "non-English speaker" would normally be understood as someone with far less command of the language than you. The noun-like "non-English speaker" itself seems odd, though the adjective-like "non- English speaking" would be ok. I'm sure someone who spends more time thinking about English could give a better explanation for my native-speaker intuitions. However, this is *way* off topic, so let's get back to work. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 20:24:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Up-0003pU-VD; Wed, 11 May 2005 20:24:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Uo-0003pM-E7 for ltru@megatron.ietf.org; Wed, 11 May 2005 20:24:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12556 for ; Wed, 11 May 2005 20:24:08 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW1kP-0003cP-1r for ltru@ietf.org; Wed, 11 May 2005 20:40:19 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j4C0Nqm21265; Thu, 12 May 2005 09:23:52 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 450a5442_c27c_11d9_9b33_0030482533a1_27187; Thu, 12 May 2005 09:24:57 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005EA0; 12 May 05 09:26:28 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 12 May 05 09:26:09 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG005E9C; 12 May 05 09:26:00 +0900 Message-Id: <6.0.0.20.2.20050511192847.0675b880@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 May 2005 19:39:28 +0900 To: "JFC (Jefsey) Morfin" , "LTRU Working Group" From: Martin Duerst Subject: Re: jamais deux sans trois ? (was RE: [Ltru] RFC 2277 - considerations) In-Reply-To: <6.2.1.2.2.20050511034921.03850200@mail.jefsey.com> References: <6.2.1.2.2.20050511034921.03850200@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 11:53 05/05/11, JFC (Jefsey) Morfin wrote: >1. this is what what _I_ would like add/remove/replace that Randy asked. Randy asked for *specific* text. This is how the IETF works: If oppinions are too far apart, or unclear (or both), specific text always helps. I don't remember having seen a single line of specific text from you, but if I missed something, please tell me. >2. I certainly want to save time and stop a "consensus developped of the remainder of the WG": this same residual reached the same "consensus" on another list for the same proposition. Do you really want the same result? Please note that the IETF works with "rough consensus", which does not mean that everybody agreed completely. The problem with the "other list" was that it wasn't a WG, which means there were no chairs, and so nobody who could assess consensus in an official function. The second problem was that some people complained that they didn't know this work was going on; this is quite different for the WG which has been widely announced. So it's very well possible that on some, or even many, issues, this WG reaches the same or a similar conclusion as a (by chance or by expertise and interest) similarly composed (but not chartered group) has reached before. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 22:23:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3Lx-0005Lc-Hm; Wed, 11 May 2005 22:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3Lw-0005LI-2t for ltru@megatron.ietf.org; Wed, 11 May 2005 22:23:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20765 for ; Wed, 11 May 2005 22:23:05 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW3bZ-0001Ys-9I for ltru@ietf.org; Wed, 11 May 2005 22:39:17 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW3Lu-0008KG-1G; Wed, 11 May 2005 19:23:06 -0700 Message-Id: <6.2.1.2.2.20050512020849.04598650@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 02:22:40 +0200 To: "Randy Presuhn" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [psg.com #952] how to determine whether an ISO 639 registration request has been processed? In-Reply-To: <001301c55682$ed0e4600$7f1afea9@oemcomputer> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <009301c555ed$9957b7c0$030aa8c0@DEWELL> <4281C670.5896@xyzzy.claranet.de> <20050511123500.GC14557@skunk.reutershealth.com> <6.2.1.2.2.20050511144726.049779d0@mail.jefsey.com> <007301c5565f$decebde0$7f1afea9@oemcomputer> <6.2.1.2.2.20050511222907.05def740@mail.jefsey.com> <001301c55682$ed0e4600$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 01:41 12/05/2005, Randy Presuhn said: >Doug's response about "treachery and skulduggery" was unhelpful, but >understandable in light of Jefsey's patently offensive initial comment. >(number 23 in http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html ) The comment is correct. It may be Franglishly awkward, but itis not offensive. It says that the MUST is inadequate because its procedure of application is not documented. It then say how the MUST and the lack of procedure will be understood (because this is the way it was understood by _every_ of the five reviewers I called upon. It was also a point which really upset them). Anyway, I am sure that if that comment was patently offensive, the Chairs would have clarified the issue with me before broadcasting it as #952. This point is obviously out of a Draft non replacing RFC 3066 and does not prevent consens on that case. This point is an absolute blocking factor as is language treatment disparity. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 22:23:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3Lx-0005Ly-OF; Wed, 11 May 2005 22:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3Lw-0005LJ-4h for ltru@megatron.ietf.org; Wed, 11 May 2005 22:23:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20768 for ; Wed, 11 May 2005 22:23:05 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW3bZ-0001Yl-9E for ltru@ietf.org; Wed, 11 May 2005 22:39:17 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW3Lp-0008KG-Rk; Wed, 11 May 2005 19:23:02 -0700 Message-Id: <6.2.1.2.2.20050512012041.05dab4e0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 04:22:55 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [psg.com #960] use ITU E.164 calling codes instead of ISO 3166 country codes In-Reply-To: <000a01c5567c$c135f740$7f1afea9@oemcomputer> References: <001201c55657$48ffe300$7f1afea9@oemcomputer> <6.2.1.2.2.20050511205732.04972090@mail.jefsey.com> <000a01c5567c$c135f740$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 00:57 12/05/2005, Randy Presuhn wrote: > > From: "JFC (Jefsey) Morfin" > > To: "Randy Presuhn" ; "LTRU Working > Group" > > Sent: Wednesday, May 11, 2005 12:00 PM > > Subject: Re: [Ltru] [psg.com #960] use ITU E.164 calling codes instead > of ISO 3166 country codes > > > > > > > At 20:28 11/05/2005, Randy Presuhn wrote: > > >Hi - > > > > In message > > > > http://www1.ietf.org/mail-archive/web/ltru/current/msg01643.html > > > > it was proposed to use ITU E.164 calling codes instead of ISO 3166 > > > > country codes. > > > > > >I haven't seen much support for this proposal, and some rather compelling > > >arguments against it, so unless I see a groundswell of support, I plan to > > >mark this one "rejected". > > > > Where did you read _instead_?? >... > >Please, then, state just what your proposal is. Showing what the changes >to the >ABNF would be might help. > >In the meantime, pending discussion of your proposal, I've re-opened the >issue. My logic is the logic of the Charter which is a IANA registry where one can register needed relevant subtags. In the case of a region, ISO 3166, M.9, E.164, X.121, postcodes, geographic coordinates, ISO 3166-2, etc. are serious entries people may want/need to use or register. Our problem is to provide the IANA with a solution to take care of the version. I provided one. Mark has discussed the canonical aspect, Interface Grids may also provide a solution (an IPv6 identifier compatible 10 to 12 hexa incremented number). I fully understand that this logic conflicts with the specific format the W3C needs to use in the XML case. This is why the current Draft is the second document expected from this WG and not the first one. In the specific case of each applications the format may prevent some of the IANA from being used. It is the choice and the responsibility of the authors of each application specific format to best use the possibilities offered by the general Internet language indentification framework the first document should be. For example in the case of E.164, I have no objection that the format calls for 4 or more digits padded with Fs since E.164 would probably more used as area codes. Non F digits would only be considered. jfc >Randy > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 22:23:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3M3-0005Sw-6Q; Wed, 11 May 2005 22:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3Lw-0005LT-OQ for ltru@megatron.ietf.org; Wed, 11 May 2005 22:23:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20779 for ; Wed, 11 May 2005 22:23:06 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW3bZ-0001Yn-9A for ltru@ietf.org; Wed, 11 May 2005 22:39:18 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW3Lr-0008KG-1S; Wed, 11 May 2005 19:23:03 -0700 Message-Id: <6.2.1.2.2.20050512014259.045a5be0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 01:43:29 +0200 To: John Cowan From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #951] extensibility via codes not maintained by ISO In-Reply-To: <20050511230038.GJ6864@skunk.reutershealth.com> References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <008e01c555ed$1fd21940$030aa8c0@DEWELL> <6.2.1.2.2.20050511143223.05800580@mail.jefsey.com> <20050511151931.GE6864@skunk.reutershealth.com> <6.2.1.2.2.20050511172503.056d4b80@mail.jefsey.com> <20050511230038.GJ6864@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 01:00 12/05/2005, John Cowan said: >they can also be used, for example, to catalogue >resources. Such as keyboard's keys? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 22:23:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3M3-0005TY-BF; Wed, 11 May 2005 22:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3Lw-0005LS-Bh for ltru@megatron.ietf.org; Wed, 11 May 2005 22:23:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20767 for ; Wed, 11 May 2005 22:23:05 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW3bZ-0001Yq-9M for ltru@ietf.org; Wed, 11 May 2005 22:39:17 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW3Ls-0008KG-25; Wed, 11 May 2005 19:23:04 -0700 Message-Id: <6.2.1.2.2.20050512014536.0459d930@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 01:55:10 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally supported In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B5A6CFC@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B5A6CFC@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 01:22 12/05/2005, Addison Phillips said: >Uh... The items in the registry all have dates attached to them. And they >are in their own canonical table over which the registry draft has >ironclad control. We are discussing rules for the maintenance of canonical >values and stability of those values in that registry. The use of ISO 3166 >to provide some of the values in that table does not mean that the >registry cedes control to the ISO 3166 MA. Defining rules for how the >registry tracks ISO 3166 is what we are about here, since creating >separate standards for these things is unappealing. Can you document the interest of a canonical table over which you want to have ironclad control? You create there your own standard. What for? Your job is not to maintain a canonical base but to tell users what a code used at a given date meant in the ISO table. It could change every year, you do not mind. Not your concern. Your concern (look at the charter) is to make sure the users know what is each subtag in the format and reach the proper version value. The registry does not cede control to the ISO 3166 MA, the ISO 3166 MA _HAS_ control, the registry just copy it in a readable form for your usage. Otherwise it conflicts. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 11 22:23:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3M3-0005U8-Fc; Wed, 11 May 2005 22:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3Lz-0005Pj-Oo for ltru@megatron.ietf.org; Wed, 11 May 2005 22:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20783 for ; Wed, 11 May 2005 22:23:09 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW3bd-0001Z7-1I for ltru@ietf.org; Wed, 11 May 2005 22:39:21 -0400 Received: from lns-p19-2-idf-82-251-106-212.adsl.proxad.net ([82.251.106.212] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DW3Lw-0008KG-7M; Wed, 11 May 2005 19:23:08 -0700 Message-Id: <6.2.1.2.2.20050512025656.03ec1030@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 04:10:43 +0200 To: Martin Duerst , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: jamais deux sans trois ? (was RE: [Ltru] RFC 2277 - considerations) In-Reply-To: <6.0.0.20.2.20050511192847.0675b880@itmail.it.aoyama.ac.jp> References: <6.2.1.2.2.20050511034921.03850200@mail.jefsey.com> <6.0.0.20.2.20050511192847.0675b880@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi! Martin, At 12:39 11/05/2005, Martin Duerst wrote: >At 11:53 05/05/11, JFC (Jefsey) Morfin wrote: > > >1. this is what what _I_ would like add/remove/replace that Randy asked. > >Randy asked for *specific* text. This is how the IETF works: >If oppinions are too far apart, or unclear (or both), specific >text always helps. I don't remember having seen a single line >of specific text from you, but if I missed something, please >tell me. I responded to that many time. No problem anwering again. I have no text to offer to enhance a text I oppose where it is and I support in part at another place. For the other part I have no text to offer before the debate to fully substantiate it has not been engaged. The way this WG has organised its debate is IMHO in the other way we needed. I submit that the present Draft includes the second document. And, as expressed since December, I do not support the solutions it proposes because I find them conflicting, but I do not consider myself interested and competent enough in W3C issues to be sure I am right. So I trust Addison. If he wants it, let him get it. I understand that he needs it urgently. So I observe that in trying to fix the world to fix his own problem Mark and him are embracing a too large issue and only delay their document. Now, when they have completed their text, I am ready - but I am sure they would do it better - to remove from it all what does not belong to a second document and to propose a Draft to be completed by the filtering elements they had before, they also will be able to better document and refine than me. I underline that this is what I proposed to do with them the very first day we started this WG. Had we gone that way I am quite sure we would be all through as per the schedule. IRT the first document, it is to address the main points of the Charter. As I explained it is of no use to propose a Draft before the WG reviewed he Charter. Expecting that we would start with a normal methodology, first considering what we had to do instead of starting with what we had failed, I planned to produce a Draft by mid-April. I will produce a Draft one month, or less if I can, after we have completed a serious review of the Charter. If this is after the closing of the WG too bad. I did not make the calendar. Obviously I know what this Draft will include, I documented that several times (an Internet language identification framework, supporting them along the lines of RFC 3066, 2277, 2130, etc. and extending them along the lines of the Charter and of the Multilingual Internet requirement, to support the existing RFC referencing RFC 3066 and the Addison/Mark's Draft). But I have no reason to oppose and not to benefit from this WG. I want to be sure this Draft is worded in the best way to obtain a general rough consensus. I also documented that I wanted this Draft to be approved by non IETF concerned parties, to legitimate its options I consider as key elements of the Multilingual Internet - specifying lingual classes and most probably structuring the basic interelation with CRCs (I do not think the IANA can support the considered amount of traffic, and I do not consider that a centralized repository is adequate to the needs we need to address - which are far more complex than discussed in here). In this I know for certain I am in full agreement with the coming standards and international resolutions. > >2. I certainly want to save time and stop a "consensus developped of the > remainder of the WG": this same residual reached the same "consensus" on > another list for the same proposition. Do you really want the same result? > >Please note that the IETF works with "rough consensus", which does not >mean that everybody agreed completely. The problem with the "other list" >was that it wasn't a WG, This was a problem we all rose and we were glad that the IESG accepted to review a charter for it. I feel however extremely unatease, and I know I am not alone, because I see that this charter has not been considered, and that instead of a clean sheet review and of open fresh work on the charter, this WG started working on Draft-xxx.11.txt using it as its own reference. >which means there were no chairs, and so nobody >who could assess consensus in an official function. May I underline that this Draft had been prepared by a list under the direct supervision of the IETF Chair by the Chair of an established organisation of which he is serious participant. That several other Members of this WG are members of this organisation. An organisation I do not disapprove since I joined it as a Member (however still not accepted on the CLDR list I was interested in). The quality and the serious of this Draft has never been questioned by anyone. What is opposed is that this Draft wants to fix the internet to fix a specific (temporary/legacy) problem. Several explained the authors that they could produce an RFC referring to RFC 3066 without problem to fix their need, and then to share in an adaptation of BPC 47 to the new needs their fix would call for (a generic registration of ISO 10646, 3166 and 15924 neither RFC 2277 nor 3066 oppose) but respecting the specifics of many other applications they refuse to consider. > The second problem >was that some people complained that they didn't know this work was >going on; this is quite different for the WG which has been widely >announced. I think I was the first one to rise this point. As it was by luck that I discovered that a Last Call had been called during the Xmas period. The current Draft does not correct this problem in the way it does not enhance the ietf-languages mailing list and governance. >So it's very well possible that on some, or even many, issues, this >WG reaches the same or a similar conclusion as a (by chance or by >expertise and interest) similarly composed (but not chartered group) >has reached before. Certainly. But this is not the case. The only chance would be in this case that the same text, the same expertise (not considering me) and the same interests do not produce a similar conclusion. This is why we need a fresh thinking or fresh blood. There is not much fresh blood at the IETF by lack of interest documented by the IAB's priorities. The reason why my position is at odds with most is that I want to maintain the Multilingual Internet documentation within the IETF as much as possible (in spite of the grassroots effort I documented a planned meeting) because I think this is a factor of stability for the whole system and probably the only way to avoid the balkanisation of the Internet. This is why I bet on a fresh thinking ... still quite tough to uncover, but I am sure it will come. I am used to that for a long. The worst opponents usually become the most active innovators. And the innovation at hands is really interesting. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 00:54:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW5ij-00030u-8l; Thu, 12 May 2005 00:54:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW5ig-0002ys-5H for ltru@megatron.ietf.org; Thu, 12 May 2005 00:54:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01116 for ; Thu, 12 May 2005 00:54:41 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW5yI-0001AZ-FX for ltru@ietf.org; Thu, 12 May 2005 01:10:55 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW5ib-00065g-00 for ltru@ietf.org; Wed, 11 May 2005 21:54:41 -0700 Message-ID: <002301c556af$0a684bc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001d01c555ac$b2bb91a0$7f1afea9@oemcomputer> <20050510223815.GC6864@skunk.reutershealth.com> Subject: Re: [Ltru] [psg.com #959] consolidate review process instructions Date: Wed, 11 May 2005 21:57:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "John Cowan" > To: "Randy Presuhn" > Sent: Tuesday, May 10, 2005 3:38 PM > Subject: Re: [Ltru] [psg.com #959] consolidate review process instructions > > Randy Presuhn scripsit: > > Hi - > > > > > Comments 31 and 32 in > > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > > suggest separating instructions to the reviewer and the review > > > process participants from the registry format and IANA procedure > > > sections. > > > > > > "31. 3.1. also includes direction to the Reviewer which should be > > > presented > > > in a separate part from the format description. > > > > > > 32. 3.2. this part is not a IANA procedure but a long guidance for the > > > Reviewer and the Reviewing process participants, limited to current > > > possible cases" > > This should be marked accepted and closed, as the latest draft has taken > it into account. > > -- > John Cowan www.reutershealth.com www.ccil.org/~cowan jcowan@reutershealth.com > 'Tis the Linux rebellion / Let coders take their place, > The Linux-nationale / Shall Microsoft outpace, > We can write better programs / Our CPUs won't stall, > So raise the penguin banner of / The Linux-nationale. --Greg Baker Ok, I've marked it "resolved." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 00:56:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW5kP-0003DU-Kg; Thu, 12 May 2005 00:56:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW5kP-0003DP-6g for ltru@megatron.ietf.org; Thu, 12 May 2005 00:56:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01270 for ; Thu, 12 May 2005 00:56:29 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW604-0001Dy-4r for ltru@ietf.org; Thu, 12 May 2005 01:12:44 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW5kN-0006VZ-00 for ltru@ietf.org; Wed, 11 May 2005 21:56:32 -0700 Message-ID: <002801c556af$4c6ffb80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001801c555ac$9ce64640$7f1afea9@oemcomputer> <20050510223826.GD6864@skunk.reutershealth.com> Subject: Re: [Ltru] [psg.com #958] move tag formation rules Date: Wed, 11 May 2005 21:58:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "John Cowan" > To: "Randy Presuhn" > Sent: Tuesday, May 10, 2005 3:38 PM > Subject: Re: [Ltru] [psg.com #958] move tag formation rules > > Randy Presuhn scripsit: > > Hi - > > > > > Comment number 30 in > > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > > (referring to the -00- draft) > > > "30. 3.1. includes a registry format description (OK) but also > > > considerations on the way the tags should be formed which have nothing > > > to > > > do in a file description. They should be moved into 2.4.1" > > This should be marked accepted and closed, as the latest draft has taken it > into account. > > Randy, ltru co-chair > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > -- > John Cowan jcowan@reutershealth.com http://www.ccil.org/~cowan > Is it not written, "That which is written, is written"? Ok, I've marked this one "resolved". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 01:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW674-0007fz-DI; Thu, 12 May 2005 01:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW671-0007fg-US for ltru@megatron.ietf.org; Thu, 12 May 2005 01:19:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02689 for ; Thu, 12 May 2005 01:19:53 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW6Me-0002P6-0X for ltru@ietf.org; Thu, 12 May 2005 01:36:05 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW66w-0003MS-00 for ltru@ietf.org; Wed, 11 May 2005 22:19:50 -0700 Message-ID: <00b901c556b2$8e26c4c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] [psg.com #941] determining currency of registry versions Date: Wed, 11 May 2005 22:22:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Wednesday, May 11, 2005 8:26 AM > Subject: RE: [Ltru] [psg.com #941] determining currency of registry versions > > I think Randy's suggestion revision is reasonable. It's a small change > with no negative side effects, and making the change will bring closure > to this particular issue quickly. ... Ok, I'll mark this one "resolved". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 01:45:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW6Vc-0004oy-Cg; Thu, 12 May 2005 01:45:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW6Va-0004oq-BF for ltru@megatron.ietf.org; Thu, 12 May 2005 01:45:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03972 for ; Thu, 12 May 2005 01:45:17 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW6lF-0003k1-BP for ltru@ietf.org; Thu, 12 May 2005 02:01:29 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW6VY-0000Bi-00 for ltru@ietf.org; Wed, 11 May 2005 22:45:16 -0700 Message-ID: <00dd01c556b6$1b7c6160$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com> Date: Wed, 11 May 2005 22:47:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Can someone map these comments into proposals? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - In entering comments from the message http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html there were a few where I haven't been able to figure out what is being requested. If anyone can come up with a constructive interpretation for any of these, I'd appreciate it. As they appear in the original posting, they are: > 5. Introduction: the introduction describes the use of the tag to name a > menu of references (dictionaries) and documents that it is often necessary > to document style related elements (dialect, orthography) and writing > system. These are the 5 elements I want to see documented. > 6. Introduction: documents that knowing the language is useful (qualifies) > or required (defines) for some processes. What is the intended meaning? > 7. Introduction: indicates that labels are one of the means of indicating > (meaning?) languages used. No other means is alluded to, and no comments > about their common consistency is provided? > 8. Introduction: identifies only two functions for the document: an > "identifier mechanism" and a "registration function". It does not talk of > the dissemination of that information, nor of the way applications should > use it. > 33. 3.3 : Understanding the meaning of "Subtags required for stability and > to keep the registry synchronised" will probably be a source of long > debates. It should be documented. > 55. it lists challenges to be addressed: "to specify a mechanism for easily > identifying the role of each subtag in the language tag". This is > addressed by the Draft. But this challenge is contradictory with stability > challenge above. If a language tag displays an identifiable subtag, it > becomes by nature dependent from the underlying value of the subtag. If someone can translate any of these into specific proposals for changes to the i-d, I'll happily create new RT tickets for them. If not, then at least it's documented that we tried to figure out what was being requested. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:31:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Dw-00062a-UJ; Thu, 12 May 2005 02:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Du-00062R-OZ for ltru@megatron.ietf.org; Thu, 12 May 2005 02:31:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27382 for ; Thu, 12 May 2005 02:31:05 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7Ta-0005VY-FM for ltru@ietf.org; Thu, 12 May 2005 02:47:18 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7Ds-000074-00 for ltru@ietf.org; Wed, 11 May 2005 23:31:04 -0700 Message-ID: <011d01c556bc$81dcd1a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:33:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] [psg.com #961] re-work part 3 of -00 draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment number 28 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > requests "28. 3: the reference to RFC 2434 is correct but the rest of > the part 3 seems inappropriate. RFC 2434 says "If the IANA is expected > to play a role in the management of a name-space the IANA must be given > clear and concise instructions describing that role". The part 3 is > neither clear and concise and is contradictory with the document which > describes a IANA file to be maintained by an IESG reviewer. The IESG > having authority on the IANA, the role of the IANA is to store and > disseminate the current file version as maintained by the reviewer." > > This was accommodated by the re-work of material going from the > the -00 draft to the -01 draft, so this issue is recorded as > "resolved". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:31:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Ea-00064M-LP; Thu, 12 May 2005 02:31:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7EY-00064E-Vs for ltru@megatron.ietf.org; Thu, 12 May 2005 02:31:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27478 for ; Thu, 12 May 2005 02:31:45 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7UD-0005WQ-Pc for ltru@ietf.org; Thu, 12 May 2005 02:47:59 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7EW-0000As-00 for ltru@ietf.org; Wed, 11 May 2005 23:31:44 -0700 Message-ID: <012201c556bc$99dc01e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:34:08 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] [psg.com #962] use CAN instead of MAY in section 3.3 of -00 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 34 of > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > "34. 3.3. why a "MAY" concerning the "description, note and prefix > fields" is not documented by conditions? Is that not a "CAN"." > > Subsequent discussion showed no support, and counter-argued that > RFC 2119 doesn't provide "CAN", and that "MAY" is correct semantic. > > Issue rejected. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:33:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Fq-0006KY-KU; Thu, 12 May 2005 02:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Fo-0006JG-PL for ltru@megatron.ietf.org; Thu, 12 May 2005 02:33:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27574 for ; Thu, 12 May 2005 02:33:03 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7VT-0005Xp-HW for ltru@ietf.org; Thu, 12 May 2005 02:49:16 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7Fm-0000ax-00 for ltru@ietf.org; Wed, 11 May 2005 23:33:02 -0700 Message-ID: <012701c556bc$c7b9a540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:35:24 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] [psg.com #963] section on registration procedure is confusing X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 35 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > reads: > "35. 3.3. the registration procedure is of extreme confusion and mixes > the form to use, the lack of definition of the requester, the iana.org > list which is not introduced, the registration request which must be > guessed, a non commented MAY, registration tricks, comments on probable > behaviour of the reviewing list, digression on Slovenian, designation > of the reviewer by the IESG, what should happen when the review period > has elapsed without any guidance to the reviewer, that a IANA list > Members and an IESG designated reviewer make an IETF decision, that the > initial registrant has some moral pre-eminence (under the form of a > comment) and that languages are not considered for registration on the > fact they actually exist, but on their own (non documented) merits." Has this been accommodated by the changes present in the -01 draft? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:35:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Hg-000738-WB; Thu, 12 May 2005 02:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7HK-0006z4-IX for ltru@megatron.ietf.org; Thu, 12 May 2005 02:34:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27716 for ; Thu, 12 May 2005 02:34:37 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7X0-0005d5-Cr for ltru@ietf.org; Thu, 12 May 2005 02:50:50 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7HJ-0000nU-00 for ltru@ietf.org; Wed, 11 May 2005 23:34:37 -0700 Message-ID: <013001c556bd$00874580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:36:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] [psg.com #964] section 3.4 of -00 is hard to understand X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 36 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > reads: > "36. 3.4. Difficult to understand. The first sentence is probably > inherited from the former versions of the draft. "compatible with > applications that process language tags according to this > specification" seems to refer to filtering which should be part of the > of the second document produced by the WG-ltru." > Has this been accommodated by the changes in the -01 draft? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:35:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Hh-00073T-7g; Thu, 12 May 2005 02:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7HU-0006zl-UT for ltru@megatron.ietf.org; Thu, 12 May 2005 02:34:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27719 for ; Thu, 12 May 2005 02:34:47 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7X9-0005dA-OS for ltru@ietf.org; Thu, 12 May 2005 02:51:01 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7HS-0000oF-00 for ltru@ietf.org; Wed, 11 May 2005 23:34:46 -0700 Message-ID: <013101c556bd$064acbe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:37:09 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] [psg.com #965] expectation of support for automated reading of registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 37 in > > "37. 3.4. The description of information to be maintained is clear, but > the format is not described. This permits IANA to freely change it or > to present it in HTML form. This does not help its automated reading." > > Some discussion regarding expectations is at > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > http://www.ietf.org/mail-archive/web/ltru/current/msg00717.html > Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:36:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7JD-0007LC-G5; Thu, 12 May 2005 02:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7JC-0007Ks-0D for ltru@megatron.ietf.org; Thu, 12 May 2005 02:36:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27890 for ; Thu, 12 May 2005 02:36:32 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7Yr-0005hx-NP for ltru@ietf.org; Thu, 12 May 2005 02:52:45 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7J9-00011X-00 for ltru@ietf.org; Wed, 11 May 2005 23:36:31 -0700 Message-ID: <013601c556bd$44eb34c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:38:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] [psg.com #966] remove something from security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 38 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > reads: > "38. 4. security considerations should not deal with users political > security outside of their network usage. Otherwise tons of such > considerations should be presented." > > followup in > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html (apologies for the vague subject line - if someone can give me something more precise, I'll happily change it.) Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:40:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7NO-0008G2-7c; Thu, 12 May 2005 02:40:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7NN-0008FQ-5K for ltru@megatron.ietf.org; Thu, 12 May 2005 02:40:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28239 for ; Thu, 12 May 2005 02:40:51 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7d3-0005px-0l for ltru@ietf.org; Thu, 12 May 2005 02:57:05 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7NL-0003YN-00 for ltru@ietf.org; Wed, 11 May 2005 23:40:51 -0700 Message-ID: <013b01c556bd$dfff8600$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:43:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] [psg.com #967] address homograph issues in security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > reads: > "39. 4. An important security consideration is homographs. It is > certainly possible to include part of text in a foreign language which > look printed as in another language or having a different meaning or > printing (phishing). Concerns are also the double "-" which is > specifically used by the IANA code "xn"." > > language issue, rather than tagging, > see http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html I think we're close to rejecting this one. Randy, ltru co-chair Technical comment: Perhaps this one might be accomodated by including an explicit statement about how the repertoire for creating language tags makes homographs a non-issue (at least in a well-designed font) for the tags themselves. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:41:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7O4-0008Qh-BL; Thu, 12 May 2005 02:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7O2-0008PS-BO for ltru@megatron.ietf.org; Thu, 12 May 2005 02:41:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28293 for ; Thu, 12 May 2005 02:41:31 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7df-0005qX-CT for ltru@ietf.org; Thu, 12 May 2005 02:57:44 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7Ny-0003fd-00 for ltru@ietf.org; Wed, 11 May 2005 23:41:30 -0700 Message-ID: <014001c556bd$f6c8f560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:43:53 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] [psg.com #968] load on IANA server by applications X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 40 in message > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > says: > "40. 4. Fourth paragraph tend to say that specification of valid sub- > tags MUST be available over the internet but that applications should > take possible DoS into consideration. This is an important indication > on the way the Draft proposes the registry file to be used and > accessed. It can be read that applications can freely access it and > proposed mirrors: this may impose on the IANA a load which will result > in its permanent inability of service" Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:42:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Oj-0000FW-9a; Thu, 12 May 2005 02:42:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7Oh-0000FH-2C for ltru@megatron.ietf.org; Thu, 12 May 2005 02:42:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28344 for ; Thu, 12 May 2005 02:42:13 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7eN-0005uY-07 for ltru@ietf.org; Thu, 12 May 2005 02:58:27 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7Od-0003jb-00 for ltru@ietf.org; Wed, 11 May 2005 23:42:12 -0700 Message-ID: <014501c556be$0fc3eac0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:44:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] [psg.com #969]character set considerations material is contradictory X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 41 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > says: (regarding -00 draft) > "41. 5. character set consideration are contradictory: they say that > character a-z exist in most character sets (good news) [what means that > there are some where they do not exist] so there should not be > character set presentation issue [in the character set where they do > not exist?]. Also the consideration only concerns the "display" what > has a limited interest if the a-z characters do not exist on the > keyboard. But may be this supposes that "intelligent people" use ascii > compatible keyboards (see below)." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 02:42:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7PK-0000SC-QJ; Thu, 12 May 2005 02:42:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7PJ-0000S7-Pr for ltru@megatron.ietf.org; Thu, 12 May 2005 02:42:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28406 for ; Thu, 12 May 2005 02:42:52 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7ey-0005vh-OC for ltru@ietf.org; Thu, 12 May 2005 02:59:06 -0400 Received: from h-64-105-136-32.snvacaid.dynamic.covad.net ([64.105.136.32] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DW7PH-0003zK-00 for ltru@ietf.org; Wed, 11 May 2005 23:42:51 -0700 Message-ID: <014a01c556be$275e65c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 11 May 2005 23:45:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] [psg.com #970] add reference to xml schema version 1.0 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment 42 in > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > reads: (with respect to -00 draft) > "42. 6. compatibility is preserved with RFC 3066 but not with evolution > of ISO code elements. The XML Schema version 1.0 requirements are > quoted but not documented." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 04:17:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW8rC-0004nB-27; Thu, 12 May 2005 04:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW8rA-0004n3-69 for ltru@megatron.ietf.org; Thu, 12 May 2005 04:15:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03861 for ; Thu, 12 May 2005 04:15:42 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW96q-0000v7-Md for ltru@ietf.org; Thu, 12 May 2005 04:31:57 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j4C8Fcfp009146; Thu, 12 May 2005 11:15:38 +0300 (EEST) Message-ID: <428310AA.9090302@kotus.fi> Date: Thu, 12 May 2005 11:15:38 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #951] extensibility via codes not maintained by ISO References: <20050510220454.BOGK11382.mta7.adelphia.net@megatron.ietf.org> <008e01c555ed$1fd21940$030aa8c0@DEWELL> <6.2.1.2.2.20050511143223.05800580@mail.jefsey.com> <20050511151931.GE6864@skunk.reutershealth.com> <6.2.1.2.2.20050511172503.056d4b80@mail.jefsey.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I'd like to comment on the need to know the script. The end user needs this information, in order to determine whether she or he is able to even recognize the characters used in the text, particularly if the orthographies of a given language provide for several scripts to choose from. Also, for many of the lesser known languages, the end user may not even be aware of the one and only script. The end user can only get the information if it is available for the browser. (In my book, UTF-8 can never be characterized as a script). Erkki I. Kolehmainen JFC (Jefsey) Morfin wrote: > On 17:19 11/05/2005, John Cowan said: > >> JFC (Jefsey) Morfin scripsit: >> >> > Most of the used charsets (sorry, "scripts") in use and part of the >> > Internet world are not documented by ISO 19524. >> >> Charsets and scripts are distinct concepts. Charsets are encodings of >> characters into octets. Scripts are collections of characters used in >> writing systems, and have no connection with encoding. ISO 8859-1 and >> Win-1252 are charsets. Latin, Greek, and Cherokee are scripts. > > > Frank documented what you can do with this mental twist. Scripts are > named in ISO 15924 ane are collections of characters documented in ISO > 10646 with their digital value. Charsets are collections of characters > with their digital encoding, which can be documented in various ISO or > non ISO documents like ISO 10646, ISO 8859-1, etc. Default Internet > charset is the UTF-8 global script. > > Anyway, non of them gives me a correct French keyboard :-) > > As long as I have not one, and all the people of the world do not have a > collections of characters to produce a keyboard respecting their > language, I am sorry but all this will call for more than a mental twist > to satisfies me. > > BTW , I always wander (and nobody answered) what is going to be the use > for your browser to know the name of the Script? Will it tell you "Hi! > John, you entered Mongolian script", or will it call a collection of > digital records to do someting with them? Or is it just for statistics? > > jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 04:31:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW96X-0007yZ-8X; Thu, 12 May 2005 04:31:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW96V-0007wl-Bc for ltru@megatron.ietf.org; Thu, 12 May 2005 04:31:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05044 for ; Thu, 12 May 2005 04:31:33 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW9MB-0001Uf-Ju for ltru@ietf.org; Thu, 12 May 2005 04:47:48 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j4C8VWfp009931; Thu, 12 May 2005 11:31:32 +0300 (EEST) Message-ID: <42831464.5030609@kotus.fi> Date: Thu, 12 May 2005 11:31:32 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] RFC 2277 - considerations References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com> <6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp> <01LO1QSCZ7S800004T@mauve.mrochek.com> <6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com> <002a01c55815$27558240$7f1afea9@oemcomputer> <6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com> <001001c55829$830b81c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com> <007d01c558ae$1cb4ec60$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org "no, let's not go down that path" Sincerely, Erkki I. Kolehmainen Randy Presuhn wrote: > Hi - > > Rather than addressing the numerous points and assertions > individually, I'd like to get a hum from the working group: > > Should we adopt the general course of action outlined below by > Jefsey? I'm not looking for point-by-point responses at this time, > just a succinct "yes, let's adopt the general approach Jefsey > proposed," "no, let's not go down that path," or "I'd like to hear > more discussion of his proposal before deciding." > > Randy, ltru co-chair > > >>From: "JFC (Jefsey) Morfin" >>To: "Randy Presuhn" ; "LTRU Working Group" >>Sent: Tuesday, May 10, 2005 7:02 AM >>Subject: Re: [Ltru] RFC 2277 - considerations >> >> > >>Dear Randy, >>it is always a pleasure to repeat the same thing to you. So I will do it again. >> >>At 04:05 14/05/2005, Randy Presuhn wrote: >> >>>Given the depth and breadth of expertise of the participants, I'm willing >>>to take their lack of confusion as a sign that we know what we need to do. >>> >>Never thought a WG was a resume contest, but I suppose I have no problem >>with that. >> >>Now, it would be surprising that people who came for a purpose (which will >>never be globally consensual, two negative Last Calls), would be confused >>on what they want to achieve. Those who disagreed but me gave up. >> >> >>>Could you *please* identify the *specific* text in the draft you would >>>like to add / remove / replace? >>> >>I thought it was clear to you, since end of December. >> >>Remove: the whole draft. >> >>Add: the XML oriented parts of the Draft in the second document where they >>belong, together with a consistent documentation of its filters and working >>tools (you oddily have no problem to add them to langtag libraries but you >>cannot add them to charset libraries?), a good explanation of the charset >>violation needs, a clear assessment/commitment of the resources required >>from IANA >> >>Replace: make BCP 47 an Internet technology (RFC 1591, 1958, 2277, 2301, >>3066, etc., etc.) consistent framework for the support of language context >>identification as one of the Multilingual Internet building blocks, >>together with others works such: within IETF (OPES, IDN, LDAP, PPP, SNMP, >>etc.), outside (for the time being) the IETF (those I know of: classes, >>groups, externets, CRC, ISO 639-X, UNITAG). And let document a consistent >>IANA external tables and values management consistent or aggregating the >>current registries. >> >> >>>The IESG reviewed our charter before approving it. >>> >>IESG will also review the deliverables of this WG before accepting them for >>a Last Call and then after the Last Call. And during an appeal if they >>approved it. So would IAB after that if they confirmed. >> >>What is the interest to have something which pleases a small score of >>supporters and is defeated by lack of global consensus? If the problem is a >>IANA registry conflict please tell us. If the problem is to ascertain the >>Unicode table vs. ISO 10646 please tell us. If the problem is to make ISO >>15924 the center of the world please tell us. If the problem are W3C >>analysis difficulties please tell us. If the problem is rooted in the CLDR >>structures please tell us. >> >>Your problem is neither to produce a Draft, nor to shut my mouth. Your >>target is to address a problem. Either it is the one written in the Charter >>and IMHO its is partly erroneously worded the way you seem to read it. Or >>it is another one, and I doubt you can solve it if you do not spell it. If >>it is part of both, let sort it out first. >> >> >>>You even commented on the proposed charter while the IESG was reviewing >>>it, so if anything was unclear, you certainly had opportunity to make your >>>view heard at that time. >>> >>I commented positively on your proposition to have a WG. This is what I >>asked for early January. I had proposed the creation of a WG-TAGs because >>this is what I am working on in a much broader scope. I was not opposed on >>a WG on language and I detailed my conditions a minima. These conditions >>are not spelled out in the Charter, but since the Charter has been >>submitted/reviewed to/by the IESG it is mostly consistent with the whole >>Internet architecture (all the more that it MUST be read in its perspective). >> >> >>>This working group's job is to produce two documents, as spelled out in >>>the charter. You are the only participant who seems to have any >>>difficulty understanding the charter. >>> >>May be I am the only one with a very low IQ? Did you forget one thing, I am >>also the only one who does not to speak English. That alone should be an >>alarm for you when addressing a multilingual issue. I am also the only one >>in various areas of importance to this topic (a ccTLD registry, the founder >>of the oldest user/operator structure, a former @large panelist, an active >>contributor to the WSIS process where multilingualism is a priority, etc.). >> >>I only think there is a qui pro quo you should have resolved first. You >>proposed a text with a W3C/Unicode culture, it was read by the IESG with an >>Internet culture. I read it with another more global network culture. All >>this makes the Internet, but one has to accept to have a limited >>methodology. This starts with reviewing what all the participants have read >>and accept in your text, not to end with it when everyone is gone. >> >>You said there were thorny points in the charter. There are. I am not sure >>you saw them all. I just waited for the list to be calm enough to rise the >>charset issue. >> >>Please understand, as I mentioned it in my response to the Chairs and ADs, >>I am as everyone else entitled to a Charter review by the WG to make sure I >>am not wrong, before producing my own Draft. Having a fragmented review of >>the Charter while most of the people disappointed with the Draft are gone, >>only delays the whole process and does not help. Neither me, nor the >>current Draft. >> >> >>>No one else on this mailing list has expressed any confusion as to what >>>our deliverables are. >>> >>This is precisely the problem. On such a matter, there should have been >>much more. This only means they are not here. >> >>Language tags, the way authors see them, are a deep change in the Internet >>architecture. This has lead to the opposition met during the first two last >>calls. This WG should have started in assessing that change. Its reasons, >>its implications. debreifing the opposition, not just jumping at an 11th >>and 12th version of the same proposition with the same text. >> >>- They want a change which affects/opposes a consistent corpus RFC. >>- I see one of the seeds of the response to an urgent market and political >>demand not addressed until now. >> >>Both have to be discussed. Better here than on the general list during the >>third Last Call, all the more if it is opposed by a short Draft of mine. >> >>You just start listing some of the points of my last month review (delay is >>not on my side) on the management system you chose. Thank you: this will >>save me the time of listing during the Last Calls all the points I rose >>which have not been discussed - what would have been poor (I am not sure >>however you will list them all?). Now they have to be addressed. But not >>all them are listed and most are listed in a way no one can understand what >>it refers to without accessing the whole review each time and to figure out >>where it is. I gave each point a "#" number (there are 55 of them). Why not >>just to paste them into your system before commenting them? Also, in the >>follow-up, why to assume people agree with you (and not me) because they >>did not comment? >> >>Think that my draft would use the Charter framework and quotes the >>concerned RFCs, documenting how to support the XML, DNS, IDNA, OPES, LDAP, >>PPP, etc. etc. needs (even the non documented ones of CLDR) in the scalable >>way the Internet has always supported them with success up to >>now. Discussing the reducing ways others may have proposed over time which >>have been opposed with that success. Scalable, simple, robust, stable, >>secure will be the keywords. I could also propose a F2F meeting before the >>Paris meeting. I would propose people from the MINC, UNESCO, WSIS, >>Francophonie, etc. to attend. >> >>I accept there will be lacks in such a document of mine as I lack inputs >>from the WG debate on the charter, and I have not the time, the expertise >>and the interest to became a specialist of all the IETF oddities it should >>aggregate and consolidate, such as the RFC of Ira McDonnald, and all the >>times the internationalisation of the ASCII Internet is considered in RFCs. >>IMHO what you miss is that what you made at stake is the transition from >>internationalisation to multilingualisation (actually to vernacularisation) >>- user to user relations, over brain to brain, over end to end. I accept >>this is beyond what this WG is able to discuss, but this This is _your_ >>decision in wanting to replace BCP 47. >> >>I frankly prefer focusing on the Multilingual Global Network (MGN) - as it >>should progressively result from our current work, the WSIS, the dialog >>between ITU, WSIS and the operators efforts (currently engaged). Let be >>candid: if this WG does not produce a Draft along that lines, the Draft (or >>eventually an RFC) and the IANA registry will only be a problem to forget. >>Is that what you really want? >> >>Here is what I propose for a serious review of the topic: >> >>1. what I had not time to do it yet: a dump of the whole IETF corpus and a >>grep on "international" and "lingual" to know which RFC can be affected and >>which experience has been gathered in there. There are more than you >>thought in preparing the Charter. >> >>2. to seriously review the problems, starting with those quoted by the >>charter. What they really mean. What are the architectural implications >>they may have in an MGN framework. They are not perfect, but they will lead >>to most of them. >> >>3. what architectural responses they may call for and what this implies on >>the structures of the contents' containers. >> >>4. _IF_ there are architectural changes (I doubt there are much, as the MGN >>IMHO concerns higher layers than the end to end architecture) what are >>they? IMHO they concerns mainly the way to use IPv6, OPES and the DNS due >>to current implication of the DNS in the architecture of usage and hyperlinks. >> >>5. what is the stable, simple, robust framework the IETF technology should >>provide to the applications designers. >> >>6. to seriously review the way this can be made supported by IANA and CRCs. >>And let implement test applications. >> >>7. let discuss how to address the evolutions/trasnsitions possibly implied >>at a network level. >> >>This makes the first document. >> >> >>Then a second document should use that stable foundations to write the >>specific solution called by the documentation of the charset in the W3C >>containers and the stabilisation of the XML langtag, its filtering, sorting >>etc. Another document could be proposed by Unicode (if free of IPRs) to >>document the CLDR approach, propositions and specific own usage (if any) of >>this framework. >> >>I accept that the expertise of this WG is more oriented towards the second >>document and I am more interested in the first one. There are two possible >>responses to that: >> >>1. either to follow my proposition above and make the general list aware of >>what we plan to discuss. I bet there will be new comers with depth and >>breadth of expertise in the concerned areas (even if IETF, IAB and IESG is >>not much aware/motivated in the lingual areas). >> >>2. or to follow the recommendations received on the general list during the >>Last Call. Let us stop pretending changing BCP 47: let consolidate RFC 3066 >>as it is today, with its relations to RFC 2277 and 2301, and publish a >>specific solution for XML. I do not think anyone will oppose this. Only >>some people will find it odd if you document IETF values violation they may >>want the IETF/W3C liaison committee to approve. This is the RFC 3066 >>bis/ter option. The real work will be carried afterward. And your problem >>will be quickly fixed. This is what I proposed the day we started the WG >>and to work with the Authors on that. We could be done for a long. Actually >>the WG was even not necessary. >> >>I fully understand this is does not make things simple for you. But you >>decided that the most complex issue Internet is to face since its >>inception, and delayed for 20 years, was something simple. It is not. >>All the best. >>jfc >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 07:33:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWBwp-0001z4-Vx; Thu, 12 May 2005 07:33:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWBwo-0001yz-Eh for ltru@megatron.ietf.org; Thu, 12 May 2005 07:33:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16122 for ; Thu, 12 May 2005 07:33:45 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWCCV-0007CB-JV for ltru@ietf.org; Thu, 12 May 2005 07:50:01 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 12 May 2005 07:33:35 -0400 id 00594408.42833F0F.0000712B Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Addison Phillips'" , "'Frank Ellermann'" , ltru@ietf.org Subject: RE: xml2rfc category (was RE: [Ltru] Re: [psg.com #938] shouldintroduction alludetointendedbcp status?) Date: Thu, 12 May 2005 07:33:08 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07916C72@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B5A6CEF@irvmbxw01.quest.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Sorry, looks like I was mistaken. I just checked and found the attribute in several of my XML source files, but nothing in the text output. -Scott- > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Wednesday, May 11, 2005 6:59 PM > To: Scott Hollenbeck; Frank Ellermann; ltru@ietf.org > Subject: RE: xml2rfc category (was RE: [Ltru] Re: [psg.com > #938] shouldintroduction alludetointendedbcp status?) > > > I know that I am: I had to download it to get the updates > that reference RFC 3978 just a few weeks ago. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Scott > Hollenbeck > > Sent: 2005?5?11? 15:23 > > To: 'Frank Ellermann'; ltru@ietf.org > > Subject: xml2rfc category (was RE: [Ltru] Re: [psg.com #938] > > shouldintroduction alludetointendedbcp status?) > > > > > -----Original Message----- > > > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > > > Sent: Wednesday, May 11, 2005 6:09 PM > > > To: ltru@ietf.org > > > Subject: [Ltru] Re: [psg.com #938] should introduction > > > alludetointendedbcp status? > > > > > > Scott Hollenbeck wrote: > > > > > > > I see it in the rfc2629 DTD. In the element, add a > > > 'category=' > > > > attribute. Valid values:std|bcp|info|exp|historic. > > > > > > No effect with my test document. Adding seriesNo="47" also > > > has no effect. With number="XXXX" it's RfC XXXX and no I-D. > > > > Are you using the most recent version of xml2rfc? I'm > pretty sure I've > > used > > this before without any trouble. > > > > -Scott- > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 07:59:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWCLR-0006at-9T; Thu, 12 May 2005 07:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWCLQ-0006ao-C2 for ltru@megatron.ietf.org; Thu, 12 May 2005 07:59:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17525 for ; Thu, 12 May 2005 07:59:11 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWCb7-0007t3-M1 for ltru@ietf.org; Thu, 12 May 2005 08:15:27 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4CBwuOM007957; Thu, 12 May 2005 07:58:56 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 12 May 2005 07:58:56 -0400 Date: Thu, 12 May 2005 07:58:56 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] [psg.com #963] section on registration procedure is confusing Message-ID: <20050512115856.GL14557@skunk.reutershealth.com> References: <012701c556bc$c7b9a540$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012701c556bc$c7b9a540$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > Has this been accommodated by the changes present in the -01 draft? Yes. -- Take two turkeys, one goose, four John Cowan cabbages, but no duck, and mix them http://www.ccil.org/~cowan together. After one taste, you'll duck jcowan@reutershealth.com soup the rest of your life. http://www.reutershealth.com --Groucho _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFTi-0007XV-Bp; Thu, 12 May 2005 11:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFTf-0007WH-AN for ltru@megatron.ietf.org; Thu, 12 May 2005 11:19:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01825 for ; Thu, 12 May 2005 11:19:53 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWFjO-0004J3-NO for ltru@ietf.org; Thu, 12 May 2005 11:36:12 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:19:42 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:19:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally supported Date: Thu, 12 May 2005 08:19:43 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally supported Thread-Index: AcVWmeZEWsFsQy6IQgecCbkEvawLlQAa0/8A From: "Peter Constable" To: X-OriginalArrivalTime: 12 May 2005 15:19:41.0609 (UTC) FILETIME=[050D1190:01C55706] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The ISO 3166 MA _has_ control over the content of _ISO 3166_. This RFC would specify how language subtags for use on the Internet are controlled. ISO does not have direct control over that, nor is it a priori necessary that the RFC must be written in a way that gives them implicit control. This much has been obvious for some time now, and it is not helping us move toward completion to have to revisit such things. Can we please bring an end to this? Peter Constable > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of JFC (Jefsey) Morfin > Sent: Wednesday, May 11, 2005 4:55 PM > To: Addison Phillips > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally > supported >=20 > On 01:22 12/05/2005, Addison Phillips said: > >Uh... The items in the registry all have dates attached to them. And they > >are in their own canonical table over which the registry draft has > >ironclad control. We are discussing rules for the maintenance of > canonical > >values and stability of those values in that registry. The use of ISO > 3166 > >to provide some of the values in that table does not mean that the > >registry cedes control to the ISO 3166 MA. Defining rules for how the > >registry tracks ISO 3166 is what we are about here, since creating > >separate standards for these things is unappealing. >=20 > Can you document the interest of a canonical table over which you want to > have ironclad control? You create there your own standard. What for? Your > job is not to maintain a canonical base but to tell users what a code used > at a given date meant in the ISO table. It could change every year, you do > not mind. Not your concern. Your concern (look at the charter) is to make > sure the users know what is each subtag in the format and reach the proper > version value. The registry does not cede control to the ISO 3166 MA, the > ISO 3166 MA _HAS_ control, the registry just copy it in a readable form > for > your usage. Otherwise it conflicts. > jfc >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:30:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFdt-0000zR-9p; Thu, 12 May 2005 11:30:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFdr-0000zM-QM for ltru@megatron.ietf.org; Thu, 12 May 2005 11:30:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04445 for ; Thu, 12 May 2005 11:30:25 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWFtb-0004i9-5o for ltru@ietf.org; Thu, 12 May 2005 11:46:44 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:30:17 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:30:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homograph issues in securityconsiderations Date: Thu, 12 May 2005 08:30:18 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #967] address homograph issues in securityconsiderations Thread-Index: AcVWvZnzGF7BDY6qQmmh75mXEUbZfgASNPmw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:30:16.0862 (UTC) FILETIME=[7FB0FBE0:01C55707] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > > Comment > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > reads: > > "39. 4. An important security consideration is homographs. It is > > certainly possible to include part of text in a foreign language which > > look printed as in another language or having a different meaning or > > printing (phishing). Concerns are also the double "-" which is > > specifically used by the IANA code "xn"." > Perhaps this one might be accomodated by including an explicit statement > about how the repertoire for creating language tags makes homographs a > non-issue (at least in a well-designed font) for the tags themselves. Because the character repertoire permitted in our protocol elements is limited to a-z, A-Z, 0-9 and "-" (with no two consecutive "-"s allowed), I believe the only homograph issue is between LATIN SMALL LETTER L and DIGIT ONE. Since the ISO source standards we use all use alpha-only IDs, and the M.49 numeric IDs are numeric only, the only potential for confusion exists in registered variants. We might consider imposing a requirement on subtag registrations that no subtag may be registered if it differs from an existing subtag only by substitution of confusables (l and 1). If we want to do that, we might also want to make this a requirement on extension RFCs. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:31:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFeq-0001NE-QN; Thu, 12 May 2005 11:31:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFep-0001N6-OG for ltru@megatron.ietf.org; Thu, 12 May 2005 11:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04508 for ; Thu, 12 May 2005 11:31:25 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWFuZ-0004jE-7a for ltru@ietf.org; Thu, 12 May 2005 11:47:44 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 08:31:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #963] section on registration procedure is confusing Date: Thu, 12 May 2005 08:31:15 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6FE9@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #963] section on registration procedure is confusing Thread-Index: AcVWvH15b/UY7heQTmup2wJu7t8x7AASx4MA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:31:16.0237 (UTC) FILETIME=[A314E3D0:01C55707] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org It should be. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?11? 23:35 > To: LTRU Working Group > Subject: [Ltru] [psg.com #963] section on registration procedure is > confusing >=20 > Hi - >=20 > > Comment 35 in > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > reads: > > "35. 3.3. the registration procedure is of extreme confusion and = mixes > > the form to use, the lack of definition of the requester, the = iana.org > > list which is not introduced, the registration request which must be > > guessed, a non commented MAY, registration tricks, comments on = probable > > behaviour of the reviewing list, digression on Slovenian, = designation > > of the reviewer by the IESG, what should happen when the review = period > > has elapsed without any guidance to the reviewer, that a IANA list > > Members and an IESG designated reviewer make an IETF decision, that = the > > initial registrant has some moral pre-eminence (under the form of a > > comment) and that languages are not considered for registration on = the > > fact they actually exist, but on their own (non documented) merits." >=20 > Has this been accommodated by the changes present in the -01 draft? >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:32:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFgI-0001Xm-Uw; Thu, 12 May 2005 11:32:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFgH-0001XE-F8 for ltru@megatron.ietf.org; Thu, 12 May 2005 11:32:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04653 for ; Thu, 12 May 2005 11:32:55 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWFw2-0004ks-1d for ltru@ietf.org; Thu, 12 May 2005 11:49:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 08:32:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #965] expectation of support for automated readingof registry Date: Thu, 12 May 2005 08:32:46 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6FEE@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #965] expectation of support for automated readingof registry Thread-Index: AcVWvOzjTJ60xWuPQMuqH5V8P95ZmAASt6Ww From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:32:48.0220 (UTC) FILETIME=[D9E861C0:01C55707] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Some changes were made to the section on extensions which should address = this issue. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?11? 23:37 > To: LTRU Working Group > Subject: [Ltru] [psg.com #965] expectation of support for automated > readingof registry >=20 > Hi - >=20 > > Comment 37 in > > > > "37. 3.4. The description of information to be maintained is clear, = but > > the format is not described. This permits IANA to freely change it = or > > to present it in HTML form. This does not help its automated = reading." > > > > Some discussion regarding expectations is at > > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > > http://www.ietf.org/mail-archive/web/ltru/current/msg00717.html > > >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:34:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFhx-0001tk-5d; Thu, 12 May 2005 11:34:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFhv-0001ta-PS for ltru@megatron.ietf.org; Thu, 12 May 2005 11:34:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04749 for ; Thu, 12 May 2005 11:34:37 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWFxf-0004nB-Bh for ltru@ietf.org; Thu, 12 May 2005 11:50:56 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 08:34:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #964] section 3.4 of -00 is hard to understand Date: Thu, 12 May 2005 08:34:26 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6FF3@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #964] section 3.4 of -00 is hard to understand Thread-Index: AcVWvQa/rIPgqfAATHOASl4U1bV3yAASwXxA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:34:27.0315 (UTC) FILETIME=[14F91430:01C55708] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Yes. The new text reads: Extension subtags are those introduced by single-letter subtags other = than 'x-'. They are reserved for the generation of identifiers which = contain a language component, and are compatible with applications = understand language tags. For example, they might be used to define = locale identifiers, which are generally based on language. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?11? 23:36 > To: LTRU Working Group > Subject: [Ltru] [psg.com #964] section 3.4 of -00 is hard to = understand >=20 > Hi - >=20 > > Comment 36 in > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > reads: > > "36. 3.4. Difficult to understand. The first sentence is probably > > inherited from the former versions of the draft. "compatible with > > applications that process language tags according to this > > specification" seems to refer to filtering which should be part of = the > > of the second document produced by the WG-ltru." > > >=20 > Has this been accommodated by the changes in the -01 draft? >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:36:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFjL-0002Kd-4r; Thu, 12 May 2005 11:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFjJ-0002KV-9D for ltru@megatron.ietf.org; Thu, 12 May 2005 11:36:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04872 for ; Thu, 12 May 2005 11:36:02 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWFz2-0004oq-Qa for ltru@ietf.org; Thu, 12 May 2005 11:52:22 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:35:51 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:35:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #969]character set considerations material iscontradictory Date: Thu, 12 May 2005 08:35:54 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #969]character set considerations material iscontradictory Thread-Index: AcVWveM24AGO6yDnRRGAbvd+n/gfLwAScOZg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:35:51.0890 (UTC) FILETIME=[47623320:01C55708] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > > Comment 41 in > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > says: (regarding -00 draft) > > "41. 5. character set consideration are contradictory: they say that > > character a-z exist in most character sets (good news) [what means that > > there are some where they do not exist] so there should not be > > character set presentation issue [in the character set where they do > > not exist?]. Also the consideration only concerns the "display" what > > has a limited interest if the a-z characters do not exist on the > > keyboard. But may be this supposes that "intelligent people" use ascii > > compatible keyboards (see below)." Since a reasonable application will not expose language tags to end users, and especially will not require them to type them in, and since IT professionals building applications who may need to type these in will almost certain have other reasons why they need to be able to type a-z, I think this is not a concern that needs to be addressed in this draft (no more than it being a concern e.g. for HTTP and countless other specifications). Therefore, I suggest that this item be closed. BTW, the *only* suggestion that "'intelligent people' use ascii compatible keyboards" has originated with the author of these comments. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:37:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFkw-0002XY-Gh; Thu, 12 May 2005 11:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFku-0002XQ-P4 for ltru@megatron.ietf.org; Thu, 12 May 2005 11:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04996 for ; Thu, 12 May 2005 11:37:42 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWG0e-0004rh-Cz for ltru@ietf.org; Thu, 12 May 2005 11:54:01 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 08:37:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homograph issues in securityconsiderations Date: Thu, 12 May 2005 08:37:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A6FFA@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #967] address homograph issues in securityconsiderations Thread-Index: AcVWvY0XAlmDtagASOGvrgSeFUse+QASp4vQ From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:37:34.0547 (UTC) FILETIME=[84926A30:01C55708] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Close to rejecting it? It's utterly confused. Langtags have nothing to = do with IDN (which uses xn-- for something special) and there are no = homographs in the ASCII range allowed for language tags (unless you = count L vs. 1 and o vs. 0). But these are restricted in use (nearly all = the defined tags use alpha codes) and would have no measurable security = impact. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?11? 23:43 > To: LTRU Working Group > Subject: [Ltru] [psg.com #967] address homograph issues in > securityconsiderations >=20 > Hi - >=20 > > Comment > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > reads: > > "39. 4. An important security consideration is homographs. It is > > certainly possible to include part of text in a foreign language = which > > look printed as in another language or having a different meaning or > > printing (phishing). Concerns are also the double "-" which is > > specifically used by the IANA code "xn"." > > > > language issue, rather than tagging, > > see http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html >=20 > I think we're close to rejecting this one. >=20 > Randy, ltru co-chair >=20 > Technical comment: > Perhaps this one might be accomodated by including an explicit = statement > about how the repertoire for creating language tags makes homographs a > non-issue (at least in a well-designed font) for the tags themselves. >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:38:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFlt-0002nn-Ay; Thu, 12 May 2005 11:38:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFlr-0002nf-GQ for ltru@megatron.ietf.org; Thu, 12 May 2005 11:38:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05023 for ; Thu, 12 May 2005 11:38:40 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWG1a-0004sK-QB for ltru@ietf.org; Thu, 12 May 2005 11:55:00 -0400 Received: from uknsprd1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 12 May 2005 15:37:50 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IGD00E6AVF2MB@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 12 May 2005 16:37:50 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Thu, 12 May 2005 16:37:36 +0100 Date: Thu, 12 May 2005 16:37:35 +0100 From: Misha Wolf Subject: RE: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations To: LTRU Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF7803C08597@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations thread-index: AcVWvZnzGF7BDY6qQmmh75mXEUbZfgASNPmwAAB0j2A= Content-Class: urn:content-classes:message X-OriginalArrivalTime: 12 May 2005 15:37:36.0574 (UTC) FILETIME=[85C7B5E0:01C55708] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > I believe the only homograph issue is between LATIN SMALL=20 > LETTER L and DIGIT ONE. What about the digit "0" and the letter "O" ? Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:40:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFnr-00030d-Ea; Thu, 12 May 2005 11:40:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFnp-00030V-Pk for ltru@megatron.ietf.org; Thu, 12 May 2005 11:40:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05211 for ; Thu, 12 May 2005 11:40:43 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWG3Y-0004vD-DT for ltru@ietf.org; Thu, 12 May 2005 11:57:02 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:40:34 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:40:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #964] section 3.4 of -00 is hard to understand Date: Thu, 12 May 2005 08:40:36 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #964] section 3.4 of -00 is hard to understand Thread-Index: AcVWvQa/rIPgqfAATHOASl4U1bV3yAASwXxAAAAYg4A= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:40:33.0890 (UTC) FILETIME=[EF77FC20:01C55708] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Yes. The new text reads... Suggested slight revision: Extension subtags are those introduced by single-letter subtags other than 'x-'. They are reserved for the generation of identifiers for data categories other than language, but which contain a language component and are compatible with applications that understand language tags. For example, they might be used to define locale identifiers, which are generally based on language. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:41:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFoN-00034z-QO; Thu, 12 May 2005 11:41:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFoL-00034r-TX for ltru@megatron.ietf.org; Thu, 12 May 2005 11:41:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05259 for ; Thu, 12 May 2005 11:41:15 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWG46-0004vm-IM for ltru@ietf.org; Thu, 12 May 2005 11:57:34 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:41:08 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:41:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations Date: Thu, 12 May 2005 08:41:10 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations Thread-Index: AcVWvZnzGF7BDY6qQmmh75mXEUbZfgASNPmwAAB0j2AAAC3lwA== From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:41:08.0344 (UTC) FILETIME=[04013F80:01C55709] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Misha Wolf > Peter Constable wrote: >=20 > > I believe the only homograph issue is between LATIN SMALL > > LETTER L and DIGIT ONE. >=20 > What about the digit "0" and the letter "O" ? Yes, of course. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:45:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFsT-0003s6-UV; Thu, 12 May 2005 11:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFsS-0003rs-SJ for ltru@megatron.ietf.org; Thu, 12 May 2005 11:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05553 for ; Thu, 12 May 2005 11:45:30 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWG8C-00051n-Ex for ltru@ietf.org; Thu, 12 May 2005 12:01:49 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4CFjJbd027566; Thu, 12 May 2005 08:45:19 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 May 2005 08:45:19 -0700 Message-ID: From: "McDonald, Ira" To: "'Misha Wolf'" , LTRU Working Group Subject: RE: [Ltru] [psg.com #967] address homograph issues insecuritycons iderations Date: Thu, 12 May 2005 08:45:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, And many sans serif fonts use an identical glyph for both LATIN CAPITAL LETTER I (eye) and LATIN SMALL LETTER L (ell). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Misha Wolf > Sent: Thursday, May 12, 2005 11:38 AM > To: LTRU Working Group > Subject: RE: [Ltru] [psg.com #967] address homograph issues > insecurityconsiderations > > > Peter Constable wrote: > > > I believe the only homograph issue is between LATIN SMALL > > LETTER L and DIGIT ONE. > > What about the digit "0" and the letter "O" ? > > Misha > > > > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com > > To find out more about Reuters Products and Services visit > http://www.reuters.com/productinfo > > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Reuters Ltd. > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 11:46:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFtE-0003ub-4v; Thu, 12 May 2005 11:46:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWFtC-0003uS-Ia for ltru@megatron.ietf.org; Thu, 12 May 2005 11:46:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05613 for ; Thu, 12 May 2005 11:46:16 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWG8x-00052o-72 for ltru@ietf.org; Thu, 12 May 2005 12:02:35 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:46:09 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 08:46:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations Date: Thu, 12 May 2005 08:46:11 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations Thread-Index: AcVWvY0XAlmDtagASOGvrgSeFUse+QASp4vQAABEuDA= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 15:46:08.0931 (UTC) FILETIME=[B72B2F30:01C55709] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Close to rejecting it? It's utterly confused. Langtags have nothing to do > with IDN (which uses xn-- for something special) and there are no > homographs in the ASCII range allowed for language tags (unless you count > L vs. 1 and o vs. 0). But these are restricted in use (nearly all the > defined tags use alpha codes) and would have no measurable security impact. Quite so. To compare with the security issues of IDN is more than a stretch. On the other hand, can we be certain that someone someday might not find a way to turn a confusion between e.g. 1996 and l996 in some future client protocol?=20 I'm not saying I'm convinced it's something we need to do. Just raising possibilities. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 12:09:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGFP-0007po-0W; Thu, 12 May 2005 12:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGFO-0007pd-Gn for ltru@megatron.ietf.org; Thu, 12 May 2005 12:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07230 for ; Thu, 12 May 2005 12:09:11 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWGV7-0005aL-2d for ltru@ietf.org; Thu, 12 May 2005 12:25:30 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 09:09:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #964] section 3.4 of -00 is hard to understand Date: Thu, 12 May 2005 09:09:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A7022@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #964] section 3.4 of -00 is hard to understand Thread-Index: AcVWvQa/rIPgqfAATHOASl4U1bV3yAASwXxAAAAYg4AAAPB/sA== From: "Addison Phillips" To: "Peter Constable" , "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 16:09:02.0015 (UTC) FILETIME=[E9972CF0:01C5570C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I don't like that revision for a simple reason: it excludes extensions = that do identify languages or aspects of languages. For example, an = extension might be used for transliteration schemes or for very = specialized kinds of categorization applied by linguists. The = requirement is that extensions be compatible with language tags and that = they be related in some meaningful, non-trivial way. But we shouldn't be = too specific IMO. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: 2005?5?12? 8:41 > To: LTRU Working Group > Subject: RE: [Ltru] [psg.com #964] section 3.4 of -00 is hard to > understand >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Addison Phillips >=20 > > Yes. The new text reads... >=20 > Suggested slight revision: >=20 > Extension subtags are those introduced by single-letter subtags = other > than 'x-'. They are reserved for the generation of identifiers for = data > categories other than language, but which contain a language component > and are compatible with applications that understand language tags. = For > example, they might be used to define locale identifiers, which are > generally based on language. >=20 >=20 > Peter Constable >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 12:15:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGLR-0001K6-KN; Thu, 12 May 2005 12:15:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGLQ-0001K1-M5 for ltru@megatron.ietf.org; Thu, 12 May 2005 12:15:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07939 for ; Thu, 12 May 2005 12:15:26 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWGbB-0005p2-IG for ltru@ietf.org; Thu, 12 May 2005 12:31:45 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 09:15:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations Date: Thu, 12 May 2005 09:15:18 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A7037@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations Thread-Index: AcVWvY0XAlmDtagASOGvrgSeFUse+QASp4vQAABEuDAAAPBHEA== From: "Addison Phillips" To: "Peter Constable" , "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 16:15:19.0345 (UTC) FILETIME=[CA7F2A10:01C5570D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Yes, but the security impact of such confusion is very small: you get a = match or not on some requested content. Or you get the wrong content. = But language tags are not addresses. Addresses present a security risk. = Asking for de-L996 is a security risk how? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: 2005?5?12? 8:46 > To: LTRU Working Group > Subject: RE: [Ltru] [psg.com #967] address homograph > issuesinsecurityconsiderations >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Addison Phillips >=20 >=20 > > Close to rejecting it? It's utterly confused. Langtags have nothing = to > do > > with IDN (which uses xn-- for something special) and there are no > > homographs in the ASCII range allowed for language tags (unless you > count > > L vs. 1 and o vs. 0). But these are restricted in use (nearly all = the > > defined tags use alpha codes) and would have no measurable security > impact. >=20 > Quite so. To compare with the security issues of IDN is more than a > stretch. >=20 > On the other hand, can we be certain that someone someday might not = find > a way to turn a confusion between e.g. 1996 and l996 in some future > client protocol? >=20 > I'm not saying I'm convinced it's something we need to do. Just = raising > possibilities. >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 12:28:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGY0-0004zZ-Ch; Thu, 12 May 2005 12:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGXy-0004zS-4m for ltru@megatron.ietf.org; Thu, 12 May 2005 12:28:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09047 for ; Thu, 12 May 2005 12:28:23 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWGnh-00069T-QX for ltru@ietf.org; Thu, 12 May 2005 12:44:43 -0400 Received: from h-64-105-136-17.snvacaid.dynamic.covad.net ([64.105.136.17] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DWGXu-0001SC-00 for ltru@ietf.org; Thu, 12 May 2005 09:28:22 -0700 Message-ID: <003001c5570f$f0d14660$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations Date: Thu, 12 May 2005 09:30:41 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Thursday, May 12, 2005 8:30 AM > Subject: RE: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations ... > Because the character repertoire permitted in our protocol elements is > limited to a-z, A-Z, 0-9 and "-" (with no two consecutive "-"s allowed), > I believe the only homograph issue is between LATIN SMALL LETTER L and > DIGIT ONE. ... as a contributor... That's why I wrote "well-designed font". If O/0 and I/l/1 (z/3 g/8, f/h/s, m/nn, u/v in extreme cases) are not visually distinct, then, in my opinion, it's not a well-designed font. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 14:24:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIMg-00083Y-Q0; Thu, 12 May 2005 14:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIMe-00083P-SS for ltru@megatron.ietf.org; Thu, 12 May 2005 14:24:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18653 for ; Thu, 12 May 2005 14:24:51 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWIcQ-0000Qf-0E for ltru@ietf.org; Thu, 12 May 2005 14:41:11 -0400 Received: from lns-p19-8-idf-82-65-72-126.adsl.proxad.net ([82.65.72.126] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DWIMX-0000H9-3x; Thu, 12 May 2005 11:24:45 -0700 Message-Id: <6.2.1.2.2.20050512200559.05f304f0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 20:24:38 +0200 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally supported In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 17:19 12/05/2005, Peter Constable wrote: >The ISO 3166 MA _has_ control over the content of _ISO 3166_. This RFC >would specify how language subtags for use on the Internet are >controlled. ISO does not have direct control over that, nor is it a >priori necessary that the RFC must be written in a way that gives them >implicit control. > >This much has been obvious for some time now, and it is not helping us >move toward completion to have to revisit such things. Can we please >bring an end to this? I fully understand that some may want to control ISO 3166 hoping that their involvement IANA will permit them to supersede the ISO 3166 MA and force him to obey their own ietf-languages@alvestrand.no decisions with Michael Everson's blessing. I have no objection to that as it will only make obvious to everyone the orientations of the affinity group leading this WG and what it wants to achieve. My only concern is that will block the XML fix now very long awaited by Addison. ISO 3166 is controlled by the ISO 3166 MA. Period. Full stop. Un point c'est tout. 1. the world will only laught at a system having its own ISO 3166 table 2. the charter explicitly asks us to avoid that changes in ISO 3166 create a confusion. Not to organise that confusion. I really do enjoy this WG! jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 14:38:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIZb-0001jH-Ht; Thu, 12 May 2005 14:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIZY-0001jC-7O for ltru@megatron.ietf.org; Thu, 12 May 2005 14:38:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19640 for ; Thu, 12 May 2005 14:38:10 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWIpJ-0000iN-7h for ltru@ietf.org; Thu, 12 May 2005 14:54:30 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4CIbpmq020305; Thu, 12 May 2005 11:37:54 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 May 2005 11:37:52 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Peter Constable , LTRU Working Group Subject: RE: [Ltru] [psg.com #967] address homograph issuesinsecurityconsi derations Date: Thu, 12 May 2005 11:37:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, Denial of Service (DoS) through masking of content by homograph language tags (e.g., in an LDAP directory of users) is a security risk that's supposed to be addressed in a 'Security Considerations' section (see section 2.3.3 and 4.6 of RFC 3552 "Guidelines for Writing RFC Text on Security Considerations"). And saying that end users don't enter or view language tags is not sufficient. Content authors, content distributors, administrators and others generally _do_ have to enter or view language tags. Since the roles of individuals who enter or view language tags were not defined in RFC 3066 (or in this latest replacement draft), the risks that may be associated with using language tags are ambiguous. Although I was shouted down, I still dislike the use of RFC 2119 requirements capitalized verbs in imperative statements with only implicit subjects, e.g., "you the reader", whatever that means... If I get some time soon, I'll write up some suggested text describing the roles of language tag users and recasting some of the conformance requirements (e.g., around the Suppress-Script field) in those terms. Then I can be ignored again, but it will be recorded in the archives of this mailing list. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Thursday, May 12, 2005 12:15 PM > To: Peter Constable; LTRU Working Group > Subject: RE: [Ltru] [psg.com #967] address homograph > issuesinsecurityconsiderations > > > Yes, but the security impact of such confusion is very small: > you get a match or not on some requested content. Or you get > the wrong content. But language tags are not addresses. > Addresses present a security risk. Asking for de-L996 is a > security risk how? > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Peter Constable > > Sent: 2005?5?12? 8:46 > > To: LTRU Working Group > > Subject: RE: [Ltru] [psg.com #967] address homograph > > issuesinsecurityconsiderations > > > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > > On > > > Behalf Of Addison Phillips > > > > > > > Close to rejecting it? It's utterly confused. Langtags > have nothing to > > do > > > with IDN (which uses xn-- for something special) and there are no > > > homographs in the ASCII range allowed for language tags > (unless you > > count > > > L vs. 1 and o vs. 0). But these are restricted in use > (nearly all the > > > defined tags use alpha codes) and would have no > measurable security > > impact. > > > > Quite so. To compare with the security issues of IDN is more than a > > stretch. > > > > On the other hand, can we be certain that someone someday > might not find > > a way to turn a confusion between e.g. 1996 and l996 in some future > > client protocol? > > > > I'm not saying I'm convinced it's something we need to do. > Just raising > > possibilities. > > > > > > > > Peter Constable > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 14:43:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIeO-0002Mg-Kq; Thu, 12 May 2005 14:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIeM-0002MZ-QX for ltru@megatron.ietf.org; Thu, 12 May 2005 14:43:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20024 for ; Thu, 12 May 2005 14:43:09 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWIu7-0000ot-I6 for ltru@ietf.org; Thu, 12 May 2005 14:59:29 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 11:42:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations Date: Thu, 12 May 2005 11:42:52 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A712C@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations Thread-Index: AcVXIcErzkdODGLOT+OBunOhb7btPQAADAQg From: "Addison Phillips" To: "McDonald, Ira" , "Peter Constable" , "LTRU Working Group" X-OriginalArrivalTime: 12 May 2005 18:42:53.0215 (UTC) FILETIME=[67D082F0:01C55722] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Text would be *most* helpful. I don't believe you were ignored previously. Quite the contrary, I'm = interested in seeing closure, which means consensus, which means not = ignoring comments.=20 Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: 2005?5?12? 11:38 > To: Addison Phillips; Peter Constable; LTRU Working Group > Subject: RE: [Ltru] [psg.com #967] address homograph > issuesinsecurityconsiderations >=20 > Hi, >=20 > Denial of Service (DoS) through masking of content by homograph = language > tags > (e.g., in an LDAP directory of users) is a security risk that's = supposed > to > be addressed in a 'Security Considerations' section (see section 2.3.3 = and > 4.6 > of RFC 3552 "Guidelines for Writing RFC Text on Security = Considerations"). >=20 > And saying that end users don't enter or view language tags is not > sufficient. > Content authors, content distributors, administrators and others = generally > _do_ have to enter or view language tags. >=20 > Since the roles of individuals who enter or view language tags were = not > defined in RFC 3066 (or in this latest replacement draft), the risks = that > may be associated with using language tags are ambiguous. >=20 > Although I was shouted down, I still dislike the use of RFC 2119 > requirements > capitalized verbs in imperative statements with only implicit = subjects, > e.g., > "you the reader", whatever that means... >=20 > If I get some time soon, I'll write up some suggested text describing = the > roles of language tag users and recasting some of the conformance > requirements > (e.g., around the Suppress-Script field) in those terms. Then I can = be > ignored again, but it will be recorded in the archives of this mailing > list. >=20 > Cheers, > - Ira >=20 > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Addison Phillips > > Sent: Thursday, May 12, 2005 12:15 PM > > To: Peter Constable; LTRU Working Group > > Subject: RE: [Ltru] [psg.com #967] address homograph > > issuesinsecurityconsiderations > > > > > > Yes, but the security impact of such confusion is very small: > > you get a match or not on some requested content. Or you get > > the wrong content. But language tags are not addresses. > > Addresses present a security risk. Asking for de-L996 is a > > security risk how? > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] On > > > Behalf Of Peter Constable > > > Sent: 2005?5?12? 8:46 > > > To: LTRU Working Group > > > Subject: RE: [Ltru] [psg.com #967] address homograph > > > issuesinsecurityconsiderations > > > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > Behalf Of Addison Phillips > > > > > > > > > > Close to rejecting it? It's utterly confused. Langtags > > have nothing to > > > do > > > > with IDN (which uses xn-- for something special) and there are = no > > > > homographs in the ASCII range allowed for language tags > > (unless you > > > count > > > > L vs. 1 and o vs. 0). But these are restricted in use > > (nearly all the > > > > defined tags use alpha codes) and would have no > > measurable security > > > impact. > > > > > > Quite so. To compare with the security issues of IDN is more than = a > > > stretch. > > > > > > On the other hand, can we be certain that someone someday > > might not find > > > a way to turn a confusion between e.g. 1996 and l996 in some = future > > > client protocol? > > > > > > I'm not saying I'm convinced it's something we need to do. > > Just raising > > > possibilities. > > > > > > > > > > > > Peter Constable > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 15:08:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJ2w-0007BU-5V; Thu, 12 May 2005 15:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJ2u-0007BL-FF for ltru@megatron.ietf.org; Thu, 12 May 2005 15:08:32 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22568 for ; Thu, 12 May 2005 15:08:30 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DWItz-0008Ox-7c for ltru@lists.ietf.org; Thu, 12 May 2005 20:59:19 +0200 Received: from du-001-130.access.de.clara.net ([212.82.227.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 20:59:19 +0200 Received: from nobody by du-001-130.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 20:59:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 12 May 2005 21:05:33 +0200 Organization: Lines: 17 Message-ID: <4283A8FD.71CB@xyzzy.claranet.de> References: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com> <00dd01c556b6$1b7c6160$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-130.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Can someone map these comments into proposals? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > at least it's documented that we tried to figure out what was > being requested. I tried to get the drift of (6) and came to the conclusion that it's in fact often useful and sometimes even required to know the language => no problem in the introduction. Examples like http and HTML are known, it's unnecesary to list them, let alone in the introduction. Something new I've seen starting recently: Accept-Language used as mail or news header field, a cute idea for e.g. English lists or news groups, if an author accepts or prefers private replies in other languages. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 15:27:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJLi-0002dL-Rh; Thu, 12 May 2005 15:27:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJLg-0002dF-M2 for ltru@megatron.ietf.org; Thu, 12 May 2005 15:27:56 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25303 for ; Thu, 12 May 2005 15:27:54 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DWJDZ-0003Xg-8f for ltru@lists.ietf.org; Thu, 12 May 2005 21:19:33 +0200 Received: from du-001-130.access.de.clara.net ([212.82.227.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 21:19:33 +0200 Received: from nobody by du-001-130.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 21:19:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 12 May 2005 21:25:54 +0200 Organization: Lines: 12 Message-ID: <4283ADC2.4D1B@xyzzy.claranet.de> References: <014a01c556be$275e65c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-130.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #970] add reference to xml schema version 1.0 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> "42. 6. compatibility is preserved with RFC 3066 but not >> with evolution of ISO code elements. The XML Schema version >> 1.0 requirements are quoted but not documented." That appears to be related to the "forever canonical" debate, Informative reference [19] is a pointer to the Schema spec., which has a pointer to RfC 3066. W3C URLs are famous to be stable => no problem, mark as closed or non-issue. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 15:50:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJh4-0006jQ-Qz; Thu, 12 May 2005 15:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJh2-0006ix-Je for ltru@megatron.ietf.org; Thu, 12 May 2005 15:50:00 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27417 for ; Thu, 12 May 2005 15:49:57 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DWJYU-0007dF-Km for ltru@lists.ietf.org; Thu, 12 May 2005 21:41:10 +0200 Received: from du-001-130.access.de.clara.net ([212.82.227.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 21:41:10 +0200 Received: from nobody by du-001-130.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 21:41:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 12 May 2005 21:47:33 +0200 Organization: Lines: 13 Message-ID: <4283B2D5.6551@xyzzy.claranet.de> References: <014501c556be$0fc3eac0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-130.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #969]character set considerations material is contradictory X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> Comment 41 >> character a-z exist in most character sets (good news) >> [what means that there are some where they do not exist] What's the idea of posting this comment ? Add a pointer to RfC 1345 explaining ISO 646 maybe ? Renaming chapter 7 to "I18N considerations" ? Mention that keyboard layouts with less than two keys won't allow straight forward UIs ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 16:04:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJvG-0000mu-8S; Thu, 12 May 2005 16:04:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJvF-0000me-28 for ltru@megatron.ietf.org; Thu, 12 May 2005 16:04:41 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00819 for ; Thu, 12 May 2005 16:04:38 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DWJmU-0001yg-Hb for ltru@lists.ietf.org; Thu, 12 May 2005 21:55:38 +0200 Received: from du-001-130.access.de.clara.net ([212.82.227.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 21:55:38 +0200 Received: from nobody by du-001-130.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 May 2005 21:55:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 12 May 2005 22:01:56 +0200 Organization: Lines: 10 Message-ID: <4283B634.529@xyzzy.claranet.de> References: <1987416CA83AC7499AC772F92E2DBF7803C08597@LONSMSXM02.emea.ime.reuters.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-130.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #967] address homograph issues insecurityconsiderations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Misha Wolf wrote: >> LATIN SMALL LETTER L and DIGIT ONE. > What about the digit "0" and the letter "O" ? Only possible in variants. In theory we could avoid even this possiility, but then we'd lose e.g. scouse21 for 21st century scouse. If later somebody tries to register sc0use2L to cause havoc the tag reviewer would reject it => no issue. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 23:44:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWR6E-0005TN-Hd; Thu, 12 May 2005 23:44:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWR6D-0005TI-31 for ltru@megatron.ietf.org; Thu, 12 May 2005 23:44:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11907 for ; Thu, 12 May 2005 23:44:26 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWRM2-0002Ix-ON for ltru@ietf.org; Fri, 13 May 2005 00:00:52 -0400 Received: from h-68-164-241-117.snvacaid.dynamic.covad.net ([68.164.241.117] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DWR69-0005Wo-00 for ltru@ietf.org; Thu, 12 May 2005 20:44:25 -0700 Message-ID: <011401c5576e$641a6e40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 12 May 2005 20:46:48 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Ltru] ltru issues 972-981 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've entered another batch of issues. All of these have already either been resolved by the changes in the -01 draft, or rejected. You can view the details at https://rt.psg.com/ with username "ietf" and password "ietf". If you believe further discussion of any of these is necessary, or if I've made a mistake, *please* use the appropriate subject line: [psg.com #972] compatibility with evolution of ISO code elements resolved [psg.com #973] remove material that should be in matching draft resolved [psg.com #974] define IQ rejected [psg.com #975] define "extlang" resolved [psg.com #976] draft does not allude to applications not mentioned in charter rejected [psg.com #977] addressing 3066 problems in -00 draft rejected [psg.com #978] how powerful is reviewer? rejected [psg.com #979] stability of tags when underlying references change resolved [psg.com #980] determine whether tag valid at particular time resolved [psg.com #981] explain "generative private use" rejected Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 23:58:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWRJz-0007cp-7p; Thu, 12 May 2005 23:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWRJx-0007cj-OU for ltru@megatron.ietf.org; Thu, 12 May 2005 23:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12590 for ; Thu, 12 May 2005 23:58:39 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWRZo-0002vY-QZ for ltru@ietf.org; Fri, 13 May 2005 00:15:05 -0400 Received: from lns-p19-8-idf-82-65-72-126.adsl.proxad.net ([82.65.72.126] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DWRJq-0008Mu-O3; Thu, 12 May 2005 20:58:36 -0700 Message-Id: <6.2.1.2.2.20050513004551.060318b0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 13 May 2005 05:58:19 +0200 To: "Peter Constable" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [Ltru] sad and afflicting (was [psg.com #969]character set considerations material is contradictory) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter, I am sad for you for your afflicting comments. At 17:35 12/05/2005, Peter Constable wrote: >Since a reasonable application will not expose language tags to end >users I explained several times how inapropriate is the term "end user" in an end to end distributed architecture. In the context of your remarks it shows you categorise the users of IETF deliverables, and discriminate their access to a common information on the base of their language. I do not want to use big words, but this is a patent violation of Human Rights. As is the whole langtag concept for that reason. That a Microsoft expert deliberately ignores the non-ascii development environments (of his clients) to justify a document, is afflicting. >BTW, the *only* suggestion that "'intelligent people' use ascii >compatible keyboards" has originated with the author of these comments. The terms "intelligent people" is a terminology of the draft 11.txt (00.txt). I ask if the authors' wording implies their intelligent people (whatever they may mean by that) use ascii compatible keyboards? Please does not reverse the suggestion: in my country it qualifies as a criminal offense. I suppose it is the case in the other countries applying the UN Declaration on Human Rights. It is advisable that IETF documents start correcting their lingual discrimination. You may not know that, I was a GNSO candidate at the ICANN BoD in 9/2001 to campaign against the lingual divide. It lead to a ccTLD resolution at the Montevideo meeting. FYI it was also to campaign against the concentration of root servers in the USA. When I made my public speach on 9/8, I was laughed at and teased, the same I am here. For the same reason: experts hates being said the obvious because they should have seen it - beati pauperes spiritu. 3 days later on, one root server disapeared in the WTC. The WSIS picked that point in its resolutions. Today there are more than 70 servers around the world - beati pauperes partly won [the file is still the NTIA file on the RSSAC ones but on a few others it is already my approach ...]). Humility and open mind leads to obvious, obvious wins at the end of the day. It is a very simple, sometimes slow when you have many experts, but a secure rule. You can trust it. I fully realise that this WG is unwillingly a RFC 3774 show case, so I do not want it continue to delay the fix W3C so dearly waits for. I will not fight its possibly innapropriately hurting wording now: this is an issue with the RFC Editor who feels concerned and will increasingly feel concerned with the comming WSIS resolutions on the issue. And I do not seen any document published before a long, to take into account Warsaw results, etc.. But, I thank you not to add to it. I am sorry: WG management and aggresiveness against me, logic contradictions, etc. will not make me to call on ADs or IESG or upset me. But this kind of discriminatory words, might. Please, let have Addison close his Draft, lose the IESG or IETF Last Call, ISO 639-4 finalised, this WG review its Charter, build a road-map, produce a Framework also respecting the ISO underscore format and the XML separated "script, region indications" format and many others, let dig into a few concepts about language as human computer sharable relation protocols, fix the conflict with charsets declarations, get the text copied around and endorsed by concerned communities and made an RFC, may be give me time enough to mess it with CRC Canonical Interface Grids, so we can eventually have the XML support of BCP 47 documented as an RFC before XML is replaced by ASN.2. This is up to you. I will wait. But stop discriminating. Thank you! jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 12 23:58:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWRK1-0007ds-FH; Thu, 12 May 2005 23:58:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWRJy-0007co-J6 for ltru@megatron.ietf.org; Thu, 12 May 2005 23:58:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12593 for ; Thu, 12 May 2005 23:58:39 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWRZo-0002vP-QV for ltru@ietf.org; Fri, 13 May 2005 00:15:06 -0400 Received: from lns-p19-8-idf-82-65-72-126.adsl.proxad.net ([82.65.72.126] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DWRJm-0008Mu-GV; Thu, 12 May 2005 20:58:32 -0700 Message-Id: <6.2.1.2.2.20050513002751.04958180@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 13 May 2005 00:29:05 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] [psg.com #964] section 3.4 of -00 is hard to understand In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B5A6FF3@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B5A6FF3@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.8 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 17:34 12/05/2005, Addison Phillips said: >Yes. The new text reads: > >Extension subtags are those introduced by single-letter subtags other >than 'x-'. They are reserved for the generation of identifiers which >contain a language component, and are compatible with applications >understand language tags. For example, they might be used to define locale >identifiers, which are generally based on language. My Franglish is uncertain on this, but should it not something like "application that understand language tags"? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 13 01:48:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWT29-0000gB-UR; Fri, 13 May 2005 01:48:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWT28-0000ea-F1 for ltru@megatron.ietf.org; Fri, 13 May 2005 01:48:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19309 for ; Fri, 13 May 2005 01:48:22 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWTHz-0006tw-PD for ltru@ietf.org; Fri, 13 May 2005 02:04:48 -0400 Received: from h-68-164-241-117.snvacaid.dynamic.covad.net ([68.164.241.117] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DWT24-0007H0-00; Thu, 12 May 2005 22:48:20 -0700 Message-ID: <003401c5577f$b36793e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 12 May 2005 22:50:42 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Subject: [Ltru] Suspension of Jefsey until 2005-05-22 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I am sad to report that, pursuant to the provisions of RFC 3934, I have suspended the ltru WG mailing list posting privileges of JFC (Jefsey) Morfin . He will continue to receive postings from the working group mailing list as long as he remains subscribed. Jefsey has been warned, both privately and on list, about his behavior. A copy of the most recent disruptive post is included below. The suspension shall be for a period of ten days, unless overruled. I intend to restore his posting privileges the evening of May 22, 2005. The appeal process is described in RFC 2026; the responsible Area Director is Scott Hollenbeck. Randy, ltru co-chair -------------------------------------------------------------------------------------------------------------------- Return-Path: Received: from megatron.ietf.org ([132.151.6.71]) by pickering.mail.mindspring.net (EarthLink SMTP Server) with ESMTP id 1dwrmRwJ3Nl3p20 for ; Fri, 13 May 2005 00:01:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWRJz-0007cp-Ai; Thu, 12 May 2005 23:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWRJx-0007cj-OU for ltru@megatron.ietf.org; Thu, 12 May 2005 23:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12590 for ; Thu, 12 May 2005 23:58:39 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWRZo-0002vY-QZ for ltru@ietf.org; Fri, 13 May 2005 00:15:05 -0400 Received: from lns-p19-8-idf-82-65-72-126.adsl.proxad.net ([82.65.72.126] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DWRJq-0008Mu-O3; Thu, 12 May 2005 20:58:36 -0700 Message-Id: <6.2.1.2.2.20050513004551.060318b0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 13 May 2005 05:58:19 +0200 To: "Peter Constable" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [Ltru] sad and afflicting (was [psg.com #969]character set considerations material is contradictory) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org X-ELNK-AV: 0 Peter, I am sad for you for your afflicting comments. At 17:35 12/05/2005, Peter Constable wrote: >Since a reasonable application will not expose language tags to end >users I explained several times how inapropriate is the term "end user" in an end to end distributed architecture. In the context of your remarks it shows you categorise the users of IETF deliverables, and discriminate their access to a common information on the base of their language. I do not want to use big words, but this is a patent violation of Human Rights. As is the whole langtag concept for that reason. That a Microsoft expert deliberately ignores the non-ascii development environments (of his clients) to justify a document, is afflicting. >BTW, the *only* suggestion that "'intelligent people' use ascii >compatible keyboards" has originated with the author of these comments. The terms "intelligent people" is a terminology of the draft 11.txt (00.txt). I ask if the authors' wording implies their intelligent people (whatever they may mean by that) use ascii compatible keyboards? Please does not reverse the suggestion: in my country it qualifies as a criminal offense. I suppose it is the case in the other countries applying the UN Declaration on Human Rights. It is advisable that IETF documents start correcting their lingual discrimination. You may not know that, I was a GNSO candidate at the ICANN BoD in 9/2001 to campaign against the lingual divide. It lead to a ccTLD resolution at the Montevideo meeting. FYI it was also to campaign against the concentration of root servers in the USA. When I made my public speach on 9/8, I was laughed at and teased, the same I am here. For the same reason: experts hates being said the obvious because they should have seen it - beati pauperes spiritu. 3 days later on, one root server disapeared in the WTC. The WSIS picked that point in its resolutions. Today there are more than 70 servers around the world - beati pauperes partly won [the file is still the NTIA file on the RSSAC ones but on a few others it is already my approach ...]). Humility and open mind leads to obvious, obvious wins at the end of the day. It is a very simple, sometimes slow when you have many experts, but a secure rule. You can trust it. I fully realise that this WG is unwillingly a RFC 3774 show case, so I do not want it continue to delay the fix W3C so dearly waits for. I will not fight its possibly innapropriately hurting wording now: this is an issue with the RFC Editor who feels concerned and will increasingly feel concerned with the comming WSIS resolutions on the issue. And I do not seen any document published before a long, to take into account Warsaw results, etc.. But, I thank you not to add to it. I am sorry: WG management and aggresiveness against me, logic contradictions, etc. will not make me to call on ADs or IESG or upset me. But this kind of discriminatory words, might. Please, let have Addison close his Draft, lose the IESG or IETF Last Call, ISO 639-4 finalised, this WG review its Charter, build a road-map, produce a Framework also respecting the ISO underscore format and the XML separated "script, region indications" format and many others, let dig into a few concepts about language as human computer sharable relation protocols, fix the conflict with charsets declarations, get the text copied around and endorsed by concerned communities and made an RFC, may be give me time enough to mess it with CRC Canonical Interface Grids, so we can eventually have the XML support of BCP 47 documented as an RFC before XML is replaced by ASN.2. This is up to you. I will wait. But stop discriminating. Thank you! jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 13 09:02:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZo1-0006kn-TZ; Fri, 13 May 2005 09:02:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZo1-0006ki-An for ltru@megatron.ietf.org; Fri, 13 May 2005 09:02:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11946 for ; Fri, 13 May 2005 09:02:15 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWa3w-0006FA-0K for ltru@ietf.org; Fri, 13 May 2005 09:18:45 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 06:02:06 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 06:02:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2005 06:01:55 -0700 Message-ID: Thread-Topic: sad and afflicting (was [psg.com #969]character set considerations material is contradictory) Thread-Index: AcVXcAdKfBDnL3mtRNe7Zc/eCJoY3wASimZg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 13 May 2005 13:02:05.0415 (UTC) FILETIME=[F6639770:01C557BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Ltru] RE: sad and afflicting (was [psg.com #969]character set considerations material is contradictory) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > I am sad for you for your afflicting comments. >=20 > At 17:35 12/05/2005, Peter Constable wrote: > >Since a reasonable application will not expose language tags to end > >users >=20 > I explained several times how inapropriate is the term "end user" in an > end to end distributed architecture. Jefsey, your sadness is your own problem. Ask any native-English speaker in the IT industry what kind of person "end user" means, and they will not include software developers and IT professionals. Your rants are wasting time; you may do what you please, but I will not waste my time on them further.=20 Bernard Shaw said of Wagner that he has his fine moments and his long quarter hours. You have made some useful contributions here, but have injected far more useless obfuscatioins and red herrings. You would do well to limit yourself to issues that are likely to be productive. > In the context of your remarks it shows > you categorise the users of IETF deliverables, and discriminate their > access to a common information on the base of their language. I do not > want to use big words, but this is a patent violation of Human Rights. Why don't you go solve the problem that Linux API function calls are not localized. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 13 13:14:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdkQ-0001gk-LT; Fri, 13 May 2005 13:14:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdkP-0001gX-3O for ltru@megatron.ietf.org; Fri, 13 May 2005 13:14:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06423 for ; Fri, 13 May 2005 13:14:45 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWe0L-0008Jk-NQ for ltru@ietf.org; Fri, 13 May 2005 13:31:19 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 10:14:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 May 2005 10:14:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B5A7609@irvmbxw01.quest.com> Thread-Topic: New version of matching draft... Thread-Index: AcVX3zuJFHTaR/G+R4iF2JIBGsOhAA== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 13 May 2005 17:14:33.0433 (UTC) FILETIME=[3B4FB490:01C557DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] New version of matching draft... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0612291078==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0612291078== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QWxsLA0KDQpJIGhhdmUgcHJlcGFyZWQgYW4gZXh0ZW5zaXZlIHJldmlzaW9uIG9mIHRoZSBtYXRj aGluZyBkcmFmdCBhbmQgcG9zdGVkIGl0IG9uIG15IHBlcnNvbmFsIHdlYnNpdGUuIEknbGwgYWxs b3cgYSBjb3VwbGUgb2YgZGF5cyB3b3J0aCBvZiBjb21tZW50YXJ5IGJlZm9yZSBzZW5kaW5nIGl0 IGluIGFzIHRoZSBvZmZpY2lhbCBmaXJzdCBkcmFmdC4gRG9uJ3QgaG9sZCBiYWNrOiBJIGhhdmUg dG8gY2hhbmdlIHRoZSBkYXRlIG9uIHRoZSBkcmFmdCBhbnl3YXkuDQoNCkkgcmFkaWNhbGx5IGFs dGVyZWQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgZG9jdW1lbnQuIFVzaW5nIHRlcm1pbm9sb2d5IHN1 Z2dlc3RlZCBvbiB0aGlzIGxpc3QsIHRoZSBkb2N1bWVudCBub3cgcHJlc2VudHMgZml2ZSBtYXRj aGluZyBzY2hlbWVzOg0KDQotIGJhc2ljIG1hdGNoaW5nDQotIGJhc2ljIGxvb2t1cA0KLSBleHRl bmRlZCByYW5nZSBtYXRjaGluZw0KLSBleHRlbmRlZCByYW5nZSBsb29rdXANCi0gc2NvcmVkIG1h dGNoaW5nDQoNClRoZSB3ZWFrZXN0IHNlY3Rpb25zIGluIHRlcm1zIG9mIHRleHQgYXJlIHRoZSBv bmUgb24gc2NvcmVkIG1hdGNoaW5nIChJIGRpZCBhIHF1aWNrIGVkaXQgb24gSm9obiBDb3dhbidz IG9yaWdpbmFsIGVtYWlsIHZlcnNpb24gYW5kIG5vdCBtdWNoIG1vcmUpIGFuZCB0aGUgc2VjdGlv biBvbiBjaG9vc2luZyAoc2VjdGlvbiAyLjQ6IGl0IGNvbnRhaW5zIG1vc3RseSBzb21lIG9sZCBs ZWZ0b3ZlciB0ZXh0KS4NCg0KUmFuZHkvTWFydGluOiBNYXJrIGFuZCBJIGhhdmUgYWdyZWVkIHRv IHZvbHVudGVlciB0byByZW1haW4gYXMgZWRpdG9ycyBvZiB0aGlzIGRvY3VtZW50IGZvciB0aGUg Zm9yZXNlZWFibGUgZnV0dXJlLg0KDQpUaGUgZG9jdW1lbnQgaXMgbG9jYXRlZCBhdDoNCg0KICBo dHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LW1hdGNoaW5nLTAw Lmh0bWwNCiAgaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1t YXRjaGluZy0wMC50eHQNCiAgaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWll dGYtbHRydS1tYXRjaGluZy0wMC54bWwNCg0KQmVzdCBSZWdhcmRzLA0KDQpBZGRpc29uDQoNCkFk ZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2Fy ZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlv biBDb3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0K SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVj dHVyZS4gDQoNCg0K --===============0612291078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0612291078==-- From ltru-bounces@lists.ietf.org Fri May 13 16:33:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgqc-0004Ll-Q2; Fri, 13 May 2005 16:33:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgqb-0004Lg-Ms for ltru@megatron.ietf.org; Fri, 13 May 2005 16:33:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05893 for ; Fri, 13 May 2005 16:33:23 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWh6X-0003RW-EX for ltru@ietf.org; Fri, 13 May 2005 16:49:54 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DWgqU-0007Am-00 for ltru@ietf.org; Fri, 13 May 2005 13:33:19 -0700 Message-ID: <001c01c557fb$54e92320$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B5A7609@irvmbxw01.quest.com> Subject: Re: [Ltru] New version of matching draft... Date: Fri, 13 May 2005 13:35:41 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "LTRU Working Group" > Sent: Friday, May 13, 2005 10:14 AM > Subject: [Ltru] New version of matching draft... ... > I have prepared an extensive revision of the matching draft and posted it on my personal website. > I'll allow a couple of days worth of commentary before sending it in as the official first draft. > Don't hold back: I have to change the date on the draft anyway. ... Please submit it to internet-drafts@ietf.org at your earliest convenience. If we need to post a -01 revision a couple of days later, fine. Integers are cheap. :-) I strongly prefer that WG discussion be in terms of posted internet-drafts, rather than material on editors' web sites, though there are times when that is a helpful additional vehicle. If you like, feel free to insert a "health warning" in the draft indicating the preliminary nature of this particular version, perhaps including some of the same remarks as were in your message. The announcement that goes out with the posting of an i-d will reach a much larger audience than this working group list, and I'd like to ensure that new participants brought in by the announcement will be on the same footing with respect to this draft as the rest of the WG. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 13 16:38:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgvc-00052r-NX; Fri, 13 May 2005 16:38:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgvb-00052m-Ug for ltru@megatron.ietf.org; Fri, 13 May 2005 16:38:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06653 for ; Fri, 13 May 2005 16:38:31 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWhBY-0003gm-OC for ltru@ietf.org; Fri, 13 May 2005 16:55:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 13:38:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] New version of matching draft... Date: Fri, 13 May 2005 13:38:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B65D927@irvmbxw01.quest.com> Thread-Topic: [Ltru] New version of matching draft... Thread-Index: AcVX+yPyBc2ofyJDRO6rayuq+TMXBgAAFlUA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 13 May 2005 20:38:18.0730 (UTC) FILETIME=[B227FCA0:01C557FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Very well. I'll send it out later today after I correct the date, run = the spell-checker, and a few other niceties. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?13? 13:36 > To: LTRU Working Group > Subject: Re: [Ltru] New version of matching draft... >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "LTRU Working Group" > > Sent: Friday, May 13, 2005 10:14 AM > > Subject: [Ltru] New version of matching draft... > ... > > I have prepared an extensive revision of the matching draft and = posted > it on my personal website. > > I'll allow a couple of days worth of commentary before sending it in = as > the official first draft. > > Don't hold back: I have to change the date on the draft anyway. > ... >=20 > Please submit it to internet-drafts@ietf.org at your earliest = convenience. > If we need to post a -01 revision a couple of days later, fine. = Integers > are cheap. :-) >=20 > I strongly prefer that WG discussion be in terms of posted = internet-drafts, > rather > than material on editors' web sites, though there are times when that = is a > helpful > additional vehicle. If you like, feel free to insert a "health = warning" > in the draft > indicating the preliminary nature of this particular version, perhaps > including > some of the same remarks as were in your message. >=20 > The announcement that goes out with the posting of an i-d will reach a > much larger > audience than this working group list, and I'd like to ensure that new > participants > brought in by the announcement will be on the same footing with = respect to > this > draft as the rest of the WG. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 15 00:56:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXBBJ-0000et-15; Sun, 15 May 2005 00:56:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXBBE-0000eD-Gb for ltru@megatron.ietf.org; Sun, 15 May 2005 00:56:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08944 for ; Sun, 15 May 2005 00:56:40 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXBRU-00038R-EK for ltru@ietf.org; Sun, 15 May 2005 01:13:33 -0400 Received: from h-64-105-137-59.snvacaid.dynamic.covad.net ([64.105.137.59] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DXBBB-0007co-00 for ltru@ietf.org; Sat, 14 May 2005 21:56:41 -0700 Message-ID: <003301c5590a$d4bf9ec0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B65D927@irvmbxw01.quest.com> Subject: Re: [Ltru] New version of matching draft... Date: Sat, 14 May 2005 21:59:09 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Friday, May 13, 2005 1:38 PM > Subject: RE: [Ltru] New version of matching draft... > > Very well. I'll send it out later today after I correct the date, run the spell-checker, and a few other niceties. ... Thanks! Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 16 00:16:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXX23-0001MS-I8; Mon, 16 May 2005 00:16:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXX22-0001LS-C9 for ltru@megatron.ietf.org; Mon, 16 May 2005 00:16:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27714 for ; Mon, 16 May 2005 00:16:38 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DXX16-0008Br-NN for ltru@lists.ietf.org; Mon, 16 May 2005 06:15:44 +0200 Received: from 212.82.251.79 ([212.82.251.79]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 May 2005 06:15:44 +0200 Received: from nobody by 212.82.251.79 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 May 2005 06:15:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 16 May 2005 06:11:43 +0200 Organization: Lines: 35 Message-ID: <42881D7F.1222@xyzzy.claranet.de> References: <4274D58C.542D@xyzzy.claranet.de> <4275CDDE.F20@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.79 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Open points before -02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > 1 - check and fill gaps in Suppress-Scripts That was "rejected", the actual idea is to publish the registry draft first (closing the old registry), and to finish the business with the draft registry later. > 2 - check SHOULD, MUST, and rationale for Suppress-Scripts Addison proposed a rationale to be added in -02. Maybe Ira and Randy still want to replace two corresponding SHOULD NOT by some "MUST NOT unless". > 3 - improve registry ABNF, simplify the corresponding chapter That was rejected, Addison wants to document the record-jar format, not its registry incarnation. That's backwards from my POV, mail (2822) and news (1036) use prose for the simple general format, and syntax for the header field details, but there's no rule to do it this way also in 3066bis. > 4 - redefine canonical / deprecated to follow the underlying > ISO and UN standards (stable forever != canonical forever) Already discussed elsewhere. The last idea was to replace the "normative Canonical: xx" by an "informative Use: xx". > 5 - move redundant tags from draft registry to an appendix Alread discussed elsewhere. It's possible to arrange things this way, the registry would be shorter, implementations would be simpler, but after all that's mainly a matter of taste. And it's already clear that I didn't like two MO-nsense entries. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 16 12:53:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXiqa-0003Q2-Cx; Mon, 16 May 2005 12:53:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXiqY-0003Pw-N1 for ltru@megatron.ietf.org; Mon, 16 May 2005 12:53:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10031 for ; Mon, 16 May 2005 12:53:33 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXj73-0003EW-7w for ltru@ietf.org; Mon, 16 May 2005 13:10:44 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 09:53:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Open points before -02 Date: Mon, 16 May 2005 09:53:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B65DD7B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Open points before -02 Thread-Index: AcVZziggq3VESVYrT6Cs6tAQToVMQQAaRxnw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 16 May 2005 16:53:18.0749 (UTC) FILETIME=[C2C79CD0:01C55A37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Your summary matches mine. A new editor's copy is posted. When I finish the matching draft = submission, maybe I'll consume another integer and submit this one as = well. > > 3 - improve registry ABNF, simplify the corresponding chapter >=20 > That was rejected, Addison wants to document the record-jar > format, not its registry incarnation. That's backwards from > my POV, mail (2822) and news (1036) use prose for the simple > general format, and syntax for the header field details, but > there's no rule to do it this way also in 3066bis. I suggested that an independent RFC be written to document record-jar = for future generations, actually. In this case, I don't see the benefit of another ultra-complicated ABNF: = I don't think it will save very much text, if any, and it is hard to = read. Clarity is served by the current text/ABNF, I think. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?5?15? 21:12 > To: ltru@ietf.org > Subject: [Ltru] Re: Open points before -02 >=20 > > 1 - check and fill gaps in Suppress-Scripts >=20 > That was "rejected", the actual idea is to publish the registry > draft first (closing the old registry), and to finish the > business with the draft registry later. >=20 > > 2 - check SHOULD, MUST, and rationale for Suppress-Scripts >=20 > Addison proposed a rationale to be added in -02. Maybe Ira > and Randy still want to replace two corresponding SHOULD NOT > by some "MUST NOT unless". >=20 > > 3 - improve registry ABNF, simplify the corresponding chapter >=20 > That was rejected, Addison wants to document the record-jar > format, not its registry incarnation. That's backwards from > my POV, mail (2822) and news (1036) use prose for the simple > general format, and syntax for the header field details, but > there's no rule to do it this way also in 3066bis. >=20 > > 4 - redefine canonical / deprecated to follow the underlying > > ISO and UN standards (stable forever !=3D canonical forever) >=20 > Already discussed elsewhere. The last idea was to replace the > "normative Canonical: xx" by an "informative Use: xx". >=20 > > 5 - move redundant tags from draft registry to an appendix >=20 > Alread discussed elsewhere. It's possible to arrange things > this way, the registry would be shorter, implementations would > be simpler, but after all that's mainly a matter of taste. And > it's already clear that I didn't like two MO-nsense entries. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 16 13:02:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXiym-0005Ks-8z; Mon, 16 May 2005 13:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXiyg-0005Kf-P2; Mon, 16 May 2005 13:02:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11109; Mon, 16 May 2005 13:01:53 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXjF9-0003YK-3n; Mon, 16 May 2005 13:19:04 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 10:01:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C55A38.EF141F5F" Date: Mon, 16 May 2005 10:01:42 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B65DD95@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: [WG I-D Submission] draft-ietf-ltru-matching-00 Thread-Index: AcVaOO3dtog7gSIFS8KiFrHkWqVpVA== From: "Addison Phillips" To: X-OriginalArrivalTime: 16 May 2005 17:01:43.0279 (UTC) FILETIME=[EF80C7F0:01C55A38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 06321bb70e4329e24fb56a67c5eca3a0 Cc: ltru@ietf.org Subject: [Ltru] [WG I-D Submission] draft-ietf-ltru-matching-00 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C55A38.EF141F5F Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBlZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGluIHRleHQgZm9ybWF0IHRoZSBm aXJzdCAoLTAwKSBkcmFmdCBvZiB0aGUgTFRSVSB3b3JraW5nIGdyb3VwIEktRCAiZHJhZnQtaWV0 Zi1sdHJ1LW1hdGNoaW5nIi4gVGhlIGNoYWlycyAoTWFydGluIER1ZXJzdCBhbmQgUmFuZHkgUHJl c3VobikgaGF2ZSBiZWVuIGNvcGllZCBvbiB0aGlzIG1lc3NhZ2UgaW4gb3JkZXIgdG8gZm9yd2Fy ZCB0aGVpciBhcHByb3ZhbCBvZiB0aGlzIGZpcnN0IGRyYWZ0Lg0KDQpCZXN0IFJlZ2FyZHMgKGZv ciB0aGUgZWRpdG9ycykNCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxp emF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoN CkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRw Oi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5v dCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== ------_=_NextPart_001_01C55A38.EF141F5F Content-Type: text/plain; name="draft-ietf-ltru-matching-00.txt" Content-Description: draft-ietf-ltru-matching-00.txt Content-Disposition: attachment; filename="draft-ietf-ltru-matching-00.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IE5vdmVtYmVy IDE0LCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNYXkgMTMsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBNYXRjaGluZyBMYW5ndWFnZSBJZGVudGlmaWVycw0KICAgICAgICAgICAgICAgICAgICAgIGRy YWZ0LWlldGYtbHRydS1tYXRjaGluZy0wMA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5 IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0 aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGlj aCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwg YW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNj bG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdy b3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29y a2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJ bnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1E cmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhw aXJlIG9uIE5vdmVtYmVyIDE0LCAyMDA1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLg0KDQpBYnN0cmFjdA0KDQogICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBkaWZmZXJlbnQgbWVjaGFuaXNtcyBmb3IgY29tcGFyaW5n IGFuZA0KICAgbWF0Y2hpbmcgdGhlIHRhZ3MgZm9yIHRoZSBpZGVudGlmaWNhdGlvbiBvZiBsYW5n dWFnZXMgZGVmaW5lZCBieSBbUkZDDQogICAzMDY2YmlzXSBbMV0uICBQb3NzaWJsZSBhbGdvcml0 aG1zIGZvciBsYW5ndWFnZSBuZWdvdGlhdGlvbiBhbmQNCiAgIGNvbnRlbnQgc2VsZWN0aW9uIGFy ZSBkZXNjcmliZWQuICBQb3J0aW9ucyBvZiB0aGlzIGRvY3VtZW50IG9ic29sZXRlDQogICBbUkZD IDMwNjZdIFsxOV0uDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAgICAgICAgICAgTWF5IDIw MDUNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIuICBUaGUg TGFuZ3VhZ2UgUmFuZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNA0KICAgICAyLjEgICBCYXNpYyBMYW5ndWFnZSBSYW5nZSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgICAgMi4xLjEgICBNYXRjaGluZyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgICAyLjEuMiAgIExv b2t1cCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0K ICAgICAyLjIgICBFeHRlbmRlZCBMYW5ndWFnZSBSYW5nZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA2DQogICAgICAgMi4yLjEgICBFeHRlbmRlZCBSYW5nZSBNYXRjaGluZyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgICAyLjIuMiAgIEV4dGVuZGVk IFJhbmdlIExvb2t1cCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAg IDIuMi4zICAgU2NvcmVkIE1hdGNoaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA5DQogICAgIDIuMyAgIE1lYW5pbmcgb2YgTGFuZ3VhZ2UgVGFncyBhbmQgUmFuZ2Vz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgICAgMi40ICAgQ2hvb3NpbmcgQmV0d2VlbiBB bHRlcm5hdGUgTWF0Y2hpbmcgU2NoZW1lcyAgLiAuIC4gLiAuIC4gLiAxMQ0KICAgICAyLjUgICBD b25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAu IDExDQogICAzLiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgIDQuICBDaGFuZ2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgNS4gIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1DQog ICA2LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTYNCiAgIDcuICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0KICAgICA3LjEgICBOb3JtYXRpdmUgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICAgIDcu MiAgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTgNCiAgICAgICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgQS4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DQogICAgICAgSW50ZWxs ZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4g MjANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAg ICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbGFuZ01h dGNoaW5nICAgICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KMS4gIEludHJvZHVjdGlv bg0KDQogICBIdW1hbiBiZWluZ3Mgb24gb3VyIHBsYW5ldCBoYXZlLCBwYXN0IGFuZCBwcmVzZW50 LCB1c2VkIGEgbnVtYmVyIG9mDQogICBsYW5ndWFnZXMuICBUaGVyZSBhcmUgbWFueSByZWFzb25z IHdoeSBvbmUgd291bGQgd2FudCB0byBpZGVudGlmeSB0aGUNCiAgIGxhbmd1YWdlIHVzZWQgd2hl biBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3JtYXRpb24uDQoNCiAgIEluZm9ybWF0aW9u IGFib3V0IGEgdXNlcidzIGxhbmd1YWdlIHByZWZlcmVuY2VzIGNvbW1vbmx5IG5lZWRzIHRvIGJl DQogICBpZGVudGlmaWVkIHNvIHRoYXQgYXBwcm9wcmlhdGUgcHJvY2Vzc2luZyBjYW4gYmUgYXBw bGllZC4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIHVzZXIncyBsYW5ndWFnZSBwcmVmZXJlbmNlcyBp biBhIGJyb3dzZXIgY2FuIGJlIHVzZWQgdG8NCiAgIHNlbGVjdCB3ZWIgcGFnZXMgYXBwcm9wcmlh dGVseS4gIEEgY2hvaWNlIG9mIGxhbmd1YWdlIHByZWZlcmVuY2UgY2FuDQogICBhbHNvIGJlIHVz ZWQgdG8gc2VsZWN0IGFtb25nIHRvb2xzIChzdWNoIGFzIGRpY3Rpb25hcmllcykgdG8gYXNzaXN0 DQogICBpbiB0aGUgcHJvY2Vzc2luZyBvciB1bmRlcnN0YW5kaW5nIG9mIGNvbnRlbnQgaW4gZGlm ZmVyZW50IGxhbmd1YWdlcy4NCg0KICAgR2l2ZW4gYSBzZXQgb2YgbGFuZ3VhZ2UgaWRlbnRpZmll cnMsIHN1Y2ggYXMgdGhvc2UgZGVmaW5lZCBpbg0KICAgUkZDMzA2NmJpcywgdmFyaW91cyBtZWNo YW5pc21zIGNhbiBiZSBlbnZpc2lvbmVkIGZvciBwZXJmb3JtaW5nDQogICBsYW5ndWFnZSBuZWdv dGlhdGlvbiBhbmQgdGFnIG1hdGNoaW5nLiAgVGhlIHN1aXRhYmlsaXR5IG9mIGENCiAgIHBhcnRp Y3VsYXIgbWVjaGFuaXNtIHRvIGEgcGFydGljdWxhciBhcHBsaWNhdGlvbiBkZXBlbmRzIG9uIHRo ZSBuZWVkcw0KICAgb2YgdGhhdCBhcHBsaWNhdGlvbi4NCg0KICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIGxhbmd1YWdlIHJhbmdlcyBhbmQgc3ludGF4IGZvciBzcGVjaWZ5aW5nIHVzZXINCiAgIHBy ZWZlcmVuY2VzIGluIGEgcmVxdWVzdCBmb3IgbGFuZ3VhZ2UgY29udGVudC4gIEl0IGFsc28gc3Bl Y2lmaWVzIGENCiAgIGRlZmF1bHQgYWxnb3JpdGhtIGZvciBtYXRjaGluZyBsYW5ndWFnZSByYW5n ZXMgdG8gY29udGVudCAobGFuZ3VhZ2UNCiAgIHRhZ3MpLCBhcyB3ZWxsIGFzIGFsdGVybmF0ZSBt ZWNoYW5pc21zIHN1aXRhYmxlIGZvciBjZXJ0YWluDQogICBhcHBsaWNhdGlvbnMuDQoNCiAgIFRo ZSBrZXl3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFM TCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIs IGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRl ZCBhcyBkZXNjcmliZWQgaW4gW1JGQyAyMTE5XSBbNV0uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAgICAgICAgICAgTWF5IDIw MDUNCg0KDQoyLiAgVGhlIExhbmd1YWdlIFJhbmdlDQoNCiAgIExhbmd1YWdlIFRhZ3MgYXJlIHVz ZWQgdG8gaWRlbnRpZnkgdGhlIGxhbmd1YWdlIG9mIHNvbWUgaW5mb3JtYXRpb24NCiAgIGl0ZW0g b3IgY29udGVudC4gIEFwcGxpY2F0aW9ucyB0aGF0IHVzZSBsYW5ndWFnZSB0YWdzIGFyZSBvZnRl biBmYWNlZA0KICAgd2l0aCB0aGUgcHJvYmxlbSBvZiBpZGVudGlmeWluZyBzZXRzIG9mIGNvbnRl bnQgdGhhdCBzaGFyZSBjZXJ0YWluDQogICBsYW5ndWFnZSBhdHRyaWJ1dGVzLiAgRm9yIGV4YW1w bGUsIEhUVFAgMS4xIFsxMF0gZGVzY3JpYmVzIGxhbmd1YWdlDQogICByYW5nZXMgaW4gaXRzIGRp c2N1c3Npb24gb2YgdGhlIEFjY2VwdC1MYW5ndWFnZSBoZWFkZXIgKFNlY3Rpb24NCiAgIDE0LjQp LCB3aGljaCBpcyB1c2VkIGZvciBzZWxlY3RpbmcgY29udGVudCBmcm9tIHNlcnZlcnMgYmFzZWQg b24gdGhlDQogICBsYW5ndWFnZSBvZiB0aGF0IGNvbnRlbnQuDQoNCiAgIFdoZW4gc2VsZWN0aW5n IGNvbnRlbnQgYWNjb3JkaW5nIHRvIGl0cyBsYW5ndWFnZSwgaXQgaXMgdXNlZnVsIHRvDQogICBo YXZlIGEgbWVjaGFuaXNtIGZvciBpZGVudGlmeWluZyBzZXRzIG9mIGxhbmd1YWdlIHRhZ3MgdGhh dCBzaGFyZQ0KICAgc3BlY2lmaWMgYXR0cmlidXRlcy4gIFRoaXMgYWxsb3dzIHVzZXJzIHRvIHNl bGVjdCBvciBmaWx0ZXIgY29udGVudA0KICAgYmFzZWQgb24gc3BlY2lmaWMgcmVxdWlyZW1lbnRz LiAgU3VjaCBhbiBpZGVudGlmaWVyIGlzIGNhbGxlZCBhDQogICAiTGFuZ3VhZ2UgUmFuZ2UiLg0K DQoyLjEgIEJhc2ljIExhbmd1YWdlIFJhbmdlDQoNCiAgIEEgYmFzaWMgbGFuZ3VhZ2UgcmFuZ2Ug KHN1Y2ggYXMgZGVzY3JpYmVkIGluIFJGQyAzMDY2IFsxOV0gYW5kIEhUVFANCiAgIDEuMSBbMTBd KSBpcyBhIHNldCBvZiBsYW5ndWFnZXMgd2hvc2UgdGFncyBhbGwgYmVnaW4gd2l0aCB0aGUgc2Ft ZQ0KICAgc2VxdWVuY2Ugb2Ygc3VidGFncy4gIEEgYmFzaWMgbGFuZ3VhZ2UgcmFuZ2UgY2FuIGJl IHJlcHJlc2VudGVkIGJ5IGENCiAgICdsYW5ndWFnZS1yYW5nZScgdGFnLCBieSB1c2luZyB0aGUg ZGVmaW5pdGlvbiBmcm9tIEhUVFAvMS4xIFsxMF0gOg0KICAgbGFuZ3VhZ2UtcmFuZ2UgPSBsYW5n dWFnZS10YWcgLyAiKiINCg0KICAgVGhhdCBpcywgYSBsYW5ndWFnZS1yYW5nZSBoYXMgdGhlIHNh bWUgc3ludGF4IGFzIGEgbGFuZ3VhZ2UtdGFnIG9yIGlzDQogICB0aGUgc2luZ2xlIGNoYXJhY3Rl ciAiKiIuICBUaGlzIGRlZmluaXRpb24gb2YgbGFuZ3VhZ2UtcmFuZ2UgaW1wbGllcw0KICAgdGhh dCB0aGVyZSBpcyBhIHNlbWFudGljIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRhZ3MgdGhhdCBzaGFy ZSB0aGUNCiAgIHNhbWUgcHJlZml4Lg0KDQogICBJbiBwYXJ0aWN1bGFyLCB0aGUgc2V0IG9mIGxh bmd1YWdlIHRhZ3MgdGhhdCBtYXRjaCBhIHNwZWNpZmljDQogICBsYW5ndWFnZS1yYW5nZSBtYXkg bm90IGFsbCBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUuICBUaGUgdXNlIG9mIGENCiAgIHByZWZp eCB3aGVuIG1hdGNoaW5nIHRhZ3MgdG8gbGFuZ3VhZ2UgcmFuZ2VzIGRvZXMgbm90IGltcGx5IHRo YXQNCiAgIGxhbmd1YWdlIHRhZ3MgYXJlIGFzc2lnbmVkIHRvIGxhbmd1YWdlcyBpbiBzdWNoIGEg d2F5IHRoYXQgaXQgaXMNCiAgIGFsd2F5cyB0cnVlIHRoYXQgaWYgYSB1c2VyIHVuZGVyc3RhbmRz IGEgbGFuZ3VhZ2Ugd2l0aCBhIGNlcnRhaW4gdGFnLA0KICAgdGhlbiB0aGlzIHVzZXIgd2lsbCBh bHNvIHVuZGVyc3RhbmQgYWxsIGxhbmd1YWdlcyB3aXRoIHRhZ3MgZm9yIHdoaWNoDQogICB0aGlz IHRhZyBpcyBhIHByZWZpeC4gIFRoZSBwcmVmaXggcnVsZSBzaW1wbHkgYWxsb3dzIHRoZSB1c2Ug b2YNCiAgIHByZWZpeCB0YWdzIGlmIHRoaXMgaXMgdGhlIGNhc2UuDQoNCiAgIFdoZW4gd29ya2lu ZyB3aXRoIHRhZ3MgYW5kIHJhbmdlcyB5b3Ugc2hvdWxkIGFsc28gbm90ZSB0aGUgZm9sbG93aW5n Og0KDQogICAxLiAgUHJpdmF0ZS11c2UgYW5kIEV4dGVuc2lvbiBzdWJ0YWdzIGFyZSBub3JtYWxs eSBvcnRob2dvbmFsIHRvDQogICAgICAgbGFuZ3VhZ2UgdGFnIGZhbGxiYWNrLiAgSW1wbGVtZW50 YXRpb25zIHNob3VsZCBpZ25vcmUNCiAgICAgICB1bnJlY29nbml6ZWQgcHJpdmF0ZS11c2UgYW5k IGV4dGVuc2lvbiBzdWJ0YWdzIHdoZW4gcGVyZm9ybWluZw0KICAgICAgIGxhbmd1YWdlIHRhZyBm YWxsYmFjay4gIFNpbmNlIHRoZXNlIHN1YnRhZ3MgYXJlIGFsd2F5cyBhdCB0aGUgZW5kDQogICAg ICAgb2YgdGhlIHNlcXVlbmNlIG9mIHN1YnRhZ3MsIHRoZXkgbmF0dXJhbGx5IGZhbGwgb3V0IG9m IHRoZQ0KICAgICAgIGRlZmF1bHQgZmFsbGJhY2sgcGF0dGVybiAoYWJvdmUpLiAgVGh1cyBhIHJl cXVlc3QgdG8gbWF0Y2ggdGhlDQogICAgICAgdGFnICJlbi1VUy1ib29udC14LTE5NDMiIHdvdWxk IHByb2R1Y2UgZXhhY3RseSB0aGUgc2FtZQ0KICAgICAgIGluZm9ybWF0aW9uIGNvbnRlbnQgYXMg dGhlIGV4YW1wbGUgYWJvdmUuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDE0LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgIGxhbmdNYXRjaGluZyAgICAgICAgICAgICAgICAgICAgICBNYXkg MjAwNQ0KDQoNCiAgIDIuICBJbXBsZW1lbnRhdGlvbnMgdGhhdCBjaG9vc2Ugbm90IHRvIGludGVy cHJldCBvbmUgb3IgbW9yZSBwcml2YXRlLQ0KICAgICAgIHVzZSBvciBleHRlbnNpb24gc3VidGFn cyBzaG91bGQgbm90IHJlbW92ZSBvciBtb2RpZnkgdGhlc2UNCiAgICAgICBleHRlbnNpb25zIGlu IGNvbnRlbnQgdGhhdCB0aGV5IGFyZSBwcm9jZXNzaW5nLiAgV2hlbiBhIGxhbmd1YWdlDQogICAg ICAgdGFnIGluc3RhbmNlIGlzIHRvIGJlIHVzZWQgaW4gYSBzcGVjaWZpYywga25vd24gcHJvdG9j b2wsIGFuZCBpcw0KICAgICAgIG5vdCBiZWluZyBwYXNzZWQgdGhyb3VnaCB0byBvdGhlciBwcm90 b2NvbHMsIGxhbmd1YWdlIHRhZ3MgbWF5IGJlDQogICAgICAgZmlsdGVyZWQgdG8gcmVtb3ZlIHN1 YnRhZ3MgYW5kIGV4dGVuc2lvbnMgdGhhdCBhcmUgbm90IHN1cHBvcnRlZA0KICAgICAgIGJ5IHRo YXQgcHJvdG9jb2wuICBUaGlzIHNob3VsZCBiZSBkb25lIHdpdGggY2F1dGlvbiwgc2luY2UgaXQg aXQNCiAgICAgICBpcyByZW1vdmluZyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSByZWxldmFudCBp ZiBzZXJ2aWNlcyBvbiB0aGUNCiAgICAgICBvdGhlciBlbmQgb2YgdGhlIHByb3RvY29sIHdvdWxk IG1ha2UgdXNlIG9mIHRoYXQgaW5mb3JtYXRpb24uDQoNCiAgIDMuICBTb21lIGFwcGxpY2F0aW9u cyBvZiBsYW5ndWFnZSB0YWdzIG1heSB3YW50IG9yIG5lZWQgdG8gY29uc2lkZXINCiAgICAgICBl eHRlbnNpb25zIGFuZCBwcml2YXRlLXVzZSBzdWJ0YWdzIHdoZW4gbWF0Y2hpbmcgdGFncy4gIElm DQogICAgICAgZXh0ZW5zaW9ucyBhbmQgcHJpdmF0ZS11c2Ugc3VidGFncyBhcmUgaW5jbHVkZWQg aW4gYSBtYXRjaGluZw0KICAgICAgIHByb2Nlc3MgdGhhdCB1dGlsaXplcyB0aGUgZGVmYXVsdCBm YWxsYmFjayBtZWNoYW5pc20sIHRoZW4gdGhlDQogICAgICAgaW1wbGVtZW50YXRpb24gc2hvdWxk IGNhbm9uaWNhbGl6ZSB0aGUgbGFuZ3VhZ2UgdGFncyBhbmQvb3INCiAgICAgICByYW5nZXMgYmVm b3JlIHBlcmZvcm1pbmcgdGhlIG1hdGNoaW5nLiAgTm90ZSB0aGF0IGxhbmd1YWdlIHRhZw0KICAg ICAgIHByb2Nlc3NvcnMgdGhhdCBjbGFpbSB0byBiZSAid2VsbC1mb3JtZWQiIHByb2Nlc3NvcnMg YXMgZGVmaW5lZA0KICAgICAgIGluIFsxXSBnZW5lcmFsbHkgZmFsbCBpbnRvIHRoaXMgY2F0ZWdv cnkuDQoNCiAgIFRoZXJlIGFyZSB0d28gbWF0Y2hpbmcgc2NoZW1lcyAgdGhhdCBhcmUgY29tbW9u bHkgYXNzb2NpYXRlZCB3aXRoDQogICBiYXNpYyBsYW5ndWFnZSByYW5nZXM6ICBtYXRjaGluZyBh bmQgIGxvb2t1cC4NCg0KMi4xLjEgIE1hdGNoaW5nDQoNCiAgIExhbmd1YWdlIHRhZyBtYXRjaGlu ZyBpcyB1c2VkIHRvIHNlbGVjdCBhbGwgY29udGVudCB0aGF0IG1hdGNoZXMgYQ0KICAgZ2l2ZW4g cHJlZml4LiAgSW4gbWF0Y2hpbmcsIHRoZSBsYW5ndWFnZSByYW5nZSByZXByZXNlbnRzIHRoZSBs ZWFzdA0KICAgc3BlY2lmaWMgdGFnIHdoaWNoIGlzIGFuIGFjY2VwdGFibGUgbWF0Y2ggYW5kIGV2 ZXJ5IHBpZWNlIG9mIGNvbnRlbnQNCiAgIHRoYXQgbWF0Y2hlcyBpcyByZXR1cm5lZC4NCg0KICAg Rm9yIGV4YW1wbGUsIGlmIGFuIGFwcGxpY2F0aW9uIGlzIGFwcGx5aW5nIGEgc3R5bGUgdG8gYWxs IGNvbnRlbnQgaW4NCiAgIGEgd2ViIHBhZ2UgaW4gYSBwYXJ0aWN1bGFyIGxhbmd1YWdlLCBpdCBt aWdodCB1c2UgbGFuZ3VhZ2UgdGFnDQogICBtYXRjaGluZyB0byBwZXJmb3JtIHRoZSBtYXRjaGlu Zy4NCg0KICAgQSBsYW5ndWFnZS1yYW5nZSBtYXRjaGVzIGEgbGFuZ3VhZ2UtdGFnIGlmIGl0IGV4 YWN0bHkgZXF1YWxzIHRoZSB0YWcsDQogICBvciBpZiBpdCBleGFjdGx5IGVxdWFscyBhIHByZWZp eCBvZiB0aGUgdGFnIHN1Y2ggdGhhdCB0aGUgZmlyc3QNCiAgIGNoYXJhY3RlciBmb2xsb3dpbmcg dGhlIHByZWZpeCBpcyAiLSIuICAoVGhhdCBpcywgdGhlIGxhbmd1YWdlLXJhbmdlDQogICAiZW4t ZGUiIG1hdGNoZXMgdGhlIGxhbmd1YWdlIHRhZyAiZW4tREUtYm9vbnQiLCBidXQgbm90IHRoZSBs YW5ndWFnZQ0KICAgdGFnICJlbi1EZXZhIi4pDQoNCiAgIFRoZSBzcGVjaWFsIHJhbmdlICIqIiBt YXRjaGVzIGFueSB0YWcuICBBIHByb3RvY29sIHdoaWNoIHVzZXMNCiAgIGxhbmd1YWdlIHJhbmdl cyBtYXkgc3BlY2lmeSBhZGRpdGlvbmFsIHJ1bGVzIGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YNCiAg ICIqIjsgZm9yIGluc3RhbmNlLCBIVFRQLzEuMSBzcGVjaWZpZXMgdGhhdCB0aGUgcmFuZ2UgIioi IG1hdGNoZXMgb25seQ0KICAgbGFuZ3VhZ2VzIG5vdCBtYXRjaGVkIGJ5IGFueSBvdGhlciByYW5n ZSB3aXRoaW4gYW4gIkFjY2VwdC1MYW5ndWFnZToiDQogICBoZWFkZXIuDQoNCjIuMS4yICBMb29r dXANCg0KICAgQ29udGVudCBsb29rdXAgaXMgdXNlZCB0byBzZWxlY3QgdGhlIHNpbmdsZSBpbmZv cm1hdGlvbiBpdGVtIHRoYXQNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMg Tm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgbGFuZ01hdGNoaW5nICAgICAgICAgICAgICAgICAgICAgIE1heSAy MDA1DQoNCg0KICAgYmVzdCBtYXRjaGVzIHRoZSBsYW5ndWFnZSByYW5nZSBmb3IgYSBnaXZlbiBy ZXF1ZXN0LiAgSW4gbG9va3VwLCB0aGUNCiAgIGxhbmd1YWdlIHJhbmdlIHJlcHJlc2VudHMgdGhl IG1vc3Qgc3BlY2lmaWMgdGFnIHdoaWNoIGlzIGFuDQogICBhY2NlcHRhYmxlIG1hdGNoIGFuZCBv bmx5IHRoZSBjbG9zZXN0IG1hdGNoaW5nIGl0ZW0gaXMgcmV0dXJuZWQuDQoNCiAgIEZvciBleGFt cGxlLCBpZiBhbiBhcHBsaWNhdGlvbiBpbnNlcnRzIHNvbWUgZHluYW1pYyBjb250ZW50IGludG8g YQ0KICAgd2ViIHBhZ2UsIHJldHVybmluZyBhbiBlbXB0eSBzdHJpbmcgaWYgdGhlcmUgaXMgbm8g ZXhhY3QgbWF0Y2ggaXMgbm90DQogICBhbiBvcHRpb24uICBJbnN0ZWFkLCB0aGUgYXBwbGljYXRp b24gImZhbGxzIGJhY2siLg0KDQogICBXaGVuIHBlcmZvcm1pbmcgbG9va3VwLCB0aGUgbGFuZ3Vh Z2UgcmFuZ2UgaXMgcHJvZ3Jlc3NpdmVseSB0cnVuY2F0ZWQNCiAgIGZyb20gdGhlIGVuZCB1bnRp bCBhIG1hdGNoaW5nIHBpZWNlIG9mIGNvbnRlbnQgaXMgbG9jYXRlZC4gIEZvcg0KICAgZXhhbXBs ZSwgc3RhcnRpbmcgd2l0aCB0aGUgcmFuZ2UgInpoLUhhbnQtQ04teC13YWRlZ2lsZSIsIHRoZSBs b29rdXANCiAgIHdvdWxkIHByb2dyZXNzaXZlbHkgc2VhcmNoIGZvciBjb250ZW50IGFzIHNob3du IGJlbG93Og0KDQogICBSYW5nZSB0byBtYXRjaDogemgtSGFudC1DTi14LXdhZGVnaWxlDQogICAx LiB6aC1IYW50LUNOLXgtd2FkZWdpbGUNCiAgIDIuIHpoLUhhbnQtQ04NCiAgIDMuIHpoLUhhbnQN CiAgIDQuIHpoDQogICA1LiAoZGVmYXVsdCBjb250ZW50IG9yIHRoZSBlbXB0eSB0YWcpDQoNCiAg ICAgICAgICAgICAgICBGaWd1cmUgMjogRGVmYXVsdCBGYWxsYmFjayBQYXR0ZXJuIEV4YW1wbGUN Cg0KICAgVGhpcyBzY2hlbWUgYWxsb3dzIHNvbWUgZmxleGliaWxpdHkgaW4gZmluZGluZyBjb250 ZW50LiAgSXQgYWxzbw0KICAgdHlwaWNhbGx5IHByb3ZpZGVzIGJldHRlciByZXN1bHRzIHdoZW4g ZGF0YSBpcyBub3QgYXZhaWxhYmxlIGF0IGENCiAgIHNwZWNpZmljIGxldmVsIG9mIHRhZyBncmFu dWxhcml0eSBvciBpcyBzcGFyc2VseSBwb3B1bGF0ZWQgKHRoYW4gaWYNCiAgIHRoZSBkZWZhdWx0 IGxhbmd1YWdlIGZvciB0aGUgc3lzdGVtIG9yIGNvbnRlbnQgd2VyZSB1c2VkKS4NCg0KMi4yICBF eHRlbmRlZCBMYW5ndWFnZSBSYW5nZQ0KDQogICBQcmVmaXggbWF0Y2hpbmcgdXNpbmcgYSBCYXNp YyBMYW5ndWFnZSBSYW5nZSwgYXMgZGVzY3JpYmVkIGFib3ZlLCBpcw0KICAgbm90IGFsd2F5cyB0 aGUgbW9zdCBhcHByb3ByaWF0ZSB3YXkgdG8gYWNjZXNzIHRoZSBpbmZvcm1hdGlvbg0KICAgY29u dGFpbmVkIGluIGxhbmd1YWdlIHRhZ3Mgd2hlbiBzZWxlY3Rpbmcgb3IgZmlsdGVyaW5nIGNvbnRl bnQuICBTb21lDQogICBhcHBsaWNhdGlvbnMgbWF5IHdpc2ggdG8gZGVmaW5lIGEgbW9yZSBncmFu dWxhciBtYXRjaGluZyBzY2hlbWUgYW5kDQogICBzdWNoIGEgbWF0Y2hpbmcgc2NoZW1lIHJlcXVp cmVzIHRoZSBhYmlsaXR5IHRvIHNwZWNpZnkgdGhlIHZhcmlvdXMNCiAgIGF0dHJpYnV0ZXMgb2Yg YSBsYW5ndWFnZSB0YWcgaW4gdGhlIGxhbmd1YWdlIHJhbmdlLiAgQW4gZXh0ZW5kZWQNCiAgIGxh bmd1YWdlIHJhbmdlIGNhbiBiZSByZXByZXNlbnRlZCBieSB0aGUgZm9sbG93aW5nIEFCTkY6DQog ICBleHRlbmRlZC1sYW5ndWFnZS1yYW5nZSA9IGdyYW5kZmF0aGVyZWQgLyBwcml2YXRldXNlIC8g cmFuZ2UNCiAgIHJhbmdlICAgPSAoIGxhbmcgWyAiLSIgc2NyaXB0IF0gWyAiLSIgcmVnaW9uIF0g KiggIi0iIHZhcmlhbnQgKQ0KICAgICAgICAgICAgICAgIFsgIi0iIHByaXZhdGV1c2UgXSApDQog ICBsYW5nICAgID0gKCAyKjhBTFBIQSAqWyAqKCAiLSIgZXh0bGFuZyBdICkgKSAvICIqIg0KICAg ZXh0bGFuZyA9IDNBTFBIQSAvICIqIg0KICAgc2NyaXB0ICA9IDRBTFBIQSAvICIqIg0KICAgcmVn aW9uICA9IDJBTFBIQSAvIDNESUdJVCAvICIqIg0KICAgdmFyaWFudCA9IDUqOGFscGhhbnVtIC8g KCBESUdJVCAzYWxwaGFudW0gKSAvICIqIg0KICAgcHJpdmF0ZXVzZSAgICA9ICggIngiIC8gIlgi ICkgMSooICItIiAoIDEqOGFscGhhbnVtICkgKQ0KICAgZ3JhbmRmYXRoZXJlZCA9IDEqM0FMUEhB IDEqMiggIi0iICggMio4YWxwaGFudW0gKSApDQogICBhbHBoYW51bSAgICAgID0gKCBBTFBIQSAv IERJR0lUICkNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJl ciAxNCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0K DQogICBJbiBhbiBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSwgdGhlIGlkZW50aWZpZXIgdGFrZXMg dGhlIGZvcm0gb2YgYQ0KICAgc2VyaWVzIG9mIHN1YnRhZ3Mgd2hpY2ggbXVzdCBjb25zaXN0IG9m IHdlbGwtZm9ybWVkIHN1YnRhZ3Mgb3IgdGhlDQogICBzcGVjaWFsIHN1YnRhZyAiKiIuICBGb3Ig ZXhhbXBsZSwgdGhlIGxhbmd1YWdlIHJhbmdlICJlbi0qLVVTIg0KICAgc3BlY2lmaWVzIGEgcHJp bWFyeSBsYW5ndWFnZSBvZiAnZW4nLCBmb2xsb3dlZCBieSBhbnkgc2NyaXB0IHN1YnRhZywNCiAg IGZvbGxvd2VkIGJ5IHRoZSByZWdpb24gc3VidGFnICdVUycuDQoNCiAgIEEgZmllbGQgbm90IHBy ZXNlbnQgaW4gdGhlIG1pZGRsZSBvZiBhbiBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSBNQVkNCiAg IGJlIHRyZWF0ZWQgYXMgaWYgdGhlIGZpZWxkIGNvbnRhaW5lZCBhICIqIi4gIEZvciBleGFtcGxl LCB0aGUgcmFuZ2UNCiAgICJlbi1VUyIgTUFZIGJlIGNvbnNpZGVyZWQgdG8gYmUgZXF1aXZhbGVu dCB0byB0aGUgcmFuZ2UgImVuLSotVVMiLg0KDQogICBUaGVyZSBhcmUgc2V2ZXJhbCBtYXRjaGlu ZyBhbGdvcml0aG1zIG9yIHNjaGVtZXMgd2hpY2ggbWF5IGJlIGFwcGxpZWQNCiAgIHdoZW4gbWF0 Y2hpbmcgZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2VzIHRvIGxhbmd1YWdlIHRhZ3MuDQoNCjIuMi4x ICBFeHRlbmRlZCBSYW5nZSBNYXRjaGluZw0KDQogICBJbiBleHRlbmRlZCByYW5nZSBtYXRjaGlu ZywgdGhlIHN1YnRhZ3MgaW4gYSBsYW5ndWFnZSB0YWcgYXJlDQogICBjb21wYXJlZCB0byB0aGUg Y29ycmVzcG9uZGluZyBzdWJ0YWdzIGluIHRoZSBleHRlbmRlZCBsYW5ndWFnZSByYW5nZS4NCiAg IEEgc3VidGFnIGlzIGNvbnNpZGVyZWQgdG8gbWF0Y2ggaWYgaXQgZXhhY3RseSBtYXRjaGVzIHRo ZQ0KICAgY29ycmVzcG9uZGluZyBzdWJ0YWcgaW4gdGhlIHJhbmdlIG9yIHRoZSByYW5nZSBjb250 YWlucyBhIHN1YnRhZyB3aXRoDQogICB0aGUgdmFsdWUgIioiICh3aGljaCBtYXRjaGVzIGFsbCBz dWJ0YWdzLCBpbmNsdWRpbmcgdGhlIGVtcHR5DQogICBzdWJ0YWcpLiAgRXh0ZW5kZWQgUmFuZ2Ug TWF0Y2hpbmcgaXMgYW4gZXh0ZW5zaW9uIG9mIGJhc2ljIG1hdGNoaW5nDQogICAoU2VjdGlvbiAy LjEuMSk6IHRoZSBsYW5ndWFnZSByYW5nZSByZXByZXNlbnRzIHRoZSBsZWFzdCBzcGVjaWZpYyB0 YWcNCiAgIHdoaWNoIGlzIGFuIGFjY2VwdGFibGUgbWF0Y2guDQoNCiAgIEJ5IGRlZmF1bHQgYWxs IGV4dGVuc2lvbnMgYW5kIHRoZWlyIHN1YnRhZ3MgYXJlIGlnbm9yZWQgZm9yIGV4dGVuZGVkDQog ICBsYW5ndWFnZSByYW5nZSBtYXRjaGluZy4NCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFncyBtYXkg YmUgc3BlY2lmaWVkIGluIHRoZSBsYW5ndWFnZSByYW5nZSBhbmQgTVVTVA0KICAgTk9UIGJlIGln bm9yZWQgd2hlbiBtYXRjaGluZy4NCg0KICAgU3VidGFncyBub3Qgc3BlY2lmaWVkLCBpbmNsdWRl ZCB0aG9zZSBhdCB0aGUgZW5kIG9mIHRoZSBsYW5ndWFnZQ0KICAgcmFuZ2UsIGFyZSBhc3NpZ25l ZCB0aGUgdmFsdWUgIioiLiAgVGhpcyBtYWtlcyBlYWNoIHJhbmdlIGludG8gYQ0KICAgcHJlZml4 IG11Y2ggbGlrZSB0aGF0IHVzZWQgaW4gYmFzaWMgbGFuZ3VhZ2UgcmFuZ2UgbWF0Y2hpbmcuICBG b3INCiAgIGV4YW1wbGUsIHRoZSBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSAiemgtKi1DTiIgbWF0 Y2hlcyBhbGwgb2YgdGhlDQogICBmb2xsb3dpbmcgdGFncyBiZWNhdXNlIHRoZSB1bnNwZWNpZmll ZCB2YXJpYW50IGZpZWxkIGlzIGV4cGFuZGVkIHRvDQogICAiKiI6DQoNCiAgICAgIHpoLUhhbnQt Q04NCg0KICAgICAgemgtQ04NCg0KICAgICAgemgtSGFucy1DTg0KDQogICAgICB6aC1DTi14LXdh ZGVnaWxlDQoNCiAgICAgIHpoLUxhdG4tQ04tYm9vbnQNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2Ug N10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGxhbmdNYXRjaGluZyAgICAgICAg ICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCjIuMi4yICBFeHRlbmRlZCBSYW5nZSBMb29rdXAN Cg0KICAgSW4gZXh0ZW5kZWQgcmFuZ2UgbG9va3VwLCB0aGUgc3VidGFncyBpbiBhIGxhbmd1YWdl IHRhZyBhcmUgY29tcGFyZWQNCiAgIHRvIHRoZSBjb3JyZXNwb25kaW5nIHN1YnRhZ3MgaW4gdGhl IGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlLiAgVGhlDQogICBzdWJ0YWcgaXMgY29uc2lkZXJlZCB0 byBtYXRjaCBpZiBpdCBleGFjdGx5IG1hdGNoZXMgdGhlIGNvcnJlc3BvbmRpbmcNCiAgIHN1YnRh ZyBpbiB0aGUgcmFuZ2Ugb3IgdGhlIHJhbmdlIGNvbnRhaW5zIGEgc3VidGFnIHdpdGggdGhlIHZh bHVlICIqIg0KICAgKHdoaWNoIG1hdGNoZXMgYWxsIHN1YnRhZ3MsIGluY2x1ZGluZyB0aGUgZW1w dHkgc3VidGFnKS4gIEV4dGVuZGVkDQogICBsYW5ndWFnZSByYW5nZSBsb29rdXAgaXMgYW4gZXh0 ZW5zaW9uIG9mIGJhc2ljIGxvb2t1cA0KICAgKFNlY3Rpb24gMi4xLjIpOiB0aGUgbGFuZ3VhZ2Ug cmFuZ2UgcmVwcmVzZW50cyB0aGUgbW9zdCBzcGVjaWZpYyB0YWcNCiAgIHdoaWNoIHdpbGwgZm9y bSBhbiBhY2NlcHRhYmxlIG1hdGNoLg0KDQogICBTdWJ0YWdzIG5vdCBzcGVjaWZpZWQgYXJlIGFz c2lnbmVkIHRoZSB2YWx1ZSAiKiIgcHJpb3IgdG8gcGVyZm9ybWluZw0KICAgdGFnIG1hdGNoaW5n LiAgVW5saWtlIGluIGV4dGVuZGVkIHJhbmdlIG1hdGNoaW5nLCBob3dldmVyLCBmaWVsZHMgYXQN CiAgIHRoZSBlbmQgb2YgdGhlIHJhbmdlIE1VU1QgTk9UIGJlIGV4cGFuZGVkIGluIHRoaXMgbWFu bmVyLiAgRm9yDQogICBleGFtcGxlLCAiZW4tVVMiIG11c3Qgbm90IGJlIGNvbnNpZGVyZWQgdG8g YmUgdGhlIHNhbWUgYXMgdGhlIHJhbmdlDQogICAiZW4tVVMtKiIuICBUaGlzIGFsbG93cyByYW5n ZXMgdG8gYmUgc3BlY2lmaWMuICBUaGUgIioiIHdpbGRjYXJkIE1VU1QNCiAgIGJlIHVzZWQgYXQg dGhlIGVuZCBvZiB0aGUgcmFuZ2UgdG8gaW5kaWNhdGUgdGhhdCBhbGwgdGFncyB3aXRoIHRoZQ0K ICAgcmFuZ2UgYXMgYSBwcmVmaXggYXJlIGFsbG93YWJsZSBtYXRjaGVzLiAgVGhhdCBpcywgdGhl IHJhbmdlICJ6aC0qIg0KICAgbWF0Y2hlcyB0aGUgdGFncyAiemgtSGFudCIgYW5kICJ6aC1IYW50 LUNOIiwgd2hpbGUgdGhlIHJhbmdlICJ6aCINCiAgIG1hdGNoZXMgbmVpdGhlciBvZiB0aG9zZSB0 YWdzLg0KDQogICBUaGUgd2lsZGNhcmQgIioiIGF0IHRoZSBlbmQgb2YgYSByYW5nZSBTSE9VTEQg YmUgY29uc2lkZXJlZCB0byBtYXRjaA0KICAgYW55IHByaXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5j ZXMgKG1ha2luZyBleHRlbmRlZCBsYW5ndWFnZSByYW5nZQ0KICAgbG9va3VwIGZ1bmN0aW9uIGV4 YWN0bHkgbGlrZSBleHRlbmRlZCByYW5nZSBtYXRjaGluZyBTZWN0aW9uIDIuMi4xKS4NCg0KICAg QnkgZGVmYXVsdCBhbGwgZXh0ZW5zaW9ucyBhbmQgdGhlaXIgc3VidGFncyBTSE9VTEQgYmUgaWdu b3JlZCBmb3INCiAgIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGxvb2t1cC4gIFByaXZhdGUgdXNl IHN1YnRhZ3MgbWF5IGJlIHNwZWNpZmllZA0KICAgaW4gdGhlIGxhbmd1YWdlIHJhbmdlIGFuZCBN VVNUIE5PVCBiZSBpZ25vcmVkIHdoZW4gcGVyZm9ybWluZyBsb29rdXAuDQogICBUaGUgd2lsZGNh cmQgIioiIGF0IHRoZSBlbmQgb2YgYSByYW5nZSBTSE9VTEQgYmUgY29uc2lkZXJlZCB0byBtYXRj aA0KICAgYW55IHByaXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5jZXMgaW4gYWRkaXRpb24gdG8gdmFy aWFudHMuDQoNCiAgIEZvciBleGFtcGxlLCB0aGUgcmFuZ2UgIiotVVMiIG1hdGNoZXMgYWxsIG9m IHRoZSBmb2xsb3dpbmcgdGFnczoNCg0KICAgICAgZW4tVVMNCg0KICAgICAgZW4tTGF0bi1VUw0K DQogICAgICBlbi1VUy1yLWV4dGVuZHMgKGV4dGVuc2lvbnMgYXJlIGlnbm9yZWQpDQoNCiAgICAg IGZyLVVTDQoNCiAgIEZvciBleGFtcGxlLCB0aGUgcmFuZ2UgImVuLSotVVMiIG1hdGNoZXMgX25v bmVfIG9mIHRoZSBmb2xsb3dpbmcNCiAgIHRhZ3M6DQoNCiAgICAgIGZyLVVTDQoNCiAgICAgIGVu IChtaXNzaW5nIHJlZ2lvbiBVUykNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAgICAgICAgICAg TWF5IDIwMDUNCg0KDQogICAgICBlbi1MYXRuIChtaXNzaW5nIHJlZ2lvbiBVUykNCg0KICAgICAg ZW4tTGF0bi1VUy1zY291c2UgKHZhcmlhbnQgZmllbGQgaXMgcHJlc2VudCkNCg0KICAgRm9yIGV4 YW1wbGUsIHRoZSByYW5nZSAiZW4tKiIgbWF0Y2hlcyBhbGwgb2YgdGhlIGZvbGxvd2luZyB0YWdz Og0KDQogICAgICBlbi1MYXRuDQoNCiAgICAgIGVuLUxhdG4tVVMNCg0KICAgICAgZW4tTGF0bi1V Uy1zY291c2UNCg0KICAgICAgZW4tVVMNCg0KICAgICAgZW4tc2NvdXNlDQoNCiAgIEl0IHNob3Vs ZCBiZSBub3RlZCB0aGF0IHRoZSBhYmlsaXR5IHRvIGJlIHNwZWNpZmljIGluIGV4dGVuZGVkIHJh bmdlDQogICBsb29rdXAgbWF5IG1ha2UgdGhpcyBtYXRjaGluZyBzY2hlbWUgYSBtb3JlIGFwcHJv cHJpYXRlIHJlcGxhY2VtZW50DQogICBmb3IgYmFzaWMgbWF0Y2hpbmcgdGhhbiB0aGUgZXh0ZW5k ZWQgcmFuZ2UgbWF0Y2hpbmcgc2NoZW1lLg0KDQoyLjIuMyAgU2NvcmVkIE1hdGNoaW5nDQoNCiAg IEluIHRoZSAic2NvcmVkIG1hdGNoaW5nIiBzY2hlbWUsIHRoZSBleHRlbmRlZCBsYW5ndWFnZSBy YW5nZSBhbmQgdGhlDQogICBsYW5ndWFnZSB0YWdzIGFyZSBwcmUtbm9ybWFsaXplZCBieSBtYXBw aW5nIGdyYW5kZmF0aGVyZWQgYW5kDQogICBvYnNvbGV0ZSB0YWdzIGludG8gbW9kZXJuIGVxdWl2 YWxlbnRzLg0KDQogICBUaGUgbGFuZ3VhZ2UgcmFuZ2UgYW5kIHRoZSBsYW5ndWFnZSB0YWdzIGFy ZSBub3JtYWxpemVkIGludG8NCiAgIHF1YWRydXBsZXMgb2YgdGhlIGZvcm0gKGxhbmd1YWdlLCBz Y3JpcHQsIGNvdW50cnksIHZhcmlhbnQpLCB3aGVyZQ0KICAgZXh0ZW5kZWQgbGFuZ3VhZ2UgaXMg Y29uc2lkZXJlZCBwYXJ0IG9mIGxhbmd1YWdlIGFuZCB4LXByaXZhdGUtY29kZXMNCiAgIGFyZSBj b25zaWRlcmVkIHBhcnQgb2YgdGhlIGxhbmd1YWdlIGlmIHRoZXkgYXJlIGluaXRpYWwgYW5kIHBh cnQgb2YNCiAgIHRoZSB2YXJpYW50IGlmIG5vdCBpbml0aWFsLiAgTWlzc2luZyBjb21wb25lbnRz IGFyZSBzZXQgdG8gIioiLiAgQW4NCiAgICIqIiBwYXR0ZXJuIGJlY29tZXMgdGhlIHF1YWRydXBs ZSAoIioiLCAiKiIsICIqIiwgIioiKS4NCg0KICAgRWFjaCBsYW5ndWFnZSB0YWcgIGJlaW5nIG1h dGNoZWQgb3IgZmlsdGVyZWQgaXMgYXNzaWduZWQgYSAicXVhbGl0eQ0KICAgdmFsdWUiIHN1Y2gg dGhhdCBoaWdoZXIgdmFsdWVzIGluZGljYXRlIGJldHRlciBtYXRjaGVzIGFuZCBsb3dlcg0KICAg dmFsdWVzIGluZGljYXRlIHdvcnNlIG9uZXMuICBJZiB0aGUgbGFuZ3VhZ2UgbWF0Y2hlcywgYWRk IDggdG8gdGhlDQogICBxdWFsaXR5IHZhbHVlLiAgSWYgdGhlIHNjcmlwdCBtYXRjaGVzLCBhZGQg NCB0byB0aGUgcXVhbGl0eSB2YWx1ZS4NCiAgIElmIHRoZSByZWdpb24gbWF0Y2hlcywgYWRkIDIg dG8gdGhlIHF1YWxpdHkgdmFsdWUuICBJZiB0aGUgdmFyaWFudA0KICAgbWF0Y2hlcywgYWRkIDEg dG8gdGhlIHF1YWxpdHkgdmFsdWUuICBFbGVtZW50cyBvZiB0aGUgcXVhZHJ1cGxlcyBhcmUNCiAg IGNvbnNpZGVyZWQgdG8gbWF0Y2ggaWYgdGhleSBhcmUgdGhlIHNhbWUgb3IgaWYgb25lIG9mIHRo ZW0gaXMgIioiLg0KDQogICBBIHZhbHVlIG9mIDE1IGlzIGEgcGVyZmVjdCBtYXRjaDsgMCBpcyBu byBtYXRjaCBhdCBhbGwuICBEaWZmZXJlbnQNCiAgIHZhbHVlcyBtYXkgYmUgbW9yZSBvciBsZXNz IGFwcHJvcHJpYXRlIGZvciBkaWZmZXJlbnQgYXBwbGljYXRpb25zIGFuZA0KICAgaW1wbGVtZW50 YXRpb25zIHNob3VsZCBwcm9iYWJseSBhbGxvdyB1c2VycyB0byBjaG9vc2UgdGhlIG1vc3QNCiAg IGFwcHJvcHJpYXRlIHNlbGVjdGlvbiB2YWx1ZS4NCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA5 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbGFuZ01hdGNoaW5nICAgICAgICAg ICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KMi4zICBNZWFuaW5nIG9mIExhbmd1YWdlIFRhZ3Mg YW5kIFJhbmdlcw0KDQogICBBIGxhbmd1YWdlIHRhZyBkZWZpbmVzIGEgbGFuZ3VhZ2UgYXMgc3Bv a2VuIChvciB3cml0dGVuLCBzaWduZWQgb3INCiAgIG90aGVyd2lzZSBzaWduYWxlZCkgYnkgaHVt YW4gYmVpbmdzIGZvciBjb21tdW5pY2F0aW9uIG9mIGluZm9ybWF0aW9uDQogICB0byBvdGhlciBo dW1hbiBiZWluZ3MuDQoNCiAgIElmIGEgbGFuZ3VhZ2UgdGFnIEIgY29udGFpbnMgbGFuZ3VhZ2Ug dGFnIEEgYXMgYSBwcmVmaXgsIHRoZW4gQiBpcw0KICAgdHlwaWNhbGx5ICJuYXJyb3dlciIgb3Ig Im1vcmUgc3BlY2lmaWMiIHRoYW4gQS4gRm9yIGV4YW1wbGUsICJ6aC0NCiAgIEhhbnQtVFciIGlz IG1vcmUgc3BlY2lmaWMgdGhhbiAiemgtSGFudCIuDQoNCiAgIFRoaXMgcmVsYXRpb25zaGlwIGlz IG5vdCBndWFyYW50ZWVkIGluIGFsbCBjYXNlczogc3BlY2lmaWNhbGx5LA0KICAgbGFuZ3VhZ2Vz IHRoYXQgYmVnaW4gd2l0aCB0aGUgc2FtZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFyZSBOT1QNCiAg IGd1YXJhbnRlZWQgdG8gYmUgbXV0dWFsbHkgaW50ZWxsaWdpYmxlLCBhbHRob3VnaCB0aGV5IG1h eSBiZS4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIHRhZyAiYXoiIHNoYXJlcyBhIHByZWZpeCB3aXRo IGJvdGggImF6LUxhdG4iDQogICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4g c2NyaXB0KSBhbmQgImF6LUN5cmwiDQogICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0aGUg Q3lyaWxsaWMgc2NyaXB0KS4gIEEgcGVyc29uIGZsdWVudCBpbg0KICAgb25lIHNjcmlwdCBtYXkg bm90IGJlIGFibGUgdG8gcmVhZCB0aGUgb3RoZXIsIGV2ZW4gdGhvdWdoIHRoZSB0ZXh0DQogICBt aWdodCBiZSBvdGhlcndpc2UgaWRlbnRpY2FsLiAgQ29udGVudCB0YWdnZWQgYXMgImF6IiBtb3N0 IHByb2JhYmx5DQogICBpcyB3cml0dGVuIGluIGp1c3Qgb25lIHNjcmlwdCBhbmQgdGh1cyBtaWdo dCBub3QgYmUgaW50ZWxsaWdpYmxlIHRvIGENCiAgIHJlYWRlciBmYW1pbGlhciB3aXRoIHRoZSBv dGhlciBzY3JpcHQuDQoNCiAgIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdGFnIGFuZCB0 aGUgaW5mb3JtYXRpb24gaXQgcmVsYXRlcyB0byBpcw0KICAgZGVmaW5lZCBieSB0aGUgc3RhbmRh cmQgZGVzY3JpYmluZyB0aGUgY29udGV4dCBpbiB3aGljaCBpdCBhcHBlYXJzLg0KICAgQWNjb3Jk aW5nbHksIHRoaXMgc2VjdGlvbiBjYW4gb25seSBnaXZlIHBvc3NpYmxlIGV4YW1wbGVzIG9mIGl0 cw0KICAgdXNhZ2UuDQoNCiAgIG8gIEZvciBhIHNpbmdsZSBpbmZvcm1hdGlvbiBvYmplY3QsIHRo ZSBhc3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MNCiAgICAgIG1pZ2h0IGJlIGludGVycHJldGVkIGFz IHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHRoYXQgaXMgcmVxdWlyZWQgZm9yDQogICAgICBhIGNvbXBs ZXRlIGNvbXByZWhlbnNpb24gb2YgdGhlIGNvbXBsZXRlIG9iamVjdC4gIEV4YW1wbGU6IFBsYWlu DQogICAgICB0ZXh0IGRvY3VtZW50cy4NCg0KICAgbyAgRm9yIGFuIGFnZ3JlZ2F0aW9uIG9mIGlu Zm9ybWF0aW9uIG9iamVjdHMsIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlDQogICAgICB0YWdzIGNv dWxkIGJlIHRha2VuIGFzIHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHVzZWQgaW5zaWRlIGNvbXBvbmVu dHMNCiAgICAgIG9mIHRoYXQgYWdncmVnYXRpb24uICBFeGFtcGxlczogRG9jdW1lbnQgc3RvcmVz IGFuZCBsaWJyYXJpZXMuDQoNCiAgIG8gIEZvciBpbmZvcm1hdGlvbiBvYmplY3RzIHdob3NlIHB1 cnBvc2UgaXMgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZXMsDQogICAgICB0aGUgYXNzb2NpYXRlZCBs YW5ndWFnZSB0YWdzIGNvdWxkIGJlIHJlZ2FyZGVkIGFzIGEgaGludCB0aGF0IHRoZQ0KICAgICAg Y29udGVudCBpcyBwcm92aWRlZCBpbiBzZXZlcmFsIGxhbmd1YWdlcywgYW5kIHRoYXQgb25lIGhh cyB0bw0KICAgICAgaW5zcGVjdCBlYWNoIG9mIHRoZSBhbHRlcm5hdGl2ZXMgaW4gb3JkZXIgdG8g ZmluZCBpdHMgbGFuZ3VhZ2Ugb3INCiAgICAgIGxhbmd1YWdlcy4gIEluIHRoaXMgY2FzZSwgdGhl IHByZXNlbmNlIG9mIG11bHRpcGxlIHRhZ3MgbWlnaHQgbm90DQogICAgICBtZWFuIHRoYXQgb25l IG5lZWRzIHRvIGJlIG11bHRpLWxpbmd1YWwgdG8gZ2V0IGNvbXBsZXRlDQogICAgICB1bmRlcnN0 YW5kaW5nIG9mIHRoZSBkb2N1bWVudC4gIEV4YW1wbGU6IE1JTUUgbXVsdGlwYXJ0Lw0KICAgICAg YWx0ZXJuYXRpdmUuDQoNCiAgIG8gIEluIG1hcmt1cCBsYW5ndWFnZXMsIHN1Y2ggYXMgSFRNTCBh bmQgWE1MLCBsYW5ndWFnZSBpbmZvcm1hdGlvbg0KICAgICAgY2FuIGJlIGFkZGVkIHRvIGVhY2gg cGFydCBvZiB0aGUgZG9jdW1lbnQgaWRlbnRpZmllZCBieSB0aGUgbWFya3VwDQogICAgICBzdHJ1 Y3R1cmUgKGluY2x1ZGluZyB0aGUgd2hvbGUgZG9jdW1lbnQgaXRzZWxmKS4gIEZvciBleGFtcGxl LCBvbmUNCiAgICAgIGNvdWxkIHdyaXRlIDxzcGFuIGxhbmc9IkZSIj5DJ2VzdCBsYSB2aWUuPC9z cGFuPiBpbnNpZGUgYQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3Zl bWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUN Cg0KDQogICAgICBOb3J3ZWdpYW4gZG9jdW1lbnQ7IHRoZSBOb3J3ZWdpYW4tc3BlYWtpbmcgdXNl ciBjb3VsZCB0aGVuIGFjY2Vzcw0KICAgICAgYSBGcmVuY2gtTm9yd2VnaWFuIGRpY3Rpb25hcnkg dG8gZmluZCBvdXQgd2hhdCB0aGUgbWFya2VkIHNlY3Rpb24NCiAgICAgIG1lYW50LiAgSWYgdGhl IHVzZXIgd2VyZSBsaXN0ZW5pbmcgdG8gdGhhdCBkb2N1bWVudCB0aHJvdWdoIGENCiAgICAgIHNw ZWVjaCBzeW50aGVzaXMgaW50ZXJmYWNlLCB0aGlzIGZvcm1hdGlvbiBjb3VsZCBiZSB1c2VkIHRv IHNpZ25hbA0KICAgICAgdGhlIHN5bnRoZXNpemVyIHRvIGFwcHJvcHJpYXRlbHkgYXBwbHkgRnJl bmNoIHRleHQtdG8tc3BlZWNoDQogICAgICBwcm9udW5jaWF0aW9uIHJ1bGVzIHRvIHRoYXQgc3Bh biBvZiB0ZXh0LCBpbnN0ZWFkIG9mIG1pc2FwcGx5aW5nDQogICAgICB0aGUgTm9yd2VnaWFuIHJ1 bGVzLg0KDQoNCjIuNCAgQ2hvb3NpbmcgQmV0d2VlbiBBbHRlcm5hdGUgTWF0Y2hpbmcgU2NoZW1l cw0KDQogICBJbXBsZW1lbnRhdGlvbnMgTUFZIGNob29zZSB0byBpbXBsZW1lbnQgZGlmZmVyZW50 IHN0eWxlcyBvZiBtYXRjaGluZw0KICAgZm9yIGRpZmZlcmVudCBraW5kcyBvZiBwcm9jZXNzaW5n LiAgRm9yIGV4YW1wbGUsIGFuIGltcGxlbWVudGF0aW9uDQogICBjb3VsZCB0cmVhdCBhbiBhYnNl bnQgc2NyaXB0IHN1YnRhZyBhcyBhICJ3aWxkY2FyZCIgZmllbGQ7IHRodXMNCiAgICJhei1BWiIg d291bGQgbWF0Y2ggImF6LUFaIiwgImF6LUN5cmwtQVoiLCAiYXotTGF0bi1BWiIsIGV0Yy4gYnV0 IG5vdA0KICAgImF6IiAodGhpcyBpcyBleHRlbmRlZCByYW5nZSBsb29rdXApLiAgSWYgb25lIGl0 ZW0gaXMgdG8gYmUgY2hvc2VuLA0KICAgdGhlIGltcGxlbWVudGF0aW9uIGNvdWxkIHBpY2sgYW1v bmcgdGhvc2UgbWF0Y2hlcyBiYXNlZCBvbiBvdGhlcg0KICAgaW5mb3JtYXRpb24sIHN1Y2ggYXMg dGhlIG1vc3QgbGlrZWx5IHNjcmlwdCB1c2VkIGluIHRoZSBsYW5ndWFnZS8NCiAgIHJlZ2lvbiBp biBxdWVzdGlvbiBvciB0aGUgc2NyaXB0IHVzZWQgYnkgb3RoZXIgY29udGVudCBzZWxlY3RlZC4N Cg0KICAgQmVjYXVzZSB0aGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgY2Fubm90IGJlIGFic2Vu dCBpbiBhIGxhbmd1YWdlDQogICB0YWcsIHRoZSAnVU5EJyBzdWJ0YWcgbWF5IHNvbWV0aW1lcyBi ZSB1c2VkIGFzIGEgJ3dpbGRjYXJkJyBpbiBiYXNpYw0KICAgbWF0Y2hpbmcuICBGb3IgZXhhbXBs ZSwgaW4gYSBxdWVyeSB3aGVyZSB5b3Ugd2FudCB0byBzZWxlY3QgYWxsDQogICBsYW5ndWFnZSB0 YWdzIHRoYXQgY29udGFpbiAnTGF0bicgYXMgdGhlIHNjcmlwdCBjb2RlIGFuZCAnQVonIGFzIHRo ZQ0KICAgcmVnaW9uIGNvZGUsIHlvdSBjb3VsZCB1c2UgdGhlIHJhbmdlICJ1bmQtTGF0bi1BWiIu ICBUaGlzIHJlcXVpcmVzIGFuDQogICBpbXBsZW1lbnRhdGlvbiB0byBleGFtaW5lIHRoZSBhY3R1 YWwgdmFsdWVzIG9mIHRoZSBzdWJ0YWdzLCB0aG91Z2guDQogICBUaGUgbWF0Y2hpbmcgc2NoZW1l cyBkZXNjcmliZWQgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQgZG8gbm90DQogICByZXF1aXJl IGltcGxlbWVudGF0aW9ucyB0byBleGFtaW5lIHRoZSB2YWx1ZXMgc3VwcGxpZWQgYW5kLCBleGNl cHQNCiAgIGZvciBzY29yZWQgbWF0Y2hpbmcsIHRoZXkgZG8gbm90IHJlcXVpcmUgYWNjZXNzIHRv IHRoZSBMYW5ndWFnZQ0KICAgU3VidGFnIFJlZ2lzdHJ5IG5vciB0aGUgdXNlIG9mIHZhbGlkIHN1 YnRhZ3MgaW4gbGFuZ3VhZ2UgdGFncyBvcg0KICAgcmFuZ2VzLiAgVGhpcyBoYXMgZ3JlYXQgYmVu ZWZpdCBmb3Igc3BlZWQgYW5kIHNpbXBsaWNpdHkgb2YNCiAgIGltcGxlbWVudGF0aW9uLg0KDQog ICBJbXBsZW1lbnRhdGlvbnMgbWF5IGFsc28gd2lzaCB0byB1c2Ugc2VtYW50aWMgaW5mb3JtYXRp b24gZXh0ZXJuYWwgdG8NCiAgIHRoZSBsYW5nYXVnZSB0YWdzIHdoZW4gcGVyZm9ybWluZyBmYWxs YmFjay4gIEZvciBleGFtcGxlLCB0aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3VidGFncyAnbm4n IChOeW5vcnNrIE5vcndlZ2lhbikgYW5kICduYicgKEJva21hbCBOb3J3ZWdpYW4pDQogICBtaWdo dCBib3RoIGJlIHVzZWZ1bGx5IG1hdGNoZWQgdG8gdGhlIG1vcmUgZ2VuZXJhbCBzdWJ0YWcgJ25v Jw0KICAgKE5vcndlZ2lhbikuICBPciBhbiBhcHBsaWNhdGlvbiBtaWdodCBpbmZlciB0aGF0IGNv bnRlbnQgbGFiZWxlZA0KICAgInpoLUNOIiBpcyBtb3JlbHkgbGlrZWx5IHRvIG1hdGNoIHRoZSBy YW5nZSAiemgtSGFucyIgdGhhbiBlcXVpdmFsZW50DQogICBjb250ZW50IGxhYmVsZWQgInpoLVRX Ii4NCg0KMi41ICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncw0KDQogICBQ cml2YXRlLXVzZSBzdWJ0YWdzIHJlcXVpcmUgcHJpdmF0ZSBhZ3JlZW1lbnQgYmV0d2VlbiB0aGUg cGFydGllcw0KICAgdGhhdCBpbnRlbmQgdG8gdXNlIG9yIGV4Y2hhbmdlIGxhbmd1YWdlIHRhZ3Mg dGhhdCB1c2UgdGhlbSBhbmQgZ3JlYXQNCiAgIGNhdXRpb24gc2hvdWxkIGJlIHVzZWQgaW4gZW1w bG95aW5nIHRoZW0gaW4gY29udGVudCBvciBwcm90b2NvbHMNCiAgIGludGVuZGVkIGZvciBnZW5l cmFsIHVzZS4gIFByaXZhdGUtdXNlIHN1YnRhZ3MgYXJlIHNpbXBseSB1c2VsZXNzIGZvcg0KICAg aW5mb3JtYXRpb24gZXhjaGFuZ2Ugd2l0aG91dCBwcmlvciBhcnJhbmdlbWVudC4NCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAg ICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbGFuZ01hdGNo aW5nICAgICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KICAgVGhlIHZhbHVlIGFuZCBz ZW1hbnRpYyBtZWFuaW5nIG9mIHByaXZhdGUtdXNlIHRhZ3MgYW5kIG9mIHRoZSBzdWJ0YWdzDQog ICB1c2VkIHdpdGhpbiBzdWNoIGEgbGFuZ3VhZ2UgdGFnIGFyZSBub3QgZGVmaW5lZC4gIE1hdGNo aW5nIHByaXZhdGUNCiAgIHVzZSB0YWdzIHVzaW5nIGxhbmd1YWdlIHJhbmdlcyBvciBleHRlbmRl ZCBsYW5ndWFnZSByYW5nZXMgbWF5IHJlc3VsdA0KICAgaW4gdW5wcmVkaWN0YWJsZSBjb250ZW50 IGJlaW5nIHJldHVybmVkLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAg ICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbGFuZ01hdGNo aW5nICAgICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KMy4gIElBTkEgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBubyBuZXcgb3IgZXhpc3RpbmcgY29u c2lkZXJhdGlvbnMgZm9yIElBTkEuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAg ICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGxh bmdNYXRjaGluZyAgICAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCjQuICBDaGFuZ2Vz DQoNCiAgIFRoaXMgaXMgdGhlIGZpcnN0IHZlcnNpb24gb2YgdGhpcyBkb2N1bWVudC4gIENoYW5n ZXMgZnJvbSB0aGUNCiAgIHJlZmVyZW5jZSB3b3JrIChkcmFmdC1waGlsbGlwcy1tYXRjaGluZy0w MCkgYXJlIHRvbyBudW1lcmlvdXMgdG8NCiAgIHJlY29yZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAx NCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQo1 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhlIG9ubHkgc2VjdXJpdHkgaXNzdWUg dGhhdCBoYXMgYmVlbiByYWlzZWQgd2l0aCBsYW5ndWFnZSB0YWdzIHNpbmNlDQogICB0aGUgcHVi bGljYXRpb24gb2YgUkZDIDE3NjYsIHdoaWNoIHN0YXRlZCB0aGF0ICJTZWN1cml0eSBpc3N1ZXMg YXJlDQogICBiZWxpZXZlZCB0byBiZSBpcnJlbGV2YW50IHRvIHRoaXMgbWVtbyIsIGlzIGEgY29u Y2VybiB3aXRoIGxhbmd1YWdlDQogICByYW5nZXMgdXNlZCBpbiBjb250ZW50IG5lZ290aWF0aW9u IC0gdGhhdCB0aGV5IG1heSBiZSB1c2VkIHRvIGluZmVyDQogICB0aGUgbmF0aW9uYWxpdHkgb2Yg dGhlIHNlbmRlciwgYW5kIHRodXMgaWRlbnRpZnkgcG90ZW50aWFsIHRhcmdldHMNCiAgIGZvciBz dXJ2ZWlsbGFuY2UuDQoNCiAgIFRoaXMgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIGdlbmVyYWwg cHJvYmxlbSB0aGF0IGFueXRoaW5nIHlvdSBzZW5kDQogICBpcyB2aXNpYmxlIHRvIHRoZSByZWNl aXZpbmcgcGFydHkuICBJdCBpcyB1c2VmdWwgdG8gYmUgYXdhcmUgdGhhdA0KICAgc3VjaCBjb25j ZXJucyBjYW4gZXhpc3QgaW4gc29tZSBjYXNlcy4NCg0KICAgVGhlIGV2YWx1YXRpb24gb2YgdGhl IGV4YWN0IG1hZ25pdHVkZSBvZiB0aGUgdGhyZWF0LCBhbmQgYW55IHBvc3NpYmxlDQogICBjb3Vu dGVybWVhc3VyZXMsIGlzIGxlZnQgdG8gZWFjaCBhcHBsaWNhdGlvbiBwcm90b2NvbC4NCg0KICAg QWx0aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gb2YgdmFsaWQgc3VidGFncyBmb3IgYW4gZXh0ZW5z aW9uIE1VU1QgYmUNCiAgIGF2YWlsYWJsZSBvdmVyIHRoZSBJbnRlcm5ldCwgaW1wbGVtZW50YXRp b25zIFNIT1VMRCBOT1QgbWVjaGFuaWNhbGx5DQogICBkZXBlbmQgb24gaXQgYmVpbmcgYWx3YXlz IGFjY2Vzc2libGUsIHRvIHByZXZlbnQgZGVuaWFsLW9mLXNlcnZpY2UNCiAgIGF0dGFja3MuDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAg ICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbGFu Z01hdGNoaW5nICAgICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KNi4gIENoYXJhY3Rl ciBTZXQgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhlIHN5bnRheCBpbiB0aGlzIGRvY3VtZW50IHJl cXVpcmVzIHRoYXQgbGFuZ3VhZ2UgcmFuZ2VzIHVzZSBvbmx5DQogICB0aGUgY2hhcmFjdGVycyBB LVosIGEteiwgMC05LCBhbmQgSFlQSEVOLU1JTlVTIGxlZ2FsIGluIGxhbmd1YWdlDQogICB0YWdz LiAgVGhlc2UgY2hhcmFjdGVycyBhcmUgcHJlc2VudCBpbiBtb3N0IGNoYXJhY3RlciBzZXRzLCBz bw0KICAgcHJlc2VudGF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgc2hvdWxkIG5vdCBoYXZlIGFueSBj aGFyYWN0ZXIgc2V0DQogICBpc3N1ZXMuDQoNCiAgIFJlbmRlcmluZyBvZiBjaGFyYWN0ZXJzIGJh c2VkIG9uIHRoZSBjb250ZW50IG9mIGEgbGFuZ3VhZ2UgdGFnIGlzIG5vdA0KICAgYWRkcmVzc2Vk IGluIHRoaXMgbWVtby4gIEhpc3RvcmljYWxseSwgc29tZSBsYW5ndWFnZXMgaGF2ZSByZWxpZWQg b24NCiAgIHRoZSB1c2Ugb2Ygc3BlY2lmaWMgY2hhcmFjdGVyIHNldHMgb3Igb3RoZXIgaW5mb3Jt YXRpb24gaW4gb3JkZXIgdG8NCiAgIGluZmVyIGhvdyBhIHNwZWNpZmljIGNoYXJhY3RlciBzaG91 bGQgYmUgcmVuZGVyZWQgKG5vdGFibHkgdGhpcw0KICAgYXBwbGllcyB0byBsYW5ndWFnZSBhbmQg Y3VsdHVyZSBzcGVjaWZpYyB2YXJpYXRpb25zIG9mIEhhbiBpZGVvZ3JhcGhzDQogICBhcyB1c2Vk IGluIEphcGFuZXNlLCBDaGluZXNlLCBhbmQgS29yZWFuKS4gIFdoZW4gbGFuZ3VhZ2UgdGFncyBh cmUNCiAgIGFwcGxpZWQgdG8gc3BhbnMgb2YgdGV4dCwgcmVuZGVyaW5nIGVuZ2luZXMgbWF5IHVz ZSB0aGF0IGluZm9ybWF0aW9uDQogICBpbiBkZWNpZGluZyB3aGljaCBmb250IHRvIHVzZSBpbiB0 aGUgYWJzZW5jZSBvZiBvdGhlciBpbmZvcm1hdGlvbiwNCiAgIHBhcnRpY3VsYXJseSB3aGVyZSBs YW5ndWFnZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5nIHRyYWRpdGlvbnMgdXNlIHRoZQ0KICAgc2Ft ZSBjaGFyYWN0ZXJzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAgICAgICAgICAgTWF5IDIw MDUNCg0KDQo3LiAgUmVmZXJlbmNlcw0KDQo3LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAg IFsxXSAgIFBoaWxsaXBzLCBBLiwgRWQuIGFuZCBNLiBEYXZpcywgRWQuLCAiVGFncyBmb3IgdGhl DQogICAgICAgICBJZGVudGlmaWNhdGlvbiBvZiBMYW5ndWFnZXMgKEludGVybmV0LURyYWZ0KSIs IEZlYnJ1YXJ5IDIwMDUsIDwNCiAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KICAgICAgICAgZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LTAxLnR4dD4uDQoNCiAg IFsyXSAgIEhhcmRjYXN0bGUtS2lsbGUsIFMuLCAiTWFwcGluZyBiZXR3ZWVuIFguNDAwKDE5ODgp IC8gSVNPIDEwMDIxDQogICAgICAgICBhbmQgUkZDIDgyMiIsIFJGQyAxMzI3LCBNYXkgMTk5Mi4N Cg0KICAgWzNdICAgQm9yZW5zdGVpbiwgTi4gYW5kIE4uIEZyZWVkLCAiTUlNRSAoTXVsdGlwdXJw b3NlIEludGVybmV0IE1haWwNCiAgICAgICAgIEV4dGVuc2lvbnMpIFBhcnQgT25lOiBNZWNoYW5p c21zIGZvciBTcGVjaWZ5aW5nIGFuZCBEZXNjcmliaW5nDQogICAgICAgICB0aGUgRm9ybWF0IG9m IEludGVybmV0IE1lc3NhZ2UgQm9kaWVzIiwgUkZDIDE1MjEsDQogICAgICAgICBTZXB0ZW1iZXIg MTk5My4NCg0KICAgWzRdICAgSG92ZXksIFIuIGFuZCBTLiBCcmFkbmVyLCAiVGhlIE9yZ2FuaXph dGlvbnMgSW52b2x2ZWQgaW4gdGhlDQogICAgICAgICBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzIiwg QkNQIDExLCBSRkMgMjAyOCwgT2N0b2JlciAxOTk2Lg0KDQogICBbNV0gICBCcmFkbmVyLCBTLiwg IktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQNCiAgICAg ICAgIExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFs2XSAgIEZy ZWVkLCBOLiBhbmQgSy4gTW9vcmUsICJNSU1FIFBhcmFtZXRlciBWYWx1ZSBhbmQgRW5jb2RlZCBX b3JkDQogICAgICAgICBFeHRlbnNpb25zOiBDaGFyYWN0ZXIgU2V0cywgTGFuZ3VhZ2VzLCBhbmQg Q29udGludWF0aW9ucyIsDQogICAgICAgICBSRkMgMjIzMSwgTm92ZW1iZXIgMTk5Ny4NCg0KICAg WzddICAgQ3JvY2tlciwgRC4sIEVkLiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYgZm9y IFN5bnRheA0KICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgMjIzNCwgTm92ZW1i ZXIgMTk5Ny4NCg0KICAgWzhdICAgQmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywgUi4sIGFuZCBM LiBNYXNpbnRlciwgIlVuaWZvcm0NCiAgICAgICAgIFJlc291cmNlIElkZW50aWZpZXJzIChVUkkp OiBHZW5lcmljIFN5bnRheCIsIFJGQyAyMzk2LA0KICAgICAgICAgQXVndXN0IDE5OTguDQoNCiAg IFs5XSAgIE5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICJHdWlkZWxpbmVzIGZvciBXcml0 aW5nIGFuIElBTkENCiAgICAgICAgIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsIEJD UCAyNiwgUkZDIDI0MzQsDQogICAgICAgICBPY3RvYmVyIDE5OTguDQoNCiAgIFsxMF0gIEZpZWxk aW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwgTWFzaW50ZXIsIEwu LA0KICAgICAgICAgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICJIeXBlcnRleHQgVHJh bnNmZXIgUHJvdG9jb2wgLS0NCiAgICAgICAgIEhUVFAvMS4xIiwgUkZDIDI2MTYsIEp1bmUgMTk5 OS4NCg0KICAgWzExXSAgQ2FycGVudGVyLCBCLiwgQmFrZXIsIEYuLCBhbmQgTS4gUm9iZXJ0cywg Ik1lbW9yYW5kdW0gb2YNCiAgICAgICAgIFVuZGVyc3RhbmRpbmcgQ29uY2VybmluZyB0aGUgVGVj aG5pY2FsIFdvcmsgb2YgdGhlIEludGVybmV0DQogICAgICAgICBBc3NpZ25lZCBOdW1iZXJzIEF1 dGhvcml0eSIsIFJGQyAyODYwLCBKdW5lIDIwMDAuDQoNCiAgIFsxMl0gIFllcmdlYXUsIEYuLCAi VVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIElTTyAxMDY0NiIsDQogICAgICAgICBT VEQgNjMsIFJGQyAzNjI5LCBOb3ZlbWJlciAyMDAzLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMTddDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAg ICAgICAgICAgTWF5IDIwMDUNCg0KDQo3LjIgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAg WzEzXSAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklT TyA2MzktDQogICAgICAgICAxOjIwMDIsIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2Yg bmFtZXMgb2YgbGFuZ3VhZ2VzIC0tDQogICAgICAgICBQYXJ0IDE6IEFscGhhLTIgY29kZSIsIElT TyBTdGFuZGFyZCA2MzksIDIwMDIuDQoNCiAgIFsxNF0gIEludGVybmF0aW9uYWwgT3JnYW5pemF0 aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gNjM5LTI6MTk5OA0KICAgICAgICAgLSBDb2Rl cyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGxhbmd1YWdlcyAtLSBQYXJ0IDI6 DQogICAgICAgICBBbHBoYS0zIGNvZGUgLSBlZGl0aW9uIDEiLCBBdWd1c3QgMTk4OC4NCg0KICAg WzE1XSAgSVNPIFRDNDYvV0czLCAiSVNPIDE1OTI0OjIwMDMgKEUvRikgLSBDb2RlcyBmb3IgdGhl DQogICAgICAgICByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBzY3JpcHRzIiwgSmFudWFyeSAy MDA0Lg0KDQogICBbMTZdICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRp emF0aW9uLCAiQ29kZXMgZm9yIHRoZQ0KICAgICAgICAgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMg b2YgY291bnRyaWVzLCAzcmQgZWRpdGlvbiIsDQogICAgICAgICBJU08gU3RhbmRhcmQgMzE2Niwg QXVndXN0IDE5ODguDQoNCiAgIFsxN10gIFN0YXRpc3RpY2FsIERpdmlzaW9uLCBVbml0ZWQgTmF0 aW9ucywgIlN0YW5kYXJkIENvdW50cnkgb3IgQXJlYQ0KICAgICAgICAgQ29kZXMgZm9yIFN0YXRp c3RpY2FsIFVzZSIsIFVOIFN0YW5kYXJkIENvdW50cnkgb3IgQXJlYSBDb2Rlcw0KICAgICAgICAg Zm9yIFN0YXRpc3RpY2FsIFVzZSwgUmV2aXNpb24gNCAoVW5pdGVkIE5hdGlvbnMgcHVibGljYXRp b24sDQogICAgICAgICBTYWxlcyBOby4gOTguWFZJSS45LCBKdW5lIDE5OTkuDQoNCiAgIFsxOF0g IEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mIExhbmd1YWdl cyIsDQogICAgICAgICBSRkMgMTc2NiwgTWFyY2ggMTk5NS4NCg0KICAgWzE5XSAgQWx2ZXN0cmFu ZCwgSC4sICJUYWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2YgTGFuZ3VhZ2VzIiwNCiAgICAg ICAgIEJDUCA0NywgUkZDIDMwNjYsIEphbnVhcnkgMjAwMS4NCg0KICAgWzIwXSAgS2x5bmUsIEcu IGFuZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1lIG9uIHRoZSBJbnRlcm5ldDoNCiAgICAgICAg IFRpbWVzdGFtcHMiLCBSRkMgMzMzOSwgSnVseSAyMDAyLg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nl cw0KDQogICBBZGRpc29uIFBoaWxsaXBzIChlZGl0b3IpDQogICBRdWVzdCBTb2Z0d2FyZQ0KDQog ICBFbWFpbDogYWRkaXNvbiBkb3QgcGhpbGxpcHMgYXQgcXVlc3QgZG90IGNvbQ0KDQoNCiAgIE1h cmsgRGF2aXMgKGVkaXRvcikNCiAgIElCTQ0KDQogICBFbWFpbDogbWFyayBkb3QgZGF2aXMgYXQg aWJtIGRvdCBjb20NCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJl cyBOb3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICBsYW5nTWF0Y2hpbmcgICAgICAgICAgICAgICAgICAgICAgTWF5 IDIwMDUNCg0KDQpBcHBlbmRpeCBBLiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBBbnkgbGlzdCBv ZiBjb250cmlidXRvcnMgaXMgYm91bmQgdG8gYmUgaW5jb21wbGV0ZTsgcGxlYXNlIHJlZ2FyZCB0 aGUNCiAgIGZvbGxvd2luZyBhcyBvbmx5IGEgc2VsZWN0aW9uIGZyb20gdGhlIGdyb3VwIG9mIHBl b3BsZSB3aG8gaGF2ZQ0KICAgY29udHJpYnV0ZWQgdG8gbWFrZSB0aGlzIGRvY3VtZW50IHdoYXQg aXQgaXMgdG9kYXkuDQoNCiAgIFRoZSBjb250cmlidXRvcnMgdG8gUkZDIDMwNjYgYW5kIFJGQyAx NzY2LCB0aGUgcHJlY3Vyc29ycyBvZiB0aGlzDQogICBkb2N1bWVudCwgbWFkZSBlbm9ybW91cyBj b250cmlidXRpb25zIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkgdG8gdGhpcw0KICAgZG9jdW1lbnQg YW5kIGFyZSBnZW5lcmFsbHkgcmVzcG9uc2libGUgZm9yIHRoZSBzdWNjZXNzIG9mIGxhbmd1YWdl DQogICB0YWdzLg0KDQogICBUaGUgZm9sbG93aW5nIHBlb3BsZSAoaW4gYWxwaGFiZXRpY2FsIG9y ZGVyKSBjb250cmlidXRlZCB0byB0aGlzDQogICBkb2N1bWVudCBvciB0byBSRkNzIDE3NjYgYW5k IDMwNjY6DQoNCiAgIEdsZW5uIEFkYW1zLCBIYXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCwgVGltIEJl cm5lcnMtTGVlLCBNYXJjIEJsYW5jaGV0LA0KICAgTmF0aGFuaWVsIEJvcmVuc3RlaW4sIEVyaWMg QnJ1bm5lciwgU2VhbiBNLiBCdXJrZSwgSmVyZW15IENhcnJvbGwsDQogICBKb2huIENsZXdzLCBK aW0gQ29ua2xpbiwgUGV0ZXIgQ29uc3RhYmxlLCBKb2huIENvd2FuLCBNYXJrIENyaXNwaW4sDQog ICBEYXZlIENyb2NrZXIsIE1hcnRpbiBEdWVyc3QsIE1pY2hhZWwgRXZlcnNvbiwgRG91ZyBFd2Vs bCwgTmVkIEZyZWVkLA0KICAgVGltIEdvb2R3aW4sIERpcmstV2lsbGVtIHZhbiBHdWxpaywgTWFy aW9uIEd1bm4sIEpvZWwgSGFscHJlbiwNCiAgIEVsbGlvdHRlIFJ1c3R5IEhhcm9sZCwgUGF1bCBI b2ZmbWFuLCBSaWNoYXJkIElzaGlkYSwgT2xsZSBKYXJuZWZvcnMsDQogICBLZW50IEthcmxzc29u LCBKb2huIEtsZW5zaW4sIEFsYWluIExhQm9udGUsIEVyaWMgTWFkZXIsIEtlaXRoIE1vb3JlLA0K ICAgQ2hyaXMgTmV3bWFuLCBNYXNhdGFrYSBPaHRhLCBHZW9yZ2UgUmhvdGVuLCBNYXJrdXMgU2No ZXJlciwgS2VsZCBKb3JuDQogICBTaW1vbnNlbiwgVGhpZXJyeSBTb3VyYmllciwgT3R0byBTdG9s eiwgVGV4IFRleGluLCBBbmRyZWEgVmluZSwgUmh5cw0KICAgV2VhdGhlcmxleSwgTWlzaGEgV29s ZiwgRnJhbmNvaXMgWWVyZ2VhdSBhbmQgbWFueSwgbWFueSBvdGhlcnMuDQoNCiAgIFZlcnkgc3Bl Y2lhbCB0aGFua3MgbXVzdCBnbyB0byBIYXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCwgd2hvDQogICBv cmlnaW5hdGVkIFJGQ3MgMTc2NiBhbmQgMzA2NiwgYW5kIHdpdGhvdXQgd2hvbSB0aGlzIGRvY3Vt ZW50IHdvdWxkDQogICBub3QgaGF2ZSBiZWVuIHBvc3NpYmxlLiAgU3BlY2lhbCB0aGFua3MgbXVz dCBnbyB0byBNaWNoYWVsIEV2ZXJzb24sDQogICB3aG8gaGFzIHNlcnZlZCBhcyBsYW5ndWFnZSB0 YWcgcmV2aWV3ZXIgZm9yIGFsbW9zdCB0aGUgY29tcGxldGUNCiAgIHBlcmlvZCBzaW5jZSB0aGUg cHVibGljYXRpb24gb2YgUkZDIDE3NjYuICBTcGVjaWFsIHRoYW5rcyB0byBEb3VnDQogICBFd2Vs bCwgZm9yIGhpcyBwcm9kdWN0aW9uIG9mIHRoZSBmaXJzdCBjb21wbGV0ZSBzdWJ0YWcgcmVnaXN0 cnksIGFuZA0KICAgaGlzIHdvcmsgaW4gcHJvZHVjaW5nIGEgdGVzdCBwYXJzZXIgZm9yIHZlcmlm eWluZyBsYW5ndWFnZSB0YWdzLg0KDQogICBGb3IgdGhpcyBwYXJ0aWN1bGFyIGRvY3VtZW50LCBK b2huIENvd2FuIG9yaWdpbmF0ZWQgdGhlIHNjaGVtZQ0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24g Mi4yLjMuICBNYXJrIERhdmlzIG9yaWdpbmF0ZWQgdGhlIHNjaGVtZQ0KICAgZGVzY3JpYmVkIGlu IHRoZSBTZWN0aW9uIDIuMS4yLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAg W1BhZ2UgMTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsYW5nTWF0Y2hpbmcg ICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkg U3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUg dmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRz IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8g dGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4N CiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRl ciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRv ZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZv cnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBw cm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUN CiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Ns b3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNl cyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0K ICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9u IGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRl cnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJv bSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYu b3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBi cmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRl bnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5 IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0 aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRG IGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpEaXNjbGFpbWVyIG9mIFZhbGlkaXR5DQoN CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFy ZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBU SEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkg KElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVOR0lO RUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1Q TElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQg VEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBB TlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU WSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpDb3B5cmlnaHQgU3Rh dGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLiAg VGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQg cmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZA0KICAgZXhjZXB0IGFzIHNldCBm b3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KDQpB Y2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBp cyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAgICAg ICAgICAgICBbUGFnZSAyMF0NCgwNCg== ------_=_NextPart_001_01C55A38.EF141F5F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C55A38.EF141F5F-- From ltru-bounces@lists.ietf.org Mon May 16 15:16:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl4M-00018x-2M; Mon, 16 May 2005 15:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl4K-00018h-9G; Mon, 16 May 2005 15:16:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26786; Mon, 16 May 2005 15:15:55 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlKr-00017I-69; Mon, 16 May 2005 15:33:06 -0400 Received: from wamui05.slb.atl.earthlink.net ([192.168.167.43]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DXl48-000641-00; Mon, 16 May 2005 15:15:48 -0400 Message-ID: <9118876.1116270948081.JavaMail.root@wamui05.slb.atl.earthlink.net> Date: Mon, 16 May 2005 12:15:47 -0700 (GMT-07:00) From: Randy Presuhn To: Addison Phillips , internet-drafts@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: [WG I-D Submission] draft-ietf-ltru-matching-00 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - As ltru co-chair, I approve this -00 draft submission. Randy -----Original Message----- From: Addison Phillips Sent: May 16, 2005 10:01 AM To: internet-drafts@ietf.org Cc: Mark Davis , Martin Duerst , Randy Presuhn , ltru@ietf.org Subject: [WG I-D Submission] draft-ietf-ltru-matching-00 Dear editor, Please find attached in text format the first (-00) draft of the LTRU working group I-D "draft-ietf-ltru-matching". The chairs (Martin Duerst and Randy Presuhn) have been copied on this message in order to forward their approval of this first draft. Best Regards (for the editors) Addison Addison P. Phillips Globalization Architect, Quest Software http://www.quest.com Chair, W3C Internationalization Core Working Group http://www.w3.org/International Internationalization is not a feature. It is an architecture. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 16 22:26:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXrnI-0007tS-KV; Mon, 16 May 2005 22:26:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXrnG-0007tD-Ml; Mon, 16 May 2005 22:26:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00301; Mon, 16 May 2005 22:26:44 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXs3q-0004Tu-9x; Mon, 16 May 2005 22:44:00 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j4H2QKm16120; Tue, 17 May 2005 11:26:20 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 6445a4fc_c67c_11d9_9bfa_0030482532aa_28273; Tue, 17 May 2005 11:35:54 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0068D6; 17 May 05 11:29:11 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 17 May 05 11:28:47 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0068D3; 17 May 05 11:28:41 +0900 Message-Id: <6.0.0.20.2.20050517112105.07a14270@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 17 May 2005 11:21:38 +0900 To: Randy Presuhn , Addison Phillips , internet-drafts@ietf.org From: Martin Duerst In-Reply-To: <9118876.1116270948081.JavaMail.root@wamui05.slb.atl.earthl ink.net> References: <9118876.1116270948081.JavaMail.root@wamui05.slb.atl.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: [WG I-D Submission] draft-ietf-ltru-matching-00 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Given Randy's approval, I don't think my approval is needed, but just in case, I also approve publication of this draft. Regards, Martin. At 04:15 05/05/17, Randy Presuhn wrote: >Hi - > >As ltru co-chair, I approve this -00 draft submission. > >Randy > >-----Original Message----- >From: Addison Phillips >Sent: May 16, 2005 10:01 AM >To: internet-drafts@ietf.org >Cc: Mark Davis , Martin Duerst , > Randy Presuhn , ltru@ietf.org >Subject: [WG I-D Submission] draft-ietf-ltru-matching-00 > >Dear editor, > >Please find attached in text format the first (-00) draft of the LTRU >working group I-D "draft-ietf-ltru-matching". The chairs (Martin Duerst and >Randy Presuhn) have been copied on this message in order to forward their >approval of this first draft. > >Best Regards (for the editors) > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Chair, W3C Internationalization Core Working Group >http://www.w3.org/International > >Internationalization is not a feature. >It is an architecture. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 02:35:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvgK-0003YR-H6; Tue, 17 May 2005 02:35:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvgJ-0003YD-5D for ltru@megatron.ietf.org; Tue, 17 May 2005 02:35:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13950 for ; Tue, 17 May 2005 02:35:53 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXvwz-0000wa-8t for ltru@ietf.org; Tue, 17 May 2005 02:53:10 -0400 Received: from h-68-164-242-97.snvacaid.dynamic.covad.net ([68.164.242.97] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DXvgE-0001Tz-00 for ltru@ietf.org; Mon, 16 May 2005 23:35:50 -0700 Message-ID: <008c01c55aab$05b3bce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 16 May 2005 23:37:44 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Ltru] Issues [psg.com #982] through [psg.com #991] X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've entered another block of issues into the tracker. All these are either rejected or resolved, *except* [psg.com #985] You can view these using the issue tracker at https://rt.psg.com/ with user and password "ietf". [psg.com #982] Alpha order in extension subtags rejected [psg.com #983] Ban singleton "i" rejected [psg.com #984] Ban singletons "y" and "z" rejected [psg.com #985] Specify case rules for canonical tags open [psg.com #986] RFC 822 line wrapping in the registry resolved [psg.com #987] Remove leading zeros from character references resolved [psg.com #988] Remove private use tags from the registry and sample registry rejected [psg.com #989] Simplify the language tag registration form resolved [psg.com #990] need to define extension registry and format resolved [psg.com #991] replacement for deprecated tags needs to be machine-readable resolved If you think I've gotten any of these wrong, or you you think an issue merits further discussion, *please* use an appropriate subject line to help us track the discussion and link it back to the issue tracker. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 02:42:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvmI-0005Kc-Ma; Tue, 17 May 2005 02:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvmH-0005KX-Hc for ltru@megatron.ietf.org; Tue, 17 May 2005 02:42:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14468 for ; Tue, 17 May 2005 02:42:02 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXw2v-0001Fc-Gz for ltru@ietf.org; Tue, 17 May 2005 02:59:19 -0400 Received: from h-68-164-242-97.snvacaid.dynamic.covad.net ([68.164.242.97] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DXvmA-00025F-00 for ltru@ietf.org; Mon, 16 May 2005 23:41:58 -0700 Message-ID: <000001c55aab$e241d5c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 16 May 2005 23:43:25 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Ltru] [psg.com #985] Specify case rules for canonical tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Comment registry-cowan-04 in message > http://www1.ietf.org/mail-archive/web/ltru/current/msg00607.html > reads: > Proposal registry-cowan-04: Specify case rules for canonical tags > > CURRENT: Canonicalizing a tag does not affect the case of the letters > in it. > > PROPOSED: Canonicalizing a tag adjusts the case of the letters as > follows: > > 1) The first letter of a script subtag is upper case; 2) Both > letters of an alpha region subtag are upper case; 3) All other > letters are lower case. > > RATIONALE: These are the de facto canonicalization rules for ISO 639, > ISO 3166, and ISO 15924 codes. Since we have not had canonical tags > before, there is no previous practice to contradict. The requirement > for case-insensitive matching may be eliminated if all tags being > matched > are known to be canonical. There was some discussion of this proposal, but it wasn't clear (to me at least) whether there was agreement at the end. Consequently, I haven't closed this item. Would we be content to wrap this this up as a "reject", or does it need further discussion? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 02:46:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvqg-000672-UF; Tue, 17 May 2005 02:46:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvqf-00066x-IB for ltru@megatron.ietf.org; Tue, 17 May 2005 02:46:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14802 for ; Tue, 17 May 2005 02:46:35 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXw7M-0001QT-3o for ltru@ietf.org; Tue, 17 May 2005 03:03:52 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4H6kQT9140244 for ; Tue, 17 May 2005 02:46:26 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4H6kQdV097478 for ; Tue, 17 May 2005 00:46:26 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4H6kQMq002785 for ; Tue, 17 May 2005 00:46:26 -0600 Received: from markdavis (sig-9-48-117-238.mts.ibm.com [9.48.117.238]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4H6kO9c002745; Tue, 17 May 2005 00:46:25 -0600 Message-ID: <002001c55aac$2505d0a0$ee753009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <008c01c55aab$05b3bce0$7f1afea9@oemcomputer> Subject: Re: [Ltru] Issues [psg.com #982] through [psg.com #991] Date: Mon, 16 May 2005 23:46:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j4H6kQT9140244 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I hadn't tried using rt.psg.com before. It is not obvious how to select a= ll and only those ltru items that are not rejected. Any hints? =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Monday, May 16, 2005 23:37 Subject: [Ltru] Issues [psg.com #982] through [psg.com #991] > Hi - > > I've entered another block of issues into the tracker. > All these are either rejected or resolved, *except* [psg.com #985] > You can view these using the issue tracker at https://rt.psg.com/ with > user and password "ietf". > > [psg.com #982] Alpha order in extension subtags > rejected > > [psg.com #983] Ban singleton "i" > rejected > > [psg.com #984] Ban singletons "y" and "z" > rejected > > [psg.com #985] Specify case rules for canonical tags > open > > [psg.com #986] RFC 822 line wrapping in the registry > resolved > > [psg.com #987] Remove leading zeros from character references > resolved > > [psg.com #988] Remove private use tags from the registry and sample registry > rejected > > [psg.com #989] Simplify the language tag registration form > resolved > > [psg.com #990] need to define extension registry and format > resolved > > [psg.com #991] replacement for deprecated tags needs to be machine-readable > resolved > > If you think I've gotten any of these wrong, or you you think an issue merits > further discussion, *please* use an appropriate subject line to help us track > the discussion and link it back to the issue tracker. > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 02:55:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvzH-00088p-Sm; Tue, 17 May 2005 02:55:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXvzG-00088c-3D for ltru@megatron.ietf.org; Tue, 17 May 2005 02:55:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15310 for ; Tue, 17 May 2005 02:55:26 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXwFv-0001rR-2T for ltru@ietf.org; Tue, 17 May 2005 03:12:44 -0400 Received: from h-68-164-242-97.snvacaid.dynamic.covad.net ([68.164.242.97] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DXvzB-0003xn-00 for ltru@ietf.org; Mon, 16 May 2005 23:55:25 -0700 Message-ID: <002b01c55aad$c33687a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <008c01c55aab$05b3bce0$7f1afea9@oemcomputer> <002001c55aac$2505d0a0$ee753009@sanjose.ibm.com> Subject: Re: [Ltru] Issues [psg.com #982] through [psg.com #991] Date: Mon, 16 May 2005 23:57:59 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Mark Davis" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Monday, May 16, 2005 11:46 PM > Subject: Re: [Ltru] Issues [psg.com #982] through [psg.com #991] > > I hadn't tried using rt.psg.com before. It is not obvious how to select all > and only those ltru items that are not rejected. Any hints? ... If you click "Tickets" on the left, it will take you to a search menu. If you chose Queue "is" "ltru-registry", with Status "isn't" "rejected", and click "Search", I think you'll get what you're looking for. The "bookmarkable URL" is https://rt.psg.com/Search/Listing.html?Bookmark=FrT%3B%404%7C%254%7C%241%7C1%241%7C2%258%7C%2411%7CDESCRIPTION%245%7CFIELD%248%7COPERATOR%245%7CVALUE%2421%7CQueue%20%3D%20ltru-registry%245%7CQueue%241%7C%3D%2413%7Cltru-registry%258%7C%2411%7CDESCRIPTION%245%7CFIELD%248%7COPERATOR%245%7CVALUE%2418%7CStatus%20%21%3D%20rejected%246%7CStatus%242%7C%21%3D%248%7Crejected%241%7C3%241%7C0%241%7C0&TicketsSortBy=id&TicketsSortOrder=ASC&RowsPerPage=50 Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 03:05:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXw9P-0002D2-Ib; Tue, 17 May 2005 03:05:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXw9O-0002Cu-4z for ltru@megatron.ietf.org; Tue, 17 May 2005 03:05:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16244 for ; Tue, 17 May 2005 03:05:56 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXwQ4-0002SX-LO for ltru@ietf.org; Tue, 17 May 2005 03:23:14 -0400 Received: from h-68-164-242-97.snvacaid.dynamic.covad.net ([68.164.242.97] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DXw9F-0000i5-00 for ltru@ietf.org; Tue, 17 May 2005 00:05:49 -0700 Message-ID: <000e01c55aaf$35d734c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001201c55657$48ffe300$7f1afea9@oemcomputer> <6.2.1.2.2.20050511205732.04972090@mail.jefsey.com> <000a01c5567c$c135f740$7f1afea9@oemcomputer> <6.2.1.2.2.20050512012041.05dab4e0@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #960] use ITU E.164 calling codes instead of ISO 3166 country codes Date: Tue, 17 May 2005 00:07:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Since there has been no other support voiced for the proposal to use E.164 codes in addition to ISO 3166 country codes, I'm going to mark issue #960 "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 04:43:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXxft-0001cC-Rt; Tue, 17 May 2005 04:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXxfs-0001bv-2Z for ltru@megatron.ietf.org; Tue, 17 May 2005 04:43:36 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23867 for ; Tue, 17 May 2005 04:43:32 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DXxcP-00057h-Fa for ltru@lists.ietf.org; Tue, 17 May 2005 10:40:02 +0200 Received: from c-134-89-236.hh.dial.de.ignite.net ([62.134.89.236]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 May 2005 10:40:01 +0200 Received: from nobody by c-134-89-236.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 May 2005 10:40:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 17 May 2005 10:34:19 +0200 Organization: Lines: 8 Message-ID: <4289AC8B.6221@xyzzy.claranet.de> References: <000001c55aab$e241d5c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-236.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > wrap this this up as a "reject" Yes. In my quick and dirty test of Doug's lstreg.txt I used something like toupper() without problems - I only forgot to "recanonicalize" the Suppress-Script output posted here. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 08:21:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY14K-000248-8Y; Tue, 17 May 2005 08:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY14J-000243-D1 for ltru@megatron.ietf.org; Tue, 17 May 2005 08:21:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15584 for ; Tue, 17 May 2005 08:21:01 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY1L2-0002zs-Q5 for ltru@ietf.org; Tue, 17 May 2005 08:38:22 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4HCKp9f007661; Tue, 17 May 2005 08:20:52 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 17 May 2005 08:20:52 -0400 Date: Tue, 17 May 2005 08:20:52 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] [psg.com #985] Specify case rules for canonical tags Message-ID: <20050517122052.GD14638@skunk.reutershealth.com> References: <000001c55aab$e241d5c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c55aab$e241d5c0$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > There was some discussion of this proposal, but it wasn't clear (to me at > least) whether there was agreement at the end. Consequently, I haven't > closed this item. Would we be content to wrap this this up as a "reject", > or does it need further discussion? I continue to believe in case-canonicalization. The whole point of canonicalizing anything, including language tags, is to squeeze out the maximum amount of non-semantic variability. Case is just as non-semantic as extension ordering, there is a well-established practice based on the styles used in the sources, and the rule is easy to state and to implement: uppercase all non-initial two-character tags (outside extensions and privates), titlecase all non-initial four-character tags (ditto), lowercase everything else. This would not affect mere well-formedness or validity, only canonicality. -- Henry S. Thompson said, / "Syntactic, structural, John Cowan Value constraints we / Express on the fly." jcowan@reutershealth.com Simon St. Laurent: "Your / Incomprehensible http://www.reutershealth.com Abracadabralike / schemas must die!" http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 10:14:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY2mM-0002R7-An; Tue, 17 May 2005 10:10:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY2mL-0002Qt-IZ for ltru@megatron.ietf.org; Tue, 17 May 2005 10:10:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27321 for ; Tue, 17 May 2005 10:10:32 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY333-0000uv-Ae for ltru@ietf.org; Tue, 17 May 2005 10:27:54 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 07:10:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #985] Specify case rules for canonical tags Date: Tue, 17 May 2005 07:10:20 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B65E30D@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #985] Specify case rules for canonical tags Thread-Index: AcVa2zWUIrcHmu8rTvSYAhnCwF/2OQAC7Giw From: "Addison Phillips" To: "John Cowan" , "Randy Presuhn" X-OriginalArrivalTime: 17 May 2005 14:10:22.0014 (UTC) FILETIME=[29CDFDE0:01C55AEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Suggestion: The text currently has this paragraph: Note: Canonicalization of language tags does not imply anything about = the use of upper or lowercase letter in subtags as described in Section = 2.1 (Syntax). All comparisons MUST be performed in a case-insensitive = manner. We can resolve this issue by changing it as follows and adding the shown = additional paragraph: Canonicalization of language tags does not imply anything about the = use of upper or lowercase letters when processing or comparing subtags = (and as described in Section 2.1). All comparisons MUST be performed in = a case-insensitive manner. When performing canonicalization of language tags, processors MAY = optionally regularize the case of the subtags, following the case used = in the registry. Note that this corresponds to the following casing = rules: uppercase all non-initial two-letter subtags; titlecase all = non-initial four-letter subtags; lowercase everything else. In other words, permit or even encourage it, but not require it. Oh, and should we add a warning about the one common case in which = locale-sensitive casing methods hurt? E.g. in Java I can write this: // set the locale as if environment is running in Turkish Locale.setDefault("tr","TR"); // ... String fubar =3D "iI"; fubar =3D fubar.toUpperCase();=20 And 'fubar' contains: \u0130\u0049 (which would be bad in a language = tag). Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: 2005?5?17? 5:21 > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #985] Specify case rules for canonical = tags >=20 > Randy Presuhn scripsit: >=20 > > There was some discussion of this proposal, but it wasn't clear (to = me > at > > least) whether there was agreement at the end. Consequently, I = haven't > > closed this item. Would we be content to wrap this this up as a > "reject", > > or does it need further discussion? >=20 > I continue to believe in case-canonicalization. The whole point of > canonicalizing > anything, including language tags, is to squeeze out the maximum = amount of > non-semantic variability. Case is just as non-semantic as extension > ordering, > there is a well-established practice based on the styles used in the > sources, > and the rule is easy to state and to implement: uppercase all = non-initial > two-character tags (outside extensions and privates), titlecase all = non- > initial > four-character tags (ditto), lowercase everything else. >=20 > This would not affect mere well-formedness or validity, only = canonicality. >=20 > -- > Henry S. Thompson said, / "Syntactic, structural, John = Cowan > Value constraints we / Express on the fly." = jcowan@reutershealth.com > Simon St. Laurent: "Your / Incomprehensible > http://www.reutershealth.com > Abracadabralike / schemas must die!" = http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 10:30:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY356-0006ml-2b; Tue, 17 May 2005 10:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY354-0006la-Jh for ltru@megatron.ietf.org; Tue, 17 May 2005 10:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00068 for ; Tue, 17 May 2005 10:29:56 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY3Lo-00027Q-Lj for ltru@ietf.org; Tue, 17 May 2005 10:47:18 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4HETgVO008251; Tue, 17 May 2005 10:29:42 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 17 May 2005 10:29:40 -0400 Date: Tue, 17 May 2005 10:29:39 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] [psg.com #985] Specify case rules for canonical tags Message-ID: <20050517142939.GG14638@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B65E30D@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B65E30D@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > When performing canonicalization of language tags, processors MAY > optionally regularize the case of the subtags, following the case used > in the registry. Note that this corresponds to the following casing > rules: uppercase all non-initial two-letter subtags; titlecase all > non-initial four-letter subtags; lowercase everything else. > > In other words, permit or even encourage it, but not require it. I can live with that, provided the casing rules are moved or copied to the registry-creation section so that they are locked in (e.g. when ISO 639-3 or 639-6 comes on line, we want their tags to be entered in lower case). > Oh, and should we add a warning about the one common case in which > locale-sensitive casing methods hurt? E.g. in Java I can write this: Yes, absolutely. Note that both Turkish and Azeri locales have this problem. > // set the locale as if environment is running in Turkish > Locale.setDefault("tr","TR"); > // ... > String fubar = "iI"; > fubar = fubar.toUpperCase(); > > And 'fubar' contains: \u0130\u0049 (which would be bad in a language tag). A more practical example would be "in" (India) being upcased to "\u0130n". Hopefully Turkish/Azeri programmers are used to this inconvenience by now, though. -- Is a chair finely made tragic or comic? Is the John Cowan portrait of Mona Lisa good if I desire to see jcowan@reutershealth.com it? Is the bust of Sir Philip Crampton lyrical, www.ccil.org/~cowan epical or dramatic? If a man hacking in fury www.reutershealth.com at a block of wood make there an image of a cow, is that image a work of art? If not, why not? --Stephen Dedalus _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 10:36:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3Bp-0000I7-5n; Tue, 17 May 2005 10:36:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3Bm-0000GI-C9 for ltru@megatron.ietf.org; Tue, 17 May 2005 10:36:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01107 for ; Tue, 17 May 2005 10:36:51 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY3SW-0002Wl-So for ltru@ietf.org; Tue, 17 May 2005 10:54:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 07:36:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #985] Specify case rules for canonical tags Date: Tue, 17 May 2005 07:36:42 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B65E340@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #985] Specify case rules for canonical tags Thread-Index: AcVa7O0lljNzC7JtRCO0fV2n2HeUgQAABn/Q From: "Addison Phillips" To: "John Cowan" X-OriginalArrivalTime: 17 May 2005 14:36:43.0541 (UTC) FILETIME=[D877DC50:01C55AED] X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Thanks, John. Some responses below. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: 2005?5?17? 7:30 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #985] Specify case rules for canonical = tags >=20 > Addison Phillips scripsit: >=20 > > When performing canonicalization of language tags, processors MAY > > optionally regularize the case of the subtags, following the case = used > > in the registry. Note that this corresponds to the following casing > > rules: uppercase all non-initial two-letter subtags; titlecase all > > non-initial four-letter subtags; lowercase everything else. > > > > In other words, permit or even encourage it, but not require it. >=20 > I can live with that, provided the casing rules are moved or copied to = the > registry-creation section so that they are locked in (e.g. when ISO = 639-3 > or 639-6 comes on line, we want their tags to be entered in lower = case). [Addison Phillips]=20 Agreed. >=20 > > Oh, and should we add a warning about the one common case in which > > locale-sensitive casing methods hurt? E.g. in Java I can write this: >=20 > Yes, absolutely. Note that both Turkish and Azeri locales have this > problem. >=20 > > // set the locale as if environment is running in Turkish > > Locale.setDefault("tr","TR"); > > // ... > > String fubar =3D "iI"; > > fubar =3D fubar.toUpperCase(); > > > > And 'fubar' contains: \u0130\u0049 (which would be bad in a language > tag). >=20 > A more practical example would be "in" (India) being upcased to = "\u0130n". > Hopefully Turkish/Azeri programmers are used to this inconvenience by > now, though. [Addison Phillips]=20 Turkish and Azeri programmers are used to it. It's all the other = programmers in the world... they are blissfully unaware. If you want = locale-neutral casing then you have to be explicit: fubar =3D fubar.toUpperCase(new Locale("","")); Programs exported to or run in systems in these locales fail if you = aren't careful. The India example is a better one. >=20 > -- > Is a chair finely made tragic or comic? Is the John Cowan > portrait of Mona Lisa good if I desire to see > jcowan@reutershealth.com > it? Is the bust of Sir Philip Crampton lyrical, > www.ccil.org/~cowan > epical or dramatic? If a man hacking in fury > www.reutershealth.com > at a block of wood make there an image of a cow, > is that image a work of art? If not, why not? --Stephen > Dedalus _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 10:37:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3CO-0000Om-EZ; Tue, 17 May 2005 10:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3CM-0000Oh-8z for ltru@megatron.ietf.org; Tue, 17 May 2005 10:37:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01327 for ; Tue, 17 May 2005 10:37:27 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY3T6-0002Zh-Gf for ltru@ietf.org; Tue, 17 May 2005 10:54:50 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4HEbImc008295; Tue, 17 May 2005 10:37:18 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 17 May 2005 10:37:17 -0400 Date: Tue, 17 May 2005 10:37:17 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] [psg.com #985] Specify case rules for canonical tags Message-ID: <20050517143716.GH14638@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B65E30D@irvmbxw01.quest.com> <20050517142939.GG14638@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517142939.GG14638@skunk.reutershealth.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan scripsit: > A more practical example would be "in" (India) being upcased to "\u0130n". Er, make that "\u0130N". Sorry. -- John Cowan http://www.ccil.org/~cowan jcowan@reutershealth.com To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 13:30:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5tb-0008EO-2W; Tue, 17 May 2005 13:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5ta-0008EI-Dz for ltru@megatron.ietf.org; Tue, 17 May 2005 13:30:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18193 for ; Tue, 17 May 2005 13:30:14 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY6AM-0003wE-68 for ltru@ietf.org; Tue, 17 May 2005 13:47:39 -0400 Received: from h-64-105-136-4.snvacaid.dynamic.covad.net ([64.105.136.4] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DY5tT-0004gN-00 for ltru@ietf.org; Tue, 17 May 2005 10:30:11 -0700 Message-ID: <005d01c55b06$6fcf11a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <000001c55aab$e241d5c0$7f1afea9@oemcomputer> <4289AC8B.6221@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags Date: Tue, 17 May 2005 10:32:44 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Tuesday, May 17, 2005 1:34 AM > Subject: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags > > Randy Presuhn wrote: > > > wrap this this up as a "reject" > > Yes. In my quick and dirty test of Doug's lstreg.txt I used > something like toupper() without problems - I only forgot to > "recanonicalize" the Suppress-Script output posted here. Bye. ... Frank: does the suggestion made in message http://www.ietf.org/mail-archive/web/ltru/current/msg01755.html (with the tweaks proposed in the followups) work for you? Everyone else: would that be an acceptable resolution to this issue? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 14:17:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY6da-0002cp-Lj; Tue, 17 May 2005 14:17:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY6dZ-0002ck-BS for ltru@megatron.ietf.org; Tue, 17 May 2005 14:17:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22920 for ; Tue, 17 May 2005 14:17:47 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY6uL-0006cl-Nf for ltru@ietf.org; Tue, 17 May 2005 14:35:11 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4HIHbu1019819; Tue, 17 May 2005 11:17:37 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 May 2005 11:17:38 -0700 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , ltru@ietf.org Subject: RE: [Ltru] Re: [psg.com #985] Specify case rules for canonical ta gs Date: Tue, 17 May 2005 11:17:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, I agree with the issue resolution with these clarifications. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Randy Presuhn > Sent: Tuesday, May 17, 2005 1:33 PM > To: ltru@ietf.org > Subject: Re: [Ltru] Re: [psg.com #985] Specify case rules for > canonical > tags > > > Hi - > > > From: "Frank Ellermann" > > To: > > Sent: Tuesday, May 17, 2005 1:34 AM > > Subject: [Ltru] Re: [psg.com #985] Specify case rules for > canonical tags > > > > > Randy Presuhn wrote: > > > > > wrap this this up as a "reject" > > > > Yes. In my quick and dirty test of Doug's lstreg.txt I used > > something like toupper() without problems - I only forgot to > > "recanonicalize" the Suppress-Script output posted here. Bye. > ... > > Frank: does the suggestion made in message > http://www.ietf.org/mail-archive/web/ltru/current/msg01755.html > (with the tweaks proposed in the followups) work for you? > > Everyone else: would that be an acceptable resolution to this issue? > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 15:47:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY82c-0007e8-5O; Tue, 17 May 2005 15:47:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY82X-0007b9-38; Tue, 17 May 2005 15:47:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01839; Tue, 17 May 2005 15:47:38 -0400 (EDT) Message-Id: <200505171947.PAA01839@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 17 May 2005 15:47:38 -0400 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-00.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Matching Language Identifiers Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-matching-00.txt Pages : 20 Date : 2005-5-17 This document describes different mechanisms for comparing and matching the tags for the identification of languages defined by [RFC 3066bis] [1]. Possible algorithms for language negotiation and content selection are described. Portions of this document obsolete [RFC 3066] [19]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-matching-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-matching-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-17154134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-17154134.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@lists.ietf.org Tue May 17 18:48:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYArT-0003cn-0j; Tue, 17 May 2005 18:48:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYArS-0003XR-0u for ltru@megatron.ietf.org; Tue, 17 May 2005 18:48:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29769 for ; Tue, 17 May 2005 18:48:20 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYB8F-0008WQ-FL for ltru@ietf.org; Tue, 17 May 2005 19:05:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 15:48:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 May 2005 15:48:12 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B65E69A@irvmbxw01.quest.com> Thread-Topic: Some comments on draft-ietf-ltru-matching-00 Thread-Index: AcVbKC4wlhedSDIARAOKF1XgWqpIpgACUuUg From: "Addison Phillips" To: "Michael A. Patton" , X-OriginalArrivalTime: 17 May 2005 22:48:13.0085 (UTC) FILETIME=[819B2CD0:01C55B32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org Subject: [Ltru] RE: Some comments on draft-ietf-ltru-matching-00 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Michael, Thanks for the comments. You should probably make future comments on the LTRU mailing list: Mark = and I are merely the editors. I've copied the list on this message. Some = responses inter-linearly below. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Michael A. Patton [mailto:MAP@MAP-NE.com] > Sent: 2005?5?17? 14:34 > To: Addison Phillips; mark.davis@ibm.com > Subject: Some comments on draft-ietf-ltru-matching-00 >=20 > Here are some comments on draft-ietf-ltru-matching-00, original > text is indented (by four spaces, in addition to any original > indentation), my comments are at the left margin (special note ">>>" > at the left margin points in to a short comment, often a simple typo). > Where alternate text is offered, it is indented as the original was in > the document. Usually, the last section heading is left in place to > help identify where the comments apply. >=20 > Most of the comments are typos, but there are two important errors (a > ref to a non-existant example and a syntax error in the ABNF) amongst > the typos >=20 >=20 > In Section 1 third paragraph there is a mention of RFC3066bis but no > reference mark. Should add "[1]" (I think), i.e. >=20 > Given a set of language identifiers, such as those defined in > RFC3066bis [1], various mechanisms ... [Addison Phillips]=20 I used xml2rfc to generate the text. I'll check on how the reference is = tagged so that it is generated correctly in the next version. >=20 > --- >=20 > In this paragraph, I'm not sure why the RFC is delimited as it is: >=20 > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > document are to be interpreted as described in [RFC 2119] [5]. >=20 > I.e. it should read: >=20 > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > document are to be interpreted as described in RFC2119 [5]. [Addison Phillips]=20 Ditto. >=20 > --- >=20 > 2.1 Basic Language Range >=20 > 1. ... as the example above. >=20 > There's no example in the document before this , so what does this > refer to? [Addison Phillips]=20 This document was made by splitting another document = (draft-phillips-langtags-10) into two documents. I have subsequently = corrected some of the oversights you mention (such as this one) in the = editor's copy and you'll see them in a draft-01 shortly. For reference, = the editor's copy is at: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-01.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-01.txt >=20 > 2. ... > by that protocol. This should be done with caution, since it it > >>> = ^^ > dup > is removing information that may be relevant if services on the [Addison Phillips]=20 Yup. Thanks. >=20 > --- >=20 > 2.2 Extended Language Range >=20 > lang =3D ( 2*8ALPHA *[ *( "-" extlang ] ) ) / "*" >=20 > This rule has a syntax error, the parens and brackets don't nest > correctly. I think you meant: >=20 > lang =3D ( 2*8ALPHA *[ *( "-" extlang ) ] ) / "*" >=20 > but even though that's now syntactically correct, it seems that having > the two nested repeats is unduly redundant. [Addison Phillips]=20 This was the result of taking Bill Fenner's ABNF checker-tool output and = pasting it in. My bad for not checking it more carefully. >=20 > --- >=20 > 2.2.1 Extended Range Matching >=20 > Subtags not specified, included those at the end of the = language > >>> ^^^^^^^^ including > range, are assigned the value "*". This makes each range into = a [Addison Phillips]=20 Good catch. Thanks. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 21:31:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYDPb-000319-Hv; Tue, 17 May 2005 21:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYDPa-0002z0-FI for ltru@megatron.ietf.org; Tue, 17 May 2005 21:31:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12266 for ; Tue, 17 May 2005 21:31:47 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYDgP-0000Eo-1G for ltru@ietf.org; Tue, 17 May 2005 21:49:15 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 May 2005 18:31:37 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 May 2005 18:31:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 May 2005 18:31:35 -0700 Message-ID: Thread-Topic: grandfathered tags and generative capacity Thread-Index: AcVbSVQFRnzsoEIlR2+VGEBMBCkI1Q== From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 18 May 2005 01:31:37.0990 (UTC) FILETIME=[55C8F260:01C55B49] X-Spam-Score: 0.5 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: Subject: [Ltru] grandfathered tags and generative capacity X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0583023968==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0583023968== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55B49.5558A522" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55B49.5558A522 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I can't remember if this has been discussed. I'm thinking about what a person should do in a particular scenario, and wondering if my thoughts align with those of others here. =20 We're defining a generative mechanism that doesn't require registration of particular combinations, and we're defining a morphology that will generally make it clear what combination of subtags a person should use to denote a particular distinction. So, for instance (anticipating the use of extlang in 3066ter), if someone wants a tag to denote Cantonese written in simplified characters for use in Hong Kong, they would generate the combination zh-yue-Hans-HK. =20 That's all pretty straightforward. =20 But now throw into this mix the fact that we have certain grandfathered tags - grandfathered because they don't fit the general syntax. What does someone do if they need to denote a category that's a restriction on something for which there's a grandfathered tag? For example, what does someone use to denote Mandarin written in traditional characters for use in Mainland China? The issue here is that Mandarin Chinese has a grandfathered tag of zh-guoyu.=20 =20 It seems that there are four logical possibilities: =20 1) They must ignore the grandfathered tag and generate a tag from subtags as though the grandfathered tag didn't exist; e.g. zh-cmn-Hant-CN. =20 2) They must register a complete tag that's derived from this grandfathered tag; e.g. zh-guoyu-Hant-CN. =20 3) The subtag "guoyu" gets treated like a variant, and they simply generate a tag using that variant; e.g. zh-Hant-CN-guoyu. =20 4) They treat the grandfathered tag zh-guoyu as though it were a ll-ext combination, and generate a tag by adding additional subtags to the right as needed; e.g. zh-guoyu-Hant-CN. =20 =20 Now, (2) isn't possible since there will no longer be any mechanism for registering complete tags. And (4) isn't permitted by the syntax. Option (3) appears to be suggested by the fact that the draft registry Doug prepared has "guoyo" as a variant (with "zh-guoyu" being considered, strictly speaking, redundant, not grandfathered). But, I also see nothing preventing someone from adopting option (1). =20 The problem I see with (3) is the inconsistency between Mandarin and Cantonese (say): the one uses a variant subtag, while the other uses an extlang subtag: =20 zh-Hant-CN-guoyu zh-yue-Hant-CN =20 That seems likely to confuse some. The problem with (1) is the inconsistency between shorter/more generic tags and longer/more fully qualified tags: =20 zh-guoyu zh-cmn-Hant / zh-cmn-CN / zh-cmn-Hant-CN / etc. =20 The latter problem has a potential remedy in the form of deprecating zh-guoyu - though you can't eliminate existing usages that may be out there. I see no potential remedy for the former problem, though. =20 This struck me because I just finished writing to someone representing the Motion Picture Association who had written to the ISO 639/RA Joint Advisory Committee looking for a solution to their language tagging problems. I was explaining that RFC 3066 bis/ter would provide all they needed, but the examples he was giving involved Chinese, and after explaining what tags he could use, I found myself also explaining why the pattern in zh-yue-Hant-CN was different from the pattern in zh-Hant-CN-guoyu. =20 So, I guess what this boils down to is a suggestion that zh-guoyu, zh-hakka, and zh-xiang be deprecated. Probably also cel-gaulish as well. =20 =20 =20 Peter Constable ------_=_NextPart_001_01C55B49.5558A522 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I can’t remember if this has been discussed. = I’m thinking about what a person should do in a particular scenario, and = wondering if my thoughts align with those of others here.

 

We’re defining a generative mechanism that = doesn’t require registration of particular combinations, and we’re = defining a morphology that will generally make it clear what combination of subtags = a person should use to denote a particular distinction. So, for instance (anticipating the use of extlang in 3066ter), if someone wants a tag to = denote Cantonese written in simplified characters for use in Hong Kong, they = would generate the combination zh-yue-Hans-HK.

 

That’s all pretty = straightforward.

 

But now throw into this mix the fact that we have = certain grandfathered tags – grandfathered because they don’t fit = the general syntax. What does someone do if they need to denote a category = that’s a restriction on something for which there’s a grandfathered tag? = For example, what does someone use to denote Mandarin written in traditional characters for use in Mainland China? The issue here is that Mandarin = Chinese has a grandfathered tag of zh-guoyu.

 

It seems that there are four logical = possibilities:

 

1) They must ignore the grandfathered tag and = generate a tag from subtags as though the grandfathered tag didn’t exist; e.g. zh-cmn-Hant-CN.

 

2) They must register a complete tag that’s = derived from this grandfathered tag; e.g. zh-guoyu-Hant-CN.

 

3) The subtag “guoyu” gets treated like a variant, and they simply generate a tag using that variant; e.g. zh-Hant-CN-guoyu.

 

4) They treat the grandfathered tag zh-guoyu as = though it were a ll-ext combination, and generate a tag by adding additional = subtags to the right as needed; e.g. zh-guoyu-Hant-CN.

 

 

Now, (2) isn’t possible since there will no = longer be any mechanism for registering complete tags. And (4) isn’t = permitted by the syntax. Option (3) appears to be suggested by the fact that the = draft registry Doug prepared has “guoyo” as a variant (with = “zh-guoyu” being considered, strictly speaking, redundant, not grandfathered). But, = I also see nothing preventing someone from adopting option = (1).

 

The problem I see with (3) is the inconsistency = between Mandarin and Cantonese (say): the one uses a variant subtag, while the = other uses an extlang subtag:

 

zh-Hant-CN-guoyu

zh-yue-Hant-CN

 

That seems likely to confuse some. The problem with = (1) is the inconsistency between shorter/more generic tags and longer/more = fully qualified tags:

 

zh-guoyu

zh-cmn-Hant / zh-cmn-CN / zh-cmn-Hant-CN / = etc.

 

The latter problem has a potential remedy in the form = of deprecating zh-guoyu – though you can’t eliminate existing = usages that may be out there. I see no potential remedy for the former problem, though.

 

This struck me because I just finished writing to = someone representing the Motion Picture Association who had written to the ISO 639/RA Joint = Advisory Committee looking for a solution to their language tagging problems. I = was explaining that RFC 3066 bis/ter would provide all they needed, but the examples he was giving involved Chinese, and after explaining what tags = he could use, I found myself also explaining why the pattern in = zh-yue-Hant-CN was different from the pattern in zh-Hant-CN-guoyu.

 

So, I guess what this boils down to is a suggestion = that zh-guoyu, zh-hakka, and zh-xiang be deprecated. Probably also cel-gaulish as = well.

 

 

 

Peter Constable

------_=_NextPart_001_01C55B49.5558A522-- --===============0583023968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0583023968==-- From ltru-bounces@lists.ietf.org Tue May 17 22:02:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYDtd-0003l0-LZ; Tue, 17 May 2005 22:02:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYDtc-0003kv-Dt for ltru@megatron.ietf.org; Tue, 17 May 2005 22:02:52 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14281 for ; Tue, 17 May 2005 22:02:49 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DYDsE-0007uW-M5 for ltru@lists.ietf.org; Wed, 18 May 2005 04:01:26 +0200 Received: from du-001-052.access.de.clara.net ([212.82.227.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 May 2005 04:01:26 +0200 Received: from nobody by du-001-052.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 May 2005 04:01:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 18 May 2005 04:00:54 +0200 Organization: Lines: 8 Message-ID: <428AA1D6.2BCE@xyzzy.claranet.de> References: <000001c55aab$e241d5c0$7f1afea9@oemcomputer> <4289AC8B.6221@xyzzy.claranet.de> <005d01c55b06$6fcf11a0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-052.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > does the suggestion made in message > http://www.ietf.org/mail-archive/web/ltru/current/msg01755.html > (with the tweaks proposed in the followups) work for you? Yes, I checked i-*, no case of i-abcd with four letters. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 17 22:20:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYEAG-00015a-Vo; Tue, 17 May 2005 22:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYEAF-00012h-Np for ltru@megatron.ietf.org; Tue, 17 May 2005 22:20:03 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15483 for ; Tue, 17 May 2005 22:20:00 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DYE91-0000mo-T5 for ltru@lists.ietf.org; Wed, 18 May 2005 04:18:47 +0200 Received: from du-001-052.access.de.clara.net ([212.82.227.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 May 2005 04:18:47 +0200 Received: from nobody by du-001-052.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 May 2005 04:18:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 18 May 2005 04:17:53 +0200 Organization: Lines: 6 Message-ID: <428AA5D1.5E5C@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B65E69A@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-052.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Some comments on draft-ietf-ltru-matching-00 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Bill Fenner's ABNF checker-tool That's already fixed... :-) Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 00:18:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYG0U-0003Sa-Ft; Wed, 18 May 2005 00:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYG0S-0003Qn-JR for ltru@megatron.ietf.org; Wed, 18 May 2005 00:18:04 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23547 for ; Wed, 18 May 2005 00:18:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050518041731.RXTB17140.mta10.adelphia.net@DEWELL> for ; Wed, 18 May 2005 00:17:31 -0400 Message-ID: <001001c55b60$7e03e660$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050517160342.SPBD28811.mta8.adelphia.net@megatron.ietf.org> Date: Tue, 17 May 2005 21:17:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org As someone who liked John's original proposal, but wasn't ready to go to war over it, I think Addison's suggestion to "permit or even encourage it, but not require it" is an excellent compromise. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 00:42:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGOC-0003oR-1o; Wed, 18 May 2005 00:42:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGOA-0003oM-Ap for ltru@megatron.ietf.org; Wed, 18 May 2005 00:42:34 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25369 for ; Wed, 18 May 2005 00:42:30 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050518044145.VODS13270.mta11.adelphia.net@DEWELL> for ; Wed, 18 May 2005 00:41:45 -0400 Message-ID: <002301c55b63$dfdfc040$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050518013420.IIMW28811.mta8.adelphia.net@megatron.ietf.org> Date: Tue, 17 May 2005 21:41:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: grandfathered tags and generative capacity X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > The issue here is that Mandarin Chinese has a grandfathered tag of > zh-guoyu. As Peter indicated later, this is in fact a redundant tag, not a grandfathered one. 'guoyu', being 5 letters long, meets the criteria for a variant subtag, and so Peter's choice 3 is the correct one: > 3) The subtag "guoyu" gets treated like a variant, and they simply > generate a tag using that variant; e.g. zh-Hant-CN-guoyu. However, assuming the existence of extended language subtags, it's also true that "zh-cmn" would be a synonym for "zh-guoyu", except that the former would have a more intuitive syntax: lang-extlang-other-stuff. When we have grandfathered tags like "no-nyn" that mean the same thing as proper generative tags like "nn", the correct thing to do is to deprecate the grandfathered tag. The only difference between "no-nyn" and "zh-guoyu" is that the first doesn't qualify as a lang-variant pair while the second does, purely because of length constraints. So it might seem reasonable to deprecate the variant subtag 'guoyu' in favor of the extended language subtag 'cmn', as soon as the latter becomes available (ISO 639-3). The only crummy little problem is that, once again, subtags can only be aliased to other subtags, and redundant tags can only be aliased to whole tags. (The sentence in Section 3.4 about "i-navajo" is still wrong, by the way. That tag is deprecated in favor of the complete tag "nv", not the subtag 'nv'.) There is no provision to alias a language-variant combination to a lang-extlang combination. Figuring out a reasonable way to do so is the challenge. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 01:42:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYHKS-0006ha-JI; Wed, 18 May 2005 01:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYHKP-0006eR-V9 for ltru@megatron.ietf.org; Wed, 18 May 2005 01:42:46 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29667 for ; Wed, 18 May 2005 01:42:44 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050518054214.KWYN8952.mta9.adelphia.net@DEWELL> for ; Wed, 18 May 2005 01:42:14 -0400 Message-ID: <006501c55b6c$55234ea0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050511161235.QTIP28887.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 17 May 2005 22:42:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Trying to catch up... Frank Ellermann wrote: >> I have never, ever argued in favor of making the registry >> draft an RFC. > > Registry draft => Addison and Mark, draft registry => you. You are right. I apologize for screwing up the terminology (which I helped create) and completely misunderstanding your intent. No excuses. > | For ISO 3166 codes, if the newly assigned code's meaning is > | associated with the same UN M.49 code as another 'region' > | subtag, then the existing region subtag remains as the > | canonical entry for that region and no new entry is created. > > That's the "same piece of land" defined by UN numbers, it's in > the *actual* draft -01. It's used in several rules to resolve > conflicts. That's fine. Just don't refer to it as "Doug's rule." -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 01:56:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYHY5-0003D5-UD; Wed, 18 May 2005 01:56:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYHY3-0003Ax-QU for ltru@megatron.ietf.org; Wed, 18 May 2005 01:56:51 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00903 for ; Wed, 18 May 2005 01:56:50 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050518055620.WRMI17140.mta10.adelphia.net@DEWELL> for ; Wed, 18 May 2005 01:56:20 -0400 Message-ID: <007401c55b6e$4ec83140$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050512000650.KTIF27459.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 17 May 2005 22:56:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I don't know if this particular issue got resolved yet, but I'm concerned about an informative "Use" field that seems to run counter to the normative "Canonical" field. We have text all over the draft that says processors should use a canonical subtag instead of an alias whenever possible. This proposal would turn that on its ear; you would have situations where one tag would be canonical, yet processors would actually be encouraged to use the other one. Or, alternatively, there would be only a "Use" field and no "Canonical" field. That would make "Use" into sort of an ersatz "Canonical," but with none of the stability that the word "canonical" implies. I agree that the whole matter of "deprecated but canonical" subtags is weird, but I'm not at all convinced this is the right solution. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 02:15:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYHmE-0007P7-1L; Wed, 18 May 2005 02:11:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYHmC-0007OR-2f for ltru@megatron.ietf.org; Wed, 18 May 2005 02:11:28 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12851 for ; Wed, 18 May 2005 02:11:26 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050518061056.XEGG17140.mta10.adelphia.net@DEWELL> for ; Wed, 18 May 2005 02:10:56 -0400 Message-ID: <008901c55b70$59717640$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050516170302.ZTOM27459.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 17 May 2005 23:10:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Open points before -02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >> That was rejected, Addison wants to document the record-jar >> format, not its registry incarnation. That's backwards from >> my POV, mail (2822) and news (1036) use prose for the simple >> general format, and syntax for the header field details, but >> there's no rule to do it this way also in 3066bis. > > I suggested that an independent RFC be written to document record-jar > for future generations, actually. I continue to think this is an excellent idea. Is it on-topic for this WG, or should those of us who support this idea start meeting off-list to discuss it? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 03:56:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJPi-0006lR-Tg; Wed, 18 May 2005 03:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJPg-0006lJ-VI for ltru@megatron.ietf.org; Wed, 18 May 2005 03:56:21 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15181 for ; Wed, 18 May 2005 03:56:17 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DYJOf-0005yg-0t for ltru@lists.ietf.org; Wed, 18 May 2005 09:55:17 +0200 Received: from 62.80.58.217 ([62.80.58.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 May 2005 09:55:17 +0200 Received: from nobody by 62.80.58.217 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 May 2005 09:55:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 18 May 2005 09:53:29 +0200 Organization: Lines: 11 Message-ID: <428AF479.22C8@xyzzy.claranet.de> References: <20050511161235.QTIP28887.mta4.adelphia.net@megatron.ietf.org> <006501c55b6c$55234ea0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.217 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > That's fine. Just don't refer to it as "Doug's rule." In a related article I managed to replace the hypothetical NH -> VU example by similar iw -> he etc. examples, and the "same language" instead of the "same piece of [***]" shouldn't trigger your shields. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 12:08:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYR5y-0001rn-Gv; Wed, 18 May 2005 12:08:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYR5w-0001pV-JX for ltru@megatron.ietf.org; Wed, 18 May 2005 12:08:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06238 for ; Wed, 18 May 2005 12:08:25 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYRMt-0007Vo-Qm for ltru@ietf.org; Wed, 18 May 2005 12:26:01 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4IG87BY014655; Wed, 18 May 2005 12:08:08 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 18 May 2005 12:07:22 -0400 Date: Wed, 18 May 2005 12:07:22 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally supported Message-ID: <20050518160722.GA23836@skunk.reutershealth.com> References: <20050512000650.KTIF27459.mta2.adelphia.net@megatron.ietf.org> <007401c55b6e$4ec83140$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007401c55b6e$4ec83140$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell scripsit: > I agree that the whole matter of "deprecated but canonical" subtags is > weird, but I'm not at all convinced this is the right solution. It's pretty straightforward, actually. They were taken into our registry from a source standard, and if they become deprecated (and so not canonical) for that source, they are still canonical *for us*. -- Said Agatha Christie / To E. Philips Oppenheim John Cowan "Who is this Hemingway? / Who is this Proust? jcowan@reutershealth.com Who is this Vladimir / Whatchamacallum, http://www.reutershealth.com This neopostrealist / Rabble?" she groused. http://www.ccil.org/cowan --author unknown to me; any suggestions? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 14:02:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSsV-0006Cw-Gw; Wed, 18 May 2005 14:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSsT-0006Ck-Jj for ltru@megatron.ietf.org; Wed, 18 May 2005 14:02:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18622; Wed, 18 May 2005 14:02:39 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYT9T-00049g-Ca; Wed, 18 May 2005 14:20:15 -0400 Received: from h-64-105-35-94.snvacaid.dynamic.covad.net ([64.105.35.94] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYSsQ-0004bv-00; Wed, 18 May 2005 11:02:38 -0700 Message-ID: <003c01c55bd4$2348dfe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Date: Wed, 18 May 2005 11:05:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: LTRU Working Group Subject: [Ltru] completed milestone for ltru charter X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Please update the following milestone on the ltru working group charter: Apr 05 Submit first draft of matching algorithms draft This milestone is now "done". Randy Presuhn Ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 14:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYTg7-0004yK-Fz; Wed, 18 May 2005 14:53:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYTg6-0004yF-E7 for ltru@megatron.ietf.org; Wed, 18 May 2005 14:53:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23156 for ; Wed, 18 May 2005 14:53:55 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYTx4-0006J3-7s for ltru@ietf.org; Wed, 18 May 2005 15:11:31 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4IIrVms025587; Wed, 18 May 2005 11:53:31 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 May 2005 11:53:31 -0700 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Wed, 18 May 2005 11:53:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, First, aliases are _bad_ for the reliability of any protocol or interface. The so-called 'preferred MIME name' label on aliases in the IANA Charset Registry is useless and dangerous. Whenever possible, the language tag registry draft should not encourage the proliferation of aliases for tags or subtags. The registry draft and the matching draft should make clear that support for the Canonical subtags is REQUIRED, but support for Alias subtags is merely RECOMMENDED. Your mileage may vary. Required support for all registered aliases is a bad idea and it will be ignored by the majority of implementors. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Doug Ewell > Sent: Wednesday, May 18, 2005 1:56 AM > To: LTRU Working Group > Subject: [Ltru] Re: [psg.com #954] all aliases must be > equally supported > > > I don't know if this particular issue got resolved yet, but I'm > concerned about an informative "Use" field that seems to run > counter to > the normative "Canonical" field. We have text all over the draft that > says processors should use a canonical subtag instead of an alias > whenever possible. This proposal would turn that on its ear; > you would > have situations where one tag would be canonical, yet processors would > actually be encouraged to use the other one. > > Or, alternatively, there would be only a "Use" field and no > "Canonical" > field. That would make "Use" into sort of an ersatz "Canonical," but > with none of the stability that the word "canonical" implies. > > I agree that the whole matter of "deprecated but canonical" subtags is > weird, but I'm not at all convinced this is the right solution. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 15:43:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUSQ-000392-AC; Wed, 18 May 2005 15:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUSO-00038e-GE for ltru@megatron.ietf.org; Wed, 18 May 2005 15:43:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29309 for ; Wed, 18 May 2005 15:43:48 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYUjN-0000Eq-1Q for ltru@ietf.org; Wed, 18 May 2005 16:01:25 -0400 Received: from h-64-105-35-94.snvacaid.dynamic.covad.net ([64.105.35.94] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYUSE-00041N-00 for ltru@ietf.org; Wed, 18 May 2005 12:43:43 -0700 Message-ID: <000a01c55be2$429f4d80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050517160342.SPBD28811.mta8.adelphia.net@megatron.ietf.org> <001001c55b60$7e03e660$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags Date: Wed, 18 May 2005 12:46:18 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, May 17, 2005 9:17 PM > Subject: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags > > As someone who liked John's original proposal, but wasn't ready to go to > war over it, I think Addison's suggestion to "permit or even encourage > it, but not require it" is an excellent compromise. ... It looks like we have a consensus on this one, so I've marked it "resolved", going with the compromise proposal with the subsequent tweaks discussed in this thread. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 15:54:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUcv-0006gw-Gg; Wed, 18 May 2005 15:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUct-0006gh-N6 for ltru@megatron.ietf.org; Wed, 18 May 2005 15:54:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02131 for ; Wed, 18 May 2005 15:54:40 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYUts-0001LK-9t for ltru@ietf.org; Wed, 18 May 2005 16:12:17 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 18 May 2005 19:54:53 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IGP00F74BAPMK@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 18 May 2005 19:54:25 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 18 May 2005 19:54:27 +0000 Date: Wed, 18 May 2005 20:54:24 +0100 From: Misha Wolf Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally support ed thread-index: AcVb22enII9oVXAUSQ6qSPO7Akp6hwAB5yFw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 18 May 2005 19:54:27.0357 (UTC) FILETIME=[65CD14D0:01C55BE3] X-Spam-Score: 0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Ira McDonald wrote: > First, aliases are _bad_ for the reliability of any protocol > or interface. The so-called 'preferred MIME name' label on > aliases in the IANA Charset Registry is useless and dangerous. We must insist that those creating tags use canonical values. Any other approach will lead to a broken Internet. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 16:05:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUnS-0003Yz-Kx; Wed, 18 May 2005 16:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUnR-0003SY-6K for ltru@megatron.ietf.org; Wed, 18 May 2005 16:05:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05684 for ; Wed, 18 May 2005 16:05:31 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYV4O-0002kT-Gz for ltru@ietf.org; Wed, 18 May 2005 16:23:08 -0400 Received: from h-64-105-35-94.snvacaid.dynamic.covad.net ([64.105.35.94] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYUn9-0003jR-00 for ltru@ietf.org; Wed, 18 May 2005 13:05:19 -0700 Message-ID: <007101c55be5$477956e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] [psg.com #954] all aliases must be equally supported Date: Wed, 18 May 2005 13:07:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "McDonald, Ira" > To: "'Doug Ewell'" ; "LTRU Working Group" > Sent: Wednesday, May 18, 2005 11:53 AM > Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed ... > The registry draft and the matching draft should make clear > that support for the Canonical subtags is REQUIRED, but > support for Alias subtags is merely RECOMMENDED. Your mileage > may vary. Required support for all registered aliases is a > bad idea and it will be ignored by the majority of implementors. ... This has been a long and winding (if not windy) thread. >From a technical perspective, I think there's been a lack of clarity on the distinction between support for a specific alias (whether an application knows what a particular subtag alias means) and support for alias subtags (meaning that an application that has a copy of the registry will know how to chase down the canonical data associated with an alias, and the application will be able to handle that alias as well (or as badly) as the canonical form.) >From a process perspective, after all this discussion, I'd like to see a proposal with specific text, since the finer points of the wording seem to be where the disagreements originate. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 16:17:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUyZ-0002CX-CN; Wed, 18 May 2005 16:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUyY-0002CE-F6 for ltru@megatron.ietf.org; Wed, 18 May 2005 16:17:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10997 for ; Wed, 18 May 2005 16:17:03 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYVFY-0004cZ-Ko for ltru@ietf.org; Wed, 18 May 2005 16:34:40 -0400 Received: from h-64-105-35-94.snvacaid.dynamic.covad.net ([64.105.35.94] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYUyH-0000T5-00 for ltru@ietf.org; Wed, 18 May 2005 13:16:50 -0700 Message-ID: <007d01c55be6$e369e1e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050518013420.IIMW28811.mta8.adelphia.net@megatron.ietf.org> <002301c55b63$dfdfc040$030aa8c0@DEWELL> Date: Wed, 18 May 2005 13:19:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] [psg.com #992] provide way to alias language-variant combination to a lang-extlang combination X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've followed up on the thread "grandfathered tags and generative capacity" by creating ticket [psg.com #992]. Please continue discussion of this issue using this ticket identifier in the subject line. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 16:32:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVD9-0002L6-Dw; Wed, 18 May 2005 16:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVD8-0002L1-LY for ltru@megatron.ietf.org; Wed, 18 May 2005 16:32:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17230 for ; Wed, 18 May 2005 16:32:05 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYVU6-0006sw-JP for ltru@ietf.org; Wed, 18 May 2005 16:49:43 -0400 Received: from h-64-105-35-94.snvacaid.dynamic.covad.net ([64.105.35.94] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYVD1-0005ON-00 for ltru@ietf.org; Wed, 18 May 2005 13:32:03 -0700 Message-ID: <009001c55be9$042d1c60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050516170302.ZTOM27459.mta2.adelphia.net@megatron.ietf.org> <008901c55b70$59717640$030aa8c0@DEWELL> Subject: Re: [Ltru] Open points before -02 Date: Wed, 18 May 2005 13:34:40 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, May 17, 2005 11:10 PM > Subject: [Ltru] Re: Open points before -02 > > Addison Phillips wrote: ... > > I suggested that an independent RFC be written to document record-jar > > for future generations, actually. > > I continue to think this is an excellent idea. Is it on-topic for this > WG, or should those of us who support this idea start meeting off-list > to discuss it? ... I'd rather not request any additions to our list of deliverables at this time, though I'd be willing to discuss it after we've finished our chartered deliverables. I think it would be better if those interested in such an RFC start their own mailing list, and perhaps discuss amongst themselves whether they might want to hold a BOF at the Paris IETF meeting. Since such work would be of interest to the members of this WG, announcing their mailing list's address on this mailing list would be appropriate. Likewise, informing this WG of their i-d's availability would also be appropriate. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 22:14:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYaWt-0008LK-58; Wed, 18 May 2005 22:12:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYaWr-0008Jm-BL for ltru@megatron.ietf.org; Wed, 18 May 2005 22:12:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17965 for ; Wed, 18 May 2005 22:12:50 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYanv-0001Pd-Iy for ltru@ietf.org; Wed, 18 May 2005 22:30:31 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4J2CfHR018168; Wed, 18 May 2005 22:12:42 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 18 May 2005 22:12:39 -0400 Date: Wed, 18 May 2005 22:12:39 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] [psg.com #992] provide way to alias language-variant combination to a lang-extlang combination Message-ID: <20050519021238.GB28377@skunk.reutershealth.com> References: <20050518013420.IIMW28811.mta8.adelphia.net@megatron.ietf.org> <002301c55b63$dfdfc040$030aa8c0@DEWELL> <007d01c55be6$e369e1e0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007d01c55be6$e369e1e0$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > I've followed up on the thread "grandfathered tags and generative > capacity" by creating ticket [psg.com #992]. Please continue > discussion of this issue using this ticket identifier in the > subject line. Okay. Peter Constable scripsit: > But now throw into this mix the fact that we have certain grandfathered > tags - grandfathered because they don't fit the general syntax. What > does someone do if they need to denote a category that's a restriction > on something for which there's a grandfathered tag? For example, what > does someone use to denote Mandarin written in traditional characters > for use in Mainland China? The issue here is that Mandarin Chinese has a > grandfathered tag of zh-guoyu. IMHO that should be treated purely as a grandfathered tag and not fitted into the generative system until we have the productive form zh-cmn available. The fact that 'guoyu' looks like a variant tag doesn't make it one, as Abraham Lincoln said about a dog's tail (it's not a leg even if you call it one). In fact, I formally propose that we modify section 3.7 as follows. Replace the following three paragraphs: # Tags that are not deprecated that consist entirely of subtags that are # valid under this document and which have the correct form and format for # tags defined by this document are superseded by this document. Such tags # are placed in records of type 'redundant' in the registry. For example, # "zh-Hant" is now defined by this document. # # Tags that are not deprecated and which contain subtags which are # consistent with registration under the guidelines in this document will # have a new subtag registration created for each eligible subtag. If all # of the subtags in the original tag are fully defined by the resulting # registrations or by this document, then the original tag is superseded # by this document. Such tags are placed in the 'redundant' section of # the registry. For example, "en-boont" will result in a new subtag # 'boont' and the RFC 3066 registered tag "en-boont" placed in the # redundant section of the registry. # # Tags that contain one or more subtags that do not match the valid # registration pattern and which are not otherwise defined by this # document will have records of type 'grandfathered' created in the # registry. with the following text: # Tags that are not deprecated that consist entirely of subtags that are # valid under this document, contain no variant or extension subtags, # and have the correct form and format for tags defined by this document # are superseded by this document. Such tags are placed in records of type # 'redundant' in the registry. For example, "zh-Hant" is now defined by # this document. # # All other tags will have records of type "grandfathered" created in the # registry. The effect of this is to initialize the registry with no subtags of type "variant". It will be up to ietf-languages@iana.org to add them as needed; presumably they will add 1901, 1996, boont, and scouse, but not guoyu. (This leads to another problem with grandfathered tags that I'll address in my next posting so it can get a new ticket number.) > zh-guoyu > > zh-cmn-Hant / zh-cmn-CN / zh-cmn-Hant-CN / etc. I think that's right, although of course zh-cmn will work too, once ISO 639-6 comes on line. -- And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods -- the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) John Cowan|jcowan@reutershealth.com|ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 22:26:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYajq-0003iM-6v; Wed, 18 May 2005 22:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYajp-0003iF-0p for ltru@megatron.ietf.org; Wed, 18 May 2005 22:26:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18764 for ; Wed, 18 May 2005 22:26:14 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYb0t-0001g7-Gh for ltru@ietf.org; Wed, 18 May 2005 22:43:55 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4J2Q5cl018230; Wed, 18 May 2005 22:26:06 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 18 May 2005 22:26:13 -0400 Date: Wed, 18 May 2005 22:26:13 -0400 From: John Cowan To: Peter Constable Subject: Re: [Ltru] grandfathered tags and generative capacity Message-ID: <20050519022613.GC28377@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable scripsit: > So, I guess what this boils down to is a suggestion that zh-guoyu, > zh-hakka, and zh-xiang be deprecated. Probably also cel-gaulish as well. We can't deprecate them until ISO 639-3 comes on line, and even then we can't directly deprecate cel-gaulish, because there's no exact 639-3 equivalent. Can you get the RA (proto-RA?) to allocate a macrolanguage code for Gaulish with Cisalpine and Transalpine Gaulish encompassed by it? That would solve the problem. -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com In might the Feanorians / that swore the unforgotten oath brought war into Arvernien / with burning and with broken troth. and Elwing from her fastness dim / then cast her in the waters wide, but like a mew was swiftly borne, / uplifted o'er the roaring tide. --the Earendillinwe _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 22:48:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYb50-00012j-Ro; Wed, 18 May 2005 22:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYb50-00012e-A6 for ltru@megatron.ietf.org; Wed, 18 May 2005 22:48:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20507 for ; Wed, 18 May 2005 22:48:07 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYbM4-0002Bu-1V for ltru@ietf.org; Wed, 18 May 2005 23:05:49 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4J2lwIU018364 for ; Wed, 18 May 2005 22:47:58 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 18 May 2005 22:48:05 -0400 Date: Wed, 18 May 2005 22:48:05 -0400 From: John Cowan To: ltru@ietf.org Message-ID: <20050519024804.GD28377@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Schizophrenic treatment of grandfathered tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The current draft can't make up its mind what to do about grandfathered tags that become ordinarily valid later on, as zh-yue will when we get ISO 693-3 tags. 2.2.2 says grandfathered tags can become redundant tags. 3.2 says the list of grandfathered tags is "permanent and stable", but grandfathered items can be deprecated. 3.3 says the Type field (which contains "grandfathered" as one option) MUST not be changed and is guaranteed stable over time. The last graf of 3.3 says grandfathered tags MUST become redundant if all their subtags become registered as an exception to the previous point. 3.4 says grandfathered tags may (not MAY) become deprecated due to registration of subtags. IMHO the resolution should be that grandfathered tags MUST become redundant (not deprecated) if all their subtags are registered, and deprecated if a replacement is found (like zh-cmn for zh-guoyu). -- When I'm stuck in something boring John Cowan where reading would be impossible or (who loves Asimov too) rude, I often set up math problems for jcowan@reutershealth.com myself and solve them as a way to pass http://www.ccil.org/~cowan the time. --John Jenkins http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 18 23:25:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYbeo-0001ic-96; Wed, 18 May 2005 23:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYbem-0001iT-85 for ltru@megatron.ietf.org; Wed, 18 May 2005 23:25:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22867 for ; Wed, 18 May 2005 23:25:05 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYbvq-000313-9y for ltru@ietf.org; Wed, 18 May 2005 23:42:47 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4J3Oq1E018555; Wed, 18 May 2005 23:24:53 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 18 May 2005 23:24:59 -0400 Date: Wed, 18 May 2005 23:24:59 -0400 From: John Cowan To: Randy Presuhn , Doug Ewell Subject: Re: [Ltru] Open points before -02 Message-ID: <20050519032459.GF28377@skunk.reutershealth.com> References: <20050516170302.ZTOM27459.mta2.adelphia.net@megatron.ietf.org> <008901c55b70$59717640$030aa8c0@DEWELL> <009001c55be9$042d1c60$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009001c55be9$042d1c60$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > I think it would be better if those interested in such an RFC start > their own mailing list, and perhaps discuss amongst themselves whether > they might want to hold a BOF at the Paris IETF meeting. Since such > work would be of interest to the members of this WG, announcing their > mailing list's address on this mailing list would be appropriate. I have created a mailing list for discussing a record-jar independent draft, record-jar@yahoogroups.com. You can sign up at http://groups.yahoo.com/group/record-jar/join if you are or wish to be a Yahoo Groups member, or by sending a blank email to mailto:record-jar-subscribe@yahoogroups.com if you aren't and don't. Signup is currently open, only members can post, and the archives are at http://groups.yahoo.com/group/record-jar/messages and open to all. I will be maintaining a backup of the archives publicly accessible so as to avoid the effects of bonehead moves by Yahoo. -- Evolutionary psychology is the theory John Cowan that men are nothing but horn-dogs, http://www.ccil.org/~cowan and that women only want them for their money. http://www.reutershealth.com --Susan McCarthy (adapted) jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 07:21:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYj5g-0001Kx-3Y; Thu, 19 May 2005 07:21:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYj5d-0001Ks-Ug for ltru@megatron.ietf.org; Thu, 19 May 2005 07:21:22 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23138 for ; Thu, 19 May 2005 07:21:19 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DYj3Q-0001WE-AF for ltru@lists.ietf.org; Thu, 19 May 2005 13:19:04 +0200 Received: from 62.80.58.103 ([62.80.58.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2005 13:19:04 +0200 Received: from nobody by 62.80.58.103 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2005 13:19:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 19 May 2005 13:18:06 +0200 Organization: Lines: 38 Message-ID: <428C75EE.23D7@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.103 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support ed X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira wrote: [aliases] > The so-called 'preferred MIME name' label on aliases in the > IANA Charset Registry is useless and dangerous. We don't make them up for fun, they just happen, like YU -> CS or jw -> jv. Or the grandfathered cases like i-klingon -> tlh. > Whenever possible, the language tag registry draft should not > encourage the proliferation of aliases for tags or subtags. It doesn't, actually it tries to avoid them like hell. > support for the Canonical subtags is REQUIRED, but support > for Alias subtags is merely RECOMMENDED. IBTD, the subject says it all. > Your mileage may vary. Certainly. The complete concept of "Canonical:" appears to be wrong, if you even think about any "let's forget the rest". The more flexible "Use:" concept (all aliases pointing to the same "best current practice" tag) is better. > Required support for all registered aliases is a bad idea and > it will be ignored by the majority of implementors. Supporting only an obsolete idea of "Canonical:" as stated in an obscure IANA registry not reflecting the state of the art in the source standards after date-B was a worse idea. With 7000+ languages our few aliases can't be the showstopper. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 07:49:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjX8-0001Xg-01; Thu, 19 May 2005 07:49:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjX7-0001Xb-DG for ltru@megatron.ietf.org; Thu, 19 May 2005 07:49:45 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25309 for ; Thu, 19 May 2005 07:49:43 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DYjUQ-0005LV-Kp for ltru@lists.ietf.org; Thu, 19 May 2005 13:46:58 +0200 Received: from 62.80.58.103 ([62.80.58.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2005 13:46:58 +0200 Received: from nobody by 62.80.58.103 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2005 13:46:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 19 May 2005 13:44:32 +0200 Organization: Lines: 27 Message-ID: <428C7C20.2D5B@xyzzy.claranet.de> References: <20050516170302.ZTOM27459.mta2.adelphia.net@megatron.ietf.org> <008901c55b70$59717640$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.103 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Open points before -02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: >> I suggested that an independent RFC be written to document >> record-jar for future generations, actually. > I continue to think this is an excellent idea. Don't get me wrong, but IMHO it's just a topological transformation of e.g. CSV (comma separated values) or your very similar old format. It's nice to squeeze something into an I-D or into a plain text file. Some redundancy (all column titles repeated again and again as field names), that _can_ be an advantage, but more likely it's a pain. I also don't see why that should be an _Internet_ draft or a RfC, it's more like a dbase or SQL view. In can replace XML in simple cases, so that sounds more like "W3C" than "IETF" for me. I'm not really trying to discourage you and John, but I won't jump to the "record-jar" list while there are still more pressing issues with SPF and USEFOR on my agenda. . Or my UTF-[ultra-secret] project... :-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 08:34:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYkEg-0006CD-BN; Thu, 19 May 2005 08:34:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYkEe-0006Bw-0q for ltru@megatron.ietf.org; Thu, 19 May 2005 08:34:44 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29317 for ; Thu, 19 May 2005 08:34:41 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DYkBn-00037i-Kx for ltru@lists.ietf.org; Thu, 19 May 2005 14:31:47 +0200 Received: from 62.80.58.103 ([62.80.58.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2005 14:31:47 +0200 Received: from nobody by 62.80.58.103 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2005 14:31:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 19 May 2005 14:29:27 +0200 Organization: Lines: 28 Message-ID: <428C86A7.40C8@xyzzy.claranet.de> References: <20050518013420.IIMW28811.mta8.adelphia.net@megatron.ietf.org> <002301c55b63$dfdfc040$030aa8c0@DEWELL> <007d01c55be6$e369e1e0$7f1afea9@oemcomputer> <20050519021238.GB28377@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.103 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #992] provide way to alias language-variant combination to a lang-extlang combination X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > The effect of this is to initialize the registry with no > subtags of type "variant". It will be up to > ietf-languages@iana.org to add them as needed; presumably > they will add 1901, 1996, boont, and scouse, but not guoyu. And what's the procedure to get rid of zh-guoyu as soon as something better is availale ? Scanning draft -01 quickly I found a forward reference to 3.7 (= what you want to update) in 3.2: | although grandfathered items may be deprecated over time. | Refer to Section 3.7 for more information. But in 3.7 I lost it, is the deprecation an automatical side- effect of "something better was added", and the tag reviewer is expected to catch it, or is this always required to be a separate procedure ? BTW, we're talking about only ten variants, and you enumerated four as almost clear (1901, 1996, boont, scouse). That leaves cel-gaulish, sl-nedis, sl-rozaj, and the three zh variants. If whatever you want makes the draft shorter I'd support it :-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 12:32:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnwz-0005Q0-P8; Thu, 19 May 2005 12:32:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnwy-0005On-FG for ltru@megatron.ietf.org; Thu, 19 May 2005 12:32:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22661 for ; Thu, 19 May 2005 12:32:39 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYoE7-0007DJ-Pr for ltru@ietf.org; Thu, 19 May 2005 12:50:28 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 09:32:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #992] provide way to alias language-variantcombination to a lang-extlang combination Date: Thu, 19 May 2005 09:32:27 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B732A1A@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #992] provide way to alias language-variantcombination to a lang-extlang combination Thread-Index: AcVcGJYvIVlin6qPQleM0hCE6iSz3AAdx2Vg From: "Addison Phillips" To: "John Cowan" , "Randy Presuhn" X-OriginalArrivalTime: 19 May 2005 16:32:28.0628 (UTC) FILETIME=[58E38940:01C55C90] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Grandfathering all the junk in the registry seems like a useful = compromise. If a variant subtag ('nedis' and 'rozaj' come immediately to = mind) are still useful, then they can be individually registered as = variants after the adoption of the RFC and the grandfathered tags = converted to redundant at that point. Then we ensure the text allows grandfathered tags to become deprecated = and mapped. This allows "zh-gouyu" to be mapped to "zh-cmn" in the = future. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: mercredi 18 mai 2005 19:13 > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #992] provide way to alias language- > variantcombination to a lang-extlang combination >=20 > Randy Presuhn scripsit: >=20 > > I've followed up on the thread "grandfathered tags and generative > > capacity" by creating ticket [psg.com #992]. Please continue > > discussion of this issue using this ticket identifier in the > > subject line. >=20 > Okay. >=20 > Peter Constable scripsit: >=20 > > But now throw into this mix the fact that we have certain = grandfathered > > tags - grandfathered because they don't fit the general syntax. What > > does someone do if they need to denote a category that's a = restriction > > on something for which there's a grandfathered tag? For example, = what > > does someone use to denote Mandarin written in traditional = characters > > for use in Mainland China? The issue here is that Mandarin Chinese = has a > > grandfathered tag of zh-guoyu. >=20 > IMHO that should be treated purely as a grandfathered tag and not = fitted > into the generative system until we have the productive form zh-cmn > available. The fact that 'guoyu' looks like a variant tag doesn't = make it > one, > as Abraham Lincoln said about a dog's tail (it's not a leg even if you > call it one). >=20 > In fact, I formally propose that we modify section 3.7 as follows. > Replace > the following three paragraphs: >=20 > # Tags that are not deprecated that consist entirely of subtags that = are > # valid under this document and which have the correct form and format = for > # tags defined by this document are superseded by this document. Such = tags > # are placed in records of type 'redundant' in the registry. For = example, > # "zh-Hant" is now defined by this document. > # > # Tags that are not deprecated and which contain subtags which are > # consistent with registration under the guidelines in this document = will > # have a new subtag registration created for each eligible subtag. If = all > # of the subtags in the original tag are fully defined by the = resulting > # registrations or by this document, then the original tag is = superseded > # by this document. Such tags are placed in the 'redundant' section of > # the registry. For example, "en-boont" will result in a new subtag > # 'boont' and the RFC 3066 registered tag "en-boont" placed in the > # redundant section of the registry. > # > # Tags that contain one or more subtags that do not match the valid > # registration pattern and which are not otherwise defined by this > # document will have records of type 'grandfathered' created in the > # registry. >=20 > with the following text: >=20 > # Tags that are not deprecated that consist entirely of subtags that = are > # valid under this document, contain no variant or extension subtags, > # and have the correct form and format for tags defined by this = document > # are superseded by this document. Such tags are placed in records of = type > # 'redundant' in the registry. For example, "zh-Hant" is now defined = by > # this document. > # > # All other tags will have records of type "grandfathered" created in = the > # registry. >=20 > The effect of this is to initialize the registry with no subtags of = type > "variant". It will be up to ietf-languages@iana.org to add them as > needed; presumably they will add 1901, 1996, boont, and scouse, but = not > guoyu. >=20 > (This leads to another problem with grandfathered tags that I'll = address > in my next posting so it can get a new ticket number.) >=20 > > zh-guoyu > > > > zh-cmn-Hant / zh-cmn-CN / zh-cmn-Hant-CN / etc. >=20 > I think that's right, although of course zh-cmn will work too, > once ISO 639-6 comes on line. >=20 > -- > And through this revolting graveyard of the universe the muffled, > maddening > beating of drums, and thin, monotonous whine of blasphemous flutes = from > inconceivable, unlighted chambers beyond Time; the detestable pounding > and piping whereunto dance slowly, awkwardly, and absurdly the = gigantic > tenebrous ultimate gods -- the blind, voiceless, mindless gargoyles = whose > soul > is Nyarlathotep. (Lovecraft) John > Cowan|jcowan@reutershealth.com|ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 13:05:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYoSw-0006WJ-TT; Thu, 19 May 2005 13:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYoSY-0006QV-1u for ltru@megatron.ietf.org; Thu, 19 May 2005 13:05:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25268 for ; Thu, 19 May 2005 13:05:18 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYojf-00086o-PD for ltru@ietf.org; Thu, 19 May 2005 13:23:08 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4JH4v0c024747 for ; Thu, 19 May 2005 13:04:57 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JH4vW5108082 for ; Thu, 19 May 2005 13:04:57 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4JH4vhj026343 for ; Thu, 19 May 2005 13:04:57 -0400 Received: from markdavis (sig-9-48-127-219.mts.ibm.com [9.48.127.219]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j4JH4to1026248; Thu, 19 May 2005 13:04:57 -0400 Message-ID: <032b01c55c94$e0ab11f0$4d6e3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "John Cowan" , "Randy Presuhn" References: <634978A7DF025A40BFEF33EB191E13BC0B732A1A@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #992] provide way to aliaslanguage-variantcombination to a lang-extlang combination Date: Thu, 19 May 2005 10:04:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id j4JH4v0c024747 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I agree. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "John Cowan" ; "Randy Presuhn" Cc: Sent: Thursday, May 19, 2005 09:32 Subject: RE: [Ltru] [psg.com #992] provide way to aliaslanguage-variantcombination to a lang-extlang combination Grandfathering all the junk in the registry seems like a useful compromis= e. If a variant subtag ('nedis' and 'rozaj' come immediately to mind) are st= ill useful, then they can be individually registered as variants after the adoption of the RFC and the grandfathered tags converted to redundant at that point. Then we ensure the text allows grandfathered tags to become deprecated an= d mapped. This allows "zh-gouyu" to be mapped to "zh-cmn" in the future. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: mercredi 18 mai 2005 19:13 > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #992] provide way to alias language- > variantcombination to a lang-extlang combination > > Randy Presuhn scripsit: > > > I've followed up on the thread "grandfathered tags and generative > > capacity" by creating ticket [psg.com #992]. Please continue > > discussion of this issue using this ticket identifier in the > > subject line. > > Okay. > > Peter Constable scripsit: > > > But now throw into this mix the fact that we have certain grandfather= ed > > tags - grandfathered because they don't fit the general syntax. What > > does someone do if they need to denote a category that's a restrictio= n > > on something for which there's a grandfathered tag? For example, what > > does someone use to denote Mandarin written in traditional characters > > for use in Mainland China? The issue here is that Mandarin Chinese ha= s a > > grandfathered tag of zh-guoyu. > > IMHO that should be treated purely as a grandfathered tag and not fitte= d > into the generative system until we have the productive form zh-cmn > available. The fact that 'guoyu' looks like a variant tag doesn't make= it > one, > as Abraham Lincoln said about a dog's tail (it's not a leg even if you > call it one). > > In fact, I formally propose that we modify section 3.7 as follows. > Replace > the following three paragraphs: > > # Tags that are not deprecated that consist entirely of subtags that ar= e > # valid under this document and which have the correct form and format = for > # tags defined by this document are superseded by this document. Such t= ags > # are placed in records of type 'redundant' in the registry. For exampl= e, > # "zh-Hant" is now defined by this document. > # > # Tags that are not deprecated and which contain subtags which are > # consistent with registration under the guidelines in this document wi= ll > # have a new subtag registration created for each eligible subtag. If a= ll > # of the subtags in the original tag are fully defined by the resulting > # registrations or by this document, then the original tag is supersede= d > # by this document. Such tags are placed in the 'redundant' section of > # the registry. For example, "en-boont" will result in a new subtag > # 'boont' and the RFC 3066 registered tag "en-boont" placed in the > # redundant section of the registry. > # > # Tags that contain one or more subtags that do not match the valid > # registration pattern and which are not otherwise defined by this > # document will have records of type 'grandfathered' created in the > # registry. > > with the following text: > > # Tags that are not deprecated that consist entirely of subtags that ar= e > # valid under this document, contain no variant or extension subtags, > # and have the correct form and format for tags defined by this documen= t > # are superseded by this document. Such tags are placed in records of t= ype > # 'redundant' in the registry. For example, "zh-Hant" is now defined by > # this document. > # > # All other tags will have records of type "grandfathered" created in t= he > # registry. > > The effect of this is to initialize the registry with no subtags of typ= e > "variant". It will be up to ietf-languages@iana.org to add them as > needed; presumably they will add 1901, 1996, boont, and scouse, but not > guoyu. > > (This leads to another problem with grandfathered tags that I'll addres= s > in my next posting so it can get a new ticket number.) > > > zh-guoyu > > > > zh-cmn-Hant / zh-cmn-CN / zh-cmn-Hant-CN / etc. > > I think that's right, although of course zh-cmn will work too, > once ISO 639-6 comes on line. > > -- > And through this revolting graveyard of the universe the muffled, > maddening > beating of drums, and thin, monotonous whine of blasphemous flutes from > inconceivable, unlighted chambers beyond Time; the detestable pounding > and piping whereunto dance slowly, awkwardly, and absurdly the gigantic > tenebrous ultimate gods -- the blind, voiceless, mindless gargoyles who= se > soul > is Nyarlathotep. (Lovecraft) John > Cowan|jcowan@reutershealth.com|ccil.org/~cowan > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 13:20:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYohC-0003JP-7A; Thu, 19 May 2005 13:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYohA-0003J8-MB for ltru@megatron.ietf.org; Thu, 19 May 2005 13:20:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26580 for ; Thu, 19 May 2005 13:20:25 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYoyK-00006N-Oa for ltru@ietf.org; Thu, 19 May 2005 13:38:15 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 10:20:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Thu, 19 May 2005 10:20:13 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B732A62@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Thread-Index: AcVcZRznRzQdjb1JTm+rCKcwTCa3TAALY5+Q From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 19 May 2005 17:20:16.0272 (UTC) FILETIME=[06234900:01C55C97] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 All that would be required to achieve this (if we also adopt John = Cowan's suggestion from #992) would be to change Canonical-Value to work = more-or-less like "Use" by modifying this paragraph: None of the subtags in the language tag has a Canonical-Value mapping = in the IANA registry (see ). Subtags = with=20 a Canonical-Value mapping MUST be replaced with their mapping in = order=20 to canonicalize the tag. To this paragraph: Subtags of type 'Region' that have a Canonical-Value mapping=20 in the IANA registry (see ) SHOULD be = replaced with their mapped value. And add these paragraphs for the remaining ISO 639 corrections and = grandfathered/redundant garbage collection: Redundant or grandfathered tags that have a Canonical-Value = mapping=20 in the IANA registry (see ) SHOULD = (MUST??) be replaced with their mapped value. These items are either deprecated mappings created before the adoption of this document (such as the mapping of "no-nyn" to 'nn' or "i-klingon" to 'tlh') or are the result of later registrations or additions to this document (for example, "zh-gouyu" might be mapped to a=20 language-extlang combination such as "zh-cmn" by some future=20 update of this document). Other subtags that have a Canonical-Value mapping=20 in the IANA registry (see ) MUST be replaced with their mapped value. These items consist entirely of = =20 clerical corrections to ISO 639-1 in which the deprecated subtags have been maintained for compatibility purposes. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 19 mai 2005 04:18 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support = ed >=20 > McDonald, Ira wrote: >=20 > [aliases] > > The so-called 'preferred MIME name' label on aliases in the > > IANA Charset Registry is useless and dangerous. >=20 > We don't make them up for fun, they just happen, like YU -> CS > or jw -> jv. Or the grandfathered cases like i-klingon -> tlh. >=20 > > Whenever possible, the language tag registry draft should not > > encourage the proliferation of aliases for tags or subtags. >=20 > It doesn't, actually it tries to avoid them like hell. >=20 > > support for the Canonical subtags is REQUIRED, but support > > for Alias subtags is merely RECOMMENDED. >=20 > IBTD, the subject says it all. >=20 > > Your mileage may vary. >=20 > Certainly. The complete concept of "Canonical:" appears to be > wrong, if you even think about any "let's forget the rest". >=20 > The more flexible "Use:" concept (all aliases pointing to the > same "best current practice" tag) is better. >=20 > > Required support for all registered aliases is a bad idea and > > it will be ignored by the majority of implementors. >=20 > Supporting only an obsolete idea of "Canonical:" as stated in > an obscure IANA registry not reflecting the state of the art > in the source standards after date-B was a worse idea. >=20 > With 7000+ languages our few aliases can't be the showstopper. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 13:59:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpJF-0005bB-Kb; Thu, 19 May 2005 13:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpJE-0005b0-FC for ltru@megatron.ietf.org; Thu, 19 May 2005 13:59:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00012 for ; Thu, 19 May 2005 13:59:47 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYpaQ-0001CU-4T for ltru@ietf.org; Thu, 19 May 2005 14:17:35 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4JHxaXF022204; Thu, 19 May 2005 13:59:36 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 19 May 2005 13:59:35 -0400 Date: Thu, 19 May 2005 13:59:35 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Message-ID: <20050519175935.GE2322@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B732A62@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B732A62@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > Redundant or grandfathered tags that have a Canonical-Value mapping > in the IANA registry (see ) SHOULD (MUST??) > be replaced with their mapped value. These items are either > deprecated mappings created before the adoption of this document > (such as the mapping of "no-nyn" to 'nn' or "i-klingon" to 'tlh') > or are the result of later registrations or additions to this > document (for example, "zh-gouyu" might be mapped to a > language-extlang combination such as "zh-cmn" by some future > update of this document). This still suffers from the problem that we don't know what the Canonical-Value is used for. For example, there is no indication whether "no-nyn" is mapped to the *language* tag 'nn' or to the *region* tag 'nn' (not currently defined, but could be). A subtag will be canonicalized to a subtag of the same type, but a grandfathered tag could be canonicalized to any kind of subtag or a combination of subtags. We need a provision for this. (Credit: Doug has been making this point repeatedly.) -- Don't be so humble. You're not that great. John Cowan --Golda Meir jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 14:02:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpM2-0006DN-Fg; Thu, 19 May 2005 14:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpLz-00069j-Uv for ltru@megatron.ietf.org; Thu, 19 May 2005 14:02:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00440 for ; Thu, 19 May 2005 14:02:38 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYpdA-0001I6-9B for ltru@ietf.org; Thu, 19 May 2005 14:20:26 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 11:02:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Thu, 19 May 2005 11:02:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B732AB5@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Thread-Index: AcVcnJiajsYlV4OkSdu60xUJHfc/UwAACmGA From: "Addison Phillips" To: "John Cowan" X-OriginalArrivalTime: 19 May 2005 18:02:25.0678 (UTC) FILETIME=[E9C802E0:01C55C9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Not true. Here is the governing text: # For fields of type 'language', 'extlang', 'script', 'region', and = 'variant', a canonical mapping of this record to a subtag record of the = same 'Type'. # For fields of type 'grandfathered' and 'redundant', a canonical = mapping to a complete language tag. "no-nyn" is of type "grandfathered", thus it is a complete language tag = and thus "nn" is of type "language". Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: jeudi 19 mai 2005 11:00 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally = support > ed >=20 > Addison Phillips scripsit: >=20 > > Redundant or grandfathered tags that have a Canonical-Value > mapping > > in the IANA registry (see ) = SHOULD > (MUST??) > > be replaced with their mapped value. These items are either > > deprecated mappings created before the adoption of this = document > > (such as the mapping of "no-nyn" to 'nn' or "i-klingon" to = 'tlh') > > or are the result of later registrations or additions to this > > document (for example, "zh-gouyu" might be mapped to a > > language-extlang combination such as "zh-cmn" by some future > > update of this document). >=20 > This still suffers from the problem that we don't know what the = Canonical- > Value > is used for. For example, there is no indication whether "no-nyn" is > mapped > to the *language* tag 'nn' or to the *region* tag 'nn' (not currently > defined, > but could be). A subtag will be canonicalized to a subtag of the > same type, but a grandfathered tag could be canonicalized to any kind = of > subtag or a combination of subtags. We need a provision for this. >=20 > (Credit: Doug has been making this point repeatedly.) >=20 > -- > Don't be so humble. You're not that great. John Cowan > --Golda Meir > jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 14:33:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpqC-00075j-Re; Thu, 19 May 2005 14:33:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpqA-00070X-Fh for ltru@megatron.ietf.org; Thu, 19 May 2005 14:33:50 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03800 for ; Thu, 19 May 2005 14:33:45 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DYpnG-0007eI-PC for ltru@lists.ietf.org; Thu, 19 May 2005 20:30:50 +0200 Received: from 62.80.58.103 ([62.80.58.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2005 20:30:50 +0200 Received: from nobody by 62.80.58.103 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2005 20:30:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 19 May 2005 20:11:48 +0200 Organization: Lines: 52 Message-ID: <428CD6E4.6C5C@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B732A62@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.103 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > change Canonical-Value to work more-or-less like "Use" That's a plan. Replacing it by Use: later if Ira still thinks that implementors might get Canonical: wrong is no problem. > Subtags of type 'Region' that have a Canonical-Value mapping > in the IANA registry (see ) SHOULD > be replaced with their mapped value. Why is it restricted to regions ? Any iw, ji, and jw should be also replaced, dito grandfathered tags, dito future deprecated variants, or all other future modifications introducing a new "best current practice" alias - whether we like it or not. > Redundant or grandfathered tags that have a Canonical-Value > mapping in the IANA registry (see ) > SHOULD (MUST??) be replaced with their mapped value. That's about redundant _and_ deprecated at the same time, like a hypothetical ji-Latn. I'd still prefer to grab the complete redundant tags, put them into an appendix, and then forget it. If that's still possible with John's idea. SHOULD. A worldwide "MUST retag everything" won't fly. It's also unnecessary if we get Ira's okay that implementors won't ignore aliases, all tags are stable. > Other subtags that have a Canonical-Value mapping in the IANA > registry (see ) MUST be replaced > with their mapped value. Okay, here you get jw etc. I'm still lost why NH -> TV should be different from jw -> jv (i.e. from a future similar case). > These items consist entirely of clerical corrections to > ISO 639-1 in which the deprecated subtags have been > maintained for compatibility purposes. At the moment. What about future deprecated variants, or a future deprecated registered-lang ? The "Use:" idea is to go with the relevant standard as far as possible, The limit is a collision with a registered subtag. That's only possible for 3166-1 region codes, and then the registry would switch to the UN number if it exists, otherwise the poor tag reviewer should get a danger bonus... ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 14:49:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYq5Z-0003Mq-Rn; Thu, 19 May 2005 14:49:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYq5Y-0003Ml-Pw for ltru@megatron.ietf.org; Thu, 19 May 2005 14:49:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05744 for ; Thu, 19 May 2005 14:49:43 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYqMi-0002ff-WE for ltru@ietf.org; Thu, 19 May 2005 15:07:32 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4JInST8022472; Thu, 19 May 2005 14:49:29 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 19 May 2005 14:48:27 -0400 Date: Thu, 19 May 2005 14:48:27 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally supported Message-ID: <20050519184827.GH2322@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B732A62@irvmbxw01.quest.com> <428CD6E4.6C5C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428CD6E4.6C5C@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > Why is it restricted to regions ? Any iw, ji, and jw should be > also replaced, dito grandfathered tags, dito future deprecated > variants, or all other future modifications introducing a new > "best current practice" alias - whether we like it or not. Because we know where the ISO 639 and 15924 Registration Authorities live, and we know which keys to turn if they misbehave. :-) > > Redundant or grandfathered tags that have a Canonical-Value > > mapping in the IANA registry (see ) > > SHOULD (MUST??) be replaced with their mapped value. > > That's about redundant _and_ deprecated at the same time, like > a hypothetical ji-Latn. I'd still prefer to grab the complete > redundant tags, put them into an appendix, and then forget it. > If that's still possible with John's idea. Still possible, but some tags may become redundant in future, like en-boont (once boont is a registered variant) and zh-yue (once extlangs are turned on and yue is a registered extlang encompassed by zh). > SHOULD. A worldwide "MUST retag everything" won't fly. It's > also unnecessary if we get Ira's okay that implementors won't > ignore aliases, all tags are stable. This is about canonicalization, which didn't exist before, so MUST is appropriate. Generating tags in canonicalized form is, as a whole, a SHOULD. -- John Cowan www.reutershealth.com www.ccil.org/~cowan jcowan@reutershealth.com 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 16:20:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrVY-0006wD-UD; Thu, 19 May 2005 16:20:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrVW-0006w8-Ug for ltru@megatron.ietf.org; Thu, 19 May 2005 16:20:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26916 for ; Thu, 19 May 2005 16:20:32 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYrme-00016c-B8 for ltru@ietf.org; Thu, 19 May 2005 16:38:22 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4JKKIOA010107 for ; Thu, 19 May 2005 16:20:18 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JKKHW5102478 for ; Thu, 19 May 2005 16:20:18 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4JKKH4w009781 for ; Thu, 19 May 2005 16:20:17 -0400 Received: from markdavis ([9.43.213.118]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j4JKKGmU009675; Thu, 19 May 2005 16:20:17 -0400 Message-ID: <038201c55cb0$2a78b380$4d6e3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Frank Ellermann" , References: <634978A7DF025A40BFEF33EB191E13BC0B732A62@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Thu, 19 May 2005 13:20:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j4JKKIOA010107 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I have to look this over in detail, but a crucial requirement is to guarantee the invariant: if isValid(tag, date1), then canonicalize(tag, date1) =3D canonicalize(ta= g, date2), for all date2 > date1 Does this still preserve that? =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Frank Ellermann" ; Sent: Thursday, May 19, 2005 10:20 Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally suppor= t ed +1 All that would be required to achieve this (if we also adopt John Cowan's suggestion from #992) would be to change Canonical-Value to work more-or-less like "Use" by modifying this paragraph: None of the subtags in the language tag has a Canonical-Value mapping in the IANA registry (see ). Subtags w= ith a Canonical-Value mapping MUST be replaced with their mapping in or= der to canonicalize the tag. To this paragraph: Subtags of type 'Region' that have a Canonical-Value mapping in the IANA registry (see ) SHOULD be replaced with their mapped value. And add these paragraphs for the remaining ISO 639 corrections and grandfathered/redundant garbage collection: Redundant or grandfathered tags that have a Canonical-Value mapping in the IANA registry (see ) SHOULD (MU= ST??) be replaced with their mapped value. These items are either deprecated mappings created before the adoption of this document (such as the mapping of "no-nyn" to 'nn' or "i-klingon" to 'tlh') or are the result of later registrations or additions to this document (for example, "zh-gouyu" might be mapped to a language-extlang combination such as "zh-cmn" by some future update of this document). Other subtags that have a Canonical-Value mapping in the IANA registry (see ) MUST be replaced with their mapped value. These items consist entirely of clerical corrections to ISO 639-1 in which the deprecated subtags have been maintained for compatibility purposes. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 19 mai 2005 04:18 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support = ed > > McDonald, Ira wrote: > > [aliases] > > The so-called 'preferred MIME name' label on aliases in the > > IANA Charset Registry is useless and dangerous. > > We don't make them up for fun, they just happen, like YU -> CS > or jw -> jv. Or the grandfathered cases like i-klingon -> tlh. > > > Whenever possible, the language tag registry draft should not > > encourage the proliferation of aliases for tags or subtags. > > It doesn't, actually it tries to avoid them like hell. > > > support for the Canonical subtags is REQUIRED, but support > > for Alias subtags is merely RECOMMENDED. > > IBTD, the subject says it all. > > > Your mileage may vary. > > Certainly. The complete concept of "Canonical:" appears to be > wrong, if you even think about any "let's forget the rest". > > The more flexible "Use:" concept (all aliases pointing to the > same "best current practice" tag) is better. > > > Required support for all registered aliases is a bad idea and > > it will be ignored by the majority of implementors. > > Supporting only an obsolete idea of "Canonical:" as stated in > an obscure IANA registry not reflecting the state of the art > in the source standards after date-B was a worse idea. > > With 7000+ languages our few aliases can't be the showstopper. > > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 16:38:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrmQ-0004uO-9k; Thu, 19 May 2005 16:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrmP-0004uE-64 for ltru@megatron.ietf.org; Thu, 19 May 2005 16:38:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28760 for ; Thu, 19 May 2005 16:38:02 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYs3c-0001cW-3i for ltru@ietf.org; Thu, 19 May 2005 16:55:53 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4JKbotD023013; Thu, 19 May 2005 16:37:53 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 19 May 2005 16:37:46 -0400 Date: Thu, 19 May 2005 16:37:46 -0400 From: John Cowan To: Mark Davis Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Message-ID: <20050519203746.GJ2322@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B732A62@irvmbxw01.quest.com> <038201c55cb0$2a78b380$4d6e3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <038201c55cb0$2a78b380$4d6e3009@sanjose.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis scripsit: > I have to look this over in detail, but a crucial requirement is to > guarantee the invariant: > > if isValid(tag, date1), then canonicalize(tag, date1) = canonicalize(tag, > date2), for all date2 > date1 > > Does this still preserve that? It does not preserve that invariant for grandfathered tags: they remain always valid but not necessarily always canonical. I think we should be able to live with that, as the alternative is very ugly: we will be stuck with some linguistic objects that can never have generative names. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 18:15:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtJ9-0002GU-E1; Thu, 19 May 2005 18:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtJ6-0002GK-Fn for ltru@megatron.ietf.org; Thu, 19 May 2005 18:15:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07532 for ; Thu, 19 May 2005 18:15:51 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYtaG-0004JI-4U for ltru@ietf.org; Thu, 19 May 2005 18:33:43 -0400 Received: from h-68-166-38-112.snvacaid.dynamic.covad.net ([68.166.38.112] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYtIu-00036W-00 for ltru@ietf.org; Thu, 19 May 2005 15:15:44 -0700 Message-ID: <00ce01c55cc0$aa82c420$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #901] add "Deprecated" field Date: Thu, 19 May 2005 15:18:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've marked this resolved, since it's included in the -01 draft and has been assumed by much of the discussion. Randy, ltru co-chair > From: > To: > Cc: > Sent: Thursday, April 07, 2005 7:12 PM > Subject: [Ltru] Re: [psg.com #901] add "Deprecated" field > > Hi - > > Message http://www.ietf.org/mail-archive/web/ltru/current/msg00479.htm > proposes adding a "Deprecated" field. > > Discussion? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 18:22:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtPi-0005md-Uw; Thu, 19 May 2005 18:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtPh-0005mS-CJ for ltru@megatron.ietf.org; Thu, 19 May 2005 18:22:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09093 for ; Thu, 19 May 2005 18:22:42 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYtgw-0004eE-0T for ltru@ietf.org; Thu, 19 May 2005 18:40:34 -0400 Received: from h-68-166-38-112.snvacaid.dynamic.covad.net ([68.166.38.112] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYtPe-0005A5-00 for ltru@ietf.org; Thu, 19 May 2005 15:22:43 -0700 Message-ID: <00dd01c55cc1$a5523980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] [psg.com #894] add figure-of-merit matching Date: Thu, 19 May 2005 15:25:21 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Proposal for additional matching algorithms appeared in > http://www.ietf.org/mail-archive/web/ltru/current/msg00313.html > > Though additional discussion on the details is needed, > I think there is a clear consensus that this approach should be > added to the matching document, and that this issue can be > marked "resolved" when that i-d becomes available. > > Randy There was substantial discussion, and the -00 i-d is now available, incorporating this as "scored matching", so I've marked this item "resolved". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 18:52:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtss-0005na-1n; Thu, 19 May 2005 18:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtsp-0005cX-VZ for ltru@megatron.ietf.org; Thu, 19 May 2005 18:52:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12030 for ; Thu, 19 May 2005 18:52:46 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYu9z-0005Qe-6R for ltru@ietf.org; Thu, 19 May 2005 19:10:36 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 15:52:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 May 2005 15:52:30 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B732C8C@irvmbxw01.quest.com> Thread-Topic: while we're housekeeping... Thread-Index: AcVcxXDIMHgCPCsoTx2CEC0GBzWLgA== From: "Addison Phillips" To: X-OriginalArrivalTime: 19 May 2005 22:52:30.0595 (UTC) FILETIME=[6FEB9530:01C55CC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] while we're housekeeping... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0917063137==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0917063137== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBzZWUgdGhlIGZvbGxvd2luZyBpc3N1ZXMgb3BlbiBpbiBSVCB0aGF0IHNob3VsZCBiZSBtYXJr ZWQgY2xvc2VkIGZvciB0aGUgcmVhc29ucyBzaG93bjoNCg0KIzkzNDogdGhpcyB3YXMgZGlzY3Vz c2VkOiB0aGUgcmVsZXZhbnQgdGV4dCByZXF1aXJlcyBhdCBsZWFzdCBvbmUgZGVzY3JpcHRpb24g dGhhdCB1c2VzIExhdGluIHRleHQgYnV0IGFsbG93cyB0aGUgZnVsbCBVbmljb2RlIHJlcGVydG9p cmUgb3RoZXJ3aXNlLg0KDQojOTYzOiB0aGlzIHNlY3Rpb24gd2FzIGhlYXZpbHkgcmV3b3JrZWQg aW4gZHJhZnQtMDEgdG8gYWRkcmVzcyB0aGUgY29uY2VybnMgcmFpc2VkIGhlcmUuDQoNCiM5NjQ6 IHNob3VsZCBiZSByZWplY3RlZCwgYWx0aG91Z2ggc3Vic3RhbnRpYWwgY2hhbmdlcyB3ZXJlIG1h ZGUgaW4gdGhpcyBzZWN0aW9uIGluIGRyYWZ0LTAxIGluIHBhcnQgYXMgYSByZXN1bHQgb2YgdGhp cyBjb21tZW50Lg0KDQojOTY1OiBzaG91bGQgYmUgY2xvc2VkLiBUaGlzIHdhcyBjaGFuZ2VkIHN1 YnN0YW50aWFsbHkgaW4gZHJhZnQtMDENCg0KIzk3MDogc2hvdWxkIGJlIGNsb3NlZC4gVGhpcyB3 YXMgZG9uZS4NCg0KIzg5MTogc2hvdWxkIGJlIGNsb3NlZC4gU3VwcG9ydCBmb3Igbm9uLUFTQ0lJ IGlzIGEgZmVhdHVyZSBvZiBkcmFmdC0wMS4NCg0KSW4gYWRkaXRpb246DQoNCiM5OTMgaXMgbWlz LWNhdGVnb3JpemVkIGFzIGx0cnUtaW5pdGlhbC4gSXQgc2hvdWxkIGJlIGx0cnUtcmVnaXN0cnks IHNpbmNlIGl0IHBlcnRhaW5zIHRvIHRoZSBzeW50YXggb2YgbGFuZ3VhZ2UgdGFncy4NCg0KQWRk aXNvbg0KDQoNCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3Qs IFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIEludGVy bmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcvSW50 ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQg aXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============0917063137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0917063137==-- From ltru-bounces@lists.ietf.org Thu May 19 19:03:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYu2n-0001FA-EH; Thu, 19 May 2005 19:03:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYu2k-0001Ew-W4 for ltru@megatron.ietf.org; Thu, 19 May 2005 19:03:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13250 for ; Thu, 19 May 2005 19:03:03 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYuJy-0005mA-9J for ltru@ietf.org; Thu, 19 May 2005 19:20:56 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4JN2rm5019786 for ; Thu, 19 May 2005 19:02:53 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JN2rx6147912 for ; Thu, 19 May 2005 19:02:53 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4JN2rSg009368 for ; Thu, 19 May 2005 19:02:53 -0400 Received: from markdavis ([9.43.213.118]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j4JN2qrP009341; Thu, 19 May 2005 19:02:52 -0400 Message-ID: <03d701c55cc6$e142ab50$4d6e3009@sanjose.ibm.com> From: "Mark Davis" To: "John Cowan" References: <634978A7DF025A40BFEF33EB191E13BC0B732A62@irvmbxw01.quest.com> <038201c55cb0$2a78b380$4d6e3009@sanjose.ibm.com> <20050519203746.GJ2322@skunk.reutershealth.com> Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Thu, 19 May 2005 16:02:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id j4JN2rm5019786 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org ok, I can live with that for the grandfathered stuff. =E2=80=8EMark ----- Original Message -----=20 From: "John Cowan" To: "Mark Davis" Cc: Sent: Thursday, May 19, 2005 13:37 Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally suppor= t ed > Mark Davis scripsit: > > > I have to look this over in detail, but a crucial requirement is to > > guarantee the invariant: > > > > if isValid(tag, date1), then canonicalize(tag, date1) =3D canonicalize(tag, > > date2), for all date2 > date1 > > > > Does this still preserve that? > > It does not preserve that invariant for grandfathered tags: they remain > always valid but not necessarily always canonical. > > I think we should be able to live with that, as the alternative is very ugly: > we will be stuck with some linguistic objects that can never have generative > names. > > --=20 > John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com > Any sufficiently-complicated C or Fortran program contains an ad-hoc, > informally-specified bug-ridden slow implementation of half of Common Lisp. > --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 19:14:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYuDP-00053i-Gi; Thu, 19 May 2005 19:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYuDO-00053d-4q for ltru@megatron.ietf.org; Thu, 19 May 2005 19:14:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14262 for ; Thu, 19 May 2005 19:14:02 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYuUd-00067S-K2 for ltru@ietf.org; Thu, 19 May 2005 19:31:55 -0400 Received: from h-68-166-38-112.snvacaid.dynamic.covad.net ([68.166.38.112] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYuDL-0002Yj-00 for ltru@ietf.org; Thu, 19 May 2005 16:14:03 -0700 Message-ID: <016301c55cc8$d0e1ca00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B732C8C@irvmbxw01.quest.com> Subject: Re: [Ltru] while we're housekeeping... Date: Thu, 19 May 2005 16:16:41 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - If anyone objects to the proposed disposition of these items, please post to the list now! > From: "Addison Phillips" > To: > Sent: Thursday, May 19, 2005 3:52 PM > Subject: [Ltru] while we're housekeeping... > > I see the following issues open in RT that should be marked closed for the reasons shown: > > #934: this was discussed: the relevant text requires at least one description that uses Latin text but allows the full Unicode repertoire otherwise. > > #963: this section was heavily reworked in draft-01 to address the concerns raised here. > > #964: should be rejected, although substantial changes were made in this section in draft-01 in part as a result of this comment. > > #965: should be closed. > > #970: should be closed. This was done. > > #891: should be closed. Support for non-ASCII is a feature of draft-01. > > In addition: > > #993 is mis-categorized as ltru-initial. It should be ltru-registry, since it pertains to the syntax of language tags. ... ok, I've made the following updates to the https://rt.psg.com/ (user ietf, password ietf) site: 934 - resolved 963 - resolved 964 - rejected 965 - rejected 970 - resolved 891 - resolved 993 - moved to the ltru-registry queue, still open If you think any of these need to be re-opened, please speak up! Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 19 19:35:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYuXu-0003Oy-Ty; Thu, 19 May 2005 19:35:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYuXs-0003Op-E1 for ltru@megatron.ietf.org; Thu, 19 May 2005 19:35:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16053 for ; Thu, 19 May 2005 19:35:12 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYup5-0006g2-Ty for ltru@ietf.org; Thu, 19 May 2005 19:53:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 16:34:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Thu, 19 May 2005 16:33:59 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B732CA2@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Thread-Index: AcVcyQp2P5Pe6OgDSpyvhh20YxHiHwAAbtug From: "Addison Phillips" To: "Mark Davis" , "John Cowan" X-OriginalArrivalTime: 19 May 2005 23:34:39.0722 (UTC) FILETIME=[5365BCA0:01C55CCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0187976420==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0187976420== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QmFzZWQgb24gdGhpcyBhbmQgd2hhdCBJIGtub3cgb2Ygb3RoZXIncyBwb3NpdGlvbnMsIEknbSBn dWVzc2luZyB0aGF0IHdlIGFyZSBuZWFyIHRvIGEgY29uc2Vuc3VzIChhdCBsZWFzdCwgb24gaG93 IHRvIHByb2NlZWQgdG93YXJkcyBhIHJlc29sdXRpb24pLiBCZWNhdXNlIHRoaXMgd2lsbCBhIG51 bWJlciBvZiBjaGFuZ2VzIHRvIHRoZSB0ZXh0IHdoaWNoIG1heSBiZSBkaWZmaWN1bHQgdG8gdW53 aW5kIGxhdGVyLCBJJ20gcHJlcHBpbmcgZHJhZnQtMDIgZm9yIHN1Ym1pc3Npb24gdG9uaWdodCBz byB0aGF0IHdlIGhhdmUgdGhlIGl0ZW1zIHJlc29sdmVkIGluIGl0ICJib29rbWFya2VkIi4gKFNv IGRyYWZ0LTAzIHdpbGwgY29udGFpbiBhbiBhdHRlbXB0IGF0IHJlc29sdmluZyB0aGlzIGxhcmdp c2ggaXNzdWUpDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlv biBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0 aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBm ZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcgW21haWx0bzpsdHJ1 LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBNYXJrIERhdmlzDQo+IFNl bnQ6IDIwMDXlubQ15pyIMTnml6UgMTY6MDMNCj4gVG86IEpvaG4gQ293YW4NCj4gQ2M6IGx0cnVA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogW3BzZy5jb20gIzk1NF0gYWxsIGFs aWFzZXMgbXVzdCBiZSBlcXVhbGx5IHN1cHBvcnQNCj4gZWQNCj4gDQo+IG9rLCBJIGNhbiBsaXZl IHdpdGggdGhhdCBmb3IgdGhlIGdyYW5kZmF0aGVyZWQgc3R1ZmYuDQo+IA0KPiDigI5NYXJrDQo+ IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJKb2huIENvd2FuIiA8 amNvd2FuQHJldXRlcnNoZWFsdGguY29tPg0KPiBUbzogIk1hcmsgRGF2aXMiIDxtYXJrLmRhdmlz QGp0Y3N2LmNvbT4NCj4gQ2M6IDxsdHJ1QGlldGYub3JnPg0KPiBTZW50OiBUaHVyc2RheSwgTWF5 IDE5LCAyMDA1IDEzOjM3DQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gUmU6IFtwc2cuY29tICM5NTRd IGFsbCBhbGlhc2VzIG11c3QgYmUgZXF1YWxseSBzdXBwb3J0DQo+IGVkDQo+IA0KPiANCj4gPiBN YXJrIERhdmlzIHNjcmlwc2l0Og0KPiA+DQo+ID4gPiBJIGhhdmUgdG8gbG9vayB0aGlzIG92ZXIg aW4gZGV0YWlsLCBidXQgYSBjcnVjaWFsIHJlcXVpcmVtZW50IGlzIHRvDQo+ID4gPiBndWFyYW50 ZWUgdGhlIGludmFyaWFudDoNCj4gPiA+DQo+ID4gPiBpZiBpc1ZhbGlkKHRhZywgZGF0ZTEpLCB0 aGVuIGNhbm9uaWNhbGl6ZSh0YWcsIGRhdGUxKSA9DQo+IGNhbm9uaWNhbGl6ZSh0YWcsDQo+ID4g PiBkYXRlMiksIGZvciBhbGwgZGF0ZTIgPiBkYXRlMQ0KPiA+ID4NCj4gPiA+IERvZXMgdGhpcyBz dGlsbCBwcmVzZXJ2ZSB0aGF0Pw0KPiA+DQo+ID4gSXQgZG9lcyBub3QgcHJlc2VydmUgdGhhdCBp bnZhcmlhbnQgZm9yIGdyYW5kZmF0aGVyZWQgdGFnczogdGhleSByZW1haW4NCj4gPiBhbHdheXMg dmFsaWQgYnV0IG5vdCBuZWNlc3NhcmlseSBhbHdheXMgY2Fub25pY2FsLg0KPiA+DQo+ID4gSSB0 aGluayB3ZSBzaG91bGQgYmUgYWJsZSB0byBsaXZlIHdpdGggdGhhdCwgYXMgdGhlIGFsdGVybmF0 aXZlIGlzIHZlcnkNCj4gdWdseToNCj4gPiB3ZSB3aWxsIGJlIHN0dWNrIHdpdGggc29tZSBsaW5n dWlzdGljIG9iamVjdHMgdGhhdCBjYW4gbmV2ZXIgaGF2ZQ0KPiBnZW5lcmF0aXZlDQo+ID4gbmFt ZXMuDQo+ID4NCj4gPiAtLQ0KPiA+IEpvaG4gQ293YW4gIGpjb3dhbkByZXV0ZXJzaGVhbHRoLmNv bSAgd3d3LmNjaWwub3JnL35jb3dhbg0KPiB3d3cucmV1dGVyc2hlYWx0aC5jb20NCj4gPiBBbnkg c3VmZmljaWVudGx5LWNvbXBsaWNhdGVkIEMgb3IgRm9ydHJhbiBwcm9ncmFtIGNvbnRhaW5zIGFu IGFkLWhvYywNCj4gPiBpbmZvcm1hbGx5LXNwZWNpZmllZCBidWctcmlkZGVuIHNsb3cgaW1wbGVt ZW50YXRpb24gb2YgaGFsZiBvZiBDb21tb24NCj4gTGlzcC4NCj4gPiAgICAgICAgIC0tR3JlZW5z cHVuJ3MgVGVudGggUnVsZSBvZiBQcm9ncmFtbWluZyAocnVsZXMgMS05IGFyZSB1bmtub3duKQ0K PiA+DQo+ID4NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9y Zw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============0187976420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0187976420==-- From ltru-bounces@lists.ietf.org Thu May 19 23:30:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYyDY-0004Ob-Ri; Thu, 19 May 2005 23:30:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYyDU-0004OQ-E5; Thu, 19 May 2005 23:30:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06854; Thu, 19 May 2005 23:30:16 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYyUZ-0003zO-PC; Thu, 19 May 2005 23:48:10 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 20:30:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C55CEC.3546236A" Date: Thu, 19 May 2005 20:30:02 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B732D08@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: Submission: LTRU Registry Draft 02 Thread-Index: AcVc7DS5reBnHeThSLK2EC7mdDHW+A== From: "Addison Phillips" To: X-OriginalArrivalTime: 20 May 2005 03:30:03.0311 (UTC) FILETIME=[35B663F0:01C55CEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 78e8d2846168c5d9a75e3a2a8b293c97 Cc: ltru@ietf.org Subject: [Ltru] Submission: LTRU Registry Draft 02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C55CEC.3546236A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGZpbmQgYXR0YWNoZWQgdGhlICIwMiIgdmVyc2lvbiBvZiAiZHJhZnQtaWV0Zi1sdHJ1 LXJlZ2lzdHJ5IiBJbnRlcm5ldC1EcmFmdCBpbiB0ZXh0IGZvcm1hdC4NCg0KQmVzdCBSZWdhcmRz LA0KDQpBZGRpc29uIChmb3IgdGhlIGVkaXRvcnMpDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkds b2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5j b20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXAN Cmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg0K ------_=_NextPart_001_01C55CEC.3546236A Content-Type: text/plain; name="draft-ietf-ltru-registry-02.txt" Content-Description: draft-ietf-ltru-registry-02.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-02.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IE5vdmVtYmVy IDIwLCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNYXkgMTksIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMDINCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBOb3ZlbWJlciAyMCwgMjAwNS4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5 cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4NCg0KQWJzdHJhY3QNCg0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHN0cnVjdHVyZSwgY29udGVudCwgY29uc3RydWN0 aW9uLCBhbmQNCiAgIHNlbWFudGljcyBvZiBsYW5ndWFnZSB0YWdzIGZvciB1c2UgaW4gY2FzZXMg d2hlcmUgaXQgaXMgZGVzaXJhYmxlIHRvDQogICBpbmRpY2F0ZSB0aGUgbGFuZ3VhZ2UgdXNlZCBp biBhbiBpbmZvcm1hdGlvbiBvYmplY3QuICBJdCBhbHNvDQogICBkZXNjcmliZXMgaG93IHRvIHJl Z2lzdGVyIHZhbHVlcyBmb3IgdXNlIGluIGxhbmd1YWdlIHRhZ3MgYW5kIHRoZQ0KICAgY3JlYXRp b24gb2YgdXNlciBkZWZpbmVkIGV4dGVuc2lvbnMgZm9yIHByaXZhdGUgaW50ZXJjaGFuZ2UuICBU aGlzDQogICBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDMwNjYgKHdoaWNoIHJlcGxhY2VkIFJGQyAx NzY2KS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAy MCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQpU YWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIuICBUaGUgTGFuZ3VhZ2Ug VGFnIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAg ICAyLjEgICBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA0DQogICAgICAgMi4xLjEgICBMZW5ndGggQ29uc2lkZXJhdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgMi4yICAgTGFuZ3VhZ2UgU3VidGFn IFNvdXJjZXMgYW5kIEludGVycHJldGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICAgIDIu Mi4xICAgUHJpbWFyeSBMYW5ndWFnZSBTdWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA4DQogICAgICAgMi4yLjIgICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgICAgICAyLjIuMyAgIFNjcmlwdCBTdWJ0YWcgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICAgIDIuMi40ICAg UmVnaW9uIFN1YnRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEx DQogICAgICAgMi4yLjUgICBWYXJpYW50IFN1YnRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTINCiAgICAgICAyLjIuNiAgIEV4dGVuc2lvbiBTdWJ0YWdzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0KICAgICAgIDIuMi43ICAgUHJpdmF0 ZSBVc2UgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICAg ICAgMi4yLjggICBQcmUtRXhpc3RpbmcgUkZDIDMwNjYgUmVnaXN0cmF0aW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gMTUNCiAgICAgICAyLjIuOSAgIENsYXNzZXMgb2YgQ29uZm9ybWFuY2UgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQ0KICAgMy4gIFJlZ2lzdHJ5IEZvcm1hdCBhbmQg TWFpbnRlbmFuY2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICAgIDMuMSAg IEZvcm1hdCBvZiB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgIC4gLiAuIC4gLiAu IC4gMTcNCiAgICAgMy4yICAgTWFpbnRlbmFuY2Ugb2YgdGhlIFJlZ2lzdHJ5ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyMQ0KICAgICAzLjMgICBTdGFiaWxpdHkgb2YgSUFOQSBSZWdp c3RyeSBFbnRyaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzDQogICAgIDMuNCAgIFJlZ2lz dHJhdGlvbiBQcm9jZWR1cmUgZm9yIFN1YnRhZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjYN CiAgICAgMy41ICAgUG9zc2liaWxpdGllcyBmb3IgUmVnaXN0cmF0aW9uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyOQ0KICAgICAzLjYgICBFeHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIE5h bWVzcGFjZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMxDQogICAgIDMuNyAgIENvbnZlcnNpb24g b2YgdGhlIFJGQyAzMDY2IExhbmd1YWdlIFRhZyBSZWdpc3RyeSAuIC4gLiAuIC4gMzQNCiAgIDQu ICBGb3JtYXRpb24gYW5kIFByb2Nlc3Npbmcgb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAzNw0KICAgICA0LjEgICBDaG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM3DQogICAgIDQuMiAgIE1lYW5pbmcgb2YgdGhlIExh bmd1YWdlIFRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzkNCiAgICAgNC4zICAg Q2Fub25pY2FsaXphdGlvbiBvZiBMYW5ndWFnZSBUYWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA0MA0KICAgICA0LjQgICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncyAu IC4gLiAuIC4gLiAuIC4gLiAuIDQxDQogICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDMNCiAgIDYuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NA0K ICAgNy4gIENoYXJhY3RlciBTZXQgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDQ1DQogICA4LiAgQ2hhbmdlcyBmcm9tIFJGQyAzMDY2ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDYNCiAgIDkuICBSZWZlcmVuY2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MA0KICAgICA5 LjEgICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDUwDQogICAgIDkuMiAgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTENCiAgICAgICBBdXRob3JzJyBBZGRyZXNzZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Mg0KICAgQS4gIEFja25v d2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDUzDQogICBCLiAgRXhhbXBsZXMgb2YgTGFuZ3VhZ2UgVGFncyAoSW5mb3JtYXRpdmUpICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNTQNCiAgIEMuICBFeGFtcGxlIFJlZ2lzdHJ5IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Nw0KICAgICAgIEludGVsbGVjdHVh bCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIDYxDQoN Cg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1i ZXIgMjAsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoN Cg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBIdW1hbiBiZWluZ3Mgb24gb3VyIHBsYW5ldCBoYXZl LCBwYXN0IGFuZCBwcmVzZW50LCB1c2VkIGEgbnVtYmVyIG9mDQogICBsYW5ndWFnZXMuICBUaGVy ZSBhcmUgbWFueSByZWFzb25zIHdoeSBvbmUgd291bGQgd2FudCB0byBpZGVudGlmeSB0aGUNCiAg IGxhbmd1YWdlIHVzZWQgd2hlbiBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3JtYXRpb24u DQoNCiAgIEluZm9ybWF0aW9uIGFib3V0IGEgdXNlcidzIGxhbmd1YWdlIHByZWZlcmVuY2VzIGNv bW1vbmx5IG5lZWRzIHRvIGJlDQogICBpZGVudGlmaWVkIHNvIHRoYXQgYXBwcm9wcmlhdGUgcHJv Y2Vzc2luZyBjYW4gYmUgYXBwbGllZC4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIHVzZXIncyBsYW5n dWFnZSBwcmVmZXJlbmNlcyBpbiBhIGJyb3dzZXIgY2FuIGJlIHVzZWQgdG8NCiAgIHNlbGVjdCB3 ZWIgcGFnZXMgYXBwcm9wcmlhdGVseS4gIEEgY2hvaWNlIG9mIGxhbmd1YWdlIHByZWZlcmVuY2Ug Y2FuDQogICBhbHNvIGJlIHVzZWQgdG8gc2VsZWN0IGFtb25nIHRvb2xzIChzdWNoIGFzIGRpY3Rp b25hcmllcykgdG8gYXNzaXN0DQogICBpbiB0aGUgcHJvY2Vzc2luZyBvciB1bmRlcnN0YW5kaW5n IG9mIGNvbnRlbnQgaW4gZGlmZmVyZW50IGxhbmd1YWdlcy4NCg0KICAgSW4gYWRkaXRpb24sIGtu b3dsZWRnZSBhYm91dCB0aGUgcGFydGljdWxhciBsYW5ndWFnZSB1c2VkIGJ5IHNvbWUNCiAgIHBp ZWNlIG9mIGluZm9ybWF0aW9uIGNvbnRlbnQgbWF5IGJlIHVzZWZ1bCBvciBldmVuIHJlcXVpcmVk IGJ5IHNvbWUNCiAgIHR5cGVzIG9mIGluZm9ybWF0aW9uIHByb2Nlc3Npbmc7IGZvciBleGFtcGxl IHNwZWxsLWNoZWNraW5nLA0KICAgY29tcHV0ZXItc3ludGhlc2l6ZWQgc3BlZWNoLCBCcmFpbGxl IHRyYW5zY3JpcHRpb24sIG9yIGhpZ2gtcXVhbGl0eQ0KICAgcHJpbnQgcmVuZGVyaW5ncy4NCg0K ICAgT25lIG1lYW5zIG9mIGluZGljYXRpbmcgdGhlIGxhbmd1YWdlIHVzZWQgaXMgYnkgbGFiZWxp bmcgdGhlDQogICBpbmZvcm1hdGlvbiBjb250ZW50IHdpdGggYSBsYW5ndWFnZSBpZGVudGlmaWVy LiAgVGhlc2UgaWRlbnRpZmllcnMNCiAgIGNhbiBhbHNvIGJlIHVzZWQgdG8gc3BlY2lmeSB1c2Vy IHByZWZlcmVuY2VzIHdoZW4gc2VsZWN0aW5nDQogICBpbmZvcm1hdGlvbiBjb250ZW50LCBvciBm b3IgbGFiZWxpbmcgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIG9mIGNvbnRlbnQNCiAgIGFuZCBhc3Nv Y2lhdGVkIHJlc291cmNlcy4NCg0KICAgVGhlc2UgaWRlbnRpZmllcnMgY2FuIGFsc28gYmUgdXNl ZCB0byBpbmRpY2F0ZSBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMNCiAgIG9mIGNvbnRlbnQgdGhhdCBh cmUgY2xvc2VseSByZWxhdGVkIHRvIHRoZSBsYW5ndWFnZS4gIEluIHBhcnRpY3VsYXIsDQogICBp dCBpcyBvZnRlbiBuZWNlc3NhcnkgdG8gaW5kaWNhdGUgc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJv dXQgdGhlDQogICBkaWFsZWN0LCB3cml0aW5nIHN5c3RlbSwgb3Igb3J0aG9ncmFwaHkgdXNlZCBp biBhIGRvY3VtZW50IG9yDQogICByZXNvdXJjZSwgYXMgdGhlc2UgYXR0cmlidXRlcyBtYXkgYmUg aW1wb3J0YW50IGZvciB0aGUgdXNlciB0byBvYnRhaW4NCiAgIGluZm9ybWF0aW9uIGluIGEgZm9y bSB0aGF0IHRoZXkgY2FuIHVuZGVyc3RhbmQsIG9yIGltcG9ydGFudCBpbg0KICAgc2VsZWN0aW5n IGFwcHJvcHJpYXRlIHByb2Nlc3NpbmcgcmVzb3VyY2VzIGZvciB0aGUgZ2l2ZW4gY29udGVudC4N Cg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gaWRlbnRpZmllciBtZWNoYW5pc20gYW5k IGEgcmVnaXN0cmF0aW9uDQogICBmdW5jdGlvbiBmb3IgdmFsdWVzIHRvIGJlIHVzZWQgd2l0aCB0 aGF0IGlkZW50aWZpZXIgbWVjaGFuaXNtLiAgSXQNCiAgIGFsc28gZGVmaW5lcyBhIG1lY2hhbmlz bSBmb3IgcHJpdmF0ZSB1c2UgdmFsdWVzIGFuZCBmdXR1cmUgZXh0ZW5zaW9uLg0KDQogICBUaGlz IGRvY3VtZW50IHJlcGxhY2VzIFJGQyAzMDY2LCB3aGljaCByZXBsYWNlZCBSRkMgMTc2Ni4gIEZv ciBhIGxpc3QNCiAgIG9mIGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVudCwgc2VlIFNlY3Rpb24gOC4N Cg0KICAgVGhlIGtleXdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM IiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQi LCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGlu dGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbMTBdLg0KDQoNCg0KDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAsIDIwMDUgICAgICAg ICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KMi4gIFRoZSBMYW5ndWFn ZSBUYWcNCg0KMi4xICBTeW50YXgNCg0KICAgVGhlIGxhbmd1YWdlIHRhZyBpcyBjb21wb3NlZCBv ZiBvbmUgb3IgbW9yZSBwYXJ0czogQSBwcmltYXJ5IGxhbmd1YWdlDQogICBzdWJ0YWcgYW5kIGEg KHBvc3NpYmx5IGVtcHR5KSBzZXJpZXMgb2Ygc3Vic2VxdWVudCBzdWJ0YWdzLiAgU3VidGFncw0K ICAgYXJlIGRpc3Rpbmd1aXNoZWQgYnkgdGhlaXIgbGVuZ3RoLCBwb3NpdGlvbiBpbiB0aGUgc3Vi dGFnIHNlcXVlbmNlLA0KICAgYW5kIGNvbnRlbnQsIHNvIHRoYXQgZWFjaCB0eXBlIG9mIHN1YnRh ZyBjYW4gYmUgcmVjb2duaXplZCBzb2xlbHkgYnkNCiAgIHRoZXNlIGZlYXR1cmVzLiAgVGhpcyBt YWtlcyBpdCBwb3NzaWJsZSB0byBjb25zdHJ1Y3QgYSBwYXJzZXIgdGhhdA0KICAgY2FuIGV4dHJh Y3QgYW5kIGFzc2lnbiBzb21lIHNlbWFudGljIGluZm9ybWF0aW9uIHRvIHRoZSBzdWJ0YWdzLCBl dmVuDQogICBpZiBzcGVjaWZpYyBzdWJ0YWcgdmFsdWVzIGFyZSBub3QgcmVjb2duaXplZC4gIFRo dXMgYSBwYXJzZXIgbmVlZCBub3QNCiAgIGhhdmUgYW4gdXAtdG8tZGF0ZSBjb3B5IG9mIHRoZSBy ZWdpc3RlcmVkIHN1YnRhZyB2YWx1ZXMgdG8gcGVyZm9ybQ0KICAgbW9zdCBzZWFyY2hpbmcgYW5k IG1hdGNoaW5nIG9wZXJhdGlvbnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDRd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQogICBUaGUgc3ludGF4IG9mIHRoaXMgdGFnIGluIEFC TkYgWzddIGlzOg0KDQogICBMYW5ndWFnZS1UYWcgPSAobGFuZw0KICAgICAgICAgICAgICAgICAg ICooIi0iIGV4dGxhbmcpDQogICAgICAgICAgICAgICAgICAgWyItIiBzY3JpcHRdDQogICAgICAg ICAgICAgICAgICAgWyItIiByZWdpb25dDQogICAgICAgICAgICAgICAgICAgKigiLSIgdmFyaWFu dCkNCiAgICAgICAgICAgICAgICAgICAqKCItIiBleHRlbnNpb24pDQogICAgICAgICAgICAgICAg ICAgWyItIiBwcml2YXRldXNlXSkNCiAgICAgICAgICAgICAgICAgICAvIHByaXZhdGV1c2UgICAg ICAgICA7IHByaXZhdGUtdXNlIHRhZw0KICAgICAgICAgICAgICAgICAgIC8gZ3JhbmRmYXRoZXJl ZCAgICAgIDsgZ3JhbmRmYXRoZXJlZCByZWdpc3RyYXRpb25zDQoNCiAgIGxhbmcgICAgICAgICAg ICA9IDIqM0FMUEhBICAgICAgICAgICA7IHNob3J0ZXN0IElTTyA2MzkgY29kZQ0KICAgICAgICAg ICAgICAgICAgIC8gcmVnaXN0ZXJlZC1sYW5nDQogICBleHRsYW5nICAgICAgICAgPSAzQUxQSEEg ICAgICAgICAgICAgOyByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZQ0KICAgc2NyaXB0ICAgICAgICAg ID0gNEFMUEhBICAgICAgICAgICAgIDsgSVNPIDE1OTI0IGNvZGUNCiAgIHJlZ2lvbiAgICAgICAg ICA9IDJBTFBIQSAgICAgICAgICAgICA7IElTTyAzMTY2IGNvZGUNCiAgICAgICAgICAgICAgICAg ICAvIDNESUdJVCAgICAgICAgICAgICA7IFVOIGNvdW50cnkgbnVtYmVyDQogICB2YXJpYW50ICAg ICAgICAgPSAgNSo4YWxwaGFudW0gICAgICAgOyByZWdpc3RlcmVkIHZhcmlhbnRzDQogICAgICAg ICAgICAgICAgICAgLyAoIERJR0lUIDNhbHBoYW51bSApDQogICBleHRlbnNpb24gICAgICAgPSBz aW5nbGV0b24gMSooIi0iICgyKjhhbHBoYW51bSkpDQogICBwcml2YXRldXNlICAgICAgPSAoIngi LyJYIikgMSooIi0iICgxKjhhbHBoYW51bSkpDQogICBzaW5nbGV0b24gICAgICAgPSAleDQxLTU3 IC8gJXg1OS01QSAvICV4NjEtNzcgLyAleDc5LTdBIC8gRElHSVQNCiAgICAgICAgICAgICAgICAg ICA7ICJhIi0idyIgLyAieSItInoiIC8gIkEiLSJXIiAvICJZIi0iWiIgLyAiMCItIjkiDQogICAg ICAgICAgICAgICAgICAgOyBTaW5nbGUgbGV0dGVyczogeC9YIGlzIHJlc2VydmVkIGZvciBwcml2 YXRlIHVzZQ0KICAgcmVnaXN0ZXJlZC1sYW5nID0gNCo4QUxQSEEgICAgICAgICAgOyByZWdpc3Rl cmVkIGxhbmd1YWdlIHN1YnRhZw0KICAgZ3JhbmRmYXRoZXJlZCAgID0gMSozQUxQSEEgMSoyKCIt IiAoMio4YWxwaGFudW0pKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg OyBncmFuZGZhdGhlcmVkIHJlZ2lzdHJhdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgOyBOb3RlOiBpIGlzIHRoZSBvbmx5IHNpbmdsZXRvbg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgOyB0aGF0IHN0YXJ0cyBhIGdyYW5kZmF0aGVyZWQg dGFnDQogICBhbHBoYW51bSAgICAgICAgPSAoQUxQSEEgLyBESUdJVCkgICA7IGxldHRlcnMgYW5k IG51bWJlcnMNCg0KICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IExhbmd1YWdlIFRh ZyBBQk5GDQoNCiAgIFRoZSBjaGFyYWN0ZXIgIi0iIGlzIEhZUEhFTi1NSU5VUyAoQUJORjogJXgy RCkuICBBbGwgc3VidGFncyBoYXZlIGENCiAgIG1heGltdW0gbGVuZ3RoIG9mIGVpZ2h0IGNoYXJh Y3RlcnMuICBOb3RlIHRoYXQgdGhlcmUgaXMgYSBzdWJ0bGV0eSBpbg0KICAgdGhlIEFCTkYgZm9y ICd2YXJpYW50JzogdmFyaWFudHMgc3RhcnRpbmcgd2l0aCBhIGRpZ2l0IG1heSBiZSBvbmx5DQog ICBmb3VyIGNoYXJhY3RlcnMgbG9uZywgd2hpbGUgdGhvc2Ugc3RhcnRpbmcgd2l0aCBhIGxldHRl ciBtdXN0IGJlIGF0DQogICBsZWFzdCBmaXZlIGNoYXJhY3RlcnMgbG9uZy4NCg0KICAgV2hpdGVz cGFjZSBpcyBub3QgcGVybWl0dGVkIGluIGEgbGFuZ3VhZ2UgdGFnLiAgRm9yIGV4YW1wbGVzIG9m DQogICBsYW5ndWFnZSB0YWdzLCBzZWUgQXBwZW5kaXggQi4NCg0KICAgTm90ZSB0aGF0IGFsdGhv dWdoIFs3XSByZWZlcnMgdG8gb2N0ZXRzLCB0aGUgbGFuZ3VhZ2UgdGFncyBkZXNjcmliZWQNCiAg IGluIHRoaXMgZG9jdW1lbnQgYXJlIHNlcXVlbmNlcyBvZiBjaGFyYWN0ZXJzIGZyb20gdGhlIFVT LUFTQ0lJDQogICByZXBlcnRvaXJlLiAgTGFuZ3VhZ2UgdGFncyBtYXkgYmUgdXNlZCBpbiBkb2N1 bWVudHMgYW5kIGFwcGxpY2F0aW9ucw0KICAgdGhhdCB1c2Ugb3RoZXIgZW5jb2RpbmdzLCBzbyBs b25nIGFzIHRoZXNlIGVuY29tcGFzcyB0aGUgVVMtQVNDSUkNCiAgIHJlcGVydG9pcmUuICBBbiBl eGFtcGxlIG9mIHRoaXMgd291bGQgYmUgYW4gWE1MIGRvY3VtZW50IHRoYXQgdXNlcw0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAg ICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQogICB0aGUgVVRGLTE2TEUg WzEyXSBlbmNvZGluZyBvZiBVbmljb2RlIFsyMF0uDQoNCiAgIFRoZSB0YWdzIGFuZCB0aGVpciBz dWJ0YWdzLCBpbmNsdWRpbmcgcHJpdmF0ZS11c2UgYW5kIGV4dGVuc2lvbnMsIGFyZQ0KICAgdG8g YmUgdHJlYXRlZCBhcyBjYXNlIGluc2Vuc2l0aXZlOiB0aGVyZSBleGlzdCBjb252ZW50aW9ucyBm b3IgdGhlDQogICBjYXBpdGFsaXphdGlvbiBvZiBzb21lIG9mIHRoZSBzdWJ0YWdzLCBidXQgdGhl c2Ugc2hvdWxkIG5vdCBiZSB0YWtlbg0KICAgdG8gY2FycnkgbWVhbmluZy4NCg0KICAgRm9yIGV4 YW1wbGU6DQoNCiAgIG8gIFtJU08gNjM5XSBbMV0gcmVjb21tZW5kcyB0aGF0IGxhbmd1YWdlIGNv ZGVzIGJlIHdyaXR0ZW4gaW4gbG93ZXINCiAgICAgIGNhc2UgKCdtbicgTW9uZ29saWFuKS4NCg0K ICAgbyAgW0lTTyAzMTY2XSBbNF0gcmVjb21tZW5kcyB0aGF0IGNvdW50cnkgY29kZXMgYmUgY2Fw aXRhbGl6ZWQgKCdNTicNCiAgICAgIE1vbmdvbGlhKS4NCg0KICAgbyAgW0lTTyAxNTkyNF0gWzNd IHJlY29tbWVuZHMgdGhhdCBzY3JpcHQgY29kZXMgdXNlIGxvd2VyIGNhc2Ugd2l0aA0KICAgICAg dGhlIGluaXRpYWwgbGV0dGVyIGNhcGl0YWxpemVkICgnQ3lybCcgQ3lyaWxsaWMpLg0KDQogICBI b3dldmVyLCBpbiB0aGUgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIHRoZSB1cHBlcmNh c2UgVVMtQVNDSUkNCiAgIGxldHRlcnMgaW4gdGhlIHJhbmdlICdBJyB0aHJvdWdoICdaJyBhcmUg Y29uc2lkZXJlZCBlcXVpdmFsZW50IGFuZA0KICAgbWFwcGVkIGRpcmVjdGx5IHRvIHRoZWlyIFVT LUFTQ0lJIGxvd2VyY2FzZSBlcXVpdmFsZW50cyBpbiB0aGUgcmFuZ2UNCiAgICdhJyB0aHJvdWdo ICd6Jy4gIFRodXMgdGhlIHRhZyAibW4tQ3lybC1NTiIgaXMgbm90IGRpc3RpbmN0IGZyb20gIk1O LQ0KICAgY1lSTC1tbiIgb3IgIm1OLWNZckwtTW4iIChvciBhbnkgb3RoZXIgY29tYmluYXRpb24p IGFuZCBlYWNoIG9mIHRoZXNlDQogICB2YXJpYXRpb25zIGNvbnZleXMgdGhlIHNhbWUgbWVhbmlu ZzogTW9uZ29saWFuIHdyaXR0ZW4gaW4gdGhlDQogICBDeXJpbGxpYyBzY3JpcHQgYXMgdXNlZCBp biBNb25nb2xpYS4NCg0KMi4xLjEgIExlbmd0aCBDb25zaWRlcmF0aW9ucw0KDQogICBBbHRob3Vn aCBuZWl0aGVyIHRoZSBBQk5GIG5vciBvdGhlciBndWlkZWxpbmVzIGluIHRoaXMgZG9jdW1lbnQN CiAgIHByb3ZpZGUgYSBmaXhlZCB1cHBlciBsaW1pdCBvbiB0aGUgbnVtYmVyIG9mIHN1YnRhZ3Mg aW4gYSBMYW5ndWFnZQ0KICAgVGFnIChhbmQgdGh1cyB0aGUgdXBwZXIgYm91bmQgb24gdGhlIHNp emUgb2YgYSB0YWcpIGFuZCBpdCBpcw0KICAgcG9zc2libGUgdG8gZW52aXNpb24gcXVpdGUgbG9u ZyBhbmQgY29tcGxleCBzdWJ0YWcgc2VxdWVuY2VzLCBpbg0KICAgcHJhY3RpY2UgdGhlc2UgYXJl IHJhcmUgYmVjYXVzZSBhZGRpdGlvbmFsIGdyYW51bGFyaXR5IGluIHRhZ3Mgc2VsZG9tDQogICBh ZGRzIHVzZWZ1bCBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbiBhbmQgYmVjYXVzZSBsb25nZXIs IG1vcmUNCiAgIGdyYW51bGFyIHRhZ3MgaW50ZXJlZmVyZSB3aXRoIHRoZSBtZWFuaW5nLCB1bmRl cnN0YW5kaW5nLCBhbmQNCiAgIHByb2Nlc3Npbmcgb2YgbGFuZ3VhZ2UgdGFncy4NCg0KICAgSW4g cGFydGljdWxhciwgIHZhcmlhbnQgc3VidGFncyBTSE9VTEQgYmUgdXNlZCBvbmx5IHdpdGggdGhl aXINCiAgIHJlY29tbWVuZGVkIHByZWZpeC4gIEluIHByYWN0aWNlLCB0aGlzIGxpbWl0cyBtb3N0 IHRhZ3MgdG8gYSBzZXF1ZW5jZQ0KICAgb2YgZm91ciBzdWJ0YWdzLCBhbmQgdGh1cyBhIG1heGlt dW0gbGVuZ3RoIG9mIDI2IGNoYXJhY3RlcnMNCiAgIChleGNsdWRpbmcgYW55IGV4dGVuc2lvbnMg b3IgcHJpdmF0ZSB1c2Ugc2VxdWVuY2VzKS4gIFRoaXMgaXMgYmVjYXVzZQ0KICAgc3VidGFncyBh cmUgbGltaXRlZCB0byBhIGxlbmd0aCBvZiBlaWdodCBjaGFyYWN0ZXJzIGFuZCB0aGUgZXh0bGFu ZywNCiAgIHNjcmlwdCwgYW5kIHJlZ2lvbiBzdWJ0YWdzIGFyZSBsaW1pdGVkIHRvIGV2ZW4gZmV3 ZXIgY2hhcmFjdGVycy4gIFNlZQ0KICAgU2VjdGlvbiA0LjEgZm9yIG1vcmUgaW5mb3JtYXRpb24g b24gc2VsZWN0aW5nIHRoZSBtb3N0IGFwcHJvcHJpYXRlDQogICBMYW5ndWFnZSBUYWcuDQoNCiAg IEEgY29uZm9ybWFudCBpbXBsZW1lbnRhdGlvbiBNQVkgcmVmdXNlIHRvIHN1cHBvcnQgdGhlIHN0 b3JhZ2Ugb2YNCiAgIGxhbmd1YWdlIHRhZ3Mgd2hpY2ggZXhjZWVkIGEgc3BlY2lmaWVkIGxlbmd0 aC4gIEZvciBhbiBleGFtcGxlLCBzZWUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgMjAsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAg IE1heSAyMDA1DQoNCg0KICAgW1JGQyAyMjMxXSBbMjJdLiAgQW55IHN1Y2ggbGltaXRhdGlvbiBN VVNUIGJlIGNsZWFybHkgZG9jdW1lbnRlZCwgYW5kDQogICBzdWNoIGRvY3VtZW50YXRpb24gU0hP VUxEIGluY2x1ZGUgdGhlIGRpc3Bvc2l0aW9uIG9mIGFueSBsb25nZXIgdGFncw0KICAgKGZvciBl eGFtcGxlLCB3aGV0aGVyIGFuIGVycm9yIHZhbHVlIGlzIGdlbmVyYXRlZCBvciB0aGUgbGFuZ3Vh Z2UgdGFnDQogICBpcyB0cnVuY2F0ZWQpLiAgSWYgdHJ1bmNhdGlvbiBpcyBwZXJtaXR0ZWQgaXQg TVVTVCBOT1QgcGVybWl0IGENCiAgIHN1YnRhZyB0byBiZSBkaXZpZGVkLg0KDQoyLjIgIExhbmd1 YWdlIFN1YnRhZyBTb3VyY2VzIGFuZCBJbnRlcnByZXRhdGlvbg0KDQogICBUaGUgbmFtZXNwYWNl IG9mIGxhbmd1YWdlIHRhZ3MgYW5kIHRoZWlyIHN1YnRhZ3MgaXMgYWRtaW5pc3RlcmVkIGJ5DQog ICB0aGUgSW50ZXJuZXQgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKElBTkEpIFsxM10gYWNj b3JkaW5nIHRvIHRoZQ0KICAgcnVsZXMgaW4gU2VjdGlvbiA1IG9mIHRoaXMgZG9jdW1lbnQuICBU aGUgcmVnaXN0cnkgbWFpbnRhaW5lZCBieSBJQU5BDQogICBpcyB0aGUgc291cmNlIGZvciB2YWxp ZCBzdWJ0YWdzOiBvdGhlciBzdGFuZGFyZHMgcmVmZXJlbmNlZCBpbiB0aGlzDQogICBzZWN0aW9u IHByb3ZpZGUgdGhlIHNvdXJjZSBtYXRlcmlhbCBmb3IgdGhhdCByZWdpc3RyeS4NCg0KICAgVGVy bWlub2xvZ3kgaW4gdGhpcyBzZWN0aW9uOg0KDQogICBvICBUYWcgb3IgdGFncyByZWZlcnMgdG8g YSBjb21wbGV0ZSBsYW5ndWFnZSB0YWcsIHN1Y2ggYXMNCiAgICAgICJmci1MYXRuLUNBIi4gIEV4 YW1wbGVzIG9mIHRhZ3MgaW4gdGhpcyBkb2N1bWVudCBhcmUgZW5jbG9zZWQgaW4NCiAgICAgIGRv dWJsZS1xdW90ZXMgKCJlbi1VUyIpLg0KDQogICBvICBTdWJ0YWcgcmVmZXJzIHRvIGEgc3BlY2lm aWMgc2VjdGlvbiBvZiBhIHRhZywgZGVsaW1pdGVkIGJ5IGh5cGhlbiwNCiAgICAgIHN1Y2ggYXMg dGhlIHN1YnRhZyAnTGF0bicgaW4gImZyLUxhdG4tQ0EiLiAgRXhhbXBsZXMgb2Ygc3VidGFncyBp bg0KICAgICAgdGhpcyBkb2N1bWVudCBhcmUgZW5jbG9zZWQgaW4gc2luZ2xlIHF1b3RlcyAoJ0xh dG4nKS4NCg0KICAgbyAgQ29kZSBvciBjb2RlcyByZWZlcnMgdG8gdmFsdWVzIGRlZmluZWQgaW4g ZXh0ZXJuYWwgc3RhbmRhcmRzIChhbmQNCiAgICAgIHdoaWNoIGFyZSB1c2VkIGFzIHN1YnRhZ3Mg aW4gdGhpcyBkb2N1bWVudCkuICBGb3IgZXhhbXBsZSwgJ0xhdG4nDQogICAgICBpcyBhbiBbSVNP IDE1OTI0XSBbM10gc2NyaXB0IGNvZGUgd2hpY2ggd2FzIHVzZWQgdG8gZGVmaW5lIHRoZQ0KICAg ICAgJ0xhdG4nIHNjcmlwdCBzdWJ0YWcgZm9yIHVzZSBpbiBhIGxhbmd1YWdlIHRhZy4gIEV4YW1w bGVzIG9mIGNvZGVzDQogICAgICBpbiB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5n bGUgcXVvdGVzICgnZW4nLCAnTGF0bicpLg0KDQogICBUaGUgZGVmaW5pdGlvbnMgaW4gdGhpcyBz ZWN0aW9uIGFwcGx5IHRvIHRoZSB2YXJpb3VzIHN1YnRhZ3Mgd2l0aGluDQogICB0aGUgbGFuZ3Vh Z2UgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIGV4Y2VwdGluZyB0aG9zZQ0KICAgImdy YW5kZmF0aGVyZWQiIHRhZ3MgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMi44Lg0KDQogICBMYW5ndWFn ZSB0YWdzIGFyZSBkZXNpZ25lZCBzbyB0aGF0IGVhY2ggc3VidGFnIHR5cGUgaGFzIHVuaXF1ZSBs ZW5ndGgNCiAgIGFuZCBjb250ZW50IHJlc3RyaWN0aW9ucy4gIFRoZXNlIG1ha2UgaWRlbnRpZmlj YXRpb24gb2YgdGhlIHN1YnRhZydzDQogICB0eXBlIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBjb250 ZW50IG9mIHRoZSBzdWJ0YWcgaXRzZWxmIGlzDQogICB1bnJlY29nbml6ZWQuICBUaGlzIGFsbG93 cyB0YWdzIHRvIGJlIHBhcnNlZCBhbmQgcHJvY2Vzc2VkIHdpdGhvdXQNCiAgIHJlZmVyZW5jZSB0 byB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzIG9yIHRoZQ0K ICAgSUFOQSByZWdpc3RyeSBhbmQgbWFrZXMgdGhlIGFzc29jaWF0ZWQgZXhjZXB0aW9uIGhhbmRs aW5nIHdoZW4NCiAgIHBhcnNpbmcgdGFncyBzaW1wbGVyLg0KDQogICBTdWJ0YWdzIGluIHRoZSBJ QU5BIHJlZ2lzdHJ5IHRoYXQgZG8gbm90IGNvbWUgZnJvbSBhbiB1bmRlcmx5aW5nDQogICBzdGFu ZGFyZCBjYW4gb25seSBhcHBlYXIgaW4gc3BlY2lmaWMgcG9zaXRpb25zIGluIGEgdGFnLg0KICAg U3BlY2lmaWNhbGx5LCB0aGV5IGNhbiBvbmx5IG9jY3VyIGFzIHByaW1hcnkgbGFuZ3VhZ2Ugc3Vi dGFncyBvciBhcw0KICAgdmFyaWFudCBzdWJ0YWdzLg0KDQogICBOb3RlIHRoYXQgc2VxdWVuY2Vz IG9mIHByaXZhdGUtdXNlIGFuZCBleHRlbnNpb24gc3VidGFncyBNVVNUIG9jY3VyDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAg ICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgIGF0IHRoZSBlbmQgb2Yg dGhlIHNlcXVlbmNlIG9mIHN1YnRhZ3MgYW5kIE1VU1QgTk9UIGJlIGludGVyc3BlcnNlZA0KICAg d2l0aCBzdWJ0YWdzIGRlZmluZWQgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIFNp bmdsZSBsZXR0ZXIgYW5kIGRpZ2l0IHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBjdXJyZW50IG9y IGZ1dHVyZQ0KICAgdXNlLiAgVGhlc2UgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGN1cnJlbnQgdXNl czoNCg0KICAgbyAgVGhlIHNpbmdsZSBsZXR0ZXIgc3VidGFnICd4JyBpcyByZXNlcnZlZCB0byBp bnRyb2R1Y2UgYSBzZXF1ZW5jZQ0KICAgICAgb2YgcHJpdmF0ZS11c2Ugc3VidGFncy4gIFRoZSBp bnRlcnByZXRhdGlvbiBvZiBhbnkgcHJpdmF0ZS11c2UNCiAgICAgIHN1YnRhZ3MgaXMgZGVmaW5l ZCBzb2xlbHkgYnkgcHJpdmF0ZSBhZ3JlZW1lbnQgYW5kIGlzIG5vdCBkZWZpbmVkDQogICAgICBi eSB0aGUgcnVsZXMgaW4gdGhpcyBzZWN0aW9uIG9yIGluIGFueSBzdGFuZGFyZCBvciByZWdpc3Ry eQ0KICAgICAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBBbGwgb3RoZXIgc2lu Z2xlIGxldHRlciBzdWJ0YWdzIGFyZSByZXNlcnZlZCB0byBpbnRyb2R1Y2UNCiAgICAgIHN0YW5k YXJkaXplZCBleHRlbnNpb24gc3VidGFnIHNlcXVlbmNlcyBhcyBkZXNjcmliZWQgaW4NCiAgICAg IFNlY3Rpb24gMy42Lg0KDQogICBUaGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgJ2knIGlzIHVzZWQg Ynkgc29tZSBncmFuZGZhdGhlcmVkIHRhZ3MsIHN1Y2gNCiAgIGFzICJpLWVub2NoaWFuIiwgd2hl cmUgaXQgYWx3YXlzIGFwcGVhcnMgaW4gdGhlIGZpcnN0IHBvc2l0aW9uIGFuZA0KICAgY2Fubm90 IGJlIGNvbmZ1c2VkIHdpdGggYW4gZXh0ZW5zaW9uLg0KDQoyLjIuMSAgUHJpbWFyeSBMYW5ndWFn ZSBTdWJ0YWcNCg0KICAgVGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHRoZSBmaXJzdCBz dWJ0YWcgaW4gYSBsYW5ndWFnZSB0YWcNCiAgICh3aXRoIHRoZSBleGNlcHRpb24gb2YgcHJpdmF0 ZS11c2UgYW5kIGNlcnRhaW4gZ3JhbmRmYXRoZXJlZCB0YWdzKQ0KICAgYW5kIGNhbm5vdCBiZSBv bWl0dGVkLiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcHJpbWFyeQ0KICAgbGFu Z3VhZ2Ugc3VidGFnOg0KDQogICAxLiAgQWxsIHR3byBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3VidGFn cyB3ZXJlIGRlZmluZWQgaW4gdGhlIElBTkENCiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8g dGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIHRoZSBzdGFuZGFyZCBJU08NCiAgICAgICA2MzkgUGFy dCAxLCAiSVNPIDYzOS0xOjIwMDIsIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YNCiAg ICAgICBuYW1lcyBvZiBsYW5ndWFnZXMgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiIFtJU08gNjM5 LTFdIFsxXSwgb3INCiAgICAgICB1c2luZyBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBi eSB0aGUgSVNPIDYzOSBQYXJ0IDENCiAgICAgICBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292ZXJu aW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuDQoNCiAgIDIuICBBbGwgdGhyZWUgY2hhcmFjdGVy IGxhbmd1YWdlIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0 cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiBJU08gNjM5IFBhcnQgMiwN CiAgICAgICAiSVNPIDYzOS0yOjE5OTggLSBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9m IG5hbWVzIG9mDQogICAgICAgbGFuZ3VhZ2VzIC0tIFBhcnQgMjogQWxwaGEtMyBjb2RlIC0gZWRp dGlvbiAxIiBbSVNPIDYzOS0yXSBbMl0sDQogICAgICAgb3IgYXNzaWdubWVudHMgc3Vic2VxdWVu dGx5IG1hZGUgYnkgdGhlIElTTyA2MzkgUGFydCAyDQogICAgICAgbWFpbnRlbmFuY2UgYWdlbmN5 IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KDQogICAzLiAgVGhlIHN1YnRh Z3MgaW4gdGhlIHJhbmdlICdxYWEnIHRocm91Z2ggJ3F0eicgYXJlIHJlc2VydmVkIGZvcg0KICAg ICAgIHByaXZhdGUgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0YWdzIGNvcnJlc3Bv bmQgdG8gY29kZXMNCiAgICAgICByZXNlcnZlZCBieSBJU08gNjM5LTIgZm9yIHByaXZhdGUgdXNl LiAgVGhlc2UgY29kZXMgTUFZIGJlIHVzZWQNCiAgICAgICBmb3Igbm9uLXJlZ2lzdGVyZWQgcHJp bWFyeS1sYW5ndWFnZSBzdWJ0YWdzIChpbnN0ZWFkIG9mIHVzaW5nDQogICAgICAgcHJpdmF0ZS11 c2Ugc3VidGFncyBmb2xsb3dpbmcgJ3gtJykuICBQbGVhc2UgcmVmZXIgdG8gU2VjdGlvbiA0LjQN CiAgICAgICBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBwcml2YXRlIHVzZSBzdWJ0YWdzLg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAg ICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgIDQuICBBbGwg Zm91ciBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgcmVzZXJ2ZWQgZm9yIHBvc3NpYmxl DQogICAgICAgZnV0dXJlIHN0YW5kYXJkaXphdGlvbi4NCg0KICAgNS4gIEFsbCBsYW5ndWFnZSBz dWJ0YWdzIG9mIDUgdG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aCBpbiB0aGUgSUFOQQ0KICAgICAg IHJlZ2lzdHJ5IHdlcmUgZGVmaW5lZCB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGluIFNl Y3Rpb24gMy40DQogICAgICAgYW5kIE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIHByaW1hcnkgbGFu Z3VhZ2Ugc3VidGFnLiAgQXQgdGhlIHRpbWUNCiAgICAgICB0aGlzIGRvY3VtZW50IHdhcyBjcmVh dGVkLCB0aGVyZSB3ZXJlIG5vIGV4YW1wbGVzIG9mIHRoaXMga2luZCBvZg0KICAgICAgIHN1YnRh ZyBhbmQgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgb2YgdGhpcyB0eXBlIHdpbGwgYmUgZGlzY291cmFn ZWQ6DQogICAgICAgcHJpbWFyeSBsYW5ndWFnZXMgYXJlIFNUUk9OR0xZIFJFQ09NTUVOREVEIGZv ciByZWdpc3RyYXRpb24gd2l0aA0KICAgICAgIElTTyA2MzkgYW5kIHByb3Bvc2FscyByZWplY3Rl ZCBieSBJU08gNjM5L1JBIHdpbGwgYmUgY2xvc2VseQ0KICAgICAgIHNjcnV0aW5pemVkIGJlZm9y ZSB0aGV5IGFyZSByZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KICAgNi4gIFRoZSBzaW5nbGUgY2hh cmFjdGVyIHN1YnRhZyAneCcgYXMgdGhlIHByaW1hcnkgc3VidGFnIGluZGljYXRlcw0KICAgICAg IHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBjb25zaXN0cyBzb2xlbHkgb2Ygc3VidGFncyB3aG9zZSBt ZWFuaW5nIGlzDQogICAgICAgZGVmaW5lZCBieSBwcml2YXRlIGFncmVlbWVudC4gIEZvciBleGFt cGxlLCBpbiB0aGUgdGFnICJ4LWZyLUNIIiwNCiAgICAgICB0aGUgc3VidGFncyAnZnInIGFuZCAn Q0gnIHNob3VsZCBub3QgYmUgdGFrZW4gdG8gcmVwcmVzZW50IHRoZQ0KICAgICAgIEZyZW5jaCBs YW5ndWFnZSBvciB0aGUgY291bnRyeSBvZiBTd2l0emVybGFuZCAob3IgYW55IG90aGVyIHZhbHVl DQogICAgICAgaW4gdGhlIElBTkEgcmVnaXN0cnkpIHVubGVzcyB0aGVyZSBpcyBhIHByaXZhdGUg YWdyZWVtZW50IGluDQogICAgICAgcGxhY2UgdG8gZG8gc28uICBTZWUgU2VjdGlvbiA0LjQuDQoN CiAgIDcuICBUaGUgc2luZ2xlIGNoYXJhY3RlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29tZSBn cmFuZGZhdGhlcmVkDQogICAgICAgdGFncyAoc2VlIFNlY3Rpb24gMi4yLjgpIHN1Y2ggYXMgImkt a2xpbmdvbiIgYW5kICJpLWJubiIuICAoT3RoZXINCiAgICAgICBncmFuZGZhdGhlcmVkIHRhZ3Mg aGF2ZSBhIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGluIHRoZWlyIGZpcnN0DQogICAgICAgcG9z aXRpb24pDQoNCiAgIDguICBPdGhlciB2YWx1ZXMgTVVTVCBOT1QgYmUgYXNzaWduZWQgdG8gdGhl IHByaW1hcnkgc3VidGFnIGV4Y2VwdCBieQ0KICAgICAgIHJldmlzaW9uIG9yIHVwZGF0ZSBvZiB0 aGlzIGRvY3VtZW50Lg0KDQogICBOb3RlOiBGb3IgbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBib3RoIGFu IElTTyA2MzktMSB0d28gY2hhcmFjdGVyIGNvZGUNCiAgIGFuZCBhbiBJU08gNjM5LTIgdGhyZWUg Y2hhcmFjdGVyIGNvZGUsIG9ubHkgdGhlIElTTyA2MzktMSB0d28NCiAgIGNoYXJhY3RlciBjb2Rl IGlzIGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkuDQoNCiAgIE5vdGU6IEZvciBsYW5ndWFn ZXMgdGhhdCBoYXZlIG5vIElTTyA2MzktMSB0d28gY2hhcmFjdGVyIGNvZGUgYW5kIGZvcg0KICAg d2hpY2ggdGhlIElTTyA2MzktMi9UIChUZXJtaW5vbG9neSkgY29kZSBhbmQgdGhlIElTTyA2Mzkt Mi9CDQogICAoQmlibGlvZ3JhcGhpYykgY29kZXMgZGlmZmVyLCBvbmx5IHRoZSBUZXJtaW5vbG9n eSBjb2RlIGlzIGRlZmluZWQgaW4NCiAgIHRoZSBJQU5BIHJlZ2lzdHJ5LiAgQXQgdGhlIHRpbWUg dGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCwgYWxsDQogICBsYW5ndWFnZXMgdGhhdCBoYWQgYm90 aCBraW5kcyBvZiB0aHJlZSBjaGFyYWN0ZXIgY29kZSB3ZXJlIGFsc28NCiAgIGFzc2lnbmVkIGEg dHdvIGNoYXJhY3RlciBjb2RlOyBpdCBpcyBub3QgZXhwZWN0ZWQgdGhhdCBmdXR1cmUNCiAgIGFz c2lnbm1lbnRzIG9mIHRoaXMgbmF0dXJlIHdpbGwgb2NjdXIuDQoNCiAgIE5vdGU6IFRvIGF2b2lk IHByb2JsZW1zIHdpdGggdmVyc2lvbmluZyBhbmQgc3VidGFnIGNob2ljZSBhcw0KICAgZXhwZXJp ZW5jZWQgZHVyaW5nIHRoZSB0cmFuc2l0aW9uIGJldHdlZW4gUkZDIDE3NjYgYW5kIFJGQyAzMDY2 LCBhcw0KICAgd2VsbCBhcyB0aGUgY2Fub25pY2FsIG5hdHVyZSBvZiBzdWJ0YWdzIGRlZmluZWQg YnkgdGhpcyBkb2N1bWVudCwgdGhlDQogICBJU08gNjM5IFJlZ2lzdHJhdGlvbiBBdXRob3JpdHkg Sm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlIChJU08gNjM5Lw0KICAgUkEtSkFDKSBoYXMgaW5jbHVk ZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gWzE2XToNCg0KICAgIkEgbGFuZ3VhZ2UgY29k ZSBhbHJlYWR5IGluIElTTyA2MzktMiBhdCB0aGUgcG9pbnQgb2YgZnJlZXppbmcgSVNPDQogICA2 MzktMSBzaGFsbCBub3QgbGF0ZXIgYmUgYWRkZWQgdG8gSVNPIDYzOS0xLiAgVGhpcyBpcyB0byBl bnN1cmUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAs IDIwMDUgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KICAg Y29uc2lzdGVuY3kgaW4gdXNhZ2Ugb3ZlciB0aW1lLCBzaW5jZSB1c2VycyBhcmUgZGlyZWN0ZWQg aW4gSW50ZXJuZXQNCiAgIGFwcGxpY2F0aW9ucyB0byBlbXBsb3kgdGhlIGFscGhhLTMgY29kZSB3 aGVuIGFuIGFscGhhLTIgY29kZSBmb3IgdGhhdA0KICAgbGFuZ3VhZ2UgaXMgbm90IGF2YWlsYWJs ZS4iDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIGluc3RhYmlsaXR5IG9mIHRoZSBjYW5vbmljYWwg Zm9ybSBvZiB0YWdzLCBpZiBhIHR3bw0KICAgY2hhcmFjdGVyIGNvZGUgaXMgYWRkZWQgdG8gSVNP IDYzOS0xIGZvciBhIGxhbmd1YWdlIGZvciB3aGljaCBhIHRocmVlDQogICBjaGFyYWN0ZXIgY29k ZSB3YXMgYWxyZWFkeSBpbmNsdWRlZCBpbiBJU08gNjM5LTIsIHRoZSB0d28gY2hhcmFjdGVyDQog ICBjb2RlIHdpbGwgbm90IGJlIGFkZGVkIGFzIGEgc3VidGFnIGluIHRoZSByZWdpc3RyeS4gIFNl ZSBTZWN0aW9uIDMuMy4NCg0KICAgRm9yIGV4YW1wbGUsIGlmIHNvbWUgY29udGVudCB3ZXJlIHRh Z2dlZCB3aXRoICdoYXcnIChIYXdhaWlhbiksIHdoaWNoDQogICBjdXJyZW50bHkgaGFzIG5vIHR3 byBjaGFyYWN0ZXIgY29kZSwgdGhlIHRhZyB3b3VsZCBub3QgYmUgaW52YWxpZGF0ZWQNCiAgIGlm IElTTyA2MzktMSB3ZXJlIHRvIGFzc2lnbiBhIHR3byBjaGFyYWN0ZXIgY29kZSB0byB0aGUgSGF3 YWlpYW4NCiAgIGxhbmd1YWdlIGF0IGEgbGF0ZXIgZGF0ZS4NCg0KICAgRm9yIGV4YW1wbGUsIG9u ZSBvZiB0aGUgZ3JhbmRmYXRoZXJlZCBJQU5BIHJlZ2lzdHJhdGlvbnMgaXMNCiAgICJpLWVub2No aWFuIi4gIFRoZSBzdWJ0YWcgJ2Vub2NoaWFuJyBjb3VsZCBiZSByZWdpc3RlcmVkIGluIHRoZSBJ QU5BDQogICByZWdpc3RyeSBhcyBhIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIChhc3N1bWluZyB0 aGF0IElTTyA2MzkgZG9lcyBub3QNCiAgIHJlZ2lzdGVyIHRoaXMgbGFuZ3VhZ2UgZmlyc3QpLCBt YWtpbmcgdGFncyBzdWNoIGFzICJlbm9jaGlhbi1BUSIgYW5kDQogICAiZW5vY2hpYW4tTGF0biIg dmFsaWQuDQoNCjIuMi4yICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzDQoNCiAgIFRoZSBmb2xs b3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3M6DQoNCiAg IDEuICBUaHJlZSBsZXR0ZXIgc3VidGFncyBpbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIHByaW1h cnkgc3VidGFnIGFyZQ0KICAgICAgIHJlc2VydmVkIGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9u LCBhbnRpY2lwYXRpbmcgd29yayB0aGF0IGlzDQogICAgICAgY3VycmVudGx5IHVuZGVyIHdheSBv biBJU08gNjM5Lg0KDQogICAyLiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIGZvbGxv dyB0aGUgcHJpbWFyeSBzdWJ0YWcgYW5kDQogICAgICAgcHJlY2VkZSBhbnkgb3RoZXIgc3VidGFn cy4NCg0KICAgMy4gIFRoZXJlIE1BWSBiZSBhbnkgYWRkaXRpb25hbCBudW1iZXIgb2YgZXh0ZW5k ZWQgbGFuZ3VhZ2Ugc3VidGFncy4NCg0KICAgNC4gIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3Mg d2lsbCBub3QgYmUgcmVnaXN0ZXJlZCBleGNlcHQgYnkNCiAgICAgICByZXZpc2lvbiBvZiB0aGlz IGRvY3VtZW50Lg0KDQogICA1LiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIE5PVCBi ZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncw0KICAgICAgIGV4Y2VwdCBieSByZXZpc2lvbiBv ZiB0aGlzIGRvY3VtZW50Lg0KDQogICBFeGFtcGxlOiBJbiBhIGZ1dHVyZSByZXZpc2lvbiBvciB1 cGRhdGUgb2YgdGhpcyBkb2N1bWVudCwgdGhlIHRhZw0KICAgInpoLWdhbiIgKHJlZ2lzdGVyZWQg dW5kZXIgUkZDIDMwNjYpIG1pZ2h0IGJlY29tZSBhIHZhbGlkIG5vbi0NCiAgIGdyYW5kZmF0aGVy ZWQgKHRoYXQgaXMsIHJlZHVuZGFudCkgdGFnIGluIHdoaWNoIHRoZSBzdWJ0YWcgJ2dhbicNCiAg IG1pZ2h0IHJlcHJlc2VudCB0aGUgQ2hpbmVzZSBkaWFsZWN0ICdHYW4nLg0KDQoyLjIuMyAgU2Ny aXB0IFN1YnRhZw0KDQogICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSBzY3JpcHQg c3VidGFnczoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJl ciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0K DQogICAxLiAgQWxsIGZvdXIgY2hhcmFjdGVyIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGFjY29yZGlu ZyB0byBJU08gMTU5MjQNCiAgICAgICBbM10tLSJDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9u IG9mIHRoZSBuYW1lcyBvZiBzY3JpcHRzIjoNCiAgICAgICBhbHBoYS00IHNjcmlwdCBjb2Rlcywg b3Igc3Vic2VxdWVudGx5IGFzc2lnbmVkIGJ5IHRoZSBJU08gMTU5MjQNCiAgICAgICBtYWludGVu YW5jZSBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMsIGRlbm90aW5n DQogICAgICAgdGhlIHNjcmlwdCBvciB3cml0aW5nIHN5c3RlbSB1c2VkIGluIGNvbmp1bmN0aW9u IHdpdGggdGhpcw0KICAgICAgIGxhbmd1YWdlLg0KDQogICAyLiAgU2NyaXB0IHN1YnRhZ3MgTVVT VCBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICBzdWJ0YWcg YW5kIGFsbCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIGFuZCBNVVNUIG9jY3VyIGJlZm9yZQ0K ICAgICAgIGFueSBvdGhlciB0eXBlIG9mIHN1YnRhZyBkZXNjcmliZWQgYmVsb3cuDQoNCiAgIDMu ICBUaGUgc2NyaXB0IHN1YnRhZ3MgJ1FhYWEnIHRocm91Z2ggJ1FhYngnIGFyZSByZXNlcnZlZCBm b3IgcHJpdmF0ZQ0KICAgICAgIHVzZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFncyBj b3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkDQogICAgICAgYnkgSVNPIDE1OTI0IGZvciBwcml2 YXRlIHVzZS4gIFRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBub24tDQogICAgICAgcmVnaXN0 ZXJlZCBzY3JpcHQgdmFsdWVzLiAgUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gNC40IGZvciBtb3Jl DQogICAgICAgaW5mb3JtYXRpb24gb24gcHJpdmF0ZS11c2Ugc3VidGFncy4NCg0KICAgNC4gIFNj cmlwdCBzdWJ0YWdzIGNhbm5vdCBiZSByZWdpc3RlcmVkIHVzaW5nIHRoZSBwcm9jZXNzIGluDQog ICAgICAgU2VjdGlvbiAzLjQgb2YgdGhpcyBkb2N1bWVudC4gIFZhcmlhbnQgc3VidGFncyBtYXkg YmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdpc3RyYXRpb24gZm9yIHRoYXQgcHVycG9zZS4N Cg0KICAgRXhhbXBsZTogImRlLUxhdG4iIHJlcHJlc2VudHMgR2VybWFuIHdyaXR0ZW4gdXNpbmcg dGhlIExhdGluIHNjcmlwdC4NCg0KMi4yLjQgIFJlZ2lvbiBTdWJ0YWcNCg0KICAgVGhlIGZvbGxv d2luZyBydWxlcyBhcHBseSB0byB0aGUgcmVnaW9uIHN1YnRhZ3M6DQoNCiAgIDEuICBUaGUgcmVn aW9uIHN1YnRhZyBkZWZpbmVzIGxhbmd1YWdlIHZhcmlhdGlvbnMgdXNlZCBpbiBhIHNwZWNpZmlj DQogICAgICAgcmVnaW9uLCBnZW9ncmFwaGljLCBvciBwb2xpdGljYWwgYXJlYS4gIFJlZ2lvbiBz dWJ0YWdzIE1VU1QNCiAgICAgICBmb2xsb3cgYW55IGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFn ZSwgb3Igc2NyaXB0IHN1YnRhZ3MgYW5kDQogICAgICAgTVVTVCBwcmVjZWRlIGFsbCBvdGhlciBz dWJ0YWdzLg0KDQogICAyLiAgQWxsIHR3byBjaGFyYWN0ZXIgc3VidGFncyBmb2xsb3dpbmcgdGhl IHByaW1hcnkgc3VidGFnIHdlcmUNCiAgICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5 IGFjY29yZGluZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQNCiAgICAgICBpbiBJU08gMzE2NiBb NF0tLSJDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mDQogICAgICAgY291 bnRyaWVzIGFuZCB0aGVpciBzdWJkaXZpc2lvbnMgLSBQYXJ0IDE6IENvdW50cnkNCiAgICAgICBj b2RlcyItLWFscGhhLTIgY291bnRyeSBjb2RlcyBvciBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkg bWFkZSBieQ0KICAgICAgIHRoZSBJU08gMzE2NiBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292ZXJu aW5nIHN0YW5kYXJkaXphdGlvbg0KICAgICAgIGJvZGllcy4NCg0KICAgMy4gIEFsbCB0aHJlZSBj aGFyYWN0ZXIgY29kZXMgY29uc2lzdGluZyBvZiBkaWdpdCAobnVtZXJpYykNCiAgICAgICBjaGFy YWN0ZXJzIHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhl DQogICAgICAgYXNzaWdubWVudHMgZm91bmQgaW4gVU4gU3RhbmRhcmQgQ291bnRyeSBvciBBcmVh IENvZGVzIGZvcg0KICAgICAgIFN0YXRpc3RpY2FsICBVc2UgWzVdIG9yIGFzc2lnbm1lbnRzIHN1 YnNlcXVlbnRseSBtYWRlIGJ5IHRoZQ0KICAgICAgIGdvdmVybmluZyBzdGFuZGFyZHMgYm9keS4g IE5vdGUgdGhhdCBub3QgYWxsIG9mIHRoZSBVTiBNLjQ5IGNvZGVzDQogICAgICAgYXJlIGRlZmlu ZWQgaW4gdGhlIElBTkEgcmVnaXN0cnk6DQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgICAgTWF5IDIwMDUNCg0KDQogICAgICAgQS4gIFVOIG51bWVyaWMgY29kZXMgYXNzaWduZWQg dG8gJ21hY3JvLWdlb2dyYXBoaWNhbA0KICAgICAgICAgICAoY29udGluZW50YWwpJyBvciBzdWIt cmVnaW9ucyBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbmVkDQogICAgICAgICAgIElTTyAz MTY2IGFscGhhLTIgY29kZSBfYXJlXyBkZWZpbmVkLg0KDQogICAgICAgQi4gIFVOIG51bWVyaWMg Y29kZXMgZm9yICdlY29ub21pYyBncm91cGluZ3MnIG9yICdvdGhlcg0KICAgICAgICAgICBncm91 cGluZ3MnIGFyZSBfbm90XyBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFuZCBNVVNUDQog ICAgICAgICAgIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0KICAgICAgIEMu ICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgd2l0aCBhbWJpZ3VvdXMgSVNPIDMxNjYN CiAgICAgICAgICAgYWxwaGEtMiBjb2RlcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4zIGFyZSBk ZWZpbmVkIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeSBhbmQgYXJlIGNhbm9uaWNhbCBmb3Ig dGhlIGdpdmVuIGNvdW50cnkgb3IgcmVnaW9uDQogICAgICAgICAgIGRlZmluZWQuDQoNCiAgICAg ICBELiAgVGhlIGFscGhhbnVtZXJpYyBjb2RlcyBpbiBBcHBlbmRpeCBYIG9mIHRoZSBVTiBkb2N1 bWVudCBhcmUNCiAgICAgICAgICAgX25vdF8gZGVmaW5lZCBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0 byBmb3JtIGxhbmd1YWdlIHRhZ3MuDQogICAgICAgICAgIChBdCB0aGUgdGltZSB0aGlzIGRvY3Vt ZW50IHdhcyBjcmVhdGVkIHRoZXNlIHZhbHVlcyBtYXRjaCB0aGUNCiAgICAgICAgICAgSVNPIDMx NjYgYWxwaGEtMiBjb2Rlcy4pDQoNCiAgIDQuICBUaGVyZSBtYXkgYmUgYXQgbW9zdCBvbmUgcmVn aW9uIHN1YnRhZyBpbiBhIGxhbmd1YWdlIHRhZy4NCg0KICAgNS4gIFRoZSByZWdpb24gc3VidGFn cyAnQUEnLCAnUU0nLSdRWicsICdYQSctJ1haJywgYW5kICdaWicgYXJlDQogICAgICAgcmVzZXJ2 ZWQgZm9yIHByaXZhdGUgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0YWdzDQogICAg ICAgY29ycmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZCBieSBJU08gMzE2NiBmb3IgcHJpdmF0ZSB1 c2UuICBUaGVzZQ0KICAgICAgIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBwcml2YXRlIHVzZSByZWdp b24gc3VidGFncyAoaW5zdGVhZCBvZg0KICAgICAgIHVzaW5nIGEgcHJpdmF0ZS11c2Ugc3VidGFn IHNlcXVlbmNlKS4gIFBsZWFzZSByZWZlciB0bw0KICAgICAgIFNlY3Rpb24gNC40IGZvciBtb3Jl IGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgICJkZS1DSCIgcmVwcmVz ZW50cyBHZXJtYW4gKCdkZScpIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQgKCdDSCcpLg0KDQogICAi c3ItTGF0bi1DUyIgcmVwcmVzZW50cyBTZXJiaWFuICgnc3InKSB3cml0dGVuIHVzaW5nIExhdGlu IHNjcmlwdA0KICAgKCdMYXRuJykgYXMgdXNlZCBpbiBTZXJiaWEgYW5kIE1vbnRlbmVncm8gKCdD UycpLg0KDQogICAiZXMtNDE5IiByZXByZXNlbnRzIFNwYW5pc2ggKCdlcycpIGFzIHVzZWQgaW4g dGhlIFVOLWRlZmluZWQgTGF0aW4NCiAgIEFtZXJpY2EgYW5kIENhcmliYmVhbiByZWdpb24gKCc0 MTknKS4NCg0KMi4yLjUgIFZhcmlhbnQgU3VidGFncw0KDQogICBUaGUgZm9sbG93aW5nIHJ1bGVz IGFwcGx5IHRvIHRoZSB2YXJpYW50IHN1YnRhZ3M6DQoNCiAgIDEuICBWYXJpYW50IHN1YnRhZ3Mg YXJlIG5vdCBhc3NvY2lhdGVkIHdpdGggYW55IGV4dGVybmFsIHN0YW5kYXJkLg0KICAgICAgIFZh cmlhbnQgc3VidGFncyBhbmQgdGhlaXIgbWVhbmluZ3MgYXJlIGRlZmluZWQgYnkgdGhlDQogICAg ICAgcmVnaXN0cmF0aW9uIHByb2Nlc3MgZGVmaW5lZCBpbiBTZWN0aW9uIDMuNC4NCg0KICAgMi4g IFZhcmlhbnQgc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgb2YgdGhlIG90aGVyIGRlZmluZWQgc3Vi dGFncywgYnV0DQogICAgICAgcHJlY2VkZSBhbnkgZXh0ZW5zaW9uIG9yIHByaXZhdGUtdXNlIHN1 YnRhZyBzZXF1ZW5jZXMuDQoNCiAgIDMuICBNb3JlIHRoYW4gb25lIHZhcmlhbnQgTUFZIGJlIHVz ZWQgdG8gZm9ybSB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgIDQuICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBiZSByZWdp c3RlcmVkIHdpdGggSUFOQSBhY2NvcmRpbmcgdG8gdGhlDQogICAgICAgcnVsZXMgaW4gU2VjdGlv biAzLjQgb2YgdGhpcyBkb2N1bWVudCBiZWZvcmUgYmVpbmcgdXNlZCB0byBmb3JtDQogICAgICAg bGFuZ3VhZ2UgdGFncy4gIEluIG9yZGVyIHRvIGRpc3Rpbmd1aXNoIHZhcmlhbnRzIGZyb20gb3Ro ZXIgdHlwZXMNCiAgICAgICBvZiBzdWJ0YWdzLCByZWdpc3RyYXRpb25zIG11c3QgbWVldCB0aGUg Zm9sbG93aW5nIGxlbmd0aCBhbmQNCiAgICAgICBjb250ZW50IHJlc3RyaWN0aW9uczoNCg0KICAg ICAgIDEuICBWYXJpYW50IHN1YnRhZ3MgdGhhdCBiZWdpbiB3aXRoIGEgbGV0dGVyIChhLXosIEEt WikgTVVTVCBiZQ0KICAgICAgICAgICBhdCBsZWFzdCBmaXZlIGNoYXJhY3RlcnMgbG9uZy4NCg0K ICAgICAgIDIuICBWYXJpYW50IHN1YnRhZ3MgdGhhdCBiZWdpbiB3aXRoIGEgZGlnaXQgKDAtOSkg TVVTVCBiZSBhdA0KICAgICAgICAgICBsZWFzdCBmb3VyIGNoYXJhY3RlcnMgbG9uZy4NCg0KICAg ImVuLXNjb3VzZSIgcmVwcmVzZW50cyB0aGUgU2NvdXNlIGRpYWxlY3Qgb2YgRW5nbGlzaC4NCg0K ICAgImRlLUNILTE5OTYiIHJlcHJlc2VudHMgR2VybWFuIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQg YW5kIGFzIHdyaXR0ZW4NCiAgIHVzaW5nIHRoZSBzcGVsbGluZyByZWZvcm0gYmVnaW5uaW5nIGlu IHRoZSB5ZWFyIDE5OTYgQy5FLg0KDQoyLjIuNiAgRXh0ZW5zaW9uIFN1YnRhZ3MNCg0KICAgVGhl IGZvbGxvd2luZyBydWxlcyBhcHBseSB0byBleHRlbnNpb25zOg0KDQogICAxLiAgIEV4dGVuc2lv biBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgb3RoZXIgc3VidGFncyBkZWZpbmVkDQog ICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgYSBzaW5nbGUtbGV0dGVyIHN1YnRhZyAoInNpbmds ZXRvbiIpLiAgVGhlDQogICAgICAgIHNpbmdsZXRvbiBNVVNUIGJlIG9uZSBhbGxvY2F0ZWQgdG8g YSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IHZpYQ0KICAgICAgICB0aGUgbWVjaGFuaXNtIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDMuNiBhbmQgY2Fubm90IGJlIHRoZSBsZXR0ZXINCiAgICAgICAgJ3gn LCB3aGljaCBpcyByZXNlcnZlZCBmb3IgcHJpdmF0ZS11c2Ugc3VidGFnIHNlcXVlbmNlcy4NCg0K ICAgMi4gICBOb3RlOiBQcml2YXRlLXVzZSBzdWJ0YWcgc2VxdWVuY2VzIHN0YXJ0aW5nIHdpdGgg dGhlIHNpbmdsZXRvbg0KICAgICAgICBzdWJ0YWcgJ3gnIGFyZSBkZXNjcmliZWQgYmVsb3cuDQoN CiAgIDMuICAgQW4gZXh0ZW5zaW9uIE1VU1QgZm9sbG93IGF0IGxlYXN0IGEgcHJpbWFyeSBsYW5n dWFnZSBzdWJ0YWcuDQogICAgICAgIFRoYXQgaXMsIGEgbGFuZ3VhZ2UgdGFnIGNhbm5vdCBiZWdp biB3aXRoIGFuIGV4dGVuc2lvbi4NCiAgICAgICAgRXh0ZW5zaW9ucyBleHRlbmQgbGFuZ3VhZ2Ug dGFncywgdGhleSBkbyBub3Qgb3ZlcnJpZGUgb3IgcmVwbGFjZQ0KICAgICAgICB0aGVtLiAgRm9y IGV4YW1wbGUsICJhLXZhbHVlIiBpcyBub3QgYSB3ZWxsLWZvcm1lZCBsYW5ndWFnZSB0YWcsDQog ICAgICAgIHdoaWxlICJkZS1hLXZhbHVlIiBpcy4NCg0KICAgNC4gICBFYWNoIHNpbmdsZXRvbiBz dWJ0YWcgTVVTVCBhcHBlYXIgYXQgbW9zdCBvbmUgdGltZSBpbiBlYWNoIHRhZw0KICAgICAgICAo b3RoZXIgdGhhbiBhcyBhIHByaXZhdGUtdXNlIHN1YnRhZykuICBUaGF0IGlzLCBzaW5nbGV0b24N CiAgICAgICAgc3VidGFncyBNVVNUIE5PVCBiZSByZXBlYXRlZC4gIEZvciBleGFtcGxlLCB0aGUg dGFnICJlbi1hLWJiYi1hLQ0KICAgICAgICBjY2MiIGlzIGludmFsaWQgYmVjYXVzZSB0aGUgc3Vi dGFnICdhJyBhcHBlYXJzIHR3aWNlLiAgTm90ZSB0aGF0DQogICAgICAgIHRoZSB0YWcgImVuLWEt YmJiLXgtYS1jY2MiIGlzIHZhbGlkIGJlY2F1c2UgdGhlIHNlY29uZA0KICAgICAgICBhcHBlYXJh bmNlIG9mIHRoZSBzaW5nbGV0b24gJ2EnIGlzIGluIGEgcHJpdmF0ZSB1c2Ugc2VxdWVuY2UuDQoN CiAgIDUuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IGFsbCBvZiB0aGUgcmVxdWlyZW1l bnRzIGZvciB0aGUNCiAgICAgICAgY29udGVudCBhbmQgZm9ybWF0IG9mIHN1YnRhZ3MgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICA2LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1QgbWVl dCB3aGF0ZXZlciByZXF1aXJlbWVudHMgYXJlIHNldCBieSB0aGUNCiAgICAgICAgZG9jdW1lbnQg dGhhdCBkZWZpbmVzIHRoZWlyIHNpbmdsZXRvbiBwcmVmaXggYW5kIHdoYXRldmVyDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAg ICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgICAgICAgcmVxdWlyZW1l bnRzIGFyZSBwcm92aWRlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5Lg0KDQogICA3LiAg IEVhY2ggZXh0ZW5zaW9uIHN1YnRhZyBNVVNUIGJlIGZyb20gdHdvIHRvIGVpZ2h0IGNoYXJhY3Rl cnMgbG9uZw0KICAgICAgICBhbmQgY29uc2lzdCBzb2xlbHkgb2YgbGV0dGVycyBvciBkaWdpdHMs IHdpdGggZWFjaCBzdWJ0YWcNCiAgICAgICAgc2VwYXJhdGVkIGJ5IGEgc2luZ2xlICctJy4NCg0K ICAgOC4gICBFYWNoIHNpbmdsZXRvbiBNVVNUIGJlIGZvbGxvd2VkIGJ5IGF0IGxlYXN0IG9uZSBl eHRlbnNpb24NCiAgICAgICAgc3VidGFnLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgInRsaC1hLWIt Zm9vIiBpcyBpbnZhbGlkIGJlY2F1c2UNCiAgICAgICAgdGhlIGZpcnN0IHNpbmdsZXRvbiAnYScg aXMgZm9sbG93ZWQgaW1tZWRpYXRlbHkgYnkgYW5vdGhlcg0KICAgICAgICBzaW5nbGV0b24gJ2In Lg0KDQogICA5LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1QgZm9sbG93IGFsbCBsYW5ndWFnZSwg ZXh0ZW5kZWQgbGFuZ3VhZ2UsDQogICAgICAgIHNjcmlwdCwgcmVnaW9uIGFuZCB2YXJpYW50IHN1 YnRhZ3MgaW4gYSB0YWcuDQoNCiAgIDEwLiAgQWxsIHN1YnRhZ3MgZm9sbG93aW5nIHRoZSBzaW5n bGV0b24gYW5kIGJlZm9yZSBhbm90aGVyIHNpbmdsZXRvbg0KICAgICAgICBhcmUgcGFydCBvZiB0 aGUgZXh0ZW5zaW9uLiAgRXhhbXBsZTogSW4gdGhlIHRhZyAiZnItYS1MYXRuIiwgdGhlDQogICAg ICAgIHN1YnRhZyAnTGF0bicgZG9lcyBub3QgcmVwcmVzZW50IHRoZSBzY3JpcHQgc3VidGFnICdM YXRuJw0KICAgICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3Ry eS4gIEl0cyBtZWFuaW5nIGlzDQogICAgICAgIGRlZmluZWQgYnkgdGhlIGV4dGVuc2lvbiAnYScu DQoNCiAgIDExLiAgSW4gdGhlIGV2ZW50IHRoYXQgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24gYXBw ZWFycyBpbiBhIHNpbmdsZQ0KICAgICAgICB0YWcsIHRoZSB0YWcgU0hPVUxEIGJlIGNhbm9uaWNh bGl6ZWQgYXMgZGVzY3JpYmVkIGluDQogICAgICAgIFNlY3Rpb24gNC4zLg0KDQogICBGb3IgZXhh bXBsZSwgaWYgdGhlIHByZWZpeCBzaW5nbGV0b24gJ3InIGFuZCB0aGUgc2hvd24gc3VidGFncyB3 ZXJlDQogICBkZWZpbmVkLCB0aGVuIHRoZSBmb2xsb3dpbmcgdGFnIHdvdWxkIGJlIGEgdmFsaWQg ZXhhbXBsZTogImVuLUxhdG4tDQogICBHQi1ib29udC1yLWV4dGVuZGVkLXNlcXVlbmNlLXgtcHJp dmF0ZSINCg0KMi4yLjcgIFByaXZhdGUgVXNlIFN1YnRhZ3MNCg0KICAgVGhlIGZvbGxvd2luZyBy dWxlcyBhcHBseSB0byBwcml2YXRlLXVzZSBzdWJ0YWdzOg0KDQogICAxLiAgUHJpdmF0ZS11c2Ug c3VidGFncyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0KICAg ICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgdGhlIHJlc2VydmVkIHNpbmdsZS1jaGFyYWN0ZXIgc3Vi dGFnICd4Jy4NCg0KICAgMi4gIFByaXZhdGUtdXNlIHN1YnRhZ3MgTVVTVCBmb2xsb3cgYWxsIGxh bmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwNCiAgICAgICBzY3JpcHQsIHJlZ2lvbiwgdmFyaWFu dCwgYW5kIGV4dGVuc2lvbiBzdWJ0YWdzIGluIHRoZSB0YWcuDQogICAgICAgQW5vdGhlciB3YXkg b2Ygc2F5aW5nIHRoaXMgaXMgdGhhdCBhbGwgc3VidGFncyBmb2xsb3dpbmcgdGhlDQogICAgICAg c2luZ2xldG9uICd4JyBNVVNUIGJlIGNvbnNpZGVyZWQgcHJpdmF0ZSB1c2UuICBFeGFtcGxlOiBU aGUNCiAgICAgICBzdWJ0YWcgJ1VTJyBpbiB0aGUgdGFnICJlbi14LVVTIiBpcyBhIHByaXZhdGUg dXNlIHN1YnRhZy4NCg0KICAgMy4gIEEgdGFnIE1BWSBjb25zaXN0IGVudGlyZWx5IG9mIHByaXZh dGUtdXNlIHN1YnRhZ3MuDQoNCiAgIDQuICBObyBzb3VyY2UgaXMgZGVmaW5lZCBmb3IgcHJpdmF0 ZSB1c2Ugc3VidGFncy4gIFVzZSBvZiBwcml2YXRlIHVzZQ0KICAgICAgIHN1YnRhZ3MgaXMgYnkg cHJpdmF0ZSBhZ3JlZW1lbnQgb25seS4NCg0KICAgRm9yIGV4YW1wbGU6IFVzZXJzIHdobyB3aXNo ZWQgdG8gdXRpbGl6ZSBTSUwgRXRobm9sb2d1ZSBmb3INCiAgIGlkZW50aWZpY2F0aW9uIG1pZ2h0 IGFncmVlIHRvIGV4Y2hhbmdlIHRhZ3Mgc3VjaCBhcyAiYXotQXJhYi14LUFaRS0NCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAsIDIwMDUgICAgICAgICAg ICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KICAgZGVyYmVuZCIuICBUaGlz IGV4YW1wbGUgY29udGFpbnMgdHdvIHByaXZhdGUtdXNlIHN1YnRhZ3MuICBUaGUgZmlyc3QNCiAg IGlzICdBWkUnIGFuZCB0aGUgc2Vjb25kIGlzICdkZXJiZW5kJy4NCg0KMi4yLjggIFByZS1FeGlz dGluZyBSRkMgMzA2NiBSZWdpc3RyYXRpb25zDQoNCiAgIEV4aXN0aW5nIElBTkEtcmVnaXN0ZXJl ZCBsYW5ndWFnZSB0YWdzIGZyb20gUkZDIDE3NjYgYW5kL29yIFJGQyAzMDY2DQogICBtYWludGFp biB0aGVpciB2YWxpZGl0eS4gIElBTkEgd2lsbCBtYWludGFpbiB0aGVzZSB0YWdzIGluIHRoZQ0K ICAgcmVnaXN0cnkgdW5kZXIgZWl0aGVyIHRoZSAiZ3JhbmRmYXRoZXJlZCIgb3IgInJlZHVuZGFu dCIgdHlwZS4gIEZvcg0KICAgbW9yZSBpbmZvcm1hdGlvbiBzZWUgU2VjdGlvbiAzLjcuDQoNCiAg IEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgYWxsIGxhbmd1YWdlIHRhZ3MgZm9ybWVkIHVu ZGVyIHRoZQ0KICAgZ3VpZGVsaW5lcyBpbiB0aGlzIGRvY3VtZW50IHdlcmUgZWl0aGVyIGxlZ2Fs LCB3ZWxsLWZvcm1lZCB0YWdzIG9yDQogICBjb3VsZCBoYXZlIGJlZW4gcmVnaXN0ZXJlZCB1bmRl ciBSRkMgMzA2Ni4NCg0KMi4yLjkgIENsYXNzZXMgb2YgQ29uZm9ybWFuY2UNCg0KICAgSW1wbGVt ZW50YXRpb25zIG1heSB3aXNoIHRvIGV4cHJlc3MgdGhlaXIgbGV2ZWwgb2YgY29uZm9ybWFuY2Ug d2l0aA0KICAgdGhlIHJ1bGVzIGFuZCBwcmFjdGljZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQuICBUaGVyZSBhcmUNCiAgIGdlbmVyYWxseSB0d28gY2xhc3NlcyBvZiBjb25mb3JtaW5nIGlt cGxlbWVudGF0aW9uczogIndlbGwtZm9ybWVkIg0KICAgcHJvY2Vzc29ycyBhbmQgInZhbGlkYXRp bmciIHByb2Nlc3NvcnMuICBDbGFpbXMgb2YgY29uZm9ybWFuY2UgU0hPVUxEDQogICBleHBsaWNp dGx5IHJlZmVyZW5jZSBvbmUgb2YgdGhlc2UgZGVmaW5pdGlvbnMuDQoNCiAgIEFuIGltcGxlbWVu dGF0aW9uIHRoYXQgY2xhaW1zIHRvIGNoZWNrIGZvciB3ZWxsLWZvcm1lZCBsYW5ndWFnZSB0YWdz DQogICBNVVNUOg0KDQogICBvICBDaGVjayB0aGF0IHRoZSB0YWcgYW5kIGFsbCBvZiBpdHMgc3Vi dGFncywgaW5jbHVkaW5nIGV4dGVuc2lvbiBhbmQNCiAgICAgIHByaXZhdGUtdXNlIHN1YnRhZ3Ms IGNvbmZvcm0gdG8gdGhlIEFCTkYgb3IgdGhhdCB0aGUgdGFnIGlzIG9uIHRoZQ0KICAgICAgbGlz dCBvZiBncmFuZGZhdGhlcmVkIHRhZ3MuDQoNCiAgIG8gIENoZWNrIHRoYXQgc2luZ2xldG9uIHN1 YnRhZ3MgdGhhdCBpZGVudGlmeSBleHRlbnNpb25zIGRvIG5vdA0KICAgICAgcmVwZWF0LiAgRm9y IGV4YW1wbGUsIHRoZSB0YWcgImVuLWEteHgtYi15eS1hLXp6IiBpcyBub3Qgd2VsbC0NCiAgICAg IGZvcm1lZC4NCg0KICAgV2VsbC1mb3JtZWQgcHJvY2Vzc29ycyBhcmUgc3Ryb25nbHkgZW5jb3Vy YWdlZCB0byBpbXBsZW1lbnQgdGhlDQogICBjYW5vbmljYWxpemF0aW9uIHJ1bGVzIGNvbnRhaW5l ZCBpbiBTZWN0aW9uIDQuMy4NCg0KICAgQW4gaW1wbGVtZW50YXRpb24gdGhhdCBjbGFpbXMgdG8g YmUgdmFsaWRhdGluZyBNVVNUOg0KDQogICBvICBDaGVjayB0aGF0IHRoZSB0YWcgaXMgd2VsbC1m b3JtZWQuDQoNCiAgIG8gIFNwZWNpZnkgdGhlIHBhcnRpY3VsYXIgcmVnaXN0cnkgZGF0ZSBmb3Ig d2hpY2ggdGhlIGltcGxlbWVudGF0aW9uDQogICAgICBwZXJmb3JtcyB2YWxpZGF0aW9uIG9mIHN1 YnRhZ3MuDQoNCiAgIG8gIENoZWNrIHRoYXQgZWl0aGVyIHRoZSB0YWcgaXMgYSBncmFuZGZhdGhl cmVkIHRhZywgb3IgdGhhdCBhbGwNCiAgICAgIGxhbmd1YWdlLCBzY3JpcHQsIHJlZ2lvbiwgYW5k IHZhcmlhbnQgc3VidGFncyBjb25zaXN0IG9mIHZhbGlkDQogICAgICBjb2RlcyBmb3IgdXNlIGlu IGxhbmd1YWdlIHRhZ3MgYWNjb3JkaW5nIHRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzDQogICAgICBv ZiB0aGUgcGFydGljdWxhciBkYXRlIHNwZWNpZmllZCBieSB0aGUgaW1wbGVtZW50YXRpb24uDQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAsIDIwMDUg ICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KICAgbyAgU3Bl Y2lmeSB3aGljaCwgaWYgYW55LCBleHRlbnNpb24gUkZDcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24g My42DQogICAgICBhcmUgc3VwcG9ydGVkLCBpbmNsdWRpbmcgdmVyc2lvbiwgcmV2aXNpb24sIGFu ZCBkYXRlLg0KDQogICBvICBGb3IgYW55IHN1Y2ggZXh0ZW5zaW9ucyBzdXBwb3J0ZWQsIGNoZWNr IHRoYXQgYWxsIHN1YnRhZ3MgdXNlZCBpbg0KICAgICAgdGhhdCBleHRlbnNpb24gYXJlIHZhbGlk Lg0KDQogICBvICBJZiB0aGUgcHJvY2Vzc29yIGdlbmVyYXRlcyB0YWdzLCBpdCBNVVNUIGRvIHNv IGluIGNhbm9uaWNhbCBmb3JtLA0KICAgICAgaW5jbHVkaW5nIGFueSBzdXBwb3J0ZWQgZXh0ZW5z aW9ucywgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAg ICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQozLiAgUmVnaXN0 cnkgRm9ybWF0IGFuZCBNYWludGVuYW5jZQ0KDQogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUg TGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IGFuZCB0aGUgbWFpbnRlbmFuY2UNCiAgIGFuZCB1cGRh dGUgcHJvY2VkdXJlcyBhc3NvY2lhdGVkIHdpdGggaXQuDQoNCiAgIFRoZSBsYW5ndWFnZSBzdWJ0 YWcgcmVnaXN0cnkgd2lsbCBiZSBtYWludGFpbmVkIHNvIHRoYXQsIGV4Y2VwdCBmb3INCiAgIGV4 dGVuc2lvbiBzdWJ0YWdzLCBpdCBpcyBwb3NzaWJsZSB0byB2YWxpZGF0ZSBhbGwgb2YgdGhlIHN1 YnRhZ3MgdGhhdA0KICAgYXBwZWFyIGluIGEgbGFuZ3VhZ2UgdGFnIHVuZGVyIHRoZSBwcm92aXNp b25zIG9mIHRoaXMgZG9jdW1lbnQgb3IgaXRzDQogICByZXZpc2lvbnMgb3Igc3VjY2Vzc29ycy4g IEluIGFkZGl0aW9uLCB0aGUgbWVhbmluZyBvZiB0aGUgdmFyaW91cw0KICAgc3VidGFncyB3aWxs IGJlIHVuYW1iaWd1b3VzIGFuZCBzdGFibGUgb3ZlciB0aW1lLiAgKFRoZSBtZWFuaW5nIG9mDQog ICBwcml2YXRlLXVzZSBzdWJ0YWdzLCBvZiBjb3Vyc2UsIGlzIG5vdCBkZWZpbmVkIGJ5IHRoZSBJ QU5BIHJlZ2lzdHJ5LikNCg0KICAgVGhlIHJlZ2lzdHJ5IGRlZmluZWQgdW5kZXIgdGhpcyBkb2N1 bWVudCBjb250YWlucyBhIGNvbXByZWhlbnNpdmUNCiAgIGxpc3Qgb2YgYWxsIG9mIHRoZSBzdWJ0 YWdzIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MuICBUaGlzIGFsbG93cw0KICAgaW1wbGVtZW50ZXJz IGEgc3RyYWlnaHRmb3J3YXJkIGFuZCByZWxpYWJsZSB3YXkgdG8gdmFsaWRhdGUgbGFuZ3VhZ2UN CiAgIHRhZ3MuDQoNCjMuMSAgRm9ybWF0IG9mIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdp c3RyeQ0KDQogICBUaGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgKCJ0aGUgcmVnaXN0 cnkiKSB3aWxsIGNvbnNpc3Qgb2YgYQ0KICAgdGV4dCBmaWxlIHRoYXQgaXMgbWFjaGluZSByZWFk YWJsZSBpbiB0aGUgZm9ybWF0IGRlc2NyaWJlZCBpbiB0aGlzDQogICBzZWN0aW9uLCBwbHVzIGNv cGllcyBvZiB0aGUgcmVnaXN0cmF0aW9uIGZvcm1zIGFwcHJvdmVkIGJ5IHRoZQ0KICAgTGFuZ3Vh Z2UgU3VidGFnIFJldmlld2VyIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgcHJvY2VzcyBkZXNjcmli ZWQgaW4NCiAgIFNlY3Rpb24gMy40LiAgV2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSByZWdpc3Ry YXRpb24gZm9ybXMgZm9yDQogICBncmFuZGZhdGhlcmVkIGFuZCByZWR1bmRhbnQgdGFncywgbm8g cmVnaXN0cmF0aW9uIHJlY29yZHMgd2lsbCBiZQ0KICAgbWFpbnRhaW5lZCBmb3IgdGhlIGluaXRp YWwgc2V0IG9mIHN1YnRhZ3MuDQoNCiAgIFRoZSByZWdpc3RyeSB3aWxsIGJlIGluIGEgbW9kaWZp ZWQgcmVjb3JkLWphciBmb3JtYXQgdGV4dCBmaWxlIFsxN10uDQogICBMaW5lcyBhcmUgbGltaXRl ZCB0byA3MiBjaGFyYWN0ZXJzLCBpbmNsdWRpbmcgYWxsIHdoaXRlc3BhY2UuDQoNCiAgIFJlY29y ZHMgYXJlIHNlcGFyYXRlZCBieSBsaW5lcyBjb250YWluaW5nIG9ubHkgdGhlIHNlcXVlbmNlICIl JSINCiAgICgleDI1LjI1KS4NCg0KICAgRWFjaCBmaWVsZCBjYW4gYmUgdmlld2VkIGFzIGEgc2lu Z2xlLCBsb2dpY2FsICBsaW5lICBvZiBBU0NJSQ0KICAgY2hhcmFjdGVycywgIGNvbXByaXNpbmcg IGEgZmllbGQtbmFtZSBhbmQgYSBmaWVsZC1ib2R5IHNlcGFyYXRlZCBieSBhDQogICBDT0xPTiBj aGFyYWN0ZXIgKCV4M0EpLiAgRm9yIGNvbnZlbmllbmNlLCB0aGUgZmllbGQtYm9keSAgcG9ydGlv biAgb2YNCiAgIHRoaXMgIGNvbmNlcHR1YWwgZW50aXR5ICBjYW4gYmUgc3BsaXQgaW50byBhIG11 bHRpcGxlLWxpbmUNCiAgIHJlcHJlc2VudGF0aW9uOyB0aGlzIGlzIGNhbGxlZCAiZm9sZGluZyIu ICBUaGUgZm9ybWF0IG9mIHRoZSByZWdpc3RyeQ0KICAgaXMgZGVzY3JpYmVkIGJ5IHRoZSBmb2xs b3dpbmcgQUJORiAocGVyIFs3XSk6DQoNCiAgIHJlZ2lzdHJ5ICAgPSByZWNvcmQgKigiJSUiIENS TEYgcmVjb3JkKQ0KICAgcmVjb3JkICAgICA9IDEqKCBmaWVsZC1uYW1lICpTUCAiOiIgKlNQIGZp ZWxkLWJvZHkgQ1JMRiApDQogICBmaWVsZC1uYW1lID0gKihBTFBIQSAvIERJR0lUIC8gIi0iKQ0K ICAgZmllbGQtYm9keSA9ICooQVNDQ0hBUi9MV1NQKQ0KICAgQVNDQ0hBUiAgICA9ICV4MjEtMjUg LyAleDI3LTdFIC8gVU5JQ0hBUiA7IE5vdGU6IEFNUEVSU0FORCBpcyAleDI2DQogICBVTklDSEFS ICAgID0gIiYjeCIgMio2SEVYRElHICI7Ig0KDQogICBUaGUgc2VxdWVuY2UgJy4uJyAoJXgyRS4y RSkgaW4gYSBmaWVsZC1ib2R5IGRlbm90ZXMgYSByYW5nZSBvZg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2Ug MTddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQogICB2YWx1ZXMuICBTdWNoIGEgcmFuZ2UgcmVw cmVzZW50cyBhbGwgc3VidGFncyBvZiB0aGUgc2FtZSBsZW5ndGggdGhhdA0KICAgYXJlIGFscGhh YmV0aWNhbGx5IHdpdGhpbiB0aGF0IHJhbmdlLCBpbmNsdWRpbmcgdGhlIHZhbHVlcyBleHBsaWNp dGx5DQogICBtZW50aW9uZWQuICBGb3IgZXhhbXBsZSAnYS4uYycgZGVub3RlcyB0aGUgdmFsdWVz ICdhJywgJ2InLCBhbmQgJ2MnLg0KDQogICBDaGFyYWN0ZXJzIGZyb20gb3V0c2lkZSB0aGUgVVMt QVNDSUkgcmVwZXJ0b2lyZSwgYXMgd2VsbCBhcyB0aGUNCiAgIEFNUEVSU0FORCBjaGFyYWN0ZXIg KCImIiwgJXgyNikgd2hlbiBpdCBvY2N1cnMgaW4gYSBmaWVsZC1ib2R5IGFyZQ0KICAgcmVwcmVz ZW50ZWQgYnkgYSAiTnVtZXJpYyBDaGFyYWN0ZXIgUmVmZXJlbmNlIiB1c2luZyBoZXhhZGVjaW1h bA0KICAgbm90YXRpb24gaW4gdGhlIHN0eWxlIHVzZWQgYnkgWE1MIDEuMCBbMThdIChzZWUNCiAg IDxodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMteG1sLyNkdC1jaGFycmVmPikuICBUaGlzIGNvbnNp c3RzIG9mIHRoZQ0KICAgc2VxdWVuY2UgIiYjeCIgKCV4MjYuMjMuNzgpIGZvbGxvd2VkIGJ5IGEg aGV4YWRlY2ltYWwgcmVwcmVzZW50YXRpb24NCiAgIG9mIHRoZSBjaGFyYWN0ZXIncyBjb2RlIHBv aW50IGluIElTTy9JRUMgMTA2NDYgWzZdIGZvbGxvd2VkIGJ5IGENCiAgIGNsb3Npbmcgc2VtaWNv bG9uICgleDNCKS4gIEZvciBleGFtcGxlLCB0aGUgRVVSTyBTSUdOLCBVKzIwQUMsIHdvdWxkDQog ICBiZSByZXByZXNlbnRlZCBieSB0aGUgc2VxdWVuY2UgIiYjeDIwQUM7Ii4gIE5vdGUgdGhhdCB0 aGUgaGV4YWRlY2ltYWwNCiAgIG5vdGF0aW9uIG1heSBoYXZlIGJldHdlZW4gdHdvIGFuZCBzaXgg ZGlnaXRzLg0KDQogICBBbGwgZmllbGRzIHdob3NlIGZpZWxkLWJvZHkgY29udGFpbnMgYSBkYXRl IHZhbHVlIHVzZSB0aGUgImZ1bGwtZGF0ZSINCiAgIGZvcm1hdCBzcGVjaWZpZWQgaW4gUkZDIDMz MzkgWzE0XS4gIEZvciBleGFtcGxlOiAiMjAwNC0wNi0yOCINCiAgIHJlcHJlc2VudHMgSnVuZSAy OCwgMjAwNCBpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLg0KDQogICBUaGUgZmlyc3QgcmVjb3Jk IGluIHRoZSBmaWxlIGNvbnRhaW5zIHRoZSBzaW5nbGUgZmllbGQgd2hvc2UgZmllbGQtDQogICBu YW1lIGlzICJGaWxlLURhdGUiIGFuZCB3aG9zZSBmaWVsZC1ib2R5IGNvbnRhaW5zIHRoZSBsYXN0 DQogICBtb2RpZmljYXRpb24gZGF0ZSBvZiB0aGUgcmVnaXN0cnk6DQoNCiAgIEZpbGUtRGF0ZTog MjAwNC0wNi0yOA0KICAgJSUNCg0KICAgU3Vic2VxdWVudCByZWNvcmRzIHJlcHJlc2VudCBzdWJ0 YWdzIGluIHRoZSByZWdpc3RyeS4gIEVhY2ggb2YgdGhlDQogICBmaWVsZHMgaW4gZWFjaCByZWNv cmQgTVVTVCBvY2N1ciBubyBtb3JlIHRoYW4gb25jZSwgdW5sZXNzIG90aGVyd2lzZQ0KICAgbm90 ZWQgYmVsb3cuICBFYWNoIHJlY29yZCBNVVNUIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6 DQoNCiAgIG8gICdUeXBlJw0KDQogICAgICAqICBUeXBlJ3MgZmllbGQtdmFsdWUgTVVTVCBjb25z aXN0IG9mIG9uZSBvZiB0aGUgZm9sbG93aW5nDQogICAgICAgICBzdHJpbmdzOiAibGFuZ3VhZ2Ui LCAiZXh0bGFuZyIsICJzY3JpcHQiLCAicmVnaW9uIiwgInZhcmlhbnQiLA0KICAgICAgICAgImdy YW5kZmF0aGVyZWQiLCBhbmQgInJlZHVuZGFudCIgYW5kIGRlbm90ZXMgdGhlIHR5cGUgb2YgdGFn IG9yDQogICAgICAgICBzdWJ0YWcuDQoNCiAgIG8gIEVpdGhlciAnU3VidGFnJyBvciAnVGFnJw0K DQogICAgICAqICBTdWJ0YWcncyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgc3VidGFnIGJlaW5n IGRlZmluZWQuICBUaGlzDQogICAgICAgICBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29y ZHMgb2Ygd2hvc2UgVHlwZSBoYXMgb25lIG9mDQogICAgICAgICB0aGVzZSB2YWx1ZXM6ICJsYW5n dWFnZSIsICJleHRsYW5nIiwgInNjcmlwdCIsICJyZWdpb24iLCBvcg0KICAgICAgICAgInZhcmlh bnQiLg0KDQogICAgICAqICBUYWcncyBmaWVsZC12YWx1ZSBjb250YWlucyBhIGNvbXBsZXRlIGxh bmd1YWdlIHRhZy4gIFRoaXMgZmllbGQNCiAgICAgICAgIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVj b3JkcyB3aG9zZSBUeXBlIGhhcyBvbmUgb2YgdGhlc2UgdmFsdWVzOg0KICAgICAgICAgImdyYW5k ZmF0aGVyZWQiIG9yICJyZWR1bmRhbnQiLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAxOF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICAgICBNYXkgMjAwNQ0KDQoNCiAgIG8gIERlc2NyaXB0aW9uDQoNCiAgICAgICogIERlc2NyaXB0 aW9uJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBub24tbm9ybWF0aXZlIGRlc2NyaXB0aW9uDQog ICAgICAgICBvZiB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgQWRkZWQNCg0KICAgICAgKiAg QWRkZWQncyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcyBhZGRl ZCB0bw0KICAgICAgICAgdGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgJ1N1YnRhZycgb3IgJ1RhZycg ZmllbGQgTVVTVCB1c2UgbG93ZXJjYXNlIGxldHRlcnMgdG8gZm9ybSB0aGUNCiAgIHN1YnRhZyBv ciB0YWcsIHdpdGggdHdvIGV4Y2VwdGlvbnMuICBTdWJ0YWdzIHdob3NlICdUeXBlJyBmaWVsZCBp cw0KICAgJ3NjcmlwdCcgKGluIG90aGVyIHdvcmRzLCBzdWJ0YWdzIGRlZmluZWQgYnkgSVNPIDE1 OTI0KSBNVVNUIHVzZQ0KICAgdGl0bGVjYXNlLiAgU3VidGFncyB3aG9zZSAnVHlwZScgZmllbGQg aXMgJ3JlZ2lvbicgKGluIG90aGVyIHdvcmRzLA0KICAgc3VidGFncyBkZWZpbmVkIGJ5IElTTyAz MTY2KSBNVVNUIHVzZSB1cHBlcmNhc2UuICBUaGVzZSBleGNlcHRpb25zDQogICBtaXJyb3IgdGhl IHVzZSBvZiBjYXNlIGluIHRoZSB1bmRlcmx5aW5nIHN0YW5kYXJkcy4NCg0KICAgVGhlIGZpZWxk ICdEZXNjcmlwdGlvbicgTUFZIGFwcGVhciBtb3JlIHRoYW4gb25lIHRpbWUuICBBdCBsZWFzdCBv bmUNCiAgIG9mIHRoZSAgJ0Rlc2NyaXB0aW9uJyBmaWVsZHMgbXVzdCBjb250YWluIGEgZGVzY3Jp cHRpb24gb2YgdGhlIHRhZw0KICAgYmVpbmcgcmVnaXN0ZXJlZCB3cml0dGVuIG9yIHRyYW5zY3Jp YmVkIGludG8gdGhlIExhdGluIHNjcmlwdDsgdGhlDQogICBzYW1lIG9yIGFkZGl0aW9uYWwgZmll bGRzIG1heSBhbHNvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5vbi0NCiAgIExhdGluIHNj cmlwdC4gIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGlzIHVzZWQgZm9yIGlkZW50aWZpY2F0aW9u DQogICBwdXJwb3NlcyBhbmQgc2hvdWxkIG5vdCBiZSB0YWtlbiB0byByZXByZXNlbnQgdGhlIGFj dHVhbCBuYXRpdmUgbmFtZQ0KICAgb2YgdGhlIGxhbmd1YWdlIG9yIHZhcmlhdGlvbiBvciB0byBi ZSBpbiBhbnkgcGFydGljdWxhciBsYW5ndWFnZS4NCiAgIE1vc3QgZGVzY3JpcHRpb25zIGFyZSB0 YWtlbiBkaXJlY3RseSBmcm9tIHNvdXJjZSBzdGFuZGFyZHMgc3VjaCBhcw0KICAgSVNPIDYzOSBv ciBJU08gMzE2Ni4NCg0KICAgTm90ZTogRGVzY3JpcHRpb25zIGluIHJlZ2lzdHJ5IGVudHJpZXMg dGhhdCBjb3JyZXNwb25kIHRvIElTTyA2MzksDQogICBJU08gMTU5MjQsICBJU08gMzE2NiBvciBV TiBNLjQ5IGNvZGVzIGFyZSBpbnRlbmRlZCBvbmx5IHRvIGluZGljYXRlDQogICB0aGUgbWVhbmlu ZyBvZiB0aGF0IGlkZW50aWZpZXIgYXMgZGVmaW5lZCBpbiB0aGUgc291cmNlIHN0YW5kYXJkIGF0 DQogICB0aGUgdGltZSBpdCB3YXMgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5LiAgVGhlIGRlc2NyaXB0 aW9uIGRvZXMgbm90DQogICByZXBsYWNlIHRoZSBjb250ZW50IG9mIHRoZSBzb3VyY2Ugc3RhbmRh cmQgaXRzZWxmLiAgVGhlIGRlc2NyaXB0aW9ucw0KICAgYXJlIG5vdCBpbnRlbmRlZCB0byBiZSB0 aGUgRW5nbGlzaCBsb2NhbGl6ZWQgbmFtZXMgZm9yIHRoZSBzdWJ0YWdzLg0KICAgTG9jYWxpemF0 aW9uIG9yIHRyYW5zbGF0aW9uIG9mIGxhbmd1YWdlIHRhZyBhbmQgc3VidGFnIGRlc2NyaXB0aW9u cw0KICAgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIEVhY2ggcmVjb3Jk IE1BWSBhbHNvIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoNCiAgIG8gIENhbm9uaWNh bA0KDQogICAgICAqICBGb3IgZmllbGRzIG9mIHR5cGUgJ2xhbmd1YWdlJywgJ2V4dGxhbmcnLCAn c2NyaXB0JywgJ3JlZ2lvbicsDQogICAgICAgICBhbmQgJ3ZhcmlhbnQnLCBhIGNhbm9uaWNhbCBt YXBwaW5nIG9mIHRoaXMgcmVjb3JkIHRvIGEgc3VidGFnDQogICAgICAgICByZWNvcmQgb2YgdGhl IHNhbWUgJ1R5cGUnLg0KDQogICAgICAqICBGb3IgZmllbGRzIG9mIHR5cGUgJ2dyYW5kZmF0aGVy ZWQnIGFuZCAncmVkdW5kYW50JywgYSBjYW5vbmljYWwNCiAgICAgICAgIG1hcHBpbmcgdG8gYSBj b21wbGV0ZSBsYW5ndWFnZSB0YWcuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMTldDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg ICAgTWF5IDIwMDUNCg0KDQogICBvICBEZXByZWNhdGVkDQoNCiAgICAgICogIERlcHJlY2F0ZWQn cyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcw0KICAgICAgICAg ZGVwcmVjYXRlZC4NCg0KICAgbyAgUmVjb21tZW5kZWQtUHJlZml4DQoNCiAgICAgICogIFJlY29t bWVuZGVkLVByZWZpeCdzIGZpZWxkLXZhbHVlIGNvbnRhaW5zIGEgbGFuZ3VhZ2UgdGFnIHdpdGgN CiAgICAgICAgIHdoaWNoIHRoaXMgc3VidGFnIG1heSBiZSB1c2VkIHRvIGZvcm0gYSBuZXcgbGFu Z3VhZ2UgdGFnLA0KICAgICAgICAgcGVyaGFwcyB3aXRoIG90aGVyIHN1YnRhZ3MgYXMgd2VsbC4g IFRoaXMgZmllbGQgTVVTVCBvbmx5DQogICAgICAgICBhcHBlYXIgaW4gcmVjb3JkcyB3aG9zZSAn VHlwZScgZmllbGQtdmFsdWUgaXMgJ3ZhcmlhbnQnIG9yDQogICAgICAgICAnZXh0bGFuZycuICBG b3IgZXhhbXBsZSwgdGhlICdSZWNvbW1lbmRlZC1QcmVmaXgnIGZvciB0aGUNCiAgICAgICAgIHZh cmlhbnQgJ3Njb3VzZScgaXMgJ2VuJywgbWVhbmluZyB0aGF0IHRoZSB0YWdzICJlbi1zY291c2Ui IGFuZA0KICAgICAgICAgImVuLUdCLXNjb3VzZSIgbWlnaHQgYmUgYXBwcm9wcmlhdGUgd2hpbGUg dGhlIHRhZyAiaXMtc2NvdXNlIg0KICAgICAgICAgaXMgbm90Lg0KDQogICBvICBDb21tZW50cw0K DQogICAgICAqICBDb21tZW50cyBjb250YWlucyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBzdWJ0YWcsIGFzDQogICAgICAgICBkZWVtZWQgYXBwcm9wcmlhdGUgZm9yIHVuZGVyc3Rh bmRpbmcgdGhlIHJlZ2lzdHJ5IGFuZA0KICAgICAgICAgaW1wbGVtZW50aW5nIGxhbmd1YWdlIHRh Z3MgdXNpbmcgdGhlIHN1YnRhZyBvciB0YWcuDQoNCiAgIG8gIFN1cHByZXNzLVNjcmlwdA0KDQog ICAgICAqICBTdXBwcmVzcy1TY3JpcHQgY29udGFpbnMgYSBzY3JpcHQgc3VidGFnIHRoYXQgU0hP VUxEIE5PVCBiZQ0KICAgICAgICAgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mgd2l0aCB0aGUg YXNzb2NpYXRlZCBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgICBzdWJ0YWcuICBUaGlzIGZpZWxk IE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3JkcyB3aG9zZSAnVHlwZScNCiAgICAgICAgIGZpZWxk LXZhbHVlIGlzICdsYW5ndWFnZScuICBTZWUgU2VjdGlvbiA0LjEuDQoNCiAgIFRoZSBmaWVsZCAn Q2Fub25pY2FsJyBTSEFMTCBOT1QgYmUgYWRkZWQgdG8gYW55IHJlY29yZCBhbHJlYWR5IGluIHRo ZQ0KICAgcmVnaXN0cnkuICBUaGUgZmllbGQgJ0Nhbm9uaWNhbCcgU0hBTEwgTk9UIGJlIG1vZGlm aWVkIGV4Y2VwdCBmb3INCiAgIHJlY29yZHMgb2YgdHlwZSAiZ3JhbmRmYXRoZXJlZCI6IHRoZXJl Zm9yZSBhIHN1YnRhZyB3aG9zZSByZWNvcmQNCiAgIGNvbnRhaW5zIG5vIGNhbm9uaWNhbCBtYXBw aW5nIHdoZW4gdGhlIHJlY29yZCBpcyBjcmVhdGVkIGlzIGENCiAgIGNhbm9uaWNhbCBmb3JtIGFu ZCB3aWxsIHJlbWFpbiBzby4NCg0KICAgVGhlICdDYW5vbmljYWwnIGZpZWxkIGluIHJlY29yZHMg b2YgdHlwZSAiZ3JhbmRmYXRoZXJlZCIgYW5kDQogICAicmVkdW5kYW50IiBjb250YWlucyB3aG9s ZSBsYW5ndWFnZSB0YWdzIHRoYXQgYXJlIFNUUk9OR0xZDQogICBSRUNPTU1FTkRFRCBmb3IgdXNl IGluIHBsYWNlIG9mIHRoZSByZWNvcmQncyB2YWx1ZS4gIEluIG1hbnkgY2FzZXMNCiAgIHRoZSBt YXBwaW5ncyB3ZXJlIGNyZWF0ZWQgYnkgZGVwcmVjYXRpb24gb2YgdGhlIHRhZ3MgZHVyaW5nIHRo ZQ0KICAgcGVyaW9kIGJlZm9yZSB0aGlzIGRvY3VtZW50IHdhcyBhZG9wdGVkLiAgRm9yIGV4YW1w bGUsIHRoZSB0YWcgIm5vLQ0KICAgbnluIiB3YXMgZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUg SVNPIDYzOS0xIGRlZmluZWQgbGFuZ3VhZ2UgY29kZQ0KICAgJ25uJy4NCg0KICAgTm90ZSB0aGF0 IGEgcmVjb3JkIHRoYXQgaGFzIGEgJ0Nhbm9uaWNhbCcgZmllbGQgTVVTVCBoYXZlIGENCiAgICdE ZXByZWNhdGVkJyBmaWVsZCBhbHNvIChhbHRob3VnaCB0aGUgY29udmVyc2UgaXMgbm90IHRydWUp Lg0KDQogICBUaGUgZmllbGQgJ0RlcHJlY2F0ZWQnIE1BWSBiZSBhZGRlZCB0byBhbnkgcmVjb3Jk IHZpYSB0aGUgbWFpbnRlbmFuY2UNCiAgIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4y IG9yIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDIwXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgICAgIE1heSAyMDA1DQoNCg0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LiAgVXN1 YWxseSB0aGUgYWRkaXRpb24gb2YgYSAnRGVwcmVjYXRlZCcNCiAgIGZpZWxkIGlzIGR1ZSB0byB0 aGUgYWN0aW9uIG9mIG9uZSBvZiB0aGUgc3RhbmRhcmRzIGJvZGllcywgc3VjaCBhcw0KICAgSVNP IDMxNjYsIHdpdGhkcmF3aW5nIGEgY29kZS4gIEluIHNvbWUgaGlzdG9yaWNhbCBjYXNlcyBpdCBt YXkgbm90DQogICBoYXZlIGJlZW4gIHBvc3NpYmxlIHRvIHJlY29uc3RydWN0IHRoZSBvcmlnaW5h bCBkZXByZWNhdGlvbiBkYXRlLg0KICAgRm9yIHRoZXNlIGNhc2VzLCBhbiBhcHByb3hpbWF0ZSBk YXRlIGFwcGVhcnMgaW4gdGhlIHJlZ2lzdHJ5Lg0KICAgQWx0aG91Z2ggdmFsaWQgaW4gbGFuZ3Vh Z2UgdGFncywgc3VidGFncyBhbmQgdGFncyB3aXRoIGEgJ0RlcHJlY2F0ZWQnDQogICBmaWVsZCBh cmUgZGVwcmVjYXRlZCBhbmQgdmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VMRCBOT1QgZ2VuZXJh dGUNCiAgIHRoZXNlIHN1YnRhZ3MuICBOb3RlIHRoYXQgYSByZWNvcmQgdGhhdCBjb250YWlucyBh ICdEZXByZWNhdGVkJyBmaWVsZA0KICAgYW5kIG5vIGNvcnJlc3BvbmRpbmcgJ0Nhbm9uaWNhbCcg ZmllbGQgaGFzIG5vIHJlcGxhY2VtZW50IG1hcHBpbmcuDQoNCiAgIFRoZSBmaWVsZCAnUmVjb21t ZW5kZWQtUHJlZml4JyBNQVkgYXBwZWFyIG1vcmUgdGhhbiBvbmNlIHBlciByZWNvcmQuDQogICBB ZGRpdGlvbmFsIGZpZWxkcyBvZiB0aGlzIHR5cGUgTUFZIGJlIGFkZGVkIHRvIGEgcmVjb3JkIHZp YSB0aGUNCiAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiAgVGhlIGZpZWxkLXZhbHVlIG9mIG9mIHRo aXMgZmllbGQgY29uc2lzdHMgb2YgYQ0KICAgbGFuZ3VhZ2UgdGFnIHRoYXQgaXMgUkVDT01NRU5E RUQgZm9yIHVzZSBhcyBhIHByZWZpeCBmb3IgdGhpcyBzdWJ0YWcuDQogICBGb3IgZXhhbXBsZSwg dGhlIHZhcmlhbnQgc3VidGFnICdzY291c2UnIGhhcyBhIHJlY29tbWVuZGVkIHByZWZpeCBvZg0K ICAgImVuIi4gIFRoaXMgbWVhbnMgdGhhdCB0YWdzIHN0YXJ0aW5nIHdpdGggdGhlIHByZWZpeCAi ZW4tIiBhcmUgbW9zdA0KICAgYXBwcm9wcmlhdGUgd2l0aCB0aGlzIHN1YnRhZywgc28gImVuLUxh dG4tc2NvdXNlIiBhbmQgImVuLUdCLXNjb3VzZSINCiAgIGFyZSBib3RoIGFjY2VwdGFibGUsIHdo aWxlIHRoZSB0YWcgImZyLXNjb3VzZSIgaXMgcHJvYmFibHkgYW4NCiAgIGluYXBwcm9wcmlhdGUg Y2hvaWNlLg0KDQogICBUaGUgZmllbGQgb2YgdHlwZSBSZWNvbW1lbmRlZC1QcmVmaXggTVVTVCBO T1QgYmUgcmVtb3ZlZCBmcm9tIGFueQ0KICAgcmVjb3JkLiAgVGhlIGZpZWxkLXZhbHVlIGZvciB0 aGlzIHR5cGUgb2YgZmllbGQgTVVTVCBOT1QgYmUgbW9kaWZpZWQuDQoNCiAgIFRoZSBmaWVsZCAn Q29tbWVudHMnIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgcGVyIHJlY29yZC4gIFRoaXMNCiAg IGZpZWxkIE1BWSBiZSBpbnNlcnRlZCBvciBjaGFuZ2VkIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHBy b2Nlc3MgYW5kIG5vDQogICBndWFyYW50ZWUgb2Ygc3RhYmlsaXR5IGlzIHByb3ZpZGVkLiAgVGhl IGNvbnRlbnQgb2YgdGhpcyBmaWVsZCBpcyBub3QNCiAgIHJlc3RyaWN0ZWQsIGV4Y2VwdCBieSB0 aGUgbmVlZCB0byByZWdpc3RlciB0aGUgaW5mb3JtYXRpb24sIHRoZQ0KICAgc3VpdGFiaWxpdHkg b2YgdGhlIHJlcXVlc3QsIGFuZCBieSByZWFzb25hYmxlIHByYWN0aWNhbCBzaXplDQogICBsaW1p dGF0aW9ucy4gIExvbmcgc2NyZWVkcyBhYm91dCBhIHBhcnRpY3VsYXIgc3VidGFnIGFyZSBmcm93 bmVkDQogICB1cG9uLg0KDQogICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTVVTVCBvbmx5 IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1 YWdlJy4gIFRoaXMgZmllbGQgbWF5IGFwcGVhciBhdCBtb3N0IG9uZSB0aW1lIGluDQogICBhIHJl Y29yZC4gIFRoaXMgZmllbGQgaW5kaWNhdGVzIGEgc2NyaXB0IHVzZWQgdG8gd3JpdGUgdGhlDQog ICBvdmVyd2hlbG1pbmcgbWFqb3JpdHkgb2YgZG9jdW1lbnRzIGZvciB0aGUgZ2l2ZW4gbGFuZ3Vh Z2UgYW5kIHdoaWNoDQogICB0aGVyZWZvcmUgYWRkcyBubyBkaXN0aW5ndWlzaGluZyBpbmZvcm1h dGlvbiB0byBhIGxhbmd1YWdlIHRhZy4gIEl0DQogICBoZWxwcyBlbnN1cmUgZ3JlYXRlciBjb21w YXRpYmlsaXR5IGJldHdlZW4gdGhlIGxhbmd1YWdlIHRhZ3MNCiAgIGdlbmVyYXRlZCBhY2NvcmRp bmcgdG8gdGhlIHJ1bGVzIGluIHRoaXMgZG9jdW1lbnQgYW5kIGxhbmd1YWdlIHRhZ3MNCiAgIGFu ZCB0YWcgcHJvY2Vzc29ycyBvciBjb25zdW1lcnMgYmFzZWQgb24gUkZDIDMwNjYuICBGb3IgZXhh bXBsZSwNCiAgIHZpcnR1YWxseSBhbGwgSWNlbGFuZGljIGRvY3VtZW50cyBhcmUgd3JpdHRlbiBp biB0aGUgTGF0aW4gc2NyaXB0LA0KICAgbWFraW5nIHRoZSBzdWJ0YWcgJ0xhdG4nIHJlZHVuZGFu dCBpbiB0aGUgdGFnICJpcy1MYXRuIi4NCg0KICAgRm9yIGV4YW1wbGVzIG9mIHJlZ2lzdHJ5IGVu dHJpZXMgYW5kIHRoZWlyIGZvcm1hdCwgc2VlIEFwcGVuZGl4IEMuDQoNCjMuMiAgTWFpbnRlbmFu Y2Ugb2YgdGhlIFJlZ2lzdHJ5DQoNCiAgIE1haW50ZW5hbmNlIG9mIHRoZSByZWdpc3RyeSByZXF1 aXJlcyB0aGF0IGFzIG5ldyBjb2RlcyBhcmUgYXNzaWduZWQNCiAgIGJ5IElTTyA2MzksIElTTyAx NTkyNCwgYW5kIElTTyAzMTY2LCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAg ICAgICBbUGFnZSAyMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgIHdpbGwgZXZhbHVhdGUg ZWFjaCBhc3NpZ25tZW50LCBkZXRlcm1pbmUgd2hldGhlciBpdCBjb25mbGljdHMgd2l0aA0KICAg ZXhpc3RpbmcgcmVnaXN0cnkgZW50cmllcywgYW5kIHN1Ym1pdCB0aGUgaW5mb3JtYXRpb24gdG8g SUFOQSBmb3INCiAgIGluY2x1c2lvbiBpbiB0aGUgcmVnaXN0cnkuICBJZiBhbiBhc3NpZ25tZW50 IHRha2VzIHBsYWNlIGFuZCB0aGUNCiAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBkb2VzIG5v dCBkbyB0aGlzIGluIGEgdGltZWx5IG1hbm5lciwgdGhlbg0KICAgYW55IGludGVyZXN0ZWQgcGFy dHkgbWF5IHVzZSB0aGUgcHJvY2VkdXJlIGluIFNlY3Rpb24gMy40IHRvIHJlZ2lzdGVyDQogICB0 aGUgYXBwcm9wcmlhdGUgdXBkYXRlLg0KDQogICBOb3RlOiBUaGUgcmVkdW5kYW50IGFuZCBncmFu ZGZhdGhlcmVkIGVudHJpZXMgdG9nZXRoZXIgYXJlIHRoZQ0KICAgY29tcGxldGUgbGlzdCBvZiB0 YWdzIHJlZ2lzdGVyZWQgdW5kZXIgUkZDIDMwNjYgWzIzXS4gIFRoZSByZWR1bmRhbnQNCiAgIHRh Z3MgYXJlIHRob3NlIHRoYXQgY2FuIG5vdyBiZSBmb3JtZWQgdXNpbmcgdGhlIHN1YnRhZ3MgZGVm aW5lZCBpbg0KICAgdGhlIHJlZ2lzdHJ5IHRvZ2V0aGVyIHdpdGggdGhlIHJ1bGVzIG9mICBTZWN0 aW9uIDIuMi4gIFRoZQ0KICAgZ3JhbmRmYXRoZXJlZCBlbnRyaWVzIGFyZSB0aG9zZSB0aGF0IGNh biBuZXZlciBiZSBsZWdhbCB1bmRlciB0aG9zZQ0KICAgc2FtZSBwcm92aXNpb25zLiAgVGhlIGl0 ZW1zIGluIGJvdGggbGlzdHMgYXJlIHBlcm1hbmVudCBhbmQgc3RhYmxlLA0KICAgYWx0aG91Z2gg Z3JhbmRmYXRoZXJlZCBpdGVtcyBtYXkgYmUgZGVwcmVjYXRlZCBvdmVyIHRpbWUuICBSZWZlciB0 bw0KICAgU2VjdGlvbiAzLjcgZm9yIG1vcmUgaW5mb3JtYXRpb24uDQoNCiAgIFJGQyAzMDY2IHRh Z3MgdGhhdCB3ZXJlIGRlcHJlY2F0ZWQgcHJpb3IgdG8gdGhlIGFkb3B0aW9uIG9mIHRoaXMNCiAg IGRvY3VtZW50IGFyZSBwYXJ0IG9mIHRoZSBsaXN0IG9mIGdyYW5kZmF0aGVyZWQgdGFncyBhbmQg dGhlaXINCiAgIGNvbXBvbmVudCBzdWJ0YWdzIHdlcmUgbm90IGluY2x1ZGVkIGFzIHJlZ2lzdGVy ZWQgdmFyaWFudHMgKGFsdGhvdWdoDQogICB0aGV5IHJlbWFpbiBlbGlnaWJsZSBmb3IgcmVnaXN0 cmF0aW9uKS4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJhcnQtDQogICBsb2piYW4iIHdhcyBkZXBy ZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBsYW5ndWFnZSBzdWJ0YWcgJ2pibycuDQoNCiAgIFRoZSBM YW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBlbnN1cmUgdGhhdCBuZXcgc3VidGFncyBtZWV0 IHRoZQ0KICAgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gNC4xIG9yIHN1Ym1pdCBhbiBhcHByb3By aWF0ZSBhbHRlcm5hdGUgc3VidGFnDQogICBhcyBkZXNjcmliZWQgaW4gdGhhdCBzZWN0aW9uLiAg SWYgYSBjaGFuZ2Ugb3IgYWRkaXRpb24gdG8gdGhlDQogICByZWdpc3RyeSBpcyByZXF1aXJlZCwg dGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciB3aWxsIHByZXBhcmUgdGhlDQogICBjb21wbGV0 ZSByZWNvcmQsIGluY2x1ZGluZyBhbGwgZmllbGRzLCBhbmQgZm9yd2FyZCBpdCB0byBJQU5BIGZv cg0KICAgaW5zZXJ0aW9uIGludG8gdGhlIHJlZ2lzdHJ5LiAgSWYgdGhpcyByZXByZXNlbnRzIGEg bmV3IHN1YnRhZywgdGhlbg0KICAgdGhlIG1lc3NhZ2Ugd2lsbCBpbmRpY2F0ZSB0aGF0IHRoaXMg cmVwcmVzZW50cyBhbiBJTlNFUlRJT04gb2YgYQ0KICAgcmVjb3JkLiAgSWYgdGhpcyByZXByZXNl bnRzIGEgY2hhbmdlIHRvIGFuIGV4aXN0aW5nIHN1YnRhZywgdGhlbiB0aGUNCiAgIG1lc3NhZ2Ug bXVzdCBpbmRpY2F0ZSB0aGF0IHRoaXMgcmVwcmVzZW50cyBhIE1PRElGSUNBVElPTiwgYXMgc2hv d24NCiAgIGluIHRoZSBmb2xsb3dpbmcgZXhhbXBsZToNCg0KICAgTEFOR1VBR0UgU1VCVEFHIE1P RElGSUNBVElPTg0KICAgRmlsZS1EYXRlOiAyMDA1LTAxLTAyDQogICAlJQ0KICAgVHlwZTogdmFy aWFudA0KICAgU3VidGFnOiBuZWRpcw0KICAgRGVzY3JpcHRpb246IE5hdGlzb25lIGRpYWxlY3QN CiAgIERlc2NyaXB0aW9uOiBOYWRpemEgZGlhbGVjdA0KICAgQWRkZWQ6IDIwMDMtMTAtMDkNCiAg IFJlY29tbWVuZGVkLVByZWZpeDogc2wNCiAgIENvbW1lbnRzOiBUaGlzIGlzIGEgY29tbWVudCBz aG93bg0KICAgICBhcyBhbiBleGFtcGxlLg0KICAgJSUNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDQNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAg TWF5IDIwMDUNCg0KDQogICBXaGVuZXZlciBhbiBlbnRyeSBpcyBjcmVhdGVkIG9yIG1vZGlmaWVk IGluIHRoZSByZWdpc3RyeSwgdGhlICdGaWxlLQ0KICAgRGF0ZScgcmVjb3JkIGF0IHRoZSBzdGFy dCBvZiB0aGUgcmVnaXN0cnkgaXMgdXBkYXRlZCB0byByZWZsZWN0IHRoZQ0KICAgbW9zdCByZWNl bnQgbW9kaWZpY2F0aW9uIGRhdGUgaW4gdGhlIFJGQyAzMzM5IFsxNF0gImZ1bGwtZGF0ZSINCiAg IGZvcm1hdC4NCg0KICAgVmFsdWVzIGluIHRoZSAnU3VidGFnJyBmaWVsZCBtdXN0IGJlIGxvd2Vy Y2FzZSBleGNlcHQgYXMgcHJvdmlkZWQgZm9yDQogICBpbiBTZWN0aW9uIDMuMS4NCg0KMy4zICBT dGFiaWxpdHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVzDQoNCiAgIFRoZSBzdGFiaWxpdHkgb2Yg ZW50cmllcyBhbmQgdGhlaXIgbWVhbmluZyBpbiB0aGUgcmVnaXN0cnkgaXMNCiAgIGNyaXRpY2Fs IHRvIHRoZSBsb25nIHRlcm0gc3RhYmlsaXR5IG9mIGxhbmd1YWdlIHRhZ3MuICBUaGUgcnVsZXMg aW4NCiAgIHRoaXMgc2VjdGlvbiBndWFyYW50ZWUgdGhhdCBhIHNwZWNpZmljIGxhbmd1YWdlIHRh ZydzIG1lYW5pbmcgaXMNCiAgIHN0YWJsZSBvdmVyIHRpbWUgYW5kIHdpbGwgbm90IGNoYW5nZSBh bmQgdGhhdCB0aGUgY2hvaWNlIG9mIGxhbmd1YWdlDQogICB0YWcgZm9yIHNwZWNpZmljIGNvbnRl bnQgaXMgYWxzbyBzdGFibGUgb3ZlciB0aW1lLg0KDQogICBUaGVzZSBydWxlcyBzcGVjaWZpY2Fs bHkgZGVhbCB3aXRoIGhvdyBjaGFuZ2VzIHRvIGNvZGVzIChpbmNsdWRpbmcNCiAgIHdpdGhkcmF3 YWwgYW5kIGRlcHJlY2F0aW9uIG9mIGNvZGVzKSBtYWludGFpbmVkIGJ5IElTTyA2MzksIElTTw0K ICAgMTU5MjQsIElTTyAzMTY2LCBhbmQgVU4gTS40OSBhcmUgcmVmbGVjdGVkIGluIHRoZSBJQU5B IExhbmd1YWdlDQogICBTdWJ0YWcgUmVnaXN0cnkuICBBc3NpZ25tZW50cyB0byB0aGUgSUFOQSBM YW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkNCiAgIE1VU1QgZm9sbG93IHRoZSBmb2xsb3dpbmcgc3Rh YmlsaXR5IHJ1bGVzOg0KDQogICBvICBWYWx1ZXMgaW4gdGhlIGZpZWxkcyAnVHlwZScsICdTdWJ0 YWcnLCAnVGFnJywgJ0FkZGVkJyBhbmQNCiAgICAgICdDYW5vbmljYWwnIE1VU1QgTk9UIGJlIGNo YW5nZWQgYW5kIGFyZSBndWFyYW50ZWVkIHRvIGJlIHN0YWJsZQ0KICAgICAgb3ZlciB0aW1lLg0K DQogICBvICBWYWx1ZXMgaW4gdGhlICdEZXNjcmlwdGlvbicgZmllbGQgTVVTVCBOT1QgYmUgY2hh bmdlZCBpbiBhIHdheQ0KICAgICAgdGhhdCB3b3VsZCBpbnZhbGlkYXRlIHByZXZpb3VzbHktZXhp c3RpbmcgdGFncy4gIFRoZXkgbWF5IGJlDQogICAgICBicm9hZGVuZWQgc29tZXdoYXQgaW4gc2Nv cGUsIGNoYW5nZWQgdG8gYWRkIGluZm9ybWF0aW9uLCBvcg0KICAgICAgYWRhcHRlZCB0byB0aGUg bW9zdCBjb21tb24gbW9kZXJuIHVzYWdlLiAgRm9yIGV4YW1wbGUsIGNvdW50cmllcw0KICAgICAg b2NjYXNpb25hbGx5IGNoYW5nZSB0aGVpciBvZmZpY2lhbCBuYW1lczogYW4gaGlzdG9yaWNhbCBl eGFtcGxlIG9mDQogICAgICB0aGlzIHdvdWxkIGJlICJVcHBlciBWb2x0YSIgY2hhbmdpbmcgdG8g IkJ1cmtpbmEgRmFzbyIuDQoNCiAgIG8gIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1JlY29tbWVuZGVk LVByZWZpeCcgTUFZIGJlIGFkZGVkIHZpYSB0aGUNCiAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNz Lg0KDQogICBvICBWYWx1ZXMgaW4gdGhlIGZpZWxkICdSZWNvbW1lbmRlZC1QcmVmaXgnIE1BWSBi ZSBtb2RpZmllZCwgc28gbG9uZw0KICAgICAgYXMgdGhlIG1vZGlmaWNhdGlvbnMgYnJvYWRlbiB0 aGUgc2V0IG9mIHJlY29tbWVuZGVkIHByZWZpeGVzLg0KICAgICAgVGhhdCBpcywgYSByZWNvbW1l bmRlZCBwcmVmaXggTUFZIGJlIHJlcGxhY2VkIGJ5IG9uZSBvZiBpdHMgb3duDQogICAgICBwcmVm aXhlcy4gIEZvciBleGFtcGxlLCB0aGUgcHJlZml4ICJlbi1VUyIgY291bGQgYmUgcmVwbGFjZWQg YnkNCiAgICAgICJlbiIsIGJ1dCBub3QgYnkgdGhlIHJhbmdlcyAiZW4tTGF0biIsICJmciIsIG9y ICJlbi1VUy1ib29udCIuDQoNCiAgIG8gIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1JlY29tbWVuZGVk LVByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZC4NCg0KICAgbyAgVGhlIGZpZWxkICdDb21tZW50 cycgTUFZIGJlIGFkZGVkLCBjaGFuZ2VkLCBtb2RpZmllZCwgb3IgcmVtb3ZlZA0KICAgICAgdmlh IHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBvciBhbnkgb2YgdGhlIHByb2Nlc3NlcyBvcg0KICAg ICAgY29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbi4NCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAg ICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQogICBvICBUaGUgZmllbGQgJ1N1 cHByZXNzLVNjcmlwdCcgTUFZIGJlIGFkZGVkIG9yIHJlbW92ZWQgdmlhIHRoZQ0KICAgICAgcmVn aXN0cmF0aW9uIHByb2Nlc3MuDQoNCiAgIG8gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElT TyAxNTkyNCwgYW5kIElTTyAzMTY2IHRoYXQgZG8gbm90DQogICAgICBjb25mbGljdCB3aXRoIGV4 aXN0aW5nIHN1YnRhZ3Mgb2YgdGhlIGFzc29jaWF0ZWQgdHlwZSBhbmQgd2hvc2UNCiAgICAgIG1l YW5pbmcgaXMgbm90IHRoZSBzYW1lIGFzIGFuIGV4aXN0aW5nIHN1YnRhZyBvZiB0aGUgc2FtZSB0 eXBlIGFyZQ0KICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNv cmRzIGFuZCB0aGVpciB2YWx1ZSBpcw0KICAgICAgY2Fub25pY2FsIGZvciB0aGUgbWVhbmluZyBh c3NpZ25lZCB0byB0aGVtLg0KDQogICBvICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08g MTU5MjQsIG9yIElTTyAzMTY2IHRoYXQgYXJlDQogICAgICB3aXRoZHJhd24gYnkgdGhlaXIgcmVz cGVjdGl2ZSBtYWludGVuYW5jZSBvciByZWdpc3RyYXRpb24NCiAgICAgIGF1dGhvcml0eSByZW1h aW4gdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAg ICAgTUFZIGJlIHVzZWQgdG8gYWRkIGEgbm90ZSBpbmRpY2F0aW5nIHRoZSB3aXRoZHJhd2FsIG9m IHRoZSBjb2RlIGJ5DQogICAgICB0aGUgcmVzcGVjdGl2ZSBzdGFuZGFyZC4NCg0KICAgbyAgQ29k ZXMgYXNzaWduZWQgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBvciBJU08gMzE2NiB0aGF0IGRvIG5v dA0KICAgICAgY29uZmxpY3Qgd2l0aCBleGlzdGluZyBzdWJ0YWdzIG9mIHRoZSBhc3NvY2lhdGVk IHR5cGUgYnV0IHdoaWNoDQogICAgICByZXByZXNlbnQgdGhlIHNhbWUgbWVhbmluZyBhcyBhbiBl eGlzdGluZyBzdWJ0YWcgb2YgdGhhdCB0eXBlIGFyZQ0KICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJ QU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRzLiAgVGhlIGZpZWxkDQogICAgICAnY2Fub25pY2Fs IHZhbHVlJyBmb3IgdGhhdCByZWNvcmQgTVVTVCBjb250YWluIHRoZSBleGlzdGluZyBzdWJ0YWcN CiAgICAgIG9mIHRoZSBzYW1lIG1lYW5pbmcNCg0KICAgICAgRXhhbXBsZSBJZiBJU08gMzE2NiB3 ZXJlIHRvIGFzc2lnbiB0aGUgY29kZSAnSU0nIHRvIHJlcHJlc2VudCB0aGUNCiAgICAgICAgIHZh bHVlICJJc2xlIG9mIE1hbiIgKHJlcHJlc2VudGVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGJ5IHRo ZSBVTg0KICAgICAgICAgTS40OSBjb2RlICc4MzMnKSwgJzgzMycgcmVtYWlucyB0aGUgY2Fub25p Y2FsIHN1YnRhZyBhbmQgJ0lNJw0KICAgICAgICAgd291bGQgYmUgYXNzaWduZWQgJzgzMycgYXMg YSBjYW5vbmljYWwgdmFsdWUuICBUaGlzIHByZXZlbnRzDQogICAgICAgICB0YWdzIHRoYXQgYXJl IGluIGNhbm9uaWNhbCBmb3JtIGZyb20gYmVjb21pbmcgbm9uLWNhbm9uaWNhbC4NCg0KICAgICAg RXhhbXBsZSBJZiB0aGUgdGFnICdlbm9jaGlhbicgd2VyZSByZWdpc3RlcmVkIGFzIGEgcHJpbWFy eQ0KICAgICAgICAgbGFuZ3VhZ2Ugc3VidGFnIGFuZCBJU08gNjM5IHN1YnNlcXVlbnRseSBhc3Np Z25lZCBhbiBhbHBoYS0zDQogICAgICAgICBjb2RlIHRvIHRoZSBzYW1lIGxhbmd1YWdlLCB0aGUg bmV3IElTTyA2MzkgY29kZSB3b3VsZCBiZQ0KICAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJQU5B IHJlZ2lzdHJ5IGFzIGEgc3VidGFnIHdpdGggYSBjYW5vbmljYWwNCiAgICAgICAgIG1hcHBpbmcg dG8gJ2Vub2NoaWFuJy4gIFRoZSBuZXcgSVNPIGNvZGUgY2FuIGJlIHVzZWQsIGJ1dCBpdCBpcw0K ICAgICAgICAgbm90IGNhbm9uaWNhbC4NCg0KICAgbyAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYz OSwgSVNPIDE1OTI0LCBvciBJU08gMzE2NiB0aGF0IGNvbmZsaWN0DQogICAgICB3aXRoIGV4aXN0 aW5nIHN1YnRhZ3Mgb2YgdGhlIGFzc29jaWF0ZWQgdHlwZSBNVVNUIE5PVCBiZSBlbnRlcmVkDQog ICAgICBpbnRvIHRoZSByZWdpc3RyeS4gIFRoZSBmb2xsb3dpbmcgYWRkaXRpb25hbCBjb25zaWRl cmF0aW9ucyBhcHBseToNCg0KICAgICAgKiAgRm9yIElTTyA2MzkgY29kZXMsIGlmIHRoZSBuZXds eSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcyBub3QNCiAgICAgICAgIHJlcHJlc2VudGVkIGJ5 IGEgc3VidGFnIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LCB0aGUgTGFuZ3VhZ2UNCiAgICAgICAgIFN1 YnRhZyBSZXZpZXdlciwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LCBzaGFsbCBwcmVwYXJl IGENCiAgICAgICAgIHByb3Bvc2FsIGZvciBlbnRlcmluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSBh cyBzb29uIGFzIHByYWN0aWNhbA0KICAgICAgICAgYSByZWdpc3RlcmVkIGxhbmd1YWdlIHN1YnRh ZyBhcyBhbiBhbHRlcm5hdGUgdmFsdWUgZm9yIHRoZSBuZXcNCiAgICAgICAgIGNvZGUuICBUaGUg Zm9ybSBvZiB0aGUgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcgd2lsbCBiZSBhdA0KICAgICAg ICAgdGhlIGRpc2NyZXRpb24gb2YgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBhbmQgbXVz dCBjb25mb3JtDQogICAgICAgICB0byBvdGhlciByZXN0cmljdGlvbnMgb24gbGFuZ3VhZ2Ugc3Vi dGFncyBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg ICBNYXkgMjAwNQ0KDQoNCiAgICAgICogIEZvciBhbGwgc3VidGFncyB3aG9zZSBtZWFuaW5nIGlz IGRlcml2ZWQgZnJvbSBhbiBleHRlcm5hbA0KICAgICAgICAgc3RhbmRhcmQgKGkuZS4gIElTTyA2 MzksIElTTyAxNTkyNCwgSVNPIDMxNjYsIG9yIFVOIE0uNDkpLCBpZiBhDQogICAgICAgICBuZXcg bWVhbmluZyBpcyBhc3NpZ25lZCB0byBhbiBleGlzdGluZyBjb2RlIGFuZCB0aGUgbmV3IG1lYW5p bmcNCiAgICAgICAgIGJyb2FkZW5zIHRoZSBtZWFuaW5nIG9mIHRoYXQgY29kZSwgdGhlbiB0aGUg bWVhbmluZyBmb3IgdGhlDQogICAgICAgICBhc3NvY2lhdGVkIHN1YnRhZyBNQVkgYmUgY2hhbmdl ZCB0byBtYXRjaC4gIFRoZSBtZWFuaW5nIG9mIGENCiAgICAgICAgIHN1YnRhZyBNVVNUIE5PVCBi ZSBuYXJyb3dlZCwgaG93ZXZlciwgYXMgdGhpcyBjYW4gcmVzdWx0IGluIGFuDQogICAgICAgICB1 bmtub3duIHByb3BvcnRpb24gb2YgdGhlIGV4aXN0aW5nIHVzZXMgb2YgYSBzdWJ0YWcgYmVjb21p bmcNCiAgICAgICAgIGludmFsaWQuICBOb3RlOiBJU08gNjM5IE1BL1JBIGhhcyBhZG9wdGVkIGEg c2ltaWxhciBzdGFiaWxpdHkNCiAgICAgICAgIHBvbGljeS4NCg0KICAgICAgKiAgRm9yIElTTyAx NTkyNCBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAg ICAgICBub3QgcmVwcmVzZW50ZWQgYnkgYSBzdWJ0YWcgaW4gdGhlIElBTkEgcmVnaXN0cnksIHRo ZSBMYW5ndWFnZQ0KICAgICAgICAgU3VidGFnIFJldmlld2VyLCBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiAzLjQsIHNoYWxsIHByZXBhcmUgYQ0KICAgICAgICAgcHJvcG9zYWwgZm9yIGVudGVyaW5n IGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIHNvb24gYXMgcHJhY3RpY2FsDQogICAgICAgICBhIHJl Z2lzdGVyZWQgdmFyaWFudCBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRlIHZhbHVlIGZvciB0aGUgbmV3 DQogICAgICAgICBjb2RlLiAgVGhlIGZvcm0gb2YgdGhlIHJlZ2lzdGVyZWQgdmFyaWFudCBzdWJ0 YWcgd2lsbCBiZSBhdCB0aGUNCiAgICAgICAgIGRpc2NyZXRpb24gb2YgdGhlIExhbmd1YWdlIFN1 YnRhZyBSZXZpZXdlciBhbmQgbXVzdCBjb25mb3JtIHRvDQogICAgICAgICBvdGhlciByZXN0cmlj dGlvbnMgb24gdmFyaWFudCBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICogIEZv ciBJU08gMzE2NiBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlz DQogICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgVU4gTS40OSBjb2RlIGFzIGFub3Ro ZXIgJ3JlZ2lvbicNCiAgICAgICAgIHN1YnRhZywgdGhlbiB0aGUgZXhpc3RpbmcgcmVnaW9uIHN1 YnRhZyByZW1haW5zIGFzIHRoZQ0KICAgICAgICAgY2Fub25pY2FsIGVudHJ5IGZvciB0aGF0IHJl Z2lvbiBhbmQgbm8gbmV3IGVudHJ5IGlzIGNyZWF0ZWQuICBBDQogICAgICAgICBjb21tZW50IE1B WSBiZSBhZGRlZCB0byB0aGUgZXhpc3RpbmcgcmVnaW9uIHN1YnRhZyBpbmRpY2F0aW5nDQogICAg ICAgICB0aGUgcmVsYXRpb25zaGlwIHRvIHRoZSBuZXcgSVNPIDMxNjYgY29kZS4NCg0KICAgICAg KiAgRm9yIElTTyAzMTY2IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5p bmcgaXMNCiAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCBhIFVOIE0uNDkgY29kZSB0aGF0IGlzIG5v dCByZXByZXNlbnRlZCBieSBhbg0KICAgICAgICAgZXhpc3RpbmcgcmVnaW9uIHN1YnRhZywgdGhl biB0aGVuIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsDQogICAgICAgICBhcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiAzLjQsIHNoYWxsIHByZXBhcmUgYSBwcm9wb3NhbCBmb3INCiAgICAgICAg IGVudGVyaW5nIHRoZSBhcHByb3ByaWF0ZSBudW1lcmljIFVOIGNvdW50cnkgY29kZSBhcyBhbiBl bnRyeSBpbg0KICAgICAgICAgdGhlIElBTkEgcmVnaXN0cnkuDQoNCiAgICAgICogIEZvciBJU08g MzE2NiBjb2RlcywgaWYgdGhlcmUgaXMgbm8gYXNzb2NpYXRlZCBVTiBudW1lcmljIGNvZGUsDQog ICAgICAgICB0aGVuIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgU0hBTEwgcGV0aXRpb24g dGhlIFVOIHRvDQogICAgICAgICBjcmVhdGUgb25lLiAgSWYgdGhlcmUgaXMgbm8gcmVzcG9uc2Ug ZnJvbSB0aGUgVU4gd2l0aGluIG5pbmV0eQ0KICAgICAgICAgZGF5cyBvZiB0aGUgcmVxdWVzdCBi ZWluZyBzZW50LCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyDQogICAgICAgICBzaGFsbCBw cmVwYXJlIGEgcHJvcG9zYWwgZm9yIGVudGVyaW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzDQog ICAgICAgICBzb29uIGFzIHByYWN0aWNhbCBhIHJlZ2lzdGVyZWQgdmFyaWFudCBzdWJ0YWcgYXMg YW4gYWx0ZXJuYXRlDQogICAgICAgICB2YWx1ZSBmb3IgdGhlIG5ldyBjb2RlLiAgVGhlIGZvcm0g b2YgdGhlIHJlZ2lzdGVyZWQgdmFyaWFudA0KICAgICAgICAgc3VidGFnIHdpbGwgYmUgYXQgdGhl IGRpc2NyZXRpb24gb2YgdGhlIExhbmd1YWdlIFN1YnRhZw0KICAgICAgICAgUmV2aWV3ZXIgYW5k IG11c3QgY29uZm9ybSB0byBvdGhlciByZXN0cmljdGlvbnMgb24gdmFyaWFudA0KICAgICAgICAg c3VidGFncyBpbiB0aGlzIGRvY3VtZW50LiAgVGhpcyBzaXR1YXRpb24gaXMgdmVyeSB1bmxpa2Vs eSB0bw0KICAgICAgICAgZXZlciBvY2N1ci4NCg0KICAgbyAgU3RhYmlsaXR5IHByb3Zpc2lvbnMg YXBwbHkgdG8gZ3JhbmRmYXRoZXJlZCB0YWdzIHdpdGggdGhpcw0KICAgICAgZXhjZXB0aW9uOiBz aG91bGQgYWxsIG9mIHRoZSBzdWJ0YWdzIGluIGEgZ3JhbmRmYXRoZXJlZCB0YWcgYmVjb21lDQog ICAgICB2YWxpZCBzdWJ0YWdzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LCB0aGVuIHRoZSBncmFuZGZh dGhlcmVkIHRhZw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJl ciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMjVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0K DQogICAgICBNVVNUIGJlIG1hcmtlZCBhcyByZWR1bmRhbnQuICBOb3RlIHRoYXQgdGhpcyB3aWxs IG5vdCBhZmZlY3QNCiAgICAgIGxhbmd1YWdlIHRhZ3MgdGhhdCBtYXRjaCB0aGUgZ3JhbmRmYXRo ZXJlZCB0YWcsIHNpbmNlIHRoZXNlIHRhZ3MNCiAgICAgIHdpbGwgbm93IG1hdGNoIHZhbGlkIGdl bmVyYXRpdmUgc3VidGFnIHNlcXVlbmNlcy4gIEZvciBleGFtcGxlLCBpZg0KICAgICAgdGhlIHN1 YnRhZyAnZ2FuJyBpbiB0aGUgbGFuZ3VhZ2UgdGFnICJ6aC1nYW4iIHdlcmUgdG8gYmUNCiAgICAg IHJlZ2lzdGVyZWQgYXMgYW4gZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnLCB0aGVuIHRoZSBncmFu ZGZhdGhlcmVkDQogICAgICB0YWcgInpoLWdhbiIgd291bGQgYmUgZGVwcmVjYXRlZCAoYnV0IGV4 aXN0aW5nIGNvbnRlbnQgb3INCiAgICAgIGltcGxlbWVudGF0aW9ucyB0aGF0IHVzZSAiemgtZ2Fu IiB3b3VsZCByZW1haW4gdmFsaWQpLg0KDQoNCjMuNCAgUmVnaXN0cmF0aW9uIFByb2NlZHVyZSBm b3IgU3VidGFncw0KDQogICBUaGUgcHJvY2VkdXJlIGdpdmVuIGhlcmUgTVVTVCBiZSB1c2VkIGJ5 IGFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGENCiAgIHN1YnRhZyBub3QgY3VycmVudGx5IGluIHRo ZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4NCg0KICAgT25seSBzdWJ0YWdzICBvZiB0 eXBlICdsYW5ndWFnZScgYW5kICd2YXJpYW50JyB3aWxsIGJlIGNvbnNpZGVyZWQgZm9yDQogICBp bmRlcGVuZGVudCByZWdpc3RyYXRpb24gb2YgbmV3IHN1YnRhZ3MuICBIYW5kbGluZyBvZiBzdWJ0 YWdzDQogICByZXF1aXJlZCBmb3Igc3RhYmlsaXR5IGFuZCBzdWJ0YWdzIHJlcXVpcmVkIHRvIGtl ZXAgdGhlIHJlZ2lzdHJ5DQogICBzeW5jaHJvbml6ZWQgd2l0aCBJU08gNjM5LCBJU08gMTU5MjQs IElTTyAzMTY2LCBhbmQgVU4gTS40OSB3aXRoaW4NCiAgIHRoZSBsaW1pdHMgZGVmaW5lZCBieSB0 aGlzIGRvY3VtZW50IGFyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuDQogICBTdGFiaWxpdHkg cHJvdmlzaW9ucyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLg0KDQogICBUaGlzIHByb2Nl ZHVyZSBNQVkgYWxzbyBiZSB1c2VkIHRvIHJlZ2lzdGVyIG9yIGFsdGVyIHRoZSBpbmZvcm1hdGlv bg0KICAgZm9yIHRoZSAiRGVzY3JpcHRpb24iLCAiQ29tbWVudHMiLCAiRGVwcmVjYXRlZCIsIG9y ICJSZWNvbW1lbmRlZC0NCiAgIFByZWZpeCIgZmllbGRzIGluIGEgc3VidGFnJ3MgcmVjb3JkIGFz IGRlc2NyaWJlZCBpbiBGaWd1cmUgNy4NCiAgIENoYW5nZXMgdG8gYWxsIG90aGVyIGZpZWxkcyBp biB0aGUgSUFOQSByZWdpc3RyeSBhcmUgTk9UIHBlcm1pdHRlZC4NCg0KICAgUmVnaXN0ZXJpbmcg YSBuZXcgc3VidGFnIG9yIHJlcXVlc3RpbmcgbW9kaWZpY2F0aW9ucyB0byBhbiBleGlzdGluZw0K ICAgdGFnIG9yIHN1YnRhZyBzdGFydHMgd2l0aCB0aGUgcmVxdXN0ZXIgZmlsbGluZyBvdXQgdGhl IHJlZ2lzdHJhdGlvbg0KICAgZm9ybSByZXByb2R1Y2VkIGJlbG93LiAgTm90ZSB0aGF0IGVhY2gg cmVzcG9uc2UgaXMgbm90IGxpbWl0ZWQgaW4NCiAgIHNpemUgYW5kIHNob3VsZCB0YWtlIHRoZSBy b29tIG5lY2Vzc2FyeSB0byBhZGVxdWF0ZWx5IGRlc2NyaWJlIHRoZQ0KICAgcmVnaXN0cmF0aW9u LiAgVGhlIGZpZWxkcyBpbiB0aGUgIlJlY29yZCBSZXF1ZXN0ZWQiIHNlY3Rpb24gU0hPVUxEDQog ICBmb2xsb3cgdGhlIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDMuMS4NCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIw MDUNCg0KDQogICBMQU5HVUFHRSBTVUJUQUcgUkVHSVNUUkFUSU9OIEZPUk0NCiAgIDEuIE5hbWUg b2YgcmVxdWVzdGVyOg0KICAgMi4gRS1tYWlsIGFkZHJlc3Mgb2YgcmVxdWVzdGVyOg0KICAgMy4g UmVjb3JkIFJlcXVlc3RlZDoNCg0KICAgVHlwZToNCiAgIFN1YnRhZzoNCiAgIERlc2NyaXB0aW9u Og0KICAgUmVjb21tZW5kZWQtUHJlZml4Og0KICAgQ2Fub25pY2FsOg0KICAgRGVwcmVjYXRlZDoN CiAgIFN1cHByZXNzLVNjcmlwdDoNCiAgIENvbW1lbnRzOg0KDQogICA0LiBJbnRlbmRlZCBtZWFu aW5nIG9mIHRoZSBzdWJ0YWc6DQogICA1LiBSZWZlcmVuY2UgdG8gcHVibGlzaGVkIGRlc2NyaXB0 aW9uDQogICBvZiB0aGUgbGFuZ3VhZ2UgKGJvb2sgb3IgYXJ0aWNsZSk6DQogICA2LiBBbnkgb3Ro ZXIgcmVsZXZhbnQgaW5mb3JtYXRpb246DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZpZ3VyZSA1DQoNCiAgIFRoZSBzdWJ0YWcgcmVnaXN0cmF0aW9uIGZvcm0gTVVTVCBiZSBz ZW50IHRvDQogICA8aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmc+IGZvciBhIHR3byB3ZWVrIHJldmll dyBwZXJpb2QgYmVmb3JlIGl0IGNhbg0KICAgYmUgc3VibWl0dGVkIHRvIElBTkEuICAoVGhpcyBp cyBhbiBvcGVuIGxpc3QuICBSZXF1ZXN0cyB0byBiZSBhZGRlZA0KICAgc2hvdWxkIGJlIHNlbnQg dG8gPGlldGYtbGFuZ3VhZ2VzLXJlcXVlc3RAaWFuYS5vcmc+LikNCg0KICAgVmFyaWFudCBzdWJ0 YWdzIGFyZSBnZW5lcmFsbHkgcmVnaXN0ZXJlZCBmb3IgdXNlIHdpdGggYSBwYXJ0aWN1bGFyDQog ICByYW5nZSBvZiBsYW5ndWFnZSB0YWdzLiAgRm9yIGV4YW1wbGUsIHRoZSBzdWJ0YWcgJ3Njb3Vz ZScgaXMgaW50ZW5kZWQNCiAgIGZvciB1c2Ugd2l0aCBsYW5ndWFnZSB0YWdzIHRoYXQgc3RhcnQg d2l0aCB0aGUgcHJpbWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnICJlbiIsIHNpbmNlIFNjb3VzZSBp cyBhIGRpYWxlY3Qgb2YgRW5nbGlzaC4gIFRodXMgdGhlIHN1YnRhZw0KICAgJ3Njb3VzZScgY291 bGQgYmUgaW5jbHVkZWQgaW4gdGFncyBzdWNoIGFzICJlbi1MYXRuLXNjb3VzZSIgb3IgImVuLQ0K ICAgR0Itc2NvdXNlIi4gIFRoaXMgaW5mb3JtYXRpb24gaXMgc3RvcmVkIGluIHRoZSAiUmVjb21t ZW5kZWQtUHJlZml4Ig0KICAgZmllbGQgaW4gdGhlIHJlZ2lzdHJ5LiAgVmFyaWFudCByZWdpc3Ry YXRpb24gcmVxdWVzdHMgYXJlIFJFUVVJUkVEIHRvDQogICBpbmNsdWRlIGF0IGxlYXN0IG9uZSAi UmVjb21tZW5kZWQtUHJlZml4IiBmaWVsZCBpbiB0aGUgcmVnaXN0cmF0aW9uDQogICBmb3JtLg0K DQogICBBbnkgc3VidGFnIE1BWSBiZSBpbmNvcnBvcmF0ZWQgaW50byBhIHZhcmlldHkgb2YgbGFu Z3VhZ2UgdGFncywNCiAgIGFjY29yZGluZyB0byB0aGUgcnVsZXMgb2YgU2VjdGlvbiAyLjEsIGlu Y2x1ZGluZyB0YWdzIHRoYXQgZG8gbm90DQogICBtYXRjaCBhbnkgb2YgdGhlIHJlY29tbWVuZGVk IHByZWZpeGVzIG9mIHRoZSByZWdpc3RlcmVkIHN1YnRhZy4NCiAgIChOb3RlIHRoYXQgdGhpcyBp cyBwcm9iYWJseSBhIHBvb3IgY2hvaWNlLikgIFRoaXMgbWFrZXMgdmFsaWRhdGlvbg0KICAgc2lt cGxlciBhbmQgdGh1cyBtb3JlIHVuaWZvcm0gYWNyb3NzIGltcGxlbWVudGF0aW9ucywgYW5kIGRv ZXMgbm90DQogICByZXF1aXJlIHRoZSByZWdpc3RyYXRpb24gb2YgYSBzZXBhcmF0ZSBzdWJ0YWcg Zm9yIHRoZSBzYW1lIHB1cnBvc2UNCiAgIGFuZCBtZWFuaW5nIGJ1dCBhIGRpZmZlcmVudCByZWNv bW1lbmRlZCBwcmVmaXguDQoNCiAgIFRoZSByZWNvbW1lbmRlZCBwcmVmaXhlcyBmb3IgYSBnaXZl biByZWdpc3RlcmVkIHN1YnRhZyB3aWxsIGJlDQogICBtYWludGFpbmVkIGluIHRoZSBJQU5BIHJl Z2lzdHJ5IGFzIGEgZ3VpZGUgdG8gdXNhZ2UuICBJZiBpdCBpcw0KICAgbmVjZXNzYXJ5IHRvIGFk ZCBhbiBhZGRpdGlvbmFsIHByZWZpeCB0byB0aGF0IGxpc3QgZm9yIGFuIGV4aXN0aW5nDQogICBs YW5ndWFnZSB0YWcsIHRoYXQgY2FuIGJlIGRvbmUgYnkgZmlsaW5nIGFuIGFkZGl0aW9uYWwgcmVn aXN0cmF0aW9uDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVy IDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAyN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoN CiAgIGZvcm0uICBJbiB0aGF0IGZvcm0sIHRoZSAiQW55IG90aGVyIHJlbGV2YW50IGluZm9ybWF0 aW9uOiIgZmllbGQNCiAgIHNob3VsZCBpbmRpY2F0ZSB0aGF0IGl0IGlzIHRoZSBhZGRpdGlvbiBv ZiBhbiBhZGRpdGlvbmFsIHJlY29tbWVuZGVkDQogICBwcmVmaXguDQoNCiAgIFJlcXVlc3RzIHRv IGFkZCBhIHJlY29tbWVuZGVkIHByZWZpeCB0byBhIHN1YnRhZyB0aGF0IGltcGx5IGENCiAgIGRp ZmZlcmVudCBzZW1hbnRpYyBtZWFuaW5nIHdpbGwgcHJvYmFibHkgYmUgcmVqZWN0ZWQuICBGb3Ig ZXhhbXBsZSwgYQ0KICAgcmVxdWVzdCB0byBhZGQgdGhlIHByZWZpeCAiZGUiIHRvIHRoZSBzdWJ0 YWcgJ25lZGlzJyBzbyB0aGF0IHRoZSB0YWcNCiAgICJkZS1uZWRpcyIgcmVwcmVzZW50ZWQgc29t ZSBHZXJtYW4gZGlhbGVjdCB3b3VsZCBiZSByZWplY3RlZC4gIFRoZQ0KICAgJ25lZGlzJyBzdWJ0 YWcgcmVwcmVzZW50cyBhIHBhcnRpY3VsYXIgU2xvdmVuaWFuIGRpYWxlY3QgYW5kIHRoZQ0KICAg YWRkaXRpb25hbCByZWdpc3RyYXRpb24gd291bGQgY2hhbmdlIHRoZSBzZW1hbnRpYyBtZWFuaW5n IGFzc2lnbmVkIHRvDQogICB0aGUgc3VidGFnLiAgQSBzZXBhcmF0ZSBzdWJ0YWcgc2hvdWxkIGJl IHByb3Bvc2VkIGluc3RlYWQuDQoNCiAgIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIG11c3QgY29u dGFpbiBhIGRlc2NyaXB0aW9uIG9mIHRoZSB0YWcgYmVpbmcNCiAgIHJlZ2lzdGVyZWQgd3JpdHRl biBvciB0cmFuc2NyaWJlZCBpbnRvIHRoZSBMYXRpbiBzY3JpcHQ7IGl0IG1heSBhbHNvDQogICBp bmNsdWRlIGEgZGVzY3JpcHRpb24gaW4gYSBub24tTGF0aW4gc2NyaXB0LiAgTm9uLUFTQ0lJIGNo YXJhY3RlcnMNCiAgIG11c3QgYmUgZXNjYXBlZCB1c2luZyB0aGUgc3ludGF4IGRlc2NyaWJlZCBp biBTZWN0aW9uIDMuMS4gIFRoZQ0KICAgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBpcyB1c2VkIGZvciBp ZGVudGlmaWNhdGlvbiBwdXJwb3NlcyBhbmQgc2hvdWxkDQogICBub3QgYmUgdGFrZW4gdG8gcmVw cmVzZW50IHRoZSBhY3R1YWwgbmF0aXZlIG5hbWUgb2YgdGhlIGxhbmd1YWdlIG9yDQogICB2YXJp YXRpb24gb3IgdG8gYmUgaW4gYW55IHBhcnRpY3VsYXIgbGFuZ3VhZ2UuDQoNCiAgIFdoaWxlIHRo ZSAnRGVzY3JpcHRpb24nIGZpZWxkIGl0c2VsZiBpcyBub3QgZ3VhcmFudGVlZCB0byBiZSBzdGFi bGUNCiAgIGFuZCBlcnJhdGEgY29ycmVjdGlvbnMgbWF5IGJlIHVuZGVydGFrZW4gZnJvbSB0aW1l IHRvIHRpbWUsIGF0dGVtcHRzDQogICB0byBwcm92aWRlIHRyYW5zbGF0aW9ucyBvciB0cmFuc2Ny aXB0aW9ucyBvZiBlbnRyaWVzIGluIHRoZSByZWdpc3RyeQ0KICAgaXRzZWxmIHdpbGwgcHJvYmFi bHkgYmUgZnJvd25lZCB1cG9uIGJ5IHRoZSBjb21tdW5pdHkgb3IgcmVqZWN0ZWQNCiAgIG91dHJp Z2h0LCBhcyBjaGFuZ2VzIG9mIHRoaXMgbmF0dXJlIG1heSBpbXBhY3QgdGhlIHByb3Zpc2lvbnMg aW4NCiAgIFNlY3Rpb24gMy4zLg0KDQogICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGlz IHJlc3BvbnNpYmxlIGZvciByZXNwb25kaW5nIHRvDQogICByZXF1ZXN0cyBmb3IgdGhlIHJlZ2lz dHJhdGlvbiBvZiBzdWJ0YWdzIHRocm91Z2ggdGhlIHJlZ2lzdHJhdGlvbg0KICAgcHJvY2VzcyAg YW5kIGlzIGFwcG9pbnRlZCBieSB0aGUgSUVTRy4NCg0KICAgV2hlbiB0aGUgdHdvIHdlZWsgcGVy aW9kIGhhcyBwYXNzZWQgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlcg0KICAgZWl0aGVyIGZv cndhcmRzIHRoZSByZWNvcmQgdG8gYmUgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgdG8NCiAgIGlhbmFA aWFuYS5vcmcgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmUgZGVzY3JpYmVkIGluIFNlY3Rpb24g My4yLCBvcg0KICAgcmVqZWN0cyB0aGUgcmVxdWVzdCBiZWNhdXNlIG9mIHNpZ25pZmljYW50IG9i amVjdGlvbnMgcmFpc2VkIG9uIHRoZQ0KICAgbGlzdCBvciBkdWUgdG8gcHJvYmxlbXMgd2l0aCBj b25zdHJhaW50cyBpbiB0aGlzIGRvY3VtZW50ICh3aGljaA0KICAgc2hvdWxkIGJlIGV4cGxpY2l0 bHkgY2l0ZWQpLiAgVGhlIHJldmlld2VyIG1heSBhbHNvIGV4dGVuZCB0aGUgcmV2aWV3DQogICBw ZXJpb2QgaW4gdHdvIHdlZWsgaW5jcmVtZW50cyB0byBwZXJtaXQgZnVydGhlciBkaXNjdXNzaW9u LiAgVGhlDQogICByZXZpZXdlciBtdXN0IGluZGljYXRlIG9uIHRoZSBsaXN0IHdoZXRoZXIgdGhl IHJlZ2lzdHJhdGlvbiBoYXMgYmVlbg0KICAgYWNjZXB0ZWQsIHJlamVjdGVkLCBvciBleHRlbmRl ZCBmb2xsb3dpbmcgZWFjaCB0d28gd2VlayBwZXJpb2QuDQoNCiAgIE5vdGUgdGhhdCB0aGUgcmV2 aWV3ZXIgY2FuIHJhaXNlIG9iamVjdGlvbnMgb24gdGhlIGxpc3QgaWYgaGUgb3Igc2hlDQogICBz byBkZXNpcmVzLiAgVGhlIGltcG9ydGFudCB0aGluZyBpcyB0aGF0IHRoZSBvYmplY3Rpb24gbXVz dCBiZSBtYWRlDQogICBwdWJsaWNseS4NCg0KICAgVGhlIGFwcGxpY2FudCBpcyBmcmVlIHRvIG1v ZGlmeSBhIHJlamVjdGVkIGFwcGxpY2F0aW9uIHdpdGgNCiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gYW5kIHN1Ym1pdCBpdCBhZ2FpbjsgdGhpcyByZXN0YXJ0cyB0aGUgdHdvDQogICB3ZWVrIGNv bW1lbnQgcGVyaW9kLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3Zl bWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUN Cg0KDQogICBEZWNpc2lvbnMgbWFkZSBieSB0aGUgcmV2aWV3ZXIgbWF5IGJlIGFwcGVhbGVkIHRv IHRoZSBJRVNHIFtSRkMgMjAyOF0NCiAgIFs5XSB1bmRlciB0aGUgc2FtZSBydWxlcyBhcyBvdGhl ciBJRVRGIGRlY2lzaW9ucyBbUkZDIDIwMjZdIFs4XS4NCg0KICAgQWxsIGFwcHJvdmVkIHJlZ2lz dHJhdGlvbiBmb3JtcyBhcmUgYXZhaWxhYmxlIG9ubGluZSBpbiB0aGUgZGlyZWN0b3J5DQogICBo dHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbCB1bmRlciAibGFuZ3VhZ2VzIi4NCg0KICAg VXBkYXRlcyBvciBjaGFuZ2VzIHRvIGV4aXN0aW5nIHJlY29yZHMsIGluY2x1ZGluZyBwcmV2aW91 cw0KICAgcmVnaXN0cmF0aW9ucywgZm9sbG93IHRoZSBzYW1lIHByb2NlZHVyZSBhcyBuZXcgcmVn aXN0cmF0aW9ucy4gIFRoZQ0KICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGRlY2lkZXMgd2hl dGhlciB0aGVyZSBpcyBjb25zZW5zdXMgdG8gdXBkYXRlDQogICB0aGUgcmVnaXN0cmF0aW9uIGZv bGxvd2luZyB0aGUgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZDsgbm9ybWFsbHkNCiAgIG9iamVjdGlv bnMgYnkgdGhlIG9yaWdpbmFsIHJlZ2lzdHJhbnQgd2lsbCBjYXJyeSBleHRyYSB3ZWlnaHQgaW4N CiAgIGZvcm1pbmcgc3VjaCBhIGNvbnNlbnN1cy4NCg0KICAgUmVnaXN0cmF0aW9ucyBhcmUgcGVy bWFuZW50IGFuZCBzdGFibGUuICBPbmNlIHJlZ2lzdGVyZWQsIHN1YnRhZ3MNCiAgIHdpbGwgbm90 IGJlIHJlbW92ZWQgZnJvbSB0aGUgcmVnaXN0cnkgYW5kIHdpbGwgcmVtYWluIHRoZSBjYW5vbmlj YWwNCiAgIG1ldGhvZCBvZiByZWZlcnJpbmcgdG8gYSBzcGVjaWZpYyBsYW5ndWFnZSBvciB2YXJp YW50LiAgVGhpcw0KICAgcHJvdmlzaW9uIGRvZXMgbm90IGFwcGx5IHRvIGdyYW5kZmF0aGVyZWQg dGFncywgd2hpY2ggbWF5IGJlY29tZQ0KICAgZGVwcmVjYXRlZCBkdWUgdG8gcmVnaXN0cmF0aW9u IG9mIHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwgdGhlIHRhZw0KICAgImktbmF2YWpvIiBpcyBkZXBy ZWNhdGVkIGluIGZhdm9yIG9mIHRoZSB0YWcgIm52Iiwgd2hpY2ggY29uc2lzdHMgb2YNCiAgIHRo ZSBzaW5nbGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgJ252Jy4NCg0KICAgTm90ZTogVGhlIHB1 cnBvc2Ugb2YgdGhlICJwdWJsaXNoZWQgZGVzY3JpcHRpb24iIGluIHRoZSByZWdpc3RyYXRpb24N CiAgIGZvcm0gaXMgaW50ZW5kZWQgYXMgYW4gYWlkIHRvIHBlb3BsZSB0cnlpbmcgdG8gdmVyaWZ5 IHdoZXRoZXIgYQ0KICAgbGFuZ3VhZ2UgaXMgcmVnaXN0ZXJlZCBvciB3aGF0IGxhbmd1YWdlIG9y IGxhbmd1YWdlIHZhcmlhdGlvbiBhDQogICBwYXJ0aWN1bGFyIHN1YnRhZyByZWZlcnMgdG8uICBJ biBtb3N0IGNhc2VzLCByZWZlcmVuY2UgdG8gYW4NCiAgIGF1dGhvcml0YXRpdmUgZ3JhbW1hciBv ciBkaWN0aW9uYXJ5IG9mIHRoYXQgbGFuZ3VhZ2Ugd2lsbCBiZSB1c2VmdWw7DQogICBpbiBjYXNl cyB3aGVyZSBubyBzdWNoIHdvcmsgZXhpc3RzLCBvdGhlciB3ZWxsIGtub3duIHdvcmtzIGRlc2Ny aWJpbmcNCiAgIHRoYXQgbGFuZ3VhZ2Ugb3IgaW4gdGhhdCBsYW5ndWFnZSBtYXkgYmUgYXBwcm9w cmlhdGUuICBUaGUgc3VidGFnDQogICByZXZpZXdlciBkZWNpZGVzIHdoYXQgY29uc3RpdHV0ZXMg Imdvb2QgZW5vdWdoIiByZWZlcmVuY2UgbWF0ZXJpYWwuDQogICBUaGlzIHJlcXVpcmVtZW50IGlz IG5vdCBpbnRlbmRlZCB0byBleGNsdWRlIHBhcnRpY3VsYXIgbGFuZ3VhZ2VzIG9yDQogICBkaWFs ZWN0cyBkdWUgdG8gdGhlIHNpemUgb2YgdGhlIHNwZWFrZXIgcG9wdWxhdGlvbiBvciBsYWNrIG9m IGENCiAgIHN0YW5kYXJkaXplZCBvcnRob2dyYXBoeS4gIE1pbm9yaXR5IGxhbmd1YWdlcyB3aWxs IGJlIGNvbnNpZGVyZWQNCiAgIGVxdWFsbHkgb24gdGhlaXIgb3duIG1lcml0cy4NCg0KMy41ICBQ b3NzaWJpbGl0aWVzIGZvciBSZWdpc3RyYXRpb24NCg0KICAgUG9zc2liaWxpdGllcyBmb3IgcmVn aXN0cmF0aW9uIG9mIHN1YnRhZ3Mgb3IgaW5mb3JtYXRpb24gYWJvdXQNCiAgIHN1YnRhZ3MgaW5j bHVkZToNCg0KICAgbyAgUHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIGZvciBsYW5ndWFnZXMgbm90 IGxpc3RlZCBpbiBJU08gNjM5IHRoYXQNCiAgICAgIGFyZSBub3QgdmFyaWFudHMgb2YgYW55IGxp c3RlZCBvciByZWdpc3RlcmVkIGxhbmd1YWdlIGNhbiBiZQ0KICAgICAgcmVnaXN0ZXJlZC4gIEF0 IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQgdGhlcmUgd2VyZSBubw0KICAgICAg ZXhhbXBsZXMgb2YgdGhpcyBmb3JtIG9mIHN1YnRhZy4gIEJlZm9yZSBhdHRlbXB0aW5nIHRvIHJl Z2lzdGVyIGENCiAgICAgIGxhbmd1YWdlIHN1YnRhZywgdGhlcmUgTVVTVCBiZSBhbiBhdHRlbXB0 IHRvIHJlZ2lzdGVyIHRoZSBsYW5ndWFnZQ0KICAgICAgd2l0aCBJU08gNjM5LiAgTm8gbGFuZ3Vh Z2Ugc3VidGFncyB3aWxsIGJlIHJlZ2lzdGVyZWQgZm9yIGNvZGVzDQogICAgICB0aGF0IGV4aXN0 IGluIElTTyA2MzktMSBvciBJU08gNjM5LTIsIHdoaWNoIGFyZSB1bmRlcg0KICAgICAgY29uc2lk ZXJhdGlvbiBieSB0aGUgSVNPIDYzOSBtYWludGVuYW5jZSBvciByZWdpc3RyYXRpb24NCiAgICAg IGF1dGhvcml0aWVzLCBvciB3aGljaCBoYXZlIG5ldmVyIGJlZW4gYXR0ZW1wdGVkIGZvciByZWdp c3RyYXRpb24NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MjAsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDI5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0K ICAgICAgd2l0aCB0aG9zZSBhdXRob3JpdGllcy4gIElmIElTTyA2MzkgaGFzIHByZXZpb3VzbHkg cmVqZWN0ZWQgYQ0KICAgICAgbGFuZ3VhZ2UgZm9yIHJlZ2lzdHJhdGlvbiwgaXQgaXMgcmVhc29u YWJsZSB0byBhc3N1bWUgdGhhdCB0aGVyZQ0KICAgICAgTVVTVCBiZSBhZGRpdGlvbmFsIHZlcnkg Y29tcGVsbGluZyBldmlkZW5jZSBvZiBuZWVkIGJlZm9yZSBpdCB3aWxsDQogICAgICBiZSByZWdp c3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5ICh0byB0aGUgZXh0ZW50IHRoYXQgaXQgaXMgdmVy eQ0KICAgICAgdW5saWtlbHkgdGhhdCBhbnkgc3VidGFncyB3aWxsIGJlIHJlZ2lzdGVyZWQgb2Yg dGhpcyB0eXBlKS4NCg0KICAgbyAgRGlhbGVjdCBvciBvdGhlciBkaXZpc2lvbnMgb3IgdmFyaWF0 aW9ucyB3aXRoaW4gYSBsYW5ndWFnZSwgaXRzDQogICAgICBvcnRob2dyYXBoeSwgd3JpdGluZyBz eXN0ZW0sIHJlZ2lvbmFsIG9yIGhpc3RvcmljYWwgdXNhZ2UsDQogICAgICB0cmFuc2xpdGVyYXRp b24gb3Igb3RoZXIgdHJhbnNmb3JtYXRpb24sIG9yIGRpc3Rpbmd1aXNoaW5nDQogICAgICB2YXJp YXRpb24gbWF5IGJlIHJlZ2lzdGVyZWQgYXMgdmFyaWFudCBzdWJ0YWdzLiAgQW4gZXhhbXBsZSBp cyB0aGUNCiAgICAgICdzY291c2UnIHN1YnRhZyAodGhlIFNjb3VzZSBkaWFsZWN0IG9mIEVuZ2xp c2gpLg0KDQogICBvICBUaGUgYWRkaXRpb24gb3IgbWFpbnRlbmFuY2Ugb2YgZmllbGRzIChnZW5l cmFsbHkgb2YgYW4NCiAgICAgIGluZm9ybWF0aW9uYWwgbmF0dXJlKSBpbiBUYWcgb3IgU3VidGFn IHJlY29yZHMgYXMgZGVzY3JpYmVkIGluDQogICAgICBTZWN0aW9uIDMuMSBhbmQgc3ViamVjdCB0 byB0aGUgc3RhYmlsaXR5IHByb3Zpc2lvbnMgaW4NCiAgICAgIFNlY3Rpb24gMy4zLiAgVGhpcyBp bmNsdWRlcyBkZXNjcmlwdGlvbnMsIHJlY29tbWVuZGVkIHByZWZpeGVzLA0KICAgICAgY29tbWVu dHMsIGRlcHJlY2F0aW9uIG9mIG9ic29sZXRlIGl0ZW1zLCBvciB0aGUgYWRkaXRpb24gb2Ygc2Ny aXB0DQogICAgICBvciBleHRsYW5nIGluZm9ybWF0aW9uIHRvIHByaW1hcnkgbGFuZ3VhZ2Ugc3Vi dGFncy4NCg0KICAgVGhpcyBkb2N1bWVudCBsZWF2ZXMgdGhlIGRlY2lzaW9uIG9uIHdoYXQgc3Vi dGFncyAgb3IgY2hhbmdlcyB0bw0KICAgc3VidGFncyBhcmUgYXBwcm9wcmlhdGUgKG9yIG5vdCkg dG8gdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQu DQoNCiAgIE5vdGU6IGZvdXIgY2hhcmFjdGVyIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBhcmUg cmVzZXJ2ZWQgdG8gYWxsb3cNCiAgIGZvciB0aGUgcG9zc2liaWxpdHkgb2YgIGFscGhhNCBjb2Rl cyBpbiBzb21lIGZ1dHVyZSBhZGRpdGlvbiB0byB0aGUNCiAgIElTTyA2MzkgZmFtaWx5IG9mIHN0 YW5kYXJkcy4NCg0KICAgSVNPIDYzOSBkZWZpbmVzIGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBh ZGRpdGlvbnMgdG8gYW5kIGNoYW5nZXMgaW4NCiAgIHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBpbiBJ U08gNjM5LiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24g Q2VudHJlIGZvciBUZXJtaW5vbG9neSAoSW5mb3Rlcm0pDQogICBBaWNoaG9semdhc3NlIDYvMTIs IEFULTExMjANCiAgIFdpZW4sIEF1c3RyaWENCiAgIFBob25lOiArNDMgMSAyNiA3NSAzNSBFeHQu IDMxMiBGYXg6ICs0MyAxIDIxNiAzMiA3Mg0KDQogICBJU08gNjM5LTIgZGVmaW5lcyBhIG1haW50 ZW5hbmNlIGFnZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzDQogICBpbiB0aGUgbGlz dCBvZiBsYW5ndWFnZXMgaW4gSVNPIDYzOS0yLiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIExpYnJh cnkgb2YgQ29uZ3Jlc3MNCiAgIE5ldHdvcmsgRGV2ZWxvcG1lbnQgYW5kIE1BUkMgU3RhbmRhcmRz IE9mZmljZQ0KICAgV2FzaGluZ3RvbiwgRC5DLiAyMDU0MCBVU0ENCiAgIFBob25lOiArMSAyMDIg NzA3IDYyMzcgIEZheDogKzEgMjAyIDcwNyAwMTE1DQogICBVUkw6IGh0dHA6Ly93d3cubG9jLmdv di9zdGFuZGFyZHMvaXNvNjM5DQoNCiAgIFRoZSBtYWludGVuYW5jZSBhZ2VuY3kgZm9yIElTTyAz MTY2IChjb3VudHJ5IGNvZGVzKSBpczoNCg0KICAgSVNPIDMxNjYgTWFpbnRlbmFuY2UgQWdlbmN5 DQogICBjL28gSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAg ICAgICAgICAgICAgW1BhZ2UgMzBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQogICAgQ2FzZSBw b3N0YWxlIDU2DQogICBDSC0xMjExIEdlbmV2YSAyMCBTd2l0emVybGFuZA0KICAgUGhvbmU6ICs0 MSAyMiA3NDkgNzIgMzMgIEZheDogKzQxIDIyIDc0OSA3MyA0OQ0KICAgVVJMOiBodHRwOi8vd3d3 Lmlzby5vcmcvaXNvL2VuL3Byb2RzLXNlcnZpY2VzL2lzbzMxNjZtYS9pbmRleC5odG1sDQoNCiAg IFRoZSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IGZvciBJU08gMTU5MjQgKHNjcmlwdCBjb2Rlcykg aXM6DQoNCiAgIFVuaWNvZGUgQ29uc29ydGl1bSBCb3ggMzkxNDc2DQogICBNb3VudGFpbiBWaWV3 LCBDQSA5NDAzOS0xNDc2LCBVU0ENCiAgIFVSTDogaHR0cDovL3d3dy51bmljb2RlLm9yZy9pc28x NTkyNA0KDQogICBUaGUgU3RhdGlzdGljcyBEaXZpc2lvbiBvZiB0aGUgVW5pdGVkIE5hdGlvbnMg U2VjcmV0YXJpYXQgbWFpbnRhaW5zDQogICB0aGUgU3RhbmRhcmQgQ291bnRyeSBvciBBcmVhIENv ZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UgYW5kIGNhbiBiZQ0KICAgcmVhY2hlZCBhdDoNCg0KICAg U3RhdGlzdGljYWwgU2VydmljZXMgQnJhbmNoDQogICBTdGF0aXN0aWNzIERpdmlzaW9uDQogICBV bml0ZWQgTmF0aW9ucywgUm9vbSBEQzItMTYyMA0KICAgTmV3IFlvcmssIE5ZIDEwMDE3LCBVU0EN Cg0KICAgRmF4OiArMS0yMTItOTYzLTA2MjMNCiAgIEUtbWFpbDogc3RhdGlzdGljc0B1bi5vcmcN CiAgIFVSTDogaHR0cDovL3Vuc3RhdHMudW4ub3JnL3Vuc2QvbWV0aG9kcy9tNDkvbTQ5YWxwaGEu aHRtDQoNCjMuNiAgRXh0ZW5zaW9ucyBhbmQgRXh0ZW5zaW9ucyBOYW1lc3BhY2UNCg0KICAgRXh0 ZW5zaW9uIHN1YnRhZ3MgYXJlIHRob3NlIGludHJvZHVjZWQgYnkgc2luZ2xlLWxldHRlciBzdWJ0 YWdzIG90aGVyDQogICB0aGFuICd4Jy4gIFRoZXkgYXJlIHJlc2VydmVkIGZvciB0aGUgZ2VuZXJh dGlvbiBvZiBpZGVudGlmaWVycyB3aGljaA0KICAgY29udGFpbiBhIGxhbmd1YWdlIGNvbXBvbmVu dCwgYW5kIGFyZSBjb21wYXRpYmxlIHdpdGggYXBwbGljYXRpb25zDQogICB0aGF0IHVuZGVyc3Rh bmQgbGFuZ3VhZ2UgdGFncy4gIEZvciBleGFtcGxlLCB0aGV5IG1pZ2h0IGJlIHVzZWQgdG8NCiAg IGRlZmluZSBsb2NhbGUgaWRlbnRpZmllcnMsIHdoaWNoIGFyZSBnZW5lcmFsbHkgYmFzZWQgb24g bGFuZ3VhZ2UuDQoNCiAgIFRoZSBzdHJ1Y3R1cmUgYW5kIGZvcm0gb2YgZXh0ZW5zaW9ucyBhcmUg ZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IHNvDQogICB0aGF0IGltcGxlbWVudGF0aW9ucyBjYW4g YmUgY3JlYXRlZCB0aGF0IGFyZSBmb3J3YXJkIGNvbXBhdGlibGUgd2l0aA0KICAgYXBwbGljYXRp b25zIHRoYXQgbWF5IGJlIGNyZWF0ZWQgdXNpbmcgc2luZ2xlLWxldHRlciBzdWJ0YWdzIGluIHRo ZQ0KICAgZnV0dXJlLiAgSW4gYWRkaXRpb24sIGRlZmluaW5nIGEgbWVjaGFuaXNtIGZvciBtYWlu dGFpbmluZyBzaW5nbGUtDQogICBsZXR0ZXIgc3VidGFncyB3aWxsIGxlbmQgdG8gdGhlIHN0YWJp bGl0eSBvZiB0aGlzIGRvY3VtZW50IGJ5DQogICByZWR1Y2luZyB0aGUgbGlrZWx5IG5lZWQgZm9y IGZ1dHVyZSByZXZpc2lvbnMgb3IgdXBkYXRlcy4NCg0KICAgQWxsb2NhdGlvbiBvZiBhIHNpbmds ZS1sZXR0ZXIgc3VidGFnIHNoYWxsIHRha2UgdGhlIGZvcm0gb2YgYW4gUkZDDQogICBkZWZpbmlu ZyB0aGUgbmFtZSwgcHVycG9zZSwgcHJvY2Vzc2VzLCBhbmQgcHJvY2VkdXJlcyBmb3IgbWFpbnRh aW5pbmcNCiAgIHRoZSBzdWJ0YWdzLiAgVGhlIG1haW50YWluaW5nIG9yIHJlZ2lzdGVyaW5nIGF1 dGhvcml0eSwgaW5jbHVkaW5nDQogICBuYW1lLCBjb250YWN0IGVtYWlsLCBkaXNjdXNzaW9uIGxp c3QgZW1haWwsIGFuZCBVUkwgbG9jYXRpb24gb2YgdGhlDQogICByZWdpc3RyeSBtdXN0IGJlIGlu ZGljYXRlZCBjbGVhcmx5IGluIHRoZSBSRkMuICBUaGUgUkZDIE1VU1Qgc3BlY2lmeQ0KICAgb3Ig aW5jbHVkZSBlYWNoIG9mIHRoZSBmb2xsb3dpbmc6DQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9u IE1VU1QgcmVmZXJlbmNlIHRoZSBzcGVjaWZpYyB2ZXJzaW9uIG9yIHJldmlzaW9uDQogICAgICBv ZiB0aGlzIGRvY3VtZW50IHRoYXQgZ292ZXJucyBpdHMgY3JlYXRpb24gYW5kIE1VU1QgcmVmZXJl bmNlIHRoaXMNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MjAsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDMxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0K ICAgICAgc2VjdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlv biBhbmQgYWxsIHN1YnRhZ3MgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbg0KICAgICAgTVVT VCBmb2xsb3cgdGhlIEFCTkYgYW5kIG90aGVyIHJ1bGVzIGZvciB0aGUgZm9ybWF0aW9uIG9mIHRh Z3MgYW5kDQogICAgICBzdWJ0YWdzIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIEluIHBh cnRpY3VsYXIgaXQgTVVTVA0KICAgICAgc3BlY2lmeSB0aGF0IGNhc2UgaXMgbm90IHNpZ25pZmlj YW50IGFuZCB0aGF0IHN1YnRhZ3MgTVVTVCBOT1QNCiAgICAgIGV4Y2VlZCBlaWdodCBjaGFyYWN0 ZXJzIGluIGxlbmd0aC4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBzcGVjaWZ5IGEg Y2Fub25pY2FsIHJlcHJlc2VudGF0aW9uLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBvZiB2 YWxpZCBzdWJ0YWdzIE1VU1QgYmUgYXZhaWxhYmxlIG92ZXIgdGhlDQogICAgICBJbnRlcm5ldCBh bmQgYXQgbm8gY29zdC4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBiZSBpbiB0aGUg cHVibGljIGRvbWFpbiBvciBhdmFpbGFibGUgdmlhIGENCiAgICAgIHJveWFsdHktZnJlZSBsaWNl bnNlIGFjY2VwdGFibGUgdG8gdGhlIElFVEYgYW5kIHNwZWNpZmllZCBpbiB0aGUNCiAgICAgIFJG Qy4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBiZSB2ZXJzaW9uZWQgYW5kIGVhY2gg dmVyc2lvbiBvZiB0aGUNCiAgICAgIHNwZWNpZmljYXRpb24gTVVTVCBiZSBudW1iZXJlZCwgZGF0 ZWQsIGFuZCBzdGFibGUuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgc3RhYmxl LiAgVGhhdCBpcywgZXh0ZW5zaW9uIHN1YnRhZ3MsDQogICAgICBvbmNlIGRlZmluZWQgYnkgYSBz cGVjaWZpY2F0aW9uLCBNVVNUIE5PVCBiZSByZXRyYWN0ZWQgb3IgY2hhbmdlDQogICAgICBpbiBt ZWFuaW5nIGluIGFueSBzdWJzdGFudGlhbCB3YXkuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9u IE1VU1QgaW5jbHVkZSBpbiBhIHNlcGFyYXRlIHNlY3Rpb24gdGhlDQogICAgICByZWdpc3RyYXRp b24gZm9ybSByZXByb2R1Y2VkIGluIHRoaXMgc2VjdGlvbiAoYmVsb3cpIHRvIGJlIHVzZWQgaW4N CiAgICAgIHJlZ2lzdGVyaW5nIHRoZSBleHRlbnNpb24gdXBvbiBwdWJsaWNhdGlvbiBhcyBhbiBS RkMuDQoNCiAgIG8gIElBTkEgTVVTVCBiZSBpbmZvcm1lZCBvZiBjaGFuZ2VzIHRvIHRoZSBjb250 YWN0IGluZm9ybWF0aW9uIGFuZA0KICAgICAgVVJMIGZvciB0aGUgc3BlY2lmaWNhdGlvbi4NCg0K ICAgbyAgTW9kaWZpZWQgdGhlIGxhdGluLXNjcmlwdCByZXF1aXJlbWVudCBvbiB0aGUgJ0Rlc2Ny aXB0aW9uJyBmaWVsZA0KICAgICAgc28gdGhhdCAiYXQgbGVhc3Qgb25lIERlc2NyaXB0aW9uIGZp ZWxkIiBtdXN0IGNvbnRhaW4gYSBMYXRpbg0KICAgICAgdHJhbnNjcmlwdGlvbi4gIChBLlBoaWxs aXBzKQ0KDQogICBJQU5BIHdpbGwgbWFpbnRhaW4gYSByZWdpc3RyeSBvZiBhbGxvY2F0ZWQgc2lu Z2xlLWxldHRlciAoc2luZ2xldG9uKQ0KICAgc3VidGFncy4gIFRoaXMgcmVnaXN0cnkgd2lsbCB1 c2UgdGhlIHJlY29yZC1qYXIgZm9ybWF0IGRlc2NyaWJlZCBieQ0KICAgdGhlIEFCTkYgaW4gU2Vj dGlvbiAzLjEuICBVcG9uIHB1YmxpY2F0aW9uIG9mIGFuIGV4dGVuc2lvbiBhcyBhbiBSRkMsDQog ICB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGRlZmluZWQgaW4gdGhlIFJGQyBtdXN0IGZvcndh cmQgdGhpcw0KICAgcmVnaXN0cmF0aW9uIGZvcm0gdG8gaWVzZ0BpZXRmLm9yZywgd2hvIHdpbGwg Zm9yd2FyZCB0aGUgcmVxdWVzdCB0bw0KICAgaWFuYUBpYW5hLm9yZy4gIFRoZSBtYWludGFpbmlu ZyBhdXRob3JpdHkgb2YgdGhlIGV4dGVuc2lvbiBNVVNUDQogICBtYWludGFpbiB0aGUgYWNjdXJh Y3kgb2YgdGhlIHJlY29yZCBieSBzZW5kaW5nIGFuIHVwZGF0ZWQgZnVsbCBjb3B5DQogICBvZiB0 aGUgcmVjb3JkIHRvIGlhbmFAaWFuYS5vcmcgd2l0aCB0aGUgc3ViamVjdCBsaW5lICJMQU5HVUFH RSBUQUcNCiAgIEVYVEVOU0lPTiBVUERBVEUiIHdoZW5ldmVyIGNvbnRlbnQgY2hhbmdlcy4gIE9u bHkgdGhlICdDb21tZW50cycsDQogICAnQ29udGFjdF9FbWFpbCcsICdNYWlsaW5nX0xpc3QnLCBh bmQgJ1VSTCcgZmllbGRzIG1heSBiZSBtb2RpZmllZCBpbg0KICAgdGhlc2UgdXBkYXRlcy4NCg0K ICAgRmFpbHVyZSB0byBtYWludGFpbiB0aGlzIHJlY29yZCwgdGhlIGNvcnJlc3BvbmRpbmcgcmVn aXN0cnksIG9yIG1lZXQNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMjAsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDMyXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1 DQoNCg0KICAgb3RoZXIgY29uZGl0aW9ucyBpbXBvc2VkIGJ5IHRoaXMgc2VjdGlvbiBvZiB0aGlz IGRvY3VtZW50IG1heSBiZQ0KICAgYXBwZWFsZWQgdG8gdGhlIElFU0cgW1JGQyAyMDI4XSBbOV0g dW5kZXIgdGhlIHNhbWUgcnVsZXMgYXMgb3RoZXINCiAgIElFVEYgZGVjaXNpb25zIChzZWUgWzhd KSBhbmQgbWF5IHJlc3VsdCBpbiB0aGUgYXV0aG9yaXR5IHRvIG1haW50YWluDQogICB0aGUgZXh0 ZW5zaW9uIGJlaW5nIHdpdGhkcmF3biBvciByZWFzc2lnbmVkIGJ5IHRoZSBJRVNHLg0KICAgJSUN CiAgIElkZW50aWZpZXI6DQogICBEZXNjcmlwdGlvbjoNCiAgIENvbW1lbnRzOg0KICAgQWRkZWQ6 DQogICBSRkM6DQogICBBdXRob3JpdHk6DQogICBDb250YWN0X0VtYWlsOg0KICAgTWFpbGluZ19M aXN0Og0KICAgVVJMOg0KICAgJSUNCg0KICAgIEZpZ3VyZSA2OiBGb3JtYXQgb2YgUmVjb3JkcyBp biB0aGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgUmVnaXN0cnkNCg0KICAgJ0lkZW50aWZpZXIn IGNvbnRhaW5zIHRoZSBzaW5nbGUgbGV0dGVyIHN1YnRhZyAoc2luZ2xldG9uKSBhc3NpZ25lZA0K ICAgdG8gdGhlIGV4dGVuc2lvbi4gIFRoZSBJbnRlcm5ldC1EcmFmdCBzdWJtaXR0ZWQgdG8gZGVm aW5lIHRoZQ0KICAgZXh0ZW5zaW9uIHNob3VsZCBzcGVjaWZpYyB3aGljaCBsZXR0ZXIgdG8gdXNl LCBhbHRob3VnaCB0aGUgSUVTRyBtYXkNCiAgIGNoYW5nZSB0aGUgYXNzaWdubWVudCB3aGVuIGFw cHJvdmluZyB0aGUgUkZDLg0KDQogICAnRGVzY3JpcHRpb24nIGNvbnRhaW5zIHRoZSBuYW1lIGFu ZCBkZXNjcmlwdGlvbiBvZiB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQ29tbWVudHMnIGlzIGFuIG9w dGlvbmFsIGZpZWxkIGFuZCBtYXkgY29udGFpbiBhIGJyb2FkZXIgZGVzY3JpcHRpb24NCiAgIG9m IHRoZSBleHRlbnNpb24uDQoNCiAgICdBZGRlZCcgY29udGFpbnMgdGhlIGRhdGUgdGhlIFJGQyB3 YXMgcHVibGlzaGVkIGluIHRoZSAiZnVsbC1kYXRlIg0KICAgZm9ybWF0IHNwZWNpZmllZCBpbiBS RkMgMzMzOSBbMTRdLiAgRm9yIGV4YW1wbGU6IDIwMDQtMDYtMjgNCiAgIHJlcHJlc2VudHMgSnVu ZSAyOCwgMjAwNCwgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhci4NCg0KICAgJ1JGQycgY29udGFp bnMgdGhlIFJGQyBudW1iZXIgYXNzaWduZWQgdG8gdGhlIGV4dGVuc2lvbi4NCg0KICAgJ0F1dGhv cml0eScgY29udGFpbnMgdGhlIG5hbWUgb2YgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBmb3Ig dGhlDQogICBleHRlbnNpb24uDQoNCiAgICdDb250YWN0X0VtYWlsJyBjb250YWlucyB0aGUgZW1h aWwgYWRkcmVzcyB1c2VkIHRvIGNvbnRhY3QgdGhlDQogICBtYWludGFpbmluZyBhdXRob3JpdHku DQoNCiAgICdNYWlsaW5nX0xpc3QnIGNvbnRhaW5zIHRoZSBVUkwgb3Igc3Vic2NyaXB0aW9uIGVt YWlsIGFkZHJlc3Mgb2YgdGhlDQogICBtYWlsaW5nIGxpc3QgdXNlZCBieSB0aGUgbWFpbnRhaW5p bmcgYXV0aG9yaXR5Lg0KDQogICAnVVJMJyBjb250YWlucyB0aGUgVVJMIG9mIHRoZSByZWdpc3Ry eSBmb3IgdGhpcyBleHRlbnNpb24uDQoNCiAgIFRoZSBkZXRlcm1pbmF0aW9uIG9mIHdoZXRoZXIg YW4gSW50ZXJuZXQtRHJhZnQgbWVldHMgdGhlIGFib3ZlDQogICBjb25kaXRpb25zIGFuZCB0aGUg ZGVjaXNpb24gdG8gZ3JhbnQgb3Igd2l0aGhvbGQgc3VjaCBhdXRob3JpdHkgcmVzdHMNCiAgIHNv bGVseSB3aXRoIHRoZSBJRVNHLCBhbmQgaXMgc3ViamVjdCB0byB0aGUgbm9ybWFsIHJldmlldyBh bmQgYXBwZWFscw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJl ciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMzNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0K DQogICBwcm9jZXNzIGFzc29jaWF0ZWQgd2l0aCB0aGUgUkZDIHByb2Nlc3MuDQoNCiAgIEV4dGVu c2lvbiBhdXRob3JzIGFyZSBzdHJvbmdseSBjYXV0aW9uZWQgdGhhdCBtYW55IChpbmNsdWRpbmcg bW9zdA0KICAgd2VsbC1mb3JtZWQpIHByb2Nlc3NvcnMgd2lsbCBiZSB1bmF3YXJlIG9mIGFueSBz cGVjaWFsIHJlbGF0aW9uc2hpcHMNCiAgIG9yIG1lYW5pbmcgaW5oZXJlbnQgaW4gdGhlIG9yZGVy IG9mIGV4dGVuc2lvbiBzdWJ0YWdzLiAgRXh0ZW5zaW9uDQogICBhdXRob3JzIFNIT1VMRCBhdm9p ZCBzdWJ0YWcgcmVsYXRpb25zaGlwcyBvciBjYW5vbmljYWxpemF0aW9uDQogICBtZWNoYW5pc21z IHRoYXQgaW50ZXJmZXJlIHdpdGggbWF0Y2hpbmcgb3Igd2l0aCBsZW5ndGggcmVzdHJpY3Rpb25z DQogICB0aGF0IG1heSBleGlzdCBpbiBjb21tb24gcHJvdG9jb2xzIHdoZXJlIHRoZSBleHRlbnNp b24gaXMgdXNlZC4gIEluDQogICBwYXJ0aWN1bGFyLCBhcHBsaWNhdGlvbnMgbWF5IHRydW5jYXRl IHRoZSBzdWJ0YWdzIGluIGRvaW5nIG1hdGNoaW5nDQogICBvciBpbiBmaXR0aW5nIGludG8gbGlt aXRlZCBsZW5ndGhzLCBzbyBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZQ0KICAgbW9zdCBzaWdu aWZpY2FudCBpbmZvcm1hdGlvbiBiZSBpbiB0aGUgbW9zdCBzaWduaWZpY2FudCAobGVmdC1tb3N0 KQ0KICAgc3VidGFncywgYW5kIHRoYXQgdGhlIHNwZWNpZmljYXRpb24gZ3JhY2VmdWxseSBoYW5k bGUgdHJ1bmNhdGVkDQogICBzdWJ0YWdzLg0KDQogICBXaGVuIGEgbGFuZ3VhZ2UgdGFnIGlzIHRv IGJlIHVzZWQgaW4gYSBzcGVjaWZpYywga25vd24sIHByb3RvY29sLCBpdA0KICAgaXMgUkVDT01N RU5ERUQgdGhhdCB0aGF0IHRoZSBsYW5ndWFnZSB0YWcgbm90IGNvbnRhaW4gZXh0ZW5zaW9ucyBu b3QNCiAgIHN1cHBvcnRlZCBieSB0aGF0IHByb3RvY29sLiAgSW4gYWRkaXRpb24sIGl0IHNob3Vs ZCBiZSBub3RlZCB0aGF0DQogICBzb21lIHByb3RvY29scyBtYXkgaW1wb3NlIHVwcGVyIGxpbWl0 cyBvbiB0aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmdzDQogICB1c2VkIHRvIHN0b3JlIG9yIHRyYW5z cG9ydCB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQozLjcgIENvbnZlcnNpb24gb2YgdGhlIFJGQyAzMDY2 IExhbmd1YWdlIFRhZyBSZWdpc3RyeQ0KDQogICBVcG9uIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQgYXMgYSBCQ1AsIHRoZSBleGlzdGluZyBJQU5BDQogICBsYW5ndWFnZSB0YWcgcmVnaXN0 cnkgbXVzdCBiZSBjb252ZXJ0ZWQgaW50byB0aGUgbmV3IHN1YnRhZyByZWdpc3RyeS4NCiAgIFRo aXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBwcm9jZXNzIGZvciBwZXJmb3JtaW5nIHRoaXMgY29udmVy c2lvbi4NCg0KICAgVGhlIGltcGFjdCBvbiB0aGUgSUFOQSBtYWludGFpbmVycyBvZiB0aGUgcmVn aXN0cnkgb2YgdGhpcyBjb252ZXJzaW9uDQogICB3aWxsIGJlIGEgc21hbGwgaW5jcmVhc2UgaW4g dGhlIGZyZXF1ZW5jeSBvZiBuZXcgZW50cmllcy4gIFRoZQ0KICAgaW5pdGlhbCBzZXQgb2YgcmVj b3JkcyByZXByZXNlbnRzIG5vIGltcGFjdCBvbiBJQU5BLCBzaW5jZSB0aGUgd29yaw0KICAgdG8g Y3JlYXRlIGl0IHdpbGwgYmUgcGVyZm9ybWVkIGV4dGVybmFsbHkgKGFzIGRlZmluZWQgaW4gdGhp cw0KICAgc2VjdGlvbikuICBGdXR1cmUgd29yayB3aWxsIGJlIGxpbWl0ZWQgdG8gaW5zZXJ0aW5n IG9yIHJlcGxhY2luZw0KICAgd2hvbGUgcmVjb3JkcyBwcmVmb3JtYXR0ZWQgZm9yIElBTkEgYnkg dGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlci4NCg0KICAgV2hlbiB0aGlzIGRvY3VtZW50IGlz IHB1Ymxpc2hlZCwgYW4gZW1haWwgd2lsbCBiZSBzZW50IGJ5IHRoZQ0KICAgY2hhaXIocykgb2Yg dGhlIExUUlUgd29ya2luZyBncm91cCB0byB0aGUgTFRSVSBhbmQgaWV0Zi1sYW5ndWFnZXMNCiAg IG1haWwgbGlzdHMgYWR2aXNpbmcgb2YgdGhlIGltcGVuZGluZyBjb252ZXJzaW9uIG9mIHRoZSBy ZWdpc3RyeS4gIEluDQogICB0aGF0IG5vdGljZSwgdGhlIGNoYWlyKHMpIHdpbGwgcHJvdmlkZSBh IFVSTCB3aG9zZSByZWZlcnJlZCBjb250ZW50DQogICBpcyB0aGUgcHJvcG9zZWQgSUFOQSBMYW5n dWFnZSBTdWJ0YWcgUmVnaXN0cnkgZm9sbG93aW5nIGNvbnZlcnNpb24uDQogICBUaGVyZSB3aWxs IGJlIGEgTGFzdCBDYWxsIHBlcmlvZCBvZiBub3QgbGVzcyB0aGFuIGZvdXIgd2Vla3MgZm9yDQog ICBjb21tZW50cyBhbmQgY29ycmVjdGlvbnMgdG8gYmUgZGlzY3Vzc2VkIG9uIHRoZQ0KICAgaWV0 Zi1sYW5ndWFnZXNAaWFuYS5vcmcgbWFpbCBsaXN0LiAgQ2hhbmdlcyBhcyBhIHJlc3VsdCBvZiBj b21tZW50cw0KICAgd2lsbCBub3QgcmVzdGFydCB0aGUgTGFzdCBDYWxsIHBlcmlvZC4gIEF0IHRo ZSBlbmQgb2YgdGhlIHBlcmlvZCwgdGhlDQogICBjaGFpcihzKSB3aWxsIGZvcndhcmQgdGhlIFVS TCB0byBJQU5BLCB3aGljaCB3aWxsIHBvc3QgdGhlIG5ldw0KICAgcmVnaXN0cnkgb24tbGluZS4N Cg0KICAgVGFncyB0aGF0IGFyZSBjdXJyZW50bHkgZGVwcmVjYXRlZCB3aWxsIGJlIG1haW50YWlu ZWQgYXMNCiAgIGdyYW5kZmF0aGVyZWQgZW50cmllcy4gIFRoZSByZWNvcmQgZm9yIHRoZSBncmFu ZGZhdGhlcmVkIGVudHJ5IHdpbGwNCiAgIGNvbnRhaW4gYSAnRGVwcmVjYXRlZCcgZmllbGQgd2l0 aCB0aGUgbW9zdCBhcHByb3ByaWF0ZSBkYXRlIHRoYXQgY2FuDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAz NF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgIGJlIGRldGVybWluZWQgZm9yIHdoZW4gdGhl IHJlY29yZCB3YXMgZGVwcmVjYXRlZC4gIFRoZSAnQ29tbWVudHMnDQogICBmaWVsZCB3aWxsIGNv bnRhaW4gdGhlIHJlYXNvbiBmb3IgdGhlIGRlcHJlY2F0aW9uLiAgVGhlICdDYW5vbmljYWwnDQog ICBmaWVsZCB3aWxsIGNvbnRhaW4gdGhlIHRhZyB0aGF0IHJlcGxhY2VzIHRoZSB2YWx1ZS4gIEZv ciBleGFtcGxlLCB0aGUNCiAgIHRhZyAiYXJ0LWxvamJhbiIgaXMgZGVwcmVjYXRlZCBhbmQgd2ls bCBiZSBwbGFjZWQgaW4gdGhlDQogICBncmFuZGZhdGhlcmVkIHNlY3Rpb24uICBJdCdzICdEZXBy ZWNhdGVkJyBmaWVsZCB3aWxsIGNvbnRhaW4gdGhlDQogICBkZXByZWNhdGlvbiBkYXRlIGFuZCAn Q2Fub25pY2FsJyBmaWVsZCB0aGUgdmFsdWUgImpibyIuDQoNCiAgIFRhZ3MgdGhhdCBhcmUgbm90 IGRlcHJlY2F0ZWQgdGhhdCBjb25zaXN0IGVudGlyZWx5IG9mIHN1YnRhZ3MgdGhhdA0KICAgYXJl IHZhbGlkIHVuZGVyIHRoaXMgZG9jdW1lbnQgYW5kIHdoaWNoIGhhdmUgdGhlIGNvcnJlY3QgZm9y bSBhbmQNCiAgIGZvcm1hdCBmb3IgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgYXJlIHN1 cGVyc2VkZWQgYnkgdGhpcw0KICAgZG9jdW1lbnQuICBTdWNoIHRhZ3MgYXJlIHBsYWNlZCBpbiBy ZWNvcmRzIG9mIHR5cGUgJ3JlZHVuZGFudCcgaW4gdGhlDQogICByZWdpc3RyeS4gIEZvciBleGFt cGxlLCAiemgtSGFudCIgaXMgbm93IGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudC4NCg0KICAgVGFn cyB0aGF0IGFyZSBub3QgZGVwcmVjYXRlZCBhbmQgd2hpY2ggY29udGFpbiBzdWJ0YWdzIHdoaWNo IGFyZQ0KICAgY29uc2lzdGVudCB3aXRoIHJlZ2lzdHJhdGlvbiB1bmRlciB0aGUgZ3VpZGVsaW5l cyBpbiB0aGlzIGRvY3VtZW50DQogICB3aWxsIGhhdmUgYSBuZXcgc3VidGFnIHJlZ2lzdHJhdGlv biBjcmVhdGVkIGZvciBlYWNoIGVsaWdpYmxlIHN1YnRhZy4NCiAgIElmIGFsbCBvZiB0aGUgc3Vi dGFncyBpbiB0aGUgb3JpZ2luYWwgdGFnIGFyZSBmdWxseSBkZWZpbmVkIGJ5IHRoZQ0KICAgcmVz dWx0aW5nIHJlZ2lzdHJhdGlvbnMgb3IgYnkgdGhpcyBkb2N1bWVudCwgdGhlbiB0aGUgb3JpZ2lu YWwgdGFnIGlzDQogICBzdXBlcnNlZGVkIGJ5IHRoaXMgZG9jdW1lbnQuICBTdWNoIHRhZ3MgYXJl IHBsYWNlZCBpbiB0aGUgJ3JlZHVuZGFudCcNCiAgIHNlY3Rpb24gb2YgdGhlIHJlZ2lzdHJ5LiAg Rm9yIGV4YW1wbGUsICJlbi1ib29udCIgd2lsbCByZXN1bHQgaW4gYQ0KICAgbmV3IHN1YnRhZyAn Ym9vbnQnIGFuZCB0aGUgUkZDIDMwNjYgcmVnaXN0ZXJlZCB0YWcgImVuLWJvb250IiBwbGFjZWQN CiAgIGluIHRoZSByZWR1bmRhbnQgc2VjdGlvbiBvZiB0aGUgcmVnaXN0cnkuDQoNCiAgIFRhZ3Mg dGhhdCBjb250YWluIG9uZSBvciBtb3JlIHN1YnRhZ3MgdGhhdCBkbyBub3QgbWF0Y2ggdGhlIHZh bGlkDQogICByZWdpc3RyYXRpb24gcGF0dGVybiBhbmQgd2hpY2ggYXJlIG5vdCBvdGhlcndpc2Ug ZGVmaW5lZCBieSB0aGlzDQogICBkb2N1bWVudCB3aWxsIGhhdmUgcmVjb3JkcyBvZiB0eXBlICAn Z3JhbmRmYXRoZXJlZCcgY3JlYXRlZCBpbiB0aGUNCiAgIHJlZ2lzdHJ5Lg0KDQogICBUaGVyZSB3 aWxsIGJlIGEgcmVhc29uYWJsZSBwZXJpb2QgaW4gd2hpY2ggdGhlIGNvbW11bml0eSBtYXkgY29t bWVudA0KICAgb24gdGhlIHByb3Bvc2VkIGxpc3QgZW50cmllcywgd2hpY2ggU0hBTEwgYmUgbm8g bGVzcyB0aGFuIGZvdXIgd2Vla3MNCiAgIGluIGxlbmd0aC4gIEF0IHRoZSBjb21wbGV0aW9uIG9m IHRoaXMgcGVyaW9kLCB0aGUgY2hhaXIocykgd2lsbA0KICAgbm90aWZ5IGlhbmFAaWFuYS5vcmcg YW5kIHRoZSBsdHJ1IGFuZCBpZXRmLWxhbmd1YWdlcyBtYWlsIGxpc3RzIHRoYXQNCiAgIHRoZSB0 YXNrIGlzIGNvbXBsZXRlIGFuZCBmb3J3YXJkIHRoZSBuZWNlc3NhcnkgbWF0ZXJpYWxzIHRvIElB TkEgZm9yDQogICBwdWJsaWNhdGlvbi4NCg0KICAgUmVnaXN0cmF0aW9ucyB0aGF0IGFyZSBpbiBw cm9jZXNzIHVuZGVyIHRoZSBydWxlcyBkZWZpbmVkIGluIFJGQyAzMDY2DQogICBNQVkgYmUgY29t cGxldGVkIHVuZGVyIHRoZSBmb3JtZXIgcnVsZXMsIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZQ0K ICAgbGFuZ3VhZ2UgdGFnIHJldmlld2VyLiAgQW55IG5ldyByZWdpc3RyYXRpb25zIHN1Ym1pdHRl ZCBhZnRlciB0aGUNCiAgIHJlcXVlc3QgZm9yIGNvbnZlcnNpb24gb2YgdGhlIHJlZ2lzdHJ5IE1V U1QgYmUgcmVqZWN0ZWQuDQoNCiAgIEFsbCBleGlzdGluZyBSRkMgMzA2NiBsYW5ndWFnZSB0YWcg cmVnaXN0cmF0aW9ucyB3aWxsIGJlIG1haW50YWluZWQNCiAgIGluIHBlcnBldHVpdHkuDQoNCiAg IFVzZXJzIG9mIHRhZ3MgdGhhdCBhcmUgZ3JhbmRmYXRoZXJlZCBzaG91bGQgY29uc2lkZXIgcmVn aXN0ZXJpbmcNCiAgIGFwcHJvcHJpYXRlIHN1YnRhZ3MgaW4gdGhlIElBTkEgc3VidGFnIHJlZ2lz dHJ5IChidXQgYXJlIG5vdCByZXF1aXJlZA0KICAgdG8pLg0KDQogICBXaGVyZSB0d28gc3VidGFn cyBoYXZlIHRoZSBzYW1lIG1lYW5pbmcsIHRoZSBwcmlvcml0eSBvZiB3aGljaCB0bw0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAg ICAgICAgW1BhZ2UgMzVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQogICBtYWtlIGNhbm9uaWNh bCBTSEFMTCBiZSB0aGUgZm9sbG93aW5nOg0KDQogICBvICBBcyBvZiB0aGUgZGF0ZSBvZiBhY2Nl cHRhbmNlIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBCQ1AsIGlmIGEgY29kZQ0KICAgICAgZXhpc3Rz IGluIHRoZSBhc3NvY2lhdGVkIElTTyBzdGFuZGFyZCBhbmQgaXQgaXMgbm90IGRlcHJlY2F0ZWQg b3INCiAgICAgIHdpdGhkcmF3biBhcyBvZiB0aGF0IGRhdGUsIHRoZW4gaXQgaGFzIHByaW9yaXR5 Lg0KDQogICBvICBPdGhlcndpc2UsIHRoZSBlYXJsaWVyLXJlZ2lzdGVyZWQgdGFnIGluIHRoZSBh c3NvY2lhdGVkIElTTw0KICAgICAgc3RhbmRhcmQgaGFzIHByaW9yaXR5Lg0KDQogICBVTiBudW1l cmljIGNvZGVzIGFzc2lnbmVkIHRvICdtYWNyby1nZW9ncmFwaGljYWwgKGNvbnRpbmVudGFsKScg b3INCiAgIHN1Yi1yZWdpb25zIG5vdCBhc3NvY2lhdGVkIHdpdGggYW4gYXNzaWduZWQgSVNPIDMx NjYgYWxwaGEtMiBjb2RlIGFyZQ0KICAgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhbmQg YXJlIHZhbGlkIGZvciB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4NCiAgIFRoZXNlIGNvZGVzIE1VU1Qg YmUgYWRkZWQgdG8gdGhlIGluaXRpYWwgdmVyc2lvbiBvZiB0aGUgcmVnaXN0cnkuDQogICBUaGUg VU4gbnVtZXJpYyBjb2RlcyBmb3IgJ2Vjb25vbWljIGdyb3VwaW5ncycgb3IgJ290aGVyIGdyb3Vw aW5ncycsDQogICBhbmQgdGhlIGFscGhhbnVtZXJpYyBjb2RlcyBpbiBBcHBlbmRpeCBYIG9mIHRo ZSBVTiBkb2N1bWVudCBNVVNUIE5PVA0KICAgYmUgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5Lg0KDQog ICBXaGVuIGNyZWF0aW5nIHJlY29yZHMgZm9yIElTTyA2MzksIElTTyAxNTkyNCwgSVNPMzE2Niwg YW5kIFVOIE0uNDkNCiAgIGNvZGVzLCB0aGUgZm9sbG93aW5nIGNyaXRlcmlhIFNIQUxMIGJlIGFw cGxpZWQgdG8gdGhlIGluY2x1c2lvbiwNCiAgIGNhbm9uaWNhbCBtYXBwaW5nLCBhbmQgZGVwcmVj YXRpb24gb2YgY29kZXM6DQoNCiAgIEZvciBlYWNoIHN0YW5kYXJkLCB0aGUgZGF0ZSBvZiB0aGUg c3RhbmRhcmQgcmVmZXJlbmNlZCBpbiBSRkMgMTc2NiBpcw0KICAgc2VsZWN0ZWQgYXMgdGhlIHN0 YXJ0aW5nIGRhdGUuICBDb2RlcyB0aGF0IHdlcmUgdmFsaWQgb24gdGhhdCBkYXRlIGluDQogICB0 aGUgc2VsZWN0ZWQgc3RhbmRhcmQgYXJlIGFkZGVkIHRvIHRoZSByZWdpc3RyeS4gIENvZGVzIHRo YXQgd2VyZQ0KICAgcHJldmlvdXNseSBhc3NpZ25lZCBieSB3ZXJlIHZhY2F0ZWQgb3Igd2l0aGRy YXduIGJlZm9yZSB0aGF0IGRhdGUgYXJlDQogICBub3QgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5LiAg Rm9yIGVhY2ggc3VjY2Vzc2l2ZSBjaGFuZ2UgdG8gdGhlDQogICBzdGFuZGFyZCwgYW55IGFkZGl0 aW9uYWwgYXNzaWdubWVudHMgYXJlIGFkZGVkIHRvIHRoZSByZWdpc3RyeS4NCiAgIFZhbHVlcyB0 aGF0IGFyZSB3aXRoZHJhd24gYXJlIG1hcmtlZCBhcyBkZXByZWNhdGVkLCBidXQgbm90IHJlbW92 ZWQuDQogICBDaGFuZ2VzIGluIG1lYW5pbmcgb3IgYXNzaWdubWVudCBvZiBhIHN1YnRhZyBhcmUg cGVybWl0dGVkIGR1cmluZw0KICAgdGhpcyBwcm9jZXNzIChjZi4gJ0NTJykuICBUaGlzIGNvbnRp bnVlcyB1cCB0byB0aGUgZGF0ZSB0aGF0IHRoaXMNCiAgIGRvY3VtZW50IHdhcyBhZG9wdGVkLiAg VGhlIHJlc3VsdGluZyBzZXQgb2YgcmVjb3JkcyBpcyBhZGRlZCB0byB0aGUNCiAgIHJlZ2lzdHJ5 LiAgRnV0dXJlIGNoYW5nZXMgb3IgYWRkaXRpb25zIHRvIHRoaXMgcG9ydGlvbiBvZiB0aGUNCiAg IHJlZ2lzdHJ5IGFyZSBnb3Zlcm5lZCBieSB0aGUgcHJvdmlzaW9ucyBvZiB0aGlzIGRvY3VtZW50 Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMzZdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgICAgTWF5IDIwMDUNCg0KDQo0LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNzaW5nIG9mIExh bmd1YWdlIFRhZ3MNCg0KICAgVGhpcyBzZWN0aW9uIGFkZHJlc3NlcyBob3cgdG8gdXNlIHRoZSBy ZWdpc3RyeSB3aXRoIHRoZSBsYW5ndWFnZSB0YWcNCiAgIGZvcm1hdCB0byBjaG9vc2UsIGZvcm0g YW5kIHByb2Nlc3MgbGFuZ3VhZ2UgdGFncy4NCg0KNC4xICBDaG9pY2Ugb2YgTGFuZ3VhZ2UgVGFn DQoNCiAgIE9uZSBtYXkgb2NjYXNpb25hbGx5IGJlIGZhY2VkIHdpdGggc2V2ZXJhbCBwb3NzaWJs ZSB0YWdzIGZvciB0aGUgc2FtZQ0KICAgYm9keSBvZiB0ZXh0Lg0KDQogICBJbnRlcm9wZXJhYmls aXR5IGlzIGJlc3Qgc2VydmVkIHdoZW4gYWxsIHVzZXJzIHVzZSB0aGUgc2FtZSBsYW5ndWFnZQ0K ICAgdGFnIGluIG9yZGVyIHRvIHJlcHJlc2VudCB0aGUgc2FtZSBsYW5ndWFnZS4gIElmIGFuIGFw cGxpY2F0aW9uIGhhcw0KICAgcmVxdWlyZW1lbnRzIHRoYXQgbWFrZSB0aGUgcnVsZXMgaGVyZSBp bmFwcGxpY2FibGUsIHRoZW4gdGhhdA0KICAgYXBwbGljYXRpb24gcmlza3MgZGFtYWdpbmcgaW50 ZXJvcGVyYWJpbGl0eS4gIEl0IGlzIHN0cm9uZ2x5DQogICBSRUNPTU1FTkRFRCB0aGF0IHVzZXJz IG5vdCBkZWZpbmUgdGhlaXIgb3duIHJ1bGVzIGZvciBsYW5ndWFnZSB0YWcNCiAgIGNob2ljZS4N Cg0KICAgT2YgcGFydGljdWxhciBub3RlLCBtYW55IGFwcGxpY2F0aW9ucyBjYW4gYmVuZWZpdCBm cm9tIHRoZSB1c2Ugb2YNCiAgIHNjcmlwdCBzdWJ0YWdzIGluIGxhbmd1YWdlIHRhZ3MsIGFzIGxv bmcgYXMgdGhlIHVzZSBpcyBjb25zaXN0ZW50IGZvcg0KICAgYSBnaXZlbiBjb250ZXh0LiAgU2Ny aXB0IHN1YnRhZ3Mgd2VyZSBub3QgZm9ybWFsbHkgZGVmaW5lZCBpbiBSRkMNCiAgIDMwNjYgYW5k IHRoZWlyIHVzZSBtYXkgYWZmZWN0IG1hdGNoaW5nIGFuZCBzdWJ0YWcgaWRlbnRpZmljYXRpb24g YnkNCiAgIGltcGxlbWVudGF0aW9ucyBvZiBSRkMgMzA2NiwgYXMgdGhlc2Ugc3VidGFncyBhcHBl YXIgYmV0d2VlbiB0aGUNCiAgIHByaW1hcnkgbGFuZ3VhZ2UgYW5kIHJlZ2lvbiBzdWJ0YWdzLiAg Rm9yIGV4YW1wbGUsIGlmIGEgdXNlciByZXF1ZXN0cw0KICAgY29udGVudCBpbiBhbiBpbXBsZW1l bnRhdGlvbiBvZiBTZWN0aW9uIDIuNSBvZiBSRkMgMzA2NiBbMjNdIHVzaW5nDQogICB0aGUgbGFu Z3VhZ2UgcmFuZ2UgImVuLVVTIiwgY29udGVudCBsYWJlbGVkICJlbi1MYXRuLVVTIiB3aWxsIG5v dA0KICAgbWF0Y2ggdGhlIHJlcXVlc3QuICBUaGVyZWZvcmUgaXQgaXMgaW1wb3J0YW50IHRvIGtu b3cgd2hlbiBzY3JpcHQNCiAgIHN1YnRhZ3Mgd2lsbCBjdXN0b21hcmlseSBiZSB1c2VkIGFuZCB3 aGVuIHRoZXkgc2hvdWxkIG5vdCBiZSB1c2VkLg0KICAgSW4gdGhlIHJlZ2lzdHJ5LCB0aGUgU3Vw cHJlc3MtU2NyaXB0IGZpZWxkIGhlbHBzIGVuc3VyZSBncmVhdGVyDQogICBjb21wYXRpYmlsaXR5 IGJldHdlZW4gdGhlIGxhbmd1YWdlIHRhZ3MgZ2VuZXJhdGVkIGFjY29yZGluZyB0byB0aGUNCiAg IHJ1bGVzIGluIHRoaXMgZG9jdW1lbnQgYW5kIGxhbmd1YWdlIHRhZ3MgYW5kIHRhZyBwcm9jZXNz b3JzIG9yDQogICBjb25zdW1lcnMgYmFzZWQgb24gUkZDIDMwNjYgYnkgZGVmaW5pbmcgd2hlbiB1 c2VycyBzaG91bGQgZ2VuZXJhbGx5DQogICBub3QgaW5jbHVkZSBhIHNjcmlwdCBzdWJ0YWcgd2l0 aCBhIHBhcnRpY3VsYXIgcHJpbWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnLg0KDQogICBFeHRlbmRl ZCBsYW5ndWFnZSBzdWJ0YWdzICh0eXBlICdleHRsYW5nJyBpbiB0aGUgcmVnaXN0cnksIHNlZQ0K ICAgU2VjdGlvbiAzLjEpIGFsc28gYXBwZWFyIGJldHdlZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ug YW5kIHJlZ2lvbg0KICAgc3VidGFncyBhbmQgYXJlIHJlc2VydmVkIGZvciBmdXR1cmUgc3RhbmRh cmRpemF0aW9uLiAgQXBwbGljYXRpb25zDQogICBtYXkgYmVuZWZpdCBmcm9tIHRoZWlyIGp1ZGlj aW91cyB1c2UgaW4gZm9ybWluZyBsYW5ndWFnZSB0YWdzIGluIHRoZQ0KICAgZnV0dXJlIGFuZCBz aW1pbGFyIHJlY29tbWVuZGF0aW9ucyBhcmUgZXhwZWN0ZWQgdG8gYXBwbHkgdG8gdGhlaXIgdXNl DQogICBhcyBhcHBseSB0byBzY3JpcHQgc3VidGFncy4NCg0KICAgU3RhbmRhcmRzLCBwcm90b2Nv bHMgYW5kIGFwcGxpY2F0aW9ucyB0aGF0IHJlZmVyZW5jZSB0aGlzIGRvY3VtZW50DQogICBub3Jt YXRpdmVseSBidXQgYXBwbHkgZGlmZmVyZW50IHJ1bGVzIHRvIHRoZSBvbmVzIGdpdmVuIGluIHRo aXMNCiAgIHNlY3Rpb24gTVVTVCBzcGVjaWZ5IGhvdyB0aGUgcHJvY2VkdXJlIHZhcmllcyBmcm9t IHRoZSBvbmUgZ2l2ZW4NCiAgIGhlcmUuDQoNCiAgIFRoZSBjaG9pY2Ugb2Ygc3VidGFncyB1c2Vk IHRvIGZvcm0gYSBsYW5ndWFnZSB0YWcgc2hvdWxkIGJlIGd1aWRlZCBieQ0KICAgdGhlIGZvbGxv d2luZyBydWxlczoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1i ZXIgMjAsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDM3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoN Cg0KICAgMS4gIFVzZSBhcyBwcmVjaXNlIGEgdGFnIGFzIHBvc3NpYmxlLCBidXQgbm8gbW9yZSBz cGVjaWZpYyB0aGFuIGlzDQogICAgICAganVzdGlmaWVkLiAgQXZvaWQgdXNpbmcgc3VidGFncyB0 aGF0IGFyZSBub3QgaW1wb3J0YW50IGZvcg0KICAgICAgIGRpc3Rpbmd1aXNoaW5nIGNvbnRlbnQg aW4gYW4gYXBwbGljYXRpb24uDQoNCiAgICAgICAqICBGb3IgZXhhbXBsZSwgJ2RlJyBtaWdodCBz dWZmaWNlIGZvciB0YWdnaW5nIGFuIGVtYWlsIHdyaXR0ZW4NCiAgICAgICAgICBpbiBHZXJtYW4s IHdoaWxlICJkZS1DSC0xOTk2IiBpcyBwcm9iYWJseSB1bm5lY2Vzc2FyaWx5DQogICAgICAgICAg cHJlY2lzZSBmb3Igc3VjaCBhIHRhc2suDQoNCiAgIDIuICBUaGUgc2NyaXB0IHN1YnRhZyBTSE9V TEQgTk9UIGJlIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHVubGVzcw0KICAgICAgIHRoZSBz Y3JpcHQgYWRkcyBzb21lIGRpc3Rpbmd1aXNoaW5nIGluZm9ybWF0aW9uIHRvIHRoZSB0YWcuICBU aGUNCiAgICAgICBmaWVsZCAnU3VwcHJlc3MtU2NyaXB0JyBpbiB0aGUgcHJpbWFyeSBsYW5ndWFn ZSByZWNvcmQgaW4gdGhlDQogICAgICAgcmVnaXN0cnkgaW5kaWNhdGVzIHdoaWNoIHNjcmlwdCBz dWJ0YWdzIGRvIG5vdCBhZGQgZGlzdGluZ3Vpc2hpbmcNCiAgICAgICBpbmZvcm1hdGlvbiBmb3Ig bW9zdCBhcHBsaWNhdGlvbnMuDQoNCiAgICAgICAqICBGb3IgZXhhbXBsZSwgdGhlIHN1YnRhZyAn TGF0bicgc2hvdWxkIG5vdCBiZSB1c2VkIHdpdGggdGhlDQogICAgICAgICAgcHJpbWFyeSBsYW5n dWFnZSAnZW4nIGJlY2F1c2UgbmVhcmx5IGFsbCBFbmdsaXNoIGRvY3VtZW50cyBhcmUNCiAgICAg ICAgICB3cml0dGVuIGluIHRoZSBMYXRpbiBzY3JpcHQgYW5kIGl0IGFkZHMgbm8gZGlzdGluZ3Vp c2hpbmcNCiAgICAgICAgICBpbmZvcm1hdGlvbi4gIEhvd2V2ZXIsIGlmIGEgZG9jdW1lbnQgd2Vy ZSB3cml0dGVuIGluIEVuZ2xpc2gNCiAgICAgICAgICBtaXhpbmcgTGF0aW4gc2NyaXB0IHdpdGgg YW5vdGhlciBzY3JpcHQgc3VjaCBhcyBCcmFpbGxlDQogICAgICAgICAgKCdCcmFpJyksIHRoZW4g aXQgbWF5IGJlIGFwcHJvcHJpYXRlIHRvIGNob29zZSB0byBpbmRpY2F0ZQ0KICAgICAgICAgIGJv dGggc2NyaXB0cyB0byBhaWQgaW4gY29udGVudCBzZWxlY3Rpb24sIHN1Y2ggYXMgdGhlDQogICAg ICAgICAgYXBwbGljYXRpb24gb2YgYSBzdHlsZXNoZWV0Lg0KDQogICAzLiAgSWYgYSBzdWJ0YWcg aGFzIGEgJ0Nhbm9uaWNhbCcgZmllbGQgaW4gaXRzIHJlZ2lzdHJ5IGVudHJ5LCB0aGUNCiAgICAg ICBjYW5vbmljYWwgc3VidGFnIFNIT1VMRCBiZSB1c2VkIHRvIGZvcm0gdGhlIGxhbmd1YWdlIHRh ZyBpbg0KICAgICAgIHByZWZlcmVuY2UgdG8gYW55IG9mIGl0cyBhbGlhc2VzLg0KDQogICAgICAg KiAgRm9yIGV4YW1wbGUsIHVzZSAnaGUnIGZvciBIZWJyZXcgaW4gcHJlZmVyZW5jZSB0byAnaXcn Lg0KDQogICA0LiAgVGhlICd1bmQnIChVbmRldGVybWluZWQpIHByaW1hcnkgbGFuZ3VhZ2Ugc3Vi dGFnIFNIT1VMRCBOT1QgYmUNCiAgICAgICB1c2VkIHRvIGxhYmVsIGNvbnRlbnQsIGV2ZW4gaWYg dGhlIGxhbmd1YWdlIGlzIHVua25vd24uICBPbWl0dGluZw0KICAgICAgIHRoZSBsYW5ndWFnZSB0 YWcgYWx0b2dldGhlciBpcyBwcmVmZXJyZWQgdG8gdXNpbmcgYSB0YWcgd2l0aCBhDQogICAgICAg cHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgb2YgJ3VuZCcuICBUaGUgJ3VuZCcgc3VidGFnIG1heSBi ZSB1c2VmdWwNCiAgICAgICBmb3IgcHJvdG9jb2xzIHRoYXQgcmVxdWlyZSBhIGxhbmd1YWdlIHRh ZyB0byBiZSBwcm92aWRlZC4gIFRoZQ0KICAgICAgICd1bmQnIHN1YnRhZyBtYXkgYWxzbyBiZSB1 c2VmdWwgd2hlbiBtYXRjaGluZyBsYW5ndWFnZSB0YWdzIGluDQogICAgICAgY2VydGFpbiBzaXR1 YXRpb25zLg0KDQogICA1LiAgVGhlICdtdWwnIChNdWx0aXBsZSkgcHJpbWFyeSBsYW5ndWFnZSBz dWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2VkDQogICAgICAgd2hlbmV2ZXIgdGhlIHByb3RvY29sIGFs bG93cyB0aGUgc2VwYXJhdGUgdGFncyBmb3IgbXVsdGlwbGUNCiAgICAgICBsYW5ndWFnZXMsIGFz IGlzIHRoZSBjYXNlIGZvciB0aGUgQ29udGVudC1MYW5ndWFnZSBoZWFkZXIgaW4NCiAgICAgICBI VFRQLiAgVGhlICdtdWwnIHN1YnRhZyBjb252ZXlzIGxpdHRsZSB1c2VmdWwgaW5mb3JtYXRpb246 DQogICAgICAgY29udGVudCBpbiBtdWx0aXBsZSBsYW5ndWFnZXMgc2hvdWxkIGluZGl2aWR1YWxs eSB0YWcgdGhlDQogICAgICAgbGFuZ3VhZ2VzIHdoZXJlIHRoZXkgYXBwZWFyIG9yIG90aGVyd2lz ZSBpbmRpY2F0ZSB0aGUgYWN0dWFsDQogICAgICAgbGFuZ3VhZ2UgaW4gcHJlZmVyZW5jZSB0byB0 aGUgJ211bCcgc3VidGFnLg0KDQogICA2LiAgVGhlIHNhbWUgdmFyaWFudCBzdWJ0YWcgU0hPVUxE IE5PVCBiZSB1c2VkIG1vcmUgdGhhbiBvbmNlIHdpdGhpbg0KICAgICAgIGEgbGFuZ3VhZ2UgdGFn Lg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAy MDA1ICAgICAgICAgICAgICBbUGFnZSAzOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgICAg ICAqICBGb3IgZXhhbXBsZSwgZG8gbm90IHVzZSAiZW4tR0Itc2NvdXNlLXNjb3VzZSIuDQoNCiAg IFRvIGVuc3VyZSBjb25zaXN0ZW50IGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIHRoaXMgZG9jdW1l bnQgY29udGFpbnMNCiAgIHNldmVyYWwgcHJvdmlzaW9ucyB0byBhY2NvdW50IGZvciBwb3RlbnRp YWwgaW5zdGFiaWxpdHkgaW4gdGhlDQogICBzdGFuZGFyZHMgdXNlZCB0byBkZWZpbmUgdGhlIHN1 YnRhZ3MgdGhhdCBtYWtlIHVwIGxhbmd1YWdlIHRhZ3MuDQogICBUaGVzZSBwcm92aXNpb25zIG1l YW4gdGhhdCBubyBsYW5ndWFnZSB0YWcgY3JlYXRlZCB1bmRlciB0aGUgcnVsZXMgaW4NCiAgIHRo aXMgZG9jdW1lbnQgd2lsbCBiZWNvbWUgb2Jzb2xldGUuICBJbiBhZGRpdGlvbiwgdGFncyB0aGF0 IGFyZSBpbg0KICAgY2Fub25pY2FsIGZvcm0gd2lsbCBhbHdheXMgYmUgaW4gY2Fub25pY2FsIGZv cm0uDQoNCjQuMiAgTWVhbmluZyBvZiB0aGUgTGFuZ3VhZ2UgVGFnDQoNCiAgIFRoZSBsYW5ndWFn ZSB0YWcgYWx3YXlzIGRlZmluZXMgYSBsYW5ndWFnZSBhcyBzcG9rZW4gKG9yIHdyaXR0ZW4sDQog ICBzaWduZWQgb3Igb3RoZXJ3aXNlIHNpZ25hbGVkKSBieSBodW1hbiBiZWluZ3MgZm9yIGNvbW11 bmljYXRpb24gb2YNCiAgIGluZm9ybWF0aW9uIHRvIG90aGVyIGh1bWFuIGJlaW5ncy4gIENvbXB1 dGVyIGxhbmd1YWdlcyBzdWNoIGFzDQogICBwcm9ncmFtbWluZyBsYW5ndWFnZXMgYXJlIGV4cGxp Y2l0bHkgZXhjbHVkZWQuDQoNCiAgIElmIGEgbGFuZ3VhZ2UgdGFnIEIgY29udGFpbnMgbGFuZ3Vh Z2UgdGFnIEEgYXMgYSBwcmVmaXgsIHRoZW4gQiBpcw0KICAgdHlwaWNhbGx5ICJuYXJyb3dlciIg b3IgIm1vcmUgc3BlY2lmaWMiIHRoYW4gQS4gRm9yIGV4YW1wbGUsICJ6aC0NCiAgIEhhbnQtVFci IGlzIG1vcmUgc3BlY2lmaWMgdGhhbiAiemgtSGFudCIuDQoNCiAgIFRoaXMgcmVsYXRpb25zaGlw IGlzIG5vdCBndWFyYW50ZWVkIGluIGFsbCBjYXNlczogc3BlY2lmaWNhbGx5LA0KICAgbGFuZ3Vh Z2VzIHRoYXQgYmVnaW4gd2l0aCB0aGUgc2FtZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFyZSBOT1QN CiAgIGd1YXJhbnRlZWQgdG8gYmUgbXV0dWFsbHkgaW50ZWxsaWdpYmxlLCBhbHRob3VnaCB0aGV5 IG1heSBiZS4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIHRhZyAiYXoiIHNoYXJlcyBhIHByZWZpeCB3 aXRoIGJvdGggImF6LUxhdG4iDQogICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0aGUgTGF0 aW4gc2NyaXB0KSBhbmQgImF6LUN5cmwiDQogICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0 aGUgQ3lyaWxsaWMgc2NyaXB0KS4gIEEgcGVyc29uIGZsdWVudCBpbg0KICAgb25lIHNjcmlwdCBt YXkgbm90IGJlIGFibGUgdG8gcmVhZCB0aGUgb3RoZXIsIGV2ZW4gdGhvdWdoIHRoZSB0ZXh0DQog ICBtaWdodCBiZSBpZGVudGljYWwuICBDb250ZW50IHRhZ2dlZCBhcyAiYXoiIG1vc3QgcHJvYmFi bHkgaXMgd3JpdHRlbg0KICAgaW4ganVzdCBvbmUgc2NyaXB0IGFuZCB0aHVzIG1pZ2h0IG5vdCBi ZSBpbnRlbGxpZ2libGUgdG8gYSByZWFkZXINCiAgIGZhbWlsaWFyIHdpdGggdGhlIG90aGVyIHNj cmlwdC4NCg0KICAgVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB0YWcgYW5kIHRoZSBpbmZv cm1hdGlvbiBpdCByZWxhdGVzIHRvIGlzDQogICBkZWZpbmVkIGJ5IHRoZSBzdGFuZGFyZCBkZXNj cmliaW5nIHRoZSBjb250ZXh0IGluIHdoaWNoIGl0IGFwcGVhcnMuDQogICBBY2NvcmRpbmdseSwg dGhpcyBzZWN0aW9uIGNhbiBvbmx5IGdpdmUgcG9zc2libGUgZXhhbXBsZXMgb2YgaXRzDQogICB1 c2FnZS4NCg0KICAgbyAgRm9yIGEgc2luZ2xlIGluZm9ybWF0aW9uIG9iamVjdCwgdGhlIGFzc29j aWF0ZWQgbGFuZ3VhZ2UgdGFncw0KICAgICAgbWlnaHQgYmUgaW50ZXJwcmV0ZWQgYXMgdGhlIHNl dCBvZiBsYW5ndWFnZXMgdGhhdCBpcyByZXF1aXJlZCBmb3INCiAgICAgIGEgY29tcGxldGUgY29t cHJlaGVuc2lvbiBvZiB0aGUgY29tcGxldGUgb2JqZWN0LiAgRXhhbXBsZTogUGxhaW4NCiAgICAg IHRleHQgZG9jdW1lbnRzLg0KDQogICBvICBGb3IgYW4gYWdncmVnYXRpb24gb2YgaW5mb3JtYXRp b24gb2JqZWN0cywgdGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UNCiAgICAgIHRhZ3MgY291bGQgYmUg dGFrZW4gYXMgdGhlIHNldCBvZiBsYW5ndWFnZXMgdXNlZCBpbnNpZGUgY29tcG9uZW50cw0KICAg ICAgb2YgdGhhdCBhZ2dyZWdhdGlvbi4gIEV4YW1wbGVzOiBEb2N1bWVudCBzdG9yZXMgYW5kIGxp YnJhcmllcy4NCg0KICAgbyAgRm9yIGluZm9ybWF0aW9uIG9iamVjdHMgd2hvc2UgcHVycG9zZSBp cyB0byBwcm92aWRlIGFsdGVybmF0aXZlcywNCiAgICAgIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdl IHRhZ3MgY291bGQgYmUgcmVnYXJkZWQgYXMgYSBoaW50IHRoYXQgdGhlDQogICAgICBjb250ZW50 IGlzIHByb3ZpZGVkIGluIHNldmVyYWwgbGFuZ3VhZ2VzLCBhbmQgdGhhdCBvbmUgaGFzIHRvDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAg ICAgICAgICAgICBbUGFnZSAzOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgICAgIGluc3Bl Y3QgZWFjaCBvZiB0aGUgYWx0ZXJuYXRpdmVzIGluIG9yZGVyIHRvIGZpbmQgaXRzIGxhbmd1YWdl IG9yDQogICAgICBsYW5ndWFnZXMuICBJbiB0aGlzIGNhc2UsIHRoZSBwcmVzZW5jZSBvZiBtdWx0 aXBsZSB0YWdzIG1pZ2h0IG5vdA0KICAgICAgbWVhbiB0aGF0IG9uZSBuZWVkcyB0byBiZSBtdWx0 aS1saW5ndWFsIHRvIGdldCBjb21wbGV0ZQ0KICAgICAgdW5kZXJzdGFuZGluZyBvZiB0aGUgZG9j dW1lbnQuICBFeGFtcGxlOiBNSU1FIG11bHRpcGFydC8NCiAgICAgIGFsdGVybmF0aXZlLg0KDQog ICBvICBJbiBtYXJrdXAgbGFuZ3VhZ2VzLCBzdWNoIGFzIEhUTUwgYW5kIFhNTCwgbGFuZ3VhZ2Ug aW5mb3JtYXRpb24NCiAgICAgIGNhbiBiZSBhZGRlZCB0byBlYWNoIHBhcnQgb2YgdGhlIGRvY3Vt ZW50IGlkZW50aWZpZWQgYnkgdGhlIG1hcmt1cA0KICAgICAgc3RydWN0dXJlIChpbmNsdWRpbmcg dGhlIHdob2xlIGRvY3VtZW50IGl0c2VsZikuICBGb3IgZXhhbXBsZSwgb25lDQogICAgICBjb3Vs ZCB3cml0ZSA8c3BhbiBsYW5nPSJmciI+Qydlc3QgbGEgdmllLjwvc3Bhbj4gaW5zaWRlIGENCiAg ICAgIE5vcndlZ2lhbiBkb2N1bWVudDsgdGhlIE5vcndlZ2lhbi1zcGVha2luZyB1c2VyIGNvdWxk IHRoZW4gYWNjZXNzDQogICAgICBhIEZyZW5jaC1Ob3J3ZWdpYW4gZGljdGlvbmFyeSB0byBmaW5k IG91dCB3aGF0IHRoZSBtYXJrZWQgc2VjdGlvbg0KICAgICAgbWVhbnQuICBJZiB0aGUgdXNlciB3 ZXJlIGxpc3RlbmluZyB0byB0aGF0IGRvY3VtZW50IHRocm91Z2ggYQ0KICAgICAgc3BlZWNoIHN5 bnRoZXNpcyBpbnRlcmZhY2UsIHRoaXMgZm9ybWF0aW9uIGNvdWxkIGJlIHVzZWQgdG8gc2lnbmFs DQogICAgICB0aGUgc3ludGhlc2l6ZXIgdG8gYXBwcm9wcmlhdGVseSBhcHBseSBGcmVuY2ggdGV4 dC10by1zcGVlY2gNCiAgICAgIHByb251bmNpYXRpb24gcnVsZXMgdG8gdGhhdCBzcGFuIG9mIHRl eHQsIGluc3RlYWQgb2YgYXBwbHlpbmcgdGhlDQogICAgICBpbmFwcHJvcHJpYXRlIE5vcndlZ2lh biBydWxlcy4NCg0KDQo0LjMgIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0KDQog ICBTaW5jZSBhIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgdGFnIG1heSBiZSB1c2VkIGluIG1hbnkgcHJv Y2Vzc2VzLA0KICAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWx3YXlzIGJlIGNyZWF0ZWQgb3IgZ2Vu ZXJhdGVkIGluIGEgY2Fub25pY2FsDQogICBmb3JtLg0KDQogICBBIGxhbmd1YWdlIHRhZyBpcyBp biBjYW5vbmljYWwgZm9ybSB3aGVuOg0KDQogICAxLiAgVGhlIHRhZyBpcyB3ZWxsLWZvcm1lZCBh Y2NvcmRpbmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gMi4xIGFuZA0KICAgICAgIFNlY3Rpb24gMi4y Lg0KDQogICAyLiAgTm9uZSBvZiB0aGUgc3VidGFncyBpbiB0aGUgbGFuZ3VhZ2UgdGFnIGhhcyBh IENhbm9uaWNhbC1WYWx1ZQ0KICAgICAgIG1hcHBpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgKHNl ZSBTZWN0aW9uIDMuMSkuICBTdWJ0YWdzIHdpdGggYQ0KICAgICAgIENhbm9uaWNhbC1WYWx1ZSBt YXBwaW5nIE1VU1QgYmUgcmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwaW5nIGluDQogICAgICAgb3Jk ZXIgdG8gY2Fub25pY2FsaXplIHRoZSB0YWcuDQoNCiAgIDMuICBJZiBtb3JlIHRoYW4gb25lIGV4 dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2UgZXhpc3RzLCB0aGUgZXh0ZW5zaW9uDQogICAgICAgc2Vx dWVuY2VzIGFyZSBvcmRlcmVkIGludG8gY2FzZS1pbnNlbnNpdGl2ZSBBU0NJSSBvcmRlciBieQ0K ICAgICAgIHNpbmdsZXRvbiBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6IFRoZSBsYW5ndWFnZSB0YWcg ImVuLUEtYWFhLUItY2NjLWJiYi14LXh5eiIgaXMgaW4gY2Fub25pY2FsDQogICBmb3JtLCB3aGls ZSAiZW4tQi1jY2MtYmJiLUEtYWFhLVgteHl6IiBpcyB3ZWxsLWZvcm1lZCBidXQgbm90IGluDQog ICBjYW5vbmljYWwgZm9ybS4NCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAiZW4tTkgi IChFbmdsaXNoIGFzIHVzZWQgaW4gdGhlIE5ldw0KICAgSGVicmlkZXMpIGlzIG5vdCBjYW5vbmlj YWwgYmVjYXVzZSB0aGUgJ05IJyBzdWJ0YWcgaGFzIGEgY2Fub25pY2FsDQogICBtYXBwaW5nIHRv ICdWVScgKFZhbnVhdHUpLg0KDQogICBDYW5vbmljYWxpemF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mg ZG9lcyBub3QgaW1wbHkgYW55dGhpbmcgYWJvdXQgdGhlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSA0MF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgIHVzZSBvZiB1cHBlciBvciBsb3dlcmNhc2UgbGV0 dGVycyB3aGVuIHByb2Nlc3Npbmcgb3IgY29tcGFyaW5nDQogICBzdWJ0YWdzIChhbmQgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gMi4xKS4gIEFsbCBjb21wYXJpc29ucyBNVVNUIGJlDQogICBwZXJm b3JtZWQgaW4gYSBjYXNlLWluc2Vuc2l0aXZlIG1hbm5lci4NCg0KICAgV2hlbiBwZXJmb3JtaW5n IGNhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncywgcHJvY2Vzc29ycyBNQVkNCiAgIG9w dGlvbmFsbHkgcmVndWxhcml6ZSB0aGUgY2FzZSBvZiB0aGUgc3VidGFncywgZm9sbG93aW5nIHRo ZSBjYXNlDQogICB1c2VkIGluIHRoZSByZWdpc3RyeS4gIE5vdGUgdGhhdCB0aGlzIGNvcnJlc3Bv bmRzIHRvIHRoZSBmb2xsb3dpbmcNCiAgIGNhc2luZyBydWxlczogdXBwZXJjYXNlIGFsbCBub24t aW5pdGlhbCB0d28tbGV0dGVyIHN1YnRhZ3M7IHRpdGxlY2FzZQ0KICAgYWxsIG5vbi1pbml0aWFs IGZvdXItbGV0dGVyIHN1YnRhZ3M7IGxvd2VyY2FzZSBldmVyeXRoaW5nIGVsc2UuDQoNCiAgIE5v dGU6IENhc2UgZm9sZGluZyBvZiBBU0NJSSBsZXR0ZXJzIGluIGNlcnRhaW4gbG9jYWxlcywgdW5s ZXNzDQogICBjYXJlZnVsbHkgaGFuZGxlZCwgbWF5IHByb2R1Y2Ugbm9uLUFTQ0lJIGNoYXJhY3Rl ciB2YWx1ZXMuICBUaGUNCiAgIFVuaWNvZGUgQ2hhcmFjdGVyIERhdGFiYXNlIGZpbGUgIlNwZWNp YWxDYXNpbmcudHh0IiBkZWZpbmVzIHRoZQ0KICAgc3BlY2lmaWMgY2FzZXMgdGhhdCBhcmUga25v d24gdG8gY2F1c2UgcHJvYmxlbXMgd2l0aCB0aGlzLiAgSW4NCiAgIHBhcnRpY3VsYXIsIHRoZSBs ZXR0ZXIgJ2knIChVKzAwNjkpIGluIFR1cmtpc2ggYW5kIEF6ZXJiYWlqYW5pIGlzDQogICB1cHBl cmNhc2VkIHRvIFUrMDEzMCAoTEFUSU4gQ0FQSVRBTCBMRVRURVIgSSBXSVRIIERPVCBBQk9WRSku DQogICBJbXBsZW1lbnRlcnMgc2hvdWxkIHNwZWNpZnkgYSBsb2NhbGUtbmV1dHJhbCBjYXNpbmcg b3BlcmF0aW9uIHRvDQogICBlbnN1cmUgdGhhdCBjYXNlIGZvbGRpbmcgb2Ygc3VidGFncyBkb2Vz IG5vdCBwcm9kdWNlIHRoaXMgdmFsdWUsDQogICB3aGljaCBpcyBpbGxlZ2FsIGluIGxhbmd1YWdl IHRhZ3MuICBGb3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8NCiAgIHVwcGVyY2FzZSB0aGUgcmVn aW9uIHN1YnRhZyAnaW4nIHVzaW5nIFR1cmtpc2ggbG9jYWxlIHJ1bGVzLCB0aGUNCiAgIHNlcXVl bmNlIFUrMDEzMCBVKzAwNEUgd291bGQgcmVzdWx0IGluc3RlYWQgb2YgdGhlIGV4cGVjdGVkICdJ TicuDQoNCiAgIE5vdGU6IGlmIHRoZSBmaWVsZCAnRGVwcmVjYXRlZCcgYXBwZWFycyBpbiBhIHJl Z2lzdHJ5IHJlY29yZCB3aXRob3V0DQogICBhbiBhY2NvbXBhbnlpbmcgJ0Nhbm9uaWNhbCcgZmll bGQsIHRoZW4gdGhhdCB0YWcgb3Igc3VidGFnIGlzDQogICBkZXByZWNhdGVkIHdpdGhvdXQgYSBy ZXBsYWNlbWVudC4gIFZhbGlkYXRpbmcgcHJvY2Vzc29ycyBTSE9VTEQgTk9UDQogICBnZW5lcmF0 ZSB0YWdzIHRoYXQgaW5jbHVkZSB0aGVzZSB2YWx1ZXMsIGFsdGhvdWdoIHRoZSB2YWx1ZXMgYXJl DQogICBjYW5vbmljYWwgd2hlbiB0aGV5IGFwcGVhciBpbiBhIGxhbmd1YWdlIHRhZy4NCg0KICAg QW4gZXh0ZW5zaW9uIE1VU1QgZGVmaW5lIGFueSByZWxhdGlvbnNoaXBzIHRoYXQgbWF5IGV4aXN0 IGJldHdlZW4gdGhlDQogICB2YXJpb3VzIHN1YnRhZ3MgaW4gdGhlIGV4dGVuc2lvbiBhbmQgdGh1 cyBNQVkgZGVmaW5lIGFuIGFsdGVybmF0ZQ0KICAgY2Fub25pY2FsaXphdGlvbiBzY2hlbWUgZm9y IHRoZSBleHRlbnNpb24ncyBzdWJ0YWdzLiAgRXh0ZW5zaW9ucyBNQVkNCiAgIGRlZmluZSBob3cg dGhlIG9yZGVyIG9mIHRoZSBleHRlbnNpb24ncyBzdWJ0YWdzIGFyZSBpbnRlcnByZXRlZC4gIEZv cg0KICAgZXhhbXBsZSwgYW4gZXh0ZW5zaW9uIGNvdWxkIGRlZmluZSB0aGF0IGl0cyBzdWJ0YWdz IGFyZSBpbiBjYW5vbmljYWwNCiAgIG9yZGVyIHdoZW4gdGhlIHN1YnRhZ3MgYXJlIHBsYWNlZCBp bnRvIEFTQ0lJIG9yZGVyOiB0aGF0IGlzLCAiZW4tYS0NCiAgIGFhYS1iYmItY2NjIiBpbnN0ZWFk IG9mICJlbi1hLWNjYy1iYmItYWFhIi4gIEFub3RoZXIgZXh0ZW5zaW9uIG1pZ2h0DQogICBkZWZp bmUgdGhhdCB0aGUgb3JkZXIgb2YgdGhlIHN1YnRhZ3MgaW5mbHVlbmNlcyB0aGVpciBzZW1hbnRp Yw0KICAgbWVhbmluZyAoc28gdGhhdCAiZW4tYi1jY2MtYmJiLWFhYSIgaGFzIGEgZGlmZmVyZW50 IHZhbHVlIGZyb20gImVuLWItDQogICBhYWEtYmJiLWNjYyIpLiAgSG93ZXZlciwgZXh0ZW5zaW9u IHNwZWNpZmljYXRpb25zIFNIT1VMRCBiZSBkZXNpZ25lZA0KICAgc28gdGhhdCB0aGV5IGFyZSB0 b2xlcmFudCBvZiB0aGUgdHlwaWNhbCBwcm9jZXNzZXMgZGVzY3JpYmVkIGluDQogICBTZWN0aW9u IDMuNi4NCg0KNC40ICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncw0KDQog ICBQcml2YXRlLXVzZSBzdWJ0YWdzIHJlcXVpcmUgcHJpdmF0ZSBhZ3JlZW1lbnQgYmV0d2VlbiB0 aGUgcGFydGllcw0KICAgdGhhdCBpbnRlbmQgdG8gdXNlIG9yIGV4Y2hhbmdlIGxhbmd1YWdlIHRh Z3MgdGhhdCB1c2UgdGhlbSBhbmQgZ3JlYXQNCiAgIGNhdXRpb24gc2hvdWxkIGJlIHVzZWQgaW4g ZW1wbG95aW5nIHRoZW0gaW4gY29udGVudCBvciBwcm90b2NvbHMNCiAgIGludGVuZGVkIGZvciBn ZW5lcmFsIHVzZS4gIFByaXZhdGUtdXNlIHN1YnRhZ3MgYXJlIHNpbXBseSB1c2VsZXNzIGZvcg0K ICAgaW5mb3JtYXRpb24gZXhjaGFuZ2Ugd2l0aG91dCBwcmlvciBhcnJhbmdlbWVudC4NCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAsIDIwMDUgICAgICAg ICAgICAgIFtQYWdlIDQxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KICAgVGhlIHZhbHVlIGFu ZCBzZW1hbnRpYyBtZWFuaW5nIG9mIHByaXZhdGUtdXNlIHRhZ3MgYW5kIG9mIHRoZSBzdWJ0YWdz DQogICB1c2VkIHdpdGhpbiBzdWNoIGEgbGFuZ3VhZ2UgdGFnIGFyZSBub3QgZGVmaW5lZCBieSB0 aGlzIGRvY3VtZW50Lg0KDQogICBUaGUgdXNlIG9mIHN1YnRhZ3MgZGVmaW5lZCBpbiB0aGUgSUFO QSByZWdpc3RyeSBhcyBoYXZpbmcgYSBzcGVjaWZpYw0KICAgcHJpdmF0ZSB1c2UgbWVhbmluZyBj b252ZXkgbW9yZSBpbmZvcm1hdGlvbiB0aGF0IGEgcHVyZWx5IHByaXZhdGUgdXNlDQogICB0YWcg cHJlZml4ZWQgYnkgdGhlIHNpbmdsZXRvbiBzdWJ0YWcgJ3gnLiAgRm9yIGFwcGxpY2F0aW9ucyB0 aGlzDQogICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIG1heSBiZSB1c2VmdWwuDQoNCiAgIEZvciBl eGFtcGxlLCB0aGUgcmVnaW9uIHN1YnRhZ3MgJ0FBJywgJ1paJyBhbmQgaW4gdGhlIHJhbmdlcw0K ICAgJ1FNJy0nUVonIGFuZCAnWEEnLSdYWicgKGRlcml2ZWQgZnJvbSBJU08gMzE2NiBwcml2YXRl IHVzZSBjb2RlcykgbWF5DQogICBiZSB1c2VkIHRvIGZvcm0gYSBsYW5ndWFnZSB0YWcuICBBIHRh ZyBzdWNoIGFzICJ6aC1IYW5zLVhRIiBjb252ZXlzIGENCiAgIGdyZWF0IGRlYWwgb2YgcHVibGlj LCBpbnRlcmNoYW5nZWFibGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxhbmd1YWdlDQogICBtYXRl cmlhbCAodGhhdCBpdCBpcyBDaGluZXNlIGluIHRoZSBzaW1wbGlmaWVkIENoaW5lc2Ugc2NyaXB0 IGFuZCBpcw0KICAgc3VpdGFibGUgZm9yIHNvbWUgZ2VvZ3JhcGhpYyByZWdpb24gJ1hRJykuICBX aGlsZSB0aGUgcHJlY2lzZQ0KICAgZ2VvZ3JhcGhpYyByZWdpb24gaXMgbm90IGtub3duIG91dHNp ZGUgb2YgcHJpdmF0ZSBhZ3JlZW1lbnQsIHRoZSB0YWcNCiAgIGNvbnZleXMgZmFyIG1vcmUgaW5m b3JtYXRpb24gdGhhbiBhbiBvcGFxdWUgdGFnIHN1Y2ggYXMgIngtc29tZUxhbmciLA0KICAgd2hp Y2ggY29udGFpbnMgbm8gaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxhbmd1YWdlIHN1YnRhZyBvciBz Y3JpcHQNCiAgIHN1YnRhZyBvdXRzaWRlIG9mIHRoZSBwcml2YXRlIGFncmVlbWVudC4NCg0KICAg SG93ZXZlciwgaW4gc29tZSBjYXNlcyBjb250ZW50IHRhZ2dlZCB3aXRoIHByaXZhdGUgdXNlIHN1 YnRhZ3MgbWF5DQogICBpbnRlcmFjdCB3aXRoIG90aGVyIHN5c3RlbXMgaW4gYSBkaWZmZXJlbnQg YW5kIHBvc3NpYmx5IHVuc3VpdGFibGUNCiAgIG1hbm5lciBjb21wYXJlZCB0byB0YWdzIHRoYXQg dXNlIG9wYXF1ZSwgcHJpdmF0ZWx5IGRlZmluZWQgc3VidGFncywNCiAgIHNvIHRoZSBjaG9pY2Ug b2YgdGhlIGJlc3QgYXBwcm9hY2ggbWF5IGRlcGVuZCBvbiB0aGUgcGFydGljdWxhcg0KICAgZG9t YWluIGluIHF1ZXN0aW9uLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAy MCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQo1 LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIHNlY3Rpb24gZGVhbHMgd2l0aCB0aGUg cHJvY2Vzc2VzIGFuZCByZXF1aXJlbWVudHMgbmVjZXNzYXJ5IGZvcg0KICAgSUFOQSB0byB1bmRl cnRha2UgdG8gbWFpbnRhaW4gdGhlIHJzdWJ0YWcgYW5kIGV4dGVuc2lvbiByZWdpc3RyaWVzIGFz DQogICBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgYW5kIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUg cmVxdWlyZW1lbnRzIG9mDQogICBSRkMgMjQzNCBbMTFdLg0KDQogICBUaGUgaW1wYWN0IG9uIHRo ZSBJQU5BIG1haW50YWluZXJzIG9mIHRoZSB0d28gcmVnaXN0cmllcyBkZWZpbmVkIGJ5DQogICB0 aGlzIGRvY3VtZW50IHdpbGwgYmUgYSBzbWFsbCBpbmNyZWFzZSBpbiB0aGUgZnJlcXVlbmN5IG9m IG5ldw0KICAgZW50cmllcyBvciB1cGRhdGVzLg0KDQogICBVcG9uIGFkb3B0aW9uIG9mIHRoaXMg ZG9jdW1lbnQsIHRoZSBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNw0KICAgd2lsbCBi ZSB1c2VkIHRvIGdlbmVyYXRlIHRoZSBpbml0aWFsIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4g IFRoZQ0KICAgaW5pdGlhbCBzZXQgb2YgcmVjb3JkcyByZXByZXNlbnRzIG5vIGltcGFjdCBvbiBJ QU5BLCBzaW5jZSB0aGUgd29yaw0KICAgdG8gY3JlYXRlIGl0IHdpbGwgYmUgcGVyZm9ybWVkIGV4 dGVybmFsbHkgKGFzIGRlZmluZWQgaW4gdGhhdA0KICAgc2VjdGlvbikuICBUaGUgbmV3IHJlZ2lz dHJ5IHdpbGwgYmUgbGlzdGVkIHVuZGVyICJMYW5ndWFnZSBUYWdzIiBhdA0KICAgPGh0dHA6Ly93 d3cuaWFuYS5vcmcvbnVtYmVycy5odG1sPi4gIFRoZSBleGlzdGluZyBkaXJlY3Rvcnkgb2YNCiAg IHJlZ2lzdHJhdGlvbiBmb3JtcyBhbmQgUkZDIDMwNjYgcmVnaXN0cmF0aW9ucyB3aWxsIGJlIHJl bGFiZWxlZCBhcw0KICAgIkxhbmd1YWdlIFRhZ3MgKE9ic29sZXRlKSIgYW5kIG1haW50YWluZWQg KGJ1dCBub3QgYWRkZWQgdG8gb3INCiAgIG1vZGlmaWVkKS4NCg0KICAgRnV0dXJlIHdvcmsgb24g dGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSB3aWxsIGJlIGxpbWl0ZWQgdG8NCiAgIGluc2Vy dGluZyBvciByZXBsYWNpbmcgd2hvbGUgcmVjb3JkcyBwcmVmb3JtYXR0ZWQgZm9yIElBTkEgYnkg dGhlDQogICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g My4yIG9mIHRoaXMNCiAgIGRvY3VtZW50LiAgRWFjaCByZWNvcmQgd2lsbCBiZSBzZW50IHRvIGlh bmFAaWFuYS5vcmcgd2l0aCBhIHN1YmplY3QNCiAgIGxpbmUgaW5kaWNhdGluZyB3aGV0aGVyIHRo ZSBlbmNsb3NlZCByZWNvcmQgaXMgYW4gaW5zZXJ0aW9uIChvZiBhIG5ldw0KICAgcmVjb3JkKSBv ciBhIHJlcGxhY21lbnQgb2YgYW4gZXhpc3RpbmcgcmVjb3JkIHdoaWNoIGhhcyBhIFR5cGUgYW5k DQogICBTdWJ0YWcgKG9yIFRhZykgZmllbGQgdGhhdCBleGFjdGx5IG1hdGNoZXMgdGhlIHJlY29y ZCBzZW50LiAgUmVjb3Jkcw0KICAgY2Fubm90IGJlIGRlbGV0ZWQgZnJvbSB0aGUgcmVnaXN0cnku DQoNCiAgIFRoZSBMYW5ndWFnZSBUYWcgRXh0ZW5zaW9ucyByZWdpc3RyeSB3aWxsIGFsc28gYmUg Z2VuZXJhdGVkIGFuZCBzZW50DQogICB0byBJQU5BIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMu Ni4gIFRoaXMgcmVnaXN0cnkgbWF5IGNvbnRhaW4gYXQNCiAgIG1vc3QgMzUgcmVjb3JkcyBhbmQg dGh1cyBjaGFuZ2VzIHRvIHRoaXMgcmVnaXN0cnkgYXJlIGV4cGVjdGVkIHRvIGJlDQogICB2ZXJ5 IGluZnJlcXVlbnQuDQoNCiAgIEZ1dHVyZSB3b3JrIGJ5IElBTkEgb24gdGhlIExhbmd1YWdlIFRh ZyBFeHRlbnNpb25zIFJlZ2lzdHJ5IGlzDQogICBsaW1pdGVkIHRvIHR3byBjYXNlcy4gIEZpcnN0 LCB0aGUgSUVTRyBtYXkgcmVxdWVzdCB0aGF0IG5ldyByZWNvcmRzDQogICBiZSBpbnNlcnRlZCBp bnRvIHRoaXMgcmVnaXN0cnkgZnJvbSB0aW1lIHRvIHRpbWUuICBUaGVzZSByZXF1ZXN0cw0KICAg d2lsbCBpbmNsdWRlIHRoZSByZWNvcmQgdG8gaW5zZXJ0IGluIHRoZSBleGFjdCBmb3JtYXQgZGVz Y3JpYmVkIGluDQogICBTZWN0aW9uIDMuNi4gIEluIGFkZGl0aW9uLCB0aGVyZSBtYXkgYmUgb2Nj YXNpb25hbCByZXF1ZXN0cyBmcm9tIHRoZQ0KICAgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGZvciBh IHNwZWNpZmljIGV4dGVuc2lvbiB0byB1cGRhdGUgdGhlIGNvbnRhY3QNCiAgIGluZm9ybWF0aW9u IG9yIFVSTHMgaW4gdGhlIHJlY29yZC4gIFRoZXNlIHJlcXVlc3RzIE1VU1QgaW5jbHVkZSB0aGUN CiAgIGNvbXBsZXRlLCB1cGRhdGVkIHJlY29yZC4gIElBTkEgaXMgbm90IHJlc3BvbnNpYmxlIGZv ciB2YWxpZGF0aW5nIHRoZQ0KICAgaW5mb3JtYXRpb24gcHJvdmlkZWQsIG9ubHkgdGhhdCBpdCBp cyBwcm9wZXJseSBmb3JtYXR0ZWQuICBJdCBzaG91bGQNCiAgIHJlYXNvbmFibHkgYmUgc2VlbiB0 byBjb21lIGZyb20gdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBuYW1lZCBpbg0KICAgdGhlIHJl Y29yZCBwcmVzZW50IGluIHRoZSByZWdpc3RyeS4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSA0M10N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQog ICBUaGUgb25seSBzZWN1cml0eSBpc3N1ZSB0aGF0IGhhcyBiZWVuIHJhaXNlZCB3aXRoIGxhbmd1 YWdlIHRhZ3Mgc2luY2UNCiAgIHRoZSBwdWJsaWNhdGlvbiBvZiBSRkMgMTc2NiBbMjFdLCB3aGlj aCBzdGF0ZWQgdGhhdCAiU2VjdXJpdHkgaXNzdWVzDQogICBhcmUgYmVsaWV2ZWQgdG8gYmUgaXJy ZWxldmFudCB0byB0aGlzIG1lbW8iLCBpcyBhIGNvbmNlcm4gd2l0aA0KICAgbGFuZ3VhZ2UgaWRl bnRpZmllcnMgdXNlZCBpbiBjb250ZW50IG5lZ290aWF0aW9uIC0gdGhhdCB0aGV5IG1heSBiZQ0K ICAgdXNlZCB0byBpbmZlciB0aGUgbmF0aW9uYWxpdHkgb2YgdGhlIHNlbmRlciwgYW5kIHRodXMg aWRlbnRpZnkNCiAgIHBvdGVudGlhbCB0YXJnZXRzIGZvciBzdXJ2ZWlsbGFuY2UuDQoNCiAgIFRo aXMgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIGdlbmVyYWwgcHJvYmxlbSB0aGF0IGFueXRoaW5n IHNlbnQgaXMNCiAgIHZpc2libGUgdG8gdGhlIHJlY2VpdmluZyBwYXJ0eSBhbmQgcG9zc2libHkg dG8gdGhpcmQgcGFydGllcyBhcyB3ZWxsLg0KICAgSXQgaXMgdXNlZnVsIHRvIGJlIGF3YXJlIHRo YXQgc3VjaCBjb25jZXJucyBjYW4gZXhpc3QgaW4gc29tZSBjYXNlcy4NCg0KICAgVGhlIGV2YWx1 YXRpb24gb2YgdGhlIGV4YWN0IG1hZ25pdHVkZSBvZiB0aGUgdGhyZWF0LCBhbmQgYW55IHBvc3Np YmxlDQogICBjb3VudGVybWVhc3VyZXMsIGlzIGxlZnQgdG8gZWFjaCBhcHBsaWNhdGlvbiBwcm90 b2NvbCAoc2VlIEJDUCA3MiwNCiAgIFJGQyAgMzU1MiBbMTVdIGZvciBiZXN0IGN1cnJlbnQgcHJh Y3RpY2UgZ3VpZGFuY2Ugb24gc2VjdXJpdHkgdGhyZWF0cw0KICAgYW5kIGRlZmVuc2VzKS4NCg0K ICAgQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gb2YgdmFsaWQgc3VidGFncyBmb3IgYW4gZXh0 ZW5zaW9uIE1VU1QgYmUNCiAgIGF2YWlsYWJsZSBvdmVyIHRoZSBJbnRlcm5ldCwgaW1wbGVtZW50 YXRpb25zIFNIT1VMRCBOT1QgbWVjaGFuaWNhbGx5DQogICBkZXBlbmQgb24gaXQgYmVpbmcgYWx3 YXlzIGFjY2Vzc2libGUsIHRvIHByZXZlbnQgZGVuaWFsLW9mLXNlcnZpY2UNCiAgIGF0dGFja3Mu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAg ICAgICAgICAgW1BhZ2UgNDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQo3LiAgQ2hhcmFjdGVy IFNldCBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgc3ludGF4IGluIHRoaXMgZG9jdW1lbnQgcmVx dWlyZXMgdGhhdCBsYW5ndWFnZSB0YWdzIHVzZSBvbmx5IHRoZQ0KICAgY2hhcmFjdGVycyBBLVos IGEteiwgMC05LCBhbmQgSFlQSEVOLU1JTlVTLCB3aGljaCBhcmUgcHJlc2VudCBpbiBtb3N0DQog ICBjaGFyYWN0ZXIgc2V0cywgc28gdGhlIGNvbXBvc2l0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgc2hv dWxkIG5vdCBoYXZlDQogICBhbnkgY2hhcmFjdGVyIHNldCBpc3N1ZXMuDQoNCiAgIFJlbmRlcmlu ZyBvZiBjaGFyYWN0ZXJzIGJhc2VkIG9uIHRoZSBjb250ZW50IG9mIGEgbGFuZ3VhZ2UgdGFnIGlz IG5vdA0KICAgYWRkcmVzc2VkIGluIHRoaXMgbWVtby4gIEhpc3RvcmljYWxseSwgc29tZSBsYW5n dWFnZXMgaGF2ZSByZWxpZWQgb24NCiAgIHRoZSB1c2Ugb2Ygc3BlY2lmaWMgY2hhcmFjdGVyIHNl dHMgb3Igb3RoZXIgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8NCiAgIGluZmVyIGhvdyBhIHNwZWNp ZmljIGNoYXJhY3RlciBzaG91bGQgYmUgcmVuZGVyZWQgKG5vdGFibHkgdGhpcw0KICAgYXBwbGll cyB0byBsYW5ndWFnZSBhbmQgY3VsdHVyZSBzcGVjaWZpYyB2YXJpYXRpb25zIG9mIEhhbiBpZGVv Z3JhcGhzDQogICBhcyB1c2VkIGluIEphcGFuZXNlLCBDaGluZXNlLCBhbmQgS29yZWFuKS4gIFdo ZW4gbGFuZ3VhZ2UgdGFncyBhcmUNCiAgIGFwcGxpZWQgdG8gc3BhbnMgb2YgdGV4dCwgcmVuZGVy aW5nIGVuZ2luZXMgbWF5IHVzZSB0aGF0IGluZm9ybWF0aW9uDQogICBpbiBkZWNpZGluZyB3aGlj aCBmb250IHRvIHVzZSBpbiB0aGUgYWJzZW5jZSBvZiBvdGhlciBpbmZvcm1hdGlvbiwNCiAgIHBh cnRpY3VsYXJseSB3aGVyZSBsYW5ndWFnZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5nIHRyYWRpdGlv bnMgdXNlIHRoZQ0KICAgc2FtZSBjaGFyYWN0ZXJzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSA0 NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCjguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYNCg0K ICAgVGhlIG1haW4gZ29hbHMgZm9yIHRoaXMgcmV2aXNpb24gb2YgbGFuZ3VhZ2UgdGFncyB3ZXJl IHRoZSBmb2xsb3dpbmc6DQoNCiAgICpDb21wYXRpYmlsaXR5LiogQWxsIHZhbGlkIFJGQyAzMDY2 IGxhbmd1YWdlIHRhZ3MgIChpbmNsdWRpbmcgdGhvc2UNCiAgIGluIHRoZSBJQU5BIHJlZ2lzdHJ5 KSAgcmVtYWluIHZhbGlkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRodXMNCiAgIHRoZXJlIGlz IGNvbXBsZXRlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHdp dGgNCiAgIGV4aXN0aW5nIGNvbnRlbnQuICBJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBkZWZp bmVzIGxhbmd1YWdlIHRhZ3MNCiAgIGluIHN1Y2ggYXMgd2F5IGFzIHRvIGVuc3VyZSBmdXR1cmUg Y29tcGF0aWJpbGl0eSwgYW5kIHByb2Nlc3NvcnMNCiAgIGJhc2VkIHNvbGVseSBvbiB0aGUgUkZD IDMwNjYgQUJORiAoc3VjaCBhcyB0aG9zZSBkZXNjcmliZWQgaW4gWE1MDQogICBTY2hlbWEgdmVy c2lvbiAxLjAgWzE5XSkgd2lsbCBiZSBhYmxlIHRvIHByb2Nlc3MgdGFncyBkZXNjcmliZWQgYnkN CiAgIHRoaXMgZG9jdW1lbnQuDQoNCiAgICpTdGFiaWxpdHkuKiBCZWNhdXNlIG9mIHRoZSBjaGFu Z2VzIGluIHVuZGVybHlpbmcgSVNPIHN0YW5kYXJkcywgYQ0KICAgdmFsaWQgUkZDIDMwNjYgbGFu Z3VhZ2UgdGFnIG1heSBiZWNvbWUgaW52YWxpZCAob3IgaGF2ZSBpdHMgbWVhbmluZw0KICAgY2hh bmdlKSBhdCBhIGxhdGVyIGRhdGUuICBXaXRoIHNvIG11Y2ggb2YgdGhlIHdvcmxkJ3MgY29tcHV0 aW5nDQogICBpbmZyYXN0cnVjdHVyZSBkZXBlbmRlbnQgb24gbGFuZ3VhZ2UgdGFncywgdGhpcyBp cyBzaW1wbHkNCiAgIHVuYWNjZXB0YWJsZTogaXQgaW52YWxpZGF0ZXMgY29udGVudCB0aGF0IG1h eSBoYXZlIGFuIGV4dGVuc2l2ZQ0KICAgc2hlbGYtbGlmZS4gIEluIHRoaXMgc3BlY2lmaWNhdGlv biwgb25jZSBhIGxhbmd1YWdlIHRhZyBpcyB2YWxpZCwgaXQNCiAgIHJlbWFpbnMgdmFsaWQgZm9y ZXZlci4gIFByZXZpb3VzbHksIHRoZXJlIHdhcyBubyB3YXkgdG8gZGV0ZXJtaW5lDQogICB3aGVu IHR3byB0YWdzIHdlcmUgZXF1aXZhbGVudC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBh IHN0YWJsZQ0KICAgbWVjaGFuaXNtIGZvciBkb2luZyBzbywgdGhyb3VnaCB0aGUgdXNlIG9mIGNh bm9uaWNhbCBmb3Jtcy4gIFRoZXNlDQogICBhcmUgYWxzbyBzdGFibGUsIHNvIHRoYXQgaW1wbGVt ZW50YXRpb25zIGNhbiBkZXBlbmQgb24gdGhlIHVzZSBvZg0KICAgY2Fub25pY2FsIGZvcm1zIHRv IGFzc2VzcyBlcXVpdmFsZW5jeS4NCg0KICAgKlZhbGlkaXR5LiogIFRoZSBzdHJ1Y3R1cmUgb2Yg bGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQNCiAgIG1ha2VzIGl0IHBvc3Np YmxlIHRvIGRldGVybWluZSBpZiBhIHBhcnRpY3VsYXIgdGFnIGlzIHdlbGwtZm9ybWVkDQogICB3 aXRob3V0IHJlZ2FyZCBmb3IgdGhlIGFjdHVhbCBjb250ZW50IG9yICJtZWFuaW5nIiBvZiB0aGUg dGFnIGFzIGENCiAgIHdob2xlLiAgVGhpcyBpcyBpbXBvcnRhbnQgYmVjYXVzZSB0aGUgcmVnaXN0 cnkgYW5kIHVuZGVybHlpbmcNCiAgIHN0YW5kYXJkcyAgY2hhbmdlIG92ZXIgdGltZS4gIEluIGFk ZGl0aW9uLCBpdCBtdXN0IGJlIHBvc3NpYmxlIHRvDQogICBkZXRlcm1pbmUgaWYgYSB0YWcgaXMg dmFsaWQgKG9yIG5vdCkgZm9yIGEgZ2l2ZW4gcG9pbnQgaW4gdGltZSBpbg0KICAgb3JkZXIgIHRv IHByb3ZpZGUgcmVwcm9kdWNpYmxlLCB0ZXN0YWJsZSByZXN1bHRzLiAgVGhpcyBwcm9jZXNzIG11 c3QNCiAgIG5vdCBiZSBlcnJvci1wcm9uZTsgb3RoZXJ3aXNlIGV2ZW4gaW50ZWxsaWdlbnQgcGVv cGxlIHdpbGwgZ2VuZXJhdGUNCiAgIGltcGxlbWVudGF0aW9ucyB0aGF0IGdpdmUgZGlmZmVyZW50 IHJlc3VsdHMuICBUaGlzIHNwZWNpZmljYXRpb24NCiAgIHByb3ZpZGVzIGZvciB0aGF0IGJ5IGhh dmluZyBhIHNpbmdsZSBkYXRhIGZpbGUsIHdpdGggc3BlY2lmaWMNCiAgIHZlcnNpb25pbmcgaW5m b3JtYXRpb24sIHNvIHRoYXQgdGhlIHZhbGlkaXR5IG9mIGxhbmd1YWdlIHRhZ3MgYXQgYW55DQog ICBwb2ludCBpbiB0aW1lIGNhbiBiZSBwcmVjaXNlbHkgZGV0ZXJtaW5lZCAoaW5zdGVhZCBvZiBp bnRlcnBvbGF0aW5nDQogICB2YWx1ZXMgZnJvbSBtYW55IHNlcGFyYXRlIHNvdXJjZXMpLg0KDQog ICAqRXh0ZW5zaWJpbGl0eS4qIEl0IGlzIGltcG9ydGFudCB0byBiZSBhYmxlIHRvIGRpZmZlcmVu dGlhdGUgYmV0d2Vlbg0KICAgd3JpdHRlbiBmb3JtcyBvZiBsYW5ndWFnZSAtLSBmb3IgbWFueSBp bXBsZW1lbnRhdGlvbnMgdGhpcyBpcyBtb3JlDQogICBpbXBvcnRhbnQgdGhhbiBkaXN0aW5ndWlz aGluZyBiZXR3ZWVuIHNwb2tlbiB2YXJpYW50cyBvZiBhIGxhbmd1YWdlLg0KICAgTGFuZ3VhZ2Vz IGFyZSB3cml0dGVuIGluIGEgd2lkZSB2YXJpZXR5IG9mIGRpZmZlcmVudCBzY3JpcHRzLCBzbyB0 aGlzDQogICBkb2N1bWVudCBwcm92aWRlcyBmb3IgdGhlIGdlbmVyYXRpdmUgdXNlIG9mIElTTyAx NTkyNCBzY3JpcHQgY29kZXMuDQogICBMaWtlIHRoZSBnZW5lcmF0aXZlIHVzZSBvZiBJU08gbGFu Z3VhZ2UgYW5kIGNvdW50cnkgY29kZXMgaW4gUkZDDQogICAzMDY2LCB0aGlzIGFsbG93cyBjb21i aW5hdGlvbnMgdG8gYmUgcHJvZHVjZWQgd2l0aG91dCByZXNvcnRpbmcgdG8NCiAgIHRoZSByZWdp c3RyYXRpb24gcHJvY2Vzcy4gIFRoZSBhZGRpdGlvbiBvZiBVTiBjb2RlcyBwcm92aWRlcyBmb3Ig dGhlDQogICBnZW5lcmF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgd2l0aCByZWdpb25hbCBzY29wZSwg d2hpY2ggaXMgYWxzbw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3Zl bWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUN Cg0KDQogICByZXF1aXJlZCBmb3IgaW5mb3JtYXRpb24gdGVjaG5vbG9neS4NCg0KICAgVGhlIHJl Y2FzdCBvZiB0aGUgcmVnaXN0cnkgZnJvbSBjb250YWluaW5nIHdob2xlIGxhbmd1YWdlIHRhZ3Mg dG8NCiAgIHN1YnRhZ3MgaXMgYSBrZXkgcGFydCBvZiB0aGlzLiAgQW4gaW1wb3J0YW50IGZlYXR1 cmUgb2YgUkZDIDMwNjYgd2FzDQogICB0aGF0IGl0IGFsbG93ZWQgZ2VuZXJhdGl2ZSB1c2Ugb2Yg c3VidGFncy4gIFRoaXMgYWxsb3dzIHBlb3BsZSB0bw0KICAgbWVhbmluZ2Z1bGx5IHVzZSBnZW5l cmF0ZWQgdGFncywgd2l0aG91dCB0aGUgZGVsYXlzIGluIHJlZ2lzdGVyaW5nDQogICB3aG9sZSB0 YWdzLCBhbmQgdGhlIGJ1cmRlbiBvbiB0aGUgcmVnaXN0cnkgb2YgaGF2aW5nIHRvIHN1cHBseSBh bGwgb2YNCiAgIHRoZSBjb21iaW5hdGlvbnMgdGhhdCBwZW9wbGUgbWF5IGZpbmQgdXNlZnVsLg0K DQogICBCZWNhdXNlIG9mIHRoZSB3aWRlc3ByZWFkIHVzZSBvZiBsYW5ndWFnZSB0YWdzLCBpdCBp cyBwb3RlbnRpYWxseQ0KICAgZGlzcnVwdGl2ZSB0byBoYXZlIHBlcmlvZGljIHJldmlzaW9ucyBv ZiB0aGUgY29yZSBzcGVjaWZpY2F0aW9uLA0KICAgZGVzcGl0ZSBkZW1vbnN0cmF0ZWQgbmVlZC4g IFRoZSBleHRlbnNpb24gbWVjaGFuaXNtIHByb3ZpZGVzIGZvciBhDQogICB3YXkgZm9yIGluZGVw ZW5kZW50IFJGQ3MgdG8gZGVmaW5lIGV4dGVuc2lvbnMgdG8gbGFuZ3VhZ2UgdGFncy4NCiAgIFRo ZXNlIGV4dGVuc2lvbnMgaGF2ZSBhIHZlcnkgY29uc3RyYWluZWQsIHdlbGwtZGVmaW5lZCBzdHJ1 Y3R1cmUgdG8NCiAgIHByZXZlbnQgZXh0ZW5zaW9ucyBmcm9tIGludGVyZmVyaW5nIHdpdGggaW1w bGVtZW50YXRpb25zIG9mIGxhbmd1YWdlDQogICB0YWdzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dC4gIFRoZSBkb2N1bWVudCBhbHNvIGFudGljaXBhdGVzDQogICBmZWF0dXJlcyBvZiBJU08gNjM5 LTMgd2l0aCB0aGUgYWRkaXRpb24gb2YgdGhlIGV4dGVuZGVkIGxhbmd1YWdlDQogICBzdWJ0YWdz LCBhcyB3ZWxsIGFzIHRoZSBwb3NzaWJpbGl0eSBvZiBvdGhlciBJU08gNjM5IHBhcnRzIGJlY29t aW5nDQogICB1c2VmdWwgZm9yIHRoZSBmb3JtYXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBpbiB0aGUg ZnV0dXJlLiAgVGhlIHVzZSBhbmQNCiAgIGRlZmluaXRpb24gb2YgcHJpdmF0ZSB1c2UgdGFncyBo YXMgYWxzbyBiZWVuIG1vZGlmaWVkLCB0byBhbGxvdw0KICAgcGVvcGxlIHRvIG1vdmUgYXMgbXVj aCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSBvdXQgb2YgcHJpdmF0ZSB1c2UNCiAgIHRhZ3MsIGFu ZCBpbnRvIHRoZSByZWd1bGFyIHN0cnVjdHVyZS4gIFRoZSBnb2FsIGlzIHRvIGRyYW1hdGljYWxs eQ0KICAgcmVkdWNlIHRoZSBuZWVkIHRvIHByb2R1Y2UgYSByZXZpc2lvbiBvZiB0aGlzIGRvY3Vt ZW50IGluIHRoZSBmdXR1cmUuDQoNCiAgIFRoZSBzcGVjaWZpYyBjaGFuZ2VzIGluIHRoaXMgZG9j dW1lbnQgdG8gbWVldCB0aGVzZSBnb2FscyBhcmU6DQoNCiAgIG8gIERlZmluZXMgdGhlIEFCTkYg YW5kIHJ1bGVzIGZvciBzdWJ0YWdzIHNvIHRoYXQgdGhlIGNhdGVnb3J5IG9mIGFsbA0KICAgICAg c3VidGFncyBjYW4gYmUgZGV0ZXJtaW5lZCB3aXRob3V0IHJlZmVyZW5jZSB0byB0aGUgcmVnaXN0 cnkuDQoNCiAgIG8gIEFkZHMgdGhlIGNvbmNlcHQgb2Ygd2VsbC1mb3JtZWQgdnMuIHZhbGlkYXRp bmcgcHJvY2Vzc29ycywNCiAgICAgIGRlZmluaW5nIHRoZSBydWxlcyBieSB3aGljaCBhbiBpbXBs ZW1lbnRhdGlvbiBjYW4gY2xhaW0gdG8gYmUgb25lDQogICAgICBvciB0aGUgb3RoZXIuDQoNCiAg IG8gIFJlcGxhY2VzIHRoZSBJQU5BIGxhbmd1YWdlIHRhZyByZWdpc3RyeSB3aXRoIGEgbGFuZ3Vh Z2Ugc3VidGFnDQogICAgICByZWdpc3RyeSB0aGF0IHByb3ZpZGVzIGEgY29tcGxldGUgbGlzdCBv ZiB2YWxpZCBzdWJ0YWdzIGluIHRoZQ0KICAgICAgSUFOQSByZWdpc3RyeS4gIFRoaXMgYWxsb3dz IGZvciByb2J1c3QgaW1wbGVtZW50YXRpb24gYW5kIGVhc2Ugb2YNCiAgICAgIG1haW50ZW5hbmNl LiAgVGhlIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSBiZWNvbWVzIHRoZSBjYW5vbmljYWwNCiAg ICAgIHNvdXJjZSBmb3IgZm9ybWluZyBsYW5ndWFnZSB0YWdzLg0KDQogICBvICBQcm92aWRlcyBh IHByb2Nlc3MgdGhhdCBndWFyYW50ZWVzIHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLCBieQ0K ICAgICAgaGFuZGxpbmcgcmV1c2Ugb2YgdmFsdWVzIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgYW5k IElTTyAzMTY2IGluDQogICAgICB0aGUgZXZlbnQgdGhhdCB0aGV5IHJlZ2lzdGVyIGEgcHJldmlv dXNseSB1c2VkIHZhbHVlIGZvciBhIG5ldw0KICAgICAgcHVycG9zZS4NCg0KICAgbyAgQWxsb3dz IElTTyAxNTkyNCBzY3JpcHQgY29kZSBzdWJ0YWdzIGFuZCBhbGxvd3MgdGhlbSB0byBiZSB1c2Vk DQogICAgICBnZW5lcmF0aXZlbHkuICBEZWZpbmVzIGEgbWV0aG9kIGZvciBpbmRpY2F0aW5nIGlu IHRoZSByZWdpc3RyeQ0KICAgICAgd2hlbiBzY3JpcHQgc3VidGFncyBhcmUgbmVjZXNzYXJ5IGZv ciBhIGdpdmVuIGxhbmd1YWdlIHRhZy4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNDddDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg ICAgTWF5IDIwMDUNCg0KDQogICBvICBBZGRzIHRoZSBjb25jZXB0IG9mIGEgdmFyaWFudCBzdWJ0 YWcgYW5kIGFsbG93cyB2YXJpYW50cyB0byBiZQ0KICAgICAgdXNlZCBnZW5lcmF0aXZlbHkuDQoN CiAgIG8gIEFkZHMgdGhlIGFiaWxpdHkgdG8gdXNlIGEgY2xhc3Mgb2YgVU4gTS40OSB0YWdzIGZv ciAgc3VwcmEtDQogICAgICBuYXRpb25hbCByZWdpb25zIGFuZCB0byByZXNvbHZlIGNvbmZsaWN0 cyBpbiB0aGUgYXNzaWdubWVudCBvZiBJU08NCiAgICAgIDMxNjYgY29kZXMuDQoNCiAgIG8gIERl ZmluZXMgdGhlIHByaXZhdGUtdXNlIHRhZ3MgaW4gSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNP IDMxNjYNCiAgICAgIGFzIHRoZSBtZWNoYW5pc20gZm9yIGNyZWF0aW5nIHByaXZhdGUtdXNlIGxh bmd1YWdlLCBzY3JpcHQsIGFuZA0KICAgICAgcmVnaW9uIHN1YnRhZ3MgcmVzcGVjdGl2ZWx5Lg0K DQogICBvICBBZGRzIGEgd2VsbC1kZWZpbmVkIGV4dGVuc2lvbiBtZWNoYW5pc20uDQoNCiAgIG8g IERlZmluZXMgYW4gZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnLCBwb3NzaWJseSBmb3IgdXNlIHdp dGggY2VydGFpbg0KICAgICAgYW50aWNpcGF0ZWQgZmVhdHVyZXMgb2YgSVNPIDYzOS0zLg0KDQog ICBFZCBOb3RlOiBUaGUgZm9sbG93aW5nIGl0ZW1zIGFyZSBwcm92aWRlZCBmb3IgdGhlIGNvbnZl bmllbmNlIG9mDQogICByZXZpZXdlcnMgYW5kIHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSBmaW5h bCBkb2N1bWVudC4NCg0KICAgQ2hhbmdlcyBiZXR3ZWVuIGRyYWZ0LWlldGYtbHRydS1yZWdpc3Ry eS0wMSBhbmQgdGhpcyB2ZXJzaW9uIGFyZToNCg0KICAgbyAgTWlub3IgdXBkYXRlcyB0byB0aGUg Y2hhbmdlcyBzZWN0aW9uICh0aGUgdGV4dCBqdXN0IGFib3ZlKSB0bw0KICAgICAgcmVmbGVjdCB2 YXJpb3VzIHVwZGF0ZXMgaW4gdGhlIFdHIGRyYWZ0cyAoQS5QaGlsbGlwcykNCg0KICAgbyAgTWlu b3IgY2hhbmdlIHRvIHRoZSBzZWN0aW9uIG9uIHRoZSBleHRlbnNpb25zIHJlZ2lzdHJ5IChiZWNh dXNlDQogICAgICB0aGVyZSBjYW4gYmUgMzUsIG5vdCAyNSwgZW50cmllcyBtYXhpbXVtLiAgKEQu RXdlbGwpDQoNCiAgIG8gIENoYW5nZWQgIlNIT1VMRCBOT1QgcGVybWl0IGEgc3VidGFnIHRvIGJl IGRpdmlkZWQiIHRvIE1VU1QgTk9ULg0KICAgICAgKCM5NDQpIChSLlByZXN1aG4pDQoNCiAgIG8g IEFkZGVkIHRleHQgdG8gU2VjdGlvbiAzLjEgYW5kIFNlY3Rpb24gNC4xIGRlc2NyaWJpbmcgdGhl IHJhdGlvbmFsZQ0KICAgICAgZm9yIFN1cHByZXNzLVNjcmlwdC4gIEJvdGggc2VudGVuY2VzIGFy ZSBzbGlnaHQgcmV3b3JkaW5ncyBvZiB0aGlzDQogICAgICB0ZXh0IHN1Z2dlc3RlZCBpbiB0aGUg ZW1haWwgdGhyZWFkOiAiVGhpcyBmaWVsZCBoZWxwcyBlbnN1cmUNCiAgICAgIGdyZWF0ZXIgY29t cGF0aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFnZSB0YWdzIGdlbmVyYXRlZA0KICAgICAgYWNj b3JkaW5nIHRvIHRoZSBydWxlcyBpbiB0aGlzIGRvY3VtZW50IGFuZCBsYW5ndWFnZSB0YWdzIGFu ZCB0YWcNCiAgICAgIHByb2Nlc3NvcnMgb3IgY29uc3VtZXJzIGJhc2VkIG9uIFJGQyAzMDY2LiIg KCM5NTQpIChGLkVsbGVybWFubiwNCiAgICAgIEEuUGhpbGxpcHMpDQoNCiAgIG8gIEFkZGVkIHRl eHQgYWJvdXQgY2FzZSBmb2xkaW5nIGR1cmluZyBjYW5vbmljYWxpemF0aW9uLiAgVGhpcyBhbHNv DQogICAgICBpbmNsdWRlcyBydWxlcyBpbiBTZWN0aW9uIDMuMiBmb3IgY2FzaW5nIG9mIHJlZ2lz dHJ5IGVudHJpZXMsIGFzDQogICAgICB3ZWxsIHRoZSBpbnNlcnRpb24gb2YgdGhlIHRleHQgcGVy bWl0dGluZyBjYXNlIG5vcm1hbGl6YXRpb24gaW4NCiAgICAgIFNlY3Rpb24gNC4zIGFuZCB0aGUg d2FybmluZyBhYm91dCBsb2NhbGUtc3BlY2lmaWMgY2FzaW5nDQogICAgICBvcGVyYXRpb25zIGlu IHRoZSBzYW1lIHNlY3Rpb24uICgjOTg1KSAoRi5FbGxlcm1hbm4sIEouQ293YW4sDQogICAgICBB LlBoaWxsaXBzKQ0KDQogICBvICBGaXhlZCB0aGUgcmVmZXJlbmNlIHRvIENhbm9uaWNhbC1WYWx1 ZSBpbiBTZWN0aW9uIDQuMy4NCiAgICAgIChBLlBoaWxsaXBzKQ0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFn ZSA0OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgIG8gIEluIFNlY3Rpb24gMy40LCBjaGFu Z2VkIHRoZSByZWZlcmVuY2UgZnJvbSB0aGUgc3VidGFnICdudicgdG8gdGhlDQogICAgICB0YWcg Im52IiB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIHdvcmRpbmcgaW4gU2VjdGlvbiAzLjEuIChw YXJ0DQogICAgICBvZiAjOTU0KSAoRC5Fd2VsbCkNCg0KICAgbyAgQWRkZWQgbWlzc2luZyB3b3Jk ICd0aGF0JyBpbiBTZWN0aW9uIDMuNiAoQS5QaGlsbGlwcykNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAy MCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQo5 LiAgUmVmZXJlbmNlcw0KDQo5LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFsxXSAgIElu dGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gNjM5LQ0K ICAgICAgICAgMToyMDAyLCBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9m IGxhbmd1YWdlcyAtLQ0KICAgICAgICAgUGFydCAxOiBBbHBoYS0yIGNvZGUiLCBJU08gU3RhbmRh cmQgNjM5LCAyMDAyLg0KDQogICBbMl0gICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3Ig U3RhbmRhcmRpemF0aW9uLCAiSVNPIDYzOS0yOjE5OTgNCiAgICAgICAgIC0gQ29kZXMgZm9yIHRo ZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBsYW5ndWFnZXMgLS0gUGFydCAyOg0KICAgICAg ICAgQWxwaGEtMyBjb2RlIC0gZWRpdGlvbiAxIiwgQXVndXN0IDE5ODguDQoNCiAgIFszXSAgIElT TyBUQzQ2L1dHMywgIklTTyAxNTkyNDoyMDAzIChFL0YpIC0gQ29kZXMgZm9yIHRoZQ0KICAgICAg ICAgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2Ygc2NyaXB0cyIsIEphbnVhcnkgMjAwNC4NCg0K ICAgWzRdICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwg IkNvZGVzIGZvciB0aGUNCiAgICAgICAgIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50 cmllcywgM3JkIGVkaXRpb24iLA0KICAgICAgICAgSVNPIFN0YW5kYXJkIDMxNjYsIEF1Z3VzdCAx OTg4Lg0KDQogICBbNV0gICBTdGF0aXN0aWNhbCBEaXZpc2lvbiwgVW5pdGVkIE5hdGlvbnMsICJT dGFuZGFyZCBDb3VudHJ5IG9yIEFyZWENCiAgICAgICAgIENvZGVzIGZvciBTdGF0aXN0aWNhbCBV c2UiLCBVTiBTdGFuZGFyZCBDb3VudHJ5IG9yIEFyZWEgQ29kZXMNCiAgICAgICAgIGZvciBTdGF0 aXN0aWNhbCBVc2UsIFJldmlzaW9uIDQgKFVuaXRlZCBOYXRpb25zIHB1YmxpY2F0aW9uLA0KICAg ICAgICAgU2FsZXMgTm8uIDk4LlhWSUkuOSwgSnVuZSAxOTk5Lg0KDQogICBbNl0gICBJbnRlcm5h dGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPL0lFQyAxMDY0Ni0N CiAgICAgICAgIDE6MjAwMC4gSW5mb3JtYXRpb24gdGVjaG5vbG9neSAtLSBVbml2ZXJzYWwgTXVs dGlwbGUtT2N0ZXQNCiAgICAgICAgIENvZGVkIENoYXJhY3RlciBTZXQgKFVDUykgLS0gUGFydCAx OiBBcmNoaXRlY3R1cmUgYW5kIEJhc2ljDQogICAgICAgICBNdWx0aWxpbmd1YWwgUGxhbmUgYW5k IElTTy9JRUMgMTA2NDYtMjoyMDAxLiBJbmZvcm1hdGlvbg0KICAgICAgICAgdGVjaG5vbG9neSAt LSBVbml2ZXJzYWwgTXVsdGlwbGUtT2N0ZXQgQ29kZWQgQ2hhcmFjdGVyIFNldA0KICAgICAgICAg KFVDUykgLS0gUGFydCAyOiBTdXBwbGVtZW50YXJ5IFBsYW5lcywgYXMsIGZyb20gdGltZSB0byB0 aW1lLA0KICAgICAgICAgYW1lbmRlZCwgcmVwbGFjZWQgYnkgYSBuZXcgZWRpdGlvbiBvciBleHBh bmRlZCBieSB0aGUgYWRkaXRpb24NCiAgICAgICAgIG9mIG5ldyBwYXJ0cyIsIDIwMDAuDQoNCiAg IFs3XSAgIENyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3lu dGF4DQogICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIsIGRyYWZ0LWNyb2NrZXItYWJuZi1y ZmMyMjM0YmlzLTAwICh3b3JrDQogICAgICAgICBpbiBwcm9ncmVzcyksIE1hcmNoIDIwMDUuDQoN CiAgIFs4XSAgIEJyYWRuZXIsIFMuLCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0t IFJldmlzaW9uIDMiLA0KICAgICAgICAgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuDQoN CiAgIFs5XSAgIEhvdmV5LCBSLiBhbmQgUy4gQnJhZG5lciwgIlRoZSBPcmdhbml6YXRpb25zIElu dm9sdmVkIGluIHRoZQ0KICAgICAgICAgSUVURiBTdGFuZGFyZHMgUHJvY2VzcyIsIEJDUCAxMSwg UkZDIDIwMjgsIE9jdG9iZXIgMTk5Ni4NCg0KICAgWzEwXSAgQnJhZG5lciwgUy4sICJLZXkgd29y ZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50DQogICAgICAgICBMZXZl bHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbMTFdICBOYXJ0ZW4sIFQu IGFuZCBILiBBbHZlc3RyYW5kLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5BDQogICAg ICAgICBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJGQyAyNDM0LA0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAg ICAgICAgICAgICAgW1BhZ2UgNTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQogICAgICAgICBP Y3RvYmVyIDE5OTguDQoNCiAgIFsxMl0gIEhvZmZtYW4sIFAuIGFuZCBGLiBZZXJnZWF1LCAiVVRG LTE2LCBhbiBlbmNvZGluZyBvZiBJU08gMTA2NDYiLA0KICAgICAgICAgUkZDIDI3ODEsIEZlYnJ1 YXJ5IDIwMDAuDQoNCiAgIFsxM10gIENhcnBlbnRlciwgQi4sIEJha2VyLCBGLiwgYW5kIE0uIFJv YmVydHMsICJNZW1vcmFuZHVtIG9mDQogICAgICAgICBVbmRlcnN0YW5kaW5nIENvbmNlcm5pbmcg dGhlIFRlY2huaWNhbCBXb3JrIG9mIHRoZSBJbnRlcm5ldA0KICAgICAgICAgQXNzaWduZWQgTnVt YmVycyBBdXRob3JpdHkiLCBSRkMgMjg2MCwgSnVuZSAyMDAwLg0KDQogICBbMTRdICBLbHluZSwg Ry4gYW5kIEMuIE5ld21hbiwgIkRhdGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0Og0KICAgICAg ICAgVGltZXN0YW1wcyIsIFJGQyAzMzM5LCBKdWx5IDIwMDIuDQoNCiAgIFsxNV0gIFJlc2Nvcmxh LCBFLiBhbmQgQi4gS29ydmVyLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBSRkMgVGV4dCBvbg0K ICAgICAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLCBCQ1AgNzIsIFJGQyAzNTUyLCBKdWx5 IDIwMDMuDQoNCjkuMiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbMTZdICBJU08gNjM5 IEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZSwgIklTTyA2MzkgSm9pbnQgQWR2aXNvcnkNCiAgICAg ICAgIENvbW1pdHRlZTogIFdvcmtpbmcgcHJpbmNpcGxlcyBmb3IgSVNPIDYzOSBtYWludGVuYW5j ZSIsDQogICAgICAgICBNYXJjaCAyMDAwLA0KICAgICAgICAgPGh0dHA6Ly93d3cubG9jLmdvdi9z dGFuZGFyZHMvaXNvNjM5LTIvaXNvNjM5amFjX24zci5odG1sPi4NCg0KICAgWzE3XSAgUmF5bW9u ZCwgRS4sICJUaGUgQXJ0IG9mIFVuaXggUHJvZ3JhbW1pbmciLCAyMDAzLg0KDQogICBbMThdICBC cmF5IChldCBhbCksIFQuLCAiRXh0ZW5zaWJsZSBNYXJrdXAgTGFuZ3VhZ2UgKFhNTCkgMS4wIiwN CiAgICAgICAgIDAyIDIwMDQuDQoNCiAgIFsxOV0gIEJpcm9uLCBQLiwgRWQuIGFuZCBBLiBNYWxo b3RyYSwgRWQuLCAiWE1MIFNjaGVtYSBQYXJ0IDI6DQogICAgICAgICBEYXRhdHlwZXMgU2Vjb25k IEVkaXRpb24iLCAxMCAyMDA0LCA8DQogICAgICAgICBodHRwOi8vd3d3LnczLm9yZy9UUi94bWxz Y2hlbWEtMi8+Lg0KDQogICBbMjBdICBVbmljb2RlIENvbnNvcnRpdW0sICJUaGUgVW5pY29kZSBD b25zb3J0aXVtLiBUaGUgVW5pY29kZQ0KICAgICAgICAgU3RhbmRhcmQsIFZlcnNpb24gNC4xLjAs IGRlZmluZWQgYnk6IFRoZSBVbmljb2RlIFN0YW5kYXJkLA0KICAgICAgICAgVmVyc2lvbiA0LjAg KEJvc3RvbiwgTUEsIEFkZGlzb24tV2VzbGV5LCAyMDAzLiBJU0JOIDAtMzIxLQ0KICAgICAgICAg MTg1NzgtMSksIGFzIGFtZW5kZWQgYnkgVW5pY29kZSA0LjAuMQ0KICAgICAgICAgKGh0dHA6Ly93 d3cudW5pY29kZS5vcmcvdmVyc2lvbnMvVW5pY29kZTQuMC4xKSBhbmQgYnkgVW5pY29kZQ0KICAg ICAgICAgNC4xLjAgKGh0dHA6Ly93d3cudW5pY29kZS5vcmcvdmVyc2lvbnMvVW5pY29kZTQuMS4w KS4iLA0KICAgICAgICAgTWFyY2ggMjAwNS4NCg0KICAgWzIxXSAgQWx2ZXN0cmFuZCwgSC4sICJU YWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2YgTGFuZ3VhZ2VzIiwNCiAgICAgICAgIFJGQyAx NzY2LCBNYXJjaCAxOTk1Lg0KDQogICBbMjJdICBGcmVlZCwgTi4gYW5kIEsuIE1vb3JlLCAiTUlN RSBQYXJhbWV0ZXIgVmFsdWUgYW5kIEVuY29kZWQgV29yZA0KICAgICAgICAgRXh0ZW5zaW9uczog Q2hhcmFjdGVyIFNldHMsIExhbmd1YWdlcywgYW5kIENvbnRpbnVhdGlvbnMiLA0KICAgICAgICAg UkZDIDIyMzEsIE5vdmVtYmVyIDE5OTcuDQoNCiAgIFsyM10gIEFsdmVzdHJhbmQsIEguLCAiVGFn cyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mIExhbmd1YWdlcyIsDQogICAgICAgICBCQ1AgNDcs IFJGQyAzMDY2LCBKYW51YXJ5IDIwMDEuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSA1MV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg ICBNYXkgMjAwNQ0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBBZGRpc29uIFBoaWxsaXBz IChlZGl0b3IpDQogICBRdWVzdCBTb2Z0d2FyZQ0KDQogICBFbWFpbDogYWRkaXNvbi5waGlsbGlw c0BxdWVzdC5jb20NCg0KDQogICBNYXJrIERhdmlzIChlZGl0b3IpDQogICBJQk0NCg0KICAgRW1h aWw6IG1hcmsuZGF2aXNAdXMuaWJtLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1Bh Z2UgNTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQpBcHBlbmRpeCBBLiAgQWNrbm93bGVkZ2Vt ZW50cw0KDQogICBBbnkgbGlzdCBvZiBjb250cmlidXRvcnMgaXMgYm91bmQgdG8gYmUgaW5jb21w bGV0ZTsgcGxlYXNlIHJlZ2FyZCB0aGUNCiAgIGZvbGxvd2luZyBhcyBvbmx5IGEgc2VsZWN0aW9u IGZyb20gdGhlIGdyb3VwIG9mIHBlb3BsZSB3aG8gaGF2ZQ0KICAgY29udHJpYnV0ZWQgdG8gbWFr ZSB0aGlzIGRvY3VtZW50IHdoYXQgaXQgaXMgdG9kYXkuDQoNCiAgIFRoZSBjb250cmlidXRvcnMg dG8gUkZDIDMwNjYgYW5kIFJGQyAxNzY2LCB0aGUgcHJlY3Vyc29ycyBvZiB0aGlzDQogICBkb2N1 bWVudCwgbWFkZSBlbm9ybW91cyBjb250cmlidXRpb25zIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkg dG8gdGhpcw0KICAgZG9jdW1lbnQgYW5kIGFyZSBnZW5lcmFsbHkgcmVzcG9uc2libGUgZm9yIHRo ZSBzdWNjZXNzIG9mIGxhbmd1YWdlDQogICB0YWdzLg0KDQogICBUaGUgZm9sbG93aW5nIHBlb3Bs ZSAoaW4gYWxwaGFiZXRpY2FsIG9yZGVyKSBjb250cmlidXRlZCB0byB0aGlzDQogICBkb2N1bWVu dCBvciB0byBSRkNzIDE3NjYgYW5kIDMwNjY6DQoNCiAgIEdsZW5uIEFkYW1zLCBIYXJhbGQgVHZl aXQgQWx2ZXN0cmFuZCwgVGltIEJlcm5lcnMtTGVlLCBNYXJjIEJsYW5jaGV0LA0KICAgTmF0aGFu aWVsIEJvcmVuc3RlaW4sIEVyaWMgQnJ1bm5lciwgU2VhbiBNLiBCdXJrZSwgTS5ULiBDYXJyYXNj bw0KICAgQmVuaXRleiwgSmVyZW15IENhcnJvbGwsIEpvaG4gQ2xld3MsIEppbSBDb25rbGluLCBQ ZXRlciBDb25zdGFibGUsDQogICBKb2huIENvd2FuLCBNYXJrIENyaXNwaW4sIERhdmUgQ3JvY2tl ciwgTWFydGluIER1ZXJzdCwgRnJhbmsNCiAgIEVsbGVybWFuLCBNaWNoYWVsIEV2ZXJzb24sIERv dWcgRXdlbGwsIE5lZCBGcmVlZCwgVGltIEdvb2R3aW4sIERpcmstDQogICBXaWxsZW0gdmFuIEd1 bGlrLCBNYXJpb24gR3VubiwgSm9lbCBIYWxwcmVuLCBFbGxpb3R0ZSBSdXN0eSBIYXJvbGQsDQog ICBQYXVsIEhvZmZtYW4sIFNjb3R0IEhvbGxlbmJlY2ssIFJpY2hhcmQgSXNoaWRhLCBPbGxlIEph cm5lZm9ycywgS2VudA0KICAgS2FybHNzb24sIEpvaG4gS2xlbnNpbiwgQWxhaW4gTGFCb250ZSwg RXJpYyBNYWRlciwgSXJhIE1jRG9uYWxkLA0KICAgS2VpdGggTW9vcmUsIENocmlzIE5ld21hbiwg TWFzYXRha2EgT2h0YSwgUmFuZHkgUHJlc3VobiwgR2VvcmdlDQogICBSaG90ZW4sIE1hcmt1cyBT Y2hlcmVyLCBLZWxkIEpvcm4gU2ltb25zZW4sIFRoaWVycnkgU291cmJpZXIsIE90dG8NCiAgIFN0 b2x6LCBUZXggVGV4aW4sIEFuZHJlYSBWaW5lLCBSaHlzIFdlYXRoZXJsZXksIE1pc2hhIFdvbGYs IEZyYW5jb2lzDQogICBZZXJnZWF1IGFuZCBtYW55LCBtYW55IG90aGVycy4NCg0KICAgVmVyeSBz cGVjaWFsIHRoYW5rcyBtdXN0IGdvIHRvIEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCB3aG8NCiAg IG9yaWdpbmF0ZWQgUkZDcyAxNzY2IGFuZCAzMDY2LCBhbmQgd2l0aG91dCB3aG9tIHRoaXMgZG9j dW1lbnQgd291bGQNCiAgIG5vdCBoYXZlIGJlZW4gcG9zc2libGUuICBTcGVjaWFsIHRoYW5rcyBt dXN0IGdvIHRvIE1pY2hhZWwgRXZlcnNvbiwNCiAgIHdobyBoYXMgc2VydmVkIGFzIGxhbmd1YWdl IHRhZyByZXZpZXdlciBmb3IgYWxtb3N0IHRoZSBjb21wbGV0ZQ0KICAgcGVyaW9kIHNpbmNlIHRo ZSBwdWJsaWNhdGlvbiBvZiBSRkMgMTc2Ni4gIFNwZWNpYWwgdGhhbmtzIHRvIERvdWcNCiAgIEV3 ZWxsLCBmb3IgaGlzIHByb2R1Y3Rpb24gb2YgdGhlIGZpcnN0IGNvbXBsZXRlIHN1YnRhZyByZWdp c3RyeSwgYW5kDQogICBoaXMgd29yayBpbiBwcm9kdWNpbmcgYSB0ZXN0IHBhcnNlciBmb3IgdmVy aWZ5aW5nIGxhbmd1YWdlIHRhZ3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAg ICAgICAgW1BhZ2UgNTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUNCg0KDQpBcHBlbmRpeCBCLiAgRXhh bXBsZXMgb2YgTGFuZ3VhZ2UgVGFncyAoSW5mb3JtYXRpdmUpDQoNCiAgIFNpbXBsZSBsYW5ndWFn ZSBzdWJ0YWc6DQoNCiAgICAgIGRlIChHZXJtYW4pDQoNCiAgICAgIGZyIChGcmVuY2gpDQoNCiAg ICAgIGphIChKYXBhbmVzZSkNCg0KICAgICAgaS1lbm9jaGlhbiAoZXhhbXBsZSBvZiBhIGdyYW5k ZmF0aGVyZWQgdGFnKQ0KDQogICBMYW5ndWFnZSBzdWJ0YWcgcGx1cyBTY3JpcHQgc3VidGFnOg0K DQogICAgICB6aC1IYW50IChDaGluZXNlIHdyaXR0ZW4gdXNpbmcgdGhlIFRyYWRpdGlvbmFsIENo aW5lc2Ugc2NyaXB0KQ0KDQogICAgICB6aC1IYW5zIChDaGluZXNlIHdyaXR0ZW4gdXNpbmcgdGhl IFNpbXBsaWZpZWQgQ2hpbmVzZSBzY3JpcHQpDQoNCiAgICAgIHNyLUN5cmwgKFNlcmJpYW4gd3Jp dHRlbiB1c2luZyB0aGUgIEN5cmlsbGljIHNjcmlwdCkNCg0KICAgICAgc3ItTGF0biAoU2VyYmlh biB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQpDQoNCiAgIExhbmd1YWdlLVNjcmlwdC1S ZWdpb246DQoNCiAgICAgIHpoLUhhbnMtQ04gKENoaW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUgU2lt bGlmaWVkIHNjcmlwdCBhcyB1c2VkIGluDQogICAgICBtYWlubGFuZCBDaGluYSkNCg0KICAgICAg c3ItTGF0bi1DUyAoU2VyYmlhbiB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQgYXMgdXNl ZCBpbg0KICAgICAgU2VyYmlhIGFuZCBNb250ZW5lZ3JvKQ0KDQogICBMYW5ndWFnZS1WYXJpYW50 Og0KDQogICAgICBlbi1ib29udCAoQm9vbnRsaW5nIGRpYWxlY3Qgb2YgRW5nbGlzaCkNCg0KICAg ICAgZW4tc2NvdXNlIChTY291c2UgZGlhbGVjdCBvZiBFbmdsaXNoKQ0KDQogICBMYW5ndWFnZS1S ZWdpb24tVmFyaWFudDoNCg0KICAgICAgZW4tR0Itc2NvdXNlIChTY291c2UgZGlhbGVjdCBvZiBF bmdsaXNoIGFzIHVzZWQgaW4gdGhlIFVLKQ0KDQogICBMYW5ndWFnZS1TY3JpcHQtUmVnaW9uLVZh cmlhbnQ6DQoNCiAgICAgIHNsLUxhdG4tSVQtbmVkaXMgKE5hZGl6YSBkaWFsZWN0IG9mIFNsb3Zl bmlhbiB3cml0dGVuIHVzaW5nIHRoZQ0KICAgICAgTGF0aW4gc2NyaXB0IGFzIHVzZWQgaW4gSXRh bHkuICBOb3RlIHRoYXQgdGhpcyB0YWcgaXMgbm90DQogICAgICByZWNvbW1lbmRlZCBiZWNhdXNl IHN1YnRhZyAnc2wnIGhhcyBhIFN1cHByZXNzLVNjcmlwdCB2YWx1ZSBvZg0KICAgICAgJ0xhdG4n KQ0KDQogICBMYW5ndWFnZS1SZWdpb246DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSA1NF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg ICBNYXkgMjAwNQ0KDQoNCiAgICAgIGRlLURFIChHZXJtYW4gZm9yIEdlcm1hbnkpDQoNCiAgICAg IGVuLVVTIChFbmdsaXNoIGFzIHVzZWQgaW4gdGhlIFVuaXRlZCBTdGF0ZXMpDQoNCiAgICAgIGVz LTQxOSAoU3BhbmlzaCBmb3IgTGF0aW4gQW1lcmljYSBhbmQgQ2FyaWJiZWFuIHJlZ2lvbiB1c2lu ZyB0aGUNCiAgICAgIFVOIHJlZ2lvbiBjb2RlKQ0KDQogICBQcml2YXRlLXVzZSBzdWJ0YWdzOg0K DQogICAgICBkZS1DSC14LXBob25lYmsNCg0KICAgICAgYXotQXJhYi14LUFaRS1kZXJiZW5kDQoN CiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgKGV4YW1wbGVzIE9OTFk6IGV4dGVuZGVkIGxh bmd1YWdlcyBtdXN0IGJlDQogICBkZWZpbmVkIGJ5IHJldmlzaW9uIG9yIHVwZGF0ZSB0byB0aGlz IGRvY3VtZW50KToNCg0KICAgICAgemgtbWluDQoNCiAgICAgIHpoLW1pbi1uYW4tSGFudC1DTg0K DQogICBQcml2YXRlLXVzZSByZWdpc3RyeSB2YWx1ZXM6DQoNCiAgICAgIHgtd2hhdGV2ZXIgKHBy aXZhdGUgdXNlIHVzaW5nIHRoZSBzaW5nbGV0b24gJ3gnKQ0KDQogICAgICBxYWEtUWFhYS1RTS14 LXNvdXRoZXJuIChhbGwgcHJpdmF0ZSB0YWdzKQ0KDQogICAgICBkZS1RYWFhIChHZXJtYW4sIHdp dGggYSBwcml2YXRlIHNjcmlwdCkNCg0KICAgICAgc3ItTGF0bi1RTSAoU2VyYmlhbiwgTGF0aW4t c2NyaXB0LCBwcml2YXRlIHJlZ2lvbikNCg0KICAgICAgc3ItUWFhYS1DUyAoU2VyYmlhbiwgcHJp dmF0ZSBzY3JpcHQsIGZvciBTZXJiaWEgYW5kIE1vbnRlbmVncm8pDQoNCiAgIFRhZ3MgdGhhdCB1 c2UgZXh0ZW5zaW9ucyAoZXhhbXBsZXMgT05MWTogZXh0ZW5zaW9ucyBtdXN0IGJlIGRlZmluZWQN CiAgIGJ5IHJldmlzaW9uIG9yIHVwZGF0ZSB0byB0aGlzIGRvY3VtZW50IG9yIGJ5IFJGQyk6DQoN CiAgICAgIGVuLVVTLXUtaXNsYW1DYWwNCg0KICAgICAgemgtQ04tYS1teUV4dC14LXByaXZhdGUN Cg0KICAgICAgZW4tYS1teUV4dC1iLWFub3RoZXINCg0KICAgU29tZSBJbnZhbGlkIFRhZ3M6DQoN CiAgICAgIGRlLTQxOS1ERSAodHdvIHJlZ2lvbiB0YWdzKQ0KDQoNCg0KDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBb UGFnZSA1NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3Ry eSAgICAgICAgICAgICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgICAgIGEtREUgKHVzZSBvZiBhIHNp bmdsZSBjaGFyYWN0ZXIgc3VidGFnIGluIHByaW1hcnkgcG9zaXRpb247IG5vdGUNCiAgICAgIHRo YXQgdGhlcmUgYXJlIGEgZmV3IGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IHN0YXJ0IHdpdGggImkt IiB0aGF0DQogICAgICBhcmUgdmFsaWQpDQoNCiAgICAgIGFyLWEtYWFhLWItYmJiLWEtY2NjICh0 d28gZXh0ZW5zaW9ucyB3aXRoIHNhbWUgc2luZ2xlIGxldHRlcg0KICAgICAgcHJlZml4KQ0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNTZdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAg TWF5IDIwMDUNCg0KDQpBcHBlbmRpeCBDLiAgRXhhbXBsZSBSZWdpc3RyeQ0KDQogICBFeGFtcGxl IFJlZ2lzdHJ5DQoNCiAgIEZpbGUtRGF0ZTogMjAwNS0wNC0xOA0KICAgJSUNCiAgIFR5cGU6IGxh bmd1YWdlDQogICBTdWJ0YWc6IGFhDQogICBEZXNjcmlwdGlvbjogQWZhcg0KICAgQWRkZWQ6IDIw MDQtMDctMDYNCiAgICUlDQogICBUeXBlOiBsYW5ndWFnZQ0KICAgU3VidGFnOiBhYg0KICAgRGVz Y3JpcHRpb246IEFia2hhemlhbg0KICAgQWRkZWQ6IDIwMDQtMDctMDYNCiAgICUlDQogICBUeXBl OiBsYW5ndWFnZQ0KICAgU3VidGFnOiBhZQ0KICAgRGVzY3JpcHRpb246IEF2ZXN0YW4NCiAgIEFk ZGVkOiAyMDA0LTA3LTA2DQogICAlJQ0KICAgVHlwZTogbGFuZ3VhZ2UNCiAgIFN1YnRhZzogYXIN CiAgIERlc2NyaXB0aW9uOiBBcmFiaWMNCiAgIEFkZGVkOiAyMDA0LTA3LTA2DQogICBTdXBwcmVz cy1TY3JpcHQ6IEFyYWINCiAgIENvbW1lbnQ6IEFyYWJpYyB0ZXh0IGlzIHVzdWFsbHkgd3JpdHRl biBpbiBBcmFiaWMgc2NyaXB0DQogICAlJQ0KICAgVHlwZTogbGFuZ3VhZ2UNCiAgIFN1YnRhZzog cWFhLi5xdHoNCiAgIERlc2NyaXB0aW9uOiBQUklWQVRFIFVTRQ0KICAgQWRkZWQ6IDIwMDQtMDgt MDENCiAgIENvbW1lbnQ6IFVzZSBwcml2YXRlIHVzZSBjb2RlcyBpbiBwcmVmZXJlbmNlDQogICAg IHRvIHRoZSB4LSBzaW5nbGV0b24gZm9yIHByaW1hcnkgbGFuZ3VhZ2UNCiAgIENvbW1lbnQ6IFRo aXMgaXMgYW4gZXhhbXBsZSBvZiB0d28gY29tbWVudHMuDQogICAlJQ0KICAgVHlwZTogc2NyaXB0 DQogICBTdWJ0YWc6IEFyYWINCiAgIERlc2NyaXB0aW9uOiBBcmFiaWMNCiAgIEFkZGVkOiAyMDA0 LTA3LTA2DQogICAlJQ0KICAgVHlwZTogc2NyaXB0DQogICBTdWJ0YWc6IEFybW4NCiAgIERlc2Ny aXB0aW9uOiBBcm1lbmlhbg0KICAgQWRkZWQ6IDIwMDQtMDctMDYNCiAgICUlDQogICBUeXBlOiBz Y3JpcHQNCiAgIFN1YnRhZzogQmFsaQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNTddDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICAg TWF5IDIwMDUNCg0KDQogICBEZXNjcmlwdGlvbjogQmFsaW5lc2UNCiAgIEFkZGVkOiAyMDA0LTA3 LTA2DQogICAlJQ0KICAgVHlwZTogc2NyaXB0DQogICBTdWJ0YWc6IEJhdGsNCiAgIERlc2NyaXB0 aW9uOiBCYXRhaw0KICAgQWRkZWQ6IDIwMDQtMDctMDYNCiAgICUlDQogICBUeXBlOiByZWdpb24N CiAgIFN1YnRhZzogQUENCiAgIERlc2NyaXB0aW9uOiBQUklWQVRFIFVTRQ0KICAgQWRkZWQ6IDIw MDQtMDgtMDENCiAgICUlDQogICBUeXBlOiByZWdpb24NCiAgIFN1YnRhZzogQUQNCiAgIERlc2Ny aXB0aW9uOiBBbmRvcnJhDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IHJl Z2lvbg0KICAgU3VidGFnOiBBRQ0KICAgRGVzY3JpcHRpb246IFVuaXRlZCBBcmFiIEVtaXJhdGVz DQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IHJlZ2lvbg0KICAgU3VidGFn OiBBWA0KICAgRGVzY3JpcHRpb246ICYjeEM1O2xhbmQgSXNsYW5kcw0KICAgQWRkZWQ6IDIwMDQt MDctMDYNCiAgIENvbW1lbnRzOiBUaGUgZGVzY3JpcHRpb24gc2hvd3MgYSBVbmljb2RlIGVzY2Fw ZQ0KICAgICBmb3IgdGhlIGxldHRlciBBLXJpbmcuDQogICAlJQ0KICAgVHlwZTogcmVnaW9uDQog ICBTdWJ0YWc6IDAwMQ0KICAgRGVzY3JpcHRpb246IFdvcmxkDQogICBBZGRlZDogMjAwNC0wNy0w Ng0KICAgJSUNCiAgIFR5cGU6IHJlZ2lvbg0KICAgU3VidGFnOiAwMDINCiAgIERlc2NyaXB0aW9u OiBBZnJpY2ENCiAgIEFkZGVkOiAyMDA0LTA3LTA2DQogICAlJQ0KICAgVHlwZTogcmVnaW9uDQog ICBTdWJ0YWc6IDAwMw0KICAgRGVzY3JpcHRpb246IE5vcnRoIEFtZXJpY2ENCiAgIEFkZGVkOiAy MDA0LTA3LTA2DQogICAlJQ0KICAgVHlwZTogdmFyaWFudA0KICAgU3VidGFnOiAxOTAxDQogICBE ZXNjcmlwdGlvbjogVHJhZGl0aW9uYWwgR2VybWFuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSA1OF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICAgICBNYXkgMjAwNQ0KDQoNCiAgICAgIG9ydGhvZ3JhcGh5DQogICBBZGRlZDogMjAwNC0w OS0wOQ0KICAgUmVjb21tZW5kZWQtUHJlZml4OiBkZQ0KICAgQ29tbWVudDogPHNob3dzIGNvbnRp bnVhdGlvbj4NCiAgICUlDQogICBUeXBlOiB2YXJpYW50DQogICBTdWJ0YWc6IDE5OTYNCiAgIERl c2NyaXB0aW9uOiBHZXJtYW4gb3J0aG9ncmFwaHkgb2YgMTk5Ng0KICAgQWRkZWQ6IDIwMDQtMDkt MDkNCiAgIFJlY29tbWVuZGVkLVByZWZpeDogZGUNCiAgICUlDQogICBUeXBlOiB2YXJpYW50DQog ICBTdWJ0YWc6IGJvb250DQogICBEZXNjcmlwdGlvbjogQm9vbnRsaW5nDQogICBBZGRlZDogMjAw My0wMi0xNA0KICAgUmVjb21tZW5kZWQtUHJlZml4OiBlbg0KICAgJSUNCiAgIFR5cGU6IHZhcmlh bnQNCiAgIFN1YnRhZzogZ2F1bGlzaA0KICAgRGVzY3JpcHRpb246IEdhdWxpc2gNCiAgIEFkZGVk OiAyMDAxLTA1LTI1DQogICBSZWNvbW1lbmRlZC1QcmVmaXg6IGNlbA0KICAgJSUNCiAgIFR5cGU6 IGdyYW5kZmF0aGVyZWQNCiAgIFRhZzogYXJ0LWxvamJhbg0KICAgRGVzY3JpcHRpb246IExvamJh bg0KICAgQWRkZWQ6IDIwMDEtMTEtMTENCiAgIENhbm9uaWNhbDogamJvDQogICBEZXByZWNhdGVk OiAyMDAzLTA5LTAyDQogICAlJQ0KICAgVHlwZTogZ3JhbmRmYXRoZXJlZA0KICAgVGFnOiBlbi1H Qi1vZWQNCiAgIERlc2NyaXB0aW9uOiBFbmdsaXNoLCBPeGZvcmQgRW5nbGlzaCBEaWN0aW9uYXJ5 IHNwZWxsaW5nDQogICBBZGRlZDogMjAwMy0wNy0wOQ0KICAgJSUNCiAgIFR5cGU6IGdyYW5kZmF0 aGVyZWQNCiAgIFRhZzogaS1hbWkNCiAgIERlc2NyaXB0aW9uOiAnQW1pcw0KICAgQWRkZWQ6IDE5 OTktMDUtMjUNCiAgICUlDQogICBUeXBlOiBncmFuZGZhdGhlcmVkDQogICBUYWc6IGktYm5uDQog ICBEZXNjcmlwdGlvbjogQnVudW4NCiAgIEFkZGVkOiAxOTk5LTA1LTI1DQogICAlJQ0KICAgVHlw ZTogcmVkdW5kYW50DQogICBUYWc6IGF6LUFyYWINCiAgIERlc2NyaXB0aW9uOiBBemVyYmFpamFu aSBpbiBBcmFiaWMgc2NyaXB0DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDIwLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSA1OV0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgICBNYXkg MjAwNQ0KDQoNCiAgIEFkZGVkOiAyMDAzLTA1LTMwDQogICAlJQ0KICAgVHlwZTogcmVkdW5kYW50 DQogICBUYWc6IGF6LUN5cmwNCiAgIERlc2NyaXB0aW9uOiBBemVyYmFpamFuaSBpbiBDeXJpbGxp YyBzY3JpcHQNCiAgIEFkZGVkOiAyMDAzLTA1LTMwDQogICAlJQ0KDQogICAgICAgICAgICAgICAg IEZpZ3VyZSA3OiBFeGFtcGxlIG9mIHRoZSBSZWdpc3RyeSBGb3JtYXQNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAs IDIwMDUgICAgICAgICAgICAgIFtQYWdlIDYwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KSW50 ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3Np dGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVk IHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hu b2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hp Y2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBi ZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBh bnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9y bWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJG QyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAg Q29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFu ZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9y IHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxp Y2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSBy aWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24g Y2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0K ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGlu dGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdo dHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkN CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVk IHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZv cm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KRGlzY2xh aW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5k IFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAg T1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhF IElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5U SUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRP IEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJFSU4g V0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElF UyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0Uu DQoNCg0KQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5l dCBTb2NpZXR5ICgyMDA1KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8gdGhlIHJp Z2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQN CiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0 aGVpciByaWdodHMuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJG QyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50ZXJu ZXQgU29jaWV0eS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3Zl bWJlciAyMCwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNjFdDQoMDQo= ------_=_NextPart_001_01C55CEC.3546236A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C55CEC.3546236A-- From ltru-bounces@lists.ietf.org Fri May 20 02:09:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ0hZ-0003Yu-EM; Fri, 20 May 2005 02:09:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ0hY-0003Yk-Cp for ltru@megatron.ietf.org; Fri, 20 May 2005 02:09:40 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27462 for ; Fri, 20 May 2005 02:09:38 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050520060906.CFOZ8952.mta9.adelphia.net@DEWELL> for ; Fri, 20 May 2005 02:09:06 -0400 Message-ID: <012a01c55d02$2300cd20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050518160718.KWCK9622.mta3.adelphia.net@megatron.ietf.org> Date: Thu, 19 May 2005 23:06:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> does the suggestion made in message >> http://www.ietf.org/mail-archive/web/ltru/current/msg01755.html >> (with the tweaks proposed in the followups) work for you? > > Yes, I checked i-*, no case of i-abcd with four letters. It wouldn't matter, because "i-abcd" would by definition be a grandfathered tag, and its canonical capitalization would be whatever appeared on its registration form. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 02:25:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ0wx-0007Pg-Bo; Fri, 20 May 2005 02:25:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ0wv-0007Pb-Ld for ltru@megatron.ietf.org; Fri, 20 May 2005 02:25:34 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10259 for ; Fri, 20 May 2005 02:25:32 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050520062502.CPNU8952.mta9.adelphia.net@DEWELL> for ; Fri, 20 May 2005 02:25:02 -0400 Message-ID: <013f01c55d04$584b2820$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050519022718.OQLI11382.mta7.adelphia.net@megatron.ietf.org> Date: Thu, 19 May 2005 23:22:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Open points before -02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> I continue to think this is an excellent idea. Is it on-topic for >> this WG, or should those of us who support this idea start meeting >> off-list to discuss it? > ... > > I'd rather not request any additions to our list of deliverables at > this time, though I'd be willing to discuss it after we've finished > our chartered deliverables. Randy is completely right, and to be honest, I don't know what I was thinking. Of course if it's not a proper deliverable for the WG, it's not on-topic for the list. I guess I need to start thinking less like a mailing-list member and more like a WG member. I applaud John Cowan's initiative in starting a separate mailing list to codify record-jar. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 02:30:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ11v-00008D-IU; Fri, 20 May 2005 02:30:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ11u-000088-58 for ltru@megatron.ietf.org; Fri, 20 May 2005 02:30:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10723 for ; Fri, 20 May 2005 02:30:40 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DZ10W-0008Dk-3H for ltru@lists.ietf.org; Fri, 20 May 2005 08:29:16 +0200 Received: from 62.80.58.118 ([62.80.58.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2005 08:29:16 +0200 Received: from nobody by 62.80.58.118 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2005 08:29:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 20 May 2005 08:29:39 +0200 Organization: Lines: 11 Message-ID: <428D83D3.702F@xyzzy.claranet.de> References: <20050518160718.KWCK9622.mta3.adelphia.net@megatron.ietf.org> <012a01c55d02$2300cd20$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.118 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #985] Specify case rules for canonical tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > "i-abcd" would by definition be a grandfathered tag Yes, and lower case for it is no problem. Sometimes I'm paranoid, a text about "4 letters" could too easily hit i-abcd. The problem with the impossible "sub-separator" and "-" being used as both separator and "sub-separator". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 02:51:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1Lj-0004Ll-0u; Fri, 20 May 2005 02:51:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1Lh-0004Lg-F9 for ltru@megatron.ietf.org; Fri, 20 May 2005 02:51:09 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12460 for ; Fri, 20 May 2005 02:51:07 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050520065037.FMTX4191.mta13.adelphia.net@DEWELL> for ; Fri, 20 May 2005 02:50:37 -0400 Message-ID: <015701c55d07$c2d32960$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050519022718.OQLI11382.mta7.adelphia.net@megatron.ietf.org> Date: Thu, 19 May 2005 23:47:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira wrote: > Whenever possible, the language tag registry draft should not > encourage the proliferation of aliases for tags or subtags. Misha Wolf wrote: > We must insist that those creating tags use canonical values. > Any other approach will lead to a broken Internet. and yet Frank Ellermann says: > The complete concept of "Canonical:" appears to be > wrong, if you even think about any "let's forget the rest". > ... > Supporting only an obsolete idea of "Canonical:" as stated in > an obscure IANA registry not reflecting the state of the art > in the source standards after date-B was a worse idea. IMHO, this is the single biggest technical stumbling block in the project. The draft has always taken the middle road by saying that there were canonical subtags, which would not change dammit, and then there were aliases which could be used (but shouldn't), and must be recognized as equivalent to the canonical. Now we have some saying there should be no aliases at all, only canonicals, and others saying the whole notion of canonical stability is "an obsolete idea." Folks, if we don't find a way to resolve this, we are nowhere. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 02:51:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1M9-0004Oq-8E; Fri, 20 May 2005 02:51:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1M8-0004Oi-H8 for ltru@megatron.ietf.org; Fri, 20 May 2005 02:51:36 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12479 for ; Fri, 20 May 2005 02:51:34 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050520065105.IBPS17140.mta10.adelphia.net@DEWELL> for ; Fri, 20 May 2005 02:51:05 -0400 Message-ID: <015801c55d07$d8900ac0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050519183446.CLWD27459.mta2.adelphia.net@megatron.ietf.org> Date: Thu, 19 May 2005 23:47:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> change Canonical-Value to work more-or-less like "Use" > > That's a plan. Replacing it by Use: later if Ira still thinks > that implementors might get Canonical: wrong is no problem. Not much later. In particular, not after the draft gets published and implementations start depending on the field name "Canonical." You know, that pesky "stability" thing again. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 02:52:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1Ml-0004U0-V9; Fri, 20 May 2005 02:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1Mk-0004Tv-Dt for ltru@megatron.ietf.org; Fri, 20 May 2005 02:52:14 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12515 for ; Fri, 20 May 2005 02:52:12 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050520065143.CXTO8952.mta9.adelphia.net@DEWELL>; Fri, 20 May 2005 02:51:43 -0400 Message-ID: <015901c55d07$efbe2f60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050519233624.RCGV9622.mta3.adelphia.net@megatron.ietf.org> Date: Thu, 19 May 2005 23:48:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > I have to look this over in detail, but a crucial requirement is to > guarantee the invariant: > > if isValid(tag, date1), then canonicalize(tag, date1) = > canonicalize(tag, date2), for all date2 > date1 > > Does this still preserve that? Not the way I see it. Frank's proposal would remove the Canonical attribute from VU and assign it to VO as soon as ISO 3166/MA changes their alpha-3 code from VU to VO. Which I thought was exactly what we were trying to get away from. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 02:52:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1N9-0004XL-UW; Fri, 20 May 2005 02:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1N9-0004XE-Fx for ltru@megatron.ietf.org; Fri, 20 May 2005 02:52:39 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12537 for ; Fri, 20 May 2005 02:52:37 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050520065208.CYAD8952.mta9.adelphia.net@DEWELL> for ; Fri, 20 May 2005 02:52:08 -0400 Message-ID: <015a01c55d07$fe0c4b60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 19 May 2005 23:48:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] UNSD adds two new codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The United Nations Statistics Division has added two new country codes: 831 Guernsey 832 Jersey They have not withdrawn 830 for Channel Islands, at least not yet. The new list is available at: http://unstats.un.org/unsd/methods/m49/m49alpha.htm Don't go looking for an "Updated" date or other fanfare on this page, or any mention of this action on their "codes added or changed" page. I found out about the change courtesy of WatchThatPage. Frank, it looks like you may get your GG and JE subtags after all. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 03:37:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ24A-0006Ju-Sm; Fri, 20 May 2005 03:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ249-0006Jp-9B for ltru@megatron.ietf.org; Fri, 20 May 2005 03:37:05 -0400 Received: from icu-project.org (icu-project.org [66.160.189.149]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15968 for ; Fri, 20 May 2005 03:37:03 -0400 (EDT) Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Fri, 20 May 2005 00:36:58 -0700 Message-ID: <04dd01c55d0e$b3fc7840$4d6e3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <20050519233624.RCGV9622.mta3.adelphia.net@megatron.ietf.org> <015901c55d07$efbe2f60$030aa8c0@DEWELL> Date: Fri, 20 May 2005 00:36:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA15968 Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Then that is not acceptable. There is no purpose to a canonical format unless it is stable. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Cc: "Mark Davis" Sent: Thursday, May 19, 2005 23:48 Subject: Re: [psg.com #954] all aliases must be equally supported > Mark Davis wrote: > > > I have to look this over in detail, but a crucial requirement is to > > guarantee the invariant: > > > > if isValid(tag, date1), then canonicalize(tag, date1) =3D > > canonicalize(tag, date2), for all date2 > date1 > > > > Does this still preserve that? > > Not the way I see it. Frank's proposal would remove the Canonical > attribute from VU and assign it to VO as soon as ISO 3166/MA changes > their alpha-3 code from VU to VO. Which I thought was exactly what we > were trying to get away from. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 05:15:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3b8-00057v-Bf; Fri, 20 May 2005 05:15:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3b6-00057P-Mh for ltru@megatron.ietf.org; Fri, 20 May 2005 05:15:13 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23022 for ; Fri, 20 May 2005 05:15:09 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DZ3Zy-00029A-H2 for ltru@lists.ietf.org; Fri, 20 May 2005 11:14:02 +0200 Received: from 62.80.58.118 ([62.80.58.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2005 11:14:02 +0200 Received: from nobody by 62.80.58.118 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2005 11:14:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 20 May 2005 11:10:44 +0200 Organization: Lines: 12 Message-ID: <428DA994.76D6@xyzzy.claranet.de> References: <015a01c55d07$fe0c4b60$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.118 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: UNSD adds two new codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > it looks like you may get your GG and JE subtags after all. I'll check later what the new -02 draft says about any GG + JE introduced _after_ 831 + 832 :-) Maybe that could sway Mark to a more realistic "Use:" idea. The real GG + JE fan or rather expert here is John. Back in the time when I collected stamps instead of TLDs it was only AD, IE, and IS, not GG, IM, or JE. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 05:29:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3oo-0008O7-0j; Fri, 20 May 2005 05:29:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3om-0008O2-OY for ltru@megatron.ietf.org; Fri, 20 May 2005 05:29:20 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23883 for ; Fri, 20 May 2005 05:29:17 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DZ3mj-0003nx-9A for ltru@lists.ietf.org; Fri, 20 May 2005 11:27:13 +0200 Received: from 62.80.58.118 ([62.80.58.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2005 11:27:13 +0200 Received: from nobody by 62.80.58.118 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2005 11:27:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 20 May 2005 11:25:04 +0200 Organization: Lines: 14 Message-ID: <428DACF0.1255@xyzzy.claranet.de> References: <20050519183446.CLWD27459.mta2.adelphia.net@megatron.ietf.org> <015801c55d07$d8900ac0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.118 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > Not much later. In particular, not after the draft gets > published and implementations start depending on the field > name "Canonical." You know, that pesky "stability" thing Sure, later = -03 or -04, assuming that -04 could be a kind of "internal last call" and -05 is then "the real thing". With Randy and Martin forced to decide on a rough consensus about the informational Use: vs. normative Canonical: issue. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 08:02:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6DT-0007xf-Na; Fri, 20 May 2005 08:02:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6DS-0007xa-AE for ltru@megatron.ietf.org; Fri, 20 May 2005 08:02:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05521 for ; Fri, 20 May 2005 08:02:57 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ6Un-0007nf-Kk for ltru@ietf.org; Fri, 20 May 2005 08:20:54 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4KC2eS4027119; Fri, 20 May 2005 08:02:40 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 20 May 2005 08:02:45 -0400 Date: Fri, 20 May 2005 08:02:45 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] UNSD adds two new codes Message-ID: <20050520120245.GB6554@skunk.reutershealth.com> References: <015a01c55d07$fe0c4b60$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015a01c55d07$fe0c4b60$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell scripsit: > The United Nations Statistics Division has added two new country codes: > > 831 Guernsey > 832 Jersey Well, I will be an egg-sucking son of a stuffed monkey. They have done precisely what I predicted it would make no sense for them to do. > They have not withdrawn 830 for Channel Islands, at least not yet. No reason to: it was a regional code before and it'll be one now. > Frank, it looks like you may get your GG and JE subtags after all. Quite likely. -- Here lies the Christian, John Cowan judge, and poet Peter, http://www.reutershealth.com Who broke the laws of God http://www.ccil.org/~cowan and man and metre. jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 12:53:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAkH-0000zz-3v; Fri, 20 May 2005 12:53:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAkG-0000zu-8z for ltru@megatron.ietf.org; Fri, 20 May 2005 12:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06254 for ; Fri, 20 May 2005 12:53:05 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZB1c-0007Pa-Se for ltru@ietf.org; Fri, 20 May 2005 13:11:07 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4KGqlMw010309; Fri, 20 May 2005 09:52:47 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 20 May 2005 09:52:46 -0700 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Fri, 20 May 2005 09:52:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, Doug's right - we need to find concensus here and move on. I think I've been guilty of a mis-conception here. I admit my comments were colored by having worked on specifications and software based on the IANA Charset Registry - which has a 10-to-1 ratio of aliases to base charset tags - the use of charset tags in MIME content has been a thorough failure. If indeed language subtag aliases are _rare_, then the requirement for support of all aliases is fine. Canonicalization of langugage tags (by exercise of an algorithm, not by reference to a copy of the IANA Language Subtag Registry) should be a SHOULD for content generation and content queries (because it's likely to reduce processing errors by less than perfect software). I'm perfectly happy to lose the problematic 'Canonical:' field in the registry and replace it with 'Use:'. The idea of 'once canonical, forever canonical' is wrapping us all around the axle, but not visibly helping. The problem we're wrestling with is that our ISO/UN sources are _not_ entirely stable and we intuitively think we should try to achieve better stability in the IANA Language Subtag Registry. We're probably catching at moonbeams... Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Doug Ewell > Sent: Friday, May 20, 2005 2:47 AM > To: LTRU Working Group > Subject: [Ltru] Re: [psg.com #954] all aliases must be > equally supported > > > McDonald, Ira wrote: > > > Whenever possible, the language tag registry draft should not > > encourage the proliferation of aliases for tags or subtags. > > Misha Wolf wrote: > > > We must insist that those creating tags use canonical values. > > Any other approach will lead to a broken Internet. > > and yet Frank Ellermann says: > > > The complete concept of "Canonical:" appears to be > > wrong, if you even think about any "let's forget the rest". > > ... > > Supporting only an obsolete idea of "Canonical:" as stated in > > an obscure IANA registry not reflecting the state of the art > > in the source standards after date-B was a worse idea. > > IMHO, this is the single biggest technical stumbling block in the > project. The draft has always taken the middle road by saying that > there were canonical subtags, which would not change dammit, and then > there were aliases which could be used (but shouldn't), and must be > recognized as equivalent to the canonical. > > Now we have some saying there should be no aliases at all, only > canonicals, and others saying the whole notion of canonical > stability is > "an obsolete idea." Folks, if we don't find a way to resolve this, we > are nowhere. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 12:59:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAqb-0002b4-40; Fri, 20 May 2005 12:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAqZ-0002aI-Dr for ltru@megatron.ietf.org; Fri, 20 May 2005 12:59:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07260 for ; Fri, 20 May 2005 12:59:36 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZB7x-0007cR-QB for ltru@ietf.org; Fri, 20 May 2005 13:17:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 09:59:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Fri, 20 May 2005 09:59:25 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B732FDF@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Thread-Index: AcVdXH0Hr8/dF4QlTry0PcGwZ4SlVwAACJMA From: "Addison Phillips" To: "McDonald, Ira" , "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 20 May 2005 16:59:26.0741 (UTC) FILETIME=[47C5BC50:01C55D5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0690381365==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0690381365== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgcHJvYmxlbSBoZXJlIGlzIHRoYXQgd2hlbiByZWdpb25zIGNoYW5nZSBpZGVu dGl0eSBhbmQgZ2V0IGEgbmV3IGNvZGUsIHRoZXkgZ2VuZXJhbGx5ICphcmUqIHNvbWVob3cgZGlm ZmVyZW50LiBUaGUgIm9sZCBjb3VudHJ5IiBpbiBzb21lIHNlbnNlIG5vIGxvbmdlciBleGlzdHMs IGV2ZW4gaWYgdGhlIG5ldyBlbnRpdHkgc2hhcmVzIHRoZSBzYW1lIGJvcmRlcnMuIERvZXMgWmFp cmUgZXhpc3Q/IERvZXMgUmhvZGVzaWE/IA0KDQpTbyB0aGUgIlVzZSIgdmFsdWUgaXMgbm90IHJl YWxseSBhIGNhbm9uaWNhbGl0eSBwcm9ibGVtLiBXZSBjYW4gd2Vha2VuIHRoZSByZWNvbW1lbmRh dGlvbiBldmVuIG1vcmUgdG8gYmUgbW9yZSBhY2N1cmF0ZToNCg0KPiA+ICAgIDx0PlN1YnRhZ3Mg b2YgdHlwZSAnUmVnaW9uJyB0aGF0IGhhdmUgYSBDYW5vbmljYWwtVmFsdWUgbWFwcGluZw0KPiA+ ICAgICAgIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IChzZWUgPHhyZWYgdGFyZ2V0PSJpYW5hZm9ybWF0 Ii8+KSBNQVkgYmUNCj4gPiAgICAgICByZXBsYWNlZCB3aXRoIHRoZWlyIG1hcHBlZCB2YWx1ZSB3 aGVuIHBlcmZvcm1pbmcgY29tcGFyaXNvbg0KICAgICAgICAgIG9mIHRhZ3MuIEl0IHNob3VsZCBi ZSBub3RlZCB0aGF0IHRoaXMgbWF5IGNoYW5nZSB0aGUgbWVhbmluZyBvZg0KICAgICAgICAgIHRo ZSB0YWcuPC90Pg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVj dCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBX b3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJ dCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0Bs aXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIE1jRG9uYWxkLCBJcmENCj4gU2VudDogMjAw NeW5tDXmnIgyMOaXpSA5OjUzDQo+IFRvOiAnRG91ZyBFd2VsbCc7IExUUlUgV29ya2luZyBHcm91 cA0KPiBTdWJqZWN0OiBSRTogW0x0cnVdIFJlOiBbcHNnLmNvbSAjOTU0XSBhbGwgYWxpYXNlcyBt dXN0IGJlIGVxdWFsbHkgc3VwcG9ydA0KPiBlZA0KPiANCj4gSGksDQo+IA0KPiBEb3VnJ3Mgcmln aHQgLSB3ZSBuZWVkIHRvIGZpbmQgY29uY2Vuc3VzIGhlcmUgYW5kIG1vdmUgb24uDQo+IA0KPiBJ IHRoaW5rIEkndmUgYmVlbiBndWlsdHkgb2YgYSBtaXMtY29uY2VwdGlvbiBoZXJlLiAgSSBhZG1p dCBteQ0KPiBjb21tZW50cyB3ZXJlIGNvbG9yZWQgYnkgaGF2aW5nIHdvcmtlZCBvbiBzcGVjaWZp Y2F0aW9ucyBhbmQNCj4gc29mdHdhcmUgYmFzZWQgb24gdGhlIElBTkEgQ2hhcnNldCBSZWdpc3Ry eSAtIHdoaWNoIGhhcyBhIDEwLXRvLTENCj4gcmF0aW8gb2YgYWxpYXNlcyB0byBiYXNlIGNoYXJz ZXQgdGFncyAtIHRoZSB1c2Ugb2YgY2hhcnNldCB0YWdzDQo+IGluIE1JTUUgY29udGVudCBoYXMg YmVlbiBhIHRob3JvdWdoIGZhaWx1cmUuDQo+IA0KPiBJZiBpbmRlZWQgbGFuZ3VhZ2Ugc3VidGFn IGFsaWFzZXMgYXJlIF9yYXJlXywgdGhlbiB0aGUgcmVxdWlyZW1lbnQNCj4gZm9yIHN1cHBvcnQg b2YgYWxsIGFsaWFzZXMgaXMgZmluZS4NCj4gDQo+IENhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3Vn YWdlIHRhZ3MgKGJ5IGV4ZXJjaXNlIG9mIGFuIGFsZ29yaXRobSwNCj4gbm90IGJ5IHJlZmVyZW5j ZSB0byBhIGNvcHkgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5KQ0KPiBzaG91 bGQgYmUgYSBTSE9VTEQgZm9yIGNvbnRlbnQgZ2VuZXJhdGlvbiBhbmQgY29udGVudCBxdWVyaWVz DQo+IChiZWNhdXNlIGl0J3MgbGlrZWx5IHRvIHJlZHVjZSBwcm9jZXNzaW5nIGVycm9ycyBieSBs ZXNzIHRoYW4NCj4gcGVyZmVjdCBzb2Z0d2FyZSkuDQo+IA0KPiBJJ20gcGVyZmVjdGx5IGhhcHB5 IHRvIGxvc2UgdGhlIHByb2JsZW1hdGljICdDYW5vbmljYWw6JyBmaWVsZA0KPiBpbiB0aGUgcmVn aXN0cnkgYW5kIHJlcGxhY2UgaXQgd2l0aCAnVXNlOicuICBUaGUgaWRlYSBvZiAnb25jZQ0KPiBj YW5vbmljYWwsIGZvcmV2ZXIgY2Fub25pY2FsJyBpcyB3cmFwcGluZyB1cyBhbGwgYXJvdW5kIHRo ZQ0KPiBheGxlLCBidXQgbm90IHZpc2libHkgaGVscGluZy4NCj4gDQo+IFRoZSBwcm9ibGVtIHdl J3JlIHdyZXN0bGluZyB3aXRoIGlzIHRoYXQgb3VyIElTTy9VTiBzb3VyY2VzIGFyZQ0KPiBfbm90 XyBlbnRpcmVseSBzdGFibGUgYW5kIHdlIGludHVpdGl2ZWx5IHRoaW5rIHdlIHNob3VsZCB0cnkg dG8NCj4gYWNoaWV2ZSBiZXR0ZXIgc3RhYmlsaXR5IGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRh ZyBSZWdpc3RyeS4NCj4gV2UncmUgcHJvYmFibHkgY2F0Y2hpbmcgYXQgbW9vbmJlYW1zLi4uDQo+ IA0KPiBDaGVlcnMsDQo+IC0gSXJhDQo+IA0KPiBJcmEgTWNEb25hbGQgKE11c2ljaWFuIC8gU29m dHdhcmUgQXJjaGl0ZWN0KQ0KPiBCbHVlIFJvb2YgTXVzaWMgLyBIaWdoIE5vcnRoIEluYw0KPiBQ TyBCb3ggMjIxICBHcmFuZCBNYXJhaXMsIE1JICA0OTgzOQ0KPiBwaG9uZTogKzEtOTA2LTQ5NC0y NDM0DQo+IGVtYWlsOiBpbWNkb25hbGRAc2hhcnBsYWJzLmNvbQ0KPiANCj4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZw0K PiA+IFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXU9uDQo+ID4gQmVoYWxmIE9m IERvdWcgRXdlbGwNCj4gPiBTZW50OiBGcmlkYXksIE1heSAyMCwgMjAwNSAyOjQ3IEFNDQo+ID4g VG86IExUUlUgV29ya2luZyBHcm91cA0KPiA+IFN1YmplY3Q6IFtMdHJ1XSBSZTogW3BzZy5jb20g Izk1NF0gYWxsIGFsaWFzZXMgbXVzdCBiZQ0KPiA+IGVxdWFsbHkgc3VwcG9ydGVkDQo+ID4NCj4g Pg0KPiA+IE1jRG9uYWxkLCBJcmEgPGltY2RvbmFsZCBhdCBzaGFycGxhYnMgZG90IGNvbT4gd3Jv dGU6DQo+ID4NCj4gPiA+IFdoZW5ldmVyIHBvc3NpYmxlLCB0aGUgbGFuZ3VhZ2UgdGFnIHJlZ2lz dHJ5IGRyYWZ0IHNob3VsZCBub3QNCj4gPiA+IGVuY291cmFnZSB0aGUgcHJvbGlmZXJhdGlvbiBv ZiBhbGlhc2VzIGZvciB0YWdzIG9yIHN1YnRhZ3MuDQo+ID4NCj4gPiBNaXNoYSBXb2xmIDxNaXNo YSBkb3QgV29sZiBhdCByZXV0ZXJzIGRvdCBjb20+IHdyb3RlOg0KPiA+DQo+ID4gPiBXZSBtdXN0 IGluc2lzdCB0aGF0IHRob3NlIGNyZWF0aW5nIHRhZ3MgdXNlIGNhbm9uaWNhbCB2YWx1ZXMuDQo+ ID4gPiBBbnkgb3RoZXIgYXBwcm9hY2ggd2lsbCBsZWFkIHRvIGEgYnJva2VuIEludGVybmV0Lg0K PiA+DQo+ID4gYW5kIHlldCBGcmFuayBFbGxlcm1hbm4gPG5vYm9keSBhdCB4eXp6eSBkb3QgY2xh cmFuZXQgZG90IGRlPiBzYXlzOg0KPiA+DQo+ID4gPiBUaGUgY29tcGxldGUgY29uY2VwdCBvZiAi Q2Fub25pY2FsOiIgYXBwZWFycyB0byBiZQ0KPiA+ID4gd3JvbmcsIGlmIHlvdSBldmVuIHRoaW5r IGFib3V0IGFueSAibGV0J3MgZm9yZ2V0IHRoZSByZXN0Ii4NCj4gPiA+IC4uLg0KPiA+ID4gU3Vw cG9ydGluZyBvbmx5IGFuIG9ic29sZXRlIGlkZWEgb2YgIkNhbm9uaWNhbDoiIGFzIHN0YXRlZCBp bg0KPiA+ID4gYW4gb2JzY3VyZSBJQU5BIHJlZ2lzdHJ5IG5vdCByZWZsZWN0aW5nIHRoZSBzdGF0 ZSBvZiB0aGUgYXJ0DQo+ID4gPiBpbiB0aGUgc291cmNlIHN0YW5kYXJkcyBhZnRlciBkYXRlLUIg d2FzIGEgd29yc2UgaWRlYS4NCj4gPg0KPiA+IElNSE8sIHRoaXMgaXMgdGhlIHNpbmdsZSBiaWdn ZXN0IHRlY2huaWNhbCBzdHVtYmxpbmcgYmxvY2sgaW4gdGhlDQo+ID4gcHJvamVjdC4gIFRoZSBk cmFmdCBoYXMgYWx3YXlzIHRha2VuIHRoZSBtaWRkbGUgcm9hZCBieSBzYXlpbmcgdGhhdA0KPiA+ IHRoZXJlIHdlcmUgY2Fub25pY2FsIHN1YnRhZ3MsIHdoaWNoIHdvdWxkIG5vdCBjaGFuZ2UgZGFt bWl0LCBhbmQgdGhlbg0KPiA+IHRoZXJlIHdlcmUgYWxpYXNlcyB3aGljaCBjb3VsZCBiZSB1c2Vk IChidXQgc2hvdWxkbid0KSwgYW5kIG11c3QgYmUNCj4gPiByZWNvZ25pemVkIGFzIGVxdWl2YWxl bnQgdG8gdGhlIGNhbm9uaWNhbC4NCj4gPg0KPiA+IE5vdyB3ZSBoYXZlIHNvbWUgc2F5aW5nIHRo ZXJlIHNob3VsZCBiZSBubyBhbGlhc2VzIGF0IGFsbCwgb25seQ0KPiA+IGNhbm9uaWNhbHMsIGFu ZCBvdGhlcnMgc2F5aW5nIHRoZSB3aG9sZSBub3Rpb24gb2YgY2Fub25pY2FsDQo+ID4gc3RhYmls aXR5IGlzDQo+ID4gImFuIG9ic29sZXRlIGlkZWEuIiAgRm9sa3MsIGlmIHdlIGRvbid0IGZpbmQg YSB3YXkgdG8gcmVzb2x2ZSB0aGlzLCB3ZQ0KPiA+IGFyZSBub3doZXJlLg0KPiA+DQo+ID4gLS0N Cj4gPiBEb3VnIEV3ZWxsDQo+ID4gRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ID4gaHR0cDovL3Vz ZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTHRydSBtYWlsaW5nIGxp c3QNCj4gPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHRydQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3Rz LmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUN Cg0K --===============0690381365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0690381365==-- From ltru-bounces@lists.ietf.org Fri May 20 13:24:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBEp-0001up-Pk; Fri, 20 May 2005 13:24:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBEo-0001uk-P2 for ltru@megatron.ietf.org; Fri, 20 May 2005 13:24:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10590 for ; Fri, 20 May 2005 13:24:39 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBWD-00004z-SJ for ltru@ietf.org; Fri, 20 May 2005 13:42:42 -0400 Received: from h-68-166-188-60.snvacaid.dynamic.covad.net ([68.166.188.60] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZBEm-0003b2-00 for ltru@ietf.org; Fri, 20 May 2005 10:24:40 -0700 Message-ID: <006f01c55d61$2d6790a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] [psg.com #954] all aliases must be equally supported Date: Fri, 20 May 2005 10:26:51 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "McDonald, Ira" > To: "'Doug Ewell'" ; "LTRU Working Group" > Sent: Friday, May 20, 2005 9:52 AM > Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed ... > The problem we're wrestling with is that our ISO/UN sources are > _not_ entirely stable and we intuitively think we should try to > achieve better stability in the IANA Language Subtag Registry. > We're probably catching at moonbeams... ... (as a contributor) Consider the motivations: (1) Re-tagging data (now or further in the future) is (a) expensive and (b) unlikely to be complete; (2) We don't want ambiguity in the interpretaion of a (sub)tag resulting from that string having meant substantially different things at different points in time; (3) Having multiple representations for "the same thing" complicates tagging and matching, both in the specification and the implementation. Although (3) appears inevitable, we can at least take steps to minimize it. I think we can and should take a strong position on (2), because the realities of (1). For tagging this means: "MUST NOT" re-use a (sub)tag string, "SHOULD NOT" tag with non-canonical form. (Calling the field "Use:" is fine with me.) For matching to work, this would mean that an implementation "MUST" treat as equivalent *all* the aliases (as of the implementation date) for its supported set of (sub)tags. At the same time, we need to be mindful of the fact that languages change and orthographies change, sometimes with surprising speed. The borders and names of countries and regions can change even faster. Ironically, scripts seem to be the most stable thing in the mix. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 13:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBMY-0003vi-Iy; Fri, 20 May 2005 13:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBMY-0003vd-4Z for ltru@megatron.ietf.org; Fri, 20 May 2005 13:32:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11350 for ; Fri, 20 May 2005 13:32:38 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBdt-0000JO-MH for ltru@ietf.org; Fri, 20 May 2005 13:50:41 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 20 May 2005 17:32:49 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IGS00J9YU1V2H@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 20 May 2005 17:32:19 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Fri, 20 May 2005 18:32:17 +0100 Date: Fri, 20 May 2005 18:32:17 +0100 From: Misha Wolf Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] [psg.com #954] all aliases must be equally supported thread-index: AcVdYSIFhledV99HQ3iuFXBQHeNxzQAADQQw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 20 May 2005 17:32:18.0104 (UTC) FILETIME=[DECBDB80:01C55D61] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > For matching to work, this would mean that an implementation=20 > "MUST" treat as equivalent *all* the aliases (as of the=20 > implementation date) for its supported set of (sub)tags. I regret that my current workload does not allow me to analyse=20 the text of the ID to get at the precise meaning. So please=20 help me: Does this imply that all implementations must support=20 the ISO 639-2 codes even where there exists a long-established=20 ISO 639-1 code? I very much hope that the answer is No. Thanks, Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 13:40:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBUL-0006aF-8C; Fri, 20 May 2005 13:40:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBUJ-0006aA-PA for ltru@megatron.ietf.org; Fri, 20 May 2005 13:40:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14712 for ; Fri, 20 May 2005 13:40:42 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBli-0000nZ-Ow for ltru@ietf.org; Fri, 20 May 2005 13:58:43 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 10:40:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported Date: Fri, 20 May 2005 10:40:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B733034@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #954] all aliases must be equally supported Thread-Index: AcVdYSIFhledV99HQ3iuFXBQHeNxzQAADQQwAABXliA= From: "Addison Phillips" To: "Misha Wolf" , "LTRU Working Group" X-OriginalArrivalTime: 20 May 2005 17:40:33.0975 (UTC) FILETIME=[065BC470:01C55D63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org No. It means that explicitly listed aliases must be mapped for matching = purposes. For ISO 639 codes, this means stuff like jv/jw and he/iw. The = 639-1/639-2 relationships are not listed because the only 639-2 codes = that appear are ones for which there is no 639-1 code (by rule). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Misha Wolf > Sent: 2005?5?20? 10:32 > To: LTRU Working Group > Subject: RE: [Ltru] [psg.com #954] all aliases must be equally = supported >=20 > Randy Presuhn wrote: >=20 > > For matching to work, this would mean that an implementation > > "MUST" treat as equivalent *all* the aliases (as of the > > implementation date) for its supported set of (sub)tags. >=20 > I regret that my current workload does not allow me to analyse > the text of the ID to get at the precise meaning. So please > help me: Does this imply that all implementations must support > the ISO 639-2 codes even where there exists a long-established > ISO 639-1 code? I very much hope that the answer is No. >=20 > Thanks, > Misha >=20 >=20 >=20 >=20 > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com >=20 > To find out more about Reuters Products and Services visit > http://www.reuters.com/productinfo >=20 > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Reuters Ltd. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 13:57:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBkD-000228-1C; Fri, 20 May 2005 13:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBkB-0001zQ-Kb for ltru@megatron.ietf.org; Fri, 20 May 2005 13:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16785 for ; Fri, 20 May 2005 13:57:06 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZC1Z-0001Mj-C7 for ltru@ietf.org; Fri, 20 May 2005 14:15:07 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 20 May 2005 17:56:51 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IGS00A11V6RVA@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 20 May 2005 18:56:51 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 20 May 2005 17:56:50 +0000 Date: Fri, 20 May 2005 18:56:50 +0100 From: Misha Wolf Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported To: LTRU Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF7803CD51EE@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] [psg.com #954] all aliases must be equally supported thread-index: AcVdYSIFhledV99HQ3iuFXBQHeNxzQAADQQwAABXliAAAKEJkA== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 20 May 2005 17:56:50.0996 (UTC) FILETIME=[4CB55740:01C55D65] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Good. Thanks. Misha=20 -----Original Message----- From: Addison Phillips [mailto:addison.phillips@quest.com]=20 Sent: 20 May 2005 18:41 To: Misha Wolf; LTRU Working Group Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported No. It means that explicitly listed aliases must be mapped for matching purposes. For ISO 639 codes, this means stuff like jv/jw and he/iw. The 639-1/639-2 relationships are not listed because the only 639-2 codes that appear are ones for which there is no 639-1 code (by rule). Addison ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 13:57:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBkb-0002Fb-U3; Fri, 20 May 2005 13:57:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBkb-0002FK-6p for ltru@megatron.ietf.org; Fri, 20 May 2005 13:57:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16894 for ; Fri, 20 May 2005 13:57:31 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZC1x-0001OP-EA for ltru@ietf.org; Fri, 20 May 2005 14:15:32 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4KHvH5c028692; Fri, 20 May 2005 13:57:18 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 20 May 2005 13:57:20 -0400 Date: Fri, 20 May 2005 13:57:20 -0400 From: John Cowan To: Misha Wolf , petercon@microsoft.com Subject: Re: [Ltru] [psg.com #954] all aliases must be equally supported Message-ID: <20050520175622.GA13468@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Misha Wolf scripsit: > So please > help me: Does this imply that all implementations must support > the ISO 639-2 codes even where there exists a long-established > ISO 639-1 code? I very much hope that the answer is No. No, no, a thousand times no. A language with both a 639-1 and a 639-2 code must *always* use the 639-1 code in RFC 3066 and all its future successors. The ISO 639 RA/JAC has guaranteed that no existing language with a 639-2 code will ever be assigned a novel 639-1 code. In effect, the list of 639-1 codes is frozen at least until 639-3 comes on line (and I bet it's still in fact frozen then). Peter, do you have any idea whether any of the new languages in 639-3 (new to ISO, that is) would be plausible candidates for ISO 639-1 registration? This is going to matter in RFC 3066ter. -- If you understand, John Cowan things are just as they are; http://www.ccil.org/~cowan if you do not understand, http://www.reutershealth.com things are just as they are. jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 14:05:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBsG-000644-NN; Fri, 20 May 2005 14:05:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBsF-00063v-Hq for ltru@megatron.ietf.org; Fri, 20 May 2005 14:05:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17801 for ; Fri, 20 May 2005 14:05:26 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZC9f-0001dQ-0H for ltru@ietf.org; Fri, 20 May 2005 14:23:27 -0400 Received: from eupig1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 20 May 2005 18:05:14 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IGS00J5GVKQLO@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 20 May 2005 18:05:14 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 20 May 2005 18:05:13 +0000 Date: Fri, 20 May 2005 19:05:13 +0100 From: Misha Wolf Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] [psg.com #954] all aliases must be equally supported thread-index: AcVdZWoq1BSiqVTOQA+xAfhPGOdApgAAGWJw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 20 May 2005 18:05:14.0099 (UTC) FILETIME=[7894C430:01C55D66] X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > No, no, a thousand times no. Hmm ... I'm disappointed. Is there any chance of making that a million? Thanks, Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 20 15:38:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDKP-0000Lc-DH; Fri, 20 May 2005 15:38:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDKJ-0000Am-Lq; Fri, 20 May 2005 15:38:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01048; Fri, 20 May 2005 15:38:29 -0400 (EDT) Message-Id: <200505201938.PAA01048@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 20 May 2005 15:38:29 -0400 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-02.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-registry-02.txt Pages : 61 Date : 2005-5-20 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. This document obsoletes RFC 3066 (which replaced RFC 1766). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-registry-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-registry-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-20154613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-20154613.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@lists.ietf.org Sat May 21 07:19:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS0b-00021H-PW; Sat, 21 May 2005 07:19:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS0Z-00020X-G8 for ltru@megatron.ietf.org; Sat, 21 May 2005 07:19:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28811 for ; Sat, 21 May 2005 07:19:03 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZN4p-0007fG-39 for ltru@ietf.org; Sat, 21 May 2005 02:03:12 -0400 Received: from h-68-164-241-14.snvacaid.dynamic.covad.net ([68.164.241.14] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZMn2-0005k4-00 for ltru@ietf.org; Fri, 20 May 2005 22:44:48 -0700 Message-ID: <002801c55dc8$929667a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B5A712C@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #967] address homograph issues in security considerations Date: Fri, 20 May 2005 22:47:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "McDonald, Ira" ; "Peter Constable" ; "LTRU Working Group" > Sent: Thursday, May 12, 2005 11:42 AM > Subject: RE: [Ltru] [psg.com #967] address homographissuesinsecurityconsiderations > > Text would be *most* helpful. ... In the interest of reaching closure on this item, as a technical contributor I'll propose some words that I think will start to address some of Ira's concerns. 1) In section 6 (security considerations) the first paragraph would need to be modified since there would no longer be just one issue. 2) Add the following paragraph to section 6: The limited repertoire of characters permitted in language tags provides few opportunities for homograph confusion. Whether there are any at all depends upon the font in use, but, for some widely used fonts, confusion between "O" and "0", or "I", "l", and "1" need to be considered as realistic possibilities. The language tag reviewer SHOULD reject registration requests for tags or subtags that could be confused in this way with existing ones. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 07:21:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS2q-0002xY-A2; Sat, 21 May 2005 07:21:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS2o-0002x6-A4 for ltru@megatron.ietf.org; Sat, 21 May 2005 07:21:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00664 for ; Sat, 21 May 2005 07:21:23 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZLHR-0005xl-Bp for ltru@ietf.org; Sat, 21 May 2005 00:08:06 -0400 Received: from h-68-164-241-14.snvacaid.dynamic.covad.net ([68.164.241.14] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZKzf-0002EM-00 for ltru@ietf.org; Fri, 20 May 2005 20:49:43 -0700 Message-ID: <007401c55db8$7e5b3780$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B65DD7B@irvmbxw01.quest.com> Date: Fri, 20 May 2005 20:52:19 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] [psg.com #997[ simplify ABNF by merging field and record-jar definitions X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Frank Ellermann" ; > Sent: Monday, May 16, 2005 9:53 AM > Subject: RE: [Ltru] Re: Open points before -02 ... > > > 3 - improve registry ABNF, simplify the corresponding chapter > > > > That was rejected, Addison wants to document the record-jar > > format, not its registry incarnation. That's backwards from > > my POV, mail (2822) and news (1036) use prose for the simple > > general format, and syntax for the header field details, but > > there's no rule to do it this way also in 3066bis. > > I suggested that an independent RFC be written to document record-jar for future generations, actually. > > In this case, I don't see the benefit of another ultra-complicated ABNF: > I don't think it will save very much text, if any, and it is hard to read. > Clarity is served by the current text/ABNF, I think. ... I've recorded this as issue [psg.com #997], and, based on this thread, given it a status of "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 07:21:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS3F-00034X-LU; Sat, 21 May 2005 07:21:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS3D-00033w-8N for ltru@megatron.ietf.org; Sat, 21 May 2005 07:21:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01012 for ; Sat, 21 May 2005 07:21:47 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZL80-0001j1-VM for ltru@ietf.org; Fri, 20 May 2005 23:58:22 -0400 Received: from h-68-164-241-14.snvacaid.dynamic.covad.net ([68.164.241.14] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZKqA-0000TS-00 for ltru@ietf.org; Fri, 20 May 2005 20:39:54 -0700 Message-ID: <006101c55db7$1e9e0d00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050519024804.GD28377@skunk.reutershealth.com> Date: Fri, 20 May 2005 20:42:31 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] [psg.com #998] fate of grandfathered tags when subtags registered or replacements found X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've created this ticket for followups to message http://www1.ietf.org/mail-archive/web/ltru/current/msg01782.html where John Cowan wrote: ================ The current draft can't make up its mind what to do about grandfathered tags that become ordinarily valid later on, as zh-yue will when we get ISO 693-3 tags. 2.2.2 says grandfathered tags can become redundant tags. 3.2 says the list of grandfathered tags is "permanent and stable", but grandfathered items can be deprecated. 3.3 says the Type field (which contains "grandfathered" as one option) MUST not be changed and is guaranteed stable over time. The last graf of 3.3 says grandfathered tags MUST become redundant if all their subtags become registered as an exception to the previous point. 3.4 says grandfathered tags may (not MAY) become deprecated due to registration of subtags. IMHO the resolution should be that grandfathered tags MUST become redundant (not deprecated) if all their subtags are registered, and deprecated if a replacement is found (like zh-cmn for zh-guoyu). ==================== Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 07:41:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSMa-0002aV-UN; Sat, 21 May 2005 07:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSMY-0002YH-VL for ltru@megatron.ietf.org; Sat, 21 May 2005 07:41:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06351 for ; Sat, 21 May 2005 07:41:46 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZIIH-00074B-Kl for ltru@ietf.org; Fri, 20 May 2005 20:56:45 -0400 Received: from h-68-166-188-60.snvacaid.dynamic.covad.net ([68.166.188.60] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZI0V-0005y8-00 for ltru@ietf.org; Fri, 20 May 2005 17:38:23 -0700 Message-ID: <034e01c55d9d$c4925460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 20 May 2005 17:41:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Tickets [psg.com #993] through [psg.com #996] X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've recorded a few more issues and their resolutions in the tracker at https://rt.psg.com/ (user and password ietf). If you think any of these needs to be reopened or merits further discussion, please use the appropriate subject line: [psg.com #993] Shall multiple extlang tags be permitted in the syntax? resolved [psg.com #994] use postal codes to identify regions rejected [psg.com #995] publish registry in form of annual RFC rejected [psg.com #996] editorial comments on -00 matching draft resolved Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 08:06:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSk5-00015j-Kb; Sat, 21 May 2005 08:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSk4-00013w-Ax for ltru@megatron.ietf.org; Sat, 21 May 2005 08:06:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05497 for ; Sat, 21 May 2005 07:40:34 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZJfs-0002H1-Bg for ltru@ietf.org; Fri, 20 May 2005 22:25:13 -0400 Received: from h-68-166-188-60.snvacaid.dynamic.covad.net ([68.166.188.60] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZJO7-0003pU-00 for ltru@ietf.org; Fri, 20 May 2005 19:06:51 -0700 Message-ID: <000801c55daa$1eb79b60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B732A1A@irvmbxw01.quest.com> <032b01c55c94$e0ab11f0$4d6e3009@sanjose.ibm.com> Subject: Re: [Ltru] [psg.com #992] provide way to alias language-variant combination to a lang-extlang combination Date: Fri, 20 May 2005 19:08:53 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Mark Davis" > To: "Addison Phillips" ; "John Cowan" ; "Randy Presuhn" > Cc: > Sent: Thursday, May 19, 2005 10:04 AM > Subject: Re: [Ltru] [psg.com #992] provide way to aliaslanguage-variantcombination to a lang-extlang combination > > I agree. > > ?Mark ... Ok, it looks like there's a consensus resolution based on the proposal in http://www1.ietf.org/mail-archive/web/ltru/current/msg01780.html So, I'll mark this one "resolved". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 08:06:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSk5-00016B-S7; Sat, 21 May 2005 08:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSk4-00014m-At for ltru@megatron.ietf.org; Sat, 21 May 2005 08:06:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06045 for ; Sat, 21 May 2005 07:41:19 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZIsY-0002L3-SJ for ltru@ietf.org; Fri, 20 May 2005 21:34:16 -0400 Received: from h-68-166-188-60.snvacaid.dynamic.covad.net ([68.166.188.60] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZIan-0003se-00 for ltru@ietf.org; Fri, 20 May 2005 18:15:54 -0700 Message-ID: <001e01c55da3$0186efc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B732A1A@irvmbxw01.quest.com> <032b01c55c94$e0ab11f0$4d6e3009@sanjose.ibm.com> Subject: Re: [Ltru] [psg.com #992] provide way to alias language-variant combination to a lang-extlang combination Date: Fri, 20 May 2005 18:18:33 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Mark Davis" > To: "Addison Phillips" ; "John Cowan" ; "Randy Presuhn" > Cc: > Sent: Thursday, May 19, 2005 10:04 AM > Subject: Re: [Ltru] [psg.com #992] provide way to aliaslanguage-variantcombination to a lang-extlang combination > > I agree. > > ?Mark ... Ok, it looks like there's a consensus resolution based on the proposal in http://www1.ietf.org/mail-archive/web/ltru/current/msg01780.html So, I'll mark this one "resolved". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 08:06:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSkF-0001A7-3u; Sat, 21 May 2005 08:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSkD-00019R-VT for ltru@megatron.ietf.org; Sat, 21 May 2005 08:06:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06436 for ; Sat, 21 May 2005 07:41:54 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZI7h-0006AX-Vw for ltru@ietf.org; Fri, 20 May 2005 20:45:51 -0400 Received: from h-68-166-188-60.snvacaid.dynamic.covad.net ([68.166.188.60] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DZHpy-0003wm-00 for ltru@ietf.org; Fri, 20 May 2005 17:27:30 -0700 Message-ID: <033201c55d9c$3de004e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B65E69A@irvmbxw01.quest.com> Subject: Re: [Ltru] RE: Some comments on draft-ietf-ltru-matching-00 Date: Fri, 20 May 2005 17:30:07 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Michael A. Patton" ; > Cc: > Sent: Tuesday, May 17, 2005 3:48 PM > Subject: [Ltru] RE: Some comments on draft-ietf-ltru-matching-00 ... > I used xml2rfc to generate the text. I'll check on how the reference > is tagged so that it is generated correctly in the next version. ... My personal preference when using xml2rfc is to use the option It gets rid of some of the redundancy, both in the XML source and in the formatted output. The complete option set I use is: ... These are (other than toc) a matter of editorial preference, unless the WG should feel strongly about some aspect of the formatting. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 08:09:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSnS-0002II-Bl; Sat, 21 May 2005 08:09:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSnQ-0002H5-UZ for ltru@megatron.ietf.org; Sat, 21 May 2005 08:09:37 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09785 for ; Sat, 21 May 2005 08:09:34 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DZOKa-0002KC-KG for ltru@lists.ietf.org; Sat, 21 May 2005 09:23:32 +0200 Received: from du-001-245.access.de.clara.net ([212.82.227.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 May 2005 09:23:32 +0200 Received: from nobody by du-001-245.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 May 2005 09:23:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 21 May 2005 09:23:03 +0200 Organization: Lines: 17 Message-ID: <428EE1D7.76@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-245.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support ed X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira wrote: > The problem we're wrestling with is that our ISO/UN sources > are _not_ entirely stable and we intuitively think we should > try to achieve better stability in the IANA Language Subtag > Registry. My intuition was and is "mirror the sources as long as possible under the rule of stability". Plus an emergency exit for cases like CS etc. > We're probably catching at moonbeams... ...some cosmic event like the CS disaster, yes. It's rare. The "Use:" concept is IMHO a pretty simple way to survive it. But "Use:" is dynamic, not static, and Mark hates it. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 08:13:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSos-0002zG-S7; Sat, 21 May 2005 08:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZSlj-0001Se-LN for ltru@megatron.ietf.org; Sat, 21 May 2005 08:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06252 for ; Sat, 21 May 2005 07:41:37 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZIV6-000885-0p for ltru@ietf.org; Fri, 20 May 2005 21:10:00 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 17:51:31 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 17:51:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported Date: Fri, 20 May 2005 17:51:00 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #954] all aliases must be equally supported Thread-Index: AcVdZW9B/M4Ta5avSZSdF838YoYgsAAN7jlQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 21 May 2005 00:51:31.0876 (UTC) FILETIME=[3ADE5640:01C55D9F] X-Spam-Score: 1.4 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: John Cowan [mailto:jcowan@reutershealth.com] > A language with both a 639-1 and a 639-2 > code must *always* use the 639-1 code in RFC 3066 and all its future > successors. The ISO 639 RA/JAC has guaranteed that no existing language > with a 639-2 code will ever be assigned a novel 639-1 code. In effect, > the list of 639-1 codes is frozen at least until 639-3 comes on line > (and I bet it's still in fact frozen then). >=20 > Peter, do you have any idea whether any of the new languages in 639-3 (new > to ISO, that is) would be plausible candidates for ISO 639-1 registration? > This is going to matter in RFC 3066ter. WRT your last question, I cannot say -- I haven't thought about it in any detail; I think there are languages already in 639-2 but not 639-1 that may in the near future meet the criteria for inclusion in 639-1. What I *can* say is that there is no plan to add entries to 639-1 as a result of the development of 639-3 except possibly in a very small number of cases (if any -- I'd have to check) of problems existing in 639 as it exists now. (E.g. there's a current quirk in that 639-1 has an entry for Serbo-Croatian, but 639-2 does not. The LOC site shows "sh" as having been deprecated in 2000, but that appears to be incorrect since it is included in the code table of ISO 639-1:2002 with no indication of deprecation.) I suggested some time ago (before the WG) that we don't have to, and should not, leave ourselves at the mercy of the whims of a Joint Advisory Committee that is happy to promise certain things today, but may not ten years from now when it's composed of different people. My proposed fix was that we simply freeze the set of ISO 639-1 IDs that are permitted in IETF language tags to those that exist now.=20 My suggestion wasn't accepted exactly, though it did result in a change to the text of 2.2.1; specifically, the following got added: In order to avoid instability of the canonical form of tags, if a two character code is added to ISO 639-1 for a language for which a three character code was already included in ISO 639-2, the two character code will not be added as a subtag in the registry. See Section 3.3. I'd still prefer to lock the alpha-2 IDs to a frozen list, but this paragraph, along with the intent expressed by the current JAC, is sufficient. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 12:25:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZWnB-0000O1-Gl; Sat, 21 May 2005 12:25:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZWnA-0000Nt-DX for ltru@megatron.ietf.org; Sat, 21 May 2005 12:25:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03760 for ; Sat, 21 May 2005 12:25:33 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZX4j-0001Me-Qg for ltru@ietf.org; Sat, 21 May 2005 12:43:48 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4LGPMp4004066; Sat, 21 May 2005 12:25:23 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 21 May 2005 12:25:21 -0400 Date: Sat, 21 May 2005 12:25:21 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] [psg.com #967] address homograph issues in security considerations Message-ID: <20050521162520.GB18016@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B5A712C@irvmbxw01.quest.com> <002801c55dc8$929667a0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002801c55dc8$929667a0$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > The limited repertoire of characters permitted in language tags provides > few opportunities for homograph confusion. Whether there are any at > all depends upon the font in use, but, for some widely used fonts, > confusion between "O" and "0", or "I", "l", and "1" need to be considered > as realistic possibilities. The language tag reviewer SHOULD reject > registration requests for tags or subtags that could be confused in this > way with existing ones. I think this is too strong because of the ell vs Eye contrast combined with the official caselessness of tags. We already have 23 pairs of subtags that differ only in having an ell vs. an eye. For example, ia and la are both valid language subtags, as are sal and sai; GI and GL are both valid region subtags. In fact, ii, li, IL, and LI are all valid subtags. As long as everything is cased consistently, there is no problem, but if someone uses anomalous casing, these would become a problem under your proposal. I propose therefore that only zero/oh, one/eye, and one/ell be treated as confusables; these could arise only in variant subtags. -- John Cowan www.reutershealth.com www.ccil.org/~cowan jcowan@reutershealth.com Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, The day and hour soon are coming / When all the IT folks say "Gosh!" It isn't from a clever lawsuit / That Windowsland will finally fall, But thousands writing open source code / Like mice who nibble through a wall. --The Linux-nationale by Greg Baker _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 13:47:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZY4B-0002yF-Th; Sat, 21 May 2005 13:47:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZY49-0002yA-W8 for ltru@megatron.ietf.org; Sat, 21 May 2005 13:47:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09619 for ; Sat, 21 May 2005 13:47:12 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZYLk-0003GU-Pl for ltru@ietf.org; Sat, 21 May 2005 14:05:26 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 21 May 2005 10:46:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Sat, 21 May 2005 10:46:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F33B6@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Thread-Index: AcVd/puotMDglTyoRF+3x2OnC0G1xgAK77UA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 21 May 2005 17:46:58.0382 (UTC) FILETIME=[15E55EE0:01C55E2D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org That turns out not to be quite true. Mark and I had a chat last night = about this issue, which, it turns out, hinges on what canonicalization = of a language tag means. What we discussed was basically that the region subtag one chooses = ("Choice of Language Tag") does evolve along the lines of the "Use" = concept. It makes eminent sense and the compromise I suggested earlier = in the week is that way to embody that in the draft. Then there is the question of canonicalization. Canonicalization for = what? For comparison and matching, of course. If you look at the way the = Use or Canonical-Value concept is set up, there is a date (in the = Deprecated field) associated with each mapping. This means that: 1. For any given tag, you can construct what the comparable tag would = have been for any given earlier date. 2. For any given tag, you can construct the set of comparable tags that = are valid at any given date (up to the date of the registry). 3. The purpose for doing this is to compare tags with ranges. In other = words, this text should appear in the matching draft. (Whether it = appears in the registry draft is a separate matter, please note). This means that the Use/Canonical-Value setup as described in the email = thread during this past week *does* meet Mark's requirements for = "canonicalization" because the data for supporting the relationships he = cares about is in the registry. The next step is to incorporate the text = into the draft, which I will set about doing over this weekend, so we = can see what it looks like. Any thoughts on whether to keep the canonicalization section in the = registry draft or just have it in matching? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?5?21? 0:23 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support = ed >=20 > McDonald, Ira wrote: >=20 > > The problem we're wrestling with is that our ISO/UN sources > > are _not_ entirely stable and we intuitively think we should > > try to achieve better stability in the IANA Language Subtag > > Registry. >=20 > My intuition was and is "mirror the sources as long as possible > under the rule of stability". Plus an emergency exit for cases > like CS etc. >=20 > > We're probably catching at moonbeams... >=20 > ...some cosmic event like the CS disaster, yes. It's rare. > The "Use:" concept is IMHO a pretty simple way to survive it. > But "Use:" is dynamic, not static, and Mark hates it. Bye. >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 14:24:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZYe3-0002MS-66; Sat, 21 May 2005 14:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZYe1-0002JL-CL for ltru@megatron.ietf.org; Sat, 21 May 2005 14:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12035 for ; Sat, 21 May 2005 14:24:15 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZYvd-0004ER-IU for ltru@ietf.org; Sat, 21 May 2005 14:42:30 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4LINr9e015199; Sat, 21 May 2005 11:23:58 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 21 May 2005 11:23:54 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Frank Ellermann , ltru@ietf.org Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Sat, 21 May 2005 11:23:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Addison, Please keep a Canonicalization section in ltru-registry draft. I will urge that we say something like: "Content authors and content authoring tools that create language tags MUST create well-formed tags and SHOULD create Canonical tags, for near-term interoperability and long-term accessibility of the content." I'm writing some text for addition to section 1 (a section 1.1 'Conformance Terminology' and section 1.2 'Language Tag Terminology') that attempts to define the subjects of imperative verbs as they occur in later sections - I'll send a draft in a day or two. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Saturday, May 21, 2005 1:47 PM > To: Frank Ellermann; ltru@ietf.org > Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally > support ed > > > That turns out not to be quite true. Mark and I had a chat > last night about this issue, which, it turns out, hinges on > what canonicalization of a language tag means. > > What we discussed was basically that the region subtag one > chooses ("Choice of Language Tag") does evolve along the > lines of the "Use" concept. It makes eminent sense and the > compromise I suggested earlier in the week is that way to > embody that in the draft. > > Then there is the question of canonicalization. > Canonicalization for what? For comparison and matching, of > course. If you look at the way the Use or Canonical-Value > concept is set up, there is a date (in the Deprecated field) > associated with each mapping. This means that: > > 1. For any given tag, you can construct what the comparable > tag would have been for any given earlier date. > > 2. For any given tag, you can construct the set of comparable > tags that are valid at any given date (up to the date of the > registry). > > 3. The purpose for doing this is to compare tags with ranges. > In other words, this text should appear in the matching > draft. (Whether it appears in the registry draft is a > separate matter, please note). > > This means that the Use/Canonical-Value setup as described in > the email thread during this past week *does* meet Mark's > requirements for "canonicalization" because the data for > supporting the relationships he cares about is in the > registry. The next step is to incorporate the text into the > draft, which I will set about doing over this weekend, so we > can see what it looks like. > > Any thoughts on whether to keep the canonicalization section > in the registry draft or just have it in matching? > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Sent: 2005?5?21? 0:23 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support ed > > McDonald, Ira wrote: > > > The problem we're wrestling with is that our ISO/UN sources > > are _not_ entirely stable and we intuitively think we should > > try to achieve better stability in the IANA Language Subtag > > Registry. > > My intuition was and is "mirror the sources as long as possible > under the rule of stability". Plus an emergency exit for cases > like CS etc. > > > We're probably catching at moonbeams... > > ...some cosmic event like the CS disaster, yes. It's rare. > The "Use:" concept is IMHO a pretty simple way to survive it. > But "Use:" is dynamic, not static, and Mark hates it. Bye. > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 14:51:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZZ3s-0007iM-CQ; Sat, 21 May 2005 14:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZZ3q-0007hf-GK for ltru@megatron.ietf.org; Sat, 21 May 2005 14:50:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13971 for ; Sat, 21 May 2005 14:50:56 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZZLN-0004hO-JI for ltru@ietf.org; Sat, 21 May 2005 15:09:11 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4LIoXua253592 for ; Sat, 21 May 2005 14:50:33 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4LIoXEL157276 for ; Sat, 21 May 2005 12:50:33 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4LIoWhi017815 for ; Sat, 21 May 2005 12:50:32 -0600 Received: from markdavis (sig-9-48-119-26.mts.ibm.com [9.48.119.26]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4LIoVPS017785; Sat, 21 May 2005 12:50:32 -0600 Message-ID: <00ea01c55e35$f5b3b500$27743009@sanjose.ibm.com> From: "Mark Davis" To: "McDonald, Ira" , "'Addison Phillips'" , "Frank Ellermann" , References: Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Sat, 21 May 2005 11:50:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j4LIoXua253592 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The problem is that there are two communities of users. For Frank (and Ira?), not having the latest codes be in the canonical form is (I guess) = not fashionable (ok, I'm being a bit flip, but I really don't know what their rationale is). For us, having unstable canonical tags is useless. We (and the vast major= ity of the world's infrastructure) can't canonicalize to the latest codes because that would invalidate all the databases that use the previously-canonical codes as keys. What Addison and I realized is that the registry already has the informat= ion to support both types of canonicalization. I think we have two choices: A. define two specifications of the two types of canonicalization for the different communities of interest in this document, or B. what may be more practical and useful -- since canonicalization is intimately associated with matching -- push the two specifications into t= he matching document. =E2=80=8EMark ----- Original Message -----=20 From: "McDonald, Ira" To: "'Addison Phillips'" ; "Frank Ellermann" ; Sent: Saturday, May 21, 2005 11:23 Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally suppor= t ed > Hi Addison, > > Please keep a Canonicalization section in ltru-registry draft. > I will urge that we say something like: > > "Content authors and content authoring tools that create language > tags MUST create well-formed tags and SHOULD create Canonical tags, > for near-term interoperability and long-term accessibility of the > content." > > I'm writing some text for addition to section 1 (a section 1.1 > 'Conformance Terminology' and section 1.2 'Language Tag Terminology') > that attempts to define the subjects of imperative verbs as they > occur in later sections - I'll send a draft in a day or two. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Addison Phillips > > Sent: Saturday, May 21, 2005 1:47 PM > > To: Frank Ellermann; ltru@ietf.org > > Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally > > support ed > > > > > > That turns out not to be quite true. Mark and I had a chat > > last night about this issue, which, it turns out, hinges on > > what canonicalization of a language tag means. > > > > What we discussed was basically that the region subtag one > > chooses ("Choice of Language Tag") does evolve along the > > lines of the "Use" concept. It makes eminent sense and the > > compromise I suggested earlier in the week is that way to > > embody that in the draft. > > > > Then there is the question of canonicalization. > > Canonicalization for what? For comparison and matching, of > > course. If you look at the way the Use or Canonical-Value > > concept is set up, there is a date (in the Deprecated field) > > associated with each mapping. This means that: > > > > 1. For any given tag, you can construct what the comparable > > tag would have been for any given earlier date. > > > > 2. For any given tag, you can construct the set of comparable > > tags that are valid at any given date (up to the date of the > > registry). > > > > 3. The purpose for doing this is to compare tags with ranges. > > In other words, this text should appear in the matching > > draft. (Whether it appears in the registry draft is a > > separate matter, please note). > > > > This means that the Use/Canonical-Value setup as described in > > the email thread during this past week *does* meet Mark's > > requirements for "canonicalization" because the data for > > supporting the relationships he cares about is in the > > registry. The next step is to incorporate the text into the > > draft, which I will set about doing over this weekend, so we > > can see what it looks like. > > > > Any thoughts on whether to keep the canonicalization section > > in the registry draft or just have it in matching? > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Frank Ellermann > > Sent: 2005?5?21? 0:23 > > To: ltru@ietf.org > > Subject: [Ltru] Re: [psg.com #954] all aliases must be equally suppor= t ed > > > > McDonald, Ira wrote: > > > > > The problem we're wrestling with is that our ISO/UN sources > > > are _not_ entirely stable and we intuitively think we should > > > try to achieve better stability in the IANA Language Subtag > > > Registry. > > > > My intuition was and is "mirror the sources as long as possible > > under the rule of stability". Plus an emergency exit for cases > > like CS etc. > > > > > We're probably catching at moonbeams... > > > > ...some cosmic event like the CS disaster, yes. It's rare. > > The "Use:" concept is IMHO a pretty simple way to survive it. > > But "Use:" is dynamic, not static, and Mark hates it. Bye. > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 16:13:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZaLt-0007UO-Cg; Sat, 21 May 2005 16:13:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZaLr-0007UG-SO for ltru@megatron.ietf.org; Sat, 21 May 2005 16:13:40 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22884 for ; Sat, 21 May 2005 16:13:36 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DZaKU-0004ja-Je for ltru@lists.ietf.org; Sat, 21 May 2005 22:12:14 +0200 Received: from du-001-245.access.de.clara.net ([212.82.227.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 May 2005 22:12:14 +0200 Received: from nobody by du-001-245.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 May 2005 22:12:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 21 May 2005 22:06:05 +0200 Organization: Lines: 37 Message-ID: <428F94AD.6AD1@xyzzy.claranet.de> References: <00ea01c55e35$f5b3b500$27743009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-245.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support ed X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > For Frank (and Ira?), not having the latest codes be in the > canonical form is (I guess) not fashionable (ok, I'm being a > bit flip, but I really don't know what their rationale is). User1: My cc just changed from GE to XX... M.D. : Don't panic, GE is still valid. User1: But the new government is very XX. M.D. : Forget governments. This is the Internet. Not a zoo. User1: But ISO 3166 also says XX. M.D. : ISO says many things. IANA knows what's good for you. User2 (interrupting): IANA has GG, can I use it ? M.D. : That's a ccTLD and no country code. User1: So I should use GE instead of XX ? M.D. : Yes. User2: I want GG. M.D. : I'm only talking with User1, *plonk* User1: Thanks, and there won't be a problem with GE ? M.D. : Of course not, it's stable and canonical forever. [some years later, Georgia finds that GE is free and grabs it] User3: What are these crazy XX-bastards doing, are they mad ? User2 (interrupting): I want GG. User1: GE is XX. User3: No, GE is Georgia. Idiot. User2: It's not GG. User3: GE is Georgia. *plonk* User1: No, it's XX. M.D. : Wait a moment. User3: We waited 50 years, that's long enough. User1: No, GE is XX, I was 20 years in prison for saying GE. User3: I've already told you that you're an idiot. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 21 16:27:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZaZR-0000r5-MM; Sat, 21 May 2005 16:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZaZQ-0000r0-7n for ltru@megatron.ietf.org; Sat, 21 May 2005 16:27:40 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24056 for ; Sat, 21 May 2005 16:27:37 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050521202707.LVMM4191.mta13.adelphia.net@DEWELL> for ; Sat, 21 May 2005 16:27:07 -0400 Message-ID: <00bb01c55e43$5e70d5c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 21 May 2005 13:26:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #967] address homograph issues in security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > I think this is too strong because of the ell vs Eye contrast combined > with the official caselessness of tags. We already have 23 pairs of > subtags that differ only in having an ell vs. an eye. For example, ia > and la are both valid language subtags, as are sal and sai; GI and GL > are both valid region subtags. In fact, ii, li, IL, and LI are all > valid subtags. > > As long as everything is cased consistently, there is no problem, but > if someone uses anomalous casing, these would become a problem under > your proposal. I propose therefore that only zero/oh, one/eye, and > one/ell be treated as confusables; these could arise only in variant > subtags. +l -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 22 02:13:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZjiV-0006bW-Bz; Sun, 22 May 2005 02:13:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZjiU-0006bR-02 for ltru@megatron.ietf.org; Sun, 22 May 2005 02:13:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10721 for ; Sun, 22 May 2005 02:13:34 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DZk09-0006rg-6f for ltru@ietf.org; Sun, 22 May 2005 02:31:54 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Sat, 21 May 2005 23:09:07 -0700 Message-ID: <005e01c55e95$5de20a00$54713009@sanjose.ibm.com> From: "Mark Davis" To: "LTRU Working Group" , "Frank Ellermann" References: <00ea01c55e35$f5b3b500$27743009@sanjose.ibm.com> <428F94AD.6AD1@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Sat, 21 May 2005 23:13:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA10721 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I was trying to describe a compromise approach. I can't make any sense of what you are trying to say below, but as I said, it doesn't much matter. = We can support both formulations, a stable canonical form and an unstable (p= ick latest) one, the one you want. =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Saturday, May 21, 2005 13:06 Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support ed > Mark Davis wrote: > > > For Frank (and Ira?), not having the latest codes be in the > > canonical form is (I guess) not fashionable (ok, I'm being a > > bit flip, but I really don't know what their rationale is). > > User1: My cc just changed from GE to XX... > M.D. : Don't panic, GE is still valid. > User1: But the new government is very XX. > M.D. : Forget governments. This is the Internet. Not a zoo. > User1: But ISO 3166 also says XX. > M.D. : ISO says many things. IANA knows what's good for you. > User2 (interrupting): IANA has GG, can I use it ? > M.D. : That's a ccTLD and no country code. > User1: So I should use GE instead of XX ? > M.D. : Yes. > User2: I want GG. > M.D. : I'm only talking with User1, *plonk* > User1: Thanks, and there won't be a problem with GE ? > M.D. : Of course not, it's stable and canonical forever. > > [some years later, Georgia finds that GE is free and grabs it] > > User3: What are these crazy XX-bastards doing, are they mad ? > User2 (interrupting): I want GG. > User1: GE is XX. > User3: No, GE is Georgia. Idiot. > User2: It's not GG. > User3: GE is Georgia. *plonk* > User1: No, it's XX. > M.D. : Wait a moment. > User3: We waited 50 years, that's long enough. > User1: No, GE is XX, I was 20 years in prison for saying GE. > User3: I've already told you that you're an idiot. > > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 22 13:26:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZuDV-0001Fz-AD; Sun, 22 May 2005 13:26:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZuDQ-0001Fu-Kn for ltru@megatron.ietf.org; Sun, 22 May 2005 13:26:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05649 for ; Sun, 22 May 2005 13:26:13 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZuVD-0007nH-Bb for ltru@ietf.org; Sun, 22 May 2005 13:44:40 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 22 May 2005 10:26:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Date: Sun, 22 May 2005 10:26:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F33D0@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #954] all aliases must be equally support ed Thread-Index: AcVelaIhADFbrUXvT2GSZqgbPrZwQwAT7/4g From: "Addison Phillips" To: "Mark Davis" , "LTRU Working Group" , "Frank Ellermann" X-OriginalArrivalTime: 22 May 2005 17:26:02.0843 (UTC) FILETIME=[53F312B0:01C55EF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1302496644==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1302496644== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 fnNpZ2h+IFdlJ3JlIGFsbCBpbiByYWdpbmcgYWdyZWVtZW50IGhlcmUuDQoNClRoZSBwcm9wb3Nh bCBpcyB0byBoYXZlICJjYW5vbmljYWwiIG1hcHBpbmdzIHRoYXQgdHJhY2sgSVNPIDMxNjYuIFN1 YnRhZ3MgdGhhdCBhcmUgZGVwcmVjYXRlZCAoaS5lLiB3aXRoZHJhd24gYnkgSVNPIDMxNjYpIHJl bWFpbiB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzIChpbiBJU08gMzE2NiB0aGV5IGRpc2FwcGVhciwg YnV0IGluIGxhbmd1YWdlIHRhZ3MgdGhleSByZW1haW4gaW4gdGhlIHJlZ2lzdHJ5IHdpdGggYSBu b3RhdGlvbiBzaG93aW5nIHRoZSBkYXRlIHRoZXkgd2VyZSB3aXRoZHJhd24gYnkgSVNPIDMxNjYp LiANCg0KTGFuZ3VhZ2UgdGFncyB0aGF0IHVzZWQgKG5vdGljZSB0aGUgdGVuc2UpIHRoZSBvbGQg Y29kZSByZW1haW4gdmFsaWQgYW5kIGluICJjYW5vbmljYWwgZm9ybSIgKHdoYXRldmVyIHRoYXQg bWVhbnMpLiBUaGVyZSBpcyBhbiBhYmlsaXR5IHRvIGZpZ3VyZSBvdXQgZnJvbSB0aGUgcmVnaXN0 cnkgd2hhdCB0aGUgIm1vZGVybiBjb2RlIiBpcy4gTm90aWNlIHRoYXQgc29tZXRpbWVzIHdoZW4g YSBjb3VudHJ5IGNoYW5nZXMgaXRzIGNvZGUgdGhlcmUgaXMgYWxzbyBhIHJlYWwsIHByYWN0aWNh bCBjaGFuZ2UgaW4gdGhlIG5hdGlvbmFsIGVudGl0eS4gQW5kIHNvbWV0aW1lcyBpdCBpcyBqdXN0 IGEgY29kZSBjaGFuZ2UuIEhvdyBjbG9zZSBvciBmYXIgdGhpcyBmYWxscyBmcm9tIG5hdGlvbmFs IGlkZW50aXR5IGFuZCBlbW90aW9uYWwgY29ubmVjdGlvbiBpc3N1ZXMgZGVwZW5kcyBvbiBlYWNo IGNhc2UuDQoNCkxldCdzIGRvIHRoZSB0ZXh0IGFuZCBzZWUgaG93IHdlbGwgdGhhdCBzdWl0cyBl dmVyeW9uZSdzIG5lZWRzLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2Jh bGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlv bmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMg bm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRv Omx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIE1hcmsgRGF2aXMN Cj4gU2VudDogMjAwNeW5tDXmnIgyMeaXpSAyMzoxMw0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3Vw OyBGcmFuayBFbGxlcm1hbm4NCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogW3BzZy5jb20gIzk1 NF0gYWxsIGFsaWFzZXMgbXVzdCBiZSBlcXVhbGx5IHN1cHBvcnQNCj4gZWQNCj4gDQo+IEkgd2Fz IHRyeWluZyB0byBkZXNjcmliZSBhIGNvbXByb21pc2UgYXBwcm9hY2guIEkgY2FuJ3QgbWFrZSBh bnkgc2Vuc2Ugb2YNCj4gd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkgYmVsb3csIGJ1dCBhcyBJ IHNhaWQsIGl0IGRvZXNuJ3QgbXVjaCBtYXR0ZXIuDQo+IFdlDQo+IGNhbiBzdXBwb3J0IGJvdGgg Zm9ybXVsYXRpb25zLCBhIHN0YWJsZSBjYW5vbmljYWwgZm9ybSBhbmQgYW4gdW5zdGFibGUNCj4g KHBpY2sNCj4gbGF0ZXN0KSBvbmUsIHRoZSBvbmUgeW91IHdhbnQuDQo+IA0KPiDigI5NYXJrDQo+ IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJGcmFuayBFbGxlcm1h bm4iIDxub2JvZHlAeHl6enkuY2xhcmFuZXQuZGU+DQo+IFRvOiA8bHRydUBpZXRmLm9yZz4NCj4g U2VudDogU2F0dXJkYXksIE1heSAyMSwgMjAwNSAxMzowNg0KPiBTdWJqZWN0OiBbTHRydV0gUmU6 IFtwc2cuY29tICM5NTRdIGFsbCBhbGlhc2VzIG11c3QgYmUgZXF1YWxseSBzdXBwb3J0IGVkDQo+ IA0KPiANCj4gPiBNYXJrIERhdmlzIHdyb3RlOg0KPiA+DQo+ID4gPiBGb3IgRnJhbmsgKGFuZCBJ cmE/KSwgbm90IGhhdmluZyB0aGUgbGF0ZXN0IGNvZGVzIGJlIGluIHRoZQ0KPiA+ID4gY2Fub25p Y2FsIGZvcm0gaXMgKEkgZ3Vlc3MpIG5vdCBmYXNoaW9uYWJsZSAob2ssIEknbSBiZWluZyBhDQo+ ID4gPiBiaXQgZmxpcCwgYnV0IEkgcmVhbGx5IGRvbid0IGtub3cgd2hhdCB0aGVpciByYXRpb25h bGUgaXMpLg0KPiA+DQo+ID4gVXNlcjE6IE15IGNjIGp1c3QgY2hhbmdlZCBmcm9tIEdFIHRvIFhY Li4uDQo+ID4gTS5ELiA6IERvbid0IHBhbmljLCBHRSBpcyBzdGlsbCB2YWxpZC4NCj4gPiBVc2Vy MTogQnV0IHRoZSBuZXcgZ292ZXJubWVudCBpcyB2ZXJ5IFhYLg0KPiA+IE0uRC4gOiBGb3JnZXQg Z292ZXJubWVudHMuICBUaGlzIGlzIHRoZSBJbnRlcm5ldC4gIE5vdCBhIHpvby4NCj4gPiBVc2Vy MTogQnV0IElTTyAzMTY2IGFsc28gc2F5cyBYWC4NCj4gPiBNLkQuIDogSVNPIHNheXMgbWFueSB0 aGluZ3MuICBJQU5BIGtub3dzIHdoYXQncyBnb29kIGZvciB5b3UuDQo+ID4gVXNlcjIgKGludGVy cnVwdGluZyk6IElBTkEgaGFzIEdHLCBjYW4gSSB1c2UgaXQgPw0KPiA+IE0uRC4gOiBUaGF0J3Mg YSBjY1RMRCBhbmQgbm8gY291bnRyeSBjb2RlLg0KPiA+IFVzZXIxOiBTbyBJIHNob3VsZCB1c2Ug R0UgaW5zdGVhZCBvZiBYWCA/DQo+ID4gTS5ELiA6IFllcy4NCj4gPiBVc2VyMjogSSB3YW50IEdH Lg0KPiA+IE0uRC4gOiBJJ20gb25seSB0YWxraW5nIHdpdGggVXNlcjEsICpwbG9uayoNCj4gPiBV c2VyMTogVGhhbmtzLCBhbmQgdGhlcmUgd29uJ3QgYmUgYSBwcm9ibGVtIHdpdGggR0UgPw0KPiA+ IE0uRC4gOiBPZiBjb3Vyc2Ugbm90LCBpdCdzIHN0YWJsZSBhbmQgY2Fub25pY2FsIGZvcmV2ZXIu DQo+ID4NCj4gPiBbc29tZSB5ZWFycyBsYXRlciwgR2VvcmdpYSBmaW5kcyB0aGF0IEdFIGlzIGZy ZWUgYW5kIGdyYWJzIGl0XQ0KPiA+DQo+ID4gVXNlcjM6IFdoYXQgYXJlIHRoZXNlIGNyYXp5IFhY LWJhc3RhcmRzIGRvaW5nLCBhcmUgdGhleSBtYWQgPw0KPiA+IFVzZXIyIChpbnRlcnJ1cHRpbmcp OiBJIHdhbnQgR0cuDQo+ID4gVXNlcjE6IEdFIGlzIFhYLg0KPiA+IFVzZXIzOiBObywgR0UgaXMg R2VvcmdpYS4gIElkaW90Lg0KPiA+IFVzZXIyOiBJdCdzIG5vdCBHRy4NCj4gPiBVc2VyMzogR0Ug aXMgR2VvcmdpYS4gKnBsb25rKg0KPiA+IFVzZXIxOiBObywgaXQncyBYWC4NCj4gPiBNLkQuIDog V2FpdCBhIG1vbWVudC4NCj4gPiBVc2VyMzogV2Ugd2FpdGVkIDUwIHllYXJzLCB0aGF0J3MgbG9u ZyBlbm91Z2guDQo+ID4gVXNlcjE6IE5vLCBHRSBpcyBYWCwgSSB3YXMgMjAgeWVhcnMgaW4gcHJp c29uIGZvciBzYXlpbmcgR0UuDQo+ID4gVXNlcjM6IEkndmUgYWxyZWFkeSB0b2xkIHlvdSB0aGF0 IHlvdSdyZSBhbiBpZGlvdC4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBCeWUs IEZyYW5rDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiA+IEx0cnVAbGlzdHMu aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1 DQo+ID4NCj4gPg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYu b3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --===============1302496644== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1302496644==-- From ltru-bounces@lists.ietf.org Sun May 22 14:11:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZuuU-0006EN-MG; Sun, 22 May 2005 14:10:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZuuT-0006EF-0T for ltru@megatron.ietf.org; Sun, 22 May 2005 14:10:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09556 for ; Sun, 22 May 2005 14:10:44 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvCF-0001hM-Sk for ltru@ietf.org; Sun, 22 May 2005 14:29:10 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4MIARti000146 for ; Sun, 22 May 2005 11:10:27 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 22 May 2005 11:10:27 -0700 Message-ID: From: "McDonald, Ira" To: ltru@ietf.org Date: Sun, 22 May 2005 11:10:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] Fix for ambiguous conformance requirements X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi folks, Sunday (22 May 2005) Addison - Below is an update for section 1 of ltru-registry that resolves my concerns about implied performers of uppercase imperatives. ------------------------------------------------------------------------ (add title to last paragraph of section 1 and add one new paragraph) 1.1 Conformance Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [10]. Consistent with previous versions of this document, RFC 1766 [21] and RFC 3066 [23], most conformance requirements in this document are written in passive voice using uppercase conformance keywords. Content authors, authoring tools, content distributors, distribution tools, and content repositories (e.g., content servers and content archives) that create or copy language tags MUST comply with all of these conformance requirements. Content users and user tools (e.g., web browsers) that create or copy language tags in content queries SHOULD also comply with all of these conformance requirements. ------------------------------------------------------------------------ Comments? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 22 17:20:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZxsV-0003uA-TV; Sun, 22 May 2005 17:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZxsU-0003u1-14 for ltru@megatron.ietf.org; Sun, 22 May 2005 17:20:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26822 for ; Sun, 22 May 2005 17:20:51 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZyAJ-00083V-JC for ltru@ietf.org; Sun, 22 May 2005 17:39:20 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 22 May 2005 14:20:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Fix for ambiguous conformance requirements Date: Sun, 22 May 2005 14:20:42 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F33DE@irvmbxw01.quest.com> Thread-Topic: [Ltru] Fix for ambiguous conformance requirements Thread-Index: AcVe+Zf1boMb3IQVSSeZ3QpTn5T8IgAGbAUg From: "Addison Phillips" To: "McDonald, Ira" , X-OriginalArrivalTime: 22 May 2005 21:20:43.0061 (UTC) FILETIME=[1C69D650:01C55F14] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hmm... I'm not happy with this text. It is too vague for my tastes. First, many of the requirements in this document have nothing to do with = the listed implementation types or uses of language tags. They apply = strictly to the registry and its population and maintenance. Second, why do you think this is necessary? The MUST-ification and = SHOULD-ification of various items should apply to the audience = interested in that particular item without additional trappings. If one = or another requirement should be strengthened or relaxed, then let's = discuss that. If you think that different levels of MUST-ifying should = apply to different applications, then we should spell that out in place = and not vaguely mention it in the introduction. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of McDonald, Ira > Sent: 2005?5?22? 11:10 > To: ltru@ietf.org > Subject: [Ltru] Fix for ambiguous conformance requirements >=20 > Hi folks, Sunday (22 May = 2005) >=20 > Addison - Below is an update for section 1 of ltru-registry that > resolves my concerns about implied performers of uppercase = imperatives. >=20 > = ------------------------------------------------------------------------ >=20 > (add title to last paragraph of section 1 and add one new paragraph) >=20 > 1.1 Conformance Terminology >=20 > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this > document are to be interpreted as described in RFC 2119 [10]. >=20 > Consistent with previous versions of this document, RFC 1766 [21] > and RFC 3066 [23], most conformance requirements in this document > are written in passive voice using uppercase conformance keywords. > Content authors, authoring tools, content distributors, = distribution > tools, and content repositories (e.g., content servers and content > archives) that create or copy language tags MUST comply with all = of > these conformance requirements. Content users and user tools = (e.g., > web browsers) that create or copy language tags in content queries > SHOULD also comply with all of these conformance requirements. >=20 > = ------------------------------------------------------------------------ >=20 > Comments? >=20 > Cheers, > - Ira >=20 > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 11:18:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaEgy-0000VJ-MA; Mon, 23 May 2005 11:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaEgx-0000Ux-Ji for ltru@megatron.ietf.org; Mon, 23 May 2005 11:18:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04830 for ; Mon, 23 May 2005 11:18:03 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaEys-0007nC-9Z for ltru@ietf.org; Mon, 23 May 2005 11:36:41 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4NFHdke016122; Mon, 23 May 2005 08:17:43 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 23 May 2005 08:17:38 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , "McDonald, Ira" , ltru@ietf.org Subject: RE: [Ltru] Fix for ambiguous conformance requirements Date: Mon, 23 May 2005 08:17:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Addison, Sigh...I tried. Conformance requirements written in the passive imperative are essentially useless. A given actor (person or software) can be said to comply with a conformance requirement only if they are explicitly named as the subject of an active voice sentence. The whole section 2 is full of passive sentences about the MUST or SHOULD length/content/position of specific classes of language subtags. Why bother to have them? Conformance requirements never apply to _readers_. They only apply to _actors_. There is clearly no support on this mailing list for rewriting every conformance requirement to active voice with explicit actors. I'll stop wasting your time. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Sunday, May 22, 2005 5:21 PM > To: McDonald, Ira; ltru@ietf.org > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > > Hmm... I'm not happy with this text. It is too vague for my tastes. > > First, many of the requirements in this document have nothing > to do with the listed implementation types or uses of > language tags. They apply strictly to the registry and its > population and maintenance. > > Second, why do you think this is necessary? The > MUST-ification and SHOULD-ification of various items should > apply to the audience interested in that particular item > without additional trappings. If one or another requirement > should be strengthened or relaxed, then let's discuss that. > If you think that different levels of MUST-ifying should > apply to different applications, then we should spell that > out in place and not vaguely mention it in the introduction. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of McDonald, Ira > > Sent: 2005?5?22? 11:10 > > To: ltru@ietf.org > > Subject: [Ltru] Fix for ambiguous conformance requirements > > > > Hi folks, Sunday > (22 May 2005) > > > > Addison - Below is an update for section 1 of ltru-registry that > > resolves my concerns about implied performers of uppercase > imperatives. > > > > > -------------------------------------------------------------- > ---------- > > > > (add title to last paragraph of section 1 and add one new paragraph) > > > > 1.1 Conformance Terminology > > > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [10]. > > > > Consistent with previous versions of this document, RFC > 1766 [21] > > and RFC 3066 [23], most conformance requirements in > this document > > are written in passive voice using uppercase > conformance keywords. > > Content authors, authoring tools, content distributors, > distribution > > tools, and content repositories (e.g., content servers > and content > > archives) that create or copy language tags MUST comply > with all of > > these conformance requirements. Content users and user > tools (e.g., > > web browsers) that create or copy language tags in > content queries > > SHOULD also comply with all of these conformance requirements. > > > > > -------------------------------------------------------------- > ---------- > > > > Comments? > > > > Cheers, > > - Ira > > > > Ira McDonald (Musician / Software Architect) > > Blue Roof Music / High North Inc > > PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 16:15:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJGy-0000dY-1N; Mon, 23 May 2005 16:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJGv-0000ck-Q1 for ltru@megatron.ietf.org; Mon, 23 May 2005 16:11:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13431 for ; Mon, 23 May 2005 16:11:31 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaJYx-00063p-PU for ltru@ietf.org; Mon, 23 May 2005 16:30:12 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 13:11:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Fix for ambiguous conformance requirements Date: Mon, 23 May 2005 13:11:10 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3840@irvmbxw01.quest.com> Thread-Topic: [Ltru] Fix for ambiguous conformance requirements Thread-Index: AcVfqp8lxkpoyBNHRuCDizfn3P/4CgAKDqIg From: "Addison Phillips" To: "McDonald, Ira" , X-OriginalArrivalTime: 23 May 2005 20:11:11.0582 (UTC) FILETIME=[906E67E0:01C55FD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Yes, but... The conformance requirements in section 2 describe the grammar of = language tags as defined by the ABNF. The tone and form is the same as = RFC 3066 and RFC 1766 before it. Do you really think anyone will be = confused by that? Here is one example: Script subtags MUST immediately follow the primary language subtag = and all extended language subtags and MUST occur before any other type = of subtag described below. Most of the other conformance requirements apply to specific actors, who = are specified. It is possible that we could rewrite section 2 to be more = melodious. For example: When forming a language tag, the script subtag MUST immediately = follow the primary language subtag and all extended language subtags and = MUST occur before any other type of subtag described below. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: 2005?5?23? 8:18 > To: Addison Phillips; McDonald, Ira; ltru@ietf.org > Subject: RE: [Ltru] Fix for ambiguous conformance requirements >=20 > Hi Addison, >=20 > Sigh...I tried. >=20 > Conformance requirements written in the passive imperative are > essentially useless. A given actor (person or software) can be > said to comply with a conformance requirement only if they are > explicitly named as the subject of an active voice sentence. >=20 > The whole section 2 is full of passive sentences about the MUST > or SHOULD length/content/position of specific classes of language > subtags. Why bother to have them? Conformance requirements > never apply to _readers_. They only apply to _actors_. >=20 > There is clearly no support on this mailing list for rewriting > every conformance requirement to active voice with explicit actors. >=20 > I'll stop wasting your time. >=20 > Cheers, > - Ira >=20 > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com >=20 > > -----Original Message----- > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > Sent: Sunday, May 22, 2005 5:21 PM > > To: McDonald, Ira; ltru@ietf.org > > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > > > > > Hmm... I'm not happy with this text. It is too vague for my tastes. > > > > First, many of the requirements in this document have nothing > > to do with the listed implementation types or uses of > > language tags. They apply strictly to the registry and its > > population and maintenance. > > > > Second, why do you think this is necessary? The > > MUST-ification and SHOULD-ification of various items should > > apply to the audience interested in that particular item > > without additional trappings. If one or another requirement > > should be strengthened or relaxed, then let's discuss that. > > If you think that different levels of MUST-ifying should > > apply to different applications, then we should spell that > > out in place and not vaguely mention it in the introduction. > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] On > > > Behalf Of McDonald, Ira > > > Sent: 2005?5?22? 11:10 > > > To: ltru@ietf.org > > > Subject: [Ltru] Fix for ambiguous conformance requirements > > > > > > Hi folks, Sunday > > (22 May 2005) > > > > > > Addison - Below is an update for section 1 of ltru-registry that > > > resolves my concerns about implied performers of uppercase > > imperatives. > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > (add title to last paragraph of section 1 and add one new = paragraph) > > > > > > 1.1 Conformance Terminology > > > > > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", > > "SHALL NOT", > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > "OPTIONAL" in this > > > document are to be interpreted as described in RFC 2119 [10]. > > > > > > Consistent with previous versions of this document, RFC > > 1766 [21] > > > and RFC 3066 [23], most conformance requirements in > > this document > > > are written in passive voice using uppercase > > conformance keywords. > > > Content authors, authoring tools, content distributors, > > distribution > > > tools, and content repositories (e.g., content servers > > and content > > > archives) that create or copy language tags MUST comply > > with all of > > > these conformance requirements. Content users and user > > tools (e.g., > > > web browsers) that create or copy language tags in > > content queries > > > SHOULD also comply with all of these conformance requirements. > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > Comments? > > > > > > Cheers, > > > - Ira > > > > > > Ira McDonald (Musician / Software Architect) > > > Blue Roof Music / High North Inc > > > PO Box 221 Grand Marais, MI 49839 > > > phone: +1-906-494-2434 > > > email: imcdonald@sharplabs.com > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 16:25:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJU8-0003BT-06; Mon, 23 May 2005 16:25:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJU5-0003BJ-Oc for ltru@megatron.ietf.org; Mon, 23 May 2005 16:25:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17561 for ; Mon, 23 May 2005 16:25:07 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaJm7-0007i1-1M for ltru@ietf.org; Mon, 23 May 2005 16:43:48 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4NKOscE389444 for ; Mon, 23 May 2005 16:24:54 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4NKOpPd230516 for ; Mon, 23 May 2005 14:24:54 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4NKOoIn003157 for ; Mon, 23 May 2005 14:24:50 -0600 Received: from markdavis (mark-davis.sanjose.ibm.com [9.43.213.118]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4NKOnFm003097; Mon, 23 May 2005 14:24:50 -0600 Message-ID: <064e01c55fd5$766720b0$54713009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "McDonald, Ira" , References: <634978A7DF025A40BFEF33EB191E13BC0B7F3840@irvmbxw01.quest.com> Subject: Re: [Ltru] Fix for ambiguous conformance requirements Date: Mon, 23 May 2005 13:24:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j4NKOscE389444 X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org In the present language it is clear what is required for conformance. I don't see any need for further wordsmithing. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "McDonald, Ira" ; Sent: Monday, May 23, 2005 13:11 Subject: RE: [Ltru] Fix for ambiguous conformance requirements Yes, but... The conformance requirements in section 2 describe the grammar of languag= e tags as defined by the ABNF. The tone and form is the same as RFC 3066 an= d RFC 1766 before it. Do you really think anyone will be confused by that? Here is one example: Script subtags MUST immediately follow the primary language subtag and all extended language subtags and MUST occur before any other type of sub= tag described below. Most of the other conformance requirements apply to specific actors, who = are specified. It is possible that we could rewrite section 2 to be more melodious. For example: When forming a language tag, the script subtag MUST immediately follow the primary language subtag and all extended language subtags and MUST oc= cur before any other type of subtag described below. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: 2005?5?23? 8:18 > To: Addison Phillips; McDonald, Ira; ltru@ietf.org > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > Hi Addison, > > Sigh...I tried. > > Conformance requirements written in the passive imperative are > essentially useless. A given actor (person or software) can be > said to comply with a conformance requirement only if they are > explicitly named as the subject of an active voice sentence. > > The whole section 2 is full of passive sentences about the MUST > or SHOULD length/content/position of specific classes of language > subtags. Why bother to have them? Conformance requirements > never apply to _readers_. They only apply to _actors_. > > There is clearly no support on this mailing list for rewriting > every conformance requirement to active voice with explicit actors. > > I'll stop wasting your time. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > Sent: Sunday, May 22, 2005 5:21 PM > > To: McDonald, Ira; ltru@ietf.org > > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > > > > > Hmm... I'm not happy with this text. It is too vague for my tastes. > > > > First, many of the requirements in this document have nothing > > to do with the listed implementation types or uses of > > language tags. They apply strictly to the registry and its > > population and maintenance. > > > > Second, why do you think this is necessary? The > > MUST-ification and SHOULD-ification of various items should > > apply to the audience interested in that particular item > > without additional trappings. If one or another requirement > > should be strengthened or relaxed, then let's discuss that. > > If you think that different levels of MUST-ifying should > > apply to different applications, then we should spell that > > out in place and not vaguely mention it in the introduction. > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] On > > > Behalf Of McDonald, Ira > > > Sent: 2005?5?22? 11:10 > > > To: ltru@ietf.org > > > Subject: [Ltru] Fix for ambiguous conformance requirements > > > > > > Hi folks, Sunday > > (22 May 2005) > > > > > > Addison - Below is an update for section 1 of ltru-registry that > > > resolves my concerns about implied performers of uppercase > > imperatives. > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > (add title to last paragraph of section 1 and add one new paragraph= ) > > > > > > 1.1 Conformance Terminology > > > > > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", > > "SHALL NOT", > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > "OPTIONAL" in this > > > document are to be interpreted as described in RFC 2119 [10]. > > > > > > Consistent with previous versions of this document, RFC > > 1766 [21] > > > and RFC 3066 [23], most conformance requirements in > > this document > > > are written in passive voice using uppercase > > conformance keywords. > > > Content authors, authoring tools, content distributors, > > distribution > > > tools, and content repositories (e.g., content servers > > and content > > > archives) that create or copy language tags MUST comply > > with all of > > > these conformance requirements. Content users and user > > tools (e.g., > > > web browsers) that create or copy language tags in > > content queries > > > SHOULD also comply with all of these conformance requirements. > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > Comments? > > > > > > Cheers, > > > - Ira > > > > > > Ira McDonald (Musician / Software Architect) > > > Blue Roof Music / High North Inc > > > PO Box 221 Grand Marais, MI 49839 > > > phone: +1-906-494-2434 > > > email: imcdonald@sharplabs.com > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 17:19:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKKH-0003l6-N9; Mon, 23 May 2005 17:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKKE-0003jO-Jf for ltru@megatron.ietf.org; Mon, 23 May 2005 17:19:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22133 for ; Mon, 23 May 2005 17:18:58 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKcE-0001O6-JY for ltru@ietf.org; Mon, 23 May 2005 17:37:39 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 14:18:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 May 2005 14:18:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F38D6@irvmbxw01.quest.com> Thread-Topic: draft of draft-03 posted... Thread-Index: AcVf3P/wABzhUzTiRd2kqHQI29X+/w== From: "Addison Phillips" To: X-OriginalArrivalTime: 23 May 2005 21:18:42.0468 (UTC) FILETIME=[FEF28E40:01C55FDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] draft of draft-03 posted... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1869735513==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1869735513== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QWxsLA0KDQpJIGhhdmUgcG9zdGVkIHRoZSBlZGl0b3IncyBjb3BpZXMgb2YgZHJhZnQtMDMgb24g bXkgd2Vic2l0ZS4gVGhlc2UgY29udGFpbiB0aGUgY2hhbmdlcyB0byBhZGRyZXNzIGlzc3VlcyAj OTU0IGFuZCAjOTkyLiBJJ20gbG9va2luZyBmb3IgZmVlZGJhY2sgb24gdGhlIHJlc3VsdHMuDQoN Cmh0dHA6Ly93d3cuaW50ZXItbG9jYWxlLmNvbS9JRC9kcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnkt MDMuaHRtbA0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1y ZWdpc3RyeS0wMy50eHQNCg0KQXMgYSByZW1pbmRlciwgIzk1NCBkZWFscyB3aXRoIGNhbm9uaWNh bGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncy4gIzk5MiBkZWFscyB3aXRoICpub3QqIGNyZWF0aW5n IGFueSByZWdpc3RlcmVkIHZhcmlhbnRzIHdoZW4gdGhlIHJlZ2lzdHJ5IGlzIGluaXRpYWxpemVk IChub3RlIHRoYXQgc29tZSBleGFtcGxlcyBzdGlsbCBuZWVkIHRvIGJlIG1vZGlmaWVkIHRvIGJl IGh5cG90aGV0aWNhbCBhcyBhIHJlc3VsdCkuDQoNCkkgaGF2ZSBhbHNvIG1hZGUgYSB2YXJpZXR5 IG9mIGNsZWFudXAgY2hhbmdlcy4gT2Ygbm90ZSwgdGhlIHNlY3Rpb24gb24gcmVnaXN0cnkgY29u dmVyc2lvbiB3YXMgY2hhbmdlZCBpbiB0aXRsZSAodG8gbWFrZSBpdCBiZSBhYm91dCByZWdpc3Ry eSBjcmVhdGlvbikuDQoNCkknbGwgaGF2ZSB0aW1lIGZvciBhbm90aGVyIHBhc3MgbGF0ZXIgdG8g ZmluaXNoIHRoZSBjbGVhbnVwLiBBbnkgY29tbWVudHMgb24gdGhlIGZpcnN0IHBhc3MgYXJlIHZl cnkgd2VsY29tZS4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNo YWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8v d3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBh IGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= --===============1869735513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1869735513==-- From ltru-bounces@lists.ietf.org Mon May 23 17:20:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKLX-00047h-Il; Mon, 23 May 2005 17:20:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKLW-00047S-2T for ltru@megatron.ietf.org; Mon, 23 May 2005 17:20:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22439 for ; Mon, 23 May 2005 17:20:19 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKdY-0001ZT-87 for ltru@ietf.org; Mon, 23 May 2005 17:39:01 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 14:20:10 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 14:19:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homograph issues in securityconsiderations Date: Mon, 23 May 2005 14:20:09 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #967] address homograph issues in securityconsiderations Thread-Index: AcVeIfDrMKQLNDNZQQCj2IpsQ01oBwBuN1uw From: "Peter Constable" To: X-OriginalArrivalTime: 23 May 2005 21:19:53.0801 (UTC) FILETIME=[29771B90:01C55FDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > John Cowan > As long as everything is cased consistently, there is no problem, but if someone > uses anomalous casing, these would become a problem under your proposal. > I propose therefore that only zero/oh, one/eye, and one/ell be treated as > confusables; these could arise only in variant subtags. As John notes, there isn't an issue for subtags from ISO source standards when casing conventions are applied, though there certainly could be when they are not -- e.g. "ia" and "la" in ISO 639-1 -- but we don't want to prohibit such on the basis of failure to apply casing conventions: a security-conscious app *should* apply the casing conventions if displaying these tags in a UI.=20 As John also notes, zero/Oh, one/Eye and one/el issues can arise for variants, and we should ensure that they are prevented. They can also arise for the registered-lang subtag, and that should also be prevented. The registered-lang subtags is also susceptible to the el / "Eye" issue since there are no casing conventions for this subtag. I think we should be adding prevention for that as well. Since extensions cannot be interpreted without reference to other RFCs, I don't think we need to worry about homographs within extensions. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 17:24:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKPS-000531-Sj; Mon, 23 May 2005 17:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKPR-00052w-Hb for ltru@megatron.ietf.org; Mon, 23 May 2005 17:24:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23287 for ; Mon, 23 May 2005 17:24:23 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKhQ-0001u1-F5 for ltru@ietf.org; Mon, 23 May 2005 17:43:05 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4NLNug8003701; Mon, 23 May 2005 14:24:00 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 23 May 2005 14:23:56 -0700 Message-ID: From: "McDonald, Ira" To: "'Mark Davis'" , Addison Phillips , "McDonald, Ira" , ltru@ietf.org Subject: RE: [Ltru] Fix for ambiguous conformance requirements Date: Mon, 23 May 2005 14:23:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, Mark summarizes the apparent concensus of the mailing list, to whit, conformance requirements that are verifiable for human or software actors simply don't matter for this spec. I don't begin to have the cycles to try to rewrite all the dubious imperatives. If the IESG cares, they should have made their concerns evident a decade ago (RFC 1766). I'm quite ready to abandon the issue. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Mark Davis [mailto:mark.davis@jtcsv.com] > Sent: Monday, May 23, 2005 4:25 PM > To: Addison Phillips; McDonald, Ira; ltru@ietf.org > Subject: Re: [Ltru] Fix for ambiguous conformance requirements >=20 >=20 > In the present language it is clear what is required for=20 > conformance. I > don't see any need for further wordsmithing. >=20 > =E2=80=8EMark >=20 > ----- Original Message -----=20 > From: "Addison Phillips" > To: "McDonald, Ira" ; > Sent: Monday, May 23, 2005 13:11 > Subject: RE: [Ltru] Fix for ambiguous conformance requirements >=20 >=20 > Yes, but... >=20 > The conformance requirements in section 2 describe the=20 > grammar of language > tags as defined by the ABNF. The tone and form is the same as=20 > RFC 3066 and > RFC 1766 before it. Do you really think anyone will be=20 > confused by that? > Here is one example: >=20 > Script subtags MUST immediately follow the primary=20 > language subtag and > all extended language subtags and MUST occur before any other=20 > type of subtag > described below. >=20 > Most of the other conformance requirements apply to specific=20 > actors, who are > specified. It is possible that we could rewrite section 2 to be more > melodious. For example: >=20 > When forming a language tag, the script subtag MUST=20 > immediately follow > the primary language subtag and all extended language subtags=20 > and MUST occur > before any other type of subtag described below. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. > > -----Original Message----- > > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > > Sent: 2005?5?23? 8:18 > > To: Addison Phillips; McDonald, Ira; ltru@ietf.org > > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > > > Hi Addison, > > > > Sigh...I tried. > > > > Conformance requirements written in the passive imperative are > > essentially useless. A given actor (person or software) can be > > said to comply with a conformance requirement only if they are > > explicitly named as the subject of an active voice sentence. > > > > The whole section 2 is full of passive sentences about the MUST > > or SHOULD length/content/position of specific classes of language > > subtags. Why bother to have them? Conformance requirements > > never apply to _readers_. They only apply to _actors_. > > > > There is clearly no support on this mailing list for rewriting > > every conformance requirement to active voice with explicit actors. > > > > I'll stop wasting your time. > > > > Cheers, > > - Ira > > > > Ira McDonald (Musician / Software Architect) > > Blue Roof Music / High North Inc > > PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > > Sent: Sunday, May 22, 2005 5:21 PM > > > To: McDonald, Ira; ltru@ietf.org > > > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > > > > > > > > Hmm... I'm not happy with this text. It is too vague for=20 > my tastes. > > > > > > First, many of the requirements in this document have nothing > > > to do with the listed implementation types or uses of > > > language tags. They apply strictly to the registry and its > > > population and maintenance. > > > > > > Second, why do you think this is necessary? The > > > MUST-ification and SHOULD-ification of various items should > > > apply to the audience interested in that particular item > > > without additional trappings. If one or another requirement > > > should be strengthened or relaxed, then let's discuss that. > > > If you think that different levels of MUST-ifying should > > > apply to different applications, then we should spell that > > > out in place and not vaguely mention it in the introduction. > > > > > > Addison > > > > > > Addison P. Phillips > > > Globalization Architect, Quest Software > > > Chair, W3C Internationalization Core Working Group > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > -----Original Message----- > > > > From: ltru-bounces@lists.ietf.org > > > [mailto:ltru-bounces@lists.ietf.org] On > > > > Behalf Of McDonald, Ira > > > > Sent: 2005?5?22? 11:10 > > > > To: ltru@ietf.org > > > > Subject: [Ltru] Fix for ambiguous conformance requirements > > > > > > > > Hi folks, Sunday > > > (22 May 2005) > > > > > > > > Addison - Below is an update for section 1 of ltru-registry = that > > > > resolves my concerns about implied performers of uppercase > > > imperatives. > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > > > > > (add title to last paragraph of section 1 and add one=20 > new paragraph) > > > > > > > > 1.1 Conformance Terminology > > > > > > > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", > > > "SHALL NOT", > > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > > "OPTIONAL" in this > > > > document are to be interpreted as described in RFC=20 > 2119 [10]. > > > > > > > > Consistent with previous versions of this document, RFC > > > 1766 [21] > > > > and RFC 3066 [23], most conformance requirements in > > > this document > > > > are written in passive voice using uppercase > > > conformance keywords. > > > > Content authors, authoring tools, content distributors, > > > distribution > > > > tools, and content repositories (e.g., content servers > > > and content > > > > archives) that create or copy language tags MUST comply > > > with all of > > > > these conformance requirements. Content users and user > > > tools (e.g., > > > > web browsers) that create or copy language tags in > > > content queries > > > > SHOULD also comply with all of these conformance=20 > requirements. > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > > > > > Comments? > > > > > > > > Cheers, > > > > - Ira > > > > > > > > Ira McDonald (Musician / Software Architect) > > > > Blue Roof Music / High North Inc > > > > PO Box 221 Grand Marais, MI 49839 > > > > phone: +1-906-494-2434 > > > > email: imcdonald@sharplabs.com > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 17:51:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKpH-0008Hx-FV; Mon, 23 May 2005 17:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKpG-0008HS-Eg for ltru@megatron.ietf.org; Mon, 23 May 2005 17:51:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29953 for ; Mon, 23 May 2005 17:51:03 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaL7H-0004K4-Oo for ltru@ietf.org; Mon, 23 May 2005 18:09:46 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4NLosLK049144 for ; Mon, 23 May 2005 17:50:54 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4NLoolw094842 for ; Mon, 23 May 2005 15:50:54 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4NLoodT026840 for ; Mon, 23 May 2005 15:50:50 -0600 Received: from markdavis (mark-davis.sanjose.ibm.com [9.43.213.118]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4NLonEu026801; Mon, 23 May 2005 15:50:49 -0600 Message-ID: <073401c55fe1$796e01a0$54713009@sanjose.ibm.com> From: "Mark Davis" To: "McDonald, Ira" , "Addison Phillips" , References: Subject: Re: [Ltru] Fix for ambiguous conformance requirements Date: Mon, 23 May 2005 14:50:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j4NLosLK049144 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org >to whit, conformance requirements that are verifiable for >human or software actors simply don't matter for this spec. I have no idea where you are getting this from. Look at Addison's example= : > Script subtags MUST immediately follow the primary > language subtag and > all extended language subtags and MUST occur before any other > type of subtag > described below. How are you afraid this would be misread? If I had a generator that put t= he script subtag, say, before the primary language subtag, that would clearl= y not be in conformance according to this language. =E2=80=8EMark ----- Original Message -----=20 From: "McDonald, Ira" To: "'Mark Davis'" ; "Addison Phillips" ; "McDonald, Ira" ; Sent: Monday, May 23, 2005 14:23 Subject: RE: [Ltru] Fix for ambiguous conformance requirements Hi, Mark summarizes the apparent concensus of the mailing list, to whit, conformance requirements that are verifiable for human or software actors simply don't matter for this spec. I don't begin to have the cycles to try to rewrite all the dubious imperatives. If the IESG cares, they should have made their concerns evident a decade ago (RFC 1766). I'm quite ready to abandon the issue. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Mark Davis [mailto:mark.davis@jtcsv.com] > Sent: Monday, May 23, 2005 4:25 PM > To: Addison Phillips; McDonald, Ira; ltru@ietf.org > Subject: Re: [Ltru] Fix for ambiguous conformance requirements > > > In the present language it is clear what is required for > conformance. I > don't see any need for further wordsmithing. > > =E2=80=8EMark > > ----- Original Message -----=20 > From: "Addison Phillips" > To: "McDonald, Ira" ; > Sent: Monday, May 23, 2005 13:11 > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > > Yes, but... > > The conformance requirements in section 2 describe the > grammar of language > tags as defined by the ABNF. The tone and form is the same as > RFC 3066 and > RFC 1766 before it. Do you really think anyone will be > confused by that? > Here is one example: > > Script subtags MUST immediately follow the primary > language subtag and > all extended language subtags and MUST occur before any other > type of subtag > described below. > > Most of the other conformance requirements apply to specific > actors, who are > specified. It is possible that we could rewrite section 2 to be more > melodious. For example: > > When forming a language tag, the script subtag MUST > immediately follow > the primary language subtag and all extended language subtags > and MUST occur > before any other type of subtag described below. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > -----Original Message----- > > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > > Sent: 2005?5?23? 8:18 > > To: Addison Phillips; McDonald, Ira; ltru@ietf.org > > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > > > Hi Addison, > > > > Sigh...I tried. > > > > Conformance requirements written in the passive imperative are > > essentially useless. A given actor (person or software) can be > > said to comply with a conformance requirement only if they are > > explicitly named as the subject of an active voice sentence. > > > > The whole section 2 is full of passive sentences about the MUST > > or SHOULD length/content/position of specific classes of language > > subtags. Why bother to have them? Conformance requirements > > never apply to _readers_. They only apply to _actors_. > > > > There is clearly no support on this mailing list for rewriting > > every conformance requirement to active voice with explicit actors. > > > > I'll stop wasting your time. > > > > Cheers, > > - Ira > > > > Ira McDonald (Musician / Software Architect) > > Blue Roof Music / High North Inc > > PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > > Sent: Sunday, May 22, 2005 5:21 PM > > > To: McDonald, Ira; ltru@ietf.org > > > Subject: RE: [Ltru] Fix for ambiguous conformance requirements > > > > > > > > > Hmm... I'm not happy with this text. It is too vague for > my tastes. > > > > > > First, many of the requirements in this document have nothing > > > to do with the listed implementation types or uses of > > > language tags. They apply strictly to the registry and its > > > population and maintenance. > > > > > > Second, why do you think this is necessary? The > > > MUST-ification and SHOULD-ification of various items should > > > apply to the audience interested in that particular item > > > without additional trappings. If one or another requirement > > > should be strengthened or relaxed, then let's discuss that. > > > If you think that different levels of MUST-ifying should > > > apply to different applications, then we should spell that > > > out in place and not vaguely mention it in the introduction. > > > > > > Addison > > > > > > Addison P. Phillips > > > Globalization Architect, Quest Software > > > Chair, W3C Internationalization Core Working Group > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > -----Original Message----- > > > > From: ltru-bounces@lists.ietf.org > > > [mailto:ltru-bounces@lists.ietf.org] On > > > > Behalf Of McDonald, Ira > > > > Sent: 2005?5?22? 11:10 > > > > To: ltru@ietf.org > > > > Subject: [Ltru] Fix for ambiguous conformance requirements > > > > > > > > Hi folks, Sunday > > > (22 May 2005) > > > > > > > > Addison - Below is an update for section 1 of ltru-registry that > > > > resolves my concerns about implied performers of uppercase > > > imperatives. > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > > > > > (add title to last paragraph of section 1 and add one > new paragraph) > > > > > > > > 1.1 Conformance Terminology > > > > > > > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", > > > "SHALL NOT", > > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > > "OPTIONAL" in this > > > > document are to be interpreted as described in RFC > 2119 [10]. > > > > > > > > Consistent with previous versions of this document, RFC > > > 1766 [21] > > > > and RFC 3066 [23], most conformance requirements in > > > this document > > > > are written in passive voice using uppercase > > > conformance keywords. > > > > Content authors, authoring tools, content distributors, > > > distribution > > > > tools, and content repositories (e.g., content servers > > > and content > > > > archives) that create or copy language tags MUST comply > > > with all of > > > > these conformance requirements. Content users and user > > > tools (e.g., > > > > web browsers) that create or copy language tags in > > > content queries > > > > SHOULD also comply with all of these conformance > requirements. > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > > > > > Comments? > > > > > > > > Cheers, > > > > - Ira > > > > > > > > Ira McDonald (Musician / Software Architect) > > > > Blue Roof Music / High North Inc > > > > PO Box 221 Grand Marais, MI 49839 > > > > phone: +1-906-494-2434 > > > > email: imcdonald@sharplabs.com > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 18:03:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaL1W-00035E-PV; Mon, 23 May 2005 18:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaL1V-000358-Js for ltru@megatron.ietf.org; Mon, 23 May 2005 18:03:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02181 for ; Mon, 23 May 2005 18:03:41 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLJX-0005BD-49 for ltru@ietf.org; Mon, 23 May 2005 18:22:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:03:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations Date: Mon, 23 May 2005 15:03:28 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3930@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations Thread-Index: AcVeIfDrMKQLNDNZQQCj2IpsQ01oBwBuN1uwAAFpn2A= From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 23 May 2005 22:03:29.0644 (UTC) FILETIME=[40A112C0:01C55FE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Note that confusables cannot appear in the registry: registry entries = are always lowercase excepting regions (uppercase) and scripts = (titlecase). Scripts and ISO 3166 codes are both alpha-only (no = digits!!) Confusables can only affect language tags. These tags will not be = well-formed excepting the use of 0/o and 1/l in primary language tags = and variants. So then... would this text work (in possibilities for registration = section??): Language tags are formed from ASCII letters and digits. Some of these = characters may be confused when displayed in certain fonts in certain = user interfaces. In well-formed tags (where all of the subtags are = actually valid), the only subtags that are affected are registered = primary-language subtags (those longer than four characters, none of = which exist at the time of adoption of this document) or variant = subtags. The character pairs normally considered confusable in these = subtags are 0 vs. O (%x30 vs. %x4F) and 1 and l (%x31 vs. %x6c). No = subtags will be permitted for registration that differ only by these = character pairs. For example, if a subtag 'example' = (%x65.78.61.6d.70.6c.65) were registered as a variant, the subtag = 'examp1e' (%x65.78.61.6d.70.31.65) would not be valid for registration. = In addition, applications for registration that present obviously = confusable sequences (such as 'examp1e') will probably be rejected. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: 2005?5?23? 14:20 > To: ltru@ietf.org > Subject: RE: [Ltru] [psg.com #967] address homograph issues > insecurityconsiderations >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of > > John Cowan >=20 >=20 > > As long as everything is cased consistently, there is no problem, = but > if someone > > uses anomalous casing, these would become a problem under your > proposal. > > I propose therefore that only zero/oh, one/eye, and one/ell be = treated > as > > confusables; these could arise only in variant subtags. >=20 > As John notes, there isn't an issue for subtags from ISO source > standards when casing conventions are applied, though there certainly > could be when they are not -- e.g. "ia" and "la" in ISO 639-1 -- but = we > don't want to prohibit such on the basis of failure to apply casing > conventions: a security-conscious app *should* apply the casing > conventions if displaying these tags in a UI. >=20 > As John also notes, zero/Oh, one/Eye and one/el issues can arise for > variants, and we should ensure that they are prevented. They can also > arise for the registered-lang subtag, and that should also be = prevented. >=20 > The registered-lang subtags is also susceptible to the el / "Eye" = issue > since there are no casing conventions for this subtag. I think we = should > be adding prevention for that as well. >=20 > Since extensions cannot be interpreted without reference to other = RFCs, > I don't think we need to worry about homographs within extensions. >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 18:22:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLJv-0006NQ-PD; Mon, 23 May 2005 18:22:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLJt-0006NI-A5 for ltru@megatron.ietf.org; Mon, 23 May 2005 18:22:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04819 for ; Mon, 23 May 2005 18:22:42 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLbw-00063u-76 for ltru@ietf.org; Mon, 23 May 2005 18:41:25 -0400 Received: from h-68-166-37-236.snvacaid.dynamic.covad.net ([68.166.37.236] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DaLJq-0002JO-00 for ltru@ietf.org; Mon, 23 May 2005 18:22:42 -0400 Message-ID: <002501c55fe6$52c535a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B7F3930@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations Date: Mon, 23 May 2005 15:25:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Peter Constable" ; > Sent: Monday, May 23, 2005 3:03 PM > Subject: RE: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations ... > So then... would this text work (in possibilities for registration section??): ... This is stronger than what I had proposed, since it's effectively MUST rather than SHOULD. (Just an observation) The "Security Considerations" section still needs to mention the issue, even if only to say "Potential homograph issues are addressed in section foo". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 18:29:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLQh-0007FF-TY; Mon, 23 May 2005 18:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLQf-0007FA-Mt for ltru@megatron.ietf.org; Mon, 23 May 2005 18:29:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05406 for ; Mon, 23 May 2005 18:29:43 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLii-0006J5-Jh for ltru@ietf.org; Mon, 23 May 2005 18:48:25 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:29:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] address homographissuesinsecurityconsiderations Date: Mon, 23 May 2005 15:29:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3958@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #967] address homographissuesinsecurityconsiderations Thread-Index: AcVf5ff6puHuP71CQsiq/FEnIV5eawAAI3ig From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 23 May 2005 22:29:34.0391 (UTC) FILETIME=[E54A8470:01C55FE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Since this is a rule that is unlikely to come into play often (if ever), = making it a MUST is hardly a hardship. In fact, it is nice and crisp = (and applies to a very small set of subtags---exactly none as of = draft-03). You're correct about the SC section. Forgot to mention it. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?23? 15:25 > To: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #967] address > homographissuesinsecurityconsiderations >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Peter Constable" ; > > Sent: Monday, May 23, 2005 3:03 PM > > Subject: RE: [Ltru] [psg.com #967] address homograph > issuesinsecurityconsiderations > ... > > So then... would this text work (in possibilities for registration > section??): > ... >=20 > This is stronger than what I had proposed, since it's effectively MUST > rather > than SHOULD. (Just an observation) >=20 > The "Security Considerations" section still needs to mention the = issue, > even if only to say "Potential homograph issues are addressed in = section > foo". >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 19:42:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMZ1-0000jF-MM; Mon, 23 May 2005 19:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMZ0-0000j7-3y for ltru@megatron.ietf.org; Mon, 23 May 2005 19:42:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14361 for ; Mon, 23 May 2005 19:42:23 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaMr3-0001wY-Pg for ltru@ietf.org; Mon, 23 May 2005 20:01:07 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4NNgEZX016437 for ; Mon, 23 May 2005 19:42:14 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 23 May 2005 19:42:13 -0400 Date: Mon, 23 May 2005 19:42:12 -0400 From: John Cowan To: ltru@ietf.org Message-ID: <20050523234212.GA18904@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] Editorial error in BNF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The BNF rule for lang still says 2*3ALPHA instead of 2*4ALPHA, even though section 2.2.1 bullet 4 says that 4ALPHA tags are reserved for future standardization. The BNF should be fixed. -- John Cowan http://www.reutershealth.com But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 19:53:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMjG-0002S2-MO; Mon, 23 May 2005 19:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMjE-0002RM-Px for ltru@megatron.ietf.org; Mon, 23 May 2005 19:53:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15117 for ; Mon, 23 May 2005 19:52:55 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaN1G-0002Nn-GA for ltru@ietf.org; Mon, 23 May 2005 20:11:39 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 16:52:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Editorial error in BNF Date: Mon, 23 May 2005 16:52:43 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F399A@irvmbxw01.quest.com> Thread-Topic: [Ltru] Editorial error in BNF Thread-Index: AcVf8ULNLV/WSP5XQrygQ2q9aXkhvAAAQGdA From: "Addison Phillips" To: "John Cowan" , X-OriginalArrivalTime: 23 May 2005 23:52:43.0938 (UTC) FILETIME=[834AF820:01C55FF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org 2*3ALPHA describes assigned subtags (i.e. subtags that are valid). = 4ALPHA is reserved for future standardization and are not valid = currently. That's the reason I didn't change the ABNF, although I'm not = religious about it. The opposite case is easy enough to make. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: 2005?5?23? 16:42 > To: ltru@ietf.org > Subject: [Ltru] Editorial error in BNF >=20 > The BNF rule for lang still says 2*3ALPHA instead of 2*4ALPHA, even = though > section 2.2.1 bullet 4 says that 4ALPHA tags are reserved for future > standardization. >=20 > The BNF should be fixed. >=20 >=20 > -- > John Cowan http://www.reutershealth.com > But no living man am I! You look upon a woman. Eowyn I am, Eomund's > daughter. > You stand between me and my lord and kin. Begone, if you be not = deathless. > For living or dark undead, I will smite you if you touch him. >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 20:00:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMqC-0003Q8-By; Mon, 23 May 2005 20:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMqA-0003Q0-TQ for ltru@megatron.ietf.org; Mon, 23 May 2005 20:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15738 for ; Mon, 23 May 2005 20:00:09 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaN8B-0002ZI-V5 for ltru@ietf.org; Mon, 23 May 2005 20:18:51 -0400 Received: from h-68-166-37-236.snvacaid.dynamic.covad.net ([68.166.37.236] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DaMq1-0001vc-00 for ltru@ietf.org; Mon, 23 May 2005 20:00:01 -0400 Message-ID: <000b01c55ff3$ea8b0c40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B7F399A@irvmbxw01.quest.com> Subject: Re: [Ltru] Editorial error in BNF Date: Mon, 23 May 2005 17:02:45 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "John Cowan" ; > Sent: Monday, May 23, 2005 4:52 PM > Subject: RE: [Ltru] Editorial error in BNF > > 2*3ALPHA describes assigned subtags (i.e. subtags that are valid). > 4ALPHA is reserved for future standardization and are not valid currently. > That's the reason I didn't change the ABNF, although I'm not religious about it. > The opposite case is easy enough to make. ... As a contributor I think the question is whether we want things using 4ALPHAs to be considered well-formed, rather than whether there are (or will be) valid ones with that form. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 21:03:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaNpO-0004Oo-Pm; Mon, 23 May 2005 21:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaNpN-0004Oj-T5 for ltru@megatron.ietf.org; Mon, 23 May 2005 21:03:26 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19341 for ; Mon, 23 May 2005 21:03:23 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DaNnD-0002nM-Bw for ltru@lists.ietf.org; Tue, 24 May 2005 03:01:11 +0200 Received: from 212.82.251.40 ([212.82.251.40]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2005 03:01:11 +0200 Received: from nobody by 212.82.251.40 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2005 03:01:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 24 May 2005 03:01:56 +0200 Organization: Lines: 16 Message-ID: <42927D04.407D@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B7F399A@irvmbxw01.quest.com> <000b01c55ff3$ea8b0c40$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.40 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Editorial error in BNF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I think the question is whether we want things using > 4ALPHAs to be considered well-formed It is both ways, either as case 2*4ALPHA or as case 4*8ALPHA. We could move the 4 from to 2*4ALPHA with 5*8 for , or we keep it where it is with 2*3ALPHA as it is. Moving it would need various minor editorial fixes without a clear advantage. The "reserved for whatever Debbie does" works in both cases for a future 3066ter or a separate spec. extending 3066bis. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 21:07:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaNtg-0004w9-Uq; Mon, 23 May 2005 21:07:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaNtc-0004w4-7W for ltru@megatron.ietf.org; Mon, 23 May 2005 21:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19643 for ; Mon, 23 May 2005 21:07:46 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaOBf-0004UM-Rq for ltru@ietf.org; Mon, 23 May 2005 21:26:29 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j4O17Wm22879; Tue, 24 May 2005 10:07:32 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 9516a926_cbf1_11d9_9fdc_0030482532aa_9512; Tue, 24 May 2005 10:17:23 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO00069F; 24 May 05 10:10:45 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 24 May 05 10:10:14 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.53) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG00069D; 24 May 05 10:10:13 +0900 Message-Id: <6.0.0.20.2.20050524100512.086e2050@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 24 May 2005 10:06:53 +0900 To: "Addison Phillips" , "Randy Presuhn" , From: Martin Duerst Subject: RE: [Ltru] [psg.com #967] addresshomographissuesinsecurityconsiderations In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B7F3958@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B7F3958@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 07:29 05/05/24, Addison Phillips wrote: >Since this is a rule that is unlikely to come into play often (if ever), >making it a MUST is hardly a hardship. Well, yes and no. Will somebody be able to provide some kind of software to IANA for checking this? Doing this kind of check by hand is extremely tedious, and the fact that the problem occurs very rarely makes it easy to just leave the check out. Regards, Martin. >In fact, it is nice and crisp (and >applies to a very small set of subtags---exactly none as of draft-03). _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 21:56:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaOeR-0003RI-V4; Mon, 23 May 2005 21:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaOeQ-0003RD-TV for ltru@megatron.ietf.org; Mon, 23 May 2005 21:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22628 for ; Mon, 23 May 2005 21:56:09 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaOwR-0005QO-Kn for ltru@ietf.org; Mon, 23 May 2005 22:14:52 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4O1tfmD157012 for ; Mon, 23 May 2005 21:55:41 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4O1tePd241260 for ; Mon, 23 May 2005 19:55:41 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4O1tewo012698 for ; Mon, 23 May 2005 19:55:40 -0600 Received: from markdavis (mark-davis.sanjose.ibm.com [9.43.213.118]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4O1tdMC012682; Mon, 23 May 2005 19:55:40 -0600 Message-ID: <07ab01c56003$add7da20$54713009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "John Cowan" , References: <634978A7DF025A40BFEF33EB191E13BC0B7F399A@irvmbxw01.quest.com> Subject: Re: [Ltru] Editorial error in BNF Date: Mon, 23 May 2005 18:55:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j4O1tfmD157012 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org One of the goals of the project was that the BNF never needs to be change= d in the future; that every current parser must be able to read every futur= e tag. (You've reminded me of this on occasion!) So it must be changed to 2= *4 =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "John Cowan" ; Sent: Monday, May 23, 2005 16:52 Subject: RE: [Ltru] Editorial error in BNF 2*3ALPHA describes assigned subtags (i.e. subtags that are valid). 4ALPHA= is reserved for future standardization and are not valid currently. That's t= he reason I didn't change the ABNF, although I'm not religious about it. The opposite case is easy enough to make. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: 2005?5?23? 16:42 > To: ltru@ietf.org > Subject: [Ltru] Editorial error in BNF > > The BNF rule for lang still says 2*3ALPHA instead of 2*4ALPHA, even tho= ugh > section 2.2.1 bullet 4 says that 4ALPHA tags are reserved for future > standardization. > > The BNF should be fixed. > > > -- > John Cowan http://www.reutershealth.com > But no living man am I! You look upon a woman. Eowyn I am, Eomund's > daughter. > You stand between me and my lord and kin. Begone, if you be not deathless. > For living or dark undead, I will smite you if you touch him. > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 22:18:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaP0R-0006Ol-Or; Mon, 23 May 2005 22:18:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaP0R-0006Og-0I for ltru@megatron.ietf.org; Mon, 23 May 2005 22:18:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24033 for ; Mon, 23 May 2005 22:18:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaPIP-0006D6-Jj for ltru@ietf.org; Mon, 23 May 2005 22:37:37 -0400 Received: from [82.241.91.24] (helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DaP0H-0007Cd-6R; Mon, 23 May 2005 19:18:45 -0700 Message-Id: <6.2.1.2.2.20050524032333.04472ca0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 24 May 2005 04:13:20 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] [psg.com #967] address homograph issues insecurityconsiderations In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B7F3930@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B7F3930@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison, in case my vacations are finished a few points. 1. I introduced the homograph issue. You discussed it at length, so I hoped you would understand as you did for the dated entries... The homograph problem I rose is not about the registry but about the script/charset conflicts and/or script variations. Your system does not introduce/document any protection against homograph issues, while users would legitimately believe they are protected. 2. ditto about security and "nationality" disclosure. I do not want Randy to ban me again for defending Human Rights., so, I prepared and circulate a short declaration on lingual rights respect by standard makers. This kind of text needs to be reviewed by many for moral and ethical endorsement. It will propose it to IETF as to everyone else. If IETF chooses to oppose it, your concept could continue. If IETF chooses to support it, it will probably call for a complete review. I told the problem enough ... I try to speed things. My target date is July 1st, Paris meeting with everyone there. I will obviously copy it to you as soon as I can. 3. My printer is down. I spent more than three dollars today to get your .02.txt version printed. Then I stared reviewing it. Now, you announce version 03.txt. I cannot follow: I will make a final review and publish it during the Last Call. Like Randy did: one mail per remark. Trying to reach consensus by exhaustion has also draught back. I only hope that 04.txt includes a global change and addresses the numerous remarks I made. From trying to make a summary today, just a suggestion.I disagree with the document and do not speak English, so I would be a poor contributor: I know you live with this text for one year; but you could try to think as a developer reading the current text for the first time. May be it could help your text to be easier to read and understand? Cheers. jfc On 00:03 24/05/2005, Addison Phillips said: >Note that confusables cannot appear in the registry: registry entries are >always lowercase excepting regions (uppercase) and scripts (titlecase). >Scripts and ISO 3166 codes are both alpha-only (no digits!!) > >Confusables can only affect language tags. These tags will not be >well-formed excepting the use of 0/o and 1/l in primary language tags and >variants. > >So then... would this text work (in possibilities for registration section??): > >Language tags are formed from ASCII letters and digits. Some of these >characters may be confused when displayed in certain fonts in certain user >interfaces. In well-formed tags (where all of the subtags are actually >valid), the only subtags that are affected are registered primary-language >subtags (those longer than four characters, none of which exist at the >time of adoption of this document) or variant subtags. The character pairs >normally considered confusable in these subtags are 0 vs. O (%x30 vs. >%x4F) and 1 and l (%x31 vs. %x6c). No subtags will be permitted for >registration that differ only by these character pairs. For example, if a >subtag 'example' (%x65.78.61.6d.70.6c.65) were registered as a variant, >the subtag 'examp1e' (%x65.78.61.6d.70.31.65) would not be valid for >registration. In addition, applications for registration that present >obviously confusable sequences (such as 'examp1e') will probably be >rejected. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Peter Constable > > Sent: 2005?5?23? 14:20 > > To: ltru@ietf.org > > Subject: RE: [Ltru] [psg.com #967] address homograph issues > > insecurityconsiderations > > > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > > On Behalf Of > > > John Cowan > > > > > > > As long as everything is cased consistently, there is no problem, but > > if someone > > > uses anomalous casing, these would become a problem under your > > proposal. > > > I propose therefore that only zero/oh, one/eye, and one/ell be treated > > as > > > confusables; these could arise only in variant subtags. > > > > As John notes, there isn't an issue for subtags from ISO source > > standards when casing conventions are applied, though there certainly > > could be when they are not -- e.g. "ia" and "la" in ISO 639-1 -- but we > > don't want to prohibit such on the basis of failure to apply casing > > conventions: a security-conscious app *should* apply the casing > > conventions if displaying these tags in a UI. > > > > As John also notes, zero/Oh, one/Eye and one/el issues can arise for > > variants, and we should ensure that they are prevented. They can also > > arise for the registered-lang subtag, and that should also be prevented. > > > > The registered-lang subtags is also susceptible to the el / "Eye" issue > > since there are no casing conventions for this subtag. I think we should > > be adding prevention for that as well. > > > > Since extensions cannot be interpreted without reference to other RFCs, > > I don't think we need to worry about homographs within extensions. > > > > > > > > Peter Constable > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 23 23:38:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaQFN-0007fC-UJ; Mon, 23 May 2005 23:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaQFM-0007f4-Ch for ltru@megatron.ietf.org; Mon, 23 May 2005 23:38:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27925 for ; Mon, 23 May 2005 23:38:21 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaQXS-0000Qg-Bo for ltru@ietf.org; Mon, 23 May 2005 23:57:06 -0400 Received: from h-68-166-37-236.snvacaid.dynamic.covad.net ([68.166.37.236] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DaQFK-0007Ja-00 for ltru@ietf.org; Mon, 23 May 2005 23:38:22 -0400 Message-ID: <001c01c56012$68c13ee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B7F3930@irvmbxw01.quest.com> <6.2.1.2.2.20050524032333.04472ca0@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #967] address homograph issues in security considerations Date: Mon, 23 May 2005 20:41:02 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "JFC (Jefsey) Morfin" > To: "Addison Phillips" > Cc: > Sent: Monday, May 23, 2005 7:13 PM > Subject: RE: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations ... > 1. I introduced the homograph issue. You discussed it at length, so I hoped > you would understand as you did for the dated entries... The homograph > problem I rose is not about the registry but about the script/charset > conflicts and/or script variations. Your system does not introduce/document > any protection against homograph issues, while users would legitimately > believe they are protected. The language tag associated with a particular bit of content is of no consequence whatsoever in determining whether that content might contain possible homographs. The fact that a text is tagged as being in one language provides no assurance whatsoever that it doesn't contain characters from scripts other than the one(s) associated with that language. Would it satisfy you if we were to include this statement in the security considerations section? Would other WG members object to including this statement? > 2. ditto about security and "nationality" disclosure. I do not want Randy What do you mean by "ditto"? Please provide text if you want anyone to pay attention to you. > to ban me again for defending Human Rights., so, I prepared and circulate a Misrepresenting the chairs' motives could be considered disruptive, and cause for revocation of posting privileges. You have been warned. > short declaration on lingual rights respect by standard makers. This kind > of text needs to be reviewed by many for moral and ethical endorsement. It > will propose it to IETF as to everyone else. If IETF chooses to oppose it, > your concept could continue. If IETF chooses to support it, it will > probably call for a complete review. I told the problem enough ... I try to > speed things. My target date is July 1st, Paris meeting with everyone > there. I will obviously copy it to you as soon as I can. Note that the WG last call for the registry i-d is planned for May, 2005. Unless something catastrophic happens, we should have been able to hand it to the IESG for consideration for publication by sometime in June. > 3. My printer is down. I spent more than three dollars today to get your > .02.txt version printed. Then I stared reviewing it. Now, you announce > version 03.txt. I cannot follow: I will make a final review and publish it > during the Last Call. Like Randy did: one mail per remark. Trying to reach > consensus by exhaustion has also draught back. I only hope that 04.txt > includes a global change and addresses the numerous remarks I made. NOTE WELL: If you hope to influence the WG, it would be better to make your comments sooner, rather than waiting for WG last call. Issues that have been resolved or rejected prior to WG last call will NOT be re-opened during last call unless there is a clear explanation of why the WG decision was technically incorrect. > From trying to make a summary today, just a suggestion.I disagree with the Broad statements like this are not helpful. > document and do not speak English, so I would be a poor contributor: I know > you live with this text for one year; but you could try to think as a > developer reading the current text for the first time. May be it could help > your text to be easier to read and understand? This is sound advice for anyone writing an i-d, but it has limits. For example, we can't reasonably expect to produce a technical specification that would be readily understood by someone not proficient in the language of that text. Still, it is good to keep the first-time reader in mind, and to strive for clarity at all times. > Cheers. > jfc ... Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 01:05:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaRc6-0001hu-O6; Tue, 24 May 2005 01:05:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaRc4-0001fM-PR for ltru@megatron.ietf.org; Tue, 24 May 2005 01:05:56 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02873 for ; Tue, 24 May 2005 01:05:55 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050524050525.XMNQ8952.mta9.adelphia.net@DEWELL> for ; Tue, 24 May 2005 01:05:25 -0400 Message-ID: <004801c5601e$2d0ded60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050523213022.YXF28811.mta8.adelphia.net@megatron.ietf.org> Date: Mon, 23 May 2005 22:05: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Fix for ambiguous conformance requirements X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira wrote: > Mark summarizes the apparent concensus of the mailing list, > to whit, conformance requirements that are verifiable for > human or software actors simply don't matter for this spec. I don't agree with this one bit, and don't understand why Ira chose to express himself that way. There isn't anything about a conformance requirement that happens to be written in passive tense that automatically makes it unverifiable, as long as it is apparent who the actor is. Language tags don't create and interpret themselves, and anyone planning to make use of the draft would understand that. Turning the sentences around to say "you" or "the user" might make the sentences punchier, but no more correct. If the RFC says, "Variant subtags SHOULD be used only with their recommended prefix," and I am the one who is "using" them (i.e. creating them), then I consider the sentence absolutely equivalent to "You SHOULD use variant subtags only with their recommended prefix." I don't know in what way this is unclear or not verifiable. I only wish this active/passive voice issue were the biggest hurdle I ever had to jump when soliciting or interpreting requirements. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 01:28:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaRxu-0004no-QQ; Tue, 24 May 2005 01:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaRxt-0004nb-Bc for ltru@megatron.ietf.org; Tue, 24 May 2005 01:28:29 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04724 for ; Tue, 24 May 2005 01:28:28 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050524052757.UDEY4191.mta13.adelphia.net@DEWELL> for ; Tue, 24 May 2005 01:27:57 -0400 Message-ID: <004b01c56021$56f7e100$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050524000130.HHMW13001.mta6.adelphia.net@megatron.ietf.org> Date: Mon, 23 May 2005 22:27:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #967] address homograph issues in security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Language tags are formed from ASCII letters and digits. Some of > these characters may be confused when displayed in certain fonts in > certain user interfaces. In well-formed tags (where all of the subtags > are actually valid), the only subtags that are affected are registered > primary-language subtags (those longer than four characters, none of > which exist at the time of adoption of this document) or variant > subtags. The character pairs normally considered confusable in these > subtags are 0 vs. O (%x30 vs. %x4F) and 1 and l (%x31 vs. %x6c). No > subtags will be permitted for registration that differ only by these > character pairs. For example, if a subtag 'example' (%x65.78.61.6d.70. > 6c.65) were registered as a variant, the subtag 'examp1e' (%x65.78.61. > 6d.70.31.65) would not be valid for registration. In addition, > applications for registration that present obviously confusable > sequences (such as 'examp1e') will probably be rejected. Whew. I wouldn't say "some of these characters may be confused." I think they're quite certain of their own identity. :-) I think some of them might be confused for each other, though. I think the third sentence doth protest too much, and could be trimmed to state simply that this applies only to subtags proposed on registration forms, not those that come from core standards. I might remove the eye-glazing hex sequences, and write something like "the subtag 'examp1e' (with the digit one)" if the spoof might not be clear enough. And I would definitely state the obvious case of deliberate spoofing ("examp1e") before the less-likely case where two subtags might both be legitimate, but the second is rejected because of similarity to the first. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 01:59:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaSRh-0000jY-6A; Tue, 24 May 2005 01:59:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaSRf-0000jT-DZ for ltru@megatron.ietf.org; Tue, 24 May 2005 01:59:15 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06181 for ; Tue, 24 May 2005 01:59:14 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050524055843.YVXO8952.mta9.adelphia.net@DEWELL> for ; Tue, 24 May 2005 01:58:43 -0400 Message-ID: <005501c56025$9f2b5200$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050524053010.IOYW9622.mta3.adelphia.net@megatron.ietf.org> Date: Mon, 23 May 2005 22:58:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #967] address homograph issues in security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > The language tag associated with a particular bit of content is of no > consequence whatsoever in determining whether that content might > contain possible homographs. The fact that a text is tagged as being > in one language provides no assurance whatsoever that it doesn't > contain characters from scripts other than the one(s) associated with > that language. In a similar vein, I would have sworn that either the draft, or RFC 3066 or 1766, had a passage somewhere to the effect that there was no guarantee that a run of text tagged, say, "fr" was actually in the French language. In other words, there is nothing that can be done within the language tagging mechanism to ensure it will never be misused. I couldn't find such a passage -- maybe I read it somewhere else -- but it is certainly true, and closely related to Randy's statement above. > Would it satisfy you if we were to include this statement in the > security considerations section? Would other WG members object to > including this statement? I would not object at all. At the very least, it is harmless. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 02:29:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaSuw-0004eI-7l; Tue, 24 May 2005 02:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaSut-0004eD-KI for ltru@megatron.ietf.org; Tue, 24 May 2005 02:29:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29431 for ; Tue, 24 May 2005 02:29:26 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaTD0-00060a-RA for ltru@ietf.org; Tue, 24 May 2005 02:48:12 -0400 Received: from h-68-166-188-156.snvacaid.dynamic.covad.net ([68.166.188.156] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DaSum-0004rD-00 for ltru@ietf.org; Tue, 24 May 2005 02:29:20 -0400 Message-ID: <01cc01c5602a$48ff21e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 23 May 2005 23:31:56 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] issue resolutions 999 & 1000 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've created two more tickets to record the long resolved (I hope!) discussions on the order of subtags and the field currently called "Suppress-script". If you feel additional discussion is warranted on either of these, please use an appropriate subject line. [psg.com #999] order of subtags resolved [psg.com #1000] Add Suppress-Script field resolved The tickets are at https://rt.psg.com/ (password and user "ietf") in the queues beginning with "ltru-" Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 02:50:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaTFG-0007Fa-H8; Tue, 24 May 2005 02:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaTFE-0007FV-8r for ltru@megatron.ietf.org; Tue, 24 May 2005 02:50:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00829 for ; Tue, 24 May 2005 02:50:27 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaTXL-0006UZ-Nc for ltru@ietf.org; Tue, 24 May 2005 03:09:12 -0400 Received: from h-68-166-188-156.snvacaid.dynamic.covad.net ([68.166.188.156] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DaTF9-0007VR-00 for ltru@ietf.org; Tue, 24 May 2005 02:50:23 -0400 Message-ID: <01d701c5602d$3aa1bc40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050523213022.YXF28811.mta8.adelphia.net@megatron.ietf.org> <004801c5601e$2d0ded60$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Fix for ambiguous conformance requirements Date: Mon, 23 May 2005 23:53:01 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I think there are some problems with the use of the 2119 keywords in draft-ietf-ltru-registry-02.txt Specifically: The phrase "[a]ny such limitation MUST be clearly documented" doesn't quite work when one considers the RFC 2119 guidelines which state "In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm". I suggest replacing this MUST with SHOULD. Likewise, the requirement "If the processor generates tags, it MUST do so in canonical form..." doesn't fit within 2119's framework, but a SHOULD would be appropriate. In the phrase "it is reasonable to assume that there MUST be additional very compelling evidence", the "MUST" clearly should be "must". There are a couple of "STRONGLY RECOMMENDED"s that should be replaced with "strongly RECOMMENDED". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 04:23:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaUhU-00041z-Ec; Tue, 24 May 2005 04:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaUhS-00041r-Bq for ltru@megatron.ietf.org; Tue, 24 May 2005 04:23:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06273 for ; Tue, 24 May 2005 04:23:39 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DaUf6-0005Ds-D8 for ltru@lists.ietf.org; Tue, 24 May 2005 10:21:16 +0200 Received: from pd9fba80a.dip.t-dialin.net ([217.251.168.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2005 10:21:16 +0200 Received: from nobody by pd9fba80a.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2005 10:21:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 24 May 2005 10:21:24 +0200 Organization: Lines: 32 Message-ID: <4292E404.65BB@xyzzy.claranet.de> References: <20050523213022.YXF28811.mta8.adelphia.net@megatron.ietf.org> <004801c5601e$2d0ded60$030aa8c0@DEWELL> <01d701c5602d$3aa1bc40$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba80a.dip.t-dialin.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Fix for ambiguous conformance requirements X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > "[a]ny such limitation MUST be clearly documented" It was "MUST be documented" + "ShOULD NOT be divided", and we agreed to swap MUST / SHOULD. Didn't quite make it in -02, I forgot to check it, Still needs to be fixed in -03pre. > "If the processor generates tags, it MUST do so in canonical > form..." doesn't fit within 2119's framework, but a SHOULD > would be appropriate. Apparently that has been removed in -03pre. > "it is reasonable to assume that there MUST be additional > very compelling evidence", the "MUST" clearly should be > "must". Indeed. This MUST be a disease of all draft editors, sooner or later they forget that lower case "must", "should", etc. still exist and even have a meaning. > a couple of "STRONGLY RECOMMENDED"s Two. Still in -03pre. In theory it's allowed to define it, but it would look silly. The first I ever saw an IETF WG it was in the process of an "OUGHT-ification" with an upper case OUGHT as something that's not quite a SHOULD. The effect was hilarious... and removed a.s.a.p. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 04:40:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaUxm-0006SO-FB; Tue, 24 May 2005 04:40:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaUxl-0006SJ-2o for ltru@megatron.ietf.org; Tue, 24 May 2005 04:40:33 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07757 for ; Tue, 24 May 2005 04:40:30 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DaUvY-00075G-8A for ltru@lists.ietf.org; Tue, 24 May 2005 10:38:16 +0200 Received: from pd9fba80a.dip.t-dialin.net ([217.251.168.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2005 10:38:16 +0200 Received: from nobody by pd9fba80a.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2005 10:38:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 24 May 2005 10:38:45 +0200 Organization: Lines: 15 Message-ID: <4292E815.59F0@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B7F3930@irvmbxw01.quest.com> <6.2.1.2.2.20050524032333.04472ca0@mail.jefsey.com> <001c01c56012$68c13ee0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba80a.dip.t-dialin.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #967] address homograph issues in security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > Would other WG members object to including this statement? No, it's a good idea, better than the rules trying to enforce a minimum of common sense on the side of the tag reviewer. | A language tag in content is only a claim by the publisher of | this content, it can be intentionally misleading. E.g. the | script could be abused to diguise homographs attacks. Something in this direction in the security considerations. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 09:48:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZlt-00010W-Nq; Tue, 24 May 2005 09:48:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZls-0000ze-GU for ltru@megatron.ietf.org; Tue, 24 May 2005 09:48:36 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00950 for ; Tue, 24 May 2005 09:48:34 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050524134804.PHRA8952.mta9.adelphia.net@DEWELL> for ; Tue, 24 May 2005 09:48:04 -0400 Message-ID: <007f01c56067$24fbb1e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 24 May 2005 06:47:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Fix for ambiguous conformance requirements X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > The phrase "[a]ny such limitation MUST be clearly documented" doesn't > quite work when one considers the RFC 2119 guidelines which state "In > particular, they MUST only be used where it is actually required for > interoperation or to limit behavior which has potential for causing > harm". I suggest replacing this MUST with SHOULD. I think a protocol that allows tags to be truncated at an arbitrary limit, without giving any indication of what that limit is, is right on the edge of "having potential for causing harm." It could change the meaning of tags in substantial ways. SHOULD doesn't seem strong enough. Is there some way we can convey that it's a really, really awful idea without running afoul of RFC 2119? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 12:02:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dabrm-0001HU-VW; Tue, 24 May 2005 12:02:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dabrm-0001HO-9N for ltru@megatron.ietf.org; Tue, 24 May 2005 12:02:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13953 for ; Tue, 24 May 2005 12:02:47 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dac9y-0000rY-F9 for ltru@ietf.org; Tue, 24 May 2005 12:21:39 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 09:02:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Fix for ambiguous conformance requirements Date: Tue, 24 May 2005 09:02:34 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3C8A@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Fix for ambiguous conformance requirements Thread-Index: AcVgZ4LV6oK9+JrVQBmwZBaeP/PniQAEkSrg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 24 May 2005 16:02:35.0034 (UTC) FILETIME=[FFE38FA0:01C56079] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1469916970==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1469916970== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 V2UgY291bGQganVzdCBzYXkgdGhhdDoNCg0KImFueSBzdWNoIGxpbWl0YXRpb24gU0hPVUxEIGJl IGNsZWFybHkgZG9jdW1lbnRlZC4gQSBwcm90b2NvbCB0aGF0IGFsbG93cyB0YWdzIHRvIGJlIHRy dW5jYXRlZCBhdCBhbiBhcmJpdHJhcnkNCmxpbWl0LCB3aXRob3V0IGdpdmluZyBhbnkgaW5kaWNh dGlvbiBvZiB3aGF0IHRoYXQgbGltaXQgaXMsIGhhcyB0aGUgcG90ZW50aWFsIGZvciBjYXVzaW5n IHN1YnN0YW50aWFsIGhhcm0gYnkgY2hhbmdpbmcgdGhlDQptZWFuaW5nIG9mIHRhZ3MgaW4gc3Vi c3RhbnRpYWwgd2F5cy4iDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFs aXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9u YWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBu b3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcgW21haWx0 bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBEb3VnIEV3ZWxs DQo+IFNlbnQ6IDIwMDXlubQ15pyIMjTml6UgNjo0OA0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3Vw DQo+IFN1YmplY3Q6IFtMdHJ1XSBSZTogRml4IGZvciBhbWJpZ3VvdXMgY29uZm9ybWFuY2UgcmVx dWlyZW1lbnRzDQo+IA0KPiBSYW5keSBQcmVzdWhuIDxyYW5keSB1bmRlcnNjb3JlIHByZXN1aG4g YXQgbWluZHNwcmluZyBkb3QgY29tPiB3cm90ZToNCj4gDQo+ID4gVGhlIHBocmFzZSAiW2Fdbnkg c3VjaCBsaW1pdGF0aW9uIE1VU1QgYmUgY2xlYXJseSBkb2N1bWVudGVkIiBkb2Vzbid0DQo+ID4g cXVpdGUgd29yayB3aGVuIG9uZSBjb25zaWRlcnMgdGhlIFJGQyAyMTE5IGd1aWRlbGluZXMgd2hp Y2ggc3RhdGUgIkluDQo+ID4gcGFydGljdWxhciwgdGhleSBNVVNUIG9ubHkgYmUgdXNlZCB3aGVy ZSBpdCBpcyBhY3R1YWxseSByZXF1aXJlZCBmb3INCj4gPiBpbnRlcm9wZXJhdGlvbiBvciB0byBs aW1pdCBiZWhhdmlvciB3aGljaCBoYXMgcG90ZW50aWFsIGZvciBjYXVzaW5nDQo+ID4gaGFybSIu ICBJIHN1Z2dlc3QgcmVwbGFjaW5nIHRoaXMgTVVTVCB3aXRoIFNIT1VMRC4NCj4gDQo+IEkgdGhp bmsgYSBwcm90b2NvbCB0aGF0IGFsbG93cyB0YWdzIHRvIGJlIHRydW5jYXRlZCBhdCBhbiBhcmJp dHJhcnkNCj4gbGltaXQsIHdpdGhvdXQgZ2l2aW5nIGFueSBpbmRpY2F0aW9uIG9mIHdoYXQgdGhh dCBsaW1pdCBpcywgaXMgcmlnaHQgb24NCj4gdGhlIGVkZ2Ugb2YgImhhdmluZyBwb3RlbnRpYWwg Zm9yIGNhdXNpbmcgaGFybS4iICBJdCBjb3VsZCBjaGFuZ2UgdGhlDQo+IG1lYW5pbmcgb2YgdGFn cyBpbiBzdWJzdGFudGlhbCB3YXlzLiAgU0hPVUxEIGRvZXNuJ3Qgc2VlbSBzdHJvbmcgZW5vdWdo Lg0KPiBJcyB0aGVyZSBzb21lIHdheSB3ZSBjYW4gY29udmV5IHRoYXQgaXQncyBhIHJlYWxseSwg cmVhbGx5IGF3ZnVsIGlkZWENCj4gd2l0aG91dCBydW5uaW5nIGFmb3VsIG9mIFJGQyAyMTE5Pw0K PiANCj4gLS0NCj4gRG91ZyBFd2VsbA0KPiBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gaHR0cDov L3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxp c3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sdHJ1DQoNCg== --===============1469916970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1469916970==-- From ltru-bounces@lists.ietf.org Tue May 24 12:08:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dabwt-0001oQ-AB; Tue, 24 May 2005 12:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dabws-0001o9-5y for ltru@megatron.ietf.org; Tue, 24 May 2005 12:08:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14383 for ; Tue, 24 May 2005 12:08:03 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DacF2-00017q-9Z for ltru@ietf.org; Tue, 24 May 2005 12:26:55 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 09:07:52 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 09:07:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Editorial error in BNF Date: Tue, 24 May 2005 09:07:23 -0700 Message-ID: Thread-Topic: [Ltru] Editorial error in BNF Thread-Index: AcVf8ULNLV/WSP5XQrygQ2q9aXkhvAAAQGdAAB/0dpA= From: "Peter Constable" To: X-OriginalArrivalTime: 24 May 2005 16:07:52.0587 (UTC) FILETIME=[BD2A4DB0:01C5607A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > 2*3ALPHA describes assigned subtags (i.e. subtags that are valid). 4ALPHA > is reserved for future standardization and are not valid currently. That's > the reason I didn't change the ABNF, although I'm not religious about it. > The opposite case is easy enough to make. It's not at all obvious if and how a 639-6 standard would get integrated into a successor to RFC3066. An obvious concern is that there isn't a clean fit into the morphology of 3066bis. Consider what *kinds* of entities are denoted. For comparison, in the case of 639-3 the entities denoted all correspond to lang or lang-extlang productions in 3066bis, and in the latter case how it would fit with the morphology is clear: a 639-1/-2/-3 ID in the lang subtag and a 639-3 ID in the extlang subtag where the two have a macrolanguage mapping defined in 639-3. But samples from the proposed code table for 639-6 indicate that *many* kinds of entities will be denoted. These could correspond to the following bits of morphology in 3066bis: lang lang-extlang lang-*-script lang-*-*-region lang-*-*-*-variant lang-*-region-variant lang-script-*-variant (for orthographic variants) (I leave the asterisks in to reflect the potential need for those intervening subtags to be combinable with an 639-6 ID.) It's not at all clear how the 639-6 IDs would interact with this morphology, though it is clear that there'd be a big issue with synonym. Plus there would be a large number of IDs for non-terminal nodes in language-classification trees, like the collections of 639-2 and 639-5, which really wouldn't be that useful in IETF language tags. Given some pretty major issues that would need to be worked out and which nobody here has given any thought to that I know of, my inclination in *this* revision would be to make no reference to the possibility of 4alpha in the lang subtag. The 639-6 project is still in very early stages; there isn't a complete working draft yet. When it gets to an advanced stage (at least CD, more probably DIS -- enough so that we really know what it will look like and can estimate when it will be completed), then we can begin to consider a further revision to incorporate it. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 12:15:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabzT-0002Cz-Vs; Tue, 24 May 2005 12:10:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabzS-0002Ct-P7 for ltru@megatron.ietf.org; Tue, 24 May 2005 12:10:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14621 for ; Tue, 24 May 2005 12:10:44 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DacHf-0001E3-4B for ltru@ietf.org; Tue, 24 May 2005 12:29:36 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 09:10:36 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 09:10:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Editorial error in BNF Date: Tue, 24 May 2005 09:10:06 -0700 Message-ID: Thread-Topic: [Ltru] Editorial error in BNF Thread-Index: AcVgA/THHCBtchw6S6C5XbbOMsCwNAAdsHsg From: "Peter Constable" To: X-OriginalArrivalTime: 24 May 2005 16:10:36.0259 (UTC) FILETIME=[1EB8AB30:01C5607B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Mark Davis > One of the goals of the project was that the BNF never needs to be changed > in the future; that every current parser must be able to read every future > tag. (You've reminded me of this on occasion!) So it must be changed to > 2*4 See my comments in another msg just sent: I do not think at this point we can know what the syntax for language tags that incorporate an ISO 639-6 standard would look like, so I think the requirement that devs be able to anticipate that future syntax with certainty now is impossible. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 12:38:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DacQH-0008T9-2G; Tue, 24 May 2005 12:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DacQF-0008Sy-Tu for ltru@megatron.ietf.org; Tue, 24 May 2005 12:38:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17383 for ; Tue, 24 May 2005 12:38:23 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaciR-0002aJ-Bm for ltru@ietf.org; Tue, 24 May 2005 12:57:15 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 09:38:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Editorial error in BNF Date: Tue, 24 May 2005 09:38:13 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3CE7@irvmbxw01.quest.com> Thread-Topic: [Ltru] Editorial error in BNF Thread-Index: AcVgA/THHCBtchw6S6C5XbbOMsCwNAAdsHsgAAC8AWA= From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 24 May 2005 16:38:14.0340 (UTC) FILETIME=[FB03C040:01C5607E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org We wouldn't define the syntax or even the source for alpha4 primary = language subtags. It would work thusly: 1. The ABNF defines lang=3D2*4ALPHA / 5*8alphanum 2. The text defines that ALPHA2 and ALPHA3 subtags are defined by ISO = 639-1 and ISO 639-2. 3. The text says that ALPHA4 subtags are reserved for future = standardization. Implementations know that four letter subtags might be = added to the registry in the future.=20 Implementations know already how to deal with the primary language = subtag(the semantics of ISO 639-6 are not important here) and must be = written to handle registered subtags with length two through eight. = Ultimately this has no impact on implementations: the only effect this = has is that there won't be any four letter primary language subtags in = the registry. Well, it has one effect: a primary language subtag with a = length of four that contains a digit is illegal. In other words, your caution that we should wait to see ISO 639-6 before = standardizing it in language tags is well taken, but not important at = this juncture. We are merely reserving a location in the registry for = those values. Standardization of 3066-based language tags on ISO 639-6 = might never happen or will at least happen in its own time. The exact = same can be said about ISO 639-3. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: 2005?5?24? 9:10 > To: ltru@ietf.org > Subject: RE: [Ltru] Editorial error in BNF >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Mark Davis >=20 >=20 > > One of the goals of the project was that the BNF never needs to be > changed > > in the future; that every current parser must be able to read every > future > > tag. (You've reminded me of this on occasion!) So it must be changed > to > > 2*4 >=20 > See my comments in another msg just sent: I do not think at this point > we can know what the syntax for language tags that incorporate an ISO > 639-6 standard would look like, so I think the requirement that devs = be > able to anticipate that future syntax with certainty now is = impossible. >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 12:56:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dachb-0003KS-E1; Tue, 24 May 2005 12:56:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dacha-0003KN-E0 for ltru@megatron.ietf.org; Tue, 24 May 2005 12:56:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18693 for ; Tue, 24 May 2005 12:56:19 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daczm-0003LX-20 for ltru@ietf.org; Tue, 24 May 2005 13:15:12 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 09:56:10 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 09:56:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Editorial error in BNF Date: Tue, 24 May 2005 09:55:41 -0700 Message-ID: Thread-Topic: [Ltru] Editorial error in BNF Thread-Index: AcVgA/THHCBtchw6S6C5XbbOMsCwNAAdsHsgAAC8AWAAAMos4A== From: "Peter Constable" To: X-OriginalArrivalTime: 24 May 2005 16:56:10.0556 (UTC) FILETIME=[7C7D47C0:01C56081] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org My point is that it's not even clear that the *lang* subtag is where these would go. But I guess I don't care if you want to allow for possible 4alpha subtags that *might* be defined some day; it just seems rather speculative. If someone suggested we might someday allow 4alphanum (not purely alpha or purely num) in the region slot, would we go ahead and define the syntax for that now? Peter Constable > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Tuesday, May 24, 2005 9:38 AM > To: Peter Constable; ltru@ietf.org > Subject: RE: [Ltru] Editorial error in BNF >=20 > We wouldn't define the syntax or even the source for alpha4 primary > language subtags. It would work thusly: >=20 > 1. The ABNF defines lang=3D2*4ALPHA / 5*8alphanum > 2. The text defines that ALPHA2 and ALPHA3 subtags are defined by ISO 639- > 1 and ISO 639-2. > 3. The text says that ALPHA4 subtags are reserved for future > standardization. Implementations know that four letter subtags might be > added to the registry in the future. >=20 > Implementations know already how to deal with the primary language > subtag(the semantics of ISO 639-6 are not important here) and must be > written to handle registered subtags with length two through eight. > Ultimately this has no impact on implementations: the only effect this has > is that there won't be any four letter primary language subtags in the > registry. Well, it has one effect: a primary language subtag with a length > of four that contains a digit is illegal. >=20 > In other words, your caution that we should wait to see ISO 639-6 before > standardizing it in language tags is well taken, but not important at this > juncture. We are merely reserving a location in the registry for those > values. Standardization of 3066-based language tags on ISO 639-6 might > never happen or will at least happen in its own time. The exact same can > be said about ISO 639-3. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Peter Constable > > Sent: 2005?5?24? 9:10 > > To: ltru@ietf.org > > Subject: RE: [Ltru] Editorial error in BNF > > > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > > On > > > Behalf Of Mark Davis > > > > > > > One of the goals of the project was that the BNF never needs to be > > changed > > > in the future; that every current parser must be able to read every > > future > > > tag. (You've reminded me of this on occasion!) So it must be changed > > to > > > 2*4 > > > > See my comments in another msg just sent: I do not think at this point > > we can know what the syntax for language tags that incorporate an ISO > > 639-6 standard would look like, so I think the requirement that devs be > > able to anticipate that future syntax with certainty now is impossible. > > > > > > > > Peter Constable > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 13:29:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadDi-0007l7-JP; Tue, 24 May 2005 13:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadDg-0007ks-ST for ltru@megatron.ietf.org; Tue, 24 May 2005 13:29:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21579 for ; Tue, 24 May 2005 13:29:29 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DadVs-0004mM-IV for ltru@ietf.org; Tue, 24 May 2005 13:48:21 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4OHTGpL022588; Tue, 24 May 2005 10:29:16 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 May 2005 10:29:16 -0700 Message-ID: From: "McDonald, Ira" To: "'Peter Constable'" , ltru@ietf.org Subject: RE: [Ltru] Editorial error in BNF Date: Tue, 24 May 2005 10:29:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Peter, I tend to agree with you about defining things for the future. If the future's very close (months later) that might work. RFC 3066 defined the format of language tags such that future changes/additions of subtag elements would still allow a successful parse. That seems to be the intent here, but I'm not convinced that it can be achieved. Unfortunately, it's rather important that it _is_ achieved, because otherwise clients that examine language tags on returned results will fail to parse them when a non-trivial new subtag element is defined in RFC3066ter. That would mask entirely access to the that new content to the older client. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Peter Constable > Sent: Tuesday, May 24, 2005 12:56 PM > To: ltru@ietf.org > Subject: RE: [Ltru] Editorial error in BNF > > > My point is that it's not even clear that the *lang* subtag is where > these would go. But I guess I don't care if you want to allow for > possible 4alpha subtags that *might* be defined some day; it > just seems > rather speculative. If someone suggested we might someday allow > 4alphanum (not purely alpha or purely num) in the region > slot, would we > go ahead and define the syntax for that now? > > > Peter Constable > > > > > -----Original Message----- > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > Sent: Tuesday, May 24, 2005 9:38 AM > > To: Peter Constable; ltru@ietf.org > > Subject: RE: [Ltru] Editorial error in BNF > > > > We wouldn't define the syntax or even the source for alpha4 primary > > language subtags. It would work thusly: > > > > 1. The ABNF defines lang=2*4ALPHA / 5*8alphanum > > 2. The text defines that ALPHA2 and ALPHA3 subtags are > defined by ISO > 639- > > 1 and ISO 639-2. > > 3. The text says that ALPHA4 subtags are reserved for future > > standardization. Implementations know that four letter subtags might > be > > added to the registry in the future. > > > > Implementations know already how to deal with the primary language > > subtag(the semantics of ISO 639-6 are not important here) > and must be > > written to handle registered subtags with length two through eight. > > Ultimately this has no impact on implementations: the only > effect this > has > > is that there won't be any four letter primary language > subtags in the > > registry. Well, it has one effect: a primary language subtag with a > length > > of four that contains a digit is illegal. > > > > In other words, your caution that we should wait to see ISO 639-6 > before > > standardizing it in language tags is well taken, but not > important at > this > > juncture. We are merely reserving a location in the > registry for those > > values. Standardization of 3066-based language tags on ISO > 639-6 might > > never happen or will at least happen in its own time. The exact same > can > > be said about ISO 639-3. > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > > On > > > Behalf Of Peter Constable > > > Sent: 2005?5?24? 9:10 > > > To: ltru@ietf.org > > > Subject: RE: [Ltru] Editorial error in BNF > > > > > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > Behalf Of Mark Davis > > > > > > > > > > One of the goals of the project was that the BNF never > needs to be > > > changed > > > > in the future; that every current parser must be able to read > every > > > future > > > > tag. (You've reminded me of this on occasion!) So it must be > changed > > > to > > > > 2*4 > > > > > > See my comments in another msg just sent: I do not think at this > point > > > we can know what the syntax for language tags that incorporate an > ISO > > > 639-6 standard would look like, so I think the > requirement that devs > be > > > able to anticipate that future syntax with certainty now is > impossible. > > > > > > > > > > > > Peter Constable > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 13:36:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadKn-0001uv-I5; Tue, 24 May 2005 13:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadKm-0001uW-4P for ltru@megatron.ietf.org; Tue, 24 May 2005 13:36:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24802 for ; Tue, 24 May 2005 13:36:49 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dadcw-0005aU-VM for ltru@ietf.org; Tue, 24 May 2005 13:55:42 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:36:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Editorial error in BNF Date: Tue, 24 May 2005 10:36:38 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3D60@irvmbxw01.quest.com> Thread-Topic: [Ltru] Editorial error in BNF Thread-Index: AcVgA/THHCBtchw6S6C5XbbOMsCwNAAdsHsgAAC8AWAAAMos4AAATIKg From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 24 May 2005 17:36:38.0972 (UTC) FILETIME=[23F027C0:01C56087] X-Spam-Score: 1.0 (+) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > rather speculative. If someone suggested we might someday allow > 4alphanum (not purely alpha or purely num) in the region slot, would = we > go ahead and define the syntax for that now? Yes. It would break the design to do that, of course. > My point is that it's not even clear that the *lang* subtag is where > these would go. But I guess I don't care if you want to allow for > possible 4alpha subtags that *might* be defined some day; it just = seems The consensus seemed to be: we know that ISO 639-6 is being worked on. = The material is not mature enough to incorporate into 3066bis. However, = we can make a very minor marginal allowance for the possibility of ISO = 639-6 being of value in forming language tags at some future date and = the only cost is forbidding the registration of alpha4 subtags for now. A future update could incorporate ISO 639-6 in an appropriate way or = restore the ability to register alpha4 subtags or, as you say, allow = registration of alphanum4 subtags. In other words, there is no cost to do it and it was a consensus to = reserve a slot in case it becomes interesting/necessary in the future. = I'm not going to defend ISO 639-6 here: I am actually skeptical about = the effort, but there is no reason to prevent ISO 639-6 from being = easily incorporated at a future date. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: 2005?5?24? 9:56 > To: ltru@ietf.org > Subject: RE: [Ltru] Editorial error in BNF >=20 > My point is that it's not even clear that the *lang* subtag is where > these would go. But I guess I don't care if you want to allow for > possible 4alpha subtags that *might* be defined some day; it just = seems > rather speculative. If someone suggested we might someday allow > 4alphanum (not purely alpha or purely num) in the region slot, would = we > go ahead and define the syntax for that now? >=20 >=20 > Peter Constable >=20 >=20 >=20 > > -----Original Message----- > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > Sent: Tuesday, May 24, 2005 9:38 AM > > To: Peter Constable; ltru@ietf.org > > Subject: RE: [Ltru] Editorial error in BNF > > > > We wouldn't define the syntax or even the source for alpha4 primary > > language subtags. It would work thusly: > > > > 1. The ABNF defines lang=3D2*4ALPHA / 5*8alphanum > > 2. The text defines that ALPHA2 and ALPHA3 subtags are defined by = ISO > 639- > > 1 and ISO 639-2. > > 3. The text says that ALPHA4 subtags are reserved for future > > standardization. Implementations know that four letter subtags might > be > > added to the registry in the future. > > > > Implementations know already how to deal with the primary language > > subtag(the semantics of ISO 639-6 are not important here) and must = be > > written to handle registered subtags with length two through eight. > > Ultimately this has no impact on implementations: the only effect = this > has > > is that there won't be any four letter primary language subtags in = the > > registry. Well, it has one effect: a primary language subtag with a > length > > of four that contains a digit is illegal. > > > > In other words, your caution that we should wait to see ISO 639-6 > before > > standardizing it in language tags is well taken, but not important = at > this > > juncture. We are merely reserving a location in the registry for = those > > values. Standardization of 3066-based language tags on ISO 639-6 = might > > never happen or will at least happen in its own time. The exact same > can > > be said about ISO 639-3. > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > > On > > > Behalf Of Peter Constable > > > Sent: 2005?5?24? 9:10 > > > To: ltru@ietf.org > > > Subject: RE: [Ltru] Editorial error in BNF > > > > > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > Behalf Of Mark Davis > > > > > > > > > > One of the goals of the project was that the BNF never needs to = be > > > changed > > > > in the future; that every current parser must be able to read > every > > > future > > > > tag. (You've reminded me of this on occasion!) So it must be > changed > > > to > > > > 2*4 > > > > > > See my comments in another msg just sent: I do not think at this > point > > > we can know what the syntax for language tags that incorporate an > ISO > > > 639-6 standard would look like, so I think the requirement that = devs > be > > > able to anticipate that future syntax with certainty now is > impossible. > > > > > > > > > > > > Peter Constable > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 13:41:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadPH-0004du-OI; Tue, 24 May 2005 13:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadPF-0004dp-Sh for ltru@megatron.ietf.org; Tue, 24 May 2005 13:41:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25405 for ; Tue, 24 May 2005 13:41:28 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DadhS-0005pM-SL for ltru@ietf.org; Tue, 24 May 2005 14:00:20 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4OHfH12021042; Tue, 24 May 2005 13:41:17 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 24 May 2005 13:41:14 -0400 Date: Tue, 24 May 2005 13:41:14 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Editorial error in BNF Message-ID: <20050524174053.GA26310@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B7F3CE7@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B7F3CE7@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > Implementations know already how to deal with the primary language > subtag(the semantics of ISO 639-6 are not important here) and must > be written to handle registered subtags with length two through > eight. Ultimately this has no impact on implementations: the only > effect this has is that there won't be any four letter primary language > subtags in the registry. Well, it has one effect: a primary language > subtag with a length of four that contains a digit is illegal. +1 -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 13:58:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dadfv-00076E-Al; Tue, 24 May 2005 13:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dadfu-00075W-Fm for ltru@megatron.ietf.org; Tue, 24 May 2005 13:58:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26461 for ; Tue, 24 May 2005 13:58:40 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dady7-0006Uw-5x for ltru@ietf.org; Tue, 24 May 2005 14:17:32 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:58:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Fix for ambiguous conformance requirements Date: Tue, 24 May 2005 10:58:29 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3D94@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Fix for ambiguous conformance requirements Thread-Index: AcVgOf4RQHg9Fx7rQTaxwmMH2Jtc2QAT17tA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 24 May 2005 17:58:30.0396 (UTC) FILETIME=[319B93C0:01C5608A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Changes being made as noted below. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?5?24? 1:21 > To: ltru@ietf.org > Subject: [Ltru] Re: Fix for ambiguous conformance requirements >=20 > Randy Presuhn wrote: >=20 > > "[a]ny such limitation MUST be clearly documented" >=20 > It was "MUST be documented" + "ShOULD NOT be divided", and we > agreed to swap MUST / SHOULD. Didn't quite make it in -02, I > forgot to check it, Still needs to be fixed in -03pre [Addison Phillips]=20 Done, will post later. . >=20 > > "If the processor generates tags, it MUST do so in canonical > > form..." doesn't fit within 2119's framework, but a SHOULD > > would be appropriate. >=20 > Apparently that has been removed in -03pre. [Addison Phillips]=20 References to canonical form are mostly removed or SHOULD-ified. >=20 > > "it is reasonable to assume that there MUST be additional > > very compelling evidence", the "MUST" clearly should be > > "must". >=20 > Indeed. This MUST be a disease of all draft editors, > sooner or later they forget that lower case "must", "should", > etc. still exist and even have a meaning. [Addison Phillips]=20 De-MUSTardized. >=20 > > a couple of "STRONGLY RECOMMENDED"s >=20 > Two. Still in -03pre. In theory it's allowed to define it, > but it would look silly. The first I ever saw an IETF WG it > was in the process of an "OUGHT-ification" with an upper case OUGHT as > something that's not quite a SHOULD. The effect was > hilarious... and removed a.s.a.p. [Addison Phillips]=20 Fixed. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 14:58:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daebm-0007V6-To; Tue, 24 May 2005 14:58:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daebl-0007V1-Vb for ltru@megatron.ietf.org; Tue, 24 May 2005 14:58:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01093 for ; Tue, 24 May 2005 14:58:28 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daeu0-00005c-Gn for ltru@ietf.org; Tue, 24 May 2005 15:17:21 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 11:58:19 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 11:58:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Editorial error in BNF Date: Tue, 24 May 2005 11:57:50 -0700 Message-ID: Thread-Topic: [Ltru] Editorial error in BNF Thread-Index: AcVgA/THHCBtchw6S6C5XbbOMsCwNAAdsHsgAAC8AWAAAMos4AAATIKgAAQZbXA= From: "Peter Constable" To: X-OriginalArrivalTime: 24 May 2005 18:58:19.0639 (UTC) FILETIME=[8CF69870:01C56092] X-Spam-Score: 1.0 (+) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I'm OK with moving forward on this basis. Peter Constable > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Tuesday, May 24, 2005 10:37 AM > To: Peter Constable; ltru@ietf.org > Subject: RE: [Ltru] Editorial error in BNF >=20 > > rather speculative. If someone suggested we might someday allow > > 4alphanum (not purely alpha or purely num) in the region slot, would we > > go ahead and define the syntax for that now? >=20 > Yes. It would break the design to do that, of course. >=20 > > My point is that it's not even clear that the *lang* subtag is where > > these would go. But I guess I don't care if you want to allow for > > possible 4alpha subtags that *might* be defined some day; it just seems >=20 > The consensus seemed to be: we know that ISO 639-6 is being worked on. The > material is not mature enough to incorporate into 3066bis. However, we can > make a very minor marginal allowance for the possibility of ISO 639-6 > being of value in forming language tags at some future date and the only > cost is forbidding the registration of alpha4 subtags for now. >=20 > A future update could incorporate ISO 639-6 in an appropriate way or > restore the ability to register alpha4 subtags or, as you say, allow > registration of alphanum4 subtags. >=20 > In other words, there is no cost to do it and it was a consensus to > reserve a slot in case it becomes interesting/necessary in the future. I'm > not going to defend ISO 639-6 here: I am actually skeptical about the > effort, but there is no reason to prevent ISO 639-6 from being easily > incorporated at a future date. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Peter Constable > > Sent: 2005?5?24? 9:56 > > To: ltru@ietf.org > > Subject: RE: [Ltru] Editorial error in BNF > > > > My point is that it's not even clear that the *lang* subtag is where > > these would go. But I guess I don't care if you want to allow for > > possible 4alpha subtags that *might* be defined some day; it just seems > > rather speculative. If someone suggested we might someday allow > > 4alphanum (not purely alpha or purely num) in the region slot, would we > > go ahead and define the syntax for that now? > > > > > > Peter Constable > > > > > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > > Sent: Tuesday, May 24, 2005 9:38 AM > > > To: Peter Constable; ltru@ietf.org > > > Subject: RE: [Ltru] Editorial error in BNF > > > > > > We wouldn't define the syntax or even the source for alpha4 primary > > > language subtags. It would work thusly: > > > > > > 1. The ABNF defines lang=3D2*4ALPHA / 5*8alphanum > > > 2. The text defines that ALPHA2 and ALPHA3 subtags are defined by ISO > > 639- > > > 1 and ISO 639-2. > > > 3. The text says that ALPHA4 subtags are reserved for future > > > standardization. Implementations know that four letter subtags might > > be > > > added to the registry in the future. > > > > > > Implementations know already how to deal with the primary language > > > subtag(the semantics of ISO 639-6 are not important here) and must be > > > written to handle registered subtags with length two through eight. > > > Ultimately this has no impact on implementations: the only effect this > > has > > > is that there won't be any four letter primary language subtags in the > > > registry. Well, it has one effect: a primary language subtag with a > > length > > > of four that contains a digit is illegal. > > > > > > In other words, your caution that we should wait to see ISO 639-6 > > before > > > standardizing it in language tags is well taken, but not important at > > this > > > juncture. We are merely reserving a location in the registry for those > > > values. Standardization of 3066-based language tags on ISO 639-6 might > > > never happen or will at least happen in its own time. The exact same > > can > > > be said about ISO 639-3. > > > > > > Addison > > > > > > Addison P. Phillips > > > Globalization Architect, Quest Software > > > Chair, W3C Internationalization Core Working Group > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > -----Original Message----- > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > Behalf Of Peter Constable > > > > Sent: 2005?5?24? 9:10 > > > > To: ltru@ietf.org > > > > Subject: RE: [Ltru] Editorial error in BNF > > > > > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > > > On > > > > > Behalf Of Mark Davis > > > > > > > > > > > > > One of the goals of the project was that the BNF never needs to be > > > > changed > > > > > in the future; that every current parser must be able to read > > every > > > > future > > > > > tag. (You've reminded me of this on occasion!) So it must be > > changed > > > > to > > > > > 2*4 > > > > > > > > See my comments in another msg just sent: I do not think at this > > point > > > > we can know what the syntax for language tags that incorporate an > > ISO > > > > 639-6 standard would look like, so I think the requirement that devs > > be > > > > able to anticipate that future syntax with certainty now is > > impossible. > > > > > > > > > > > > > > > > Peter Constable > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 16:18:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafrH-0005jl-KI; Tue, 24 May 2005 16:18:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafrG-0005gi-9K for ltru@megatron.ietf.org; Tue, 24 May 2005 16:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20620 for ; Tue, 24 May 2005 16:18:32 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dag9T-00079W-JU for ltru@ietf.org; Tue, 24 May 2005 16:37:25 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 13:18:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #967] addresshomographissuesinsecurityconsiderations Date: Tue, 24 May 2005 13:18:16 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3EB8@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #967] addresshomographissuesinsecurityconsiderations Thread-Index: AcVf/QIDqY42Lfb9S0KRPwpJ5KBLigAn54qw From: "Addison Phillips" To: "Martin Duerst" , "Randy Presuhn" , X-OriginalArrivalTime: 24 May 2005 20:18:17.0546 (UTC) FILETIME=[B8BD1AA0:01C5609D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The simplest possibility would eliminate all of this (pointless) text: = we can eliminate the homograph problem altogether in a very simple = manner. Require subtags to be all ALPHA or all DIGIT. This actually = affects only registered primary language subtags and registered variants = and *no* extant subtags. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2005?5?23? 18:07 > To: Addison Phillips; Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] [psg.com #967] > addresshomographissuesinsecurityconsiderations >=20 > At 07:29 05/05/24, Addison Phillips wrote: > >Since this is a rule that is unlikely to come into play often (if = ever), > >making it a MUST is hardly a hardship. >=20 > Well, yes and no. Will somebody be able to provide some kind of > software to IANA for checking this? Doing this kind of check by > hand is extremely tedious, and the fact that the problem occurs > very rarely makes it easy to just leave the check out. >=20 > Regards, Martin. >=20 > >In fact, it is nice and crisp (and > >applies to a very small set of subtags---exactly none as of = draft-03). _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 16:57:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DagTJ-0006Ju-Pn; Tue, 24 May 2005 16:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DagTH-0006Jo-GX for ltru@megatron.ietf.org; Tue, 24 May 2005 16:57:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23843 for ; Tue, 24 May 2005 16:57:49 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaglW-0000Eq-0q for ltru@ietf.org; Tue, 24 May 2005 17:16:43 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j4OKvWJ3002335; Tue, 24 May 2005 13:57:38 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 May 2005 13:57:32 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Martin Duerst , Randy Presuhn , ltru@ietf.org Subject: RE: [Ltru] [psg.com #967] addresshomographissuesinsecurityconside rations Date: Tue, 24 May 2005 13:57:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 Eliminating mixed ALPHA/DIGIT in individual subtags is a _fine_ idea. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Tuesday, May 24, 2005 4:18 PM > To: Martin Duerst; Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] [psg.com #967] > addresshomographissuesinsecurityconsiderations > > > The simplest possibility would eliminate all of this > (pointless) text: we can eliminate the homograph problem > altogether in a very simple manner. Require subtags to be all > ALPHA or all DIGIT. This actually affects only registered > primary language subtags and registered variants and *no* > extant subtags. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: 2005?5?23? 18:07 > > To: Addison Phillips; Randy Presuhn; ltru@ietf.org > > Subject: RE: [Ltru] [psg.com #967] > > addresshomographissuesinsecurityconsiderations > > > > At 07:29 05/05/24, Addison Phillips wrote: > > >Since this is a rule that is unlikely to come into play > often (if ever), > > >making it a MUST is hardly a hardship. > > > > Well, yes and no. Will somebody be able to provide some kind of > > software to IANA for checking this? Doing this kind of check by > > hand is extremely tedious, and the fact that the problem occurs > > very rarely makes it easy to just leave the check out. > > > > Regards, Martin. > > > > >In fact, it is nice and crisp (and > > >applies to a very small set of subtags---exactly none as > of draft-03). > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 17:25:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dagu2-0003Dh-E3; Tue, 24 May 2005 17:25:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dagu0-0003Dc-DN for ltru@megatron.ietf.org; Tue, 24 May 2005 17:25:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25541 for ; Tue, 24 May 2005 17:25:25 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DahCD-0001PR-Jh for ltru@ietf.org; Tue, 24 May 2005 17:44:20 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4OLPBua406000 for ; Tue, 24 May 2005 17:25:11 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OLPAGO133988 for ; Tue, 24 May 2005 15:25:11 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4OLPAaF021229 for ; Tue, 24 May 2005 15:25:10 -0600 Received: from markdavis (sig-9-48-124-62.mts.ibm.com [9.48.124.62]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j4OLP9RE021192; Tue, 24 May 2005 15:25:09 -0600 Message-ID: <094401c560a7$0e329c90$54713009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Martin Duerst" , "Randy Presuhn" , References: <634978A7DF025A40BFEF33EB191E13BC0B7F3EB8@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #967]addresshomographissuesinsecurityconsiderations Date: Tue, 24 May 2005 14:25:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j4OLPBua406000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I am wary of this step -- it could be dangerous. If, say, 3166 starts usi= ng, say, C3 because they run out of codes, it will cause a problem. It also doesn't allow for alternatives like 1996a 1996b, which I can perhaps see = a need for. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Martin Duerst" ; "Randy Presuhn" ; Sent: Tuesday, May 24, 2005 13:18 Subject: RE: [Ltru] [psg.com #967]addresshomographissuesinsecurityconsiderations The simplest possibility would eliminate all of this (pointless) text: we can eliminate the homograph problem altogether in a very simple manner. Require subtags to be all ALPHA or all DIGIT. This actually affects only registered primary language subtags and registered variants and *no* exta= nt subtags. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2005?5?23? 18:07 > To: Addison Phillips; Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] [psg.com #967] > addresshomographissuesinsecurityconsiderations > > At 07:29 05/05/24, Addison Phillips wrote: > >Since this is a rule that is unlikely to come into play often (if eve= r), > >making it a MUST is hardly a hardship. > > Well, yes and no. Will somebody be able to provide some kind of > software to IANA for checking this? Doing this kind of check by > hand is extremely tedious, and the fact that the problem occurs > very rarely makes it easy to just leave the check out. > > Regards, Martin. > > >In fact, it is nice and crisp (and > >applies to a very small set of subtags---exactly none as of draft-03). _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 17:27:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dagvb-0003Jb-Ev; Tue, 24 May 2005 17:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DagvZ-0003JR-QK for ltru@megatron.ietf.org; Tue, 24 May 2005 17:27:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25628 for ; Tue, 24 May 2005 17:27:03 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DahDo-0001RA-Ql for ltru@ietf.org; Tue, 24 May 2005 17:45:58 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 14:26:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #941] determining currency of registry versions Date: Tue, 24 May 2005 14:26:52 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B7F3F48@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #941] determining currency of registry versions Thread-Index: AcVWsnidVdxY5Vb7RSqMqrlPQGVtAgJ9LNIg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 24 May 2005 21:26:52.0941 (UTC) FILETIME=[4DB48BD0:01C560A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The text added was slightly different than Randy's suggested text to = finish the resolution of this issue: The first record in the file contains the single field whose = field-name is "File-Date". The field-body of this record contains the = last modification date of this copy of the registry, making it possible to = compare different versions of the registry. The registry on the IANA = website is the most current. Versions with an older date than that one are not up-to-date. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?5?11? 22:22 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #941] determining currency of registry > versions >=20 > Hi - >=20 > > From: "Peter Constable" > > To: "LTRU Working Group" > > Sent: Wednesday, May 11, 2005 8:26 AM > > Subject: RE: [Ltru] [psg.com #941] determining currency of registry > versions > > >=20 > > I think Randy's suggestion revision is reasonable. It's a small = change > > with no negative side effects, and making the change will bring = closure > > to this particular issue quickly. > ... >=20 > Ok, I'll mark this one "resolved". >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 18:46:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaiAA-0000Ka-LE; Tue, 24 May 2005 18:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaiA9-0000JJ-Ex for ltru@megatron.ietf.org; Tue, 24 May 2005 18:46:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02467 for ; Tue, 24 May 2005 18:46:10 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaiSP-0004jj-7a for ltru@ietf.org; Tue, 24 May 2005 19:05:06 -0400 Received: from h-68-166-189-99.snvacaid.dynamic.covad.net ([68.166.189.99] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DaiA6-0000bd-00 for ltru@ietf.org; Tue, 24 May 2005 18:46:10 -0400 Message-ID: <003201c560b2$c0989f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Editorial error in BNF Date: Tue, 24 May 2005 15:48:48 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Peter Constable" > To: > Sent: Tuesday, May 24, 2005 11:57 AM > Subject: RE: [Ltru] Editorial error in BNF > > I'm OK with moving forward on this basis. ... As a contributor, so am I. If we've guessed correctly, it's a major win. If we've our guess is wrong, the harm is insignificant, and could be rectified in an update to the specification. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 19:06:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaiTb-0003bx-Tt; Tue, 24 May 2005 19:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaiTZ-0003bn-VD for ltru@megatron.ietf.org; Tue, 24 May 2005 19:06:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03756 for ; Tue, 24 May 2005 19:06:14 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dailp-0005Ty-8k for ltru@ietf.org; Tue, 24 May 2005 19:25:10 -0400 Received: from h-68-166-189-99.snvacaid.dynamic.covad.net ([68.166.189.99] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DaiTW-0004nk-00 for ltru@ietf.org; Tue, 24 May 2005 19:06:14 -0400 Message-ID: <005201c560b5$8f4c0c40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <007f01c56067$24fbb1e0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Fix for ambiguous conformance requirements Date: Tue, 24 May 2005 16:08:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, May 24, 2005 6:47 AM > Subject: [Ltru] Re: Fix for ambiguous conformance requirements > > Randy Presuhn wrote: > > > The phrase "[a]ny such limitation MUST be clearly documented" doesn't > > quite work when one considers the RFC 2119 guidelines which state "In > > particular, they MUST only be used where it is actually required for > > interoperation or to limit behavior which has potential for causing > > harm". I suggest replacing this MUST with SHOULD. > > I think a protocol that allows tags to be truncated at an arbitrary > limit, without giving any indication of what that limit is, is right on > the edge of "having potential for causing harm." It could change the > meaning of tags in substantial ways. SHOULD doesn't seem strong enough. > Is there some way we can convey that it's a really, really awful idea > without running afoul of RFC 2119? ... *Documenting* the limitation won't help interoperability. The rules regarding truncation is where MUST-speak is most appropriate, since they do have the potential to affect interoperability. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 19:19:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daigl-000673-8F; Tue, 24 May 2005 19:19:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daigj-00066E-J2 for ltru@megatron.ietf.org; Tue, 24 May 2005 19:19:53 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04819 for ; Tue, 24 May 2005 19:19:49 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DaieX-0005UV-L6 for ltru@lists.ietf.org; Wed, 25 May 2005 01:17:38 +0200 Received: from 212.82.251.124 ([212.82.251.124]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 May 2005 01:17:37 +0200 Received: from nobody by 212.82.251.124 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 May 2005 01:17:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 25 May 2005 01:17:08 +0200 Organization: Lines: 14 Message-ID: <4293B5F4.3FA4@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B7F3EB8@irvmbxw01.quest.com> <094401c560a7$0e329c90$54713009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.124 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com#967]addresshomographissuesinsecurityconsiderations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > It also doesn't allow for alternatives like 1996a 1996b, > which I can perhaps see a need for. Me too, the scouse21 example for scouse in the 21st century. But I really don't see any need to mention that sc0use2l is a profoundly bad idea, the tag reviewer isn't some script, (s)he can judge this. Jefsey's concern, the script abused to cause confusion with misleadingly tagged content, was more realistic. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 24 21:40:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daksn-0004He-FK; Tue, 24 May 2005 21:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daksm-0004HZ-3Y for ltru@megatron.ietf.org; Tue, 24 May 2005 21:40:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15182 for ; Tue, 24 May 2005 21:40:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DalB2-0002EA-5s for ltru@ietf.org; Tue, 24 May 2005 21:59:22 -0400 Received: from [82.241.91.24] (helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Daksc-0006kV-T4; Tue, 24 May 2005 18:40:19 -0700 Message-Id: <6.2.1.2.2.20050524233528.047bba30@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 24 May 2005 23:58:15 +0200 To: "McDonald, Ira" , "'Peter Constable'" , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Editorial error in BNF In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear all, I would _strongly_ advise to stabilise your XML oriented tag for the present and to not consider "RFC 3066 ter" now. You all know that I disagree with the concept of this Draft to become BCP 047, and that I find its proposition technically not precise, and conflicting (between a precise orthogonal charset and a non defined notion of "script"). A conflict which is by far not resolved at ISO 639-4 level. Etc. But RFC 3066 bis is proposed/supported by W3C people and it will be used for XML, with the difficulties you all described. If it is accepted, it will be used. So, do not make things more complex for users and developers. Randy will say that the text is not written for me and I should learn English before reading it, but I find enough complexities and oddities (Ira quoted some), not to add more. Please, only include things that WILL work, not things that MIGHT work. Unless, obviously, you want to kill the project because you finally agree with me, without telling it officially. What I doubt. :-( jfc At 19:29 24/05/2005, McDonald, Ira wrote: >Hi Peter, > >I tend to agree with you about defining things for the future. >If the future's very close (months later) that might work. > >RFC 3066 defined the format of language tags such that future >changes/additions of subtag elements would still allow a >successful parse. That seems to be the intent here, but I'm >not convinced that it can be achieved. > >Unfortunately, it's rather important that it _is_ achieved, >because otherwise clients that examine language tags on returned >results will fail to parse them when a non-trivial new subtag >element is defined in RFC3066ter. That would mask entirely >access to the that new content to the older client. > >Cheers, >- Ira > > > >Ira McDonald (Musician / Software Architect) >Blue Roof Music / High North Inc >PO Box 221 Grand Marais, MI 49839 >phone: +1-906-494-2434 >email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Peter Constable > > Sent: Tuesday, May 24, 2005 12:56 PM > > To: ltru@ietf.org > > Subject: RE: [Ltru] Editorial error in BNF > > > > > > My point is that it's not even clear that the *lang* subtag is where > > these would go. But I guess I don't care if you want to allow for > > possible 4alpha subtags that *might* be defined some day; it > > just seems > > rather speculative. If someone suggested we might someday allow > > 4alphanum (not purely alpha or purely num) in the region > > slot, would we > > go ahead and define the syntax for that now? > > > > > > Peter Constable > > > > > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > > Sent: Tuesday, May 24, 2005 9:38 AM > > > To: Peter Constable; ltru@ietf.org > > > Subject: RE: [Ltru] Editorial error in BNF > > > > > > We wouldn't define the syntax or even the source for alpha4 primary > > > language subtags. It would work thusly: > > > > > > 1. The ABNF defines lang=2*4ALPHA / 5*8alphanum > > > 2. The text defines that ALPHA2 and ALPHA3 subtags are > > defined by ISO > > 639- > > > 1 and ISO 639-2. > > > 3. The text says that ALPHA4 subtags are reserved for future > > > standardization. Implementations know that four letter subtags might > > be > > > added to the registry in the future. > > > > > > Implementations know already how to deal with the primary language > > > subtag(the semantics of ISO 639-6 are not important here) > > and must be > > > written to handle registered subtags with length two through eight. > > > Ultimately this has no impact on implementations: the only > > effect this > > has > > > is that there won't be any four letter primary language > > subtags in the > > > registry. Well, it has one effect: a primary language subtag with a > > length > > > of four that contains a digit is illegal. > > > > > > In other words, your caution that we should wait to see ISO 639-6 > > before > > > standardizing it in language tags is well taken, but not > > important at > > this > > > juncture. We are merely reserving a location in the > > registry for those > > > values. Standardization of 3066-based language tags on ISO > > 639-6 might > > > never happen or will at least happen in its own time. The exact same > > can > > > be said about ISO 639-3. > > > > > > Addison > > > > > > Addison P. Phillips > > > Globalization Architect, Quest Software > > > Chair, W3C Internationalization Core Working Group > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > -----Original Message----- > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > Behalf Of Peter Constable > > > > Sent: 2005?5?24? 9:10 > > > > To: ltru@ietf.org > > > > Subject: RE: [Ltru] Editorial error in BNF > > > > > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > > > On > > > > > Behalf Of Mark Davis > > > > > > > > > > > > > One of the goals of the project was that the BNF never > > needs to be > > > > changed > > > > > in the future; that every current parser must be able to read > > every > > > > future > > > > > tag. (You've reminded me of this on occasion!) So it must be > > changed > > > > to > > > > > 2*4 > > > > > > > > See my comments in another msg just sent: I do not think at this > > point > > > > we can know what the syntax for language tags that incorporate an > > ISO > > > > 639-6 standard would look like, so I think the > > requirement that devs > > be > > > > able to anticipate that future syntax with certainty now is > > impossible. > > > > > > > > > > > > > > > > Peter Constable > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 25 01:17:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaoGb-0007LP-SV; Wed, 25 May 2005 01:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaoGa-0007LK-Cz for ltru@megatron.ietf.org; Wed, 25 May 2005 01:17:16 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00930 for ; Wed, 25 May 2005 01:17:15 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050525051644.VWKD8952.mta9.adelphia.net@DEWELL> for ; Wed, 25 May 2005 01:16:44 -0400 Message-ID: <00b301c560e8$e69daf20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 24 May 2005 22:16:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Editorial error in BNF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org For what it is worth, I will go on record as saying the following: I do not believe the mechanism described in draft-ietf-ltru-registry-* is intended only for XML, or suitable only for XML. I believe it is suitable for many different tagging purposes, only one of which is XML. I do not believe the mechanism is supported only by "W3C people." I do not believe the concept of "script" is undefined, or even poorly defined, either in the draft or anywhere else. And I do not believe anyone secretly wants to "kill the project." Those who want it to fail have been very public about it. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 25 02:13:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dap5s-0000aS-6Q; Wed, 25 May 2005 02:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dap5p-0000a9-OD for ltru@megatron.ietf.org; Wed, 25 May 2005 02:10:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13605 for ; Wed, 25 May 2005 02:10:12 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DapO7-0002BE-Un for ltru@ietf.org; Wed, 25 May 2005 02:29:09 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4P69c712152; Wed, 25 May 2005 15:09:38 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id f4c8fd80_cce4_11d9_81bb_0030482532aa_11436; Wed, 25 May 2005 15:19:31 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000A27; 25 May 05 15:12:54 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 25 May 05 15:12:48 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.53) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG000A24; 25 May 05 15:12:37 +0900 Message-Id: <6.0.0.20.2.20050525083711.071cb320@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 25 May 2005 08:43:03 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Fix for ambiguous conformance requirements In-Reply-To: <4292E404.65BB@xyzzy.claranet.de> References: <20050523213022.YXF28811.mta8.adelphia.net@megatron.ietf.org> <004801c5601e$2d0ded60$030aa8c0@DEWELL> <01d701c5602d$3aa1bc40$7f1afea9@oemcomputer> <4292E404.65BB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 17:21 05/05/24, Frank Ellermann wrote: >Randy Presuhn wrote: >> "it is reasonable to assume that there MUST be additional >> very compelling evidence", the "MUST" clearly should be >> "must". > > Indeed. This MUST be a disease of all draft editors, >sooner or later they forget that lower case "must", "should", >etc. still exist and even have a meaning. It would be great if 'must', 'should' could just be used that way. But as a draft editor who has gone through these kinds of things, I can tell you: I'll get comments asking why this isn't upper case, and so on. There are other words that avoid this, such as 'have to',... >> a couple of "STRONGLY RECOMMENDED"s > >Two. Still in -03pre. In theory it's allowed to define it, >but it would look silly. The first I ever saw an IETF WG it >was in the process of an "OUGHT-ification" with an upper case OUGHT as >something that's not quite a SHOULD. The effect was >hilarious... and removed a.s.a.p. For some more on the hilarious side: In the W3C I18N WG, in particular for the Character Model, we use(d) a yellowish color for sentences containing MUST,... (see http://www.w3.org/TR/charmod/#C001 for an example). We talked about adding MUSTard when we discovered that there was something that needed a MUST :-). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 25 03:52:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqgS-0000oJ-67; Wed, 25 May 2005 03:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqgR-0000oB-41 for ltru@megatron.ietf.org; Wed, 25 May 2005 03:52:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16386 for ; Wed, 25 May 2005 03:52:05 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daqyl-00054W-Q7 for ltru@ietf.org; Wed, 25 May 2005 04:11:05 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN8-942942e872a2; Wed, 25 May 2005 03:51:36 -0500 Received: from DEBHOME (ACD8E76E.ipt.aol.com [172.216.231.110]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j4P7pQfe019126; Wed, 25 May 2005 03:51:26 -0400 Message-Id: <200505250751.j4P7pQfe019126@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Randy Presuhn'" , Subject: RE: [Ltru] Editorial error in BNF Date: Wed, 25 May 2005 08:51:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVgspwkIsyQ6ua1QGqVXaXKlngvaQASvZ3Q In-Reply-To: <003201c560b2$c0989f00$7f1afea9@oemcomputer> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 2.6 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > If we've guessed correctly, it's a major win. > If we've our guess is wrong, the harm is insignificant, and could > be rectified in an update to the specification. + 1 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: 24 May 2005 23:49 > To: ltru@ietf.org > Subject: Re: [Ltru] Editorial error in BNF > > Hi - > > > From: "Peter Constable" > > To: > > Sent: Tuesday, May 24, 2005 11:57 AM > > Subject: RE: [Ltru] Editorial error in BNF > > > > > I'm OK with moving forward on this basis. > ... > > As a contributor, so am I. > If we've guessed correctly, it's a major win. > If we've our guess is wrong, the harm is insignificant, and could > be rectified in an update to the specification. > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 25 09:49:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DawGJ-0003Gr-Er; Wed, 25 May 2005 09:49:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DawGH-0003GO-HJ for ltru@megatron.ietf.org; Wed, 25 May 2005 09:49:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12496 for ; Wed, 25 May 2005 09:49:27 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DawYb-0006Yw-JY for ltru@ietf.org; Wed, 25 May 2005 10:08:30 -0400 Received: from [82.241.91.24] (helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DawG4-0005WF-AM for ltru@ietf.org; Wed, 25 May 2005 06:49:23 -0700 Message-Id: <6.2.1.2.2.20050525154843.03837eb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 25 May 2005 15:49:06 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [Ltru] On the records (was Editorial error in BNF) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Doug, Thank you for going on the record for these points. This permits me to go on the records with the following comments. It will save time further on for the Last Call. On 07:16 25/05/2005, Doug Ewell said: >For what it is worth, I will go on record as saying the following: > >I do not believe the mechanism described in draft-ietf-ltru-registry-* >is intended only for XML, or suitable only for XML. I believe it is >suitable for many different tagging purposes, only one of which is XML. This comment by itself shows that I am right. The comment certainly fits a specific RFC. To fit BCP 47, you should be _certain_ that it is suitable for _every_ language tagging purpose on the Internet. In saying "_many_" you are honest and show that you are not certain about the total scalability of your proposition. This is normal, it is too specific. We fully agree. I only regret that the refusal of this group of investigating that "many". It could have helped developer and kept some RFC consistent and secure (the one wich refers to RFC 3066). We discussed, inconclusively since no text resulted, some cons and pros about text, HTML, CLDR, XML, LDAP, Java, MIME. Do I forget some? >I do not believe the mechanism is supported only by "W3C people." If this is to comment a remark of mine, I said that because it is supported by W3C people, it will be used for XML. And that for that reason it MUST be clear to XML developers and users. Any other reading would be biaised. Since we are on the records, I also made clear in other mails that there is no "end-user" in the IETF thinking who would be addressed in a different way. IETF deliverables are for everyone. All users from every language are to enjoy the same lingual, technical, cultural opportunity to share in the technology usage, development, specifications and contribution. This is their absolute security. Whatever their mother tongue they must be able to use it the same way as you do yours, in contributing, specifying, developing and using the Internet technology. The technical needs of every national, local, global, cultural, private Internet communities must be equally considered and loyally addressed. Technology and current budgets cannot warranty this will happen, but technology MUST be designed for it to be possible, at least in using double indexing usual solutions. English, French, etc. are each only one of the 7520 languages of ISO 639-3 and of the 20.000 ones of ISO 639-6. This is not the case of what is specified here, and this is the main reason why the proposed Draft is inadequate, not fitting the IETF, UN and UNESCO core values. This can obviously be accepted for a temporary fix of documents also not matching yet these values. It cannot for what is by essence a funding building block of the MGN (Multilingual Global NGN). It cannot when it is specifically build over a denying of these values (even bilingualism was formally opposed here: why it would have been a hook for multilingualism, and a first step towards multilingual QA). This is a general deny of innovation because all the collateral general technical advances we can all expect from a correct multilingual support R&D are delayed or blocked. Because, when IAB starves for Government R&D funding (RFC 3869) all the public R&D budgets Internet could get from the unanimous multilingual priority of 192 Governments (ITU and WSIS resolutions) will go somewhere else. For you to understand what it means in immediate results: should the proposed text be written both in English and in French, and may be in Russian, Spanish, Arabic and Chinese, I bet the text would be clearer, each paragraph more well thought and its inner logic analysed, its implementation far easier and its technical coverage and registry management feasibility far more practical. I accept it would take more time, effort and persons: this is the price of better quality. This is the reason why, even if what is named in some governmental spheres the "lingual Yalta" is an understandable try and has brought some real first good things, it is not a good move for the Internet and for the world. Sorry. Please read RFC 3869: IAB explains the reasons why very well. You know, some others than this WG also happen to be right from time to time. This is all the more understandable that its proposed solution is _much_ more complex than a digital generalised one. >I do not believe the concept of "script" is undefined, or even poorly >defined, either in the draft or anywhere else. The best way to address that contentious point is to define the term "script" in the proposed RFC initial recital of used terms. >And I do not believe anyone secretly wants to "kill the project." Those >who want it to fail have been very public about it. This is something I am afraid you are misinformed about. There are many who oppose the principle of the project as a BCP 47, and this is the reason why they do not even bother to discuss it. I have only accepted, at the request of some of them, to spend time in being be vocal about its architectural flaws (the reasons why it failed its Last Call twice) to try to help adapting it - but I see it is useless. It also was because I wanted to learn from this WG during your much delayed debate on the IESG charter thorny points. But now most of the members are gone... I patiently and loyally made available another language, another experience and another culture to this WG and I did not spare my warning. It was a collective choice of (the most vocale part of ?) this WG to waste time in fighting/banning it instead of saving time in using it. This is was its consenual (?) choice. May be they are right and know better than so many else. This is now in the records. Thank you to have permitted it. I just stay around to show there is no consensus by exhaustion. All the best. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed May 25 23:11:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8lz-0005Xd-Jh; Wed, 25 May 2005 23:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8lw-0005Wv-UR for ltru@megatron.ietf.org; Wed, 25 May 2005 23:11:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29224 for ; Wed, 25 May 2005 23:10:57 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db94Q-0003zt-Md for ltru@ietf.org; Wed, 25 May 2005 23:30:07 -0400 Received: from h-68-166-38-247.snvacaid.dynamic.covad.net ([68.166.38.247] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Db8lt-0004kU-00 for ltru@ietf.org; Wed, 25 May 2005 23:10:57 -0400 Message-ID: <000001c561a0$e8b70fa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200505250751.j4P7pQfe019126@smtp-los02.proxy.aol.com> Date: Wed, 25 May 2005 17:15:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] [psg.com #1007] future-proofing wrt anticiapted ISO 639-6 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've created a ticket to record our resolution of this issue. If you think it needs further discussion, *please* use the appropriate subject line, rather than the not-too-accurate "Editorial error in BNF". The ticket summary says: ------------------------------------------------------------------------- Although ISO 639-6 will not be ready in time for this work to reference it formally, there were statements that it would be desirable to structure the ABNF so that the impact on implementations would be minimized, if ISO 639-6 develops as is currently anticipated. This question arose in several threads, and a summary of concerns is in http://www1.ietf.org/mail-archive/web/ltru/current/msg01869.html The rough consensus was to allow for them in syntax, recognizing that there is a risk that 639-6 might take a different form. ------------------------------------------------------------------------- Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 26 01:06:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbAZQ-0007J0-QU; Thu, 26 May 2005 01:06:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbAZP-0007Ht-DP for ltru@megatron.ietf.org; Thu, 26 May 2005 01:06:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05974 for ; Thu, 26 May 2005 01:06:10 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbArv-0006ZN-15 for ltru@ietf.org; Thu, 26 May 2005 01:25:20 -0400 Received: from h-68-166-38-247.snvacaid.dynamic.covad.net ([68.166.38.247] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbAZE-0000TA-00 for ltru@ietf.org; Thu, 26 May 2005 01:06:00 -0400 Message-ID: <005d01c561b0$fd0aa9c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] [psg.com #969] character set considerations materialis contradictory Date: Wed, 25 May 2005 22:08:42 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Thursday, May 12, 2005 8:35 AM > Subject: RE: [Ltru] [psg.com #969]character set considerations materialiscontradictory ... > Since a reasonable application will not expose language tags to end > users, and especially will not require them to type them in, and since > IT professionals building applications who may need to type these in > will almost certain have other reasons why they need to be able to type > a-z, I think this is not a concern that needs to be addressed in this > draft (no more than it being a concern e.g. for HTTP and countless other > specifications). > > Therefore, I suggest that this item be closed. ... Since there haven't been any proposals for specific changes to section 7 of http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-02.txt, I've closed this item with a status of "rejected". _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 26 01:15:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbAih-0000An-NG; Thu, 26 May 2005 01:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbAig-0000Ag-OY for ltru@megatron.ietf.org; Thu, 26 May 2005 01:15:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06415 for ; Thu, 26 May 2005 01:15:43 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbB1B-0006kw-IV for ltru@ietf.org; Thu, 26 May 2005 01:34:53 -0400 Received: from h-68-166-38-247.snvacaid.dynamic.covad.net ([68.166.38.247] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbAic-0002BT-00 for ltru@ietf.org; Thu, 26 May 2005 01:15:42 -0400 Message-ID: <007801c561b2$5904ffe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B7F3EB8@irvmbxw01.quest.com><094401c560a7$0e329c90$54713009@sanjose.ibm.com> <4293B5F4.3FA4@xyzzy.claranet.de> Subject: Re: [Ltru] [psg.com#967] address homograph issues in security considerations Date: Wed, 25 May 2005 22:18:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Tuesday, May 24, 2005 4:17 PM > Subject: [Ltru] Re: [psg.com#967]addresshomographissuesinsecurityconsiderations > > Mark Davis wrote: > > > It also doesn't allow for alternatives like 1996a 1996b, > > which I can perhaps see a need for. > > Me too, the scouse21 example for scouse in the 21st century. > > But I really don't see any need to mention that sc0use2l is > a profoundly bad idea, the tag reviewer isn't some script, > (s)he can judge this. > > Jefsey's concern, the script abused to cause confusion with > misleadingly tagged content, was more realistic. Bye, Frank ... Ok, so it looks like the proposal to address the concern by limiting the repertoire doesn't have sufficient traction. That takes us back to the proposal to add > > The language tag associated with a particular bit of content is of no > > consequence whatsoever in determining whether that content might > > contain possible homographs. The fact that a text is tagged as being > > in one language provides no assurance whatsoever that it doesn't > > contain characters from scripts other than the one(s) associated with > > that language. My reading is that we have a rough consensus to add words to this effect to the security considerations section, and I'll mark this issue "resolved." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 26 09:17:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbIFH-000244-Sw; Thu, 26 May 2005 09:17:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbIFG-00023z-J2 for ltru@megatron.ietf.org; Thu, 26 May 2005 09:17:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27502 for ; Thu, 26 May 2005 09:17:52 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbIXm-0000nI-Te for ltru@ietf.org; Thu, 26 May 2005 09:37:07 -0400 Received: from [82.241.91.24] (helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DbIF9-0002kM-93; Thu, 26 May 2005 06:17:47 -0700 Message-Id: <6.2.1.2.2.20050526125216.03a8fe20@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 26 May 2005 14:55:51 +0200 To: "Randy Presuhn" From: "JFC (Jefsey) Morfin" In-Reply-To: <005d01c561b0$fd0aa9c0$7f1afea9@oemcomputer> References: <005d01c561b0$fd0aa9c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ltru@ietf.org Subject: [Ltru] last response (was: character set considerations materialis contradictory) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 07:08 26/05/2005, Randy Presuhn wrote: >Hi - > > From: "Peter Constable" > > To: "LTRU Working Group" > > Sent: Thursday, May 12, 2005 8:35 AM > > Subject: RE: [Ltru] [psg.com #969]character set considerations > materialiscontradictory >... > > Since a reasonable application will not expose language tags to end > > users, and especially will not require them to type them in, and since > > IT professionals building applications who may need to type these in > > will almost certain have other reasons why they need to be able to type > > a-z, I think this is not a concern that needs to be addressed in this > > draft (no more than it being a concern e.g. for HTTP and countless other > > specifications). > > > > Therefore, I suggest that this item be closed. >... > >Since there haven't been any proposals for specific changes to section >7 of http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-02.txt, >I've closed this item with a status of "rejected". Dear Mr. Presuhn, I think I have been clear enough in repeating that: - characterisation of application's "reasonability" as not exposing non-ASCII characters, - the concept of outcast "end users" who would have only a limited access to IETF deliverables, - imprecise considerations such "will _almost_certain_" ignoring one shot all the non-ASCII development environments, are hardly acceptable in order to support a proposition seriously wanting to be a scalable IETF standard for the whole internet I note that for three hundred years communications have known to build language/script independent protocols accessible to everyone and to the reading of every lawmaker, Judge and Jury in every courts of the world. I have no doubt the WG you chair can come with a similar approach, as a still pending serious reading of its Charter would have shown it has been entrusted to by the IESG. Tired to blow in the violin of this mailing list, I went yesterday on records about the collective attitude of the affinity group leading this WG to a consensus by exhaustion, making it an RFC 3774 show case. So, I will not come back on the points I made. My censors will be able to go to these two mails. All the more than everyone will suspect your repetition of Peter Constable's quote and your wording were a bait on purpose, as a way to tackle my yesterday mail. Actually I take advantage of it to copy in Bcc all those who did not believe it possible. I expect that you will now ban me again for disrespect of the Chair, defending technical principles supporting the concepts of national sovereignty, facilitating international cooperation, cultural empowerment and absolute respect of users' person, rights and equal opportunity which are explicit or implicit core values of every SDO and of every postal and communication architecture for centuries. If you feel these values and objectives, which are my reason in life for decades, are no part of the IETF vision I can only feel sorry for you. I then suggest you introduce a Draft to also ban them as a disgrace for the centralised Internet you seem to want to build. I also feel sorry for the good work of this WG IRT the XML W3C says to need. It is hurt by their authors' pretension to make it a new BCP 47 and your politicking. We are here to discuss global scalable cute technical solutions, for their intelligence and/or for their support of the real world. Not to share into now plain to many cross-SDOs commercial maneuvers. I proposed many times we try to find a consensual proposition addressing that commercial interest, avoiding a market dominance and matching the Multilingual Internet requirements. This is because I doubt market organised joint monopolies can succeed nowadays, but I realise the world is not ready to practically replace them. In refusing/fighting this proposition and in asking too much, you will only push many to awake and to strive to develop responses preventing a lingual tools market control by any one, even by leading stakeholders. For that last reason, and for that reason only, we can all thank you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 26 11:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKlI-0004Qk-KS; Thu, 26 May 2005 11:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKlH-0004Qe-AN for ltru@megatron.ietf.org; Thu, 26 May 2005 11:59:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08253 for ; Thu, 26 May 2005 11:59:04 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbL3t-0004It-Ov for ltru@ietf.org; Thu, 26 May 2005 12:18:22 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 May 2005 08:58:56 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 May 2005 08:58:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] last response (was: character set considerations materialis contradictory) Date: Thu, 26 May 2005 08:58:55 -0700 Message-ID: Thread-Topic: [Ltru] last response (was: character set considerations materialis contradictory) Thread-Index: AcVh9cSzcHjrZhjYQMeGmWQ+pyVW0gAERmTQ From: "Peter Constable" To: X-OriginalArrivalTime: 26 May 2005 15:58:56.0698 (UTC) FILETIME=[D293A1A0:01C5620B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of JFC > (Jefsey) Morfin Mr. Morfin seems to have a penchant for misrepresentation when quoting others. > > > Since a reasonable application will not expose language tags to end > > > users, and especially will not require them to type them in, and since > > > IT professionals building applications who may need to type these in > > > will almost certain have other reasons why they need to be able to type > > > a-z, I think this is not a concern that needs to be addressed in this > > > draft (no more than it being a concern e.g. for HTTP and countless other > > > specifications). > - characterisation of application's "reasonability" as not exposing > non-ASCII characters, It has *never* been suggested that a reasonable application will not expose non-ASCII characters; only that a reasonable application will not normally expose protocol elements not intended for UI usage. > - the concept of outcast "end users" who would have only a limited access > to IETF deliverables, It has *never* been suggested that any group of end users are outcasts; only that the immediate users of IETF deliverables are developers and IT professionals who have different expectations and requirements than do end users. > - imprecise considerations such "will _almost_certain_" ignoring one shot > all the non-ASCII development environments, It has *never* been suggested that non-ASCII development environments can be ignored; only that it is a non-requirement to create a language-tag specification that permits development in an ASCII-free environment. =20 > I note that for three hundred years communications have known to build > language/script independent protocols accessible to everyone and to the > reading of every lawmaker, Judge and Jury in every courts of the world. And I will note that the standards for communication upheld by any lawmaker, judge, jury or court from the past three *thousand* years would have rejected the kind of misrepresentation you practice. I find this utterly reprehensible. > Tired to blow in the violin of this mailing list, I went yesterday on > records about the collective attitude of the affinity group leading this WG > to a consensus by exhaustion, making it an RFC 3774 show case. So, I will > not come back on the points I made. My censors will be able to go to these > two mails. All the more than everyone will suspect your repetition of Peter > Constable's quote and your wording were a bait on purpose, as a way to > tackle my yesterday mail. Actually I take advantage of it to copy in Bcc > all those who did not believe it possible. I can only hope that those who were blind copied, to whom I have no opportunity of directly defending my statements, will simply read and compare what I wrote with Mr. Morfin's interpretation, which very plainly are incongruous. > I expect that you will now ban me again for disrespect of the Chair, > defending technical principles supporting the concepts of national > sovereignty, facilitating international cooperation, cultural empowerment > and absolute respect of users' person, rights and equal opportunity which > are explicit or implicit core values of every SDO and of every postal and > communication architecture for centuries. >=20 > If you feel these values and objectives, which are my reason in life for > decades, are no part of the IETF vision I can only feel sorry for you. You are most pitiable. Your values and objectives are thoroughly worthy, but your judgment of where they need to be applied is misguided. The elements of postal addresses are linguistic elements. That does not make every element of every communications infrastructure a linguistic element. Language tags are *not* linguistic elements; they are simply abstract entities composed of characters. They *denote* linguistic elements, but are not themselves linguistic elements. In terms of multilingual limits to the range of elements denoted by language tags, we have devised a specification that has no significant limits but is extensible to deal with whatever linguistic distinctions we can conceivably anticipate ever being needed. But in terms of the multilingual limits of the tags themselves, this is a non-issue, since the tags themselves are not linguistic elements. What I find most personally offensive is that you seem to think I don't care about multilingualism every bit as much as you do, and that you interpret anyone who does not share your opinion of what is required to build an infrastructure for multilingual users is therefore opposed to multilingualism. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 26 12:39:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLOH-00041d-OO; Thu, 26 May 2005 12:39:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLOG-00041K-5h for ltru@megatron.ietf.org; Thu, 26 May 2005 12:39:24 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11317 for ; Thu, 26 May 2005 12:39:19 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DbLKR-0003B0-UX for ltru@lists.ietf.org; Thu, 26 May 2005 18:35:28 +0200 Received: from c-134-89-89.hh.dial.de.ignite.net ([62.134.89.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 18:35:27 +0200 Received: from nobody by c-134-89-89.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 18:35:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 26 May 2005 18:35:44 +0200 Organization: Lines: 10 Message-ID: <4295FAE0.1B4F@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-89.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: last response X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > It has *never* been suggested that non-ASCII development > environments can be ignored; only that it is a > non-requirement to create a language-tag specification > that permits development in an ASCII-free environment. There's also no problem with "hidden" c2d('r') + 1 = c2d('s') assumptions, I'm still used to see such pitfalls. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 26 14:26:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbN3W-0005wD-0W; Thu, 26 May 2005 14:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbN3V-0005vu-BB for ltru@megatron.ietf.org; Thu, 26 May 2005 14:26:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19113 for ; Thu, 26 May 2005 14:26:03 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbNM9-000875-2u for ltru@ietf.org; Thu, 26 May 2005 14:45:21 -0400 Received: from h-68-165-6-129.snvacaid.dynamic.covad.net ([68.165.6.129] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbN3T-00031W-00 for ltru@ietf.org; Thu, 26 May 2005 14:26:03 -0400 Message-ID: <004101c56220$c1988180$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <005d01c561b0$fd0aa9c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050526125216.03a8fe20@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #969] character set considerations Date: Thu, 26 May 2005 11:28:46 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Unless someone provides a proposal with specific text, issue [psg.com #969] will remain closed. Randy, ltru co-chair > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" > Cc: > Sent: Thursday, May 26, 2005 5:55 AM > Subject: last response (was: character set considerations materialis contradictory) > > At 07:08 26/05/2005, Randy Presuhn wrote: > >Hi - > > > From: "Peter Constable" > > > To: "LTRU Working Group" > > > Sent: Thursday, May 12, 2005 8:35 AM > > > Subject: RE: [Ltru] [psg.com #969]character set considerations > > materialiscontradictory > >... > > > Since a reasonable application will not expose language tags to end > > > users, and especially will not require them to type them in, and since > > > IT professionals building applications who may need to type these in > > > will almost certain have other reasons why they need to be able to type > > > a-z, I think this is not a concern that needs to be addressed in this > > > draft (no more than it being a concern e.g. for HTTP and countless other > > > specifications). > > > > > > Therefore, I suggest that this item be closed. > >... > > > >Since there haven't been any proposals for specific changes to section > >7 of http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-02.txt, > >I've closed this item with a status of "rejected". > > Dear Mr. Presuhn, > I think I have been clear enough in repeating that: > > - characterisation of application's "reasonability" as not exposing > non-ASCII characters, > - the concept of outcast "end users" who would have only a limited access > to IETF deliverables, > - imprecise considerations such "will _almost_certain_" ignoring one shot > all the non-ASCII development environments, > > are hardly acceptable in order to support a proposition seriously wanting > to be a scalable IETF standard for the whole internet > > I note that for three hundred years communications have known to build > language/script independent protocols accessible to everyone and to the > reading of every lawmaker, Judge and Jury in every courts of the world. I > have no doubt the WG you chair can come with a similar approach, as a still > pending serious reading of its Charter would have shown it has been > entrusted to by the IESG. > > Tired to blow in the violin of this mailing list, I went yesterday on > records about the collective attitude of the affinity group leading this WG > to a consensus by exhaustion, making it an RFC 3774 show case. So, I will > not come back on the points I made. My censors will be able to go to these > two mails. All the more than everyone will suspect your repetition of Peter > Constable's quote and your wording were a bait on purpose, as a way to > tackle my yesterday mail. Actually I take advantage of it to copy in Bcc > all those who did not believe it possible. > > I expect that you will now ban me again for disrespect of the Chair, > defending technical principles supporting the concepts of national > sovereignty, facilitating international cooperation, cultural empowerment > and absolute respect of users' person, rights and equal opportunity which > are explicit or implicit core values of every SDO and of every postal and > communication architecture for centuries. > > If you feel these values and objectives, which are my reason in life for > decades, are no part of the IETF vision I can only feel sorry for you. I > then suggest you introduce a Draft to also ban them as a disgrace for the > centralised Internet you seem to want to build. I also feel sorry for the > good work of this WG IRT the XML W3C says to need. It is hurt by their > authors' pretension to make it a new BCP 47 and your politicking. We are > here to discuss global scalable cute technical solutions, for their > intelligence and/or for their support of the real world. Not to share into > now plain to many cross-SDOs commercial maneuvers. > > I proposed many times we try to find a consensual proposition addressing > that commercial interest, avoiding a market dominance and matching the > Multilingual Internet requirements. This is because I doubt market > organised joint monopolies can succeed nowadays, but I realise the world is > not ready to practically replace them. In refusing/fighting this > proposition and in asking too much, you will only push many to awake and to > strive to develop responses preventing a lingual tools market control by > any one, even by leading stakeholders. > > For that last reason, and for that reason only, we can all thank you. > jfc > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu May 26 15:12:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbNlz-0004Pk-7B; Thu, 26 May 2005 15:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbNlw-0004Nl-7w for ltru@megatron.ietf.org; Thu, 26 May 2005 15:12:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22734 for ; Thu, 26 May 2005 15:11:57 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbO4Z-0000am-LZ for ltru@ietf.org; Thu, 26 May 2005 15:31:16 -0400 Received: from h-68-165-6-129.snvacaid.dynamic.covad.net ([68.165.6.129] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbNlk-0001Df-00; Thu, 26 May 2005 15:11:49 -0400 Message-ID: <008001c56227$2690d640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "JFC \(Jefsey\) Morfin" References: <005d01c561b0$fd0aa9c0$7f1afea9@oemcomputer> <6.2.1.2.2.20050526125216.03a8fe20@mail.jefsey.com> Date: Thu, 26 May 2005 12:14:33 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ltru@ietf.org Subject: [Ltru] Re: last response X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Jefsey - I don't know why you are trying so hard to get us to suspend your posting privileges under the terms RFC 3934. All concerned would be better served if you instead focused your considerable energy on proposing specific text for the drafts. You might also be a more effective advocate if you kept your postings short and to the point. If you stop insulting WG members and misrepresenting their positions, they might be more inclined to listen to what you say. However, if your disruptive postings cause the WG to waste excessive time and energy, your posting privileges may again be suspended. Randy, ltru co-chair ----- Original Message ----- > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" > Cc: > Sent: Thursday, May 26, 2005 5:55 AM > Subject: last response (was: character set considerations materialis contradictory) > > At 07:08 26/05/2005, Randy Presuhn wrote: > >Hi - > > > From: "Peter Constable" > > > To: "LTRU Working Group" > > > Sent: Thursday, May 12, 2005 8:35 AM > > > Subject: RE: [Ltru] [psg.com #969]character set considerations > > materialiscontradictory > >... > > > Since a reasonable application will not expose language tags to end > > > users, and especially will not require them to type them in, and since > > > IT professionals building applications who may need to type these in > > > will almost certain have other reasons why they need to be able to type > > > a-z, I think this is not a concern that needs to be addressed in this > > > draft (no more than it being a concern e.g. for HTTP and countless other > > > specifications). > > > > > > Therefore, I suggest that this item be closed. > >... > > > >Since there haven't been any proposals for specific changes to section > >7 of http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-02.txt, > >I've closed this item with a status of "rejected". > > Dear Mr. Presuhn, > I think I have been clear enough in repeating that: > > - characterisation of application's "reasonability" as not exposing > non-ASCII characters, > - the concept of outcast "end users" who would have only a limited access > to IETF deliverables, > - imprecise considerations such "will _almost_certain_" ignoring one shot > all the non-ASCII development environments, > > are hardly acceptable in order to support a proposition seriously wanting > to be a scalable IETF standard for the whole internet > > I note that for three hundred years communications have known to build > language/script independent protocols accessible to everyone and to the > reading of every lawmaker, Judge and Jury in every courts of the world. I > have no doubt the WG you chair can come with a similar approach, as a still > pending serious reading of its Charter would have shown it has been > entrusted to by the IESG. > > Tired to blow in the violin of this mailing list, I went yesterday on > records about the collective attitude of the affinity group leading this WG > to a consensus by exhaustion, making it an RFC 3774 show case. So, I will > not come back on the points I made. My censors will be able to go to these > two mails. All the more than everyone will suspect your repetition of Peter > Constable's quote and your wording were a bait on purpose, as a way to > tackle my yesterday mail. Actually I take advantage of it to copy in Bcc > all those who did not believe it possible. > > I expect that you will now ban me again for disrespect of the Chair, > defending technical principles supporting the concepts of national > sovereignty, facilitating international cooperation, cultural empowerment > and absolute respect of users' person, rights and equal opportunity which > are explicit or implicit core values of every SDO and of every postal and > communication architecture for centuries. > > If you feel these values and objectives, which are my reason in life for > decades, are no part of the IETF vision I can only feel sorry for you. I > then suggest you introduce a Draft to also ban them as a disgrace for the > centralised Internet you seem to want to build. I also feel sorry for the > good work of this WG IRT the XML W3C says to need. It is hurt by their > authors' pretension to make it a new BCP 47 and your politicking. We are > here to discuss global scalable cute technical solutions, for their > intelligence and/or for their support of the real world. Not to share into > now plain to many cross-SDOs commercial maneuvers. > > I proposed many times we try to find a consensual proposition addressing > that commercial interest, avoiding a market dominance and matching the > Multilingual Internet requirements. This is because I doubt market > organised joint monopolies can succeed nowadays, but I realise the world is > not ready to practically replace them. In refusing/fighting this > proposition and in asking too much, you will only push many to awake and to > strive to develop responses preventing a lingual tools market control by > any one, even by leading stakeholders. > > For that last reason, and for that reason only, we can all thank you. > jfc > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 27 01:50:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbXjr-0005eX-6U; Fri, 27 May 2005 01:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbXjl-0005ah-CC for ltru@megatron.ietf.org; Fri, 27 May 2005 01:50:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18996 for ; Fri, 27 May 2005 01:50:24 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbY2U-0001Nd-0v for ltru@ietf.org; Fri, 27 May 2005 02:09:47 -0400 Received: from h-68-164-242-158.snvacaid.dynamic.covad.net ([68.164.242.158] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbXjd-0004mq-00 for ltru@ietf.org; Fri, 27 May 2005 01:50:17 -0400 Message-ID: <004101c56280$591966a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4264C99F.3A19770B@egt.ie> Date: Thu, 26 May 2005 22:53:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] [psg.com #1009] generic variant subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Recording yet another issue that I think has been resolved. There's no need to follow up on this one unless you think it merits additional discussion. The initial proposal was floated on the ietf-languages@iana.org list, with some discussion spilling over onto the ltru WG mailing list. I'm just recording it in the issue tracker for completeness. The proposal (from John Cowan) read: This is a bit premature for both lists, but I wanted to float the idea to see if there are any objections to it. When the RFC 3066bis registry is up and running, I intend to propose some highly generic variant subtags which may be used with many languages. Some examples that come to mind are -northern, -southern, -eastern, - western, and -central for geographical dialects; -ancient and -middle for earlier versions of languages (-old being too short); and -highreg, -midreg, and -lowreg for sociolinguistic registers. Ietf-languages folks: do you have any objections to this idea? Ltru folks: does one of these deserve to appear in the registry draft as an example of a generic variant subtag? ------------------------------------------------------------ The proposal found little support and much opposition, so it is marked "rejected" Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 27 02:03:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbXwC-0007kN-Lu; Fri, 27 May 2005 02:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbXwA-0007kF-Og for ltru@megatron.ietf.org; Fri, 27 May 2005 02:03:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22955 for ; Fri, 27 May 2005 02:03:13 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbYEt-0001dP-8A for ltru@ietf.org; Fri, 27 May 2005 02:22:36 -0400 Received: from h-68-164-242-158.snvacaid.dynamic.covad.net ([68.164.242.158] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbXw7-0006pI-00 for ltru@ietf.org; Fri, 27 May 2005 02:03:11 -0400 Message-ID: <006001c56282$2614e020$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050523213022.YXF28811.mta8.adelphia.net@megatron.ietf.org><004801c5601e$2d0ded60$030aa8c0@DEWELL><01d701c5602d$3aa1bc40$7f1afea9@oemcomputer><4292E404.65BB@xyzzy.claranet.de> <6.0.0.20.2.20050525083711.071cb320@itmail.it.aoyama.ac.jp> Date: Thu, 26 May 2005 23:05:56 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Ltru] [psg.com #1010] conformance terminology X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - If you think this item needs further discussion, please use an appropriate subject line. ------------------------------------------------------------------------- Message http://www1.ietf.org/mail-archive/web/ltru/current/msg01840.html proposes (add title to last paragraph of section 1 and add one new paragraph) 1.1 Conformance Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [10]. Consistent with previous versions of this document, RFC 1766 [21] and RFC 3066 [23], most conformance requirements in this document are written in passive voice using uppercase conformance keywords. Content authors, authoring tools, content distributors, distribution tools, and content repositories (e.g., content servers and content archives) that create or copy language tags MUST comply with all of these conformance requirements. Content users and user tools (e.g., web browsers) that create or copy language tags in content queries SHOULD also comply with all of these conformance requirements. ------------------------------------------------------------------------ Although the exact text did not find support, this comment did trigger a review of the use of the 2119 keywords in the draft, in line with the spirit of the comment. Consequently, this item is marked "resolved." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 27 13:42:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbirG-0006Bn-5s; Fri, 27 May 2005 13:42:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbirE-0006BM-OD for ltru@megatron.ietf.org; Fri, 27 May 2005 13:42:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02862 for ; Fri, 27 May 2005 13:42:51 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbjA2-0001Kt-8C for ltru@ietf.org; Fri, 27 May 2005 14:02:20 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 10:42:37 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 10:42:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 May 2005 10:42:35 -0700 Message-ID: Thread-Topic: use of region subtags Thread-Index: AcVi43fOvPiIFnKLT2aLFsPxKJ179A== From: "Peter Constable" To: X-OriginalArrivalTime: 27 May 2005 17:42:37.0591 (UTC) FILETIME=[78EE5270:01C562E3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Subject: [Ltru] use of region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0074441494==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0074441494== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C562E3.7990FB92" This is a multi-part message in MIME format. ------_=_NextPart_001_01C562E3.7990FB92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've agreed to include a Suppress-Script field to avoid things like "en-Latn" or "en-Latn-US". Part of the concern over the script subtag had to do with interaction with existing usage of tags like "en-US". =20 A case like "iu-CA" or "iu-Latn-CA" for which the region is considered undesirable because it's considered redundant (for the 99% case) is similar in that it's considered best practice not to use a subtag that can be assumed by default, though it doesn't have the same compat-with-existing-usage issue. Would we ever want to consider a Suppress-Region field for lang subtags?=20 =20 =20 =20 Thanks. =20 Peter Constable GIFT | GPTS | MICROSOFT =20 ------_=_NextPart_001_01C562E3.7990FB92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve agreed to include a = Suppress-Script field to avoid things like “en-Latn” or = “en-Latn-US”. Part of the concern over the script subtag had to do with interaction with = existing usage of tags like “en-US”.

 

A case like “iu-CA” or = “iu-Latn-CA” for which the region is considered undesirable because it’s = considered redundant (for the 99% case) is similar in that it’s considered best = practice not to use a subtag that can be assumed by default, though it doesn’t = have the same compat-with-existing-usage issue. Would we ever want to = consider a Suppress-Region field for lang subtags?

 

 

 

Thanks.

 

Peter Constable

GIFT | GPTS | MICROSOFT

 

------_=_NextPart_001_01C562E3.7990FB92-- --===============0074441494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0074441494==-- From ltru-bounces@lists.ietf.org Fri May 27 14:04:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjBn-0000HG-VT; Fri, 27 May 2005 14:04:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjBl-0000HB-VK for ltru@megatron.ietf.org; Fri, 27 May 2005 14:04:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07547 for ; Fri, 27 May 2005 14:04:02 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbjUY-0002uN-QQ for ltru@ietf.org; Fri, 27 May 2005 14:23:32 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 11:03:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] use of region subtags Date: Fri, 27 May 2005 11:03:51 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B8B9C87@irvmbxw01.quest.com> Thread-Topic: [Ltru] use of region subtags Thread-Index: AcVi43fOvPiIFnKLT2aLFsPxKJ179AAAtamg From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 27 May 2005 18:03:51.0165 (UTC) FILETIME=[700A4AD0:01C562E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org No. Nor a Suppress-Variant. We might consider a Suppress-Extlang, but I can't think why. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: vendredi 27 mai 2005 10:43 > To: ltru@ietf.org > Subject: [Ltru] use of region subtags >=20 > We've agreed to include a Suppress-Script field to avoid things like = "en- > Latn" or "en-Latn-US". Part of the concern over the script subtag had = to > do with interaction with existing usage of tags like "en-US". >=20 >=20 >=20 > A case like "iu-CA" or "iu-Latn-CA" for which the region is considered > undesirable because it's considered redundant (for the 99% case) is > similar in that it's considered best practice not to use a subtag that = can > be assumed by default, though it doesn't have the same compat-with- > existing-usage issue. Would we ever want to consider a Suppress-Region > field for lang subtags? >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Thanks. >=20 >=20 >=20 > Peter Constable >=20 > GIFT | GPTS | MICROSOFT >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 27 14:18:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjQA-0002nu-Lb; Fri, 27 May 2005 14:18:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjQ9-0002nn-Ao for ltru@megatron.ietf.org; Fri, 27 May 2005 14:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09168 for ; Fri, 27 May 2005 14:18:56 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbjiy-0003IJ-UY for ltru@ietf.org; Fri, 27 May 2005 14:38:26 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4RIIkk3000936; Fri, 27 May 2005 14:18:46 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 27 May 2005 14:18:46 -0400 Date: Fri, 27 May 2005 14:18:55 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] use of region subtags Message-ID: <20050527181855.GD6509@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B8B9C87@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B8B9C87@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > No [Suppress-Region]. > > Nor a Suppress-Variant. > > We might consider a Suppress-Extlang, but I can't think why. "No" to each. Suppress-Script is not part of a general method for expressing best practices in language tagging, but a hack applicable to existing ISO 639-1/2 based tags to prevent gratuitous matching errors. -- John Cowan jcowan@reutershealth.com "You need a change: try Canada" "You need a change: try China" --fortune cookies opened by a couple that I know _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 27 14:50:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjui-00038o-H6; Fri, 27 May 2005 14:50:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjuh-00038e-Pa for ltru@megatron.ietf.org; Fri, 27 May 2005 14:50:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13250 for ; Fri, 27 May 2005 14:50:28 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkDV-0004Rk-Hb for ltru@ietf.org; Fri, 27 May 2005 15:09:58 -0400 Received: from h-64-105-137-105.snvacaid.dynamic.covad.net ([64.105.137.105] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dbjuc-00031l-00 for ltru@ietf.org; Fri, 27 May 2005 14:50:26 -0400 Message-ID: <005001c562ed$5603fbc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B8B9C87@irvmbxw01.quest.com> <20050527181855.GD6509@skunk.reutershealth.com> Date: Fri, 27 May 2005 11:53:13 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] [psg.com #1011] add suppress-region X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've created a ticket for this proposal: [psg.com #1011] Randy, ltru co-chair > From: "John Cowan" > To: "Addison Phillips" > Cc: > Sent: Friday, May 27, 2005 11:18 AM > Subject: Re: [Ltru] use of region subtags > > Addison Phillips scripsit: > > > No [Suppress-Region]. > > > > Nor a Suppress-Variant. > > > > We might consider a Suppress-Extlang, but I can't think why. > > "No" to each. Suppress-Script is not part of a general method for expressing > best practices in language tagging, but a hack applicable to existing ISO 639-1/2 > based tags to prevent gratuitous matching errors. > > -- > John Cowan jcowan@reutershealth.com > "You need a change: try Canada" "You need a change: try China" > --fortune cookies opened by a couple that I know > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 27 15:09:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkDH-0002rJ-U7; Fri, 27 May 2005 15:09:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkDF-0002rE-Vi for ltru@megatron.ietf.org; Fri, 27 May 2005 15:09:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16774 for ; Fri, 27 May 2005 15:09:40 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkW5-0005Nq-U1 for ltru@ietf.org; Fri, 27 May 2005 15:29:11 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 12:09:28 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 12:09:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1011] add suppress-region Date: Fri, 27 May 2005 12:09:25 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #1011] add suppress-region Thread-Index: AcVi7SOXthVHQ/QNRqGIJfqb3JGQlQAAh9tA From: "Peter Constable" To: X-OriginalArrivalTime: 27 May 2005 19:09:27.0869 (UTC) FILETIME=[9A7FA6D0:01C562EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > I've created a ticket for this proposal: [psg.com #1011] I didn't actually intend to suggest a change in 3066bis; for that, I want nothing that doesn't move us toward stabilization and successful completion. More generally, I'm happy to go along with Addison's and John's "No" on this. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 27 15:30:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkXS-00082g-QC; Fri, 27 May 2005 15:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkXR-00082b-VX for ltru@megatron.ietf.org; Fri, 27 May 2005 15:30:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19238 for ; Fri, 27 May 2005 15:30:32 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkqI-0005wA-7u for ltru@ietf.org; Fri, 27 May 2005 15:50:03 -0400 Received: from h-64-105-137-105.snvacaid.dynamic.covad.net ([64.105.137.105] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbkXO-0007XY-00 for ltru@ietf.org; Fri, 27 May 2005 15:30:30 -0400 Message-ID: <000d01c562f2$ef541580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] [psg.com #1011] add suppress-region Date: Fri, 27 May 2005 12:33:17 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Peter Constable" > To: > Sent: Friday, May 27, 2005 12:09 PM > Subject: RE: [Ltru] [psg.com #1011] add suppress-region ... > I didn't actually intend to suggest a change in 3066bis; for that, I > want nothing that doesn't move us toward stabilization and successful > completion. > > More generally, I'm happy to go along with Addison's and John's "No" on > this. ... Ok, since there hasn't exactly been a groundswell of support for this proposal, I'll mark it rejected. If anyone decides it's a great idea, they can post to the WG mailing list and I'll re-open it. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri May 27 18:34:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbnPs-0006hI-V6; Fri, 27 May 2005 18:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbnPr-0006h5-AI for ltru@megatron.ietf.org; Fri, 27 May 2005 18:34:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11252 for ; Fri, 27 May 2005 18:34:50 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbnih-0004R3-Cq for ltru@ietf.org; Fri, 27 May 2005 18:54:24 -0400 Received: from h-68-164-241-253.snvacaid.dynamic.covad.net ([68.164.241.253] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbnPl-0004w0-00 for ltru@ietf.org; Fri, 27 May 2005 18:34:50 -0400 Message-ID: <000801c5630c$aeec3440$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <013601c556bd$44eb34c0$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #966] remove something from security considerations Date: Fri, 27 May 2005 15:37:36 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Randy Presuhn" > To: "LTRU Working Group" > Sent: Wednesday, May 11, 2005 11:38 PM > Subject: [Ltru] [psg.com #966] remove something from security considerations > > Hi - > > > Comment 38 in > > http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html > > reads: > > "38. 4. security considerations should not deal with users political > > security outside of their network usage. Otherwise tons of such > > considerations should be presented." > > > > followup in > > http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html > > (apologies for the vague subject line - if someone can give me something > more precise, I'll happily change it.) ... No one provided specific text, and there were no follow-ups in favor of this proposal, so I've marked it "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 28 00:17:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbslR-0005Mv-3Z; Sat, 28 May 2005 00:17:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbslQ-0005Mq-KO for ltru@megatron.ietf.org; Sat, 28 May 2005 00:17:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29954 for ; Sat, 28 May 2005 00:17:29 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbt4K-0002Iw-SL for ltru@ietf.org; Sat, 28 May 2005 00:37:06 -0400 Received: from h-68-164-241-106.snvacaid.dynamic.covad.net ([68.164.241.106] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DbslM-0003LT-00 for ltru@ietf.org; Sat, 28 May 2005 00:17:29 -0400 Message-ID: <000b01c5633c$8c274aa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 27 May 2005 21:20:13 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] three more closed issues: 1012, 1013, and 1015 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've recorded three more resolved issues in the tracker at https://rt.psg.com/ (password & user ietf) If you feel any of these merits further discussion, please use an appropriate subject line: [psg.com #1012] hyphen versus underscore in field labels (agreed hyphen) [psg.com #1013] localization of field labels in file format rejected [psg.com #1015] name working group as registry maintainer rejected Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 28 00:33:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbt0Z-0007qa-7q; Sat, 28 May 2005 00:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbt0Y-0007qV-2N for ltru@megatron.ietf.org; Sat, 28 May 2005 00:33:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00913 for ; Sat, 28 May 2005 00:33:06 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbtJS-0002bZ-3W for ltru@ietf.org; Sat, 28 May 2005 00:52:43 -0400 Received: from h-64-105-136-74.snvacaid.dynamic.covad.net ([64.105.136.74] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dbt0U-00067f-00 for ltru@ietf.org; Sat, 28 May 2005 00:33:06 -0400 Message-ID: <001101c5633e$bc039240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 27 May 2005 21:34:33 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Ltru] [psg.com #1014] make scope of applicability universal X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've created a ticket in the issue tracker at https://rt.psg.com/ for this: > ------------------------------------------------------------------------- > Message > http://www1.ietf.org/mail-archive/web/ltru/current/msg01358.html > says: > "1. in having an language identification framework applicable > to _every_ Internet Standard Process needs, past and future. > This should be accompanied by a letter to the IESG or a part > in the Draft to provide further guidance on the Charter revisions. > It should document why this brings consistency, stability, security > and capacity for Internet standards scalability. This general > framework should succeed to RFC 3066 as RFC 047." As a technical contributor: The current (-02) id makes no claim to universal applicability, nor does it explicitly limit its applicability. It says: This document specifies an identifier mechanism and a registration function for values to be used with that identifier mechanism. It also defines a mechanism for private use values and future extension. To me, this seems in line with our charter, which similarly implies that the specification may have wide applicability, without requiring universality, when it says: "Language tags are necessary for many applications, ranging from cataloging content to computer processing of text. The RFC 3066 standard for language tags has been widely adopted in various protocols and text formats, including HTML, XML, and CLDR, as the best means of identifying languages and language preferences." Consequently, as a technical contributor, I think we should reject this proposal, as supporting "_every_ Internet Standard Process needs, past and future" would be like trying to boil the ocean, preventing us from completing our assigned task in a timely manner. As co-chair, I note that none voiced support for this proposal, but I'd like to give one last opportunity for discussion before I mark it "rejected". In particular, does anyone see a need to be more explicit about the intended applicability of language tags? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 28 15:08:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc6fv-0000ng-LD; Sat, 28 May 2005 15:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc6ft-0000nb-MX for ltru@megatron.ietf.org; Sat, 28 May 2005 15:08:45 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26676 for ; Sat, 28 May 2005 15:08:43 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050528190813.MOSN17140.mta10.adelphia.net@DEWELL> for ; Sat, 28 May 2005 15:08:13 -0400 Message-ID: <005901c563b7$e1acf260$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> Subject: Re: [Ltru] [psg.com #966] remove something from security considerations Date: Sat, 28 May 2005 12:03:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >>> Comment 38 in >>> http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html >>> reads: >>> "38. 4. security considerations should not deal with users political >>> security outside of their network usage. Otherwise tons of such >>> considerations should be presented." >>> >>> followup in >>> http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html >> >> (apologies for the vague subject line - if someone can give me >> something more precise, I'll happily change it.) > ... > > No one provided specific text, and there were no follow-ups in favor > of this proposal, so I've marked it "rejected". I'm happy to let the rejection stand, but in case it is challenged, I can provide a follow-up against this proposal. One, the wording in question deals with "language identifiers used in content negotiation... that... may be used to infer the nationality of the sender." So, to the extent that the content being negotiated is sent via the Internet, this wording does indeed deal with security related to network usage. Two, the wording was carried over from RFC 3066, as a response to the passage in RFC 1766 that said "Security issues are not discussed in this memo" (not "believed to be irrelevant," as quoted in RFC 3066). The intent at that time was apparently that the wording about content negotiation and surveillance *was* considered appropriate for the RFC. An attempt to overturn this decision would have to provide more detail than a single line. Alternatively, if there are "tons of such considerations," then they would have to be spelled out instead of just alluded to. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 28 15:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc6r1-0002TV-Og; Sat, 28 May 2005 15:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc6r1-0002TQ-6s for ltru@megatron.ietf.org; Sat, 28 May 2005 15:20:15 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27750 for ; Sat, 28 May 2005 15:20:12 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050528191934.KLSQ4191.mta13.adelphia.net@DEWELL> for ; Sat, 28 May 2005 15:19:34 -0400 Message-ID: <005e01c563b9$5dd580e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> Date: Sat, 28 May 2005 12:13:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1011] add suppress-region X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I've created a ticket for this proposal: [psg.com #1011] I agree that more Suppress-* categories should not be created. Specifically, I agree with John Cowan that Suppress-Script was created as a response to charges that RFC 3066bis tags would be incompatible with RFC 3066 matching algorithms, not as a general guide to best tagging practices. Addison stated that extended-language subtags might also be candidates for Suppression, because (like scripts) they are positioned between the primary language and region subtags. I worry about this because an extended-language subtag would probably denote a genuinely different language, and suppressing it would greatly change the meaning of the tag. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 28 16:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc7VO-00008d-0s; Sat, 28 May 2005 16:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc7VM-00008P-0C for ltru@megatron.ietf.org; Sat, 28 May 2005 16:01:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00226 for ; Sat, 28 May 2005 16:01:53 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dc7oP-0006bc-85 for ltru@ietf.org; Sat, 28 May 2005 16:21:38 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4SK1eT9010062; Sat, 28 May 2005 16:01:40 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 28 May 2005 16:01:40 -0400 Date: Sat, 28 May 2005 16:01:39 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: [psg.com #1011] add suppress-region Message-ID: <20050528200139.GC8830@skunk.reutershealth.com> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005e01c563b9$5dd580e0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell scripsit: > Addison stated that extended-language subtags might also be candidates > for Suppression, because (like scripts) they are positioned between the > primary language and region subtags. I worry about this because an > extended-language subtag would probably denote a genuinely different > language, and suppressing it would greatly change the meaning of the > tag. It's a difficult question. Probably most of the time when someone uses "ar", they mean "ar-arb", standard Arabic. But some of the time they mean, or may mean, any Arabic whatsoever. It's precisely this dichotomy that led Peter Constable to introduce the notion of macrolanguages. If we used suppression in this case, we'd be saying that "ar" means always and only Standard Arabic henceforward, possibly undermining existing usage. Better to leave "ar" as deliberately vague and allow "ar-arb" for specificity. What we *will* need when we come to put extlang entries into the registry is a new header "Language-subtag" showing which (singular) language subtag they can be used with; thus "arb" will point to "ar". -- Work hard, John Cowan play hard, jcowan@reutershealth.com die young, http://www.reutershealth.com rot quickly. http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat May 28 16:32:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc7z9-0004nm-3Y; Sat, 28 May 2005 16:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc7z7-0004nh-U1 for ltru@megatron.ietf.org; Sat, 28 May 2005 16:32:41 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01843 for ; Sat, 28 May 2005 16:32:39 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050528203210.PPNS17140.mta10.adelphia.net@DEWELL> for ; Sat, 28 May 2005 16:32:10 -0400 Message-ID: <000401c563c4$4dcabfc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> Date: Sat, 28 May 2005 13:32:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1014] make scope of applicability universal X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > Consequently, as a technical contributor, I think we should reject this > proposal, as supporting "_every_ Internet Standard Process needs, past and > future" would be like trying to boil the ocean, preventing us from > completing our assigned task in a timely manner. I agree. Since this "universality" issue has been used to try to demonstrate that the draft should not be considered for BCP status, I would also add that RFC 2026 (BCP 9) makes no statement that a Best Current Practice must support, or claim to support, every conceivable Internet Standard Process need, let alone that it should try to predict future needs. The RFC Index Search Engine did not indicate that RFC 2026 has been obsoleted or superseded in any way related to this issue, but if someone can point to a more recent document that touches on it, please do so. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 01:06:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcG0V-00012U-Dt; Sun, 29 May 2005 01:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcG0U-00012P-Tt for ltru@megatron.ietf.org; Sun, 29 May 2005 01:06:39 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00116 for ; Sun, 29 May 2005 01:06:38 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050529050607.CGKP13270.mta11.adelphia.net@DEWELL> for ; Sun, 29 May 2005 01:06:07 -0400 Message-ID: <001301c5640c$1855f9c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050527160132.IJCL27459.mta2.adelphia.net@megatron.ietf.org> Date: Sat, 28 May 2005 22:05:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: last response X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> It has *never* been suggested that non-ASCII development >> environments can be ignored; only that it is a >> non-requirement to create a language-tag specification >> that permits development in an ASCII-free environment. > > There's also no problem with "hidden" c2d('r') + 1 = c2d('s') > assumptions, I'm still used to see such pitfalls. I think Peter's references to ASCII had to do with the repertoire of "Basic Latin" characters, not the ASCII ordering. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 07:27:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcLxK-0000QL-8T; Sun, 29 May 2005 07:27:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcLxI-0000QG-Sd for ltru@megatron.ietf.org; Sun, 29 May 2005 07:27:45 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09463 for ; Sun, 29 May 2005 07:27:43 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcLua-0003dF-1d for ltru@lists.ietf.org; Sun, 29 May 2005 13:24:56 +0200 Received: from 212.82.251.2 ([212.82.251.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 13:24:56 +0200 Received: from nobody by 212.82.251.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 13:24:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 29 May 2005 13:25:55 +0200 Organization: Lines: 22 Message-ID: <4299A6C2.4867@xyzzy.claranet.de> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> <20050528200139.GC8830@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.2 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1011] add suppress-region X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > What we *will* need when we come to put extlang entries into > the registry is a new header "Language-subtag" showing which > (singular) language subtag they can be used with; thus "arb" > will point to "ar". That's like Recommended-Prefix. I'm still lost with multiple extlang-s in a tag, how many in which order ? Draft -03pre still says *( "-" extlang ). The maximum Recommended-Prefix allows 17 extlang-s. We are sure that this will never happen, and it wouldn't work in encoded word (RfC 2047). But the draft -03pre doesn't say so, it also does not yet mention RfC 2047 together with 2231. This one * before extlang in the ABNF will fascinate developers in the "last call", it triggers nightmares of buffer overflows and memory leaks. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 07:43:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcMCf-0002JU-PI; Sun, 29 May 2005 07:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcMCe-0002JP-00 for ltru@megatron.ietf.org; Sun, 29 May 2005 07:43:36 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09981 for ; Sun, 29 May 2005 07:43:35 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcM9e-0004oI-Pi for ltru@lists.ietf.org; Sun, 29 May 2005 13:40:30 +0200 Received: from 212.82.251.2 ([212.82.251.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 13:40:30 +0200 Received: from nobody by 212.82.251.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 13:40:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 29 May 2005 13:40:46 +0200 Organization: Lines: 13 Message-ID: <4299AA3E.4F66@xyzzy.claranet.de> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005901c563b7$e1acf260$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.2 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #966] remove something from security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > Alternatively, if there are "tons of such considerations," > then they would have to be spelled out instead of just > alluded to. It's not pure science fiction, I just checked that you don't have a Suppress-Script for Tatar (tt) (= let's NOT add Cyrl), and you reported a dispute about Latn for Moldavian (mo). It's nothing we can do about in the Security Considerations or elsewhere in the draft, but it's no nonsense. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 11:10:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcPR2-00007X-FE; Sun, 29 May 2005 11:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcPR0-00007S-UX for ltru@megatron.ietf.org; Sun, 29 May 2005 11:10:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21359 for ; Sun, 29 May 2005 11:10:37 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcPkE-0007LC-B8 for ltru@ietf.org; Sun, 29 May 2005 11:30:31 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4TFANfo013589; Sun, 29 May 2005 11:10:24 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 29 May 2005 11:10:33 -0400 Date: Sun, 29 May 2005 11:10:33 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #1011] add suppress-region Message-ID: <20050529151033.GH8830@skunk.reutershealth.com> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> <20050528200139.GC8830@skunk.reutershealth.com> <4299A6C2.4867@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4299A6C2.4867@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > > What we *will* need when we come to put extlang entries into > > the registry is a new header "Language-subtag" showing which > > (singular) language subtag they can be used with; thus "arb" > > will point to "ar". > > That's like Recommended-Prefix. No, it's mandatory: you can only use 'arb' with 'ar', never with any other language subtag. But it could be called "Required-Prefix". > I'm still lost with multiple extlang-s in a tag, how many in > which order ? Draft -03pre still says *( "-" extlang ). The > maximum Recommended-Prefix allows 17 extlang-s. The only way multiple extlangs can arise is if language B, which is encompassed by macrolanguage A, is itself reanalyzed as a macrolanguage encompassing languages C, D, etc. That would make A-B-C and A-B-D valid (partial) language tags. Order would be significant for matching purposes, but could be reconstructed from the registry by following the Required-Prefix pointers. -- John Cowan jcowan@reutershealth.com http://www.ccil.org/~cowan Is it not written, "That which is written, is written"? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 13:43:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcRp9-0007Mx-1v; Sun, 29 May 2005 13:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcRp7-0007Ms-EH for ltru@megatron.ietf.org; Sun, 29 May 2005 13:43:41 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29183 for ; Sun, 29 May 2005 13:43:39 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcRm5-0002FV-Ln for ltru@lists.ietf.org; Sun, 29 May 2005 19:40:33 +0200 Received: from 212.82.251.2 ([212.82.251.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 19:40:33 +0200 Received: from nobody by 212.82.251.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 19:40:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 29 May 2005 19:41:05 +0200 Organization: Lines: 20 Message-ID: <4299FEB1.738E@xyzzy.claranet.de> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> <20050528200139.GC8830@skunk.reutershealth.com> <4299A6C2.4867@xyzzy.claranet.de> <20050529151033.GH8830@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.2 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1011] add suppress-region X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: >> That's like Recommended-Prefix. > No, it's mandatory: you can only use 'arb' with 'ar', never > with any other language subtag. But it could be called > "Required-Prefix". Maybe we should say "Prefix:", with REQUIRED for extlang, and RECOMMENDED elsewhere. These long field names are ugly, and too may different field names are a zoo. > That would make A-B-C and A-B-D valid (partial) language > tags. Order would be significant for matching purposes, but > could be reconstructed from the registry by following the > Required-Prefix pointers. Pray that nobody wants E-C or E-D. Okay, there can be more than one Recommended-Prefix, it should still work. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 14:13:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcSHg-0001mn-EI; Sun, 29 May 2005 14:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcSHf-0001me-0P for ltru@megatron.ietf.org; Sun, 29 May 2005 14:13:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00861 for ; Sun, 29 May 2005 14:13:10 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcSat-0002A7-VZ for ltru@ietf.org; Sun, 29 May 2005 14:33:05 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4TICsNO014200; Sun, 29 May 2005 14:12:55 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 29 May 2005 14:12:58 -0400 Date: Sun, 29 May 2005 14:12:58 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #1011] add suppress-region Message-ID: <20050529181258.GI8830@skunk.reutershealth.com> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> <20050528200139.GC8830@skunk.reutershealth.com> <4299A6C2.4867@xyzzy.claranet.de> <20050529151033.GH8830@skunk.reutershealth.com> <4299FEB1.738E@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4299FEB1.738E@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > Maybe we should say "Prefix:", with REQUIRED for extlang, and > RECOMMENDED elsewhere. These long field names are ugly, and > too may different field names are a zoo. I think that would be easy to make a mistake about. > > That would make A-B-C and A-B-D valid (partial) language > > tags. Order would be significant for matching purposes, but > > could be reconstructed from the registry by following the > > Required-Prefix pointers. > > Pray that nobody wants E-C or E-D. That wouldn't make any sense. It may be a matter of context whether Chadian Spoken Arabic ('shu') is a separate language or just part of the Arabic macro-language; it's uncontroversial that it's Arabic and not (say) Chinese, so "zh-shu" can be ruled out as invalid. Similarly, the Auvergnat language is encompassed by the Occitan macrolanguage, so in 3066ter-speak it would be designated "oc-auv". Suppose that further research shows that the Haut-Auvergnat and Bas-Auvergnat dialects are really more distinct than we now believe, and they deserve separate ISO 3166 language codes, say 'avh' and 'avx' respectively (insert "the good ones are all taken" lament here). Then Auvergnat might become a macrolanguage within a macrolanguage, and the two newly recognized languages would be coded "oc-auv-avh" and "oc-auv-avx". But it wouldn't ever make sense to refer to "en-avh" (Haut-Auvergnat as encompassed by the individual language English) or "sql-avx" (Bas-Auvergnat as encompassed by the macrolanguage Albanian). The required prefix for 'avh' and 'avx' would be "oc-auv", just as the required prefix for 'auv' is 'oc'. (Seventeen levels of splitting is way more than enough under any conceivable scenario, and I do think that word means what I think it means.) -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 16:23:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcUKF-0005vy-4I; Sun, 29 May 2005 16:23:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcUKD-0005vs-S6 for ltru@megatron.ietf.org; Sun, 29 May 2005 16:23:58 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21036 for ; Sun, 29 May 2005 16:23:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcTjI-00065v-AP for ltru@lists.ietf.org; Sun, 29 May 2005 21:45:48 +0200 Received: from 212.82.251.2 ([212.82.251.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 21:45:48 +0200 Received: from nobody by 212.82.251.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 21:45:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 29 May 2005 21:36:31 +0200 Organization: Lines: 31 Message-ID: <429A19BF.51F3@xyzzy.claranet.de> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> <20050528200139.GC8830@skunk.reutershealth.com> <4299A6C2.4867@xyzzy.claranet.de> <20050529151033.GH8830@skunk.reutershealth.com> <4299FEB1.738E@xyzzy.claranet.de> <20050529181258.GI8830@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.2 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] extlang again (was: [psg.com #1011] add suppress-region) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: [Prefix for both RECOMMENDED and REQUIRED cases] > I think that would be easy to make a mistake about. Required-Prefix Macro-Language We could just say what it means. 3066ter territory, but Randy wanted us to prepare everything as far as possible. > It may be a matter of context whether Chadian Spoken Arabic > ('shu') is a separate language or just part of the Arabic > macro-language; it's uncontroversial that it's Arabic and > not (say) Chinese, so "zh-shu" can be ruled out as invalid. Okay, that's a detail not yet stated in the draft, I didn't know that zh-shu for a hypothetical "southern Hu" isn't allowed as soon as an ar-shu exists. If the "Macro-Language" is always unique and implicit, why bother with it ? Is it about a hypothetical shu vs. ar-shu ? > (insert "the good ones are all taken" lament here) "26**3 ought to be enough for everybody". Hm, actually it's not that much, minus 20*26 for qaa..qtz, plus 26**2 alpha-2, 17732 if I got this right. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 16:41:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcUan-0007KD-SS; Sun, 29 May 2005 16:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcUal-0007JK-Fu for ltru@megatron.ietf.org; Sun, 29 May 2005 16:41:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23158 for ; Sun, 29 May 2005 16:41:01 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcUu1-0006yF-Qa for ltru@ietf.org; Sun, 29 May 2005 17:00:59 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4TKeqRc014907; Sun, 29 May 2005 16:40:52 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 29 May 2005 16:40:51 -0400 Date: Sun, 29 May 2005 16:40:54 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] extlang again (was: [psg.com #1011] add suppress-region) Message-ID: <20050529204054.GJ8830@skunk.reutershealth.com> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> <20050528200139.GC8830@skunk.reutershealth.com> <4299A6C2.4867@xyzzy.claranet.de> <20050529151033.GH8830@skunk.reutershealth.com> <4299FEB1.738E@xyzzy.claranet.de> <20050529181258.GI8830@skunk.reutershealth.com> <429A19BF.51F3@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429A19BF.51F3@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > Okay, that's a detail not yet stated in the draft, I didn't > know that zh-shu for a hypothetical "southern Hu" isn't > allowed as soon as an ar-shu exists. Correct: 'shu' always means Chadian Spoken Arabic in ISO 639-3. > If the "Macro-Language" is always unique and implicit, why > bother with it ? Is it about a hypothetical shu vs. ar-shu ? No. It's yet another compromise with standard matching algorithms. If a resource in Chadian Arabic were to be tagged simply "shu", a client looking for Arabic of all sorts would have to have specialized knowledge to recognize "shu" (and 29 other language subtags) as equivalent. By requiring "ar-shu" instead, we make it easy for such a client, whereas a client wanting Standard Arabic specifically can request "ar-arb" specifically. Banning "shu" by itself eliminates double coding for the same thing. > > (insert "the good ones are all taken" lament here) > > "26**3 ought to be enough for everybody". Hm, actually it's > not that much, minus 20*26 for qaa..qtz, plus 26**2 alpha-2, > 17732 if I got this right. In fact every alpha-2 code has an alpha-3 equivalent (not used in 3066), so you can't count those separately. Still, 2,541,865,827,809 codes is quite a lot of codes. Only a few, however, can possibly have mnemonic value. -- "Well, I'm back." --Sam John Cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 17:37:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVTU-0005Dg-CU; Sun, 29 May 2005 17:37:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVTS-0005Cf-VE for ltru@megatron.ietf.org; Sun, 29 May 2005 17:37:35 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26516 for ; Sun, 29 May 2005 17:37:32 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcVQl-0006af-TO for ltru@lists.ietf.org; Sun, 29 May 2005 23:34:47 +0200 Received: from du-001-103.access.de.clara.net ([212.82.227.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 23:34:47 +0200 Received: from nobody by du-001-103.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 23:34:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 29 May 2005 23:34:45 +0200 Organization: Lines: 47 Message-ID: <429A3575.4916@xyzzy.claranet.de> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> <20050528200139.GC8830@skunk.reutershealth.com> <4299A6C2.4867@xyzzy.claranet.de> <20050529151033.GH8830@skunk.reutershealth.com> <4299FEB1.738E@xyzzy.claranet.de> <20050529181258.GI8830@skunk.reutershealth.com> <429A19BF.51F3@xyzzy.claranet.de> <20050529204054.GJ8830@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-103.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: extlang again X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > yet another compromise with standard matching algorithms. What kind of a compromise is this, replicate redundant info in billions of tags instead of once in the registy ? That strikes me as abuse^Wodd, to put it politely. Cc: Randy, that doesn't fly without a formal ticket number. Not only is the *("-" extlang) a PITA, it's also _redundant_ ? > If a resource in Chadian Arabic were to be tagged simply > "shu", a client looking for Arabic of all sorts would have > to have specialized knowledge to recognize "shu" (and 29 > other language subtags) as equivalent. By requiring "ar-shu" > instead, we make it easy for such a client Okay, old clients might look for ar wanting also ar-TD or the future ar-shu or ar-shu-TD. New servers or new clients could know that ar includes shu. So that's about an old client with an old server and some new shu content. What a headache. But in theory old clients could say ar or shu or ... in an Accept-Language. > whereas a client wanting Standard Arabic specifically can > request "ar-arb" specifically. Banning "shu" by itself > eliminates double coding for the same thing. I have to think about this for a while. It was a big surprise, thanks for info. It's ODD. Why no de-nds instead of nds, what is the difference from ar-shu by definition ? Where is this definition, who decides about it, and do we trust them to get it right ? > In fact every alpha-2 code has an alpha-3 equivalent (not > used in 3066), so you can't count those separately. Okay, 26**3 - 20*26 = 17056. > 2,541,865,827,809 codes is quite a lot of codes. That's 3**26, not 26**3. The CS disaster was no accident. ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 18:37:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWPm-00068B-GN; Sun, 29 May 2005 18:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWPl-00065c-Dy for ltru@megatron.ietf.org; Sun, 29 May 2005 18:37:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01870 for ; Sun, 29 May 2005 18:37:46 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWj3-000152-IA for ltru@ietf.org; Sun, 29 May 2005 18:57:45 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4TMbYO3015264; Sun, 29 May 2005 18:37:35 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 29 May 2005 18:37:43 -0400 Date: Sun, 29 May 2005 18:37:43 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: extlang again Message-ID: <20050529223743.GK8830@skunk.reutershealth.com> References: <20050528160708.MEM13001.mta6.adelphia.net@megatron.ietf.org> <005e01c563b9$5dd580e0$030aa8c0@DEWELL> <20050528200139.GC8830@skunk.reutershealth.com> <4299A6C2.4867@xyzzy.claranet.de> <20050529151033.GH8830@skunk.reutershealth.com> <4299FEB1.738E@xyzzy.claranet.de> <20050529181258.GI8830@skunk.reutershealth.com> <429A19BF.51F3@xyzzy.claranet.de> <20050529204054.GJ8830@skunk.reutershealth.com> <429A3575.4916@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <429A3575.4916@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.reutershealth.com id j4TMbYO3015264 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > Cc: Randy, that doesn't fly without a formal ticket number. It's an RFC 3066ter feature, so we don't need to deal with it yet. > Not only is the *("-" extlang) a PITA, it's also _redundant_ ? Technically, yes. > Okay, old clients might look for ar wanting also ar-TD or the > future ar-shu or ar-shu-TD. New servers or new clients could > know that ar includes shu. Currently you don't have to have access to the registry to do matching, only to do validity checking. I think that's as it should be. > So that's about an old client with an old server and some new > shu content. What a headache. But in theory old clients could > say ar or shu or ... in an Accept-Language. Some clients. Java resource matching doesn't work that way: the client specifies one language-tag and gets the narrowest resource that matches. > I have to think about this for a while. It was a big surprise, > thanks for info. It's ODD. Why no de-nds instead of nds, what > is the difference from ar-shu by definition ? Basically because "German"/"Deutsch" normally means the standard language including its regional varieties, but does not include the true Mundarten. "Arabic" does include both the standard language and its colloquials. > Where is this definition, In ISO 639-3, or at present the draft thereof. # In this example, it may appear that the single identifiers in ISO # 639-1 and ISO 639-2 should be designated as collective language # identifiers. That is not assumed here, however. In various parts of the # world, there are clusters of closely-related language varieties that, # based on the criteria discussed in 4.2.1, can be considered individual # languages, yet in certain usage contexts a single language identity # for all is needed. Typical situations in which this need can occur # include the following: # # =E2=8E=AF There is one variety that is more developed and that tends to= be # used for wider communication by speakers of various closely-related # languages; as a result, there is a perceived common linguistic identi= ty # across these languages. For instance, there are several distinct spok= en # Arabic languages, but Standard Arabic is generally used in business # and media across all of these communities, and is also an important # aspect of a shared ethno-religious unity. As a result, a perceived # common linguistic identity exists. # # =E2=8E=AF There is a common written form used for multiple closely-rela= ted # languages. For instance, multiple Chinese languages share a common # written form. # # =E2=8E=AF There is a transitional socio-linguistic situation in which # sub-communities of a single language communityare diverging, creating # a need for some purposes to recognise distinct languages while, for # other purposes, a single common identity is still valid. For instance= , # in some business contexts it is necessary to make a distinction betwe= en # Bosnian, Croatian and Serbian languages, yet there are other contexts # in which these distinctions are not discernable in language resources # that are in use. # # Where such situations exist, an identifier for the single, common # language identity is considered in this part of ISO 639 to be a # macrolanguage identifier. > who decides about it, The ISO 639-3/RA, or at present Peter Constable, the editor of 639-3. > and do we trust them to get it right ? I do, anyhow. > > In fact every alpha-2 code has an alpha-3 equivalent (not > > used in 3066), so you can't count those separately. >=20 > Okay, 26**3 - 20*26 =3D 17056. >=20 > > 2,541,865,827,809 codes is quite a lot of codes. >=20 > That's 3**26, not 26**3. The CS disaster was no accident. ;-) Oops. 17056 it is. Still plenty if you don't care about mnemonicity. --=20 John Cowan http://www.ccil.org/~cowan jcowan@reutershealth.com Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass. --DeXiderata, Sean McGrath _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 20:45:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcYP3-0006fG-T4; Sun, 29 May 2005 20:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcYP2-0006fB-Nq for ltru@megatron.ietf.org; Sun, 29 May 2005 20:45:12 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10205 for ; Sun, 29 May 2005 20:45:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050530004441.GOVG8952.mta9.adelphia.net@DEWELL> for ; Sun, 29 May 2005 20:44:41 -0400 Message-ID: <004201c564b0$750041e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050529160431.VKUN11379.mta5.adelphia.net@megatron.ietf.org> Date: Sun, 29 May 2005 17:42:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #966] remove something from security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> Alternatively, if there are "tons of such considerations," >> then they would have to be spelled out instead of just >> alluded to. > > It's not pure science fiction, I just checked that you don't > have a Suppress-Script for Tatar (tt) (= let's NOT add Cyrl), > and you reported a dispute about Latn for Moldavian (mo). > > It's nothing we can do about in the Security Considerations > or elsewhere in the draft, but it's no nonsense. I don't know what the open-ended nature of the Suppress-Script repertoire has to do with asking for specific details about security considerations (as opposed to simply asserting that "tons" of them exist). I argued that the Suppress-Script repertoire could never be complete and uncontroversial in its assignments, as users would expect it to be. The group felt that it could be made "close enough" and could be adequately handled through the registration process. But even I would not have claimed that any of this constitutes a security problem. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 21:30:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcZ70-00028F-Q0; Sun, 29 May 2005 21:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcZ6z-00028A-Cw for ltru@megatron.ietf.org; Sun, 29 May 2005 21:30:37 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13422 for ; Sun, 29 May 2005 21:30:35 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050530013006.IFUZ8952.mta9.adelphia.net@DEWELL> for ; Sun, 29 May 2005 21:30:06 -0400 Message-ID: <004801c564b6$8400d640$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 29 May 2005 18:25:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1011] add suppress-region X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > I'm still lost with multiple extlang-s in a tag, how many in > which order ? Draft -03pre still says *( "-" extlang ). The > maximum Recommended-Prefix allows 17 extlang-s. Extended-language subtags really have nothing to do with Recommended-Prefix fields. That is, I suppose an RP field might have as its value a prefix that included an extlang subtag, but I still don't see the connection. (I also don't see where this 17 limit came from.) > We are sure that this will never happen, and it wouldn't work > in encoded word (RfC 2047). But the draft -03pre doesn't say > so, it also does not yet mention RfC 2047 together with 2231. The draft says very little about extlangs in general, except that they are reserved for the future. I really don't see what the fuss is *right now*. > This one * before extlang in the ABNF will fascinate developers > in the "last call", it triggers nightmares of buffer overflows > and memory leaks. As a C and C++ developer -- languages infamous for their vulnerability to buffer overflows -- I responded to the star with caution, but no nightmares. My validator has a fixed internal upper limit of 1,024 characters per tag, which is the sort of limit that should be documented in accordance with Section 2.1.1. A tag with 17 (or 256) extended-language subtags would be syntactically legal ("well-formed") but not semantically legal ("valid") as long as there are no extlang subtags in the registry. My validator doesn't care how many extlang subtags it finds, but if the total tag length is over 1,024 it will silently truncate the tag. (A message might be better.) Memory leaks are always the fault of the developer (or rarely, a buggy development environment) -- never the spec. Since this is all moot, and the mechanism really nothing more than a placeholder, until RFC 3066ter is ready to be discussed, I suggest we not worry about it right now. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 21:40:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcZGr-0002zG-6w; Sun, 29 May 2005 21:40:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcZGq-0002zB-2a for ltru@megatron.ietf.org; Sun, 29 May 2005 21:40:48 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13747 for ; Sun, 29 May 2005 21:40:46 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050530014016.HLBR13270.mta11.adelphia.net@DEWELL>; Sun, 29 May 2005 21:40:16 -0400 Message-ID: <004d01c564b7$d3818240$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050530013101.WNFA11379.mta5.adelphia.net@megatron.ietf.org> Date: Sun, 29 May 2005 18:35:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA13747 Cc: Subject: [Ltru] Re: extlang again X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > Currently you don't have to have access to the registry to do > matching, only to do validity checking. I think that's as it should > be. Almost true. You can't match preferred (n=C3=A9e canonical) values with their non-preferred (n=C3=A9e alias) equivalents without the registry. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 22:52:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcaOZ-0000zd-Qb; Sun, 29 May 2005 22:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcaOX-0000zY-Fo for ltru@megatron.ietf.org; Sun, 29 May 2005 22:52:49 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17326 for ; Sun, 29 May 2005 22:52:46 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcaLY-00041o-82 for ltru@lists.ietf.org; Mon, 30 May 2005 04:49:44 +0200 Received: from du-001-103.access.de.clara.net ([212.82.227.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 May 2005 04:49:44 +0200 Received: from nobody by du-001-103.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 May 2005 04:49:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 30 May 2005 04:50:05 +0200 Organization: Lines: 42 Message-ID: <429A7F5D.75E4@xyzzy.claranet.de> References: <004801c564b6$8400d640$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-103.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] extlang again (was: [psg.com #1011] add suppress-region) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > Extended-language subtags really have nothing to do with > Recommended-Prefix fields. Okay, then let's add Macro-Language to our field name zoo. Assuming that a redundant extlang makes technically sense. > (I also don't see where this 17 limit came from.) 72 is the line length in the registry. LWSP allows to fold behind the colon, Macro-Language:lng-ex1-etc 72 minus one SP minus three "lng" is 68, and 68 / (1+3) = 17. > I really don't see what the fuss is *right now*. The fuss is that *("-" extlang) was discussed quite often, but I never got the idea that it's _redundant_ info. And we're supposed to prepare anything as far as possible for the extlang-s, and that would require a field name "Macro-Language:" (or similar), because adding new field names later could break some new 3066bis registry readers. > I responded to the star with caution, but no nightmares. These tags might be used in any piece of MIME compatible software in some way, in any browser, in any Web server, in any XML lib, Ned mentioned IMAP, we talked about JAVA. > Memory leaks are always the fault of the developer (or > rarely, a buggy development environment) -- never the spec. The spec. should be KISS where possible. Reserving 1 KB per tag is fine when you have it, but some devices might be forced to find a smaller buffer size still trying to support all "important" subtags (up to and including the "script"). And *("-" extlang) comes before the "script". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun May 29 23:02:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcaYD-0001qP-50; Sun, 29 May 2005 23:02:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcaYB-0001qJ-QW for ltru@megatron.ietf.org; Sun, 29 May 2005 23:02:47 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17873 for ; Sun, 29 May 2005 23:02:45 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcaVC-00053b-Vz for ltru@lists.ietf.org; Mon, 30 May 2005 04:59:43 +0200 Received: from du-001-103.access.de.clara.net ([212.82.227.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 May 2005 04:59:42 +0200 Received: from nobody by du-001-103.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 May 2005 04:59:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 30 May 2005 05:01:36 +0200 Organization: Lines: 10 Message-ID: <429A8210.31F5@xyzzy.claranet.de> References: <20050529160431.VKUN11379.mta5.adelphia.net@megatron.ietf.org> <004201c564b0$750041e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-103.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #966] remove something from security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I would not have claimed that any of this constitutes a > security problem. Latn vs. Cyrl for tt is apparently a hot political issue in Russia - I heard a report that it went to the supreme court. But as we both said this doesn't affect the draft. ;-) Bye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 30 05:13:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcgLO-0005DK-VP; Mon, 30 May 2005 05:13:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcgLN-0005DE-JA for ltru@megatron.ietf.org; Mon, 30 May 2005 05:13:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29070 for ; Mon, 30 May 2005 05:13:53 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcgei-0004Ao-HD for ltru@ietf.org; Mon, 30 May 2005 05:33:58 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4U9Da726750; Mon, 30 May 2005 18:13:36 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 8376aeaa_d0ec_11d9_965f_0030482532aa_15818; Mon, 30 May 2005 18:23:42 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0015B6; 30 May 05 18:17:07 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 30 May 05 18:17:02 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.1) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0015B1; 30 May 05 18:16:53 +0900 Message-Id: <6.0.0.20.2.20050528180524.06f3ab00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 28 May 2005 18:06:42 +0900 To: "Addison Phillips" , "Peter Constable" , From: Martin Duerst Subject: RE: [Ltru] use of region subtags In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B8B9C87@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B8B9C87@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I'd be happy either way. But we should make sure that we are very clear about the fact that regions and similar stuff can be omited and is best omited if it doesn't actually contribute any substantial information, even if we choose not to list the combinations where this applies. Regards, Martin. At 03:03 05/05/28, Addison Phillips wrote: >No. > >Nor a Suppress-Variant. > >We might consider a Suppress-Extlang, but I can't think why. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture. > >> -----Original Message----- >> From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On >> Behalf Of Peter Constable >> Sent: vendredi 27 mai 2005 10:43 >> To: ltru@ietf.org >> Subject: [Ltru] use of region subtags >> >> We've agreed to include a Suppress-Script field to avoid things like "en- >> Latn" or "en-Latn-US". Part of the concern over the script subtag had to >> do with interaction with existing usage of tags like "en-US". >> >> >> >> A case like "iu-CA" or "iu-Latn-CA" for which the region is considered >> undesirable because it's considered redundant (for the 99% case) is >> similar in that it's considered best practice not to use a subtag that can >> be assumed by default, though it doesn't have the same compat-with- >> existing-usage issue. Would we ever want to consider a Suppress-Region >> field for lang subtags? >> >> >> >> >> >> >> >> Thanks. >> >> >> >> Peter Constable >> >> GIFT | GPTS | MICROSOFT >> >> > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 30 12:18:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcmyK-00039G-8K; Mon, 30 May 2005 12:18:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcmyI-00039B-6d for ltru@megatron.ietf.org; Mon, 30 May 2005 12:18:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25190 for ; Mon, 30 May 2005 12:18:29 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcnHh-0003bK-N3 for ltru@ietf.org; Mon, 30 May 2005 12:38:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 30 May 2005 09:18:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] use of region subtags Date: Mon, 30 May 2005 09:18:20 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B8BA021@irvmbxw01.quest.com> Thread-Topic: [Ltru] use of region subtags Thread-Index: AcVk9+t+LluvozL7TqK5ke8K42pp7gANzGUQ From: "Addison Phillips" To: "Martin Duerst" , "Peter Constable" , X-OriginalArrivalTime: 30 May 2005 16:18:21.0400 (UTC) FILETIME=[32720D80:01C56533] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Martin, I believe this is pretty clear. See section 4.1 (although you are = correct that region subtags are not specifically cited there). Perhaps = we should add this paragraph between the second and third paragraph of = that section: --- The application and content where the language tag is being used = should be carefully considered when selecting the tag. Methods of = matching tags and variation in the content may influence this choice. = Generally, additional subtags beyond the primary language subtag, such = as scripts, regions, or variants, should only be used when they serve to = directly distinguish one piece of content from some other content. Some = applications of language tag, however, produce better results with more = specific tags. --- The text then continues with the text about scripts ("Of particular = note...") Notice that this would be a useful place for a forward reference to = matching. Notice also that this is a paraphrase of the much loved Rule = Zero: "Tag content wisely." Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: samedi 28 mai 2005 02:07 > To: Addison Phillips; Peter Constable; ltru@ietf.org > Subject: RE: [Ltru] use of region subtags >=20 > I'd be happy either way. But we should make sure that we are very > clear about the fact that regions and similar stuff can be omited > and is best omited if it doesn't actually contribute any substantial > information, even if we choose not to list the combinations where > this applies. >=20 > Regards, Martin. >=20 > At 03:03 05/05/28, Addison Phillips wrote: > >No. > > > >Nor a Suppress-Variant. > > > >We might consider a Suppress-Extlang, but I can't think why. > > > >Addison > > > >Addison P. Phillips > >Globalization Architect, Quest Software > >Chair, W3C Internationalization Core Working Group > > > >Internationalization is not a feature. > >It is an architecture. > > > >> -----Original Message----- > >> From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > >> Behalf Of Peter Constable > >> Sent: vendredi 27 mai 2005 10:43 > >> To: ltru@ietf.org > >> Subject: [Ltru] use of region subtags > >> > >> We've agreed to include a Suppress-Script field to avoid things = like > "en- > >> Latn" or "en-Latn-US". Part of the concern over the script subtag = had > to > >> do with interaction with existing usage of tags like "en-US". > >> > >> > >> > >> A case like "iu-CA" or "iu-Latn-CA" for which the region is = considered > >> undesirable because it's considered redundant (for the 99% case) = is > >> similar in that it's considered best practice not to use a subtag = that > can > >> be assumed by default, though it doesn't have the same = compat-with- > >> existing-usage issue. Would we ever want to consider a = Suppress-Region > >> field for lang subtags? > >> > >> > >> > >> > >> > >> > >> > >> Thanks. > >> > >> > >> > >> Peter Constable > >> > >> GIFT | GPTS | MICROSOFT > >> > >> > > > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 30 12:43:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcnMe-0005CM-O7; Mon, 30 May 2005 12:43:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcnMc-0005CH-Vv for ltru@megatron.ietf.org; Mon, 30 May 2005 12:43:43 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26594 for ; Mon, 30 May 2005 12:43:39 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050530164311.IVGO8952.mta9.adelphia.net@DEWELL> for ; Mon, 30 May 2005 12:43:11 -0400 Message-ID: <001101c56536$9ddef080$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050530160104.XMYF13001.mta6.adelphia.net@megatron.ietf.org> Date: Mon, 30 May 2005 09:42:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: extlang again (was: [psg.com #1011] add suppress-region) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> (I also don't see where this 17 limit came from.) > > 72 is the line length in the registry. LWSP allows to fold > behind the colon, Macro-Language:lng-ex1-etc > > 72 minus one SP minus three "lng" is 68, and 68 / (1+3) = 17. Wow, OK. That's a lot of work, and ultimately it does lead to the result you came up with: one primary language subtag plus 17 extended-language subtags. But John is right too: such a tag is never going to be valid. This business with macrolanguages and the sub-languages they contain currently involves two levels, and may involve three levels at some point, but it is not ever going to involve 17 levels. The hierarchy exists because things like "Chinese" and "Arabic" and "Zapotec" have been encoded in the past as one entity each, and the experts have determined they should actually be broken into multiple entities. But it seems incredibly unlikely (I know, that's not good enough for some) that this refinement could ever involve more than three or four levels. The existing groupings are just not that coarse. I suppose we could set an upper limit of, say, five extlangs, but I fail to see how that qualifies as "keeping it simple." > The fuss is that *("-" extlang) was discussed quite often, > but I never got the idea that it's _redundant_ info. I wouldn't have used the term "redundant" in the sense of "completely unnecessary because already covered by other features." In the tag "ar-arb", one might consider the subtag 'ar' to be redundant because 'arb' already denotes a flavor of Arabic. But it's also possible that a user searching for "Arabic" may want to retrieve all flavors of Arabic, in which case the generality implied by a search for "ar" (matched by "ar-arb" and "ar-shu" and others) would be appropriate. Note that at no point are we saying the extlang itself is redundant. Rather, it is the primary language subtag in this scenario that could be considered redundant. > And we're supposed to prepare anything as far as possible > for the extlang-s, and that would require a field name > "Macro-Language:" (or similar), because adding new field > names later could break some new 3066bis registry readers. At the rate this group is inventing and renaming fields, it wouldn't surprise me at all if some future version of the language tagging document did introduce a new field name. I would suggest that 3066bis registry parsers that are intended to be forward compatible with future versions should quietly ignore fields they don't understand, and would further suggest (TICKET ALERT) that a passage to this effect should be added to the draft. > These tags might be used in any piece of MIME compatible > software in some way, in any browser, in any Web server, > in any XML lib, Ned mentioned IMAP, we talked about JAVA. OK, each of these applications can set (and document) its own limit. >> Memory leaks are always the fault of the developer (or >> rarely, a buggy development environment) -- never the spec. > > The spec. should be KISS where possible. "Keep It Simple, Stupid" (or bowdlerized to "Keep It Short and Simple") makes a great lapel button or picket sign, but the sad fact is that not all problems are simple, and not all problems are best served by the simplest possible solution. See also the Zero-One-Infinity Rule, which is certainly more KISS than setting a scalar limit > 1. And no matter how simple or complex the specification, memory leaks are still the fault of the developer. > Reserving 1 KB > per tag is fine when you have it, but some devices might > be forced to find a smaller buffer size still trying to > support all "important" subtags (up to and including the > "script"). And *("-" extlang) comes before the "script". Then they can set (and document) their own limits. Isn't Section 2.1.1 clear enough on this? And I still don't believe it is necessary to solve this problem, if such it is, within the current draft. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 30 15:01:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcpWM-00079o-7d; Mon, 30 May 2005 15:01:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcpWI-00079j-La for ltru@megatron.ietf.org; Mon, 30 May 2005 15:01:53 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05157 for ; Mon, 30 May 2005 15:01:48 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcpS2-0008Ae-EC for ltru@lists.ietf.org; Mon, 30 May 2005 20:57:26 +0200 Received: from 212.82.251.190 ([212.82.251.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 May 2005 20:57:26 +0200 Received: from nobody by 212.82.251.190 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 May 2005 20:57:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 30 May 2005 20:57:09 +0200 Organization: Lines: 59 Message-ID: <429B6205.1699@xyzzy.claranet.de> References: <20050530160104.XMYF13001.mta6.adelphia.net@megatron.ietf.org> <001101c56536$9ddef080$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.190 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: extlang again X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I suppose we could set an upper limit of, say, five extlangs, > but I fail to see how that qualifies as "keeping it simple." For a developer reading the draft as is, without an explanation for the Macro-Language plus last extlang idea, a clear limit of five means 3 + 5 * (1+3) + (1+4) + (1+3) = 32 for any solution guaranteeing to support at least the subtags up to the region. With an 2047 encoded word =?charset*tag?B?content?= you have 76-9 = 67 characters for the charset name plus the tag plus the encoded content. For the "minimal" 32 mentioned above and "UTF-8" (5) that's 76-9-5-32 = 30 characters for the encoded content. For B (base64) 30*3/4 is about 22.5 source bytes, and in the case of UTF-8 about 22.5/3 = 7.5 Unicode points. Or in other words, the hypothetical limit of five extlang-s with radical truncation before any variant still allows to encode up to 7.5 Unicode points per folded 2231/2047 phrase (assuming UTF-8 and Base 64). If we'd consider one maximal variant (8) as important we'd get 21 instead of 30, or about five B64 UTF-8 characters. Whatever we do, less than one worst case codepoint for 2231 is impossible. A proposal to limit the extlang-s to ten instead of five would be utter dubious for this reason. > Note that at no point are we saying the extlang itself is > redundant. Rather, it is the primary language subtag in > this scenario that could be considered redundant. Yes, looking from the "last" extlang to the "prefix" I got it wrong, of course the Macro-Language is redundant, because it's determined by the last extlang, the last extlang is required. One vague idea I had, maybe restricting this stuff to at most one extlang is the best solution. So if they want to split ar-shu later into ar-shu-sha and ar-shu-shb, we could say that this won't be reflected in real tags but only in the registry. Real tags would simply use ar-sha or ar-shb. If a smart matching algorithm "knows" (because the registry says so) that ar-shu "includes" ar-sha and ar-shb, it's fine, and otherwise forget it. > At the rate this group is inventing and renaming fields, it > wouldn't surprise me at all if some future version of the > language tagging document did introduce a new field name. "Macro-Language" is only the second after "Suppress-Script", and it's apparently necessary for the extlang-s. Nobody liked my idea to use one neutral name like "Associated" to combine "Suppress-Script", "Macro-Laguage", and "Recomended-Prefix" depending on the record type. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon May 30 21:56:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcvzr-0007vt-38; Mon, 30 May 2005 21:56:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcvzp-0007vn-GM for ltru@megatron.ietf.org; Mon, 30 May 2005 21:56:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02686 for ; Mon, 30 May 2005 21:56:43 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcwJL-0006Nr-6v for ltru@ietf.org; Mon, 30 May 2005 22:16:56 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4V1uYju021002; Mon, 30 May 2005 21:56:34 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 30 May 2005 21:56:42 -0400 Date: Mon, 30 May 2005 21:56:42 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: extlang again Message-ID: <20050531015622.GA6568@skunk.reutershealth.com> References: <20050530160104.XMYF13001.mta6.adelphia.net@megatron.ietf.org> <001101c56536$9ddef080$030aa8c0@DEWELL> <429B6205.1699@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429B6205.1699@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > One vague idea I had, maybe restricting this stuff to at most > one extlang is the best solution. So if they want to split > ar-shu later into ar-shu-sha and ar-shu-shb, we could say that > this won't be reflected in real tags but only in the registry. > Real tags would simply use ar-sha or ar-shb. The logic for not doing that is the same as the logic for doing macrolanguages in the first place: a macrolanguage covers multiple languages, and a macrolanguage encompassed by a larger macrolanguage does too. > "Macro-Language" is only the second after "Suppress-Script", > and it's apparently necessary for the extlang-s. Nobody liked > my idea to use one neutral name like "Associated" to combine > "Suppress-Script", "Macro-Laguage", and "Recomended-Prefix" > depending on the record type. It would be too easy to get the semantics wrong. Having separate headers ensures that each is treated correctly, without having to worry about what the type is. -- The Unicode Standard does not encode John Cowan idiosyncratic, personal, novel, or private http://www.ccil.org/~cowan use characters, nor does it encode logos http://www.reutershealth.com or graphics. jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 00:54:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcylv-0002Zj-Dc; Tue, 31 May 2005 00:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcyls-0002ZZ-BT for ltru@megatron.ietf.org; Tue, 31 May 2005 00:54:33 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13953 for ; Tue, 31 May 2005 00:54:27 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050531045359.SUDW17140.mta10.adelphia.net@DEWELL> for ; Tue, 31 May 2005 00:53:59 -0400 Message-ID: <004e01c5659c$b8027700$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 30 May 2005 21:53:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] New registry to reflect draft-03 changes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org As most already know, draft-03 includes a change with regard to the initial registry. Instead of automatically creating variant subtags from tags like "en-boont" and "de-1901", this draft proposes that all such tags be grandfathered, and the variants proposed through the normal registration process and evaluated case by case. Accordingly, I've uploaded a new registry that removes all the variant subtags, and changes the status of all "redundant" tags that would have included one of these variants to "grandfathered." Please take a look at this registry and see if you think it agrees with the changes proposed in draft-03, and with the draft generally. Please note that no other content-related changes that may have been discussed on the list are reflected in this registry. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 01:13:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcz4W-000561-RZ; Tue, 31 May 2005 01:13:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcz4V-00055w-6g for ltru@megatron.ietf.org; Tue, 31 May 2005 01:13:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15070 for ; Tue, 31 May 2005 01:13:46 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DczO2-0001cA-Lp for ltru@ietf.org; Tue, 31 May 2005 01:33:59 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 May 2005 22:13:32 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 May 2005 22:13:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] extlang again (was: [psg.com #1011] add suppress-region) Date: Mon, 30 May 2005 22:13:34 -0700 Message-ID: Thread-Topic: [Ltru] extlang again (was: [psg.com #1011] add suppress-region) Thread-Index: AcVkwsgYnq28pChRSuCTpCqOauQxDAA3BJmw From: "Peter Constable" To: X-OriginalArrivalTime: 31 May 2005 05:13:34.0601 (UTC) FILETIME=[7E794790:01C5659F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > The fuss is that *("-" extlang) was discussed quite often, > but I never got the idea that it's _redundant_ info. Clarification: the extlang subtag would *not* be redundant info; when an extlang subtag is used (assuming the ideas that have been exchanged re how we would implement this in 3066ter) then the *lang* subtag is redundant info. For instance, "shu" is a specific variety encompassed by "ar", hence it implies "ar"; so in "ar-shu", the "ar" is redundant. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 08:08:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd5Xc-0007Pv-MZ; Tue, 31 May 2005 08:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd5Xb-0007Pp-66 for ltru@megatron.ietf.org; Tue, 31 May 2005 08:08:15 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03746 for ; Tue, 31 May 2005 08:08:13 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dd5Tn-0004YT-IH for ltru@lists.ietf.org; Tue, 31 May 2005 14:04:19 +0200 Received: from c-134-90-31.hh.dial.de.ignite.net ([62.134.90.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 May 2005 14:04:19 +0200 Received: from nobody by c-134-90-31.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 May 2005 14:04:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 31 May 2005 14:03:22 +0200 Organization: Lines: 22 Message-ID: <429C528A.690E@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-90-31.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: extlang again X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > the *lang* subtag is redundant info. For instance, "shu" > is a specific variety encompassed by "ar", hence it implies > "ar"; so in "ar-shu", the "ar" is redundant. Yes, so far it's clear. What I don't see is a convincing reason for multiple levels of redudancy. From an academical POV this is probably fascinating, but is it also important in practice ? When I want tomatoes for cooking, I'm really not interested in potatoes. In recipes I wouldn't want to "tag" this as sol-tom and sol-pot, and I'm not tempted to match them with banewort. Either they are variants or they are different. To get this right is probably a PITA, but attempts to do both at the same time IMHO don't belong in billions of tags in the real world. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 09:17:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd6co-0008Bf-TR; Tue, 31 May 2005 09:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd6cm-0008BS-Cn for ltru@megatron.ietf.org; Tue, 31 May 2005 09:17:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08046 for ; Tue, 31 May 2005 09:17:39 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd6wL-0002Ih-Nr for ltru@ietf.org; Tue, 31 May 2005 09:37:57 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4VDHPRe023270; Tue, 31 May 2005 09:17:26 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 31 May 2005 09:17:25 -0400 Date: Tue, 31 May 2005 09:17:25 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: extlang again Message-ID: <20050531131725.GL6568@skunk.reutershealth.com> References: <429C528A.690E@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429C528A.690E@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > Yes, so far it's clear. What I don't see is a convincing > reason for multiple levels of redudancy. From an academical > POV this is probably fascinating, but is it also important > in practice ? It's as important as backward compatibility is. > When I want tomatoes for cooking, I'm really not interested > in potatoes. In recipes I wouldn't want to "tag" this as > sol-tom and sol-pot, and I'm not tempted to match them with > banewort. _Cannabis indica_ and _Cannabis sativa_ are separate species, but they'll both get you high; for that purpose they are the same. > Either they are variants or they are different. Unfortunately, that turns out not to be the case. Standard Arabic and Egyptian Arabic definitely aren't mere variants of one another, but there is a definite sense in which they are both Arabic which is not a mere family resemblance. -- Do what you will, John Cowan this Life's a Fiction jcowan@reutershealth.com And is made up of http://www.reutershealth.com Contradiction. --William Blake http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 11:05:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8JE-0007da-EK; Tue, 31 May 2005 11:05:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8JE-0007dV-3u for ltru@megatron.ietf.org; Tue, 31 May 2005 11:05:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16883 for ; Tue, 31 May 2005 11:05:34 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd8cq-0004NN-OU for ltru@ietf.org; Tue, 31 May 2005 11:25:54 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 08:05:23 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 08:05:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: extlang again Date: Tue, 31 May 2005 08:05:27 -0700 Message-ID: Thread-Topic: [Ltru] Re: extlang again Thread-Index: AcVl2ebo2pVvpozJS1ex63GISxHXcwAEq2sg From: "Peter Constable" To: X-OriginalArrivalTime: 31 May 2005 15:05:23.0832 (UTC) FILETIME=[2B9FEF80:01C565F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Yes, so far it's clear. What I don't see is a convincing > reason for multiple levels of redudancy. From an academical > POV this is probably fascinating, but is it also important > in practice ? > Either they are variants or they are different. To get this > right is probably a PITA, but attempts to do both at the same > time IMHO don't belong in billions of tags in the real world. We will eventually need to work through all such issues when we are developing 3066ter. But let me ask: is the immediate issue that you want to change *("-" extlang) to *n("-" extlang) for some smallish value of n, such as 5? If so, that would be reasonable to me. Now, as for the issues you raise, it's reasonably clear that we will not be facing billions of tags with extlang subtags, let alone multiple extlang subtags. You can inspect the tables in ISO/DIS 639-3 to find that there are some 56 macrolanguages (26 of these have alpha-2 IDs) which together encompass 365 individual languages. (This status of the code tables is that they are still draft proposals; in particular, the ISO 639/RA Joint=20 Advisory Committee still needs to decide if they want to treat those 56 entries in 639-2 as macrolanguages, as I have proposed.) Let's imagine that on average each is written with three different scripts, spoken in five countries, and that five variant subtags are eventually registered -- an *extreme* unlikelihood; that's around 53000 possible tags involving these extlangs. But again, the assumptions behind that scenario are very unlikely: there are only a small number of these that have any likelihood of being written in more than one script; many are spoken in only one country, and only Arabic and Chinese are spoken in many countries. I suppose on average there's as much likelihood of variants being registered for these languages as for any other. In reality, we're looking at *far* fewer than 53000. At present, there is no case in the draft code tables for 639-3 of a macrolanguage that is encompassed by another macrolanguage. So, at present, there would be no valid 3066ter tag with more than one extlang. John has described the scenario under which such a thing could arise. It's something I'd expect would happen rarely. So, the number of tags you'll ever see multiple extlang subtags, if any, will be very limited. Now, does it make sense to use extlang subtags? And if the possibility of multiple extlangs arises would it make to use multiple extlangs? I think it would, since it provides a workable means for matching where the request and the items are tagged with different levels of specificity -- something that *is* likely given that there will be existing implementations using the more generic value, with the more specific value becoming possible. Again, if the immediate issue is to limit the length of possible tags, let's change the ABNF to allow at most 5 extlangs and move on. Peter Constable=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 11:07:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8LF-0007zA-E8; Tue, 31 May 2005 11:07:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8LD-0007z2-L1 for ltru@megatron.ietf.org; Tue, 31 May 2005 11:07:39 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17152 for ; Tue, 31 May 2005 11:07:37 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dd8Fk-0006kH-Ie for ltru@lists.ietf.org; Tue, 31 May 2005 17:02:00 +0200 Received: from c-134-90-31.hh.dial.de.ignite.net ([62.134.90.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 May 2005 17:02:00 +0200 Received: from nobody by c-134-90-31.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 May 2005 17:02:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 31 May 2005 17:00:33 +0200 Organization: Lines: 33 Message-ID: <429C7C11.D78@xyzzy.claranet.de> References: <429C528A.690E@xyzzy.claranet.de> <20050531131725.GL6568@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-90-31.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: extlang again X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > It's as important as backward compatibility is. At the moment the worst we have is lng-cc-variant. To be somewhat compatible with this scheme I understand "ar-shu belongs to ar". But I don't undertstand _further_ levels. "Old" (= all) applications only know ar, not hypothetical subdivisions ar-shu-sha and ar-shu-shb below ar-shu. > _Cannabis indica_ and _Cannabis sativa_ are separate > species, but they'll both get you high; for that purpose > they are the same. For a hemp rope I don't care about the THC, and I wouldn't try to use olibanum for ropes. Classifications are a can of worms. > Standard Arabic and Egyptian Arabic definitely aren't mere > variants of one another, but there is a definite sense in > which they are both Arabic Sounds like nds and de. Where I live all local newspapers and radio stations have daily nds columns. I never learned it, but understanding it is possible (with the help of "en" for interpolations in my case). Both de-nds and nds are fine as far as I'm concerned, but the idea of _more_ levels bothers me. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 13:13:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAIz-00024D-Ny; Tue, 31 May 2005 13:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAIy-000248-Oq for ltru@megatron.ietf.org; Tue, 31 May 2005 13:13:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26237 for ; Tue, 31 May 2005 13:13:26 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdAcb-0006w1-Il for ltru@ietf.org; Tue, 31 May 2005 13:33:47 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4VHDGb4024434; Tue, 31 May 2005 13:13:17 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 31 May 2005 13:13:20 -0400 Date: Tue, 31 May 2005 13:13:20 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: extlang again Message-ID: <20050531171240.GA13188@skunk.reutershealth.com> References: <429C528A.690E@xyzzy.claranet.de> <20050531131725.GL6568@skunk.reutershealth.com> <429C7C11.D78@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <429C7C11.D78@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.reutershealth.com id j4VHDGb4024434 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > At the moment the worst we have is lng-cc-variant. To be > somewhat compatible with this scheme I understand "ar-shu > belongs to ar". But I don't undertstand _further_ levels. >=20 > "Old" (=3D all) applications only know ar, not hypothetical > subdivisions ar-shu-sha and ar-shu-shb below ar-shu. You are not allowing for *future* backward compatibility, as it were. When 3066ter comes into force, and people start tagging their Chadian Arabic corpora "ar-shu", they will not be happy with us if we say that "ar-shu" is now discredited in favor of "ar-sha" and "ar-shb". No, they will say, we will reclassify our resources as you say, but we insist that people looking for "ar-shu" content can still find it. That's why we want to be able to tell them to use "ar-shu-sha" and "ar-shu-shb". > Sounds like nds and de. Where I live all local newspapers > and radio stations have daily nds columns. I never learned > it, but understanding it is possible (with the help of "en" > for interpolations in my case). Under what circumstances is nds referred to simply as "Deutsch", unqualif= ied? That's the essence of being encompassed by a macrolanguage. > Both de-nds and nds are fine as far as I'm concerned, but > the idea of _more_ levels bothers me. Right now there are none, and I'm willing to bet a reasonable sum that there never will be, based on the Ethnologue's known propensity for fine splits. For example, there are are already 18 indigenous West Germanic languages in Germany (Alemannisch, Bayerisch, North and East Frisian and Saterfrisian, K=F6lsch, Jenisch, Limburgisch, Letzeburgesch, Mainfr=E4nkisch, Pf=E4lzisch, Plautdietsch, nds under any of its various names, Upper Saxon, Schw=E4bisch, Westf=E4lisch, Western Yiddish, and of course Standard German), plus eight others (Danish, Polish, Upper and Lower Sorbian, three kinds of Romani, and German Sign Language). None of these are languages encompassed by a macrolanguage. There are also some 44 immigrant languages listed, some of which are so encompassed. So as Peter says, let's limit it to five extlangs and move on. --=20 Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): jcowan@reutershealth.com One sentence (two stanzas) / Hexasyllabically http://www.reutershealth.= com Challenges poets who / Don't have the time. --robison who's at texas = dot net _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 15:55:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCpP-00009L-Lv; Tue, 31 May 2005 15:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCpN-000074-Uy for ltru@megatron.ietf.org; Tue, 31 May 2005 15:55:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13680 for ; Tue, 31 May 2005 15:55:04 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdD91-0006y1-8v for ltru@ietf.org; Tue, 31 May 2005 16:15:26 -0400 Received: from h-64-105-137-177.snvacaid.dynamic.covad.net ([64.105.137.177] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DdCpJ-0001tM-00 for ltru@ietf.org; Tue, 31 May 2005 15:55:01 -0400 Message-ID: <001c01c5661b$0a964ea0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <004801c564b6$8400d640$030aa8c0@DEWELL> Subject: Re: [Ltru] [psg.com #1011] add suppress-region Date: Tue, 31 May 2005 12:57:56 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - It looks like there is no consensus to add "suppress-region", so I'll mark this issue "rejected". If further discussion is necessary, please use an appropriate subject line. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 16:17:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDA1-0004lz-L7; Tue, 31 May 2005 16:16:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDA0-0004lV-8D for ltru@megatron.ietf.org; Tue, 31 May 2005 16:16:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22166 for ; Tue, 31 May 2005 16:16:22 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdDTf-00024h-IF for ltru@ietf.org; Tue, 31 May 2005 16:36:44 -0400 Received: from h-64-105-137-177.snvacaid.dynamic.covad.net ([64.105.137.177] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DdD9w-0000VP-00 for ltru@ietf.org; Tue, 31 May 2005 16:16:21 -0400 Message-ID: <002b01c5661e$05b61c00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] [psg.com #875] should initial registry contents be made into an internet-draft? Date: Tue, 31 May 2005 13:19:17 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - The WG discussion of this issue was inconclusive, so the co-chairs consulted with our responsible AD to determine what in his opinion would work best logistically with IANA and the IESG to deliver the initial registry contents. The conclusion: the registry contents should indeed be put into an internet-draft, for publication as an *informational* RFC. It would contain both the initial registry contents and text to let people know that they should refer to the registry at a specific location for the most current values. Consequently, I'm marking issue #875 (and related issue 878) as "resolved", and the editors will need to adjust the text in the registry draft (sections 3.7 and 5, I think) accordingly. Doug Ewell graciously volunteered to edit this i-d some time ago. Ideally, we'd issue its WG last call at the same time as the registry draft, since comments on the proposed initial registry have been most useful in revealing issues in the registry draft. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 16:17:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDBQ-0005hi-8L; Tue, 31 May 2005 16:17:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDBO-0005hE-Bq for ltru@megatron.ietf.org; Tue, 31 May 2005 16:17:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23035 for ; Tue, 31 May 2005 16:17:48 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdDV3-0002T0-NQ for ltru@ietf.org; Tue, 31 May 2005 16:38:10 -0400 Received: from h-64-105-137-177.snvacaid.dynamic.covad.net ([64.105.137.177] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DdDBM-0000zr-00 for ltru@ietf.org; Tue, 31 May 2005 16:17:48 -0400 Message-ID: <003001c5661e$3a178880$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] [psg.com #878] should the initial registry contents i-d be published as an RFC? Date: Tue, 31 May 2005 13:20:45 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - The WG discussion of this issue was inconclusive, so the co-chairs consulted with our responsible AD to determine what in his opinion would work best logistically with IANA and the IESG to deliver the initial registry contents. The conclusion: the registry contents should indeed be put into an internet-draft, for publication as an *informational* RFC. It would contain both the initial registry contents and text to let people know that they should refer to the registry at a specific location for the most current values. Consequently, I'm marking issue #878 (and related issue 875) as "resolved", and the editors will need to adjust the text in the registry draft (sections 3.7 and 5, I think) accordingly. Doug Ewell graciously volunteered to edit this i-d some time ago. Ideally, we'd issue its WG last call at the same time as the registry draft, since comments on the proposed initial registry have been most useful in revealing issues in the registry draft. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 16:32:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDPk-0001YL-OZ; Tue, 31 May 2005 16:32:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDPi-0001Y2-HE for ltru@megatron.ietf.org; Tue, 31 May 2005 16:32:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28380 for ; Tue, 31 May 2005 16:32:36 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdDjO-0004hk-5T for ltru@ietf.org; Tue, 31 May 2005 16:52:59 -0400 Received: from h-64-105-137-177.snvacaid.dynamic.covad.net ([64.105.137.177] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DdDPf-0006hy-00 for ltru@ietf.org; Tue, 31 May 2005 16:32:35 -0400 Message-ID: <004b01c56620$4b0a9ae0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050510144234.LCSR17200.mta1.adelphia.net@megatron.ietf.org> <007701c555e9$b61b23a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #949] remove three-character limit in sections 2.2.2, 2.2.3 (of -00) Date: Tue, 31 May 2005 13:35:10 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - There was no consensus to adopt this item, so I've marked it "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 16:44:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDbG-0004dp-Ke; Tue, 31 May 2005 16:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDbE-0004bn-5j for ltru@megatron.ietf.org; Tue, 31 May 2005 16:44:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29449 for ; Tue, 31 May 2005 16:44:28 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdDuq-0005Ho-Pg for ltru@ietf.org; Tue, 31 May 2005 17:04:51 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:44:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #875] should initial registry contents be madeinto an internet-draft? Date: Tue, 31 May 2005 13:44:13 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B989E07@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #875] should initial registry contents be madeinto an internet-draft? Thread-Index: AcVmHpAJYzHKSPsYTMuqWCYcR6H56gAAn6Yw From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 31 May 2005 20:44:14.0619 (UTC) FILETIME=[81B7D6B0:01C56621] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I have made the changes to section 3.7. There was no text in section 5 = that actually required a change (how the initial registry gets populated = has no impact on IANA, so long as IANA doesn't do it). I will post the updated "draft-03" shortly on my site and may submit the = results if I get the time to update all the other bits and pieces and = run the QA on the text. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: mardi 31 mai 2005 13:19 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #875] should initial registry contents be > madeinto an internet-draft? >=20 > Hi - >=20 > The WG discussion of this issue was inconclusive, so the co-chairs > consulted > with our responsible AD to determine what in his opinion would work = best > logistically with IANA and the IESG to deliver the initial registry > contents. > The conclusion: the registry contents should indeed be put into an > internet-draft, > for publication as an *informational* RFC. It would contain both the > initial registry > contents and text to let people know that they should refer to the > registry at a > specific location for the most current values. >=20 > Consequently, I'm marking issue #875 (and related issue 878) as = "resolved", > and the editors will need to adjust the text in the registry draft > (sections 3.7 > and 5, I think) accordingly. >=20 > Doug Ewell graciously volunteered to edit this i-d some time ago. = Ideally, > we'd issue its WG last call at the same time as the registry draft, = since > comments on the proposed initial registry have been most useful in > revealing > issues in the registry draft. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 17:53:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdEgF-0000PR-3F; Tue, 31 May 2005 17:53:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdEgD-0000PM-L9 for ltru@megatron.ietf.org; Tue, 31 May 2005 17:53:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03058 for ; Tue, 31 May 2005 17:53:43 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdEzt-0000KI-LE for ltru@ietf.org; Tue, 31 May 2005 18:14:07 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j4VLrUrr025764 for ; Tue, 31 May 2005 17:53:31 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 31 May 2005 17:53:37 -0400 Date: Tue, 31 May 2005 17:53:37 -0400 From: John Cowan To: ltru@ietf.org Message-ID: <20050531215337.GH13188@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Ltru] Re: extlang again X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy, can we have a ticket for "restrict the maximum number of extlang subtags to five"? -- The experiences of the past show John Cowan that there has always been a discrepancy jcowan@reutershealth.com between plans and performance. http://www.reutershealth.com --Emperor Hirohito, August 1945 http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 19:40:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdGLc-000126-7m; Tue, 31 May 2005 19:40:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdGLa-000121-CM for ltru@megatron.ietf.org; Tue, 31 May 2005 19:40:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10575 for ; Tue, 31 May 2005 19:40:31 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdGfH-0005Hw-Bv for ltru@ietf.org; Tue, 31 May 2005 20:00:56 -0400 Received: from h-68-165-6-140.snvacaid.dynamic.covad.net ([68.165.6.140] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DdGLX-0003GY-00 for ltru@ietf.org; Tue, 31 May 2005 19:40:31 -0400 Message-ID: <001d01c5663a$8bb10e20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050531215337.GH13188@skunk.reutershealth.com> Date: Tue, 31 May 2005 16:43:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] [psg.com #1016] restrict the maximum number of extlang subtags to five X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "John Cowan" > To: > Sent: Tuesday, May 31, 2005 2:53 PM > Subject: [Ltru] Re: extlang again > > Randy, can we have a ticket for "restrict the maximum number of extlang subtags > to five"? ... Done. ------------------------------------------------------------------------- This issue was raised in message http://www1.ietf.org/mail-archive/web/ltru/current/msg01937.html of a longer thread. Note that this is distinct from issue [psg.com #943] Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 20:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdH0a-0007ar-EQ; Tue, 31 May 2005 20:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdH0Z-0007al-2V for ltru@megatron.ietf.org; Tue, 31 May 2005 20:22:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12741 for ; Tue, 31 May 2005 20:22:53 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdHKH-0007HU-Dn for ltru@ietf.org; Tue, 31 May 2005 20:43:17 -0400 Received: from h-68-165-6-140.snvacaid.dynamic.covad.net ([68.165.6.140] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DdH0W-0007eZ-00 for ltru@ietf.org; Tue, 31 May 2005 20:22:53 -0400 Message-ID: <00da01c56640$75f72b40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050510065151.NPIT28887.mta4.adelphia.net@megatron.ietf.org> <005e01c555e8$3dc7b900$030aa8c0@DEWELL> Subject: Re: [Ltru] [psg.com #944] MAY a conformant implementation impose length constraints? Date: Tue, 31 May 2005 17:25:48 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - In light of the recent discussion, would it make sense to simply nail down the maximum length of a tag, and require all conformant implementations to support that length, thus eliminating the question of truncation? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 20:26:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdH3Z-0007rA-RI; Tue, 31 May 2005 20:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdH3Y-0007r5-Et for ltru@megatron.ietf.org; Tue, 31 May 2005 20:26:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12981 for ; Tue, 31 May 2005 20:25:56 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdHND-0007RP-Ly for ltru@ietf.org; Tue, 31 May 2005 20:46:21 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 17:25:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation imposelength constraints? Date: Tue, 31 May 2005 17:25:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B989F0D@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #944] MAY a conformant implementation imposelength constraints? Thread-Index: AcVmQBXJFuFUrJcXSYq4Aer1/CTtEwAAD1wQ From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 01 Jun 2005 00:25:41.0096 (UTC) FILETIME=[71135680:01C56640] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Won't work: Variants and private use subtags are not bounded in number. = Neither can extension lengths be known in advance. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: mardi 31 mai 2005 17:26 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #944] MAY a conformant implementation > imposelength constraints? >=20 > Hi - >=20 > In light of the recent discussion, would it make sense to simply nail = down > the maximum length of a tag, and require all conformant = implementations to > support that length, thus eliminating the question of truncation? >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 20:38:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdHFi-0001L3-Fg; Tue, 31 May 2005 20:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdHFg-0001Ky-VM for ltru@megatron.ietf.org; Tue, 31 May 2005 20:38:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13649 for ; Tue, 31 May 2005 20:38:31 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdHZO-00085L-Hr for ltru@ietf.org; Tue, 31 May 2005 20:58:56 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j510cJMv000616; Tue, 31 May 2005 17:38:19 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 31 May 2005 17:38:19 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Randy Presuhn , LTRU Working Group Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation imposel ength constraints? Date: Tue, 31 May 2005 17:38:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, Also won't work because there are quite a few existing protocols and markup languages that already _have_ imposed maximum lengths on language tags (often modest lengths, because they never anticipated script/variant/extlang/etc.). RFC3066bis could define a lower bound on maximum length (with a SHOULD?) to be supported by conforming implementations. It would probably be worth considering, because it seems obvious that truncation in practice may be ugly and poorly implemented (i.e., greater than X gets chopped at X). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Tuesday, May 31, 2005 8:26 PM > To: Randy Presuhn; LTRU Working Group > Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation > imposelength constraints? > > > Won't work: Variants and private use subtags are not bounded > in number. Neither can extension lengths be known in advance. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Randy Presuhn > > Sent: mardi 31 mai 2005 17:26 > > To: LTRU Working Group > > Subject: Re: [Ltru] [psg.com #944] MAY a conformant implementation > > imposelength constraints? > > > > Hi - > > > > In light of the recent discussion, would it make sense to > simply nail down > > the maximum length of a tag, and require all conformant > implementations to > > support that length, thus eliminating the question of truncation? > > > > Randy > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 20:44:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdHLR-0002AL-9a; Tue, 31 May 2005 20:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdHLP-0002AG-Al for ltru@megatron.ietf.org; Tue, 31 May 2005 20:44:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13898 for ; Tue, 31 May 2005 20:44:25 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdHf6-0008Lo-O4 for ltru@ietf.org; Tue, 31 May 2005 21:04:49 -0400 Received: from h-68-165-6-140.snvacaid.dynamic.covad.net ([68.165.6.140] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DdHLI-0006cB-00 for ltru@ietf.org; Tue, 31 May 2005 20:44:20 -0400 Message-ID: <013701c56643$76004ba0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B989F0D@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #944] MAY a conformant implementation impose length constraints? Date: Tue, 31 May 2005 17:47:16 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - (as a technical contributor) > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, May 31, 2005 5:25 PM > Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation imposelength constraints? > > Won't work: Variants and private use subtags are not bounded in number. > Neither can extension lengths be known in advance. ... Then I think we really need to add something like the following to the security considerations section, as part of this issue's resolution / rejection: Since there is no limit to the number of variant and private use subtags, and consequently no limit on the possible length of a tag, implementations need to guard against buffer overflow attacks. See section ## for details on tag truncation, which can occur as a consequence of defenses against buffer overflow. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 23:31:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdJx4-0001ZR-QM; Tue, 31 May 2005 23:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdJx3-0001ZM-T2 for ltru@megatron.ietf.org; Tue, 31 May 2005 23:31:29 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22251 for ; Tue, 31 May 2005 23:31:27 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050601033057.NKBN4191.mta13.adelphia.net@DEWELL> for ; Tue, 31 May 2005 23:30:57 -0400 Message-ID: <000401c5665a$4da6e440$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050601003909.GDCH17930.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 31 May 2005 20:30:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1016] restrict the maximum number of extlang subtags to five X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> Randy, can we have a ticket for "restrict the maximum number of >> extlang subtags to five"? > ... > > Done. > > ---------------------------------------------------------------------- > This issue was raised in message > http://www1.ietf.org/mail-archive/web/ltru/current/msg01937.html > of a longer thread. > > Note that this is distinct from issue [psg.com #943] I support this. I mean, it's arbitrary and not beautiful, but it seems to satisfy an objection that was holding up progress, without imposing a serious practical limitation. So, I support it. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 23:47:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdKCQ-00047n-L1; Tue, 31 May 2005 23:47:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdKCP-00047i-4N for ltru@megatron.ietf.org; Tue, 31 May 2005 23:47:21 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23460 for ; Tue, 31 May 2005 23:47:18 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050601034647.NWGV4191.mta13.adelphia.net@DEWELL> for ; Tue, 31 May 2005 23:46:47 -0400 Message-ID: <000c01c5665c$84056e60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050601003909.GDCH17930.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 31 May 2005 20:46:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #944] MAY a conformant implementation impose length constraints? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Won't work: Variants and private use subtags are not bounded in > number. Neither can extension lengths be known in advance. I agree. In addition to what Addison said, even those limits that can be known in advance would add up to a maximum length that few space-limited applications would honor: lng-exa-exb-exc-exd-exe-scrp-RG-variant-e-xtension-x-private contains only one variant, one extension, and one private-use subtag, but is already 60 characters, much longer than an encoded-word could handle. There's not much point in imposing an upper limit that would still be too long for some applications. I don't think the title of this thread/ticket quite matches the question asked in the body. My response to the title would be, *of course* a conformant implementation may impose a length constraint. So says Section 2.1.1. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue May 31 23:50:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdKFS-0004ZB-Td; Tue, 31 May 2005 23:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdKFR-0004Z6-Cu for ltru@megatron.ietf.org; Tue, 31 May 2005 23:50:29 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23609 for ; Tue, 31 May 2005 23:50:26 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050601034958.IJYY17140.mta10.adelphia.net@DEWELL> for ; Tue, 31 May 2005 23:49:58 -0400 Message-ID: <001401c5665c$f9fa9320$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 31 May 2005 20:49:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #944] MAY a conformant implementation impose length constraints? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> Won't work: Variants and private use subtags are not bounded in >> number. Neither can extension lengths be known in advance. > > Then I think we really need to add something like the following to the > security considerations section, as part of this issue's resolution / > rejection: > > Since there is no limit to the number of variant and private use > subtags, and consequently no limit on the possible length of a tag, > implementations need to guard against buffer overflow attacks. See > section ## for details on tag truncation, which can occur as a > consequence of defenses against buffer overflow. Yes. Excellent. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru