From duerst@it.aoyama.ac.jp Wed Apr 1 00:34:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85ED73A68C8 for ; Wed, 1 Apr 2009 00:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.871 X-Spam-Level: X-Spam-Status: No, score=0.871 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0h3ow15jEkY for ; Wed, 1 Apr 2009 00:34:12 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id DBE3C3A67A7 for ; Wed, 1 Apr 2009 00:34:11 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n317ZAN6009117 for ; Wed, 1 Apr 2009 16:35:10 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 464a_a14b7736_1e8f_11de_8b82_0019b9e2b3d9; Wed, 01 Apr 2009 16:35:10 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51700) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 1 Apr 2009 16:26:29 +0900 Message-ID: <49D3191B.6070409@it.aoyama.ac.jp> Date: Wed, 01 Apr 2009 16:34:51 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Mark Nottingham Subject: Re: Minutes from informal IETF/W3C meeting about HTML5 work References: <0E44F8EA-C111-45AD-BF86-DA2673B28EF9@mnot.net> <49D1F12D.3040009@it.aoyama.ac.jp> <295EC891-EF33-4400-89AF-020BCBBB4A9C@mnot.net> In-Reply-To: <295EC891-EF33-4400-89AF-020BCBBB4A9C@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss , HTTP Working Group , public-iri@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:34:13 -0000 At one point, it definitely was. Many people on the uri list were not interested in IRI issues, and some i18n experts on the IRI list weren't interested in URI issues. Of course, times may have changed, and in case we'd decide to stuff all the HTML5 bugwards-compatibility stuff for URIs into the IRI spec because the URI spec is already at Full Standard, things might change. Regards, Martin. On 2009/03/31 20:10, Mark Nottingham wrote: > Just thinking out loud -- is it *really* a good idea to have separate > URI and IRI lists? > > Cheers, From duerst@it.aoyama.ac.jp Wed Apr 1 01:34:00 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A56A28C150 for ; Wed, 1 Apr 2009 01:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yFUJNZiBnxm for ; Wed, 1 Apr 2009 01:33:58 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id BBDB83A6C0B for ; Wed, 1 Apr 2009 01:33:56 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n318YtIH020506 for ; Wed, 1 Apr 2009 17:34:55 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 3618_fa6441f6_1e97_11de_af5b_0019b9e2b3d9; Wed, 01 Apr 2009 17:34:55 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40276) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 1 Apr 2009 17:26:14 +0900 Message-ID: <49D3271D.2040203@it.aoyama.ac.jp> Date: Wed, 01 Apr 2009 17:34:37 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Julian Reschke Subject: Re: Generic URI syntax incompatible with IPv6 addresses in SIP URIs References: <167dfb9b0903290605m606a0ee8v13f1afede2d1c8f3@mail.gmail.com> <49D285A6.6060104@gmx.de> In-Reply-To: <49D285A6.6060104@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: public-iri@w3.org, Mark Baker , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:34:00 -0000 I agree with Julian that discussion about updates of RFC 3987 (IRI spec, new version currently at draft-duerst-iri-bis-05) should go to public-iri@w3.org, whereas bug reports and discussions about RFC 3986 (URI spec) should go to uri@w3.org. But Lisa, you are the AD who eventually has to handle anything that comes out of these drafts, so I'm glad to follow your directions. Julian, could you be more specific (pointer is sufficient) about what you mean below with "potential issue (normalization)"? Regards, Martin. On 2009/04/01 6:05, Julian Reschke wrote: > Lisa Dusseault wrote: >> Well, I'm confused. "Moving" was a loose term, but I did think I >> heard that we should join "public-?ri" (didn't hear very clearly at >> the bar bof) and "public-iri" was the match I found. Since I'm a >> newcomer to either list (URI work has been pretty slow while I've been >> AD), just let me know which list we should use to discuss updating the >> IETF URI RFCs. > > Well, we've got both > > > > and > > > > As far as I can tell, the discussion is about: > > - a potential issue with the IRI spec (normalization) > > and > > - a potential addition already drafted in RFC3987bis (LEIRIs) > > In particular, I haven't seen any bugs reported against RFC3986 in this > context (except the lack of error handling requirements, which clearly > is controversial). > > Thus, it seems that we are really talking about RFC3987bis, and thus the > IRI mailing list would be the right place. > > BR, Julian > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- #-# Martin J.Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From julian.reschke@gmx.de Wed Apr 1 01:51:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A285C3A6AB2 for ; Wed, 1 Apr 2009 01:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=-2.420, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs2UsLXID9TE for ; Wed, 1 Apr 2009 01:51:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7653E3A6A9B for ; Wed, 1 Apr 2009 01:51:32 -0700 (PDT) Received: (qmail invoked by alias); 01 Apr 2009 08:52:31 -0000 Received: from p508FF886.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.248.134] by mail.gmx.net (mp070) with SMTP; 01 Apr 2009 10:52:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+yElZDusqykvjBnbxNvo1HEgFPagaRKevkNt/ehK 8Z93Pd2mRMwCrh Message-ID: <49D32B3F.8080108@gmx.de> Date: Wed, 01 Apr 2009 10:52:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Subject: Re: Generic URI syntax incompatible with IPv6 addresses in SIP URIs References: <167dfb9b0903290605m606a0ee8v13f1afede2d1c8f3@mail.gmail.com> <49D285A6.6060104@gmx.de> <49D3271D.2040203@it.aoyama.ac.jp> In-Reply-To: <49D3271D.2040203@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: public-iri@w3.org, Mark Baker , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:51:34 -0000 Martin J. Dürst wrote: > I agree with Julian that discussion about updates of RFC 3987 (IRI spec, > new version currently at draft-duerst-iri-bis-05) should go to > public-iri@w3.org, whereas bug reports and discussions about RFC 3986 > (URI spec) should go to uri@w3.org. > > But Lisa, you are the AD who eventually has to handle anything that > comes out of these drafts, so I'm glad to follow your directions. > > Julian, could you be more specific (pointer is sufficient) about what > you mean below with "potential issue (normalization)"? > > Regards, Martin. It's the one raised by Anne vK: Section 3.1 requires different IRI->URI behavior depending on the encoding of the source document: Step 1. Generate a UCS character sequence from the original IRI format. This step has the following three variants, depending on the form of the input: a. If the IRI is written on paper, read aloud, or otherwise represented as a sequence of characters independent of any character encoding, represent the IRI as a sequence of characters from the UCS normalized according to Normalization Form C (NFC, [UTR15]). b. If the IRI is in some digital representation (e.g., an octet stream) in some known non-Unicode character encoding, convert the IRI to a sequence of characters from the UCS normalized according to NFC. c. If the IRI is in a Unicode-based character encoding (for example, UTF-8 or UTF-16), do not normalize (see section 5.3.2.2 for details). Apply step 2 directly to the encoded Unicode character sequence. It would be helpful to understand where exactly this requirement comes from, and whether we have evidence it's being implemented (or even implementable; the source document encoding may not be known at the moment where the URI->IRI conversion occurs). BR, Julian From bortzmeyer@nic.fr Wed Apr 1 01:52:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58483A684A for ; Wed, 1 Apr 2009 01:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.013 X-Spam-Level: X-Spam-Status: No, score=-4.013 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lO3UiJbfc8g for ; Wed, 1 Apr 2009 01:52:25 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id EA6D73A67A7 for ; Wed, 1 Apr 2009 01:52:24 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5FA531C0179; Wed, 1 Apr 2009 10:48:23 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 5B10C1C0102; Wed, 1 Apr 2009 10:48:23 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 59167A1D9AE; Wed, 1 Apr 2009 10:48:23 +0200 (CEST) Date: Wed, 1 Apr 2009 10:48:23 +0200 From: Stephane Bortzmeyer To: zhangguoqiang Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <20090401084823.GA20305@nic.fr> References: <200904011116363933242@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904011116363933242@cnnic.cn> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: YAO Jiankang , apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:52:25 -0000 On Wed, Apr 01, 2009 at 11:16:36AM +0800, zhangguoqiang wrote a message of 156 lines which said: > Different from search engines, keyword-based addressing is an > addressing technology. Based on whether a keyword is registered or > not, the resolution result is determinstic for any given keyword, Then it will have all the problems of the domain names, including bureaucratic registration rules, UDRP, lawyers, ICANN, etc. > For example, if you are a blogger of a portal blog website, > typically, you are assigned a URL that identifies your blog. It is > usually composed of two parts: a domain name and an ID(typically a > magic number). So how can you advertise your blog to your friends? tinyurl.com But it is simpler to buy a domain name and redirect. > So, we think keyword-based addressing is a very useful technique, > especially for non-english speaking countries. Even for english > speaking countries, the above example also illustrates its > practicability. To internationalize this service and provide cross > resolution capability, we highly recommend a standard being > developped. I'm very skeptical but I'll read your draft. > Our keyword-based addressing draft is available at > http://tools.ietf.org/html/draft-zhang-keyword-ddds-00, which > specifies keyword-based addressing as a DDDS application. You apparently do not mention RFC 2345 (keywords are a very old idea which keep popping up from time to time). From zhangguoqiang@cnnic.cn Wed Apr 1 01:54:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD683A698C for ; Wed, 1 Apr 2009 01:54:27 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.506 X-Spam-Level: ** X-Spam-Status: No, score=2.506 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjSKqF7WTj8s for ; Wed, 1 Apr 2009 01:54:26 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id CEDB93A67A7 for ; Wed, 1 Apr 2009 01:54:25 -0700 (PDT) Received: (eyou send program); Wed, 01 Apr 2009 16:55:25 +0800 Message-ID: <438576125.12366@cnnic.cn> X-EYOUMAIL-SMTPAUTH: zhangguoqiang@cnnic.cn Received: from unknown (HELO cnnic-eae3fdf20) (218.241.111.8) by 159.226.7.146 with SMTP; Wed, 01 Apr 2009 16:55:25 +0800 Date: Wed, 1 Apr 2009 16:55:24 +0800 From: "zhangguoqiang" To: "Stephane Bortzmeyer" References: <200904011116363933242@cnnic.cn>, <438575712.22018@cnnic.cn> Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <200904011655238597895@cnnic.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon775424217660_=====" Cc: YAO Jiankang , apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:54:27 -0000 This is a multi-part message in MIME format. --=====001_Dragon775424217660_===== Content-Type: multipart/alternative; boundary="=====003_Dragon775424217660_=====" --=====003_Dragon775424217660_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIGRpc3B1dGUgaXMgaW5ldml0YWJsZS4gQnV0IHBvbGljeSBpc3N1ZXMgZG9uJ3QgcHJldmVu dCBkb21haW4gbmFtZXMgZnJvbSBiZWluZyB3aWRlbHkgdXNlZCwgYW5kIGl0IHNob3VsZCBub3Qg cHJldmVudCBrZXl3b3JkIGFzIHdlbGwuICANCg0KDQoyMDA5LTA0LTAxIA0KDQoNCg0Kemhhbmdn dW9xaWFuZyANCg0KDQoNCreivP7Iy6O6IFN0ZXBoYW5lIEJvcnR6bWV5ZXIgDQq3osvNyrG85KO6 IDIwMDktMDQtMDEgIDE2OjQ4OjMyIA0KytW8/sjLo7ogemhhbmdndW9xaWFuZyANCrOty82juiBh cHBzLWRpc2N1c3M7IFlBTyBKaWFua2FuZyANCtb3zOKjuiBSZTogU29saWNpdGF0aW9uIGZvciBh IGRpc2N1c3Npb24gb24gS2V5d29yZC1iYXNlZCBhZGRyZXNzaW5nIA0KIA0KT24gV2VkLCBBcHIg MDEsIDIwMDkgYXQgMTE6MTY6MzZBTSArMDgwMCwNCiB6aGFuZ2d1b3FpYW5nICA8emhhbmdndW9x aWFuZ0Bjbm5pYy5jbiA+IHdyb3RlIA0KIGEgbWVzc2FnZSBvZiAxNTYgbGluZXMgd2hpY2ggc2Fp ZDoNCg0KPiBEaWZmZXJlbnQgZnJvbSBzZWFyY2ggZW5naW5lcywga2V5d29yZC1iYXNlZCBhZGRy ZXNzaW5nIGlzIGFuDQo+IGFkZHJlc3NpbmcgdGVjaG5vbG9neS4gQmFzZWQgb24gd2hldGhlciBh IGtleXdvcmQgaXMgcmVnaXN0ZXJlZCBvcg0KPiBub3QsIHRoZSByZXNvbHV0aW9uIHJlc3VsdCBp cyBkZXRlcm1pbnN0aWMgZm9yIGFueSBnaXZlbiBrZXl3b3JkLCANCg0KVGhlbiBpdCB3aWxsIGhh dmUgYWxsIHRoZSBwcm9ibGVtcyBvZiB0aGUgZG9tYWluIG5hbWVzLCBpbmNsdWRpbmcNCmJ1cmVh dWNyYXRpYyByZWdpc3RyYXRpb24gcnVsZXMsIFVEUlAsIGxhd3llcnMsIElDQU5OLCBldGMuDQoN Cj4gRm9yIGV4YW1wbGUsIGlmIHlvdSBhcmUgYSBibG9nZ2VyIG9mIGEgcG9ydGFsIGJsb2cgd2Vi c2l0ZSwNCj4gdHlwaWNhbGx5LCB5b3UgYXJlIGFzc2lnbmVkIGEgVVJMIHRoYXQgaWRlbnRpZmll cyB5b3VyIGJsb2cuIEl0IGlzDQo+IHVzdWFsbHkgY29tcG9zZWQgb2YgdHdvIHBhcnRzOiBhIGRv bWFpbiBuYW1lIGFuZCBhbiBJRCh0eXBpY2FsbHkgYQ0KPiBtYWdpYyBudW1iZXIpLiBTbyBob3cg Y2FuIHlvdSBhZHZlcnRpc2UgeW91ciBibG9nIHRvIHlvdXIgZnJpZW5kcz8gDQoNCnRpbnl1cmwu Y29tDQoNCkJ1dCBpdCBpcyBzaW1wbGVyIHRvIGJ1eSBhIGRvbWFpbiBuYW1lIGFuZCByZWRpcmVj dC4NCg0KPiBTbywgd2UgdGhpbmsga2V5d29yZC1iYXNlZCBhZGRyZXNzaW5nIGlzIGEgdmVyeSB1 c2VmdWwgdGVjaG5pcXVlLA0KPiBlc3BlY2lhbGx5IGZvciBub24tZW5nbGlzaCBzcGVha2luZyBj b3VudHJpZXMuIEV2ZW4gZm9yIGVuZ2xpc2gNCj4gc3BlYWtpbmcgY291bnRyaWVzLCB0aGUgYWJv dmUgZXhhbXBsZSBhbHNvIGlsbHVzdHJhdGVzIGl0cw0KPiBwcmFjdGljYWJpbGl0eS4gVG8gaW50 ZXJuYXRpb25hbGl6ZSB0aGlzIHNlcnZpY2UgYW5kIHByb3ZpZGUgY3Jvc3MNCj4gcmVzb2x1dGlv biBjYXBhYmlsaXR5LCB3ZSBoaWdobHkgcmVjb21tZW5kIGEgc3RhbmRhcmQgYmVpbmcNCj4gZGV2 ZWxvcHBlZC4gDQoNCkknbSB2ZXJ5IHNrZXB0aWNhbCBidXQgSSdsbCByZWFkIHlvdXIgZHJhZnQu DQoNCj4gT3VyIGtleXdvcmQtYmFzZWQgYWRkcmVzc2luZyBkcmFmdCBpcyBhdmFpbGFibGUgYXQN Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmcta2V5d29yZC1kZGRzLTAw LCB3aGljaA0KPiBzcGVjaWZpZXMga2V5d29yZC1iYXNlZCBhZGRyZXNzaW5nIGFzIGEgREREUyBh cHBsaWNhdGlvbi4NCg0KWW91IGFwcGFyZW50bHkgZG8gbm90IG1lbnRpb24gUkZDIDIzNDUgKGtl eXdvcmRzIGFyZSBhIHZlcnkgb2xkIGlkZWENCndoaWNoIGtlZXAgcG9wcGluZyB1cCBmcm9tIHRp bWUgdG8gdGltZSkuDQo= --=====003_Dragon775424217660_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjU3MjYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+VGhlIGRpc3B1dGUgaXMgaW5ldml0 YWJsZS4gDQpCdXQmbmJzcDtwb2xpY3kgaXNzdWVzJm5ic3A7ZG9uJ3QgcHJldmVudCBkb21haW4g bmFtZXMgZnJvbSBiZWluZyB3aWRlbHkgdXNlZCwgDQphbmQgaXQgc2hvdWxkIG5vdCBwcmV2ZW50 IGtleXdvcmQgYXMgd2VsbC4gJm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+MjAwOS0wNC0wMSA8 L0ZPTlQ+PC9ESVY+PEZPTlQgDQpmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8 SFIgc3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIGFsaWduPWxlZnQgU0laRT0yPg0K PC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+PFNQ QU4+emhhbmdndW9xaWFuZzwvU1BBTj4gDQo8L0ZPTlQ+PC9ESVY+PEZPTlQgZmFjZT1WZXJkYW5h IGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSPg0KPC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgc2l6ZT0yPjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gU3RlcGhhbmUgQm9ydHptZXll ciANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05H Preiy83Ksbzko7o8L1NUUk9ORz4gMjAwOS0wNC0wMSZuYnNwOyAxNjo0ODozMiANCjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9T VFJPTkc+IHpoYW5nZ3VvcWlhbmcgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRh bmEgc2l6ZT0yPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IGFwcHMtZGlzY3VzczsgWUFPIEppYW5r YW5nIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJP Tkc+1vfM4qO6PC9TVFJPTkc+IFJlOiBTb2xpY2l0YXRpb24gZm9yIGEgDQpkaXNjdXNzaW9uIG9u IEtleXdvcmQtYmFzZWQgYWRkcmVzc2luZyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 VmVyZGFuYSBzaXplPTI+PC9GT05UPiA8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNp emU9Mj4NCjxESVY+T24mbmJzcDtXZWQsJm5ic3A7QXByJm5ic3A7MDEsJm5ic3A7MjAwOSZuYnNw O2F0Jm5ic3A7MTE6MTY6MzZBTSZuYnNwOyswODAwLDwvRElWPg0KPERJVj4mbmJzcDt6aGFuZ2d1 b3FpYW5nJm5ic3A7ICZsdDt6aGFuZ2d1b3FpYW5nQGNubmljLmNuIA0KJmd0OyZuYnNwO3dyb3Rl Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwO2EmbmJzcDttZXNzYWdlJm5ic3A7b2YmbmJzcDsxNTYm bmJzcDtsaW5lcyZuYnNwO3doaWNoJm5ic3A7c2FpZDo8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPiZndDsmbmJzcDtEaWZmZXJlbnQmbmJzcDtmcm9tJm5ic3A7c2VhcmNoJm5ic3A7ZW5n aW5lcywmbmJzcDtrZXl3b3JkLWJhc2VkJm5ic3A7YWRkcmVzc2luZyZuYnNwO2lzJm5ic3A7YW48 L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2FkZHJlc3NpbmcmbmJzcDt0ZWNobm9sb2d5LiZuYnNwO0Jh c2VkJm5ic3A7b24mbmJzcDt3aGV0aGVyJm5ic3A7YSZuYnNwO2tleXdvcmQmbmJzcDtpcyZuYnNw O3JlZ2lzdGVyZWQmbmJzcDtvcjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bm90LCZuYnNwO3RoZSZu YnNwO3Jlc29sdXRpb24mbmJzcDtyZXN1bHQmbmJzcDtpcyZuYnNwO2RldGVybWluc3RpYyZuYnNw O2ZvciZuYnNwO2FueSZuYnNwO2dpdmVuJm5ic3A7a2V5d29yZCwmbmJzcDs8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPlRoZW4mbmJzcDtpdCZuYnNwO3dpbGwmbmJzcDtoYXZlJm5ic3A7 YWxsJm5ic3A7dGhlJm5ic3A7cHJvYmxlbXMmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2RvbWFpbiZu YnNwO25hbWVzLCZuYnNwO2luY2x1ZGluZzwvRElWPg0KPERJVj5idXJlYXVjcmF0aWMmbmJzcDty ZWdpc3RyYXRpb24mbmJzcDtydWxlcywmbmJzcDtVRFJQLCZuYnNwO2xhd3llcnMsJm5ic3A7SUNB Tk4sJm5ic3A7ZXRjLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0Zv ciZuYnNwO2V4YW1wbGUsJm5ic3A7aWYmbmJzcDt5b3UmbmJzcDthcmUmbmJzcDthJm5ic3A7Ymxv Z2dlciZuYnNwO29mJm5ic3A7YSZuYnNwO3BvcnRhbCZuYnNwO2Jsb2cmbmJzcDt3ZWJzaXRlLDwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7dHlwaWNhbGx5LCZuYnNwO3lvdSZuYnNwO2FyZSZuYnNwO2Fz c2lnbmVkJm5ic3A7YSZuYnNwO1VSTCZuYnNwO3RoYXQmbmJzcDtpZGVudGlmaWVzJm5ic3A7eW91 ciZuYnNwO2Jsb2cuJm5ic3A7SXQmbmJzcDtpczwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dXN1YWxs eSZuYnNwO2NvbXBvc2VkJm5ic3A7b2YmbmJzcDt0d28mbmJzcDtwYXJ0czombmJzcDthJm5ic3A7 ZG9tYWluJm5ic3A7bmFtZSZuYnNwO2FuZCZuYnNwO2FuJm5ic3A7SUQodHlwaWNhbGx5Jm5ic3A7 YTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bWFnaWMmbmJzcDtudW1iZXIpLiZuYnNwO1NvJm5ic3A7 aG93Jm5ic3A7Y2FuJm5ic3A7eW91Jm5ic3A7YWR2ZXJ0aXNlJm5ic3A7eW91ciZuYnNwO2Jsb2cm bmJzcDt0byZuYnNwO3lvdXImbmJzcDtmcmllbmRzPyZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+dGlueXVybC5jb208L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJ1 dCZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtzaW1wbGVyJm5ic3A7dG8mbmJzcDtidXkmbmJzcDthJm5i c3A7ZG9tYWluJm5ic3A7bmFtZSZuYnNwO2FuZCZuYnNwO3JlZGlyZWN0LjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1NvLCZuYnNwO3dlJm5ic3A7dGhpbmsmbmJzcDtr ZXl3b3JkLWJhc2VkJm5ic3A7YWRkcmVzc2luZyZuYnNwO2lzJm5ic3A7YSZuYnNwO3ZlcnkmbmJz cDt1c2VmdWwmbmJzcDt0ZWNobmlxdWUsPC9ESVY+DQo8RElWPiZndDsmbmJzcDtlc3BlY2lhbGx5 Jm5ic3A7Zm9yJm5ic3A7bm9uLWVuZ2xpc2gmbmJzcDtzcGVha2luZyZuYnNwO2NvdW50cmllcy4m bmJzcDtFdmVuJm5ic3A7Zm9yJm5ic3A7ZW5nbGlzaDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7c3Bl YWtpbmcmbmJzcDtjb3VudHJpZXMsJm5ic3A7dGhlJm5ic3A7YWJvdmUmbmJzcDtleGFtcGxlJm5i c3A7YWxzbyZuYnNwO2lsbHVzdHJhdGVzJm5ic3A7aXRzPC9ESVY+DQo8RElWPiZndDsmbmJzcDtw cmFjdGljYWJpbGl0eS4mbmJzcDtUbyZuYnNwO2ludGVybmF0aW9uYWxpemUmbmJzcDt0aGlzJm5i c3A7c2VydmljZSZuYnNwO2FuZCZuYnNwO3Byb3ZpZGUmbmJzcDtjcm9zczwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7cmVzb2x1dGlvbiZuYnNwO2NhcGFiaWxpdHksJm5ic3A7d2UmbmJzcDtoaWdobHkm bmJzcDtyZWNvbW1lbmQmbmJzcDthJm5ic3A7c3RhbmRhcmQmbmJzcDtiZWluZzwvRElWPg0KPERJ Vj4mZ3Q7Jm5ic3A7ZGV2ZWxvcHBlZC4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPkknbSZuYnNwO3ZlcnkmbmJzcDtza2VwdGljYWwmbmJzcDtidXQmbmJzcDtJJ2xsJm5ic3A7 cmVhZCZuYnNwO3lvdXImbmJzcDtkcmFmdC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZndDsmbmJzcDtPdXImbmJzcDtrZXl3b3JkLWJhc2VkJm5ic3A7YWRkcmVzc2luZyZuYnNwO2Ry YWZ0Jm5ic3A7aXMmbmJzcDthdmFpbGFibGUmbmJzcDthdDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 PEEgDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1rZXl3b3Jk LWRkZHMtMDAsJm5ic3A7d2hpY2giPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpo YW5nLWtleXdvcmQtZGRkcy0wMCwmbmJzcDt3aGljaDwvQT48L0RJVj4NCjxESVY+Jmd0OyZuYnNw O3NwZWNpZmllcyZuYnNwO2tleXdvcmQtYmFzZWQmbmJzcDthZGRyZXNzaW5nJm5ic3A7YXMmbmJz cDthJm5ic3A7REREUyZuYnNwO2FwcGxpY2F0aW9uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+WW91Jm5ic3A7YXBwYXJlbnRseSZuYnNwO2RvJm5ic3A7bm90Jm5ic3A7bWVudGlvbiZu YnNwO1JGQyZuYnNwOzIzNDUmbmJzcDsoa2V5d29yZHMmbmJzcDthcmUmbmJzcDthJm5ic3A7dmVy eSZuYnNwO29sZCZuYnNwO2lkZWE8L0RJVj4NCjxESVY+d2hpY2gmbmJzcDtrZWVwJm5ic3A7cG9w cGluZyZuYnNwO3VwJm5ic3A7ZnJvbSZuYnNwO3RpbWUmbmJzcDt0byZuYnNwO3RpbWUpLjwvRElW PjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon775424217660_=====-- --=====001_Dragon775424217660_===== Content-Type: text/x-vcard; name="=?gb2312?B?1cW5+se/KDEpLnZjZg==?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?gb2312?B?1cW5+se/KDEpLnZjZg==?=" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOtXFO7n6x78NCkZOOtXFufrHvw0KT1JHOkNOTklD O0xhYnMNClRFTDtXT1JLO1ZPSUNFOjAxMC01ODgxMzAzOA0KVEVMO1dPUks7Vk9JQ0U6MTM0Mzkx NDA0NzkNCkFEUjtXT1JLOjs7OztCZWlqaW5nOztDaGluYQ0KTEFCRUw7V09SSztFTkNPRElORz1R VU9URUQtUFJJTlRBQkxFOg0KDQpCZWlqaW5nDQoNCkNoaW5hDQpFTUFJTDtQUkVGO0lOVEVSTkVU OnpoYW5nZ3VvcWlhbmdAY25uaWMuY24NClJFVjoyMDA5MDQwMVQxNjU1MjNaDQpFTkQ6VkNBUkQN Cg== --=====001_Dragon775424217660_=====-- From lear@cisco.com Wed Apr 1 02:35:53 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443B73A6997 for ; Wed, 1 Apr 2009 02:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.721 X-Spam-Level: X-Spam-Status: No, score=-9.721 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrFuc88WeyAn for ; Wed, 1 Apr 2009 02:35:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CAFBC3A690B for ; Wed, 1 Apr 2009 02:35:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208";a="37185635" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2009 09:36:50 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n319ao1c014309; Wed, 1 Apr 2009 11:36:50 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp1583.cisco.com [10.61.70.47]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n319anae021930; Wed, 1 Apr 2009 09:36:50 GMT Message-ID: <49D335B1.8030808@cisco.com> Date: Wed, 01 Apr 2009 11:36:49 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090331 Shredder/3.0b3pre MIME-Version: 1.0 To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> In-Reply-To: <49D28280.3080406@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1929; t=1238578610; x=1239442610; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20supposing=20one=20would=20want=09to=09c reate=09a=09new=09URN=09space=09for=09timezones... |Sender:=20; bh=bdSlGqwCfruAYh0lYUfSQKqsXerAXWNGuwHXvm6sY40=; b=ZFS8SCOKrIGVT3MZHIZqTI37MLerpRv3Mu65LpglxcgqQJDUqNBN3ylBLb gJ4YnNQFBFNNJfQSMCp/FiTtCg8FCcNV3uN5M0hWK9klgpeFRyKj5XfYKwAr /+ApzAE1nK; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Apps Discuss , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 09:35:53 -0000 On 3/31/09 10:52 PM, Keith Moore wrote: > To respond to Eliot's comment, I don't think we're going to tell > publishers what keys to use, or more generally, how to help users select > default timezones or timezones for events. That's a UI concern. What we > might be able to do is to define standard timezone names to aid in > interoperability between different iCalendar implementations using data > supplied by different publishers. > This assumes two things: first that there is a problem that requires fixing. Why do you believe that there is? The Olson database for over two decades. It's free and it's well managed. Second, if there is a need for standard timezone names, who is going to manage the mapping between them and what the publishers put out? I see no reason why anyone would want to do the job unless there is a REAL problem. Here is the problem I want to solve: a standard form for a name that includes publisher and the pubisher's (preferrably human readable) index for a given location. Second, if we feel we need to approve of the use of one publisher, we say that separately, and allow for the possibility that it might change in the future. > Timezones are defined by political entities (mostly countries). We > should define our timezone names in terms of those entities, and > standard abbreviations for those entities. e.g. ISO 3166 country > codes. Within a country, we should use accepted names or abbreviations > for timezones if those exist and if they're independent of > "daylight/summer time" conventions. Where local conventions deviate > from national ones, we will need to decide on an ad-hoc basis. > Why? Why should we deal with the fact that all of western Europe is in one timezone (CE[S]T) while Indiana has counties that have distinct timezones, especially when others are already doing a good job at it? Eliot From lear@cisco.com Wed Apr 1 04:00:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042573A6A98 for ; Wed, 1 Apr 2009 04:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.744 X-Spam-Level: X-Spam-Status: No, score=-7.744 tagged_above=-999 required=5 tests=[AWL=-1.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma6tFbkMiyNx for ; Wed, 1 Apr 2009 04:00:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 060633A69B4 for ; Wed, 1 Apr 2009 04:00:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,306,1235952000"; d="scan'208";a="164864950" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2009 11:01:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n31B1kt0032138; Wed, 1 Apr 2009 13:01:46 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp1583.cisco.com [10.61.70.47]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n31B1kZI003669; Wed, 1 Apr 2009 11:01:46 GMT Message-ID: <49D34999.9000303@cisco.com> Date: Wed, 01 Apr 2009 13:01:45 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090331 Shredder/3.0b3pre MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> <49D1289A.4070803@cisco.com> <20090331223318.GU9992@Sun.COM> <20090331230639.GX9992@Sun.COM> In-Reply-To: <20090331230639.GX9992@Sun.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=479; t=1238583706; x=1239447706; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20supposing=20one=20would=09want=09to=09c reate=09a=09new=09URN=09space=09for=09timezones... |Sender:=20; bh=FZPs+6OwKzYv44Wj3PN0alCoWhl2rc0j3AV/0Fwd/88=; b=kHV4lcVzfuJ3puHQ57AltrhgCu+Mcc7AXPCj8xt64TTVFmCo49tYmY7wBw uphy4RaJ+FLaszZI4yg0abADqqLkXbxMUocZpEisvxKXbVOVc7xLzF52eY1P NKXVSY8EFE; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Apps Discuss , Keith Moore X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 11:00:49 -0000 On 4/1/09 1:06 AM, Nicolas Williams wrote: > Great. How does one "refer to the same timezone definitions"? Where > are those? I don't see how to escape the need for a registry. Sorry. > There is a registry. It's existed for quite a long time, Nico. In fact there are several (which is the problem). Creating ANOTHER one and creating alot more work will not make things better, and will serve to only annoy those who currently do a very good job. Eliot From moore@network-heretics.com Wed Apr 1 06:26:53 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20ED63A6C65 for ; Wed, 1 Apr 2009 06:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSBIAYA5RGdR for ; Wed, 1 Apr 2009 06:26:52 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 4600D3A6B75 for ; Wed, 1 Apr 2009 06:26:52 -0700 (PDT) Received: from lust.indecency.org (173-6-132-16.pools.spcsdns.net [173.6.132.16] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMG69704 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 06:27:46 -0700 (PDT) Message-ID: <49D36BCF.9090204@network-heretics.com> Date: Wed, 01 Apr 2009 09:27:43 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <49D335B1.8030808@cisco.com> In-Reply-To: <49D335B1.8030808@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 13:26:53 -0000 Eliot Lear wrote: > On 3/31/09 10:52 PM, Keith Moore wrote: >> To respond to Eliot's comment, I don't think we're going to tell >> publishers what keys to use, or more generally, how to help users select >> default timezones or timezones for events. That's a UI concern. What we >> might be able to do is to define standard timezone names to aid in >> interoperability between different iCalendar implementations using data >> supplied by different publishers. >> > > This assumes two things: first that there is a problem that requires > fixing. Why do you believe that there is? The Olson database for over > two decades. It's free and it's well managed. > > Second, if there is a need for standard timezone names, who is going to > manage the mapping between them and what the publishers put out? I see > no reason why anyone would want to do the job unless there is a REAL > problem. The problem that I think exists is that event descriptions now must, as a practical matter, include reasonably complete descriptions of the event's timezone. And if the timezone definition changes between the time the event description is created and the event itself, the event description becomes wrong. Really, what's being done now is only marginally better than sending GMT offset (and even then only for recurring events that cross a "summer time" change boundary), because the indication of the timezone that is sent is neither portable between iCalendar implementations nor is there any way of mapping it to a current timezone definition. > Here is the problem I want to solve: a standard form for a name that > includes publisher and the pubisher's (preferrably human readable) index > for a given location. Second, if we feel we need to approve of the use > of one publisher, we say that separately, and allow for the possibility > that it might change in the future. I think it harms interoperability for the name to be specific to a particular publisher, and I don't think IETF wants to be in the position of naming any specific publisher. > >> Timezones are defined by political entities (mostly countries). We >> should define our timezone names in terms of those entities, and >> standard abbreviations for those entities. e.g. ISO 3166 country >> codes. Within a country, we should use accepted names or abbreviations >> for timezones if those exist and if they're independent of >> "daylight/summer time" conventions. Where local conventions deviate >> from national ones, we will need to decide on an ad-hoc basis. >> > > Why? Why should we deal with the fact that all of western Europe is in > one timezone (CE[S]T) while Indiana has counties that have distinct > timezones, especially when others are already doing a good job at it? Others are not doing a good job at naming timezones. They're doing a really poor job of it, IMHO, by encouraging use of cities as timezone names. Keith From moore@network-heretics.com Wed Apr 1 06:29:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD733A688F for ; Wed, 1 Apr 2009 06:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+64n4Cy09FR for ; Wed, 1 Apr 2009 06:29:27 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 4AE063A67F4 for ; Wed, 1 Apr 2009 06:29:27 -0700 (PDT) Received: from lust.indecency.org (173-6-132-16.pools.spcsdns.net [173.6.132.16] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMG69976 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 06:30:03 -0700 (PDT) Message-ID: <49D36C58.8020306@network-heretics.com> Date: Wed, 01 Apr 2009 09:30:00 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> <49D1289A.4070803@cisco.com> <20090331223318.GU9992@Sun.COM> <20090331230639.GX9992@Sun.COM> <49D34999.9000303@cisco.com> In-Reply-To: <49D34999.9000303@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 13:29:27 -0000 Eliot Lear wrote: > On 4/1/09 1:06 AM, Nicolas Williams wrote: >> Great. How does one "refer to the same timezone definitions"? Where >> are those? I don't see how to escape the need for a registry. Sorry. >> > > There is a registry. It's existed for quite a long time, Nico. In fact > there are several (which is the problem). Creating ANOTHER one and > creating alot more work will not make things better, and will serve to > only annoy those who currently do a very good job. They're doing a very good job of describing timezones and their changes over time. That's not the same thing as doing a good job at naming timezones in such a way that those names can be used by multiple publishers, or multiple software vendors using a variety of publishers. From cyrus@daboo.name Wed Apr 1 06:53:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881863A6801 for ; Wed, 1 Apr 2009 06:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwkcTBCY-WGg for ; Wed, 1 Apr 2009 06:53:13 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 5A8553A6BA4 for ; Wed, 1 Apr 2009 06:52:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7C122132449F; Wed, 1 Apr 2009 09:53:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE39yZE5Y3J9; Wed, 1 Apr 2009 09:53:43 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 690551324498; Wed, 1 Apr 2009 09:53:41 -0400 (EDT) Date: Wed, 01 Apr 2009 09:53:38 -0400 From: Cyrus Daboo To: Keith Moore , Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: In-Reply-To: <49D36BCF.9090204@network-heretics.com> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <49D335B1.8030808@cisco.com> <49D36BCF.9090204@network-heretics.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2387 Cc: Apps Discuss , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 13:53:15 -0000 Hi Keith, --On April 1, 2009 9:27:43 AM -0400 Keith Moore wrote: >> Second, if there is a need for standard timezone names, who is going to >> manage the mapping between them and what the publishers put out? I see >> no reason why anyone would want to do the job unless there is a REAL >> problem. > > The problem that I think exists is that event descriptions now must, as > a practical matter, include reasonably complete descriptions of the > event's timezone. And if the timezone definition changes between the > time the event description is created and the event itself, the event > description becomes wrong. > > Really, what's being done now is only marginally better than sending GMT > offset (and even then only for recurring events that cross a "summer > time" change boundary), because the indication of the timezone that is > sent is neither portable between iCalendar implementations nor is there > any way of mapping it to a current timezone definition. So technically there should not be a problem with timezones in iCalendar because iCalendar requires that timezones be passed by value - i.e. the VTIMEZONE component included in the VCALENDAR object that references a timezone. If implementations strictly interpreted that behavior they would use the VTIMEZONEs supplied in an iCalendar object to calculate UTC and Organizer and Attendees would arrive at the same value. The problem comes in that each implementation typically has its own timezone database and they prefer to throw away incoming timezones in favor of their own definitions. Since those databases can get out of sync (or may be completely different and require some form of fuzzy matching between timezone ids), Organizers and Attendees can end up with different UTC times for the same event - bad news! So, again, one of the key reasons to do this work is to recognize the fact that implementations are really treating timezone exchanges as "by reference" rather than "by value" (i.e. they discard the supplied VTIMEZONE data in favor of their own that matches the TZID). In order for that to work there must be agreement on the timezone identifiers and a standard timezone service that allows clients to keep their databases up to date via regular updates. If we do these two things we solve the biggest problem that exists today. -- Cyrus Daboo From fanf2@hermes.cam.ac.uk Wed Apr 1 07:58:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5813A6A1C for ; Wed, 1 Apr 2009 07:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWFYat1AvA0W for ; Wed, 1 Apr 2009 07:58:21 -0700 (PDT) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by core3.amsl.com (Postfix) with ESMTP id 40BC33A698A for ; Wed, 1 Apr 2009 07:58:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59979) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Lp1uR-0006iA-Pc (Exim 4.70) (return-path ); Wed, 01 Apr 2009 15:59:19 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Lp1uR-00038P-Tn (Exim 4.67) (return-path ); Wed, 01 Apr 2009 15:59:19 +0100 Date: Wed, 1 Apr 2009 15:59:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... In-Reply-To: <49D294FA.7080501@network-heretics.com> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Apps Discuss , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:58:22 -0000 On Tue, 31 Mar 2009, Keith Moore wrote: > > Heck, if it would help get consensus (and avoid arguing about local > names), I'd even accept the default (non summer-time) GMT offset as part > of the name for areas within countries that adopted the normal rules for > that country. Australia's DST rules vary between the states. > > IMO this sort of issue is best left to international standards > > development organizations with national representation (think ISO), not > > the IETF. That would exclude informal timezones. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From moore@cs.utk.edu Wed Apr 1 08:07:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A2E28C1C3 for ; Wed, 1 Apr 2009 08:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OovKDK6Zseqy for ; Wed, 1 Apr 2009 08:07:34 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id EC38A28C144 for ; Wed, 1 Apr 2009 08:07:34 -0700 (PDT) Received: from lust.indecency.org (173-6-132-16.pools.spcsdns.net [173.6.132.16] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMG81191 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 08:08:27 -0700 (PDT) Message-ID: <49D38368.8050300@cs.utk.edu> Date: Wed, 01 Apr 2009 11:08:24 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=E1473978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:07:35 -0000 Tony Finch wrote: 
On Tue, 31 Mar 2009, Keith Moore wrote:

Heck, if it would help get consensus (and avoid arguing about local
names), I'd even accept the default (non summer-time) GMT offset as part
of the name for areas within countries that adopted the normal rules for
that country.
Australia's DST rules vary between the states.
I don't think it's possible to make a naming scheme that's so general that it covers every case.  but a general naming scheme might reduce the number of things that people want to argue about.

Still, this might mean that rather than having, say, an IETF WG try to define names for every major timezone, it makes more sense to (a) set up a registry and a review process, (b) make some recommendations for the format of timezone names that serve as guidelines to the reviewers, and (c) invite interested parties to submit registrations.

Keith

From fanf2@hermes.cam.ac.uk Wed Apr 1 08:11:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638E03A687C for ; Wed, 1 Apr 2009 08:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QADsNxC4Fod3 for ; Wed, 1 Apr 2009 08:11:27 -0700 (PDT) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by core3.amsl.com (Postfix) with ESMTP id 3F0C73A6949 for ; Wed, 1 Apr 2009 08:11:27 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47358) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1Lp277-00017X-3b (Exim 4.70) (return-path ); Wed, 01 Apr 2009 16:12:25 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Lp277-0004rL-3E (Exim 4.67) (return-path ); Wed, 01 Apr 2009 16:12:25 +0100 Date: Wed, 1 Apr 2009 16:12:25 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... In-Reply-To: <49D38368.8050300@cs.utk.edu> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Apps Discuss , Keith Moore , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:11:28 -0000 On Wed, 1 Apr 2009, Keith Moore wrote: > > Still, this might mean that rather than having, say, an IETF WG try to > define names for every major timezone, it makes more sense to (a) set up > a registry and a review process, (b) make some recommendations for the > format of timezone names that serve as guidelines to the reviewers, and > (c) invite interested parties to submit registrations. You just described exactly what Olson's tz list does. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From lear@cisco.com Wed Apr 1 08:43:01 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FC383A6821 for ; Wed, 1 Apr 2009 08:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqRFTzPj-eoU for ; Wed, 1 Apr 2009 08:43:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5C53A3A67F7 for ; Wed, 1 Apr 2009 08:43:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="40708063" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Apr 2009 15:44:00 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n31Fi0cS007037; Wed, 1 Apr 2009 11:44:00 -0400 Received: from adsl-247-4-fixip.tiscali.ch ([10.86.252.181]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n31Fhw1c029480; Wed, 1 Apr 2009 15:43:59 GMT Message-ID: <49D38BBE.6080308@cisco.com> Date: Wed, 01 Apr 2009 17:43:58 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090331 Shredder/3.0b3pre MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=421; t=1238600640; x=1239464640; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20supposing=20one=20would=09want=09to=09c reate=09a=09new=09URN=09space=09for=20timezones... |Sender:=20 |To:=20Tony=20Finch=20; bh=XV/5HjKn1IcPJCzEhvKLu/2h49TWGIkQefc9ZL2hQ+g=; b=GiXiMh75WQMEe1HyTpObyaLuSSIJxI3QF4Aq87rt16+W91eFT6SDR1Eo9a ZtGo1Gr+B+bA66Rq9dH+lt5jSO/3t0c8bfL+xgK1tSnoLc3pbR8RMLZCz3fm pGzEiFhJWO; Authentication-Results: rtp-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Apps Discuss , Keith Moore , Keith Moore , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:43:01 -0000 On 4/1/09 5:12 PM, Tony Finch wrote: > You just described exactly what Olson's tz list does. > Precisely so. The only issue is this: what is the succession plan for the distribution? What happens on the off chance it implodes? And perhaps Cyrus and Barry are implicitly correct in the draft that we should make this tomorrow's problem, and not today's if this conversation is any indicator. Eliot From fanf2@hermes.cam.ac.uk Wed Apr 1 09:15:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA213A6A98 for ; Wed, 1 Apr 2009 09:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bgEaNlJfIPw for ; Wed, 1 Apr 2009 09:15:18 -0700 (PDT) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by core3.amsl.com (Postfix) with ESMTP id E568C3A6949 for ; Wed, 1 Apr 2009 09:15:17 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35090) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Lp36s-0008UF-Li (Exim 4.70) (return-path ); Wed, 01 Apr 2009 17:16:14 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Lp36s-0004xA-N2 (Exim 4.67) (return-path ); Wed, 01 Apr 2009 17:16:14 +0100 Date: Wed, 1 Apr 2009 17:16:14 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... In-Reply-To: <49D38BBE.6080308@cisco.com> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Apps Discuss , Keith Moore , Keith Moore , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:15:19 -0000 On Wed, 1 Apr 2009, Eliot Lear wrote: > On 4/1/09 5:12 PM, Tony Finch wrote: > > You just described exactly what Olson's tz list does. > > Precisely so. The only issue is this: what is the succession plan for the > distribution? What happens on the off chance it implodes? And perhaps Cyrus > and Barry are implicitly correct in the draft that we should make this > tomorrow's problem, and not today's if this conversation is any indicator. Allowing multiple publishers allows for forking Olson's tz project or resurrecting it, as well as making space for the CLDR and commercial publishers and so on. It's a lightweight and general mechanism that matches the current state of play. A lot of the arguments in this conversation would go away if we had a location -> tz lookup service, especially if that service can cope with multiple publishers' tz names. Yes this is just moving the problem but I think it is being moved to the right place. Or to be more exact, this is where the problem already lies, and the service doesn't exist because it's a hard problem. This should be a warning that redrawing the boundaries is likely to make a standards effort fail, by making it unnecessarily hard to solve the easy parts. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From phoffman@imc.org Wed Apr 1 09:17:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D61728C1E3 for ; Wed, 1 Apr 2009 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4adcKKTK-BuT for ; Wed, 1 Apr 2009 09:17:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6030728C1F5 for ; Wed, 1 Apr 2009 09:17:33 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n31GIQRU084752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 09:18:27 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090401084823.GA20305@nic.fr> References: <200904011116363933242@cnnic.cn> <20090401084823.GA20305@nic.fr> Date: Wed, 1 Apr 2009 09:18:25 -0700 To: Stephane Bortzmeyer , zhangguoqiang From: Paul Hoffman Subject: Re: Solicitation for a discussion on Keyword-based addressing Content-Type: text/plain; charset="us-ascii" Cc: YAO Jiankang , apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:17:34 -0000 At 10:48 AM +0200 4/1/09, Stephane Bortzmeyer wrote: >On Wed, Apr 01, 2009 at 11:16:36AM +0800, > zhangguoqiang wrote > a message of 156 lines which said: > >> Different from search engines, keyword-based addressing is an >> addressing technology. Based on whether a keyword is registered or >> not, the resolution result is determinstic for any given keyword, > >Then it will have all the problems of the domain names, including >bureaucratic registration rules, UDRP, lawyers, ICANN, etc. It will have *some* of the problems of those systems, but not all of them. The problems will be limited by the policies adopted by the keyword admins. > > For example, if you are a blogger of a portal blog website, >> typically, you are assigned a URL that identifies your blog. It is >> usually composed of two parts: a domain name and an ID(typically a >> magic number). So how can you advertise your blog to your friends? > >tinyurl.com That is one answer, but not a protocol. >But it is simpler to buy a domain name and redirect. How is that simpler than buying a keyword?!? > > So, we think keyword-based addressing is a very useful technique, >> especially for non-english speaking countries. Even for english >> speaking countries, the above example also illustrates its >> practicability. To internationalize this service and provide cross >> resolution capability, we highly recommend a standard being >> developped. > >I'm very skeptical but I'll read your draft. ...but not before posting to the list. :-) From Nicolas.Williams@sun.com Wed Apr 1 10:04:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DB93A6A6C for ; Wed, 1 Apr 2009 10:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faGpi2h3NCfC for ; Wed, 1 Apr 2009 10:04:29 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 5EB0F3A6840 for ; Wed, 1 Apr 2009 10:04:29 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n31H5TB6020569 for ; Wed, 1 Apr 2009 17:05:30 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n31H5THt042789 for ; Wed, 1 Apr 2009 11:05:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n31GuDv7015320; Wed, 1 Apr 2009 11:56:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31Gu8v9015319; Wed, 1 Apr 2009 11:56:08 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 11:56:08 -0500 From: Nicolas Williams To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090401165607.GZ9992@Sun.COM> References: <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> <49D1289A.4070803@cisco.com> <20090331223318.GU9992@Sun.COM> <49D2F93B.8040406@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D2F93B.8040406@cs.utk.edu> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:04:30 -0000 On Wed, Apr 01, 2009 at 01:18:51AM -0400, Keith Moore wrote: > Nicolas Williams wrote:
>
> 
Face it: we need a registry.  And: we need country authorities to
> participate.  That means we need to ask ISO for a solution.  Q.E.D.  :)
>
>
> non sequitor.  :)
Anything involving national politics and international standards best belongs in the ISO. Indeed, it does not follow that the IETF cannot do anything in this space, but it does seem likely to create friction -- thus we need at least a path to ISO involvement. My proposal then (I hinted at this earlier) is to create an IANA registry, seed it from existing sources, and open the registry to submitters named by the relevant IETF-ISO liasons. That way we can a) move fast, b) let country authorities take over if they care to, c) allow existing timezone data maintainers to continue doing that until (b) happens on a country by country basis. > I agree that, in the long term, you want to get countries to publish > their timezone definitions.  I also think it's useful to have them > define new timezone names when needed, and to maintain the links > between their names and the published definitions.  (nothing stops > existing publishers from proofreading and fixing such definitions as a > value-added service.)
Indeed, nothing does. In fact, we all do -- they ship with operating systems and various applications and can be found elsewhere as well. > But IMHO these names are less likely to have the right semantics if > they're initially defined by ISO, than if they're initially defined by > an IETF WG composed of people with experience in developing iCalendar > implementations.  Remember, the challenge is to get the naming right, > not the definitions themselves.  Getting the naming right means picking > semantics for the names that maximizes the potential for > interoperability, and picking a form for the names that encourages the > right semantics.
I've not problem with the above -- we're more or less proposing the same sort of thing: an IETF-created and seeded IANA registry with a political safety valve to hand things off to ISO member countries as they step up to do the maintenance work. BTW, we don't need a service if publishers will just publish copies of the IANA registry. There's no need to create a global timezone data distribution service infrastructure. Nico -- From lear@cisco.com Wed Apr 1 10:21:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49F33A6B48 for ; Wed, 1 Apr 2009 10:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF87P-sqFFRZ for ; Wed, 1 Apr 2009 10:21:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 24DDA3A6911 for ; Wed, 1 Apr 2009 10:21:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="165083543" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2009 17:22:30 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n31HMU6o024015; Wed, 1 Apr 2009 13:22:30 -0400 Received: from adsl-247-4-fixip.tiscali.ch ([10.86.252.181]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n31HMSpD015884; Wed, 1 Apr 2009 17:22:28 GMT Message-ID: <49D3A2D1.7010402@cisco.com> Date: Wed, 01 Apr 2009 19:22:25 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090331 Shredder/3.0b3pre MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=424; t=1238606550; x=1239470550; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20supposing=20one=20would=09want=09to=09c reate=09a=09new=09URN=09space=09for=09timezones... |Sender:=20 |To:=20Tony=20Finch=20; bh=YvZ/C6UzcClpNXxf6/p1qq8hK+qg8CNfcZOg4uq0o5A=; b=A/EMLPP+fOyvpGUiv0LDB68dxT7N1ArjpvHZVpGwS65wrsWyrAvIAcOG3j k6iUzUe2AmBpDzEffwL9aaQz28JtMtVBOC1JUpd5P6IeuAaqlHrol9Wp1MYG c4cH9RaEka; Authentication-Results: rtp-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Apps Discuss , Keith Moore , Keith Moore , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:21:31 -0000 On 4/1/09 6:16 PM, Tony Finch wrote: > > A lot of the arguments in this conversation would go away if we had a > location -> tz lookup service, especially if that service can cope with > multiple publishers' tz names. Yes this is just moving the problem but I > think it is being moved to the right place. > What is the difference between what you are suggesting here and the DHCP timezone option? Eliot From moore@cs.utk.edu Wed Apr 1 10:26:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED96D3A6B48 for ; Wed, 1 Apr 2009 10:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf44g5tvOSXW for ; Wed, 1 Apr 2009 10:26:03 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 48E293A6A98 for ; Wed, 1 Apr 2009 10:26:03 -0700 (PDT) Received: from lust.indecency.org (68-243-29-187.pools.spcsdns.net [68.243.29.187]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMG98100 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 10:25:47 -0700 (PDT) Message-ID: <49D3A394.5040402@cs.utk.edu> Date: Wed, 01 Apr 2009 13:25:40 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:26:04 -0000 Tony Finch wrote: 
On Wed, 1 Apr 2009, Keith Moore wrote:

Still, this might mean that rather than having, say, an IETF WG try to
define names for every major timezone, it makes more sense to (a) set up
a registry and a review process, (b) make some recommendations for the
format of timezone names that serve as guidelines to the reviewers, and
(c) invite interested parties to submit registrations.


You just described exactly what Olson's tz list does.
last I knew, Olson's tz list did not have a distinguished, reasonable, publisher-independent name for each timezone.

Keith

From moore@cs.utk.edu Wed Apr 1 10:27:40 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF553A6B48 for ; Wed, 1 Apr 2009 10:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd13qqrUnxCq for ; Wed, 1 Apr 2009 10:27:39 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id CFEF63A6B5F for ; Wed, 1 Apr 2009 10:27:39 -0700 (PDT) Received: from lust.indecency.org (68-243-29-187.pools.spcsdns.net [68.243.29.187]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMG98479 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 10:28:32 -0700 (PDT) Message-ID: <49D3A43D.8090201@cs.utk.edu> Date: Wed, 01 Apr 2009 13:28:29 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:27:40 -0000 Tony Finch wrote: 
On Wed, 1 Apr 2009, Eliot Lear wrote:

On 4/1/09 5:12 PM, Tony Finch wrote:

You just described exactly what Olson's tz list does.

Precisely so.  The only issue is this: what is the succession plan for the
distribution?  What happens on the off chance it implodes?  And perhaps Cyrus
and Barry are implicitly correct in the draft that we should make this
tomorrow's problem, and not today's if this conversation is any indicator.


Allowing multiple publishers allows for forking Olson's tz project or
resurrecting it, as well as making space for the CLDR and commercial
publishers and so on. It's a lightweight and general mechanism that
matches the current state of play.
excellent idea.  but if you want to have multiple publishers, you need a set of timezone names that is independent of publisher if you want interoperability.
A lot of the arguments in this conversation would go away if we had a
location -> tz lookup service, especially if that service can cope with
multiple publishers' tz names.
no they would not.  that's an entirely separate problem.
Or to be more exact, this is where the problem already lies, and the
service doesn't exist because it's a hard problem.
to me it looks like a suggestion for trying to turn a relatively easy problem into a difficult one.

Keith

From moore@cs.utk.edu Wed Apr 1 10:29:05 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5388B3A6B6F for ; Wed, 1 Apr 2009 10:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIgRrwKR6KEG for ; Wed, 1 Apr 2009 10:29:04 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id A66703A6AF0 for ; Wed, 1 Apr 2009 10:29:04 -0700 (PDT) Received: from lust.indecency.org (68-243-29-187.pools.spcsdns.net [68.243.29.187]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMG98648 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 10:29:58 -0700 (PDT) Message-ID: <49D3A491.2010905@cs.utk.edu> Date: Wed, 01 Apr 2009 13:29:53 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> In-Reply-To: <49D3A2D1.7010402@cisco.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Apps Discuss , Keith Moore , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:29:05 -0000 Eliot Lear wrote:
On 4/1/09 6:16 PM, Tony Finch wrote:

A lot of the arguments in this conversation would go away if we had a
location ->  tz lookup service, especially if that service can cope with
multiple publishers' tz names. Yes this is just moving the problem but I
think it is being moved to the right place.
  

What is the difference between what you are suggesting here and the DHCP timezone option?
sigh.  a DHCP timezone option, like a lot of other DHCP options, makes no sense - because the timezone you are in and where you are attached to the network are not inherently related.

and anyway, what would be the use of a DHCP timezone option without a standard set of publisher independent timezone names?

Keith

From fanf2@hermes.cam.ac.uk Wed Apr 1 10:30:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18AF3A6B7F for ; Wed, 1 Apr 2009 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gO2uEUQFFNv for ; Wed, 1 Apr 2009 10:30:46 -0700 (PDT) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by core3.amsl.com (Postfix) with ESMTP id 2249A3A6A50 for ; Wed, 1 Apr 2009 10:30:46 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36087) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Lp4Hy-0004YJ-Jx (Exim 4.70) (return-path ); Wed, 01 Apr 2009 18:31:46 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Lp4Hy-0005kf-5X (Exim 4.67) (return-path ); Wed, 01 Apr 2009 18:31:46 +0100 Date: Wed, 1 Apr 2009 18:31:46 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... In-Reply-To: <49D3A2D1.7010402@cisco.com> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Apps Discuss , Keith Moore , Keith Moore , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:30:47 -0000 On Wed, 1 Apr 2009, Eliot Lear wrote: > > What is the difference between what you are suggesting here and the DHCP > timezone option? We need a mechanism for looking up the tz used by an arbitrary place. We're talking about calendaring and scheduling, not host configuration. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From moore@network-heretics.com Wed Apr 1 10:37:24 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F473A6A6C for ; Wed, 1 Apr 2009 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbXZn5H5yb3u for ; Wed, 1 Apr 2009 10:37:23 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id C35203A67B5 for ; Wed, 1 Apr 2009 10:37:23 -0700 (PDT) Received: from lust.indecency.org (68-243-29-187.pools.spcsdns.net [68.243.29.187]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMG99825 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 10:38:17 -0700 (PDT) Message-ID: <49D3A686.10907@network-heretics.com> Date: Wed, 01 Apr 2009 13:38:14 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Nicolas Williams , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:37:24 -0000 Tony Finch wrote: > On Wed, 1 Apr 2009, Eliot Lear wrote: >> What is the difference between what you are suggesting here and the DHCP >> timezone option? > > We need a mechanism for looking up the tz used by an arbitrary place. *why* do we need such a mechanism? do you think that people don't know what timezone they're using when they schedule a meeting? do you think that people always schedule meetings at their current lat/long locations? do you think that people know the lat/longs of locations at places where they schedule meetings? I'm not saying such a mechanism isn't useful, but it's not a solution to the problem we're trying to solve in this discussion. From john-ietf@jck.com Wed Apr 1 10:42:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C043A6AB5 for ; Wed, 1 Apr 2009 10:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n1X8HGRf60H for ; Wed, 1 Apr 2009 10:42:42 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 1DE753A6A1D for ; Wed, 1 Apr 2009 10:42:42 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Lp4TI-000L4V-T9; Wed, 01 Apr 2009 13:43:29 -0400 Date: Wed, 01 Apr 2009 13:43:28 -0400 From: John C Klensin To: Paul Hoffman , Stephane Bortzmeyer , zhangguoqiang Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <1D33B6C39F5B1949D16F69B7@PST.JCK.COM> In-Reply-To: References: <200904011116363933242@cnnic.cn> <20090401084823.GA20305@nic.fr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: YAO Jiankang , apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:42:43 -0000 --On Wednesday, April 01, 2009 09:18 -0700 Paul Hoffman wrote: > At 10:48 AM +0200 4/1/09, Stephane Bortzmeyer wrote: >> On Wed, Apr 01, 2009 at 11:16:36AM +0800, >> zhangguoqiang wrote >> a message of 156 lines which said: >> >>> Different from search engines, keyword-based addressing is an >>> addressing technology. Based on whether a keyword is >>> registered or not, the resolution result is determinstic for >>> any given keyword, >> >> Then it will have all the problems of the domain names, >> including bureaucratic registration rules, UDRP, lawyers, >> ICANN, etc. > > It will have *some* of the problems of those systems, but not > all of them. The problems will be limited by the policies > adopted by the keyword admins. Yes. And because of the distributed nature of DDDS, there is potentially less "opportunity" for arguments about the One True Root and who is in charge of it, disputes about who has "rights" to establish a tree, etc. Localization of those issues would be a huge help with regard to the set of problems we have encountered with the DNS (and of which ICANN, lawyers, UDRP, etc., are either causes or symptoms, depending on how one looks at the situation). Whether this draft, which seems to assume a country-based structure, is the best one, is another matter that at least deserves further study. >> > For example, if you are a blogger of a portal blog website, >>> typically, you are assigned a URL that identifies your blog. >>> It is usually composed of two parts: a domain name and an >>> ID(typically a magic number). So how can you advertise your >>> blog to your friends? >> >> tinyurl.com > > That is one answer, but not a protocol. It is also a single point of failure located at a few addresses close together on the Internet, with all that implies about scaling and robustness. >> But it is simpler to buy a domain name and redirect. > > How is that simpler than buying a keyword?!? >... I've read this draft a couple of times and will need to read it at least once more before being ready to comment in-depth. My sense so far is that it needs work and that I'd like to understand why certain decisions were made, but that the idea is interesting for all of the reasons why keyword systems "above the DNS" have always been interesting. I find it interesting that Stephane's note doesn't address any of the issues that occurred to me as a read through the draft (perhaps another symptom of his having not read the draft). For example, IDNs are inevitably a compromise with the rather weak matching rules of the DNS, the absence of information about language or other localization clues, etc. One of the arguments often given about keyword systems is that they can be localized, taking advantage of language and other knowledge to permit name structures and matching that are more suited to the needs of local users. This proposal, however, uses IDNA (RFC3490) processing and encoding, which seems to discard that advantage. john From moore@cs.utk.edu Wed Apr 1 10:45:00 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DFA3A6BB0 for ; Wed, 1 Apr 2009 10:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBEuW1YGorJD for ; Wed, 1 Apr 2009 10:44:59 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 9C26F3A6B5F for ; Wed, 1 Apr 2009 10:44:59 -0700 (PDT) Received: from lust.indecency.org (68-243-29-187.pools.spcsdns.net [68.243.29.187]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH00710 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 10:45:51 -0700 (PDT) Message-ID: <49D3A849.9050900@cs.utk.edu> Date: Wed, 01 Apr 2009 13:45:45 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> <49D1289A.4070803@cisco.com> <20090331223318.GU9992@Sun.COM> <49D2F93B.8040406@cs.utk.edu> <20090401165607.GZ9992@Sun.COM> In-Reply-To: <20090401165607.GZ9992@Sun.COM> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:45:00 -0000 
Anything involving national politics and international standards best
belongs in the ISO.
...or some similar international organization with close ties to governments.  which one is beyond my claimed expertise.

(though I still wonder if ICAO hasn't solved this problem already)
  Indeed, it does not follow that the IETF cannot do
anything in this space, but it does seem likely to create friction --
thus we need at least a path to ISO involvement.
I'm fine with having a path to involvement by ISO or a similar organization. 
My proposal then (I hinted at this earlier) is to create an IANA
registry, seed it from existing sources, and open the registry to
submitters named by the relevant IETF-ISO liasons.  That way we can a)
move fast, b) let country authorities take over if they care to, c)
allow existing timezone data maintainers to continue doing that until
(b) happens on a country by country basis.
I'd instead have submitters be anybody and have the reviewers be named (or approved) by relevant liasons, or perhaps by some IETF appointees and some ISO (or whomever) appointees.

Keith

 From lear@cisco.com Wed Apr 1 10:52:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A18A3A68E5 for ; Wed, 1 Apr 2009 10:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z59yVDxUAtml for ; Wed, 1 Apr 2009 10:52:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 632A33A689B for ; Wed, 1 Apr 2009 10:52:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="149205212" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2009 17:53:24 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n31HrOUh008619; Wed, 1 Apr 2009 13:53:24 -0400 Received: from adsl-247-4-fixip.tiscali.ch ([10.86.252.181]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n31HrMC5011820; Wed, 1 Apr 2009 17:53:23 GMT Message-ID: <49D3AA12.7000709@cisco.com> Date: Wed, 01 Apr 2009 19:53:22 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090331 Shredder/3.0b3pre MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=686; t=1238608404; x=1239472404; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20supposing=20one=20would=09want=09to=09c reate=09a=09new=09URN=09space=09for=20timezones... |Sender:=20 |To:=20Tony=20Finch=20; bh=AfhQHY/9Lx8XF28s8vp6UKN8Zce/wj9bel7jETrGvuY=; b=Ki/Z9beCPdG4m+x928x3/AOxszIH5jlwvCEcOB32Sf7sidqw5lyY1VqqI+ 0sK5GIM+WcttaMIedf1QqiaQmYmJeHxrq+iEOC0NOz64isPodJ/AAIPpf8R+ hYXYwMqroY; Authentication-Results: rtp-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Apps Discuss , Keith Moore , Keith Moore , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:52:25 -0000 On 4/1/09 7:31 PM, Tony Finch wrote: > On Wed, 1 Apr 2009, Eliot Lear wrote: > >> What is the difference between what you are suggesting here and the DHCP >> timezone option? >> > We need a mechanism for looking up the tz used by an arbitrary place. > We're talking about calendaring and scheduling, not host configuration. > They're related. It depends on whether you want to look up tz of your host or of others. If it's your host, DHCP options do that just fine. If it's of others, or if it's yours sometime other than "now", then you need a lookup as you describe. And while that problem perhaps has been solved, it's not simple code. Eliot From lear@cisco.com Wed Apr 1 10:55:33 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FF63A6DE5 for ; Wed, 1 Apr 2009 10:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY++I2b4H7on for ; Wed, 1 Apr 2009 10:55:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 183BD3A6DCA for ; Wed, 1 Apr 2009 10:55:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="278261293" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2009 17:56:33 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n31HuXRA005032; Wed, 1 Apr 2009 13:56:33 -0400 Received: from adsl-247-4-fixip.tiscali.ch ([10.86.252.181]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n31HuRGl013042; Wed, 1 Apr 2009 17:56:32 GMT Message-ID: <49D3AACB.4030409@cisco.com> Date: Wed, 01 Apr 2009 19:56:27 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090331 Shredder/3.0b3pre MIME-Version: 1.0 To: SJ Kissane Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0EFF1.6050402@network-heretics.com> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> <49D1289A.4070803@cisco.com> <20090331223318.GU9992@Sun.COM> <20090331230639.GX9992@Sun.COM> <6F7F1C3941B4D89695982BCC@dhcp-43ed.meeting.ietf.org> <82fa66380903312048o7f5864f5kb349ab3e2089f1de@mail.gmail.com> In-Reply-To: <82fa66380903312048o7f5864f5kb349ab3e2089f1de@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=199; t=1238608593; x=1239472593; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20supposing=20one=20would=20want=20to=20c reate=20a=20new=20URN=20space=20for=20=09timezones... |Sender:=20 |To:=20SJ=20Kissane=20; bh=pZbqssHFI8SbecZlZpIhE7cLQipv/TAuBoSMi9qiO0Y=; b=zUvXpKA3vl8vvZagbsJjjOqhEn8u5LKIWANNl54+huviIb9H+JVzqdJ6Cs KpgtX39bu9bIo/UN9slZgrNnivAxlcZUymEQ5RsBbR48EHEEh9zPoal60hhI za32XiBsBT; Authentication-Results: rtp-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:55:33 -0000 On first blush, I think what you're suggesting might go a long way in the right direction. This would require no new documents from the IETF side, and we could just reference the Unicode CLDR. From Nicolas.Williams@sun.com Wed Apr 1 11:01:33 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5BF03A6DF0 for ; Wed, 1 Apr 2009 11:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk4VEtdeCRO5 for ; Wed, 1 Apr 2009 11:01:33 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id DAD2C3A6DF4 for ; Wed, 1 Apr 2009 11:01:32 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n31I2XYQ026578 for ; Wed, 1 Apr 2009 18:02:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n31I2XPr032289 for ; Wed, 1 Apr 2009 12:02:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n31HrGmI015400; Wed, 1 Apr 2009 12:53:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31HrG4w015399; Wed, 1 Apr 2009 12:53:16 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 12:53:16 -0500 From: Nicolas Williams To: SJ Kissane Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090401175316.GG9992@Sun.COM> References: <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> <49D1289A.4070803@cisco.com> <20090331223318.GU9992@Sun.COM> <20090331230639.GX9992@Sun.COM> <6F7F1C3941B4D89695982BCC@dhcp-43ed.meeting.ietf.org> <82fa66380903312048o7f5864f5kb349ab3e2089f1de@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82fa66380903312048o7f5864f5kb349ab3e2089f1de@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:01:33 -0000 On Wed, Apr 01, 2009 at 02:48:16PM +1100, SJ Kissane wrote: > Wow this thread is long, I don't have time to read it all, but let me add my > own two cents. > > Unicode CLDR (http://cldr.unicode.org/) already defines unique > identifiers for timezones, which are the Olson names, save that as I > understand, they only use the first name ever defined, so if the name > ever changes in Olson, they stick to the original name. (see UTS#35 > section 5.9.2 -- http://www.unicode.org/reports/tr35/#Timezone_Names) Oh, good point! > It defines timezone names in multiple languages, mapping to > pre-existing vendor standards (i.e. Windows) -- I think it would be > silly for IETF to reinvent the wheel when the Unicode consortium are > doing so much already in this area. Indeed. From Nicolas.Williams@sun.com Wed Apr 1 11:03:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DF43A6A7B for ; Wed, 1 Apr 2009 11:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.743 X-Spam-Level: X-Spam-Status: No, score=-5.743 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLhVoGhwRiQ4 for ; Wed, 1 Apr 2009 11:03:18 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id D5EAE3A6DE8 for ; Wed, 1 Apr 2009 11:03:13 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n31I4E6X003187 for ; Wed, 1 Apr 2009 18:04:14 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n31I4DKc034488 for ; Wed, 1 Apr 2009 12:04:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n31HsvkN015407; Wed, 1 Apr 2009 12:54:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31HsvL9015406; Wed, 1 Apr 2009 12:54:57 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 12:54:57 -0500 From: Nicolas Williams To: Allison Mankin Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090401175456.GH9992@Sun.COM> References: <45310.1238554003@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45310.1238554003@psg.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:03:18 -0000 On Tue, Mar 31, 2009 at 07:46:43PM -0700, Allison Mankin wrote: > ISO doesn't register timezones now, I think, but I imagine some > diplomacy would still be in order - I'd be happy to help with > that via JTC1/SC6. Well, SJ Kissane points out that the Unicode Consortium does define timezone names. So perhaps we should start with that, and maybe even stop there and just define timezone URNs by reference to the Unicode standards. Nico -- From fanf2@hermes.cam.ac.uk Wed Apr 1 11:10:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562723A6A7B for ; Wed, 1 Apr 2009 11:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkx-DlIUWAqr for ; Wed, 1 Apr 2009 11:10:53 -0700 (PDT) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by core3.amsl.com (Postfix) with ESMTP id 31E553A67E3 for ; Wed, 1 Apr 2009 11:10:53 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35159) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Lp4uk-0003RD-Og (Exim 4.70) (return-path ); Wed, 01 Apr 2009 19:11:50 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Lp4uk-0001OD-KM (Exim 4.67) (return-path ); Wed, 01 Apr 2009 19:11:50 +0100 Date: Wed, 1 Apr 2009 19:11:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... In-Reply-To: <49D3A686.10907@network-heretics.com> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> <49D3A686.10907@network-heretics.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Apps Discuss , Keith Moore , Nicolas Williams , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:10:54 -0000 On Wed, 1 Apr 2009, Keith Moore wrote: > Tony Finch wrote: > > > > We need a mechanism for looking up the tz used by an arbitrary place. > > *why* do we need such a mechanism? do you think that people don't know > what timezone they're using when they schedule a meeting? Yes, when the meeting is in a place that they are not familiar with, or when tz boundaries change. > do you think that people know the lat/longs of locations at > places where they schedule meetings? No, I mean places as in names of towns, not co-ordinates. > I'm not saying such a mechanism isn't useful, but it's not a solution to > the problem we're trying to solve in this discussion. You are right, it's a different problem. However, if you have a mechanism for getting the tz data for a place then you no longer need to expose the name of the tz data - that becomes internal to the data provider. This means tz naming is no longer crucial for interoperability, and you no longer have to worry about tz stability over time because the lookup is more dynamic. However a simpler (smaller) solution to the naming problem is to make it easy to obtain the mapping between names from different publishers. The CLDR already does this, so I expect it can be part of the service proposed by Cyrus. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From mark@coactus.com Tue Mar 31 13:28:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62D43A68F1 for ; Tue, 31 Mar 2009 13:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDOCcbi-M1uC for ; Tue, 31 Mar 2009 13:28:35 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 3603B3A68B0 for ; Tue, 31 Mar 2009 13:28:30 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so3761293ywh.49 for ; Tue, 31 Mar 2009 13:29:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.98.11 with SMTP id a11mr1430192ybm.215.1238531370217; Tue, 31 Mar 2009 13:29:30 -0700 (PDT) In-Reply-To: References: <167dfb9b0903290605m606a0ee8v13f1afede2d1c8f3@mail.gmail.com> Date: Tue, 31 Mar 2009 16:29:30 -0400 Message-ID: Subject: Re: Generic URI syntax incompatible with IPv6 addresses in SIP URIs From: Mark Baker To: Lisa Dusseault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 01 Apr 2009 11:39:16 -0700 Cc: public-iri@w3.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 20:28:36 -0000 On Tue, Mar 31, 2009 at 3:31 PM, Lisa Dusseault wrote: > There is at least one relevant list: public-iri@w3.org. =A0I believe > that's where discussion of updating the base URI specs is moving? =A0I'm > trying to join myself. Moving, really? I hadn't heard anything about that. I would have thought uri@w3.org would be the place to take this. Mark. From mankin@psg.com Tue Mar 31 19:45:53 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46E53A6AE4 for ; Tue, 31 Mar 2009 19:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3lD5kmpLqnq for ; Tue, 31 Mar 2009 19:45:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 04E2F3A687B for ; Tue, 31 Mar 2009 19:45:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LoqTT-000Bmp-Mw; Wed, 01 Apr 2009 02:46:46 +0000 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... Date: Tue, 31 Mar 2009 19:46:43 -0700 Message-ID: <45310.1238554003@psg.com> From: Allison Mankin X-Mailman-Approved-At: Wed, 01 Apr 2009 11:39:16 -0700 Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 02:45:53 -0000 > > Well, creating an IANA registry might force ISO's hand, who knows. The > registration rules for the registry might be such that the IETF/ISO > JTC1/SC6 liason would have to certify submitters. But most likely the > ISO would want to define the timezone naming scheme(s), at least as to > country-specific timezones... > > In any case, I think asking the IETF/ISO liasons is the correct first > step for an IETF participant interested in addressing these problems. > I've decided to cc the currently listed IETF/ISO JTC1/SC6 liason, > Allison Mankin. > I agree with the instinct to check up and communicate. ISO doesn't register timezones now, I think, but I imagine some diplomacy would still be in order - I'd be happy to help with that via JTC1/SC6. Allison From moore@cs.utk.edu Wed Apr 1 12:44:42 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9170D3A6A91 for ; Wed, 1 Apr 2009 12:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC48mkiMm8tI for ; Wed, 1 Apr 2009 12:44:41 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id ECFE83A689B for ; Wed, 1 Apr 2009 12:44:41 -0700 (PDT) Received: from lust.indecency.org (h66-222-47-6.cncrtn.dedicated.static.tds.net [66.222.47.6]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH16177 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 12:45:31 -0700 (PDT) Message-ID: <49D3C45A.7060206@cs.utk.edu> Date: Wed, 01 Apr 2009 15:45:30 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> <49D3A686.10907@network-heretics.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:44:42 -0000 
do you think that people know the lat/longs of locations at
places where they schedule meetings?


No, I mean places as in names of towns, not co-ordinates.
a database mapping place names to standard, distinguished timezone names would clearly be useful.
I'm not saying such a mechanism isn't useful, but it's not a solution to
the problem we're trying to solve in this discussion.


You are right, it's a different problem. However, if you have a mechanism
for getting the tz data for a place then you no longer need to expose the
name of the tz data - that becomes internal to the data provider.
disagree.  you still have the problem that timezone rules change, sometimes on relatively short notice.

Keith

 From moore@network-heretics.com Wed Apr 1 12:46:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F4F3A6A09 for ; Wed, 1 Apr 2009 12:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38m0giS0rf3W for ; Wed, 1 Apr 2009 12:46:56 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id A66FE3A686E for ; Wed, 1 Apr 2009 12:46:56 -0700 (PDT) Received: from lust.indecency.org (h66-222-47-6.cncrtn.dedicated.static.tds.net [66.222.47.6]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH16448 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 12:47:48 -0700 (PDT) Message-ID: <49D3C4E2.4050701@network-heretics.com> Date: Wed, 01 Apr 2009 15:47:46 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <45310.1238554003@psg.com> <20090401175456.GH9992@Sun.COM> In-Reply-To: <20090401175456.GH9992@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:46:57 -0000 Nicolas Williams wrote: > On Tue, Mar 31, 2009 at 07:46:43PM -0700, Allison Mankin wrote: >> ISO doesn't register timezones now, I think, but I imagine some >> diplomacy would still be in order - I'd be happy to help with >> that via JTC1/SC6. > > Well, SJ Kissane points out that the Unicode Consortium does define > timezone names. So perhaps we should start with that, and maybe even > stop there and just define timezone URNs by reference to the Unicode > standards. depends on how good a job they did. From cyrus@daboo.name Wed Apr 1 12:51:02 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57D23A6A09 for ; Wed, 1 Apr 2009 12:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdkAs9elzZ-J for ; Wed, 1 Apr 2009 12:51:01 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 88DA33A686E for ; Wed, 1 Apr 2009 12:51:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B8C5C1326D0B; Wed, 1 Apr 2009 15:52:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHwnQfP2z986; Wed, 1 Apr 2009 15:52:01 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 1EDFA1326D04; Wed, 1 Apr 2009 15:51:57 -0400 (EDT) Date: Wed, 01 Apr 2009 15:51:54 -0400 From: Cyrus Daboo To: Keith Moore , Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <163F609542FCF04B619B2DE8@caldav.corp.apple.com> In-Reply-To: <49D3C45A.7060206@cs.utk.edu> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> <49D3A686.10907@network-heretics.com> <49D3C45A.7060206@cs.utk.edu> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=506 Cc: Apps Discuss , Keith Moore , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:51:02 -0000 Hi Keith, --On April 1, 2009 3:45:30 PM -0400 Keith Moore wrote: > No, I mean places as in names of towns, not co-ordinates. > > > a database mapping place names to standard, distinguished timezone names > would clearly be useful. As I noted before there are already sites offering services like this, e.g. . Encouraging a standard protocol to retrieve that information would be great - LoST being one mentioned previously in this thread. -- Cyrus Daboo From moore@network-heretics.com Wed Apr 1 12:53:48 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72F93A6A7B for ; Wed, 1 Apr 2009 12:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ-72LHdp0iM for ; Wed, 1 Apr 2009 12:53:48 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 37A5E3A68A7 for ; Wed, 1 Apr 2009 12:53:48 -0700 (PDT) Received: from lust.indecency.org (h66-222-47-6.cncrtn.dedicated.static.tds.net [66.222.47.6]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH17468 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 12:54:34 -0700 (PDT) Message-ID: <49D3C678.7050002@network-heretics.com> Date: Wed, 01 Apr 2009 15:54:32 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> <49D1289A.4070803@cisco.com> <20090331223318.GU9992@Sun.COM> <20090331230639.GX9992@Sun.COM> <6F7F1C3941B4D89695982BCC@dhcp-43ed.meeting.ietf.org> <82fa66380903312048o7f5864f5kb349ab3e2089f1de@mail.gmail.com> <20090401175316.GG9992@Sun.COM> In-Reply-To: <20090401175316.GG9992@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:53:48 -0000 Nicolas Williams wrote: > On Wed, Apr 01, 2009 at 02:48:16PM +1100, SJ Kissane wrote: >> Wow this thread is long, I don't have time to read it all, but let me add my >> own two cents. >> >> Unicode CLDR (http://cldr.unicode.org/) already defines unique >> identifiers for timezones, which are the Olson names, save that as I >> understand, they only use the first name ever defined, so if the name >> ever changes in Olson, they stick to the original name. (see UTS#35 >> section 5.9.2 -- http://www.unicode.org/reports/tr35/#Timezone_Names) > > Oh, good point! > >> It defines timezone names in multiple languages, mapping to >> pre-existing vendor standards (i.e. Windows) -- I think it would be >> silly for IETF to reinvent the wheel when the Unicode consortium are >> doing so much already in this area. > > Indeed. I've generally found the Olson names to be very poorly chosen. Many of them are based on city names, which distances them from the reality that in most cases these conventions are dictated by national or local governments. So I think, unfortunately, the Unicode work is not going to be acceptable. Keith From moore@network-heretics.com Wed Apr 1 12:57:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28933A67F4 for ; Wed, 1 Apr 2009 12:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNOV16t6kxyw for ; Wed, 1 Apr 2009 12:57:57 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 2D2C53A68A7 for ; Wed, 1 Apr 2009 12:57:57 -0700 (PDT) Received: from lust.indecency.org (h66-222-47-6.cncrtn.dedicated.static.tds.net [66.222.47.6]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH17608 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 12:55:46 -0700 (PDT) Message-ID: <49D3C6C0.4080907@network-heretics.com> Date: Wed, 01 Apr 2009 15:55:44 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> <49D3A686.10907@network-heretics.com> <49D3C45A.7060206@cs.utk.edu> <163F609542FCF04B619B2DE8@caldav.corp.apple.com> In-Reply-To: <163F609542FCF04B619B2DE8@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Nicolas Williams , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:57:57 -0000 Cyrus Daboo wrote: > Hi Keith, > > --On April 1, 2009 3:45:30 PM -0400 Keith Moore wrote: > >> No, I mean places as in names of towns, not co-ordinates. >> >> >> a database mapping place names to standard, distinguished timezone names >> would clearly be useful. > > As I noted before there are already sites offering services like this, > e.g. . Encouraging a standard protocol to > retrieve that information would be great - LoST being one mentioned > previously in this thread. and of course it would help if there were standard timezone names to map to. Keith From Nicolas.Williams@sun.com Wed Apr 1 13:40:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7E43A6C18 for ; Wed, 1 Apr 2009 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYi5s6smfDig for ; Wed, 1 Apr 2009 13:40:49 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 440EC3A67C1 for ; Wed, 1 Apr 2009 13:40:49 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n31Kfn32001064 for ; Wed, 1 Apr 2009 20:41:50 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n31Kfnvn038401 for ; Wed, 1 Apr 2009 14:41:49 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n31KWX8o015498; Wed, 1 Apr 2009 15:32:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31KWMMe015497; Wed, 1 Apr 2009 15:32:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 15:32:22 -0500 From: Nicolas Williams To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090401203221.GP9992@Sun.COM> References: <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:40:50 -0000 On Wed, Apr 01, 2009 at 03:59:19PM +0100, Tony Finch wrote: > On Tue, 31 Mar 2009, Keith Moore wrote: > > > IMO this sort of issue is best left to international standards > > > development organizations with national representation (think ISO), not > > > the IETF. > > That would exclude informal timezones. You're jumping to conclusions. I didn't say anything about not having a private use sub-namespace. From Nicolas.Williams@sun.com Wed Apr 1 13:50:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC633A6A10 for ; Wed, 1 Apr 2009 13:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3AbIBYi3Ysv for ; Wed, 1 Apr 2009 13:50:50 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 6980A3A692A for ; Wed, 1 Apr 2009 13:50:50 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n31KpplE004967 for ; Wed, 1 Apr 2009 20:51:51 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n31Kpox7046837 for ; Wed, 1 Apr 2009 14:51:50 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n31KgYOm015512; Wed, 1 Apr 2009 15:42:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31KgYnm015511; Wed, 1 Apr 2009 15:42:34 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 15:42:34 -0500 From: Nicolas Williams To: Lisa Dusseault Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090401204233.GQ9992@Sun.COM> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:50:51 -0000 On Mon, Mar 30, 2009 at 03:56:57PM -0700, Lisa Dusseault wrote: > On Mon, Mar 30, 2009 at 9:30 AM, Keith Moore wrote: > > It doesn't matter.  The location shouldn't be part of the timezone name, > > as the set of locations to which a timezone refers can change over time, > > and sometimes there is a dispute about which timezone applies to a > > particular location. > > That could be OK. The URN can be persistent even if the timezone > boundaries change at some point in time. You just have to know the > period over which the URN is relevant, or more relevant the time point > at which the URN ceases to refer to a single timezone. It doesn't matter what the canonical name of a timezone is IF there are useful aliases (for query syntax), meaningful display syntax for canonical names, and a usable canonicalization mechanism. My timezone could be named by a UUID, or by + or +, and so on. A UUID would be utterly useless for humans. A canonical name form with a display form like [/][/] would be fine, even if obnoxious, provided I could reliably enter something like "PDT". The CLDR timezone definitions actually provide for aliases. So it seems like a useful candidate. Nico -- From moore@network-heretics.com Wed Apr 1 14:27:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8F43A68C8 for ; Wed, 1 Apr 2009 14:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbBtYyX6qYtL for ; Wed, 1 Apr 2009 14:27:12 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id A8BFF3A6863 for ; Wed, 1 Apr 2009 14:27:12 -0700 (PDT) Received: from lust.indecency.org (68-243-61-155.pools.spcsdns.net [68.243.61.155]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH27347 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 14:28:08 -0700 (PDT) Message-ID: <49D3DC65.7080004@network-heretics.com> Date: Wed, 01 Apr 2009 17:28:05 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> In-Reply-To: <20090401204233.GQ9992@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:27:13 -0000 Nicolas Williams wrote: > On Mon, Mar 30, 2009 at 03:56:57PM -0700, Lisa Dusseault wrote: >> On Mon, Mar 30, 2009 at 9:30 AM, Keith Moore wrote: >>> It doesn't matter. The location shouldn't be part of the timezone name, >>> as the set of locations to which a timezone refers can change over time, >>> and sometimes there is a dispute about which timezone applies to a >>> particular location. >> That could be OK. The URN can be persistent even if the timezone >> boundaries change at some point in time. You just have to know the >> period over which the URN is relevant, or more relevant the time point >> at which the URN ceases to refer to a single timezone. > > It doesn't matter what the canonical name of a timezone is IF there are > useful aliases (for query syntax), meaningful display syntax for > canonical names, and a usable canonicalization mechanism. Pretty much agree. The main value in having it be meaningful to humans is as a sanity check. e.g. if timezone names were of the form "TZ."[-+]{HHMM}"."{ISO3166}["."{modifier}] and you found some software that mapped a location in Oregon to TZ.-0500.CA, you'd know at a glance that something were wrong. Correspondingly you could scan a timezone database with mappings from publisher zone names to standard zone names, and more or less be able to tell at a glance whether the mappings were reasonable. If the timezone IDs were say UUIDs we wouldn't have that kind of sanity check, and transcription errors would be more likely. Also I think it would invite publishers to create their own UUIDs rather than map to standard ones. But again, for the problem at hand I don't think we even care about aliases, query syntax, display syntax, or canonicalization. All we care about is being able to name timezones in such a way that different publishers can treat our names as distinguished aliases for their existing definitions, and such that software can export those aliases in event descriptions. For the most part, users don't have to see these things. > The CLDR timezone definitions actually provide for aliases. So it seems > like a useful candidate. The definitions are probably as good as any, since they're derived form the Olsen database. But we're not proposing to standardize the definitions, just the names. And the CLDR names (and the canonicalization algorithm) are totally screwed up for use in event descriptions. So, apparently, are everyone else's names. That's why we're having this discussion. Keith From Nicolas.Williams@sun.com Wed Apr 1 14:45:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152353A6DB3 for ; Wed, 1 Apr 2009 14:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poQPxNXqS2X9 for ; Wed, 1 Apr 2009 14:45:46 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 6CB063A6863 for ; Wed, 1 Apr 2009 14:45:46 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n31LklMY016595 for ; Wed, 1 Apr 2009 21:46:47 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n31LkkC5024247 for ; Wed, 1 Apr 2009 15:46:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n31LbU1s015571; Wed, 1 Apr 2009 16:37:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31LbUeD015570; Wed, 1 Apr 2009 16:37:30 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 16:37:30 -0500 From: Nicolas Williams To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090401213729.GU9992@Sun.COM> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D3DC65.7080004@network-heretics.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:45:47 -0000 On Wed, Apr 01, 2009 at 05:28:05PM -0400, Keith Moore wrote: > And the CLDR names (and the > canonicalization algorithm) are totally screwed up for use in event > descriptions. Er, but the CLDR does provide for aliases. So, how's it broken? (I've not looked at the data, no...) From lisa.dusseault@messagingarchitects.com Wed Apr 1 14:51:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B3D28C18E for ; Wed, 1 Apr 2009 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJFQ+w9xS6Km for ; Wed, 1 Apr 2009 14:51:12 -0700 (PDT) Received: from mplus1.messagingarchitects.com (bastille.messagingarchitects.com [216.94.112.120]) by core3.amsl.com (Postfix) with ESMTP id 80F793A672F for ; Wed, 1 Apr 2009 14:51:11 -0700 (PDT) Received: from [192.168.1.100] lisad@messagingarchitects.com [74.95.2.169] by mplus1.messagingarchitects.com with M+ Extreme Email Engine 2008.4.release; Wed, 01 Apr 2009 17:51:08 -0400 X-MailFrom: lisa.dusseault@messagingarchitects.com Message-Id: <2460BD9E-DEA8-4CE9-B674-CAFE6251FC7D@messagingarchitects.com> From: Lisa Dusseault To: Apps Discuss , Lisa Dusseault's Chairs Content-Type: multipart/alternative; boundary=Apple-Mail-62-469822365 Subject: Lisa's Apps Area Activity Report for March 2009 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 14:49:03 -0700 X-Mailer: Apple Mail (2.930.3) X-Mplus-Virus-Scanned: mplusversion: 2008.4.release ; timestamp: Wed, 01 Apr 2009 17:51:09 -0400 engine: XCFAntiVirus1 Engine; version: 3981 (20090401)/1082 (20090213)/1091 (20090309)/1.009 (20070910) result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus2 Engine; version: 5.1.00/5571 result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus3 Engine; version: 5.07.0001 result: 0 ; ref: str=0001.0A010204.49D3E153.013D,ss=1,fgs=0; status: success; error: none X-Mplus-Spam-Scanned: mplusversion: 2008.4.release ; timestamp: Wed, 01 Apr 2009 17:51:11 -0400 engine: XCFSPAM3 Engine ; version: 5.07.0001 ; level: 1 ref: str=0001.0A010209.49D3E154.0060,ss=1,fgs=0 status: success ;error: none engine: XCFSPAM1 Engine ; version: Not Available ; level: 0 ref: 0-0-0-12454-c status: success ;error: none engine: XCFSPAM4 Engine ; version: 5.2.1/2009.03.31.22.01.40/2005.02.11.04.44.13/0/0/2007.01.28.16.09.00/2007.02.13.01.23.26/0/0/2009.03.30.20.21.40/2009.04.01.21.01.02/2009.04.01.01.40.01/2009.04.01.21.32.46/0/0/2009.03.10.15.48.12/; level: 10 ref: 3 100 status: success ;error: none X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:51:13 -0000 --Apple-Mail-62-469822365 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit News, Updates Outcomes of SFO BOFs - OAUTH: good consensus to create a WG, now just need followup on finalizing charter - YAM: good consensus to create a WG - MMOX: Some confusion, difficulty covering the depth and breadth of possible work, but good to meet people & hope more chartering work continues on list - XMPP: BOF happened in RAI, good consensus to create a WG - Bar BOF on HTML5 topics for HTTP: discussed a good number of works in progress to see what fell on IETF side, what on W3C side; launched some new URI work (public-iri@w3.org). New mailing list to discuss long-poll, reverse HTTP and Web Sockets: https://www.ietf.org/mailman/listinfo/hybi Anthony Bryan looking for advice on moving forward with: http://tools.ietf.org/html/draft-bryan-metalink-06 Document Status and Progress Active documents, my action: - draft-montemurro-gsma-imei-urn (Exp): Following up on last remaining DISCUSS - draft-ietf-calsify-rfc2445bis (PS): Following up on ADs clearing DISCUSS, also waiting to see authors response to Pasi's DISCUSS Active documents, waiting on other: - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenArt review - draft-ietf-calsify-2446bis (PS): Waiting for a revision - draft-snell-atompub-bidi (PS): Waiting for a revision - draft-wilde-sms-uri (PS): Waiting for a revision Finished processing -- new in RFC Ed queue and new RFCs - draft-ietf-usefor-usepro (PS): Approved, announcement sent - RFC 5423, Internet Message Store Events - RFC 5429, Sieve Email Filtering: Reject and Extended Reject Extensions - RFC 5463, Sieve Email Filtering: Ihave Extension - RFC 5490, The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata WG Status ALTO: WG accepted Problem Statement and Requirements drafts as WG items. CALSIFY: Along with following up on RFC2445bis issues, interesting discussion spun off onto apps-discuss on timezones HTTPBIS: Ongoing discussions on issues including pipelining and Content-Location. IDNABIS: Major advances in SFO: confirm consensus to stick with current and original WG approach and documents, modulo introducing new discussions about a mapping step and recommendations for that step. SIEVE: Alexey steps down as WG Chair, replaced by Aaron Stone. USEFOR: CLOSED! --Apple-Mail-62-469822365 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable public-iri@w3.org).

New mailing list to discuss long-poll, reverse HTTP and Web = Sockets: https://www.ietf.org/m= ailman/listinfo/hybi

Anthony Bryan looking = for advice on moving forward with: http://tools.i= etf.org/html/draft-bryan-metalink-06

<= b>Document Status and Progress
Active documents, my = action:
 - draft-montemurro-gsma-imei-urn (Exp): = Following up on last remaining DISCUSS
 - = draft-ietf-calsify-rfc2445bis (PS): Following up on ADs clearing = DISCUSS, also waiting to see authors response to Pasi's = DISCUSS

Active documents, waiting on = other:
 - draft-reschke-webdav-post (Exp): Cyrus Daboo is = doing shepherd review and writeup
 - = draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenArt = review
 - draft-ietf-calsify-2446bis (PS): Waiting for a = revision
 - draft-snell-atompub-bidi (PS): Waiting for a = revision
 - draft-wilde-sms-uri (PS): Waiting for a = revision

Finished processing -- new in RFC Ed = queue and new RFCs
 - draft-ietf-usefor-usepro (PS): = Approved, announcement sent
 - RFC 5423, Internet = Message Store Events
 - RFC 5429, Sieve Email = Filtering: Reject and Extended Reject Extensions
 - RFC = 5463, Sieve Email Filtering: Ihave Extension
 - RFC = 5490, The Sieve Mail-Filtering Language -- Extensions for = Checking Mailbox Status and Accessing Mailbox = Metadata

WG = Status

ALTO: WG accepted Problem Statement and = Requirements drafts as WG items.
CALSIFY: Along with following = up on RFC2445bis issues, interesting discussion spun off onto = apps-discuss on timezones
HTTPBIS: Ongoing discussions on = issues including pipelining and Content-Location.
IDNABIS: =  Major advances in SFO: confirm consensus to stick with current and = original WG approach and documents, modulo introducing new discussions = about a mapping step and recommendations for that step.
SIEVE: =  Alexey steps down as WG Chair, replaced by Aaron Stone. =  
USEFOR: = CLOSED!


= --Apple-Mail-62-469822365-- From moore@network-heretics.com Wed Apr 1 15:25:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4736F3A68D3 for ; Wed, 1 Apr 2009 15:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur4nX25hGkwb for ; Wed, 1 Apr 2009 15:25:46 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 95E963A6842 for ; Wed, 1 Apr 2009 15:25:46 -0700 (PDT) Received: from lust.indecency.org (70-11-3-140.pools.spcsdns.net [70.11.3.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH33408 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 15:26:43 -0700 (PDT) Message-ID: <49D3EA20.1090708@network-heretics.com> Date: Wed, 01 Apr 2009 18:26:40 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <20090401213729.GU9992@Sun.COM> In-Reply-To: <20090401213729.GU9992@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 22:25:47 -0000 Nicolas Williams wrote: > On Wed, Apr 01, 2009 at 05:28:05PM -0400, Keith Moore wrote: >> And the CLDR names (and the >> canonicalization algorithm) are totally screwed up for use in event >> descriptions. > > Er, but the CLDR does provide for aliases. So, how's it broken? (I've > not looked at the data, no...) I expect that the CLDR database of mappings between GMT and the timezone is good, since it's derived from the Olsen tz list database. Unfortunately, the distinguished names in CLDR are poorly chosen. Having an alias feature is good, but there needs to be some way to distinguish the standard name for a timezone from other aliases for that timezone. (This might be accomplished simply by making standard timezone identifiers be sufficiently different (and ugly) that nobody would confuse them for an alias of any other kind. ) Keith From munjo.yu@gmail.com Wed Apr 1 18:16:59 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F00A3A6B69; Wed, 1 Apr 2009 18:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOdO1v8AvL1c; Wed, 1 Apr 2009 18:16:58 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 3D9AF3A67F2; Wed, 1 Apr 2009 18:16:58 -0700 (PDT) Received: by qyk36 with SMTP id 36so663430qyk.29 for ; Wed, 01 Apr 2009 18:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2AUfstrkdKl57zFGqfYQR7iOMFLyuHb8icozupQ21jQ=; b=HgK8HiUCDx9YzcvWkg51BVIZBEVq4EXrFLWU39zYCWYWEXHyvfXKSN73Hyu2ZugBIh OgyTFios58jx63LLuf11xl6phTWugsZkuYqZYbSOnY3qOmj8TZU3HvgY8zZrXWuWB+hO pVEpGHZ/o0bTwQ2tsqI/vWlJy/NpqAg3GOqcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=d9b2wZqxGFVhoxwLoORNMqGgEvH0oHTWZP7q/JpEASTjlQZ3zeoATwnPTEgzV2Z8yb JP9sJFt5kKrrq8fwkTLyHuuAOZ2ZgZAsxIx7Y89npMn2znOy8n3CVCsWOzj4qKTubvUI XVJO3kvt5ocZrd+5C8h7f067BM0YdpIRFjewI= MIME-Version: 1.0 Received: by 10.229.96.13 with SMTP id f13mr3357038qcn.36.1238635078798; Wed, 01 Apr 2009 18:17:58 -0700 (PDT) Date: Wed, 1 Apr 2009 20:17:58 -0500 Message-ID: Subject: Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case From: Munjo Yu To: apps-discuss@ietf.org, sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:16:59 -0000 Hi all, I am Munjo Yu and currently working with Jong Sung Kim of a network solution start-up in Korea, VineGen Inc. During the 74th IETF in San Francisco, Dave Crocker and Lisa Dusseault suggested us to post in the Application mailing list. And I thought the SIP mailing list is a good place too, since we have a use case of our extension with SIP. Jong Sung Kim noticed there should be a better version of the ABNF definition section of RFC 3261 while developing a "complete" ABNF parser generator. The parser generator is complete in the sense that generated parser code does not need any hand coding. In Section 7 of RFC 3261, Request is defined like following. Request = Request-Line *( message-header ) CRLF [ message-body ] where, message-header = (Accept / Accept-Encoding . / Call-ID . / CSeq . / Via . / extension-header) CRLF I omitted most part of the long "message-header" for sake of readability. >From the above, one can tell that *(message-header) achieves a group whose elements are non-sequential and optional. So, any of the following complies with the definition. () ; empty group (Accept) (Accept, Accept) (Accept, Call-ID) (Call-ID, Accept) and so on. However, only a small portion of all the possible combinations are legitimate according to some sections like 8.1.1 as follows. 8.1.1 Generating the Request A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, . . As shown above, few elements like To, From, CSeq, are mandatory - the first sign that the ABNF definition is not self-contained. In fact, all the "additional" definitions of message-header are embedded in various sections in the RFC , which makes it impractical ( if not impossible ) to build a complete parser generator. So, Jong Sung Kim had to add an extension, "non-sequential" group to ABNF, and he named it as SET whose is already available elsewhere like ASN.1 SET is described simply as follows, using a pair of braces: SET {Rule1 Rule2} Using SET, a redefinition of the above Request is something like following: Request = Request-Line message-header CRLF [ message-body ] where, message-header = { Call-ID CSeq . 1*Via . 0*1Accept 0*1Accept-Encoding . 0*1extension-header} CRLF This new version makes quite a few parts of the RFC paragraphs unnecessary and redundant, resulting in a self-contained, straightforward, easy-to-maintain, and parser generator friendly definition. We'd like to know what SIP folks would think about this, and if there are other cases that can benefit from this extension. Also would like to hear from App folks, such as balance between feature and simplicity, architectural point, etc. Regards, -Munjo Yu P.S. we'd like to express our thanks to Dave Crocker and Lisa Dusseault, and other WG chairs for their help and kindness during the meeting. From zhangguoqiang@cnnic.cn Wed Apr 1 18:26:40 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A6B3A68B2 for ; Wed, 1 Apr 2009 18:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.313 X-Spam-Level: *** X-Spam-Status: No, score=3.313 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_103=0.327, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLjAOgyxanZt for ; Wed, 1 Apr 2009 18:26:39 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 2177F3A685D for ; Wed, 1 Apr 2009 18:26:33 -0700 (PDT) Received: (eyou send program); Thu, 02 Apr 2009 09:27:33 +0800 Message-ID: <438635653.30081@cnnic.cn> Received: from 218.241.111.8 by mail.cnnic.cn with HTTP; Thu, 02 Apr 2009 09:27:33 +0800 X-WebMAIL-MUA: [218.241.111.8] From: "=?gb2312?B?1cW5+se/?=" To: john-ietf@jck.com, phoffman@imc.org, bortzmeyer@nic.fr Date: Thu, 02 Apr 2009 09:27:33 +0800 X-Priority: 3 Subject: Re: Solicitation for a discussion on Keyword-basedaddressing Content-Type: text/plain Cc: yaojk@cnnic.cn, lee@cnnic.cn, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?gb2312?B?1cW5+se/?= List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:26:40 -0000 ÔÚÄúµÄÀ´ÐÅÖÐÔø¾­Ìáµ½: >From: John C Klensin >Reply-To: >To: Paul Hoffman , Stephane Bortzmeyer , zhangguoqiang >Subject: Re: Solicitation for a discussion on Keyword-based addressing >Date:Wed, 01 Apr 2009 13:43:28 -0400 > >--On Wednesday, April 01, 2009 09:18 -0700 Paul Hoffman > wrote: > > > At 10:48 AM +0200 4/1/09, Stephane Bortzmeyer wrote: > >> On Wed, Apr 01, 2009 at 11:16:36AM +0800, > >> zhangguoqiang wrote > >> a message of 156 lines which said: > >> > >>> Different from search engines, keyword-based addressing is an > >>> addressing technology. Based on whether a keyword is > >>> registered or not, the resolution result is determinstic for > >>> any given keyword, > >> > >> Then it will have all the problems of the domain names, > >> including bureaucratic registration rules, UDRP, lawyers, > >> ICANN, etc. > > > > It will have *some* of the problems of those systems, but not > > all of them. The problems will be limited by the policies > > adopted by the keyword admins. > > Yes. And because of the distributed nature of DDDS, there is > potentially less "opportunity" for arguments about the One True > Root and who is in charge of it, disputes about who has "rights" > to establish a tree, etc. Localization of those issues would be > a huge help with regard to the set of problems we have > encountered with the DNS (and of which ICANN, lawyers, UDRP, > etc., are either causes or symptoms, depending on how one looks > at the situation). > > Whether this draft, which seems to assume a country-based > structure, is the best one, is another matter that at least > deserves further study. Yes, I agree. I also have a languged-based structure, a little bit more complicated. > >> > For example, if you are a blogger of a portal blog website, > >>> typically, you are assigned a URL that identifies your blog. > >>> It is usually composed of two parts: a domain name and an > >>> ID(typically a magic number). So how can you advertise your > >>> blog to your friends? > >> > >> tinyurl.com > > > > That is one answer, but not a protocol. > > It is also a single point of failure located at a few addresses > close together on the Internet, with all that implies about > scaling and robustness. > > >> But it is simpler to buy a domain name and redirect. > > > > How is that simpler than buying a keyword?!? > >... > > I've read this draft a couple of times and will need to read it > at least once more before being ready to comment in-depth. My > sense so far is that it needs work and that I'd like to > understand why certain decisions were made, but that the idea is > interesting for all of the reasons why keyword systems "above > the DNS" have always been interesting. > > I find it interesting that Stephane's note doesn't address any > of the issues that occurred to me as a read through the draft > (perhaps another symptom of his having not read the draft). > For example, IDNs are inevitably a compromise with the rather > weak matching rules of the DNS, the absence of information about > language or other localization clues, etc. One of the arguments > often given about keyword systems is that they can be localized, > taking advantage of language and other knowledge to permit name > structures and matching that are more suited to the needs of > local users. This proposal, however, uses IDNA (RFC3490) > processing and encoding, which seems to discard that advantage. Yes, since we currently use the DNS as the valid DDDS database, we have the same problem encountered by IDNA. However, DNS is only one kind of valid DDDS database(surely it is the only DDDS database defined so far). Maybe we can define another valid DDDS database which accepts Unicode. Should this solve the problem? > john > > From skissane@gmail.com Wed Apr 1 18:48:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28EF28C1E8 for ; Wed, 1 Apr 2009 18:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAuk4z3pUsqN for ; Wed, 1 Apr 2009 18:48:55 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.250]) by core3.amsl.com (Postfix) with ESMTP id 9361C28C1E0 for ; Wed, 1 Apr 2009 18:48:55 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id k29so288838rvb.34 for ; Wed, 01 Apr 2009 18:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZBB7g6kw/gSdFgwHnMlbxCsj+Tg+E9m6zdp0tm+w9hw=; b=rex8Cs8vUNgCpQj/qa0akYchxteYKQ3nAuInMFfQDseKDykABzwmrB0UxIhWCYJAKL iB5YGbFK9VtUU7kUK5pmiKj5alr86Ia1X6rdPvNSJ2oLmDQvkNzXYBL7hbZw0N8xlYSJ t9xRkoKgiaH7jVyByzSPfeGh+woN6Csw5k5Ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QTWgWU+JbWVhISyg/wMWSuW5QcO7UGcDziOKZ8eSy+DXvvsW3UW3cXJNUcj5rtle7c l2pl544LDaPs+AD6WSr8iLXVB30+w0dZcl+SIy+JJdsEh4qAAFOkoOvV7YcuclYf0Gi+ iXfhmjsVsfe/QR2t7wDw65dwUCt7ju64q47H8= MIME-Version: 1.0 Received: by 10.141.151.3 with SMTP id d3mr4270742rvo.262.1238636996395; Wed, 01 Apr 2009 18:49:56 -0700 (PDT) In-Reply-To: <49D3C4E2.4050701@network-heretics.com> References: <45310.1238554003@psg.com> <20090401175456.GH9992@Sun.COM> <49D3C4E2.4050701@network-heretics.com> Date: Thu, 2 Apr 2009 12:49:56 +1100 Message-ID: <82fa66380904011849p235588f5jfd755c2573fc83d6@mail.gmail.com> Subject: Re: supposing one would want to create a new URN space for timezones... From: SJ Kissane To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd20a202d0486046688a6c1 Cc: Apps Discuss , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:48:56 -0000 --000e0cd20a202d0486046688a6c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/4/2 Keith Moore > Nicolas Williams wrote: > > On Tue, Mar 31, 2009 at 07:46:43PM -0700, Allison Mankin wrote: > >> ISO doesn't register timezones now, I think, but I imagine some > >> diplomacy would still be in order - I'd be happy to help with > >> that via JTC1/SC6. > > > > Well, SJ Kissane points out that the Unicode Consortium does define > > timezone names. So perhaps we should start with that, and maybe even > > stop there and just define timezone URNs by reference to the Unicode > > standards. > > depends on how good a job they did. > I think the intention of the Unicode project was to have unique identifiers, for use in data formats and protocols (XML, Web Services, databases, whatever). So, they picked the Olson identifiers, rather than reinvent the wheel, but choose to ignore renames, to make the identifiers more stable over time. Some of the names may be imperfect, even plain wrong, but its not an issue because these names are not meant for direct display to the user -- they are meant just as identifiers. The CLDR defines mapping tables, for user-friendly names of these identifiers in various languages. The identifiers are fixed permanently, but the mapping tables can be changed from version to version. If someone thinks the mapping tables are imperfect, they can always contact the CLDR project and suggest changes / revisions. There have been some comments above, that people would prefer a pick a country and state province to find the timezone, rather than a city. Well, Olson already contains a mapping file for ISO-3166-1 codes to timezones. Of course, this is not a 1-1 mapping, since multiple countries share the same timezone, and the same country has multiple timezones. Maybe a useful addition, would be to map to ISO-3166-2 codes as well? So then, you can find the Timezone for Kentucky, USA. BUT, even this is not a 1-1 mapping, because sometimes the same state/province has multiple time zones. Example: The State of New South Wales in Australia has 3 timezones - UTC+10 / +11 in most of the state - UTC+9.5 / +10.5 in Yancowinna County [Broken Hill and the surrounding area] - UTC+10.5 / +11 on Lord Howe Island So, even picking Australia > NSW in a user interface, you still have 3 choices of timezone (although, 99%+ of the state population and area is in the main one, still you wouldn't want to alienate those people who live in the other two...) This is why City, Continent like Olson uses is a better choice than Country>State/Province. Because at least down to the county/municipality level, you can have a different timezone in some cases, but you wouldn't want to list every county/municipality in the world in your timezone database... Cheers Simon --000e0cd20a202d0486046688a6c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2009/4/2 Keith Moore <moore@network-heretics.com>=
Nicolas Williams wrote:
> On Tue, Mar 31, 2009 at 07:46:43PM -0700, Allison Mankin wrote:
>> ISO doesn't register timezones now, I think, but I imagine som= e
>> diplomacy would still be in order - I'd be happy to help with<= br> >> that via JTC1/SC6.
>
> Well, SJ Kissane points out that the Unicode Consortium does define > timezone names. =A0So perhaps we should start with that, and maybe eve= n
> stop there and just define timezone URNs by reference to the Unicode > standards.

depends on how good a job they did.
I think the intention of the Unicode project was to have= unique identifiers,
for use in data formats and protocols (XML, Web Ser= vices, databases, whatever).
So, they picked the Olson identifiers, rath= er than reinvent the wheel, but
choose to ignore renames, to make the identifiers more stable over time.Some of the names may be imperfect, even plain wrong, but its not an issue=
because these names are not meant for direct display to the user -- the= y are meant
just as identifiers. The CLDR defines mapping tables, for user-friendly nam= es of
these identifiers in various languages. The identifiers are fixed = permanently, but the
mapping tables can be changed from version to versi= on.

If someone thinks the mapping tables are imperfect, they can always con= tact the
CLDR project and suggest changes / revisions.

There have= been some comments above, that people would prefer a pick a country and state province to find the timezone, rather than a city.
Well, Olson alr= eady contains a mapping file for ISO-3166-1 codes to timezones.
Of cours= e, this is not a 1-1 mapping, since multiple countries share the same timez= one,
and the same country has multiple timezones.

Maybe a useful addition= , would be to map to ISO-3166-2 codes as well?
So then, you can find the= Timezone for Kentucky, USA.
BUT, even this is not a 1-1 mapping, becaus= e sometimes the same
state/province has multiple time zones.

Example: The State of New So= uth Wales in Australia has 3 timezones
- UTC+10 / +11 in most of the sta= te
- UTC+9.5 / +10.5 in Yancowinna County [Broken Hill and the surroundi= ng area]
- UTC+10.5 / +11 on Lord Howe Island
So, even picking Australia > NSW= in a user interface, you still have 3 choices of timezone
(although, 99= %+ of the state population and area is in the main one, still you wouldn= 9;t
want to alienate those people who live in the other two...)

This is = why City, Continent like Olson uses is a better choice than Country>Stat= e/Province.
Because at least down to the county/municipality level, you = can have a different timezone in
some cases, but you wouldn't want to list every county/municipality in = the world in your
timezone database...

Cheers
Simon
--000e0cd20a202d0486046688a6c1-- From zhangguoqiang@cnnic.cn Wed Apr 1 18:56:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3595C3A68CE for ; Wed, 1 Apr 2009 18:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.045 X-Spam-Level: **** X-Spam-Status: No, score=4.045 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_103=0.327, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJR4TRhI0QuG for ; Wed, 1 Apr 2009 18:56:26 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id D57513A685D for ; Wed, 1 Apr 2009 18:56:25 -0700 (PDT) Received: (eyou send program); Thu, 02 Apr 2009 09:57:25 +0800 Message-ID: <438637445.02282@cnnic.cn> Received: from 218.241.111.8 by mail.cnnic.cn with HTTP; Thu, 02 Apr 2009 09:57:25 +0800 X-WebMAIL-MUA: [218.241.111.8] From: "=?gb2312?B?1cW5+se/?=" To: bortzmeyer@nic.fr Date: Thu, 02 Apr 2009 09:57:25 +0800 X-Priority: 3 Subject: Re: Solicitation for a discussion on Keyword-based addressing Content-Type: text/plain Cc: yaojk@cnnic.cn, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?gb2312?B?1cW5+se/?= List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:56:27 -0000 ÔÚÄúµÄÀ´ÐÅÖÐÔø¾­Ìáµ½: >From: Stephane Bortzmeyer >Reply-To: >To: zhangguoqiang >Subject: Re: Solicitation for a discussion on Keyword-based addressing >Date:Wed, 1 Apr 2009 10:48:23 +0200 > >On Wed, Apr 01, 2009 at 11:16:36AM +0800, > zhangguoqiang wrote > a message of 156 lines which said: > > > Different from search engines, keyword-based addressing is an > > addressing technology. Based on whether a keyword is registered or > > not, the resolution result is determinstic for any given keyword, > > Then it will have all the problems of the domain names, including > bureaucratic registration rules, UDRP, lawyers, ICANN, etc. > > > For example, if you are a blogger of a portal blog website, > > typically, you are assigned a URL that identifies your blog. It is > > usually composed of two parts: a domain name and an ID(typically a > > magic number). So how can you advertise your blog to your friends? > > tinyurl.com > > But it is simpler to buy a domain name and redirect. > > > So, we think keyword-based addressing is a very useful technique, > > especially for non-english speaking countries. Even for english > > speaking countries, the above example also illustrates its > > practicability. To internationalize this service and provide cross > > resolution capability, we highly recommend a standard being > > developped. > > I'm very skeptical but I'll read your draft. > > > Our keyword-based addressing draft is available at > > http://tools.ietf.org/html/draft-zhang-keyword-ddds-00, which > > specifies keyword-based addressing as a DDDS application. > > You apparently do not mention RFC 2345 (keywords are a very old idea > which keep popping up from time to time). Yes,I will read that RFC. But you should read my draft too. From SRS0=ctsviW=AA=standardstrack.com=eburger@srs.bis.na.blackberry.com Wed Apr 1 18:25:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98403A685D; Wed, 1 Apr 2009 18:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.708 X-Spam-Level: X-Spam-Status: No, score=-6.708 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zau17Hky+2eE; Wed, 1 Apr 2009 18:25:34 -0700 (PDT) Received: from smtp01.bis.na.blackberry.com (smtp01.bis.na.blackberry.com [216.9.248.48]) by core3.amsl.com (Postfix) with ESMTP id 90B753A6821; Wed, 1 Apr 2009 18:25:33 -0700 (PDT) Received: from bda379.bisx.prod.on.blackberry (bda379.bisx.prod.on.blackberry [172.20.234.79]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id n321Qs5g031039; Thu, 2 Apr 2009 01:26:54 GMT Received: from bda379.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda379.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id n321QVYw021862; Thu, 2 Apr 2009 01:26:31 GMT X-rim-org-msg-ref-id: 858250208 Message-ID: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: In-Reply-To: Sensitivity: Normal Importance: Normal To: apps-discuss@ietf.org, SIP@ietf.org Subject: Re: Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case From: "eburger" Date: Thu, 2 Apr 2009 01:26:51 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:59:57 -0000 UGVyc29uYWxseSwgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB3ZSBkaWRuJ3QganVzdCB1c2UgWUFD Qy4gSSBhbSByZWFsbHkgaW4gZmF2b3Igb2YgdXNpbmcgYSBmb3JtYWwgbGFuZ3VhZ2UgZm9yIHNw ZWNpZnlpbmcgZ3JhbW1hci4gQXMgTXVuam8gc3RhdGVzLCB0aGUgQUJORiBpcyBlc3NlbnRpYWxs eSBkb2N1bWVudGF0aW9uIGZsdWZmIC0gdXNlbGVzcyBhdCBiZXN0IGFuZCB3cm9uZyBhdCB3b3Jz dC4gDQoNCkFzIGZvciB0aGlzIHBhcnRpY3VsYXIgc3VnZ2VzdGlvbiwgSSBhbSBhbWJpdmFsZW50 IGFzIHRvIHdoZXRoZXIgd2UgaGFjayBBQk5GLCBhZG9wdCBZQUNDLCBvciBldmVuIGFkb3B0IEFT Ti4xLiANCg0KLS0NCkVyaWMgQnVyZ2VyDQoNClNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNlOyBz b3JyeSBpZiB0ZXJzZS4gQWxsIG1vYmlsZSB1c2VycyBuZWVkIGxlbW9uYWRlLiAgU2VlIDxodHRw Oi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlPiBmb3IgbW9yZSBpbmZvcm1h dGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE11bmpvIFl1IDxtdW5q by55dUBnbWFpbC5jb20+DQoNCkRhdGU6IFdlZCwgMSBBcHIgMjAwOSAyMDoxNzo1OCANClRvOiA8 YXBwcy1kaXNjdXNzQGlldGYub3JnPjsgPHNpcEBpZXRmLm9yZz4NClN1YmplY3Q6IFByb3Bvc2Fs IG9mIE5vbi1TZXF1ZW50aWFsIEdyb3VwIE5vdGlvbiBpbiBBQk5GIHcvIGEgU0lQIGNhc2UNCg0K DQpIaSBhbGwsDQoNCkkgYW0gTXVuam8gWXUgYW5kIGN1cnJlbnRseSB3b3JraW5nIHdpdGggSm9u ZyBTdW5nIEtpbSBvZiBhIG5ldHdvcmsNCnNvbHV0aW9uIHN0YXJ0LXVwIGluIEtvcmVhLCBWaW5l R2VuIEluYy4NCkR1cmluZyB0aGUgNzR0aCBJRVRGIGluIFNhbiBGcmFuY2lzY28sIERhdmUgQ3Jv Y2tlciBhbmQgTGlzYSBEdXNzZWF1bHQNCnN1Z2dlc3RlZCB1cyB0byBwb3N0IGluIHRoZSBBcHBs aWNhdGlvbiBtYWlsaW5nIGxpc3QuDQpBbmQgSSB0aG91Z2h0IHRoZSBTSVAgbWFpbGluZyBsaXN0 IGlzIGEgZ29vZCBwbGFjZSB0b28sIHNpbmNlIHdlIGhhdmUNCmEgdXNlIGNhc2Ugb2Ygb3VyIGV4 dGVuc2lvbiB3aXRoIFNJUC4NCg0KSm9uZyBTdW5nIEtpbSBub3RpY2VkIHRoZXJlIHNob3VsZCBi ZSBhIGJldHRlciB2ZXJzaW9uIG9mIHRoZSBBQk5GDQpkZWZpbml0aW9uIHNlY3Rpb24gb2YgUkZD IDMyNjENCndoaWxlIGRldmVsb3BpbmcgYSAiY29tcGxldGUiIEFCTkYgcGFyc2VyIGdlbmVyYXRv ci4NClRoZSBwYXJzZXIgZ2VuZXJhdG9yIGlzIGNvbXBsZXRlIGluIHRoZSBzZW5zZSB0aGF0IGdl bmVyYXRlZCBwYXJzZXIgY29kZQ0KZG9lcyBub3QgbmVlZCBhbnkgaGFuZCBjb2RpbmcuDQoNCklu IFNlY3Rpb24gNyBvZiBSRkMgMzI2MSwgUmVxdWVzdCBpcyBkZWZpbmVkIGxpa2UgZm9sbG93aW5n Lg0KDQogICBSZXF1ZXN0ICAgICAgICA9ICBSZXF1ZXN0LUxpbmUNCiAgICAgICAgICAgICAgICAg ICAgICooIG1lc3NhZ2UtaGVhZGVyICkNCiAgICAgICAgICAgICAgICAgICAgIENSTEYNCiAgICAg ICAgICAgICAgICAgICAgIFsgbWVzc2FnZS1ib2R5IF0NCg0Kd2hlcmUsDQoNCiAgIG1lc3NhZ2Ut aGVhZGVyICA9ICAoQWNjZXB0DQogICAgICAgICAgICAgICAgICAgLyAgQWNjZXB0LUVuY29kaW5n DQogICAgICAgICAgICAgICAgICAgLg0KICAgICAgICAgICAgICAgICAgIC8gIENhbGwtSUQNCiAg ICAgICAgICAgICAgICAgICAuDQogICAgICAgICAgICAgICAgICAgLyAgQ1NlcQ0KICAgICAgICAg ICAgICAgICAgIC4NCiAgICAgICAgICAgICAgICAgIC8gIFZpYQ0KICAgICAgICAgICAgICAgICAg IC4NCiAgICAgICAgICAgICAgICAgIC8gIGV4dGVuc2lvbi1oZWFkZXIpIENSTEYNCg0KSSBvbWl0 dGVkIG1vc3QgcGFydCBvZiB0aGUgbG9uZyAibWVzc2FnZS1oZWFkZXIiIGZvciBzYWtlIG9mIHJl YWRhYmlsaXR5Lg0KDQpGcm9tIHRoZSBhYm92ZSwgb25lIGNhbiB0ZWxsIHRoYXQgKihtZXNzYWdl LWhlYWRlcikgYWNoaWV2ZXMgYSBncm91cA0Kd2hvc2UgZWxlbWVudHMgYXJlDQpub24tc2VxdWVu dGlhbCBhbmQgb3B0aW9uYWwuDQpTbywgYW55IG9mIHRoZSBmb2xsb3dpbmcgY29tcGxpZXMgd2l0 aCB0aGUgZGVmaW5pdGlvbi4NCg0KKCkgOyBlbXB0eSBncm91cA0KKEFjY2VwdCkNCihBY2NlcHQs IEFjY2VwdCkNCihBY2NlcHQsIENhbGwtSUQpDQooQ2FsbC1JRCwgQWNjZXB0KQ0KDQphbmQgc28g b24uDQoNCkhvd2V2ZXIsIG9ubHkgYSBzbWFsbCBwb3J0aW9uIG9mIGFsbCB0aGUgcG9zc2libGUg Y29tYmluYXRpb25zDQphcmUgbGVnaXRpbWF0ZSBhY2NvcmRpbmcgdG8gc29tZSBzZWN0aW9ucyBs aWtlIDguMS4xIGFzIGZvbGxvd3MuDQoNCiAgIDguMS4xIEdlbmVyYXRpbmcgdGhlIFJlcXVlc3QN Cg0KICAgICAgQSB2YWxpZCBTSVAgcmVxdWVzdCBmb3JtdWxhdGVkIGJ5IGEgVUFDIE1VU1QsIGF0 IGEgbWluaW11bSwgY29udGFpbg0KICAgICAgdGhlIGZvbGxvd2luZyBoZWFkZXIgZmllbGRzOiBU bywgRnJvbSwgQ1NlcSwgQ2FsbC1JRCwgTWF4LUZvcndhcmRzLA0KICAgICAgYW5kIFZpYTsgYWxs IG9mIHRoZXNlIGhlYWRlciBmaWVsZHMgYXJlIG1hbmRhdG9yeSBpbiBhbGwgU0lQDQogICAgICBy ZXF1ZXN0cy4gIFRoZXNlIHNpeCBoZWFkZXIgZmllbGRzIGFyZSB0aGUgZnVuZGFtZW50YWwgYnVp bGRpbmcNCiAgICAgIGJsb2NrcyBvZiBhIFNJUCBtZXNzYWdlLA0KICAgICAgLg0KICAgICAgLg0K DQpBcyBzaG93biBhYm92ZSwgZmV3IGVsZW1lbnRzIGxpa2UgVG8sIEZyb20sIENTZXEsIGFyZSBt YW5kYXRvcnkgLSB0aGUNCmZpcnN0IHNpZ24gdGhhdCB0aGUgQUJORiBkZWZpbml0aW9uIGlzIG5v dCBzZWxmLWNvbnRhaW5lZC4NCkluIGZhY3QsIGFsbCB0aGUgImFkZGl0aW9uYWwiIGRlZmluaXRp b25zIG9mIG1lc3NhZ2UtaGVhZGVyIGFyZQ0KZW1iZWRkZWQgaW4gdmFyaW91cyBzZWN0aW9ucyBp biB0aGUgUkZDDQosIHdoaWNoIG1ha2VzIGl0IGltcHJhY3RpY2FsICggaWYgbm90IGltcG9zc2li bGUgKSB0byBidWlsZCBhIGNvbXBsZXRlDQpwYXJzZXIgZ2VuZXJhdG9yLg0KDQpTbywgSm9uZyBT dW5nIEtpbSBoYWQgdG8gYWRkIGFuIGV4dGVuc2lvbiwgIm5vbi1zZXF1ZW50aWFsIiBncm91cCB0 byBBQk5GLCBhbmQNCmhlIG5hbWVkIGl0IGFzIFNFVCB3aG9zZSBpcyBhbHJlYWR5IGF2YWlsYWJs ZSBlbHNld2hlcmUgbGlrZSBBU04uMQ0KDQpTRVQgaXMgZGVzY3JpYmVkIHNpbXBseSBhcyBmb2xs b3dzLCB1c2luZyBhIHBhaXIgb2YgYnJhY2VzOg0KDQpTRVQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHtSdWxlMSBSdWxlMn0NCg0KVXNpbmcgU0VULCBhIHJlZGVmaW5pdGlvbiBvZiB0aGUg YWJvdmUgUmVxdWVzdCBpcyBzb21ldGhpbmcgbGlrZSBmb2xsb3dpbmc6DQoNCiAgIFJlcXVlc3Qg ICAgICAgID0gIFJlcXVlc3QtTGluZQ0KICAgICAgICAgICAgICAgICAgICAgbWVzc2FnZS1oZWFk ZXINCiAgICAgICAgICAgICAgICAgICAgIENSTEYNCiAgICAgICAgICAgICAgICAgICAgIFsgbWVz c2FnZS1ib2R5IF0NCg0Kd2hlcmUsDQoNCiAgIG1lc3NhZ2UtaGVhZGVyICA9ICB7DQogICAgICAg ICAgICAgICAgICAgQ2FsbC1JRA0KICAgICAgICAgICAgICAgICAgIENTZXENCiAgICAgICAgICAg ICAgICAgICAuDQogICAgICAgICAgICAgICAgICAxKlZpYQ0KICAgICAgICAgICAgICAgICAgIC4N CiAgICAgICAgICAgICAgICAgIDAqMUFjY2VwdA0KICAgICAgICAgICAgICAgICAgMCoxQWNjZXB0 LUVuY29kaW5nDQogICAgICAgICAgICAgICAgICAgLg0KICAgICAgICAgICAgICAgICAgMCoxZXh0 ZW5zaW9uLWhlYWRlcn0gQ1JMRg0KDQpUaGlzIG5ldyB2ZXJzaW9uIG1ha2VzIHF1aXRlIGEgZmV3 IHBhcnRzIG9mIHRoZSBSRkMgcGFyYWdyYXBocw0KdW5uZWNlc3NhcnkgYW5kIHJlZHVuZGFudCwg cmVzdWx0aW5nIGluIGEgc2VsZi1jb250YWluZWQsDQpzdHJhaWdodGZvcndhcmQsIGVhc3ktdG8t bWFpbnRhaW4sIGFuZCBwYXJzZXIgZ2VuZXJhdG9yIGZyaWVuZGx5DQpkZWZpbml0aW9uLg0KDQpX ZSdkIGxpa2UgdG8ga25vdyB3aGF0IFNJUCBmb2xrcyB3b3VsZCB0aGluayBhYm91dCB0aGlzLA0K YW5kIGlmIHRoZXJlIGFyZSBvdGhlciBjYXNlcyB0aGF0IGNhbiBiZW5lZml0IGZyb20gdGhpcyBl eHRlbnNpb24uDQpBbHNvIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9tIEFwcCBmb2xrcywgc3VjaCBh cw0KYmFsYW5jZSBiZXR3ZWVuIGZlYXR1cmUgYW5kIHNpbXBsaWNpdHksIGFyY2hpdGVjdHVyYWwg cG9pbnQsIGV0Yy4NCg0KUmVnYXJkcywNCi1NdW5qbyBZdQ0KDQpQLlMuIHdlJ2QgbGlrZSB0byBl eHByZXNzIG91ciB0aGFua3MgdG8gRGF2ZSBDcm9ja2VyIGFuZCBMaXNhIER1c3NlYXVsdCwNCmFu ZCBvdGhlciBXRyBjaGFpcnMgZm9yIHRoZWlyIGhlbHAgYW5kIGtpbmRuZXNzIGR1cmluZyB0aGUg bWVldGluZy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpBcHBzLURpc2N1c3MgbWFpbGluZyBsaXN0DQpBcHBzLURpc2N1c3NAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo= From john-ietf@jck.com Wed Apr 1 20:52:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62603A682F for ; Wed, 1 Apr 2009 20:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H23sLGkTFeqZ for ; Wed, 1 Apr 2009 20:52:31 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id D504A3A6800 for ; Wed, 1 Apr 2009 20:52:30 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LpDzc-000BHp-DV; Wed, 01 Apr 2009 23:53:28 -0400 Date: Wed, 01 Apr 2009 23:53:27 -0400 From: John C Klensin To: =?UTF-8?Q?=E5=BC=A0=E5=9B=BD=E5=BC=BA?= , bortzmeyer@nic.fr Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <807AF62AC3FEAC95D5E670BD@PST.JCK.COM> In-Reply-To: <438637445.02282@cnnic.cn> References: <438637445.02282@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: yaojk@cnnic.cn, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 03:52:31 -0000 --On Thursday, April 02, 2009 09:57 +0800 = =E5=BC=A0=E5=9B=BD=E5=BC=BA wrote: >... >> You apparently do not mention RFC 2345 (keywords are a very >> old idea which keep popping up from time to time). >=20 > Yes,I will read that RFC. But you should read my draft too.=20 In my capacity as lead author of 2345 (and without consulting my co-authors),... -- It had not occurred to me until I read Stephane's note that this was actually one of the first published descriptions of the keyword approach although, in retrospect, it probably was. -- The "keep it as simple as possible" approach taken in that document would put DDDS and NAPTR records, neither of which existed at the time, in the same category as the other more complex database mechanisms and query techniques that it describes with disfavor. -- While it could be updated, probably in obvious ways (but don't expect me to do it), some of the technology suggestions are clearly those of an experimental 1998 protocol, not a production 2009 one: no provision for non-ASCII strings, single points of failure, no authentication of responses, etc. -- Please don't bother trying to look for the test programs and examples. I should try to find them sometime and put them somewhere stable for historical reasons even though the odds of their running on contemporary operating systems is just about zero, but my recollection is that the domain shown for those materials was effectively retired in 1999 or thereabouts. regards, john From moore@cs.utk.edu Wed Apr 1 21:55:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028993A69F7; Wed, 1 Apr 2009 21:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwHQ9ShPhGdq; Wed, 1 Apr 2009 21:55:02 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 2A22F3A69B8; Wed, 1 Apr 2009 21:54:46 -0700 (PDT) Received: from lust.indecency.org (70-11-3-140.pools.spcsdns.net [70.11.3.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH68639 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 21:55:43 -0700 (PDT) Message-ID: <49D44549.2000101@cs.utk.edu> Date: Thu, 02 Apr 2009 00:55:37 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Munjo Yu Subject: Re: Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=E1473978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 04:55:04 -0000 If memory serves, we discussed a very similar notation within the DRUMS working group (around 12 years ago), which is where the RFC 822 ABNF was generalized
to its present form.  Obviously we decided not to include it.  I don't recall
why, but I think it had something to with the fact that having the n*m notation mean one thing when applied to an expression outside of a "SET", and something else when used inside a "SET", creates an ambiguity in the notation.  You can resolve the ambiguity by various means, but the trick is to keep the result from being
confusing to humans.

Keith

 
Hi all,

I am Munjo Yu and currently working with Jong Sung Kim of a network
solution start-up in Korea, VineGen Inc.
During the 74th IETF in San Francisco, Dave Crocker and Lisa Dusseault
suggested us to post in the Application mailing list.
And I thought the SIP mailing list is a good place too, since we have
a use case of our extension with SIP.

Jong Sung Kim noticed there should be a better version of the ABNF
definition section of RFC 3261
while developing a "complete" ABNF parser generator.
The parser generator is complete in the sense that generated parser code
does not need any hand coding.

In Section 7 of RFC 3261, Request is defined like following.

   Request        =  Request-Line
                     *( message-header )
                     CRLF
                     [ message-body ]

where,

   message-header  =  (Accept
                   /  Accept-Encoding
                   .
                   /  Call-ID
                   .
                   /  CSeq
                   .
                  /  Via
                   .
                  /  extension-header) CRLF

I omitted most part of the long "message-header" for sake of readability.

>From the above, one can tell that *(message-header) achieves a group
whose elements are
non-sequential and optional.
So, any of the following complies with the definition.

() ; empty group
(Accept)
(Accept, Accept)
(Accept, Call-ID)
(Call-ID, Accept)

and so on.

However, only a small portion of all the possible combinations
are legitimate according to some sections like 8.1.1 as follows.

   8.1.1 Generating the Request

      A valid SIP request formulated by a UAC MUST, at a minimum, contain
      the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
      and Via; all of these header fields are mandatory in all SIP
      requests.  These six header fields are the fundamental building
      blocks of a SIP message,
      .
      .

As shown above, few elements like To, From, CSeq, are mandatory - the
first sign that the ABNF definition is not self-contained.
In fact, all the "additional" definitions of message-header are
embedded in various sections in the RFC
, which makes it impractical ( if not impossible ) to build a complete
parser generator.

So, Jong Sung Kim had to add an extension, "non-sequential" group to ABNF, and
he named it as SET whose is already available elsewhere like ASN.1

SET is described simply as follows, using a pair of braces:

SET                             {Rule1 Rule2}

Using SET, a redefinition of the above Request is something like following:

   Request        =  Request-Line
                     message-header
                     CRLF
                     [ message-body ]

where,

   message-header  =  {
                   Call-ID
                   CSeq
                   .
                  1*Via
                   .
                  0*1Accept
                  0*1Accept-Encoding
                   .
                  0*1extension-header} CRLF

This new version makes quite a few parts of the RFC paragraphs
unnecessary and redundant, resulting in a self-contained,
straightforward, easy-to-maintain, and parser generator friendly
definition.

We'd like to know what SIP folks would think about this,
and if there are other cases that can benefit from this extension.
Also would like to hear from App folks, such as
balance between feature and simplicity, architectural point, etc.

Regards,
-Munjo Yu

P.S. we'd like to express our thanks to Dave Crocker and Lisa Dusseault,
and other WG chairs for their help and kindness during the meeting.
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
From moore@cs.utk.edu Wed Apr 1 21:58:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E09F3A694D; Wed, 1 Apr 2009 21:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xed1fylpLgq4; Wed, 1 Apr 2009 21:58:18 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 788BA3A682F; Wed, 1 Apr 2009 21:58:18 -0700 (PDT) Received: from lust.indecency.org (70-11-3-140.pools.spcsdns.net [70.11.3.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH69097 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 21:59:14 -0700 (PDT) Message-ID: <49D4461E.2050709@cs.utk.edu> Date: Thu, 02 Apr 2009 00:59:10 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: eburger@standardstrack.com Subject: Re: Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> In-Reply-To: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> X-Enigmail-Version: 0.95.7 OpenPGP: id=E1473978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 04:58:19 -0000 eburger wrote: 
Personally, I don't understand why we didn't just use YACC.
Exercise: write an RFC ?822 parse in yacc.  It can be done, but not easily, as the RFC ?822 grammar is not LALR(1).
 I am really in favor of using a formal language for specifying grammar. As Munjo states, the ABNF is essentially documentation fluff - useless at best and wrong at worst. 

As for this particular suggestion, I am ambivalent as to whether we hack ABNF, adopt YACC, or even adopt ASN.1.
One lesson from the DRUMS effort - rewrite an existing grammar at your peril.  Even if the old specification has errors, writing a new grammar which verifiably recognizes exactly the same language as the old one can be difficult.  And even if you restrict the language that new implementations can emit, you generally have to accept the old language for compatibility's sake.  So you end up with two grammars where one was formerly (almost) good enough.

Keith
From moore@cs.utk.edu Wed Apr 1 22:12:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A48F3A6B4B for ; Wed, 1 Apr 2009 22:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9r8mlRzamLl for ; Wed, 1 Apr 2009 22:12:48 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 588CE3A6809 for ; Wed, 1 Apr 2009 22:12:48 -0700 (PDT) Received: from lust.indecency.org (70-11-3-140.pools.spcsdns.net [70.11.3.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH70249 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 22:13:43 -0700 (PDT) Message-ID: <49D44984.3000300@cs.utk.edu> Date: Thu, 02 Apr 2009 01:13:40 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: SJ Kissane Subject: Re: supposing one would want to create a new URN space for timezones... References: <45310.1238554003@psg.com> <20090401175456.GH9992@Sun.COM> <49D3C4E2.4050701@network-heretics.com> <82fa66380904011849p235588f5jfd755c2573fc83d6@mail.gmail.com> In-Reply-To: <82fa66380904011849p235588f5jfd755c2573fc83d6@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=E1473978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 05:12:49 -0000 SJ Kissane wrote:
I think the intention of the Unicode project was to have unique identifiers,
for use in data formats and protocols (XML, Web Services, databases, whatever).
So, they picked the Olson identifiers, rather than reinvent the wheel, but
choose to ignore renames, to make the identifiers more stable over time.
Some of the names may be imperfect, even plain wrong, but its not an issue
because these names are not meant for direct display to the user -- they are  meant just as identifiers.
I'd almost agree with you, except that the Olson/CLDR identifiers are so poorly chosen that it seems likely that they will break.  Let me give an example.  There have, over the years, been serious discussion as to whether the city of Chicago, IL should move to the Eastern time zone.  If (as I think is the case) America/Chicago is the canonical name for the Central time zone in the US according to CLDR canonicalization rules, and should Chicago move to the Eastern time zone, an unavoidable tension results - does America/Chicago mean "Central time zone" (to preserve the old meaning) or does it mean "the time zone in use in the city of Chicago?"
There have been some comments above, that people would prefer a pick a country and
state province to find the timezone, rather than a city.
Well, Olson already contains a mapping file for ISO-3166-1 codes to timezones.
Of course, this is not a 1-1 mapping, since multiple countries share the same timezone, and the same country has multiple timezones.

Maybe a useful addition, would be to map to ISO-3166-2 codes as well?
So then, you can find the Timezone for Kentucky, USA.
BUT, even this is not a 1-1 mapping, because sometimes the same
state/province has multiple time zones.
Indeed, the state I live in (Tennessee) has two time zones.  So clearly we don't want to do this entirely using state names.
Example: The State of New South Wales in Australia has 3 timezones
- UTC+10 / +11 in most of the state
- UTC+9.5 / +10.5 in Yancowinna County [Broken Hill and the surrounding area]
- UTC+10.5 / +11 on Lord Howe Island
So, even picking Australia > NSW in a user interface, you still have 3 choices of timezone (although, 99%+ of the state population and area is in the main one, still you wouldn't want to alienate those people who live in the other two...)
However, if you use default GMT offset along with country code (and state name when needed) you get a naming scheme which comes very close to covering all timezones in current use.  E.g. "+1000.AU.NSW" to mean "the timezone with default GMT offset of +1000, using the summer time rules in effect in the state of New South Wales in the country of Australia."
This is why City, Continent like Olson uses is a better choice than Country>State/Province.
nope.   Not only do cities sometimes change timezones (most often because of realignment of political boundaries), the area that shares a particular city's timezone often changes also.   Using a city name as a canonical timezone name is exactly the wrong thing to do for any event held outside that city.

Keith

 From fanf2@hermes.cam.ac.uk Thu Apr 2 03:26:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E972F3A6953 for ; Thu, 2 Apr 2009 03:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53tyuuZcWvwQ for ; Thu, 2 Apr 2009 03:26:15 -0700 (PDT) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by core3.amsl.com (Postfix) with ESMTP id 90AC63A6AD4 for ; Thu, 2 Apr 2009 03:26:15 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41188) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1LpK8f-0008G7-Kz (Exim 4.70) (return-path ); Thu, 02 Apr 2009 11:27:13 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LpK8f-00046C-Fj (Exim 4.67) (return-path ); Thu, 02 Apr 2009 11:27:13 +0100 Date: Thu, 2 Apr 2009 11:27:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... In-Reply-To: <49D3C45A.7060206@cs.utk.edu> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> <49D3A686.10907@network-heretics.com> <49D3C45A.7060206@cs.utk.edu> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-429673971-1238668033=:28199" Sender: Tony Finch Cc: Apps Discuss , Keith Moore , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 10:26:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-429673971-1238668033=:28199 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 1 Apr 2009, Keith Moore wrote: > > > However, if you have a mechanism for getting the tz data for a place > > then you no longer need to expose the name of the tz data - that > > becomes internal to the data provider. > > disagree.=A0 you still have the problem that timezone rules change, somet= imes on > relatively short notice. If the lookup from place to tz rules is dynamic then *all* problems with tz instability go away. Tony. --=20 f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. --1870870024-429673971-1238668033=:28199-- From moore@network-heretics.com Thu Apr 2 04:29:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B703A6876 for ; Thu, 2 Apr 2009 04:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlidBrW+TnpR for ; Thu, 2 Apr 2009 04:29:44 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 376D93A6CB2 for ; Thu, 2 Apr 2009 04:29:44 -0700 (PDT) Received: from lust.indecency.org (70-11-3-140.pools.spcsdns.net [70.11.3.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMI03141 (AUTH admin@network-heretics.com); Thu, 2 Apr 2009 04:30:32 -0700 (PDT) Message-ID: <49D4A1D4.9060000@network-heretics.com> Date: Thu, 02 Apr 2009 07:30:28 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Finch Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> <49D3A686.10907@network-heretics.com> <49D3C45A.7060206@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Nicolas Williams , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 11:29:45 -0000 Tony Finch wrote: > On Wed, 1 Apr 2009, Keith Moore wrote: >>> However, if you have a mechanism for getting the tz data for a place >>> then you no longer need to expose the name of the tz data - that >>> becomes internal to the data provider. >> disagree. you still have the problem that timezone rules change, sometimes on >> relatively short notice. > > If the lookup from place to tz rules is dynamic then *all* problems with > tz instability go away. only if you maintain tz rules for regions with extremely fine granularity (say at the level of postal codes in the US). and even then you have the problem of what to do when there's a dispute about which timezone applies to a particular region. Keith From Nicolas.Williams@sun.com Thu Apr 2 08:04:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D2D3A6D29 for ; Thu, 2 Apr 2009 08:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pDW3H5TQ4+j for ; Thu, 2 Apr 2009 08:04:47 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id D741D3A6CE6 for ; Thu, 2 Apr 2009 08:04:46 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n32F5mI6017818 for ; Thu, 2 Apr 2009 15:05:48 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n32F5mUI013966 for ; Thu, 2 Apr 2009 09:05:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32EuURx001941; Thu, 2 Apr 2009 09:56:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32EuPXw001940; Thu, 2 Apr 2009 09:56:25 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 2 Apr 2009 09:56:25 -0500 From: Nicolas Williams To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090402145625.GJ1500@Sun.COM> References: <45310.1238554003@psg.com> <20090401175456.GH9992@Sun.COM> <49D3C4E2.4050701@network-heretics.com> <82fa66380904011849p235588f5jfd755c2573fc83d6@mail.gmail.com> <49D44984.3000300@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D44984.3000300@cs.utk.edu> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:04:47 -0000 On Thu, Apr 02, 2009 at 01:13:40AM -0400, Keith Moore wrote: > Really, HTML e-mail on a mailing list? > > I think the intention of the Unicode project was to have unique > > identifiers, for use in data formats and protocols (XML, Web > > Services, databases, whatever). So, they picked the Olson > > identifiers, rather than reinvent the wheel, but choose to ignore > > renames, to make the identifiers more stable over time. > > > > Some of the names may be imperfect, even plain wrong, but its not an > > issue because these names are not meant for direct display to the > > user -- they are  meant just as identifiers. > > I'd almost agree with you, except that the Olson/CLDR identifiers are > so poorly chosen that it seems likely that they will break.  Let me Doesn't matter -- it suffices that the CLDR provides user-friendly aliases. I don't care at all what the canonical timezone names look like -- I hate /, as I'm sure I've made clear by now, but I don't mind at all the use of / as a canonical form provided that: a) conflicts are avoided/resolved, b) there are alternative, user-friendly aliases including localization. Nico -- From ajs@shinkuro.com Thu Apr 2 08:16:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C813A6985 for ; Thu, 2 Apr 2009 08:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC4J8n9vd8Aj for ; Thu, 2 Apr 2009 08:16:22 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 150233A6D2B for ; Thu, 2 Apr 2009 08:16:22 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id ACFA32FE9C72 for ; Thu, 2 Apr 2009 15:17:22 +0000 (UTC) Date: Thu, 2 Apr 2009 11:17:21 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <20090402151721.GF21659@shinkuro.com> References: <200904011116363933242@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904011116363933242@cnnic.cn> User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:16:23 -0000 On Wed, Apr 01, 2009 at 11:16:36AM +0800, zhangguoqiang wrote: > webpage, while IDN is used to access a web site. Second, keyword > eases user's experience by eliminating the need to remember > potentially great number of suffixes. That argument is a little odd: instead of the user needing to remember a bounded number of suffixes, the user has to remember a completely unbounded number of keywords. Moreover, the user has to guess just the right keyword for the particular site desired, since if keywords are to be an addressing technology then the words in question have to be unique to a destination. This is not to dismiss the arguments for keywords, but I don't think that it actually makes a user's experience any easier except in peculiar cases. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dan.winship@gmail.com Thu Apr 2 08:38:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949273A6BDB for ; Thu, 2 Apr 2009 08:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.856 X-Spam-Level: X-Spam-Status: No, score=-4.856 tagged_above=-999 required=5 tests=[AWL=-4.080, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnEpvwyjhveE for ; Thu, 2 Apr 2009 08:38:46 -0700 (PDT) Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id B4FC63A68C2 for ; Thu, 2 Apr 2009 08:38:46 -0700 (PDT) Received: from desktop.home.mysterion.org (c-24-99-22-247.hsd1.ga.comcast.net [24.99.22.247]) by mysterion.org (Postfix) with ESMTPA id 037C180289; Thu, 2 Apr 2009 11:39:47 -0400 (EDT) Message-ID: <49D4DC43.1080905@gmail.com> Date: Thu, 02 Apr 2009 11:39:47 -0400 From: Dan Winship User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> In-Reply-To: <49D3DC65.7080004@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Eliot Lear , Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:38:47 -0000 Keith Moore wrote: > For the most part, users don't have to see these things. At some point, the user's computer needs to figure out what time zone it is in, and likewise for the user's calendar app. If there is not a standard protocol for doing this automatically somehow, then the user is going to need to see the list of timezones, and somehow be able to pick the correct one. Olsen mostly works OK for this for the easy cases, but is pretty awful for the tricky cases; no one except Olsen himself is going to know which city in Indiana happens to have the same history of Eastern time vs Central time as the city that they live in. And for labeling events that are entirely in the present and future, it doesn't even matter whether they pick the one that happens to have the right offsets in the past. And even if they do pick the right one, there's no guarantee that it will *continue* to be the right one in the future. Given the constant splitting of timezones in Indiana, a user could send out a meeting request to his colleagues for a once-a-week recurring meeting at 10am Thursday in America/Indiana/Indianapolis time, only to have his county switch timezones away from Indianapolis a few months later, forcing him to send out an updated meeting request changing the future instances to the newly-created timezone. (In fact, if *Indianapolis* decides to switch timezones and the user's county decides to not switch, the user *still* needs to send out an updated meeting request, or else the time of the existing appointments will automatically change to match Indianapolis.) There are situations where it's important to have information about the history of GMT offsets in a particular location. But most of the time, you just want to know which GMT offset (or pattern of summer/winter offsets) applies *now*. Splitting this into two separate things (ie, having standard identifiers for the things that ordinary people think of as "time zones": "Eastern Time", "Moscow Time", "Western Australia Time", etc; and a then a separate set of standard identifiers for specifying historical change data like "the same pattern of using Eastern/Central Time as Indianapolis") rather than merging them into a single identifier (Olsen timezones) will probably make things much easier for users to deal with, and may make the spec simpler as well... -- Dan From Nicolas.Williams@sun.com Thu Apr 2 09:03:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE473A6DD7 for ; Thu, 2 Apr 2009 09:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q4mpBOGKfO1 for ; Thu, 2 Apr 2009 09:03:44 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D0DBF3A6E30 for ; Thu, 2 Apr 2009 09:03:05 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n32G46cV016704 for ; Thu, 2 Apr 2009 16:04:06 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n32G45WV020967 for ; Thu, 2 Apr 2009 10:04:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32FsmjA001978; Thu, 2 Apr 2009 10:54:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32FsmnR001977; Thu, 2 Apr 2009 10:54:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 2 Apr 2009 10:54:48 -0500 From: Nicolas Williams To: Dan Winship Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090402155447.GN1500@Sun.COM> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <49D4DC43.1080905@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D4DC43.1080905@gmail.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:03:45 -0000 On Thu, Apr 02, 2009 at 11:39:47AM -0400, Dan Winship wrote: > Keith Moore wrote: > > For the most part, users don't have to see these things. > > At some point, the user's computer needs to figure out what time zone it > is in, and likewise for the user's calendar app. If there is not a > standard protocol for doing this automatically somehow, then the user is > going to need to see the list of timezones, and somehow be able to pick > the correct one. We've been discussing several very different but related problems: 1) how to represent timezones in application protocol data; 2) how to represent timezones in UIs; 3) how to find one's current timezone. The CLDR is sufficient for (1) because if provides for canonical timezone names. The CLDR is sufficient for (2) because it allows for alternative, user-friendly and even localized timezone names. To the extent that any of the canonical name or aliases of a user's current timezone are familiar to the user, then the CLDR provides one solution to (3). But not every user will know any of the names for their current timezone. For networks where physical location and IP address are highly correlated then a DHCP option should suffice for solving (3). But not every IP address is easily mapped to a physical location with sufficient resolution, and not every DHCP server is going to offer this feature. For any node that has a receiver for GPS, WWV or the like, then a location->timezone service would be great. But not every node has such a device. I don't see how we can solve (3) with just one solution. We'll need all of the above. > And for labeling events that are entirely in the present and future, it ^^^^^^ Good point! A date + timestamp + timezone can be written long before a timezone change. We can't prevent all failure modes resulting from timezone changes. Nico -- From cyrus@daboo.name Thu Apr 2 09:17:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714223A681D for ; Thu, 2 Apr 2009 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7r2za6mKkXG for ; Thu, 2 Apr 2009 09:17:42 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 2C74C3A6A14 for ; Thu, 2 Apr 2009 09:17:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 871A3132DA17; Thu, 2 Apr 2009 12:18:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS8XLTFMEUmj; Thu, 2 Apr 2009 12:18:43 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id BCA44132DA09; Thu, 2 Apr 2009 12:18:40 -0400 (EDT) Date: Thu, 02 Apr 2009 12:18:38 -0400 From: Cyrus Daboo To: Nicolas Williams , Dan Winship Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <27E64EE2D15343EAC03C782D@caldav.corp.apple.com> In-Reply-To: <20090402155447.GN1500@Sun.COM> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <49D4DC43.1080905@gmail.com> <20090402155447.GN1500@Sun.COM> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2910 Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:17:43 -0000 Hi Nicolas, --On April 2, 2009 10:54:48 AM -0500 Nicolas Williams wrote: >> At some point, the user's computer needs to figure out what time zone it >> is in, and likewise for the user's calendar app. If there is not a >> standard protocol for doing this automatically somehow, then the user is >> going to need to see the list of timezones, and somehow be able to pick >> the correct one. > > We've been discussing several very different but related problems: > > 1) how to represent timezones in application protocol data; > 2) how to represent timezones in UIs; > 3) how to find one's current timezone. > > The CLDR is sufficient for (1) because if provides for canonical > timezone names. > > The CLDR is sufficient for (2) because it allows for alternative, > user-friendly and even localized timezone names. Right now most UIs provide some sort of map-based graphical timezone picker - i.e. a "fuzzy" location to timezone service. > To the extent that any of the canonical name or aliases of a user's > current timezone are familiar to the user, then the CLDR provides one > solution to (3). But not every user will know any of the names for > their current timezone. > > For networks where physical location and IP address are highly > correlated then a DHCP option should suffice for solving (3). But not > every IP address is easily mapped to a physical location with sufficient > resolution, and not every DHCP server is going to offer this feature. Such a DHCP option already exists: RFC4833. That allows use of POSIX TZ strings and Olson strings. > For any node that has a receiver for GPS, WWV or the like, then a > location->timezone service would be great. But not every node has such > a device. > > I don't see how we can solve (3) with just one solution. We'll need all > of the above. > >> And for labeling events that are entirely in the present and future, it > ^^^^^^ > > Good point! A date + timestamp + timezone can be written long before a > timezone change. We can't prevent all failure modes resulting from > timezone changes. A CalConnect document discusses many of the problems that arose from the US shift in 2007: . In an ideal world we would like clients to be able to detect that a timezone has changed in some way and automatically figure out what events need to be updated, or at least flagged to users as potentially needing to be re-scheduled. This is a complex task. One of the things we would like a timezone service to do is actually do the hard part of figuring out what UTC time ranges in the future are impacted by a timezone change, and return that list to the client which can then figure out which events fall in those ranges. -- Cyrus Daboo From Nicolas.Williams@sun.com Thu Apr 2 09:35:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4978E3A6D27 for ; Thu, 2 Apr 2009 09:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B61Y05TLx3+V for ; Thu, 2 Apr 2009 09:35:15 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 893053A6D08 for ; Thu, 2 Apr 2009 09:35:14 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n32GaFap024852 for ; Thu, 2 Apr 2009 16:36:16 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n32GaFYM049062 for ; Thu, 2 Apr 2009 10:36:15 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32GQwjD002020; Thu, 2 Apr 2009 11:26:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32GQt4X002019; Thu, 2 Apr 2009 11:26:55 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 2 Apr 2009 11:26:55 -0500 From: Nicolas Williams To: Cyrus Daboo Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090402162655.GT1500@Sun.COM> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <49D4DC43.1080905@gmail.com> <20090402155447.GN1500@Sun.COM> <27E64EE2D15343EAC03C782D@caldav.corp.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27E64EE2D15343EAC03C782D@caldav.corp.apple.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Eliot Lear , Keith Moore X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:35:16 -0000 On Thu, Apr 02, 2009 at 12:18:38PM -0400, Cyrus Daboo wrote: > >>And for labeling events that are entirely in the present and future, it > > ^^^^^^ > > > >Good point! A date + timestamp + timezone can be written long before a > >timezone change. We can't prevent all failure modes resulting from > >timezone changes. > > A CalConnect document discusses many of the problems that arose from the US > shift in 2007: > . > > In an ideal world we would like clients to be able to detect that a > timezone has changed in some way and automatically figure out what events > need to be updated, or at least flagged to users as potentially needing to > be re-scheduled. This is a complex task. One of the things we would like a > timezone service to do is actually do the hard part of figuring out what > UTC time ranges in the future are impacted by a timezone change, and return > that list to the client which can then figure out which events fall in > those ranges. You can't resolve all such problems automatically. If I schedule an event for 2010-04-01 10:00:00 EDT and Congress changes EDT to start on the following Sunday then what happens? Should the schedule change to be at 9AM EST, or should the schedule be updated to show 2010-04-01 10:00:00 EST? I'd say that depends at least on the type of the event (e.g., for a wake-up alarm -> change the timezone, for a meeting -> change the time and the timezone). But can that determination be made automatically in all cases? I doubt it. In most cases changing the time and timezone of the event will do though. Nico -- From fanf2@hermes.cam.ac.uk Thu Apr 2 09:58:08 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CE23A6DFD for ; Thu, 2 Apr 2009 09:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.076 X-Spam-Level: X-Spam-Status: No, score=-6.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KxroxZ-4qHI for ; Thu, 2 Apr 2009 09:58:07 -0700 (PDT) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id B6B8B3A6A14 for ; Thu, 2 Apr 2009 09:57:57 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47202) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1LpQFh-0004Al-0w (Exim 4.70) (return-path ); Thu, 02 Apr 2009 17:58:53 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LpQFh-0004Rq-8t (Exim 4.67) (return-path ); Thu, 02 Apr 2009 17:58:53 +0100 Date: Thu, 2 Apr 2009 17:58:53 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... In-Reply-To: <49D4A1D4.9060000@network-heretics.com> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@network-heretics.com> <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> <49D0F5AD.2020509@network-heretics.com> <49D1060E.2030709@cisco.com> <20090331201412.GL9992@Sun.COM> <49D28280.3080406@network-heretics.com> <20090331212703.GR9992@Sun.COM> <49D294FA.7080501@network-heretics.com> <49D38368.8050300@cs.utk.edu> <49D38BBE.6080308@cisco.com> <49D3A2D1.7010402@cisco.com> <49D3A686.10907@network-heretics.com> <49D3C45A.7060206@cs.utk.edu> <49D4A1D4.9060000@network-heretics.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Apps Discuss , Keith Moore , Nicolas Williams , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:58:08 -0000 On Thu, 2 Apr 2009, Keith Moore wrote: > > and even then you have the problem of what to do when there's a dispute > about which timezone applies to a particular region. A very good point, thanks. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From moore@network-heretics.com Thu Apr 2 13:46:32 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97CE3A6A6E for ; Thu, 2 Apr 2009 13:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iLnBkMegIkF for ; Thu, 2 Apr 2009 13:46:32 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 240CC28C266 for ; Thu, 2 Apr 2009 13:46:32 -0700 (PDT) Received: from lust.indecency.org (70-90-152-34-Knoxville.hfc.comcastbusiness.net [70.90.152.34] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMI68694 (AUTH admin@network-heretics.com); Thu, 2 Apr 2009 13:47:30 -0700 (PDT) Message-ID: <49D5245D.2070205@network-heretics.com> Date: Thu, 02 Apr 2009 16:47:25 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <45310.1238554003@psg.com> <20090401175456.GH9992@Sun.COM> <49D3C4E2.4050701@network-heretics.com> <82fa66380904011849p235588f5jfd755c2573fc83d6@mail.gmail.com> <49D44984.3000300@cs.utk.edu> <20090402145625.GJ1500@Sun.COM> In-Reply-To: <20090402145625.GJ1500@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:46:32 -0000 Nicolas Williams wrote: > On Thu, Apr 02, 2009 at 01:13:40AM -0400, Keith Moore wrote: >> > > > Really, HTML e-mail on a mailing list? > Sorry, I thought my MUA was configured to not do that. >> I'd almost agree with you, except that the Olson/CLDR identifiers are >> so poorly chosen that it seems likely that they will break.  Let me > > Doesn't matter -- it suffices that the CLDR provides user-friendly > aliases. I consider that irrelevant to the question at hand. Keith From moore@network-heretics.com Thu Apr 2 14:03:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900A73A6CB3 for ; Thu, 2 Apr 2009 14:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwYhNjuTvhZU for ; Thu, 2 Apr 2009 14:03:49 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id D7A193A6C7E for ; Thu, 2 Apr 2009 14:03:49 -0700 (PDT) Received: from lust.indecency.org (70-90-152-34-Knoxville.hfc.comcastbusiness.net [70.90.152.34] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMI70485 (AUTH admin@network-heretics.com); Thu, 2 Apr 2009 14:04:47 -0700 (PDT) Message-ID: <49D5286A.1040606@network-heretics.com> Date: Thu, 02 Apr 2009 17:04:42 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <49D4DC43.1080905@gmail.com> <20090402155447.GN1500@Sun.COM> In-Reply-To: <20090402155447.GN1500@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:03:50 -0000 Nicolas Williams wrote: > On Thu, Apr 02, 2009 at 11:39:47AM -0400, Dan Winship wrote: >> Keith Moore wrote: >>> For the most part, users don't have to see these things. >> At some point, the user's computer needs to figure out what time zone it >> is in, and likewise for the user's calendar app. If there is not a >> standard protocol for doing this automatically somehow, then the user is >> going to need to see the list of timezones, and somehow be able to pick >> the correct one. > > We've been discussing several very different but related problems: > > 1) how to represent timezones in application protocol data; > 2) how to represent timezones in UIs; > 3) how to find one's current timezone. > > The CLDR is sufficient for (1) because if provides for canonical > timezone names. false, for reasons stated earlier. > The CLDR is sufficient for (2) because it allows for alternative, > user-friendly and even localized timezone names. depends on the UI. >> And for labeling events that are entirely in the present and future, it > ^^^^^^ > > Good point! A date + timestamp + timezone can be written long before a > timezone change. We can't prevent all failure modes resulting from > timezone changes. true. there are many sources of potential error, e.g.: users or software can select the wrong timezone, the timezone originally associated with an event can change boundaries, the timezone might change but the database used by an event recipient fail to be updated. the best we can hope to do is to minimize the potential for failures. Keith From Nicolas.Williams@sun.com Thu Apr 2 14:29:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5003A685D for ; Thu, 2 Apr 2009 14:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PqX5Y5W5oel for ; Thu, 2 Apr 2009 14:29:14 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id DB63F3A67A1 for ; Thu, 2 Apr 2009 14:29:14 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n32LUGhC023064 for ; Thu, 2 Apr 2009 21:30:16 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n32LUG8M013099 for ; Thu, 2 Apr 2009 15:30:16 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32LKwY0002174; Thu, 2 Apr 2009 16:20:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32LKwKP002173; Thu, 2 Apr 2009 16:20:58 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 2 Apr 2009 16:20:58 -0500 From: Nicolas Williams To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090402212057.GF1500@Sun.COM> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <49D4DC43.1080905@gmail.com> <20090402155447.GN1500@Sun.COM> <49D5286A.1040606@network-heretics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D5286A.1040606@network-heretics.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:29:15 -0000 On Thu, Apr 02, 2009 at 05:04:42PM -0400, Keith Moore wrote: > Nicolas Williams wrote: > > On Thu, Apr 02, 2009 at 11:39:47AM -0400, Dan Winship wrote: > >> Keith Moore wrote: > >>> For the most part, users don't have to see these things. > >> At some point, the user's computer needs to figure out what time zone it > >> is in, and likewise for the user's calendar app. If there is not a > >> standard protocol for doing this automatically somehow, then the user is > >> going to need to see the list of timezones, and somehow be able to pick > >> the correct one. > > > > We've been discussing several very different but related problems: > > > > 1) how to represent timezones in application protocol data; > > 2) how to represent timezones in UIs; > > 3) how to find one's current timezone. > > > > The CLDR is sufficient for (1) because if provides for canonical > > timezone names. > > false, for reasons stated earlier. IIRC you had complains about the form of the canonical name chosen for CLDR, but I don't care because (1) is about what appears on the wire (and in document meta-data) and I don't care what form that takes. > > The CLDR is sufficient for (2) because it allows for alternative, > > user-friendly and even localized timezone names. > > depends on the UI. Yes, but that's not CLDR's fault. From moore@network-heretics.com Thu Apr 2 16:30:32 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3C93A6D37 for ; Thu, 2 Apr 2009 16:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prgqcwD6so-c for ; Thu, 2 Apr 2009 16:30:31 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 2B7C73A6896 for ; Thu, 2 Apr 2009 16:30:31 -0700 (PDT) Received: from lust.indecency.org (174-151-82-40.pools.spcsdns.net [174.151.82.40]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMI83436 (AUTH admin@network-heretics.com); Thu, 2 Apr 2009 16:31:26 -0700 (PDT) Message-ID: <49D54ACB.4040409@network-heretics.com> Date: Thu, 02 Apr 2009 19:31:23 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <49D4DC43.1080905@gmail.com> <20090402155447.GN1500@Sun.COM> <49D5286A.1040606@network-heretics.com> <20090402212057.GF1500@Sun.COM> In-Reply-To: <20090402212057.GF1500@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 23:30:32 -0000 Nicolas Williams wrote: >>> We've been discussing several very different but related problems: >>> >>> 1) how to represent timezones in application protocol data; >>> 2) how to represent timezones in UIs; >>> 3) how to find one's current timezone. >>> >>> The CLDR is sufficient for (1) because if provides for canonical >>> timezone names. >> false, for reasons stated earlier. > > IIRC you had complains about the form of the canonical name chosen for > CLDR, but I don't care because (1) is about what appears on the wire > (and in document meta-data) and I don't care what form that takes. I guess we're just going to agree to disagree here. From moore@cs.utk.edu Thu Apr 2 16:45:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528633A6A9E; Thu, 2 Apr 2009 16:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpoUm4VdFU8X; Thu, 2 Apr 2009 16:45:13 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 9A6F53A6A81; Thu, 2 Apr 2009 16:45:13 -0700 (PDT) Received: from lust.indecency.org (174-151-82-40.pools.spcsdns.net [174.151.82.40]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMI84559 (AUTH admin@network-heretics.com); Thu, 2 Apr 2009 16:46:05 -0700 (PDT) Message-ID: <49D54E3A.4080702@cs.utk.edu> Date: Thu, 02 Apr 2009 19:46:02 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> <49D54893.6010008@cisco.com> In-Reply-To: <49D54893.6010008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 23:45:14 -0000 Paul Kyzivat wrote: > I agree with Keith about the inadvisability of rewriting the grammar. > Save it for SIP/3.0. > > In any case, I think the issue isn't with ABNF per se, its with the > way ABNF was used for SIP. ABNF isn't actually able to represent > everything that was desired for sip, so some things were simply > handled as exceptions in the text. > > Of course the "right" thing to do would have been to either give up on > anything that couldn't legitimately be represented, or else switch to > some other specification language that could express what was intended. not clear. IMHO, trying to specify every aspect of detail of a protocol syntax using a formal specification language can be misleading and cause more interop failures, than a looser specification written in ABNF plus some exceptions in the text. One reason for the additional failures when using the precise formal specification is that you don't really benefit from that specification unless you feed it to a program that will automatically generate the recognizer. And if you do automatically generate a recognizer from the formal specification, you often find that it doesn't report errors in the way that you'd like, doesn't perform as well as you want, etc. The trick is to design the protocol in such a way that a precise formal syntax specification is not necessary. This implies having a certain degree of simplicity and regularity in the protocol. > > But there is a big tradeoff there. At least many people are capable of > reading ABNF, and a reasonable number of those can accurately > understand what it means. A somewhat smaller, but still significant, > number can write it correctly. Its important that the people involved > in the standardization process, and that implement the standard, be > able to understand it. A more powerful specification language, that > fewer people could understand, might not be such a great choice. exactly. Keith From munjo.yu@gmail.com Thu Apr 2 17:00:52 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3693A684C; Thu, 2 Apr 2009 17:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI1pOQPj4O9T; Thu, 2 Apr 2009 17:00:51 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 8AAAE3A67B1; Thu, 2 Apr 2009 17:00:51 -0700 (PDT) Received: by qyk36 with SMTP id 36so1531351qyk.29 for ; Thu, 02 Apr 2009 17:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K3BIFiZ3yHWcZBY5RX4flunI3nIsAzsxWWjsQq9dGnY=; b=oLttBrof2mQ/QfdjJR4xFGA80XlpcSMh9KcIipxeOpF1WHgryMyY+B9zuwFHNChiW+ Hp2WdWy1y/CRnoxPYr725mv03Mj9Ikqvn15t5vIWjTk35mxxR0wqq96atVTxvWsi33Lu 0K38vKw66xU+V6QfYAnBABzdVktSU0LzdD46Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fUmpl1yf3knVLnQksMXGfZCDvysBefwSooK9H3q+qW5OWGmL8bqxHSLVxTx4zlkNEy bh5ds4Jxsl55P8CodV28EZmJw6HAudF0i4YGCsFMNxtmfV22JSjmge+JCOwqFoSecJRE lVaHW6IlT1wrj0MFeXbwa2wt1Ii7QBEzjE/zI= MIME-Version: 1.0 Received: by 10.229.84.5 with SMTP id h5mr335774qcl.25.1238716913214; Thu, 02 Apr 2009 17:01:53 -0700 (PDT) In-Reply-To: <49D54E3A.4080702@cs.utk.edu> References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> <49D54893.6010008@cisco.com> <49D54E3A.4080702@cs.utk.edu> Date: Thu, 2 Apr 2009 19:01:53 -0500 Message-ID: Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case From: Munjo Yu To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIP@ietf.org, Paul Kyzivat , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:00:52 -0000 Thanks for the historical insights. Yes, I found the following section from http://tools.ietf.org/html/draft-ietf-drums-abnf-02 3.5 Set Group: {Rule 1 Rule2} Elements enclosed in braces (squiggly brackets) are treated as a single, UNORDERED element. Its contents may occur in any order. Hence: {elem foo} bar would match (elem foo bar) and (foo elem bar). NOTE: Specifying alternatives is quite different from specifying set grouping. Alternatives indicate the matching of exactly one (sub-)rule out of the total grouping. The set mechanism indicates the matching of a string which contains all of the elements within the group; however the elements may occur in any order. And it was dropped from the following revisions. To understand the ambiguity Keith mentioned, I tried to find any discussion archives which led to the decision, but no luck so far. Anyone knows about such an archive somewhere? thanks, -Munjo On Thu, Apr 2, 2009 at 6:46 PM, Keith Moore wrote: > Paul Kyzivat wrote: >> I agree with Keith about the inadvisability of rewriting the grammar. >> Save it for SIP/3.0. >> >> In any case, I think the issue isn't with ABNF per se, its with the >> way ABNF was used for SIP. ABNF isn't actually able to represent >> everything that was desired for sip, so some things were simply >> handled as exceptions in the text. >> >> Of course the "right" thing to do would have been to either give up on >> anything that couldn't legitimately be represented, or else switch to >> some other specification language that could express what was intended. > not clear. =A0IMHO, trying to specify every aspect of detail of a protoco= l > syntax using a formal specification language can be misleading and cause > more interop failures, than a looser specification written in ABNF plus > some exceptions in the text. =A0 One reason for the additional failures > when using the precise formal specification is that you don't really > benefit from that specification unless you feed it to a program that > will automatically generate the recognizer. =A0And if you do automaticall= y > generate a recognizer from the formal specification, you often find that > it doesn't report errors in the way that you'd like, doesn't perform as > well as you want, etc. > > The trick is to design the protocol in such a way that a precise formal > syntax specification is not necessary. =A0 This implies having a certain > degree of simplicity and regularity in the protocol. >> >> But there is a big tradeoff there. At least many people are capable of >> reading ABNF, and a reasonable number of those can accurately >> understand what it means. A somewhat smaller, but still significant, >> number can write it correctly. Its important that the people involved >> in the standardization process, and that implement the standard, be >> able to understand it. A more powerful specification language, that >> fewer people could understand, might not be such a great choice. > exactly. > > Keith > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From john-ietf@jck.com Thu Apr 2 18:45:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E2B3A6D29; Thu, 2 Apr 2009 18:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVqvHhQk76rt; Thu, 2 Apr 2009 18:45:55 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 818383A6C2A; Thu, 2 Apr 2009 18:45:55 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LpYUf-000N6E-Qw; Thu, 02 Apr 2009 21:46:54 -0400 Date: Thu, 02 Apr 2009 21:46:53 -0400 From: John C Klensin To: Keith Moore , Paul Kyzivat Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case Message-ID: <3144A139F1F4B00535C2A8F4@PST.JCK.COM> In-Reply-To: <49D54E3A.4080702@cs.utk.edu> References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> <49D54893.6010008@cisco.com> <49D54E3A.4080702@cs.utk.edu> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: SIP@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:45:56 -0000 --On Thursday, April 02, 2009 19:46 -0400 Keith Moore wrote: > not clear. IMHO, trying to specify every aspect of detail of > a protocol syntax using a formal specification language can be > misleading and cause more interop failures, than a looser > specification written in ABNF plus some exceptions in the > text. One reason for the additional failures when using the > precise formal specification is that you don't really benefit > from that specification unless you feed it to a program that > will automatically generate the recognizer. And if you do > automatically generate a recognizer from the formal > specification, you often find that it doesn't report errors in > the way that you'd like, doesn't perform as well as you want, > etc. Yes. And if the protocol is even nearly as complicated as SIP, you need a formal language that can specify semantics as well as syntax to get even close to a full description of the protocol. Syntax alone just doesn't do it. I would slightly disagree with Keith's characterization because those things can be good for generating reference implementations that can be checked against production ones to see if the latter are working correctly. But I agree that such a reference implementation isn't likely to be something one would like to use in production for the reasons he gives. I could suggest a few specification languages of that variety from experience (and there are more in the literature), but, as you point out... >> But there is a big tradeoff there. At least many people are >> capable of reading ABNF, and a reasonable number of those can >> accurately understand what it means. A somewhat smaller, but >> still significant, number can write it correctly. Its >> important that the people involved in the standardization >> process, and that implement the standard, be able to >> understand it. A more powerful specification language, that >> fewer people could understand, might not be such a great >> choice. >... the languages that can be used to specify not just static syntax but semantics and actions require serious work to understand how to read and even more to be able to write, leading to only a small population who can really understand such a specification. That is usually considered bad news although I've been in situations in which it is considered job security. > The trick is to design the protocol in such a way that a > precise formal syntax specification is not necessary. This > implies having a certain degree of simplicity and regularity > in the protocol. Unfortunately, SIP probably fails the test that implies. And no alternate choice of specification method is going to change that. john From moore@network-heretics.com Thu Apr 2 19:47:08 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454373A6A02 for ; Thu, 2 Apr 2009 19:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEKkD0Z2YhHH for ; Thu, 2 Apr 2009 19:47:07 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id A92323A6962 for ; Thu, 2 Apr 2009 19:47:07 -0700 (PDT) Received: from lust.indecency.org (99-205-32-250.pools.spcsdns.net [99.205.32.250]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMI96392 (AUTH admin@network-heretics.com); Thu, 2 Apr 2009 19:47:58 -0700 (PDT) Message-ID: <49D578D2.30708@network-heretics.com> Date: Thu, 02 Apr 2009 22:47:46 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <49D4DC43.1080905@gmail.com> <20090402155447.GN1500@Sun.COM> <27E64EE2D15343EAC03C782D@caldav.corp.apple.com> <20090402162655.GT1500@Sun.COM> In-Reply-To: <20090402162655.GT1500@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:47:08 -0000 Nicolas Williams wrote: > You can't resolve all such problems automatically. If I schedule an > event for 2010-04-01 10:00:00 EDT and Congress changes EDT to start on > the following Sunday then what happens? if EDT appears as a timezone in an event description, it's a bug in the software that generated that event description. > Should the schedule change to be at 9AM EST, or should the schedule be updated to show 2010-04-01 > 10:00:00 EST? the right thing is for the user agent that generates the event description to not offer EDT as an option. what should the receiving system do? probably flag the event as malformed because it's ambiguous, and let the user try to resolve the ambiguity. Keith From fanf2@hermes.cam.ac.uk Fri Apr 3 06:10:01 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31E23A6DA0 for ; Fri, 3 Apr 2009 06:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dBESv3XqN-z for ; Fri, 3 Apr 2009 06:10:00 -0700 (PDT) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by core3.amsl.com (Postfix) with ESMTP id 19BB73A6D0C for ; Fri, 3 Apr 2009 06:10:00 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51251) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1LpjAi-0006Md-4L (Exim 4.70) (return-path ); Fri, 03 Apr 2009 14:11:00 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LpjAi-0002F2-Ad (Exim 4.67) (return-path ); Fri, 03 Apr 2009 14:11:00 +0100 Date: Fri, 3 Apr 2009 14:11:00 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... In-Reply-To: <20090402162655.GT1500@Sun.COM> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <20090401204233.GQ9992@Sun.COM> <49D3DC65.7080004@network-heretics.com> <49D4DC43.1080905@gmail.com> <20090402155447.GN1500@Sun.COM> <27E64EE2D15343EAC03C782D@caldav.corp.apple.com> <20090402162655.GT1500@Sun.COM> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Apps Discuss , Keith Moore , Eliot Lear X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:10:01 -0000 On Thu, 2 Apr 2009, Nicolas Williams wrote: > > You can't resolve all such problems automatically. I believe the only cases that need manual assistance are: * Events whose scheduling depends on the DST transition itself, i.e. those occurring in the early hours of the affected Sundays. * Events that occur in multipls places (e.g. transatlantic flights or conference calls) where the tz change does not affect all the places. Other events should not need to be modified. If they do need to be modified then you've fixed the events' tz data too early. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From bortzmeyer@nic.fr Fri Apr 3 08:42:29 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D047E3A6D54 for ; Fri, 3 Apr 2009 08:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.562 X-Spam-Level: X-Spam-Status: No, score=-5.562 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDpWkNfudt40 for ; Fri, 3 Apr 2009 08:42:29 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id F173E3A6C87 for ; Fri, 3 Apr 2009 08:42:28 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id F17331C01AF; Fri, 3 Apr 2009 17:38:29 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id ECCB51C0166; Fri, 3 Apr 2009 17:38:29 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id EA624A1DC3D; Fri, 3 Apr 2009 17:38:29 +0200 (CEST) Date: Fri, 3 Apr 2009 17:38:29 +0200 From: Stephane Bortzmeyer To: zhangguoqiang Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <20090403153829.GA19074@nic.fr> References: <200904011116363933242@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904011116363933242@cnnic.cn> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: YAO Jiankang , apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:42:29 -0000 On Wed, Apr 01, 2009 at 11:16:36AM +0800, zhangguoqiang wrote a message of 156 lines which said: > Our keyword-based addressing draft is available at > http://tools.ietf.org/html/draft-zhang-keyword-ddds-00, which > specifies keyword-based addressing as a DDDS application. OK, I've read the draft and here are my remarks. First, the way I understand section 3.1, the fully-qualified keyword will be something like cn:+huawei or cn:=li Correct? If so, I seriously doubt it is simpler for users to type cn:+huawei than huawei.cn. The draft seems to imply that country-codes could be omitted when in a given country but the corean travelling to China will have to remember to add kr: in front on every keyword he's used to. It does not seem very convenient to me. Frankly, I do not see the advantage over domain names. There is a policy issue with the organization stricly by country: some countries may wish to decline participation. And some people may wish to use a system different than their national one. Now, about the use of the DNS, guidance like "Clients are encouraged to check for additional information but are not required to do so." seem to contradict RFC 2181, section 5.4.1. Sentences like "Until all resolvers can handle larger responses" are incorrect (the problem is typically not in resolvers but in middleboxes, see the Nominet report, for instance). A nit: RFC 2396 has been replaced by RFC 3986. From pkyzivat@cisco.com Thu Apr 2 16:20:55 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958DC3A6A90; Thu, 2 Apr 2009 16:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS9keDcK80Ag; Thu, 2 Apr 2009 16:20:54 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3F9153A6832; Thu, 2 Apr 2009 16:20:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,316,1235952000"; d="scan'208";a="40856503" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2009 23:21:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32NLtq2031656; Thu, 2 Apr 2009 19:21:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n32NLtD2009409; Thu, 2 Apr 2009 23:21:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:21:55 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:21:55 -0400 Message-ID: <49D54893.6010008@cisco.com> Date: Thu, 02 Apr 2009 19:21:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Keith Moore Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> In-Reply-To: <49D4461E.2050709@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2009 23:21:55.0311 (UTC) FILETIME=[CFE05FF0:01C9B3E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2483; t=1238714515; x=1239578515; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Proposal=20of=20Non-Sequential= 20Group=20Notion=20in=20ABNF=20w/=20a=20SIP=0A=20case |Sender:=20 |To:=20Keith=20Moore=20; bh=PeI3kt52QyeXAh3J5uEedocGElBaUBqSbKd859IejA4=; b=SK7ST/WSp0ySWS+3RZtoz7QtpKXCs3/D2fw3QlIK1CVYbDe/MKbC4fTW2S 0MrcXdVD4K30ErpImB/9fnb3BMJpi6Ev1X4tCCToV+C4zLdMcI4/9bhozZ45 HHabDWbKQC; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Sun, 05 Apr 2009 10:07:43 -0700 Cc: SIP@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 23:20:55 -0000 I agree with Keith about the inadvisability of rewriting the grammar. Save it for SIP/3.0. In any case, I think the issue isn't with ABNF per se, its with the way ABNF was used for SIP. ABNF isn't actually able to represent everything that was desired for sip, so some things were simply handled as exceptions in the text. Of course the "right" thing to do would have been to either give up on anything that couldn't legitimately be represented, or else switch to some other specification language that could express what was intended. But there is a big tradeoff there. At least many people are capable of reading ABNF, and a reasonable number of those can accurately understand what it means. A somewhat smaller, but still significant, number can write it correctly. Its important that the people involved in the standardization process, and that implement the standard, be able to understand it. A more powerful specification language, that fewer people could understand, might not be such a great choice. Thanks, Paul Keith Moore wrote: > eburger wrote: >> Personally, I don't understand why we didn't just use YACC. > Exercise: write an RFC ?822 parse in yacc. It can be done, but not > easily, as the RFC ?822 grammar is not LALR(1). >> I am really in favor of using a formal language for specifying grammar. As Munjo states, the ABNF is essentially documentation fluff - useless at best and wrong at worst. >> >> As for this particular suggestion, I am ambivalent as to whether we hack ABNF, adopt YACC, or even adopt ASN.1. > One lesson from the DRUMS effort - rewrite an existing grammar at your > peril. Even if the old specification has errors, writing a new grammar > which verifiably recognizes exactly the same language as the old one can > be difficult. And even if you restrict the language that new > implementations can emit, you generally have to accept the old language > for compatibility's sake. So you end up with two grammars where one was > formerly (almost) good enough. > > Keith > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From mnot@mnot.net Mon Apr 6 02:34:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93BA28C0DB for ; Mon, 6 Apr 2009 02:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.703 X-Spam-Level: X-Spam-Status: No, score=-4.703 tagged_above=-999 required=5 tests=[AWL=-2.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3Z-PyegNxFT for ; Mon, 6 Apr 2009 02:34:17 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id E00233A6945 for ; Mon, 6 Apr 2009 02:34:16 -0700 (PDT) Received: from [192.168.1.1] (unknown [209.131.62.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B8568D0500 for ; Mon, 6 Apr 2009 05:35:20 -0400 (EDT) Message-Id: From: Mark Nottingham To: Apps Discuss Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Soliciting reviews for Cross-Origin Resource Sharing Date: Mon, 6 Apr 2009 19:35:19 +1000 X-Mailer: Apple Mail (2.930.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 09:34:18 -0000 [ with my liaison hat on] Members of the WebApps WG in the W3C have brought Cross-Origin Resource Sharing (CORS) to my attention, and asked for review/input from IETF folks. http://www.w3.org/TR/2009/WD-cors-20090317/ > This document defines a mechanism to enable client-side cross-origin > requests. Specifications that want to enable cross-origin requests > in an API they define can use the algorithms defined by this > specification. If such an API is used on http://example.org > resources, a resource on http://hello-world.example can opt in using > the mechanism described by this specification (e.g., specifying > Access-Control-Allow-Origin: http://example.org as response header), > which would allow that resource to be fetched cross-origin from http://example.org > . For those who have seen this work before, it has apparently changed significantly in its lifetime, so it's probably worth another look. The document's status section contains information about how to provide feedback to them. Cheers, -- Mark Nottingham http://www.mnot.net/ From zhangguoqiang@cnnic.cn Mon Apr 6 18:40:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00613A6929 for ; Mon, 6 Apr 2009 18:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.088 X-Spam-Level: **** X-Spam-Status: No, score=4.088 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_103=0.327, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1aBoWOeu+sN for ; Mon, 6 Apr 2009 18:40:56 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 8A3A63A68D6 for ; Mon, 6 Apr 2009 18:40:54 -0700 (PDT) Received: (eyou send program); Tue, 07 Apr 2009 09:42:00 +0800 Message-ID: <439068520.24528@cnnic.cn> Received: from 218.241.111.8 by mail.cnnic.cn with HTTP; Tue, 07 Apr 2009 09:42:00 +0800 X-WebMAIL-MUA: [218.241.111.8] From: "=?gb2312?B?1cW5+se/?=" To: bortzmeyer@nic.fr Date: Tue, 07 Apr 2009 09:42:00 +0800 X-Priority: 3 Subject: Re: Solicitation for a discussion on Keyword-based addressing Content-Type: text/plain Cc: yaojk@cnnic.cn, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?gb2312?B?1cW5+se/?= List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 01:40:57 -0000 ÔÚÄúµÄÀ´ÐÅÖÐÔø¾­Ìáµ½: >From: Stephane Bortzmeyer >Reply-To: >To: zhangguoqiang >Subject: Re: Solicitation for a discussion on Keyword-based addressing >Date:Fri, 3 Apr 2009 17:38:29 +0200 > >On Wed, Apr 01, 2009 at 11:16:36AM +0800, > zhangguoqiang wrote > a message of 156 lines which said: > > > Our keyword-based addressing draft is available at > > http://tools.ietf.org/html/draft-zhang-keyword-ddds-00, which > > specifies keyword-based addressing as a DDDS application. > > OK, I've read the draft and here are my remarks. > > First, the way I understand section 3.1, the fully-qualified keyword > will be something like cn:+huawei or cn:=li Correct? Yes, in the current version draft, the fully-qualified keyword is in this form. > If so, I seriously doubt it is simpler for users to type cn:+huawei > than huawei.cn. The draft seems to imply that country-codes could be > omitted when in a given country but the corean travelling to China > will have to remember to add kr: in front on every keyword he's used > to. It does not seem very convenient to me. Frankly, I do not see the > advantage over domain names. Your doubts make sense. There is debate on the classifier, i.e, "+","@"... Some strongly suggests total removal of the classifier. For the country code, however, the users do not need to type it each time. It can be some form of the user's settings, for example, the browser's setting. So when a korean travel's to China, he don't have to add kr: in front on every keyword he's used. If the classifier is removed, the user only need to type "huawei", which is also our ultimate goal. > There is a policy issue with the organization stricly by country: some > countries may wish to decline participation. And some people may wish > to use a system different than their national one. Policy issues are inevitable for registration-based services. However, as I said, keyword is not intended to replace DNS, It is a useful technique especially favored by non-english speaking countries and with customized writing habits. > Now, about the use of the DNS, guidance like "Clients are encouraged > to check for additional information but are not required to do so." > seem to contradict RFC 2181, section 5.4.1. Sentences like "Until all > resolvers can handle larger responses" are incorrect (the problem is > typically not in resolvers but in middleboxes, see the Nominet report, > for instance). Thanks for these comments, I will check them carefully. > A nit: RFC 2396 has been replaced by RFC 3986. Yes. > > From zhangguoqiang@cnnic.cn Mon Apr 6 19:26:40 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7130F3A6A61 for ; Mon, 6 Apr 2009 19:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.196 X-Spam-Level: **** X-Spam-Status: No, score=4.196 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_103=0.327, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBDjSuvpA-M5 for ; Mon, 6 Apr 2009 19:26:39 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 389153A6A44 for ; Mon, 6 Apr 2009 19:26:38 -0700 (PDT) Received: (eyou send program); Tue, 07 Apr 2009 10:27:43 +0800 Message-ID: <439071263.01018@cnnic.cn> Received: from 218.241.111.8 by mail.cnnic.cn with HTTP; Tue, 07 Apr 2009 10:27:43 +0800 X-WebMAIL-MUA: [218.241.111.8] From: "=?gb2312?B?1cW5+se/?=" To: ajs@shinkuro.com, apps-discuss@ietf.org Date: Tue, 07 Apr 2009 10:27:43 +0800 X-Priority: 3 Subject: Re: Solicitation for a discussion on Keyword-based addressing Content-Type: text/plain X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?gb2312?B?1cW5+se/?= List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 02:26:40 -0000 ÔÚÄúµÄÀ´ÐÅÖÐÔø¾­Ìáµ½: >From: Andrew Sullivan >Reply-To: >To: apps-discuss@ietf.org >Subject: Re: Solicitation for a discussion on Keyword-based addressing >Date:Thu, 2 Apr 2009 11:17:21 -0400 > >On Wed, Apr 01, 2009 at 11:16:36AM +0800, zhangguoqiang wrote: > > > webpage, while IDN is used to access a web site. Second, keyword > > eases user's experience by eliminating the need to remember > > potentially great number of suffixes. > > That argument is a little odd: instead of the user needing to remember > a bounded number of suffixes, the user has to remember a completely > unbounded number of keywords. Moreover, the user has to guess just > the right keyword for the particular site desired, since if keywords > are to be an addressing technology then the words in question have to > be unique to a destination. I think you misunderstood the idea. Keywords eliminates the need to remember suffixes. Compared with Keywords, domain names require users to remember not only the unbounded number of names itself( for example, "hp" part in the "hp.com"), but also the bounded number of suffixes("com" part in the "hp.com"). It is a K:1 problem where K is the number of possible suffixes. > > This is not to dismiss the arguments for keywords, but I don't think > that it actually makes a user's experience any easier except in > peculiar cases. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From bortzmeyer@nic.fr Tue Apr 7 23:33:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6BC3A6A15 for ; Tue, 7 Apr 2009 23:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUKVaQcOv+-1 for ; Tue, 7 Apr 2009 23:33:53 -0700 (PDT) Received: from mail.bortzmeyer.org (bortzmeyer-1-pt.tunnel.tserv10.par1.ipv6.he.net [IPv6:2001:470:1f12:420::2]) by core3.amsl.com (Postfix) with ESMTP id 7F1063A6962 for ; Tue, 7 Apr 2009 23:33:53 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id B046594CA0; Wed, 8 Apr 2009 08:34:57 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 3BCDD1575DF; Wed, 8 Apr 2009 08:23:25 +0200 (CEST) Date: Wed, 8 Apr 2009 08:23:25 +0200 From: =?iso-8859-1?Q?St=E9phane?= Bortzmeyer To: zhangguoqiang@cnnic.cn Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <20090408062325.GA32069@laperouse.bortzmeyer.org> References: <439068520.24528@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <439068520.24528@cnnic.cn> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Cc: yaojk@cnnic.cn, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 06:33:54 -0000 On Tue, Apr 07, 2009 at 09:42:00AM +0800, wrote a message of 66 lines which said: > It can be some form of the user's settings, for example, the > browser's setting. So when a korean travel's to China, he don't have > to add kr: in front on every keyword he's used. If he has his own machine (or if he remembers to configure it for korean keywords). With domain names, I can work in a cyber-cafe or with the machine of a friend and it works just fine. Also, the same trick is possible with domain names. A browser configured in France could certainly add '.fr' at te end of each domain name. > If the classifier is removed, the user only need to type "huawei", > which is also our ultimate goal. Creating a flat namespace does not seem a way forward. > It is a useful technique especially favored by non-english speaking > countries So, it seems the real reason is the delay in IDN deployment. If IDN were to be deployed in the root (something that should have been done years ago), I do not think there would be any reason to keep keywords. From zhangguoqiang@cnnic.cn Tue Apr 7 23:58:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7673A69DF for ; Tue, 7 Apr 2009 23:58:15 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 4.907 X-Spam-Level: **** X-Spam-Status: No, score=4.907 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZNX83DrrWx8 for ; Tue, 7 Apr 2009 23:58:14 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id C09823A6807 for ; Tue, 7 Apr 2009 23:58:12 -0700 (PDT) Received: (eyou send program); Wed, 08 Apr 2009 14:59:19 +0800 Message-ID: <439173959.18620@cnnic.cn> X-EYOUMAIL-SMTPAUTH: zhangguoqiang@cnnic.cn Received: from unknown (HELO cnnic-eae3fdf20) (218.241.111.8) by 159.226.7.146 with SMTP; Wed, 08 Apr 2009 14:59:19 +0800 Date: Wed, 8 Apr 2009 14:59:18 +0800 From: "zhangguoqiang" To: "=?gb2312?B?U3TpcGhhbmVCb3J0em1leWVy?=" References: <439068520.24528@cnnic.cn>, <439172505.26000@cnnic.cn> Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <200904081459183349275@cnnic.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon427484430671_=====" Cc: "yaojk@cnnic.cn" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 06:58:15 -0000 This is a multi-part message in MIME format. --=====001_Dragon427484430671_===== Content-Type: multipart/alternative; boundary="=====003_Dragon427484430671_=====" --=====003_Dragon427484430671_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QmVmb3JlIGFueSBmdXJ0aGVyIGFyZ3VtZW50cyBvbiB3aGV0aGVyIGl0IGlzIG5lY2Vzc2FyeSB0 byBpbnRyb2R1Y2Uga2V5d29yZHMgYW5kIHRoZSBkZXRhaWxlZCBzb2x1dGlvbi4gTGV0IG1lIGxp c3Qgc29tZSB1c2FnZSBzY2VuYXJpb3MgYW5kIHJlcXVpcmVtZW50cyBvZiBLZXl3b3Jkcywgd2hp Y2ggYWNjb21vZGF0ZXMgdGhlIHN1Z2dlc3Rpb25zIHByb3Bvc2VkIGJ5IEpvaG4uDQoNCigxKSBB IGtleXdvcmQgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBtb3JlIHRoYW4gb25lIFVSSSwgYnV0IHR5 cGljYWxseSBpcyBhc3NvY2lhdGVkIHdpdGggb25seSBvbmUgVVJJLg0KKDIpIFVzZXJzIGluIG1v c3QgY2FzZXMob3IgYnkgZGVmYXVsdCkgb25seSBuZWVkIHRvIGFjY2VzcyBrZXl3b3JkcyBpbiB0 aGVpciBvd24gY291bnRyaWVzLCBidXQgdGhlIHN5c3RlbSBzaG91bGQgcHJvdmlkZSBtZWNoYW5p c21zIHRvIGFsbG93IHVzZXJzIHRvIGFjY2VzcyBrZXl3b3JkcyBhY3Jvc3MgbmF0aW9uYWwgYm91 bmRhcmllcy4NCigzKSBLZXl3b3JkcyBzaG91bGQgYmUgc2ltcGxlIGJ1dCB3aXRob3V0IGxvc2lu ZyB1c2FiaWxpdHkuIEEgc2luZ2xlIGxldmVsIG9mIGtleXdvcmRzIGlzIGNvbW1vbiwgYnV0IHRo ZXJlIGFyZSBpbmNyZWFzaW5nIGRlbWFuZHMgZm9yIHR3byBsZXZlbCBrZXl3b3Jkcy4gRm9yIGV4 YW1wbGUsIGEgYmxvZ2dlciBwdWJsaXNoaW5nIGl0cyBibG9nIHRvIG90aGVycyB3aWxsIHVzZSB0 aGUga2V5d29yZHMgZm9ybWF0dGVkIGxpa2UgInlhaG9vYmxvZzpib2IiLiBTbyBhcyBhIGNvbXBy b21pc2UgYmV0d2VlbiBzaW1wbGljaXR5IGFuZCBwcmFjdGljYWJpbGl0eSwga2V5d29yZHMgY2Fu IGhhdmUgYXQgbW9zdCB0d28gbGV2ZWxzLiANCig0KSBLZXl3b3JkcyBzeXN0ZW0gc2hvdWxkIHJl c3BlY3QgY3VsdHVyYWwgd3JpdGluZyBjb252ZW50aW9ucy4gRm9yIHR3byBsZXZlbCBrZXl3b3Jk cywgZGlmZmVyZW50IGNvdW50cmllcyBtYXkgaGF2ZSBkaWZmZXJlbnQgd3JpdGluZyBjb252ZW50 aW9ucy4gV2VzdGVybiBwZW9wbGUgb2Z0ZW4gd3JpdGUgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgcGFy dCBpbiB0aGUgcmlnaHRtb3N0IHBvcnRpb24sIHdoaWxlIGluIG90aGVyIGNvdW50cmllcywgZm9y IGV4YW1wbGUgQ2hpbmEsIGZhdm9ycyB3cml0aW5nIHRoZSBtb3N0IHNpZ25pZmljYW50IHBhcnQg aW4gdGhlIGxlZnRtb3N0IHBvcnRpb24uIEtleXdvcmQgc3lzdGVtcyBzaG91bGQgZW5hYmxlIHZh cmlvdXMgd3JpdGluZyBjb252ZW50aW9ucy4gDQooNSlLZXl3b3JkcyBzeXN0ZW0gc2hvdWxkIGVu YWJsZSBzZXJ2ZXItc2lkZSBtYXRjaGluZyBydWxlcyB0aGF0IGNvdWxkIGFwcGx5IFVuaWNvZGUg bm9ybWFsaXphdGlvbiwgQ2FzZUZvbGRpbmcsIGV0Yy4gDQooNilLZXl3b3JkcyBzeXN0ZW0gc2hv dWxkIGVuYWJsZSBkaWZmZXJlbnQgbWF0Y2hpbmcgcnVsZXMgZm9yIGRpZmZlcmVudCBrZXl3b3Jk IHJlZ2lvbnMuDQooNylLZXl3b3JkcyBzeXN0ZW0gc2hvdWxkIGFsbG93IG11bHRpcGxlIG5hbWVz IGF0IGEgZ2l2ZW4gbm9kZSwgcmF0aGVyIHRoYW4gQ05BTUUtbGlrZSBhbGlhcyBmdW5jdGlvbiB0 aGF0IHBvaW50cyBiZXR3ZWVuIG5vZGVzLg0KDQoNCjIwMDktMDQtMDggDQoNCg0KDQp6aGFuZ2d1 b3FpYW5nIA0KDQoNCg0Kt6K8/sjLo7ogU3TpcGhhbmVCb3J0em1leWVyIA0Kt6LLzcqxvOSjuiAy MDA5LTA0LTA4ICAxNDozNTowNSANCsrVvP7Iy6O6IHpoYW5nZ3VvcWlhbmdAY25uaWMuY24gDQqz rcvNo7ogYXBwcy1kaXNjdXNzQGlldGYub3JnOyB5YW9qa0Bjbm5pYy5jbiANCtb3zOKjuiBSZTog U29saWNpdGF0aW9uIGZvciBhIGRpc2N1c3Npb24gb24gS2V5d29yZC1iYXNlZCBhZGRyZXNzaW5n IA0KIA0KT24gVHVlLCBBcHIgMDcsIDIwMDkgYXQgMDk6NDI6MDBBTSArMDgwMCwNCiAgPHpoYW5n Z3VvcWlhbmdAY25uaWMuY24gPiB3cm90ZSANCiBhIG1lc3NhZ2Ugb2YgNjYgbGluZXMgd2hpY2gg c2FpZDoNCg0KPiBJdCBjYW4gYmUgc29tZSBmb3JtIG9mIHRoZSB1c2VyJ3Mgc2V0dGluZ3MsIGZv ciBleGFtcGxlLCB0aGUNCj4gYnJvd3NlcidzIHNldHRpbmcuIFNvIHdoZW4gYSBrb3JlYW4gdHJh dmVsJ3MgdG8gQ2hpbmEsIGhlIGRvbid0IGhhdmUNCj4gdG8gYWRkIGtyOiBpbiBmcm9udCBvbiBl dmVyeSBrZXl3b3JkIGhlJ3MgdXNlZC4NCg0KSWYgaGUgaGFzIGhpcyBvd24gbWFjaGluZSAob3Ig aWYgaGUgcmVtZW1iZXJzIHRvIGNvbmZpZ3VyZSBpdCBmb3INCmtvcmVhbiBrZXl3b3JkcykuIFdp dGggZG9tYWluIG5hbWVzLCBJIGNhbiB3b3JrIGluIGEgY3liZXItY2FmZSBvcg0Kd2l0aCB0aGUg bWFjaGluZSBvZiBhIGZyaWVuZCBhbmQgaXQgd29ya3MganVzdCBmaW5lLg0KDQpBbHNvLCB0aGUg c2FtZSB0cmljayBpcyBwb3NzaWJsZSB3aXRoIGRvbWFpbiBuYW1lcy4gQSBicm93c2VyDQpjb25m aWd1cmVkIGluIEZyYW5jZSBjb3VsZCBjZXJ0YWlubHkgYWRkICcuZnInIGF0IHRlIGVuZCBvZiBl YWNoDQpkb21haW4gbmFtZS4NCg0KPiBJZiB0aGUgY2xhc3NpZmllciBpcyByZW1vdmVkLCB0aGUg dXNlciBvbmx5IG5lZWQgdG8gdHlwZSAiaHVhd2VpIiwNCj4gd2hpY2ggaXMgYWxzbyBvdXIgdWx0 aW1hdGUgZ29hbC4NCg0KQ3JlYXRpbmcgYSBmbGF0IG5hbWVzcGFjZSBkb2VzIG5vdCBzZWVtIGEg d2F5IGZvcndhcmQuDQoNCj4gSXQgaXMgYSB1c2VmdWwgdGVjaG5pcXVlIGVzcGVjaWFsbHkgZmF2 b3JlZCBieSBub24tZW5nbGlzaCBzcGVha2luZw0KPiBjb3VudHJpZXMNCg0KU28sIGl0IHNlZW1z IHRoZSByZWFsIHJlYXNvbiBpcyB0aGUgZGVsYXkgaW4gSUROIGRlcGxveW1lbnQuIElmIElETg0K d2VyZSB0byBiZSBkZXBsb3llZCBpbiB0aGUgcm9vdCAoc29tZXRoaW5nIHRoYXQgc2hvdWxkIGhh dmUgYmVlbiBkb25lDQp5ZWFycyBhZ28pLCBJIGRvIG5vdCB0aGluayB0aGVyZSB3b3VsZCBiZSBh bnkgcmVhc29uIHRvIGtlZXAga2V5d29yZHMuDQo= --=====003_Dragon427484430671_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjU3MjYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+QmVmb3JlIGFueSBmdXJ0aGVyIGFy Z3VtZW50cyBvbiANCndoZXRoZXIgaXQgaXMgbmVjZXNzYXJ5IHRvIGludHJvZHVjZSBrZXl3b3Jk cyBhbmQgdGhlIGRldGFpbGVkIHNvbHV0aW9uLiBMZXQgDQptZSZuYnNwO2xpc3Qgc29tZSB1c2Fn ZSBzY2VuYXJpb3MgYW5kIHJlcXVpcmVtZW50cyBvZiBLZXl3b3Jkcywgd2hpY2ggDQphY2NvbW9k YXRlcyB0aGUgc3VnZ2VzdGlvbnMgcHJvcG9zZWQgYnkgSm9obi48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xv cj0jMDAwMDgwPigxKSBBIGtleXdvcmQgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBtb3JlIHRoYW4g b25lIFVSSSwgDQpidXQgdHlwaWNhbGx5IGlzIGFzc29jaWF0ZWQgd2l0aCBvbmx5IG9uZSBVUkku PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPigyKSBVc2VycyBpbiBtb3N0 IGNhc2VzKG9yIGJ5IGRlZmF1bHQpIG9ubHkgbmVlZCB0byANCmFjY2VzcyBrZXl3b3JkcyBpbiB0 aGVpciBvd24gY291bnRyaWVzLCBidXQgdGhlIHN5c3RlbSBzaG91bGQgcHJvdmlkZSBtZWNoYW5p c21zIA0KdG8gYWxsb3cgdXNlcnMgdG8gYWNjZXNzIGtleXdvcmRzIGFjcm9zcyBuYXRpb25hbCBi b3VuZGFyaWVzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD4oMykgS2V5 d29yZHMgc2hvdWxkIGJlIHNpbXBsZSBidXQgd2l0aG91dCBsb3NpbmcgDQp1c2FiaWxpdHkuIEEg c2luZ2xlIGxldmVsIG9mIGtleXdvcmRzIGlzIGNvbW1vbiwgYnV0IHRoZXJlIGFyZSBpbmNyZWFz aW5nIA0KZGVtYW5kcyBmb3IgdHdvIGxldmVsIGtleXdvcmRzLiBGb3IgZXhhbXBsZSwgYSBibG9n Z2VyIHB1Ymxpc2hpbmcgaXRzIGJsb2cgdG8gDQpvdGhlcnMgd2lsbCB1c2UgdGhlIGtleXdvcmRz IGZvcm1hdHRlZCBsaWtlICJ5YWhvb2Jsb2c6Ym9iIi4gU28gYXMgYSBjb21wcm9taXNlIA0KYmV0 d2VlbiBzaW1wbGljaXR5IGFuZCBwcmFjdGljYWJpbGl0eSwga2V5d29yZHMgY2FuIGhhdmUgYXQg bW9zdCB0d28gbGV2ZWxzLiANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4 MD4oNCkgS2V5d29yZHMgc3lzdGVtIHNob3VsZCByZXNwZWN0IGN1bHR1cmFsIHdyaXRpbmcgDQpj b252ZW50aW9ucy4gPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwODA+Rm9yIHR3byBsZXZlbCBrZXl3 b3JkcywgZGlmZmVyZW50IA0KY291bnRyaWVzIG1heSBoYXZlIGRpZmZlcmVudCB3cml0aW5nIGNv bnZlbnRpb25zLiBXZXN0ZXJuIHBlb3BsZSBvZnRlbiB3cml0ZSB0aGUgDQptb3N0IHNpZ25pZmlj YW50IHBhcnQgaW4gdGhlIHJpZ2h0bW9zdCBwb3J0aW9uLCB3aGlsZSBpbiBvdGhlciBjb3VudHJp ZXMsIGZvciANCmV4YW1wbGUgQ2hpbmEsIGZhdm9ycyB3cml0aW5nIHRoZSBtb3N0IHNpZ25pZmlj YW50IHBhcnQgaW4gdGhlIGxlZnRtb3N0IHBvcnRpb24uIA0KS2V5d29yZCBzeXN0ZW1zIHNob3Vs ZCBlbmFibGUgdmFyaW91cyB3cml0aW5nIGNvbnZlbnRpb25zLiA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwODA+KDUpS2V5d29yZHMgc3lzdGVtIHNob3VsZCBlbmFibGUgc2Vy dmVyLXNpZGUgbWF0Y2hpbmcgDQpydWxlcyB0aGF0IGNvdWxkIGFwcGx5IFVuaWNvZGUgbm9ybWFs aXphdGlvbiwgQ2FzZUZvbGRpbmcsIGV0Yy4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xv cj0jMDAwMDgwPig2KUtleXdvcmRzIHN5c3RlbSBzaG91bGQgZW5hYmxlIGRpZmZlcmVudCBtYXRj aGluZyANCnJ1bGVzIGZvciBkaWZmZXJlbnQga2V5d29yZCByZWdpb25zLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD4oNylLZXl3b3JkcyBzeXN0ZW0gc2hvdWxkIGFsbG93 IG11bHRpcGxlIG5hbWVzIGF0IGEgDQpnaXZlbiBub2RlLCByYXRoZXIgdGhhbiBDTkFNRS1saWtl IGFsaWFzIGZ1bmN0aW9uIHRoYXQgcG9pbnRzIGJldHdlZW4gDQpub2Rlcy48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMw IHNpemU9Mj4yMDA5LTA0LTA4IDwvRk9OVD48L0RJVj48Rk9OVCANCmZhY2U9VmVyZGFuYSBjb2xv cj0jMDAwMDgwIHNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIg YWxpZ249bGVmdCBTSVpFPTI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xv cj0jYzBjMGMwIHNpemU9Mj48U1BBTj56aGFuZ2d1b3FpYW5nPC9TUEFOPiANCjwvRk9OVD48L0RJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8SFI+DQo8L0ZPTlQ+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz63orz+yMujujwvU1RST05H PiBTdOlwaGFuZUJvcnR6bWV5ZXIgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBzaXplPTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IDIwMDktMDQtMDgmbmJzcDsg MTQ6MzU6MDUgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiB6aGFuZ2d1b3FpYW5nQGNubmljLmNuIA0KPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+s63LzaO6PC9T VFJPTkc+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzsgDQp5YW9qa0Bjbm5pYy5jbiA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7W98zio7o8L1NUUk9O Rz4gUmU6IFNvbGljaXRhdGlvbiBmb3IgYSANCmRpc2N1c3Npb24gb24gS2V5d29yZC1iYXNlZCBh ZGRyZXNzaW5nIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48 L0ZPTlQ+IDwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPERJVj5PbiZu YnNwO1R1ZSwmbmJzcDtBcHImbmJzcDswNywmbmJzcDsyMDA5Jm5ic3A7YXQmbmJzcDswOTo0Mjow MEFNJm5ic3A7KzA4MDAsPC9ESVY+DQo8RElWPiZuYnNwOyAmbHQ7emhhbmdndW9xaWFuZ0Bjbm5p Yy5jbiAmZ3Q7Jm5ic3A7d3JvdGUmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7YSZuYnNwO21lc3Nh Z2UmbmJzcDtvZiZuYnNwOzY2Jm5ic3A7bGluZXMmbmJzcDt3aGljaCZuYnNwO3NhaWQ6PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SXQmbmJzcDtjYW4mbmJzcDtiZSZu YnNwO3NvbWUmbmJzcDtmb3JtJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDt1c2VyJ3MmbmJzcDtzZXR0 aW5ncywmbmJzcDtmb3ImbmJzcDtleGFtcGxlLCZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7YnJvd3NlcidzJm5ic3A7c2V0dGluZy4mbmJzcDtTbyZuYnNwO3doZW4mbmJzcDthJm5ic3A7 a29yZWFuJm5ic3A7dHJhdmVsJ3MmbmJzcDt0byZuYnNwO0NoaW5hLCZuYnNwO2hlJm5ic3A7ZG9u J3QmbmJzcDtoYXZlPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0byZuYnNwO2FkZCZuYnNwO2tyOiZu YnNwO2luJm5ic3A7ZnJvbnQmbmJzcDtvbiZuYnNwO2V2ZXJ5Jm5ic3A7a2V5d29yZCZuYnNwO2hl J3MmbmJzcDt1c2VkLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SWYmbmJzcDtoZSZu YnNwO2hhcyZuYnNwO2hpcyZuYnNwO293biZuYnNwO21hY2hpbmUmbmJzcDsob3ImbmJzcDtpZiZu YnNwO2hlJm5ic3A7cmVtZW1iZXJzJm5ic3A7dG8mbmJzcDtjb25maWd1cmUmbmJzcDtpdCZuYnNw O2ZvcjwvRElWPg0KPERJVj5rb3JlYW4mbmJzcDtrZXl3b3JkcykuJm5ic3A7V2l0aCZuYnNwO2Rv bWFpbiZuYnNwO25hbWVzLCZuYnNwO0kmbmJzcDtjYW4mbmJzcDt3b3JrJm5ic3A7aW4mbmJzcDth Jm5ic3A7Y3liZXItY2FmZSZuYnNwO29yPC9ESVY+DQo8RElWPndpdGgmbmJzcDt0aGUmbmJzcDtt YWNoaW5lJm5ic3A7b2YmbmJzcDthJm5ic3A7ZnJpZW5kJm5ic3A7YW5kJm5ic3A7aXQmbmJzcDt3 b3JrcyZuYnNwO2p1c3QmbmJzcDtmaW5lLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ QWxzbywmbmJzcDt0aGUmbmJzcDtzYW1lJm5ic3A7dHJpY2smbmJzcDtpcyZuYnNwO3Bvc3NpYmxl Jm5ic3A7d2l0aCZuYnNwO2RvbWFpbiZuYnNwO25hbWVzLiZuYnNwO0EmbmJzcDticm93c2VyPC9E SVY+DQo8RElWPmNvbmZpZ3VyZWQmbmJzcDtpbiZuYnNwO0ZyYW5jZSZuYnNwO2NvdWxkJm5ic3A7 Y2VydGFpbmx5Jm5ic3A7YWRkJm5ic3A7Jy5mcicmbmJzcDthdCZuYnNwO3RlJm5ic3A7ZW5kJm5i c3A7b2YmbmJzcDtlYWNoPC9ESVY+DQo8RElWPmRvbWFpbiZuYnNwO25hbWUuPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SWYmbmJzcDt0aGUmbmJzcDtjbGFzc2lmaWVy Jm5ic3A7aXMmbmJzcDtyZW1vdmVkLCZuYnNwO3RoZSZuYnNwO3VzZXImbmJzcDtvbmx5Jm5ic3A7 bmVlZCZuYnNwO3RvJm5ic3A7dHlwZSZuYnNwOyJodWF3ZWkiLDwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7d2hpY2gmbmJzcDtpcyZuYnNwO2Fsc28mbmJzcDtvdXImbmJzcDt1bHRpbWF0ZSZuYnNwO2dv YWwuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5DcmVhdGluZyZuYnNwO2EmbmJzcDtm bGF0Jm5ic3A7bmFtZXNwYWNlJm5ic3A7ZG9lcyZuYnNwO25vdCZuYnNwO3NlZW0mbmJzcDthJm5i c3A7d2F5Jm5ic3A7Zm9yd2FyZC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsm bmJzcDtJdCZuYnNwO2lzJm5ic3A7YSZuYnNwO3VzZWZ1bCZuYnNwO3RlY2huaXF1ZSZuYnNwO2Vz cGVjaWFsbHkmbmJzcDtmYXZvcmVkJm5ic3A7YnkmbmJzcDtub24tZW5nbGlzaCZuYnNwO3NwZWFr aW5nPC9ESVY+DQo8RElWPiZndDsmbmJzcDtjb3VudHJpZXM8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPlNvLCZuYnNwO2l0Jm5ic3A7c2VlbXMmbmJzcDt0aGUmbmJzcDtyZWFsJm5ic3A7 cmVhc29uJm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtkZWxheSZuYnNwO2luJm5ic3A7SUROJm5ic3A7 ZGVwbG95bWVudC4mbmJzcDtJZiZuYnNwO0lETjwvRElWPg0KPERJVj53ZXJlJm5ic3A7dG8mbmJz cDtiZSZuYnNwO2RlcGxveWVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtyb290Jm5ic3A7KHNvbWV0 aGluZyZuYnNwO3RoYXQmbmJzcDtzaG91bGQmbmJzcDtoYXZlJm5ic3A7YmVlbiZuYnNwO2RvbmU8 L0RJVj4NCjxESVY+eWVhcnMmbmJzcDthZ28pLCZuYnNwO0kmbmJzcDtkbyZuYnNwO25vdCZuYnNw O3RoaW5rJm5ic3A7dGhlcmUmbmJzcDt3b3VsZCZuYnNwO2JlJm5ic3A7YW55Jm5ic3A7cmVhc29u Jm5ic3A7dG8mbmJzcDtrZWVwJm5ic3A7a2V5d29yZHMuPC9ESVY+PC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= --=====003_Dragon427484430671_=====-- --=====001_Dragon427484430671_===== Content-Type: text/x-vcard; name="=?gb2312?B?1cW5+se/KDEpLnZjZg==?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?gb2312?B?1cW5+se/KDEpLnZjZg==?=" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOtXFO7n6x78NCkZOOtXFufrHvw0KT1JHOkNOTklD O0xhYnMNClRFTDtXT1JLO1ZPSUNFOjAxMC01ODgxMzAzOA0KVEVMO1dPUks7Vk9JQ0U6MTM0Mzkx NDA0NzkNCkFEUjtXT1JLOjs7OztCZWlqaW5nOztDaGluYQ0KTEFCRUw7V09SSztFTkNPRElORz1R VU9URUQtUFJJTlRBQkxFOg0KDQpCZWlqaW5nDQoNCkNoaW5hDQpFTUFJTDtQUkVGO0lOVEVSTkVU OnpoYW5nZ3VvcWlhbmdAY25uaWMuY24NClJFVjoyMDA5MDQwOFQxNDU5MThaDQpFTkQ6VkNBUkQN Cg== --=====001_Dragon427484430671_=====-- From randy_presuhn@mindspring.com Wed Apr 8 16:23:42 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420783A6B7F for ; Wed, 8 Apr 2009 16:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFWihHEGCi4c for ; Wed, 8 Apr 2009 16:23:41 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 849933A6B6A for ; Wed, 8 Apr 2009 16:23:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RTazGjwLen2cqAX+UZ/AKT3OR1YpylwUwbLwQLk/Anz3gXKKHBKy1om47a6LbxKk; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.221] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lrh8S-0002Cg-Q2 for apps-discuss@ietf.org; Wed, 08 Apr 2009 19:24:49 -0400 Message-ID: <002501c9b8a1$7ceca9e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <439068520.24528@cnnic.cn>, <439172505.26000@cnnic.cn> <439173959.18620@cnnic.cn> Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing Date: Wed, 8 Apr 2009 16:26:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1733f5b6410bbe3c7c05cb672a81d04fd47350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.221 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:23:42 -0000 Hi - > From: "zhangguoqiang" > To: "Sté–œhaneBortzmeyer" > Cc: ; > Sent: Tuesday, April 07, 2009 11:59 PM > Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing ... > For two level keywords, different countries may have different writing > conventions. Western people often write the most significant part in > the rightmost portion, This is the second time I've seen this assertion. It rings false, so I'd like to know just what is being claimed here. The existence of "Western" languages in which adjectives follow nouns (e.g. Spanish), precede them (e.g. German) and occur on both sides (e.g. French), as well as the widespread convention of writing numbers most-significant portion first, all seem to contradict the assertion that there is some sort of "western bias" towards putting the most significant part rightmost. Randy From zhangguoqiang@cnnic.cn Wed Apr 8 19:07:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8993A6A32 for ; Wed, 8 Apr 2009 19:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.412 X-Spam-Level: **** X-Spam-Status: No, score=4.412 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_103=0.327, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K282vIJBZnSF for ; Wed, 8 Apr 2009 19:07:03 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id DB6003A67B1 for ; Wed, 8 Apr 2009 19:07:02 -0700 (PDT) Received: (eyou send program); Thu, 09 Apr 2009 10:08:09 +0800 Message-ID: <439242889.11264@cnnic.cn> Received: from 218.241.111.8 by mail.cnnic.cn with HTTP; Thu, 09 Apr 2009 10:08:09 +0800 X-WebMAIL-MUA: [218.241.111.8] From: "=?gb2312?B?1cW5+se/?=" To: randy_presuhn@mindspring.com, apps-discuss@ietf.org Date: Thu, 09 Apr 2009 10:08:09 +0800 X-Priority: 3 Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing Content-Type: text/plain X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?gb2312?B?1cW5+se/?= List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 02:07:04 -0000 ÔÚÄúµÄÀ´ÐÅÖÐÔø¾­Ìáµ½: >From: "Randy Presuhn" >Reply-To: >To: >Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing >Date:Wed, 8 Apr 2009 16:26:47 -0700 > >Hi - > >> From: "zhangguoqiang" >> To: "StéphaneBortzmeyer" >> Cc: ; >> Sent: Tuesday, April 07, 2009 11:59 PM >> Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing >... >> For two level keywords, different countries may have different writing >> conventions. Western people often write the most significant part in >> the rightmost portion, > >This is the second time I've seen this assertion. >It rings false, so I'd like to know just what is >being claimed here. > >The existence of "Western" languages in which adjectives follow >nouns (e.g. Spanish), precede them (e.g. German) and occur on >both sides (e.g. French), as well as the widespread convention >of writing numbers most-significant portion first, all seem >to contradict the assertion that there is some sort of "western bias" >towards putting the most significant part rightmost. What I mean is domain name like writing convention, or the post mail address writing convention. For example, "pku.edu.cn", but in Chinese writing convention, "cn.edu.pku" is more preferable. >Randy > > >_______________________________________________ >Apps-Discuss mailing list >Apps-Discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discu From randy_presuhn@mindspring.com Wed Apr 8 19:27:53 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41A33A696F for ; Wed, 8 Apr 2009 19:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4WDQyN8FqgB for ; Wed, 8 Apr 2009 19:27:53 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 043413A67FA for ; Wed, 8 Apr 2009 19:27:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QfoiFrfl2lTmfvjaXFRTbPjio6Fq3uiZ1/+dq9RIYSvrp2YEetQfYZ5IRXfOZEMr; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.221] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lrk0i-000892-FI for apps-discuss@ietf.org; Wed, 08 Apr 2009 22:29:00 -0400 Message-ID: <001901c9b8bb$37e7c0e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <439242889.11264@cnnic.cn> Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing Date: Wed, 8 Apr 2009 19:30:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1739c9d895b4fe26124d26b88766f4f0a52350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.221 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 02:27:53 -0000 Hi - > From: > To: ; > Sent: Wednesday, April 08, 2009 7:08 PM > Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing ... > What I mean is domain name like writing convention, or the post mail address > writing convention. For example, "pku.edu.cn", but in Chinese writing convention, > "cn.edu.pku" is more preferable. There's nothing "western" about the order of elements in a domain name. I also do not see how "western" postal conventions are like domain names - Postal codes in the US, to the extent that they even *have* a structure, definitely put the most significant part on the left. When writing a street address, it's a mixture - in the US we write the building number first, then the street name, and then the apartment number, which means the "most significant part" is in the middle. In Germany, one writes Country code, then postal code, then the city name, which means the most significant part is on the left, and the least significant part is in the middle. The claim that domain names have some sort of "western" bias just does not hold water. Randy From zhangguoqiang@cnnic.cn Wed Apr 8 19:41:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E883A696F for ; Wed, 8 Apr 2009 19:41:54 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 4.072 X-Spam-Level: **** X-Spam-Status: No, score=4.072 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFLanGO4CCBD for ; Wed, 8 Apr 2009 19:41:53 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 777503A6AB8 for ; Wed, 8 Apr 2009 19:41:51 -0700 (PDT) Received: (eyou send program); Thu, 09 Apr 2009 10:42:58 +0800 Message-ID: <439244978.31211@cnnic.cn> X-EYOUMAIL-SMTPAUTH: zhangguoqiang@cnnic.cn Received: from unknown (HELO cnnic-eae3fdf20) (218.241.111.8) by 159.226.7.146 with SMTP; Thu, 09 Apr 2009 10:42:58 +0800 Date: Thu, 9 Apr 2009 10:43:00 +0800 From: "zhangguoqiang" To: "Randy Presuhn" , "apps-discuss@ietf.org" References: <439242889.11264@cnnic.cn>, <439244146.09485@cnnic.cn> Subject: Re: Re: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <200904091042596251896@cnnic.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon014345885081_=====" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 02:41:54 -0000 This is a multi-part message in MIME format. --=====001_Dragon014345885081_===== Content-Type: multipart/alternative; boundary="=====003_Dragon014345885081_=====" --=====003_Dragon014345885081_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIGNsYXJpZmljYXRpb24uIEkgd2lsbCByZW1vdmUgdGhlICJ3ZXN0ZXJu IiB3b3JkIGZyb20gbXkgc3RhdGVtZW50LiANCg0KWW91ciBtZW50aW9uZWQgZmFjdHMgaXMgYSBn b29kIG1lc3NhZ2UuIEl0IHByb3ZlcyB0aGUgZGl2ZXJzaXR5IG9mIHdyaXRpbmcgY29udmVudGlv bnMgYWxsIGFjcm9zcyB0aGUgd29ybGQsIHdoaWNoIHNob3VsZCBiZSByZXNwZWN0ZWQgaW4ga2V5 d29yZCBsaWtlIHNlcnZpY2VzLg0KDQoNCjIwMDktMDQtMDkgDQoNCg0KDQp6aGFuZ2d1b3FpYW5n IA0KDQoNCg0Kt6K8/sjLo7ogUmFuZHkgUHJlc3VobiANCreiy83Ksbzko7ogMjAwOS0wNC0wOSAg MTA6Mjk6MDYgDQrK1bz+yMujuiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcgDQqzrcvNo7ogDQrW98zi o7ogUmU6IFJlOiBTb2xpY2l0YXRpb24gZm9yIGEgZGlzY3Vzc2lvbiBvbiBLZXl3b3JkLWJhc2Vk IGFkZHJlc3NpbmcgDQogDQpIaSAtDQoNCj4gRnJvbTogIDx6aGFuZ2d1b3FpYW5nQGNubmljLmNu ID4NCj4gVG86ICA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbSA+OyAgPGFwcHMtZGlzY3Vz c0BpZXRmLm9yZyA+DQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDgsIDIwMDkgNzowOCBQTQ0K PiBTdWJqZWN0OiBSZTogUmU6IFNvbGljaXRhdGlvbiBmb3IgYSBkaXNjdXNzaW9uIG9uIEtleXdv cmQtYmFzZWQgYWRkcmVzc2luZw0KLi4NCj4gV2hhdCBJIG1lYW4gaXMgZG9tYWluIG5hbWUgbGlr ZSB3cml0aW5nIGNvbnZlbnRpb24sIG9yIHRoZSBwb3N0IG1haWwgYWRkcmVzcw0KPiB3cml0aW5n IGNvbnZlbnRpb24uIEZvciBleGFtcGxlLCAicGt1LmVkdS5jbiIsIGJ1dCBpbiBDaGluZXNlIHdy aXRpbmcgY29udmVudGlvbiwNCj4gImNuLmVkdS5wa3UiIGlzIG1vcmUgcHJlZmVyYWJsZS4gDQoN ClRoZXJlJ3Mgbm90aGluZyAid2VzdGVybiIgYWJvdXQgdGhlIG9yZGVyIG9mIGVsZW1lbnRzIGlu IGEgZG9tYWluIG5hbWUuDQoNCkkgYWxzbyBkbyBub3Qgc2VlIGhvdyAid2VzdGVybiIgcG9zdGFs IGNvbnZlbnRpb25zIGFyZSBsaWtlIGRvbWFpbiBuYW1lcyAtIA0KUG9zdGFsIGNvZGVzIGluIHRo ZSBVUywgdG8gdGhlIGV4dGVudCB0aGF0IHRoZXkgZXZlbiAqaGF2ZSogYSBzdHJ1Y3R1cmUsDQpk ZWZpbml0ZWx5IHB1dCB0aGUgbW9zdCBzaWduaWZpY2FudCBwYXJ0IG9uIHRoZSBsZWZ0LiAgV2hl biB3cml0aW5nIGENCnN0cmVldCBhZGRyZXNzLCBpdCdzIGEgbWl4dHVyZSAtIGluIHRoZSBVUyB3 ZSB3cml0ZSB0aGUgYnVpbGRpbmcgbnVtYmVyDQpmaXJzdCwgdGhlbiB0aGUgc3RyZWV0IG5hbWUs IGFuZCB0aGVuIHRoZSBhcGFydG1lbnQgbnVtYmVyLCB3aGljaCBtZWFucw0KdGhlICJtb3N0IHNp Z25pZmljYW50IHBhcnQiIGlzIGluIHRoZSBtaWRkbGUuICBJbiBHZXJtYW55LCBvbmUgd3JpdGVz DQpDb3VudHJ5IGNvZGUsIHRoZW4gcG9zdGFsIGNvZGUsIHRoZW4gdGhlIGNpdHkgbmFtZSwgd2hp Y2ggbWVhbnMgdGhlIG1vc3QNCnNpZ25pZmljYW50IHBhcnQgaXMgb24gdGhlIGxlZnQsIGFuZCB0 aGUgbGVhc3Qgc2lnbmlmaWNhbnQgcGFydCBpcyBpbiB0aGUNCm1pZGRsZS4gIFRoZSBjbGFpbSB0 aGF0IGRvbWFpbiBuYW1lcyBoYXZlIHNvbWUgc29ydCBvZiAid2VzdGVybiIgYmlhcw0KanVzdCBk b2VzIG5vdCBob2xkIHdhdGVyLg0KDQpSYW5keQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KQXBwcy1EaXNjdXNzIG1haWxpbmcgbGlzdA0KQXBwcy1E aXNjdXNzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fw cHMtZGlzY3Vzcw0K --=====003_Dragon014345885081_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjU3MjYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+VGhhbmtzIGZvciB5b3VyIGNsYXJp ZmljYXRpb24uIEkgDQp3aWxsIHJlbW92ZSB0aGUgIndlc3Rlcm4iIHdvcmQgZnJvbSBteSBzdGF0 ZW1lbnQuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+WW91ciBtZW50aW9uZWQgZmFjdHMg aXMgYSBnb29kIG1lc3NhZ2UuIEl0IHByb3ZlcyB0aGUgDQpkaXZlcnNpdHkgb2Ygd3JpdGluZyBj b252ZW50aW9ucyZuYnNwO2FsbCBhY3Jvc3MgdGhlIHdvcmxkLCB3aGljaCBzaG91bGQgYmUgDQpy ZXNwZWN0ZWQgaW4ga2V5d29yZCBsaWtlIHNlcnZpY2VzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjIw MDktMDQtMDkgPC9GT05UPjwvRElWPjxGT05UIA0KZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAg c2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0 IFNJWkU9Mj4NCjwvRk9OVD4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAg c2l6ZT0yPjxTUEFOPnpoYW5nZ3VvcWlhbmc8L1NQQU4+IA0KPC9GT05UPjwvRElWPjxGT05UIGZh Y2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj4NCjxIUj4NCjwvRk9OVD4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPreivP7Iy6O6PC9TVFJPTkc+IFJhbmR5IFBy ZXN1aG4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJP Tkc+t6LLzcqxvOSjujwvU1RST05HPiAyMDA5LTA0LTA5Jm5ic3A7IDEwOjI5OjA2IA0KPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+ytW8/sjLo7o8 L1NUUk9ORz4gYXBwcy1kaXNjdXNzQGlldGYub3JnIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPtb3zOKjujwvU1RST05H PiBSZTogUmU6IFNvbGljaXRhdGlvbiBmb3IgYSANCmRpc2N1c3Npb24gb24gS2V5d29yZC1iYXNl ZCBhZGRyZXNzaW5nIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9 Mj48L0ZPTlQ+IDwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPERJVj5I aSZuYnNwOy08L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtGcm9tOiZu YnNwOyAmbHQ7emhhbmdndW9xaWFuZ0Bjbm5pYy5jbiAmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJz cDtUbzombmJzcDsgJmx0O3JhbmR5X3ByZXN1aG5AbWluZHNwcmluZy5jb20gJmd0OzsmbmJzcDsg DQombHQ7YXBwcy1kaXNjdXNzQGlldGYub3JnICZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1Nl bnQ6Jm5ic3A7V2VkbmVzZGF5LCZuYnNwO0FwcmlsJm5ic3A7MDgsJm5ic3A7MjAwOSZuYnNwOzc6 MDgmbmJzcDtQTTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7U3ViamVjdDombmJzcDtSZTombmJzcDtS ZTombmJzcDtTb2xpY2l0YXRpb24mbmJzcDtmb3ImbmJzcDthJm5ic3A7ZGlzY3Vzc2lvbiZuYnNw O29uJm5ic3A7S2V5d29yZC1iYXNlZCZuYnNwO2FkZHJlc3Npbmc8L0RJVj4NCjxESVY+Li48L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwO1doYXQmbmJzcDtJJm5ic3A7bWVhbiZuYnNwO2lzJm5ic3A7ZG9t YWluJm5ic3A7bmFtZSZuYnNwO2xpa2UmbmJzcDt3cml0aW5nJm5ic3A7Y29udmVudGlvbiwmbmJz cDtvciZuYnNwO3RoZSZuYnNwO3Bvc3QmbmJzcDttYWlsJm5ic3A7YWRkcmVzczwvRElWPg0KPERJ Vj4mZ3Q7Jm5ic3A7d3JpdGluZyZuYnNwO2NvbnZlbnRpb24uJm5ic3A7Rm9yJm5ic3A7ZXhhbXBs ZSwmbmJzcDsicGt1LmVkdS5jbiIsJm5ic3A7YnV0Jm5ic3A7aW4mbmJzcDtDaGluZXNlJm5ic3A7 d3JpdGluZyZuYnNwO2NvbnZlbnRpb24sPC9ESVY+DQo8RElWPiZndDsmbmJzcDsiY24uZWR1LnBr dSImbmJzcDtpcyZuYnNwO21vcmUmbmJzcDtwcmVmZXJhYmxlLiZuYnNwOzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+VGhlcmUncyZuYnNwO25vdGhpbmcmbmJzcDsid2VzdGVybiImbmJz cDthYm91dCZuYnNwO3RoZSZuYnNwO29yZGVyJm5ic3A7b2YmbmJzcDtlbGVtZW50cyZuYnNwO2lu Jm5ic3A7YSZuYnNwO2RvbWFpbiZuYnNwO25hbWUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5JJm5ic3A7YWxzbyZuYnNwO2RvJm5ic3A7bm90Jm5ic3A7c2VlJm5ic3A7aG93Jm5ic3A7 Indlc3Rlcm4iJm5ic3A7cG9zdGFsJm5ic3A7Y29udmVudGlvbnMmbmJzcDthcmUmbmJzcDtsaWtl Jm5ic3A7ZG9tYWluJm5ic3A7bmFtZXMmbmJzcDstJm5ic3A7PC9ESVY+DQo8RElWPlBvc3RhbCZu YnNwO2NvZGVzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtVUywmbmJzcDt0byZuYnNwO3RoZSZuYnNw O2V4dGVudCZuYnNwO3RoYXQmbmJzcDt0aGV5Jm5ic3A7ZXZlbiZuYnNwOypoYXZlKiZuYnNwO2Em bmJzcDtzdHJ1Y3R1cmUsPC9ESVY+DQo8RElWPmRlZmluaXRlbHkmbmJzcDtwdXQmbmJzcDt0aGUm bmJzcDttb3N0Jm5ic3A7c2lnbmlmaWNhbnQmbmJzcDtwYXJ0Jm5ic3A7b24mbmJzcDt0aGUmbmJz cDtsZWZ0LiZuYnNwOyZuYnNwO1doZW4mbmJzcDt3cml0aW5nJm5ic3A7YTwvRElWPg0KPERJVj5z dHJlZXQmbmJzcDthZGRyZXNzLCZuYnNwO2l0J3MmbmJzcDthJm5ic3A7bWl4dHVyZSZuYnNwOy0m bmJzcDtpbiZuYnNwO3RoZSZuYnNwO1VTJm5ic3A7d2UmbmJzcDt3cml0ZSZuYnNwO3RoZSZuYnNw O2J1aWxkaW5nJm5ic3A7bnVtYmVyPC9ESVY+DQo8RElWPmZpcnN0LCZuYnNwO3RoZW4mbmJzcDt0 aGUmbmJzcDtzdHJlZXQmbmJzcDtuYW1lLCZuYnNwO2FuZCZuYnNwO3RoZW4mbmJzcDt0aGUmbmJz cDthcGFydG1lbnQmbmJzcDtudW1iZXIsJm5ic3A7d2hpY2gmbmJzcDttZWFuczwvRElWPg0KPERJ Vj50aGUmbmJzcDsibW9zdCZuYnNwO3NpZ25pZmljYW50Jm5ic3A7cGFydCImbmJzcDtpcyZuYnNw O2luJm5ic3A7dGhlJm5ic3A7bWlkZGxlLiZuYnNwOyZuYnNwO0luJm5ic3A7R2VybWFueSwmbmJz cDtvbmUmbmJzcDt3cml0ZXM8L0RJVj4NCjxESVY+Q291bnRyeSZuYnNwO2NvZGUsJm5ic3A7dGhl biZuYnNwO3Bvc3RhbCZuYnNwO2NvZGUsJm5ic3A7dGhlbiZuYnNwO3RoZSZuYnNwO2NpdHkmbmJz cDtuYW1lLCZuYnNwO3doaWNoJm5ic3A7bWVhbnMmbmJzcDt0aGUmbmJzcDttb3N0PC9ESVY+DQo8 RElWPnNpZ25pZmljYW50Jm5ic3A7cGFydCZuYnNwO2lzJm5ic3A7b24mbmJzcDt0aGUmbmJzcDts ZWZ0LCZuYnNwO2FuZCZuYnNwO3RoZSZuYnNwO2xlYXN0Jm5ic3A7c2lnbmlmaWNhbnQmbmJzcDtw YXJ0Jm5ic3A7aXMmbmJzcDtpbiZuYnNwO3RoZTwvRElWPg0KPERJVj5taWRkbGUuJm5ic3A7Jm5i c3A7VGhlJm5ic3A7Y2xhaW0mbmJzcDt0aGF0Jm5ic3A7ZG9tYWluJm5ic3A7bmFtZXMmbmJzcDto YXZlJm5ic3A7c29tZSZuYnNwO3NvcnQmbmJzcDtvZiZuYnNwOyJ3ZXN0ZXJuIiZuYnNwO2JpYXM8 L0RJVj4NCjxESVY+anVzdCZuYnNwO2RvZXMmbmJzcDtub3QmbmJzcDtob2xkJm5ic3A7d2F0ZXIu PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5SYW5keTwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L0RJVj4NCjxESVY+QXBwcy1EaXNjdXNzJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4N CjxESVY+QXBwcy1EaXNjdXNzQGlldGYub3JnPC9ESVY+DQo8RElWPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzPC9ESVY+PC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= --=====003_Dragon014345885081_=====-- --=====001_Dragon014345885081_===== Content-Type: text/x-vcard; name="=?gb2312?B?1cW5+se/KDEpLnZjZg==?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?gb2312?B?1cW5+se/KDEpLnZjZg==?=" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOtXFO7n6x78NCkZOOtXFufrHvw0KT1JHOkNOTklD O0xhYnMNClRFTDtXT1JLO1ZPSUNFOjAxMC01ODgxMzAzOA0KVEVMO1dPUks7Vk9JQ0U6MTM0Mzkx NDA0NzkNCkFEUjtXT1JLOjs7OztCZWlqaW5nOztDaGluYQ0KTEFCRUw7V09SSztFTkNPRElORz1R VU9URUQtUFJJTlRBQkxFOg0KDQpCZWlqaW5nDQoNCkNoaW5hDQpFTUFJTDtQUkVGO0lOVEVSTkVU OnpoYW5nZ3VvcWlhbmdAY25uaWMuY24NClJFVjoyMDA5MDQwOVQxMDQyNTlaDQpFTkQ6VkNBUkQN Cg== --=====001_Dragon014345885081_=====-- From bortzmeyer@nic.fr Fri Apr 10 02:34:44 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48523A6969 for ; Fri, 10 Apr 2009 02:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQwoGzVnWo7f for ; Fri, 10 Apr 2009 02:34:44 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 23D413A6D84 for ; Fri, 10 Apr 2009 02:34:44 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7EFB91C0100; Fri, 10 Apr 2009 11:30:51 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7A5DB1C00F8; Fri, 10 Apr 2009 11:30:51 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6E5BF7B003A; Fri, 10 Apr 2009 11:30:51 +0200 (CEST) Date: Fri, 10 Apr 2009 11:30:51 +0200 From: Stephane Bortzmeyer To: zhangguoqiang@cnnic.cn Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <20090410093051.GA24542@nic.fr> References: <439071263.01018@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <439071263.01018@cnnic.cn> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 09:34:45 -0000 On Tue, Apr 07, 2009 at 10:27:43AM +0800, wrote a message of 64 lines which said: > I think you misunderstood the idea. Keywords eliminates the need to > remember suffixes. You're playing with words: if there is a system to allow people not to type the country-code of the keyword, for instance because a korean has a default country-code of "kr", then, the same system can be applied to domain names and ".kr" can be appended automatically (many Web browsers do it for ".com", for instance). From bortzmeyer@nic.fr Fri Apr 10 02:38:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A523A6969 for ; Fri, 10 Apr 2009 02:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxqjWOPURC-S for ; Fri, 10 Apr 2009 02:38:05 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 467693A6DA2 for ; Fri, 10 Apr 2009 02:38:05 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 375F01C016A; Fri, 10 Apr 2009 11:39:13 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 32AA41C0100; Fri, 10 Apr 2009 11:39:13 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 26F867B003A; Fri, 10 Apr 2009 11:39:13 +0200 (CEST) Date: Fri, 10 Apr 2009 11:39:13 +0200 From: Stephane Bortzmeyer To: zhangguoqiang@cnnic.cn Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <20090410093913.GD24542@nic.fr> References: <439242889.11264@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <439242889.11264@cnnic.cn> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 09:38:06 -0000 On Thu, Apr 09, 2009 at 10:08:09AM +0800, wrote a message of 60 lines which said: > What I mean is domain name like writing convention, or the post mail > address writing convention. For example, "pku.edu.cn", but in > Chinese writing convention, "cn.edu.pku" is more preferable. Not just the Chinese, after all, the British wrote domain names in big-endian form for many years... Every Janet user fondly remembers it (and it is another proof that the West is not specially little-endian.) But isn't it just a UI issue? Could it be solved by the UI swapping between the "network label order" and the "host label order"? From bortzmeyer@nic.fr Fri Apr 10 02:40:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7F13A6969 for ; Fri, 10 Apr 2009 02:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPDO0QhyLQMJ for ; Fri, 10 Apr 2009 02:40:28 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id E4A2B3A6993 for ; Fri, 10 Apr 2009 02:40:27 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 711291C0102; Fri, 10 Apr 2009 11:36:35 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 6CB111C0100; Fri, 10 Apr 2009 11:36:35 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 60CBD7B003A; Fri, 10 Apr 2009 11:36:35 +0200 (CEST) Date: Fri, 10 Apr 2009 11:36:35 +0200 From: Stephane Bortzmeyer To: Randy Presuhn Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <20090410093635.GC24542@nic.fr> References: <439242889.11264@cnnic.cn> <001901c9b8bb$37e7c0e0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001901c9b8bb$37e7c0e0$6801a8c0@oemcomputer> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 09:40:28 -0000 On Wed, Apr 08, 2009 at 07:30:57PM -0700, Randy Presuhn wrote a message of 30 lines which said: > There's nothing "western" about the order of elements in a domain > name. Indeed, saying that the West is little-endian (least significant first) and the East big-endian (most significant first) is clearly false. To Randy's examples, you can add the way dates are displayed, the French and British conventions are little-endian but ISO 8601 is big-endian and the US is mixed. From duerst@it.aoyama.ac.jp Fri Apr 10 03:30:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4786F3A69C0 for ; Fri, 10 Apr 2009 03:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAEB+dSZYsUC for ; Fri, 10 Apr 2009 03:30:29 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 2932A3A68F2 for ; Fri, 10 Apr 2009 03:30:28 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n3AAVaTr012537 for ; Fri, 10 Apr 2009 19:31:36 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 7963_c4c5a218_25ba_11de_9498_001d0969ab06; Fri, 10 Apr 2009 19:31:36 +0900 Received: from [IPv6:::1] ([133.2.210.1]:59636) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 10 Apr 2009 19:29:41 +0900 Message-ID: <49DF1FBF.8020007@it.aoyama.ac.jp> Date: Fri, 10 Apr 2009 19:30:23 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: Solicitation for a discussion on Keyword-based addressing References: <439242889.11264@cnnic.cn> <20090410093913.GD24542@nic.fr> In-Reply-To: <20090410093913.GD24542@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 10:30:30 -0000 On 2009/04/10 18:39, Stephane Bortzmeyer wrote: > On Thu, Apr 09, 2009 at 10:08:09AM +0800, > wrote > a message of 60 lines which said: > >> What I mean is domain name like writing convention, or the post mail >> address writing convention. For example, "pku.edu.cn", but in >> Chinese writing convention, "cn.edu.pku" is more preferable. > > Not just the Chinese, after all, the British wrote domain names in > big-endian form for many years... Every Janet user fondly remembers it > (and it is another proof that the West is not specially > little-endian.) I think I seem to remember that I once heard Tim Berners-Lee saying that it might have been better to invert the domain name label ordering when creating URIs. But that may have been somebody else. Anyway, currently URIs are part Big-endian (scheme and path) and part little-endian (domain name), which we might call a "fair compromize". > But isn't it just a UI issue? Could it be solved by the UI swapping > between the "network label order" and the "host label order"? If it were only for personal computers, where personal means "this is mine", then maybe. But domain names have to work on billboards,..., where a per-viewer switching is slightly difficult to implement. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From alexey.melnikov@isode.com Fri Apr 10 15:17:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C28D3A68AE for ; Fri, 10 Apr 2009 15:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_SBL=1.551] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6K9e6Y9nw86 for ; Fri, 10 Apr 2009 15:17:30 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F10923A688D for ; Fri, 10 Apr 2009 15:17:29 -0700 (PDT) Received: from [92.40.40.175] (92.40.40.175.sub.mbb.three.co.uk [92.40.40.175]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 10 Apr 2009 23:18:36 +0100 Message-ID: <49DFC58C.5040802@isode.com> Date: Fri, 10 Apr 2009 23:17:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss Subject: Alexey's Apps Area Activity Report March-mid April 2009 References: <2460BD9E-DEA8-4CE9-B674-CAFE6251FC7D@messagingarchitects.com> In-Reply-To: <2460BD9E-DEA8-4CE9-B674-CAFE6251FC7D@messagingarchitects.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey-melnikov-chairs@tools.ietf.org, Lisa Dusseault X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 22:17:31 -0000 Document Status and Progress Active documents, my action: - draft-ietf-ltru-4646bis (BCP) - performing AD review now (Note: requested some extra reviews from the Apps Review Team) - draft-hollenbeck-rfc493*bis - Scott Hollenbeck has requested progression of these documents to Full Standard. I will be reviewing them shortly. - draft-ietf-webdav-bind (Experimental) - need to do AD review Active documents in IETF LC or IESG review: - draft-ietf-lemonade-notifications (Informational): on IESG telechat agenda for May 7th - draft-thomson-beep-async (Proposed Standard): waiting for IETF LC to complete before putting on IESG telechat - draft-ncook-urlauth-accessid (Proposed Standard): waiting for IETF LC to complete before putting on IESG telechat (Note: normative dependency for draft-ietf-lemonade-streaming) - draft-ietf-ltru-4645bis (Informational): in IETF LC Active documents, waiting on other: - draft-ietf-lemonade-streaming (Informational): IESG has reviewed the document on Thursday. The document had 6 DUSCUSSes, 2 of which were resolved, 2 more should be straightforward to resolve and 2 remaining need some discussion between the author/WG chairs and ADs holding the DISCUSS (Cullen, Pasi) - draft-crocker-email-arch (Proposed Standard): waiting for new revision addressing IETF LC comments (e.g. I18N section) Other actions: - Good progress on SCRAM SASL mechanism (draft-newman-auth-scram-12.txt) during SF meeting, ready for WG LC - Took over most of the DISCUSSes entered by Chris Newman - draft-ietf-bfd-base-09.txt: text proposed, waiting for a new revision/updated RFC editor note to clear - draft-ietf-avt-rtp-speex-05.txt - draft-mraihi-inch-thraud-08.txt - New DISCUSSes (waiting for RFC Editor notes/new revision) on - draft-ietf-ntp-ntpv4-proto-11.txt - draft-ietf-nsis-ntlp-19.txt - Need to review OAuth document regarding possible reuse of SCRAM - Request to review 2 new MIME types - Updated registration for "audio/3gpp" and "video/3gpp": some issues with ABNF specified by 3GPP were found, waiting for the fix - Request for registration for 3gpp-ims+xml: need to followup - Need to followup on YAM BOF WG Status: EAI - waiting for the WG to finish POP3 and IMAP drafts Lemonade - pushing dependencies for the Lemonade Profile Bis out of the door (draft-newman-auth-scram-12.txt [see above], QRESYNC (draft-ietf-lemonade-5162bis-00.txt)). Also a couple of informational documents in IESG review LTRU - WG requested IETF LC for the 2 remaining documents, I am reviewing them MORG - Good discussion about fuzzy searches, multimailbox searches in SF VCARDDAV - Mailing lis discussion about a proposal to switch to XML format in Vcard 4.0. Also a discussion about a new registry for timezone names. From john@jck.com Sat Apr 11 09:39:03 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FBA3A6A4C for ; Sat, 11 Apr 2009 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njCpWGh9APZi for ; Sat, 11 Apr 2009 09:39:02 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 980B73A6872 for ; Sat, 11 Apr 2009 09:39:02 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LsgFT-0008lf-P3; Sat, 11 Apr 2009 12:40:07 -0400 Date: Sat, 11 Apr 2009 12:40:07 -0400 From: John C Klensin To: Stephane Bortzmeyer , zhangguoqiang@cnnic.cn Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <6F5E002E97B06624FE93FB1B@PST.JCK.COM> In-Reply-To: <20090410093913.GD24542@nic.fr> References: <439242889.11264@cnnic.cn> <20090410093913.GD24542@nic.fr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 16:39:03 -0000 --On Friday, April 10, 2009 11:39 +0200 Stephane Bortzmeyer wrote: > Not just the Chinese, after all, the British wrote domain > names in big-endian form for many years... Every Janet user > fondly remembers it (and it is another proof that the West is > not specially little-endian.) > > But isn't it just a UI issue? Could it be solved by the UI > swapping between the "network label order" and the "host label > order"? Since you cite the JANET experience, I would refer you back to it for the answer to this question. Identifiers, whether domain names or otherwise, are handed to others, embedded in text, etc. When someone (or some software) cannot tell by looking which order something is in, we have a bad problem. Contemplate au.co.ac.uk and tell me whether it is left-to-right or right to left. This is one of several reasons why keyword systems should not look like domain names. One can think of many ways to do that and still retain an optional location-qualifier or system-qualifier. For example, if the keyword is "foo" and the location qualifier is "bar", then "foo.bar" and "bar.foo" are equally undesirable -- they get tied up with the ordering problem, then look like domain names, and one can't tell which is which except by position. However consider the following as just four of many examples, each of which has a precedent elsewhere: foo (the short form) foo[bar] or [bar]foo (order-independent, does not look like a domain name, but the delimiters may not be i18n-optimal) foo /country=bar/keyword=foo (in either order) > You're playing with words: if there is a system to allow > people not to type the country-code of the keyword, for > instance because a korean has a default country-code of "kr", > then, the same system can be applied to domain names and ".kr" > can be appended automatically (many Web browsers do it for > ".com", for instance). Certainly true as long as the keywords look like domain names, but see above. Where I imagine we are in agreement is that keyword systems are hardly worth the trouble if they do not offer very significant advantages over a flat-hierarchy DNS with labels expressed in a different order. For example, I'd hope to see more language sensitivity, including in matching rules, than the DNS can offer and perhaps strong alias and/or referral mechanisms, a mechanism for dealing with replicated versions of the same object that doesn't raise the URI-related problems of URNs, or similar capabilities. john From john-ietf@jck.com Sat Apr 11 10:01:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFF13A6872 for ; Sat, 11 Apr 2009 10:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO6lCuwJKG28 for ; Sat, 11 Apr 2009 10:01:27 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7D7543A6A3B for ; Sat, 11 Apr 2009 10:01:26 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Lsgb2-000923-De; Sat, 11 Apr 2009 13:02:24 -0400 Date: Sat, 11 Apr 2009 13:02:23 -0400 From: John C Klensin To: zhangguoqiang , "St?phaneBortzmeyer" Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <53C274ED9284815FF80F2BCB@PST.JCK.COM> In-Reply-To: <439173959.18620@cnnic.cn>, <200904081459183349275@cnnic.cn> References: <439068520.24528@cnnic.cn>, <439172505.26000@cnnic.cn> <439173959.18620@cnnic.cn>, <200904081459183349275@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: yaojk@cnnic.cn, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 17:01:28 -0000 --On Wednesday, April 08, 2009 14:59 +0800 zhangguoqiang wrote: > Before any further arguments on whether it is necessary to > introduce keywords and the detailed solution. Let me list some > usage scenarios and requirements of Keywords, which > accomodates the suggestions proposed by John. This material should be in the document. I suggest it would be worth your revising it to accommodate this material and your responses to the other suggestions that have been made before the discussion proceeds much further. > (1) A keyword can be associated with more than one URI, but > typically is associated with only one URI. I can see advantages to allowing this, but also disadvantages of needing a potential resolver for ambiguity. If it is "different URIs, but pointing to identical copies of the same object" it would be, IMO, fine. But note, for example, that equivalent copies of the same object are different from identical ones. "Equivalent" is often what is most desirable, but then you have to define "equivalent" unless you think that is best left to operators of keyword systems... in which case the document needs to say that and to sketch out how things would work in practice. > (2) Users in most > cases(or by default) only need to access keywords in their own > countries, but the system should provide mechanisms to allow > users to access keywords across national boundaries. See comments in my last note. I'd also encourage you to think really carefully about "country" and "national". It sets off all of the problems about internationally-standardized country codes versus the many names by which a country can be called (or might call itself), how those names are written, and how to avoid conflicts between preferred names that are problematic in ICANN these days, it may deprive you of the ability to do language-sensitive things (again, see previous note). And it means that governments will end up having to choose a single keyword operator per-country, which may not be wise in some places either. If one is going to go to the trouble of inventing a new naming system, one should try to learn as much as possible from the areas in which the DNS has not worked. I suggest that evolving into something that needs a system the size of ICANN to administer a single level of the hierarchy is something that one should strive to avoid, not re-invent. > (3) > Keywords should be simple but without losing usability. A > single level of keywords is common, but there are increasing > demands for two level keywords. For example, a blogger > publishing its blog to others will use the keywords formatted > like "yahooblog:bob". So as a compromise between simplicity > and practicability, keywords can have at most two levels. While I understand the principle of compromise, prior experience with naming systems strongly suggests that, if one needs three levels, then one is certainly likely to discover that one needs four or more. Maybe one can draw the line at two, but the above doesn't suggest two but three (it is really "[cn]yahooblog:bob" (see that previous note about this notation). >... > (5)Keywords system > should enable server-side matching rules that could apply > Unicode normalization, CaseFolding, etc. The most important server-side matching operations aren't these simple Unicode operations which, being Unicode operations, are more or less globally applicable. Think rather about being able to match Simplified and Traditional Chinese without resort to rather complex variant systems, being able to apply matching rules for Swedish and Norwegian that are sensitive to the same characters being written differently, to rules for French that are slightly case-sensitive but not entirely so, to rules for Greek that could ignore Tonos when appropriate but not when it is not, to rules for Arabic and Hebrew Scripts that would handle Harakat and "vowel points" in appropriate ways, and so on... for a rather long list of things that Unicode operations cannot provide. Certainly the Unicode matching operations should be considered as well, but we know how to fake those, more or less. > (6)Keywords system > should enable different matching rules for different keyword > regions. See above and note that your proposal (at -00) has no provision for this. > (7)Keywords system should allow multiple names at a > given node, rather than CNAME-like alias function that points > between nodes. Also see above and note that your proposal (at -00) has no provision for this. To repeat what I said above, I'd really like to see a new draft that addresses these many issues. john From dworley@nortel.com Fri Apr 10 14:56:09 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749833A67F4; Fri, 10 Apr 2009 14:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPYfhP5G+0Q0; Fri, 10 Apr 2009 14:56:08 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2ECBC3A6985; Fri, 10 Apr 2009 14:55:44 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3ALuhu01175; Fri, 10 Apr 2009 21:56:43 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 17:56:42 -0400 Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case From: "Dale Worley" To: Munjo Yu In-Reply-To: References: Content-Type: text/plain Organization: Nortel Networks Date: Fri, 10 Apr 2009 17:56:41 -0400 Message-Id: <1239400601.3742.71.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2009 21:56:42.0237 (UTC) FILETIME=[3B8D32D0:01C9BA27] X-Mailman-Approved-At: Sat, 11 Apr 2009 18:44:35 -0700 Cc: sip@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 21:56:09 -0000 On Wed, 2009-04-01 at 20:17 -0500, Munjo Yu wrote: > SET is described simply as follows, using a pair of braces: > > SET {Rule1 Rule2} As a start, I would like to see a fully accurate description of how the SET construction is written, and what its significance is. Given that SET is a *tool for writing specifications*, we must be careful to define it exactly. Currently, all we have is one example of its use. Dale From stpeter@stpeter.im Tue Apr 14 10:55:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F263A699D for ; Tue, 14 Apr 2009 10:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYjNFT+7ZvgP for ; Tue, 14 Apr 2009 10:55:53 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id E106C3A6952 for ; Tue, 14 Apr 2009 10:55:52 -0700 (PDT) Received: from wrk165.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 20F2FE800D for ; Tue, 14 Apr 2009 11:57:04 -0600 (MDT) Message-ID: <49E4CE6A.7050909@stpeter.im> Date: Tue, 14 Apr 2009 11:56:58 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: minutes from IETF 74 App Area Open Meeting X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090409030602090908010902" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:55:54 -0000 This is a cryptographically signed message in MIME format. --------------ms090409030602090908010902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Applications Area Open Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D MONDAY, March 23, 2009 0900-1130 Morning Session I Imperial B Jabber logs: http://jabber.ietf.org/logs/apparea/2009-03-23.txt Jabber Scribe: Peter Saint-Andre 1. AGENDA BASHING No bashing. 2. HTML 5 (Lisa Dusseault) Lisa provided background information regarding HTML5 efforts, and announced HTTP Bar BOF. 3. IPR and Copyright Update (Lisa Dusseault) Lisa provided background information regarding the recent confusion regarding RFC 5378 and I-D submissions. Participants raised questions/concerns about: - The current outline for a fix might be too broad - Are there anti-trust issues? - This is not an engineering problem, so the IETF does not have expertise or a track record of success - Is there potential for WG to shop between IETF areas for more palatable IPR policies? 4. Resource Discovery (Eran Hammer-Lahav) Eran discussed draft-hammer-discovery-02 (Link-based Resource Descriptor Discovery), which describes a process for obtaining information about a resource identified by a URI. It is based on Extensible Resource Descriptors (XRD), being defined at OASIS. The core idea is to use hypertext links with rel=3D"describedby"=C3=82 and type=3D"application/xrd+xml" to get from a URI to a document that describes the resource. No discussion regarding this topic. 5. Server/service Discovery (Stuart Cheshire) Stuart discussed draft-cheshire-dnsext-dns-sd-05 (DNS-Based Service Discovery), which describes a convention for naming and structuring DNS resource records so that a client can discover a list of named instances matching a given service, using standard DNS queries. Participants raised questions/concerns about: - Isn't this already standardized? - When will the RFCs be published? - What can people in AppArea do to move this along? - Does this violate some core DNS assumptions/practices (in a way bordering on misuse)? Lisa noted that we have seen different AppArea WGs define their own discovery methods, that it would be preferable to use the same underlying technology, and that dns-sd seems like a good fit for AppArea needs. 6. Timezone Definitions (Cyrus Daboo) Cyrus discussed challenges involved in time zone information, and possible solutions. Currently many operating systems and devices rely on the "tz database" (a.k.a. "the zoneinfo database" or "the Olson database) hosted by the U.S. National Institutes of Health and maintained by a small group of volunteers. Challenges: - No guarantee of the longevity of this source. - Other vendors maintain their own databases. - There are interoperability problems. - Different definitions in different products. - Information not always updated properly when there are rules changes. - Information not always updated in a timely fashion when there are data changes. Proposed solutions: (1) IANA registry for publishers of timezone data. (2) Define a timezone services protocol. (3) Work out a succession plan for the Olson database. (4) Make sure timezone data is provided "securely". Participants raised questions/concerns about: - Perhaps just use a wiki? - Use ISOC instead of IANA? (The chapters could help.) 7. SCRAM SASL Mechanism (Alexey Melnikov) Alexey provided some background information about the SCRAM mechanism for SASL and the implications of this work for AppArea efforts. The relevant drafts are draft-newman-auth-scram-10 and draft-newman-auth-scram-gs2-01. The SASL framework (RFC 4422) is used for authentication in IMAP, POP3, LDAP, SMTP, BEEP, XMPP, ManageSieve, etc. (but not HTTP). The existing SASL mechanisms are perceived to be lacking: - PLAIN lacks strong security - CRAM-MD5 is simple to implement but lacks modern features - DIGEST-MD5 is difficult to implement and has led to interoperability problems SCRAM is intended to provide a "better" password-based SASL mechanism (password not sent in cleartext, server auth, i18n, channel bindings to TLS, more modern crypto) that is simpler to implement than DIGEST-MD5. Work on SCRAM is mostly complete in the SASL WG, and early implementations are starting to appear. Need to figure out how to integrate it into HTTP. Participants raised questions/concerns about: - Deprecating CRAM-MD5 given its wide deployment. - It was noted that SCRAM is designed to replace DIGEST-MD5, not CRAM-MD5. 8. Bidirectional HTTP: BOSH, Bayeux, COMET, WebSockets, rHTTP 8a. Comet / Bayeux (Greg Wilkins) Greg summarized the Comet methodology and Bayeux protocol . It is designed to provide two-way messages between a web browser and a web server, using "long polling", a publish-subscribe model, and JSON payloads. This is all "legal" HTTP. The two-connection limit in HTTP is acceptable. Interframe communication and pipeline control would be desirable. Also interested in 1xx responses for better communication of interim status before server returns 2xx response. 8b. XMPP BOSH (Jack Moffitt) Jack summarized BOSH , an HTTP binding for XMPP traffic, originally developed in 2004. Basically emulates TCP over HTTP using "long polling" with 2+ active HTTP request/response pairs at any one time, containing XML payloads. Widely adopted in the XMPP community, with some non-XMPP deployment. Works well for XMPP and has relatively strong security (as strong as TCP, at least), although it could be simplified. 8c. Overview of BiDi HTTP technologies (Mark Lentczner) Mark provided an overview of the major known technologies in this space, comparing Bayeux, BOSH, rHTTP (draft-lentczner-rhttp-00), and Web Sockets (draft-hixie-thewebsocketprotocol) along various dimensions: long polling vs. use of HTTP upgrade, inclusion of a body vs. use of an in-band wire protocol, whether the usage is stateful or stateless, etc. 8d. Discussion Lisa noted that further discussion is welcome on the apps-discuss and httpbis lists (with a dedicated list to follow) and that BOF proposals would be welcome. 9. Intro to MMOX -- David Levine MMOX =3D Massively Multiparty Online "X" (games and applications). Much recent discussion on the mmox@ietf.org list. BOF at IETF 74. Many existing systems/services/implemenetations. Growing desire for interoperability. Work at the IETF seemed appropriate to various contributors in this space. Topics might include: - Define "shared space". - Real-time content sharing / melding. - Collaboration across trust boundaries. - How to combine graphical and object streaming. - Manage update streams between components. - Manage access to virtual spaces. - Manage access to content. Possible WG approach: - Define use cases and core problems in this space. - Adapt Open Grid Protocol to solve needs in existing ecosystem. - Foster work on future-oriented layers. 10. YAM Preview (Tony Hansen) Pointer to http://trac.tools.ietf.org/bof/trac/wiki/YamCharter for the Yet Another Mail (YAM) BOF. This is work to push a number of email-related specifications from Draft to Final. 11. XMPP Preview (Peter Saint-Andre) Preview of Extensible Messaging and Presence Protocol (XMPP) BOF. Four areas of focus: - Finish revisions to RFCs 3920 and 3921. - Improve server-to-server connections. - Define end-to-end encryption method. - Describe SIP-XMPP interworking. 12. AD Update Outgoing AD Chris Newman recognized for his years of service in the Applications Area. /psa --------------ms090409030602090908010902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWZDCC BzswggYjoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wODA3MDIyMDQzMThaFw0wOTA3MDIyMDQzMThaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDBemNDejWS/iB/hQVbp2Gd5eYWYb+z1RSPbY4RQHW/apL4auhig1FhCOrN+eN+32iYp3tm K0kv/Rrhae9UzjFMzxc3QBcuj+H6kRudhawlrjeXMX7er9sqSIO0pDlaFvs7Kq0Lz7FFZL4e whqdPfK5MROPp1ucUtI5mMkYE2y6Sll04UKoCWVK4bLsTkJGMp0lnpNRG2LaMKjZldJYe7ci bkcTsnVPF4H4SVgwQbwkfw/wSS+HzOjtng3Nzz4z572WIMCwwJnfCVDJMXpdvssejkOaVl1/ +Ewqt80sjae67rD28v8sPAs7si+JIL5SYYqCw4djCSYfeMHO7R0qox3fAgMBAAGjggNuMIID ajAMBgNVHRMEBTADAgEAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwHQYDVR0OBBYEFFObPTX8kvCsGgtLWvPiSviKgJ51MIGoBgNVHSMEgaAwgZ2AFHuJ nJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEPMIIBRwYDVR0g BIIBPjCCATowggE2BgsrBgEEAYG1NwEBBTCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBv bGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBj BgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3Js MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJNQdIoQBoFf8UslzTDD7ue89LppTEBJ w5Za9ddTSfI8MEdomLK52FfLPu1JWWlzDZrwV/MHqTNqBHeXrjUxqnrERmKIXVZpIO7tEJia cIGO2LYJoCMzXxOpIcAv2H9gVlAE0ibx3gOJ6XQGz7WUdOKouWUMf9aj1SCFJOChHTe6vSPl rPjbJufQG7mwjpTrkwUos1/rznZWDCGCTUVLWiMN5XNzg8SMOurICxPborHlERiiX/ilwmL6 JBanoCQcyL45L40cFFF923FOWCXCHY0XAj/7MmVWpMl83tNRnXaYtukNJwM2C3rSEo3GTClU IjB/0feH/9uWyMGPcF8WTxcwggc7MIIGI6ADAgECAgEpMA0GCSqGSIb3DQEBBQUAMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMDgwNzAyMjA0MzE4WhcNMDkwNzAy MjA0MzE4WjCBwjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZE ZW52ZXIxIjAgBgNVBAoTGVhNUFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0 YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWlu dC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXpjQ3o1kv4gf4UFW6dhneXmFmG/s9UUj22OEUB1v2qS +GroYoNRYQjqzfnjft9omKd7ZitJL/0a4WnvVM4xTM8XN0AXLo/h+pEbnYWsJa43lzF+3q/b KkiDtKQ5Whb7OyqtC8+xRWS+HsIanT3yuTETj6dbnFLSOZjJGBNsukpZdOFCqAllSuGy7E5C RjKdJZ6TURti2jCo2ZXSWHu3Im5HE7J1TxeB+ElYMEG8JH8P8Ekvh8zo7Z4Nzc8+M+e9liDA sMCZ3wlQyTF6Xb7LHo5DmlZdf/hMKrfNLI2nuu6w9vL/LDwLO7IviSC+UmGKgsOHYwkmH3jB zu0dKqMd3wIDAQABo4IDbjCCA2owDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRTmz01/JLwrBoLS1rz4kr4ioCe dTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAQUwggElMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIB FihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8BggrBgEFBQcC AjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0 aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0 dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au c3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCTUHSK EAaBX/FLJc0ww+7nvPS6aUxAScOWWvXXU0nyPDBHaJiyudhXyz7tSVlpcw2a8FfzB6kzagR3 l641Map6xEZiiF1WaSDu7RCYmnCBjti2CaAjM18TqSHAL9h/YFZQBNIm8d4Diel0Bs+1lHTi qLllDH/Wo9UghSTgoR03ur0j5az42ybn0Bu5sI6U65MFKLNf6852Vgwhgk1FS1ojDeVzc4PE jDrqyAsT26Kx5REYol/4pcJi+iQWp6AkHMi+OS+NHBRRfdtxTlglwh2NFwI/+zJlVqTJfN7T UZ12mLbpDScDNgt60hKNxkwpVCIwf9H3h//blsjBj3BfFk8XMIIH4jCCBcqgAwIBAgIBDzAN BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMzMyWhcNMTIx MDIyMjEwMzMyWjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuaNJbhI+IMqUCKe9V4tk5V8i2K4/VpEcvnfQTtBR z2JwLAvff48f4mzUcCHwKBYWXfiw7HHUUnJL8LhUs9GyoN8/vaO3MJVQAvQMDFnvCDNC8XPv HrWMbF+FiGphvX4884uRgFuREis8yDd0sR0qZchglhcMf6YH9X+Mujvf8pvuH+s2g2D+gcdK /kmiXK+nkhjZu19xMF9b+16UQWPmsNNfaO5O9ndCF/ddBflxrdDsDXTOtRX9xYk4nsXlGW1s QhpuhmZfkkFRvcWFSIB0Gi16EBfoNsM65igm1XGYah/oa5UZw+j3wrhMl/wUej5QD0Q5UOn9 bt8KopPixeT9eQIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYD VR0OBBYEFHuJnJKXJKGERwLLdPwu9KzcMuXzMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYB BQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j cnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0E QxZBU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFp bCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEFBQADggIBAFKXBA3bChUQsRQcXEpvvKDE036U u322ZMVh8eXxw47wIGgUPqGNLZOMbWw+lcXh2I8SOt/oY/IyAp6nlVz3t+Abvl83pCJ9k5a5 zwkKGynUBdqedkIFLyMUlEXndI3AWggVdtg0imlKgzsw/08elUMu/M6W5V40R+zgCxP/h48y VZrKXZwVFLUDi2ID6PduMZMUduVQ3YLRBObwF2v4NqAnmYctGRDuDW4CGsgGAiXCUQ89IXQ9 gIXnOuSsOiwdze1VxI4kUef1qCsB/0LXkczyWxQ3NbKJqwKY5tnMoPuZ25tUR3hSM/hsV5bk az87b4TXG8tD7QI6sGNbcYuLFtEemST7mdg2df3c3JKBYcmYBcjl90hJDV1S5XY0853hSRZ1 Usw23O9tL6tfOI0e6WKCPfn+UCfemtIi8RABvEieWrgcFyP8NhZipsJnTLyfP9e/geLDAiEa 16w0Jdsc6VV4f0HJpOZ3/sPBxZqgExstTlAEG14GuwMkgFGmIb7xZOdLtGzuQ4lBsM6yTt06 8L2gthIuBBWgZiFYBu031OU2mmPSHCUgkOwBlGBN0RUkabCzqANw7MT+NmBEYEvzccNvfmKm bT6DtkD2zaSO8Zx1QnzQWm8d6AyH+N/JxX7/LKcOQUKgUmxBdYsyQOe3hOuAsx57e5QdtDhQ 9dWr2KKcMYIDvTCCA7kCAQEwgZIwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIBKTAJBgUrDgMCGgUAoIIB/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wOTA0MTQxNzU2NThaMCMGCSqGSIb3DQEJBDEWBBRsx7eKdf16oEfCTQBNj8Ff qc8fVzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAtbYPkzcVgjifiCsD2z/8bDKVAYocY0G2InrCorxKAd97IaZfN/QvZURHWR0l 6ui3U5oeCTXG/Wl6ui1ev95ktxABvPGJXzaUynAxKosnj0jGJf4N3GhYU7OuNa1cmniI6l6N 7t7erwZgsUrQUfZcQOsSxDwhUA5EBbAvmgoufQb2SNv+egfJ0/kDOE5hhCb9dJQbGN0/Qh6U 5cLCDCZZgLmr6i3hdQyawq7mk/dzLg+7jYaov5uvxNk9LOEqCoGfnIkDqTdz+77LkvJYI6vu jR4+J41Q9DHdSK/xaf1O4zyTKK5xDLMKZDDGHwGxV7P4YlwLFLgXHaJtDaD7YMPlWwAAAAAA AA== --------------ms090409030602090908010902-- From samj@samj.net Tue Apr 14 11:52:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71133A68A8 for ; Tue, 14 Apr 2009 11:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AWL=-1.899, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kzci2Y1gfTlt for ; Tue, 14 Apr 2009 11:52:38 -0700 (PDT) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by core3.amsl.com (Postfix) with ESMTP id 874B73A659C for ; Tue, 14 Apr 2009 11:52:38 -0700 (PDT) Received: by qyk40 with SMTP id 40so1387017qyk.29 for ; Tue, 14 Apr 2009 11:53:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.85.9 with SMTP id m9mr8191610vcl.40.1239735229337; Tue, 14 Apr 2009 11:53:49 -0700 (PDT) Date: Tue, 14 Apr 2009 20:53:49 +0200 Message-ID: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> Subject: rel="shortlink" proposal for advertising short URLs in HTML/HTTP From: Sam Johnston To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 18:56:24 -0000 Evening all, I think it's time to call the grown-ups into a discussion started by a handful of web developers trying to kill off URL shorteners and associated linkrot, opaque URLs, etc. Perhaps it's just accelerating change but the decidedly ordinary rev="canonical" proposal has already taken a life of its own, springing up a blog[1], a "30 minutes or less" PoC[2], a busy twitter hashtag, even a slashdot article[3] (submitted by the "inventor" himself no less) - but more worryingly a handful of high profile implementations at sites like Ars Technica (even if there's no clients yet that will read them). The concept is simple: rather than forcing users to rely on third parties like bit.ly, tinyurl.com etc. for short links the publishers themselves can suggest link(s) in the HTTP headers and/or HTML code. The resulting URL (e.g. http://example.com/promo) will generally live as long as the content does and won't vanish when the redirector disappears (as some invariably will - there's at least a 3 figure count of them now and probably a dozen new ones every day). It's also a good deal more useful to users as it can show the source (domain) and subject (path), and when the link is exposed via HTTP HEAD the performance is at least as good as third party shorteners. A bunch of alternatives to rev="canonical" have been proposed including rel="short|shorter|shortcut|short_url|short_url|alternate|self|...", but for various reasons[4] I don't think any of them are suitable. I think rel="shortlink" would work nicely and is impossible to confuse with anything else (I got here via rel="short" and rel="shortcut"). I've roughed up a specification[5] so you can see the technical details (copied below). I'm not necessarily all that fussed about this - the concept looks good but I was basically just driving by on the weekend and saw an accident about to happen (e.g. people confusing rel and rev and knocking sites like Ars out of the search engines). Seems it caught mnot's eye too[6] and I should point out that I had every intention[7] of bringing this to your attention after having extracted consensus in the group[8]. I think link relations come relatively cheap and unless there's something I've missed helping to put another nail in the coffin of the URL shorteners is arguably a good thing. Thoughts? Sam 1. http://revcanonical.wordpress.com/ 2. http://revcanonical.appspot.com/ 3. http://developers.slashdot.org/article.pl?sid=09/04/12/1834205 4. http://code.google.com/p/shortlink/wiki/Alternatives 5. http://code.google.com/p/shortlink/wiki/Specification 6. http://www.mnot.net/blog/2009/04/14/rev_canonical_bad 7. http://samj.net/2009/04/introducing-relshort-better-alternative.html 8. http://groups.google.com/group/shortlink shortlink Specification Technical specification for the HTML/HTTP "shortlink" relation Introduction The shortlink relation allows webmasters to specify a short link to use for the resource, thereby avoiding having to obtain one from a potentially unreliable third party URL shortening service such as tinyurl.com. Such links are useful for space-constrained applications (e.g. microblogging including Twitter and mobile Internet) as well as any time URLs need to be manually entered (e.g. when they are printed or spoken). Note: Until such time as shortlink is officially standardised http://purl.org/net/shortlink should be used for standards compliance. Details The shortlink appears in two places: within the HEAD section of the HTML document: in the Link: HTTP header: Link: ; rel=shortlink Implementation Servers Servers should implement both HTML and HTTP links for efficiency and performance reasons. The shortlink should default to an automatically generated stable URI based on an existing unique identifier (e.g. http://example.com/123). Such identifiers may be compressed using base32 or similar (e.g. http://example.com/3r). URIs should be case-insensitive and avoid symbols that look or sound similar (e.g. 1 vs l), particularly when manual entry will be required (e.g. printed, spoken). Publishers should also be given the option to specify a human-friendly slug (e.g. http://example.com/promo), as users should be able to derive information about the resource (path) and its source (domain) from the URL. Where a shortlink is changed the previous URL should not be broken as it may have been stored by users. Typically this requires maintaining a register of mappings. Clients Clients that have already retrieved the document (e.g. web browsers, news readers) should parse it to discover the link rel="shortlink" element(s) and extract the href attribute from each. Clients that have the URL but not the document (e.g. microblogging software) should conduct a HTTP HEAD request and extract any Link: headers from the response. Clients should not retrieve and parse the document unless the user specifically requests it. In the event that there are multiple shortlinks then the client may choose one itself or offer the user the choice (e.g. in a drop-down list). If the client chooses one it may do so randomly, by order (first vs last) or by some quality of the URL (length, readability, etc.). From munjo.yu@gmail.com Tue Apr 14 16:47:46 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E7E3A6E62; Tue, 14 Apr 2009 16:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DAL9V9hfBWJ; Tue, 14 Apr 2009 16:47:45 -0700 (PDT) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by core3.amsl.com (Postfix) with ESMTP id 74CB83A68E1; Tue, 14 Apr 2009 16:47:45 -0700 (PDT) Received: by qyk40 with SMTP id 40so1609474qyk.29 for ; Tue, 14 Apr 2009 16:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Et0TtATIlmxh9s2/bNPfx857RmKcAulsxqVO1DJkRx0=; b=OT9DkdbhsPdk3G0DSVzrxSbVl6oJgEZR6P7NObV3sdK6UeC7HQAoZZYf6NW6mhFw8G cXRLOgJK1Ss5fgw5waDSfsLbkuWgnG6EGh/xtP6EBn4+G/WeJOSztpDXXkmu6PfNIOqd fk255er8fMdCcoNhXmzAyWa1W/j3L6EMb0/X4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tCx0THwIFh0YR/255D1JTVflwNPbQ/+Wpuy95dA2NkaX0/JDvcAssrQzPFNzxMdnyE OrhKLCeTVbjJQnE2HKk2Hi04QhxMCAGRfYA8HfnYEOSi9hEIENEiwUze0BqIJBE9WbVB +3bQrdqWAIuMycfUhVSONuxVFHDrHaeXb7CnA= MIME-Version: 1.0 Received: by 10.229.109.194 with SMTP id k2mr2325779qcp.6.1239752934137; Tue, 14 Apr 2009 16:48:54 -0700 (PDT) In-Reply-To: <1239400601.3742.71.camel@victoria-pingtel-com.us.nortel.com> References: <1239400601.3742.71.camel@victoria-pingtel-com.us.nortel.com> Date: Tue, 14 Apr 2009 19:48:54 -0400 Message-ID: Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case From: Munjo Yu To: Dale Worley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:47:46 -0000 Hi all, again. We find two keywords from the responses. - trade-off between features and simplicity - ambiguities in Set These two may well have been the main reasons why Set was dropped from the draft 3 (http://tools.ietf.org/html/draft-ietf-drums-abnf-03) about 12 years ago. Since then, Internet flourished and so did protocols. Along the line, the pivot for trading off might have shifted towards "features" from "simplicity" a little bit, we wonder. And we still hope that overall gain from adding "Set" might be positive. The biggest advantage of introducing Set again is: - self-contained definitions in describing a message whose components can come unordered. - more readability - far better for parser generation And of course, we sacrifice its simplicity, a little bit. The following is a writing of Set specifications. We are looking forward to hearing overall integrity concerns, among other things. 3.6. Variable Repetition: *Rule . . 3.6.1. Element's Repetition in Sequence, Concatenation, etc, other than Set An element with a repetition is expanded sequentially. Example: Element's Repetition in non-Set types which results in forming a Sequence group 3A =3D (A A A) So, ... Example: Sequence Group in a Set set =3D {(3A) X} =3D {(A A A) X} =3D ((A A A) X)/ (X (A A A)) =3D (A A A X) / (X A A A) Example: Sequence Group in Set set =3D {(A B C) X} =3D (A B C X) / (X A B C) 3.6.2. Element's Repetition in Set An element with a repetition in a Set is expanded non-sequentially. Example: Element's Repetition in Set set =3D {3A X} =3D {A A A X} =3D (A A A X) / (A A X A) / (A X A A) / (X A A A) 3.6.3. Set's Repetition A Set with a repetition is expanded only atomically. Example: SETa =3D {A B} 2SETa =3D 2{A B} =3D 2((A B)/(B A)) =3D ((A B) (A B)) / ((B A) (B A)) =3D (A B A B) / (B A B A) ******************** 4. ABNF Definition of ABNF . . element =3D rulename / group / set / option / char-val / num-val / prose-val set =3D "{" repetition *(1*c-wsp repetition ) "}" ; repetitions in any order Note that the rule "element" above now includes "set" and the rule set is of course the new addition for Set. In addition to probing into this new specifications, please raise a red flag for any possible disruptions of existing RFCs by this new Set, even though we are pretty sure that no existing specifications would be affected by this change. Thanks, -Munjo Yu, VineGen Inc. On Fri, Apr 10, 2009 at 5:56 PM, Dale Worley wrote: > On Wed, 2009-04-01 at 20:17 -0500, Munjo Yu wrote: >> SET is described simply as follows, using a pair of braces: >> >> SET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {Rule1 Rule2= } > > As a start, I would like to see a fully accurate description of how the > SET construction is written, and what its significance is. =A0Given that > SET is a *tool for writing specifications*, we must be careful to define > it exactly. =A0Currently, all we have is one example of its use. > > Dale > > > From moore@cs.utk.edu Tue Apr 14 16:51:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D017F3A6E91 for ; Tue, 14 Apr 2009 16:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9u+6sUgw103 for ; Tue, 14 Apr 2009 16:51:55 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id F38353A6E78 for ; Tue, 14 Apr 2009 16:51:53 -0700 (PDT) Received: from lust.indecency.org (host65-17-26-18.birch.net [65.17.26.18]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNH91923 (AUTH admin@network-heretics.com); Tue, 14 Apr 2009 16:53:02 -0700 (PDT) Message-ID: <49E521DB.8080403@cs.utk.edu> Date: Tue, 14 Apr 2009 19:52:59 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sam Johnston Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> In-Reply-To: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:51:56 -0000 I think it's interesting that PURLs started out with the notion that URLs via a 3rd party referrer could be more persistent than URLs from the original domain, and now we're proposing that an original domain's URLs might be more persistent than those through a 3rd party service. Both are correct, of course, depending on circumstances. In general I think that the fewer human meaningful components to an identifier, the more persistent you can make the binding between that identifier and whatever it originally referred to. Having the components of the identifier be meaningless reduces the temptation to change the binding associated with an identifier (from that originally established) to something that is more "current". (There are lots of versions of this. If you use file and directory names in URLs, at some point you inevitably feel the need to reorganize the directory tree - which tends to invalidate URLs based on the old tree.) What's not immediately clear to me is why you'd use anything other than the stable identifier in any links within documents. I can understand wanting to keep a set of "human friendly" identifiers that are easy for users to remember, that might change over time, but I have a more difficult time understanding why you'd want to use those in links. So anyway, I think that having a "stable" or "persistent" link in the HTTP and/or document header is a good idea. (Note: putting this in the HTTP header is more general: don't restrict this to just HTML! And putting it in the document header is somewhat risky as the link might need to change (or not) when the document is updated - existing tools certainly won't do the right thing in all cases.) Ideally, software would recognize these headers and use the stable URL in preference to other URLs when appropriate. So that when you create a bookmark to a web page, the bookmark points to the stable link by default. Or when you are editing a document and you create a link to another document, you should get the stable link by default. I think it should be possible to override the defaults, but it ought to be clear to the user/editor that he's not using the stable URL. I don't think this mechanism can work well without some sort of content management system (it can be a very primitive one) that automatically creates unique, persistent URLs for things. So it's important for web servers to _not_ generate these headers by default, but rather, to do so only when explicitly configured (presumably by a content management system). Of course, this is trying to solve the same problems for which URNs were invented, and I still think that URNs are a good approach. I'd like to see any mechanism for advertising a persistent identifier be compatible with URNs. But it doesn't bother me that people are still interested in using URLs for this purpose. Keith Sam Johnston wrote: > Evening all, > > I think it's time to call the grown-ups into a discussion started by a > handful of web developers trying to kill off URL shorteners and > associated linkrot, opaque URLs, etc. Perhaps it's just accelerating > change but the decidedly ordinary rev="canonical" proposal has already > taken a life of its own, springing up a blog[1], a "30 minutes or > less" PoC[2], a busy twitter hashtag, even a slashdot article[3] > (submitted by the "inventor" himself no less) - but more worryingly a > handful of high profile implementations at sites like Ars Technica > (even if there's no clients yet that will read them). > > The concept is simple: rather than forcing users to rely on third > parties like bit.ly, tinyurl.com etc. for short links the publishers > themselves can suggest link(s) in the HTTP headers and/or HTML code. > The resulting URL (e.g. http://example.com/promo) will generally live > as long as the content does and won't vanish when the redirector > disappears (as some invariably will - there's at least a 3 figure > count of them now and probably a dozen new ones every day). It's also > a good deal more useful to users as it can show the source (domain) > and subject (path), and when the link is exposed via HTTP HEAD the > performance is at least as good as third party shorteners. > > A bunch of alternatives to rev="canonical" have been proposed > including rel="short|shorter|shortcut|short_url|short_url|alternate|self|...", > but for various reasons[4] I don't think any of them are suitable. I > think rel="shortlink" would work nicely and is impossible to confuse > with anything else (I got here via rel="short" and rel="shortcut"). > I've roughed up a specification[5] so you can see the technical > details (copied below). > > I'm not necessarily all that fussed about this - the concept looks > good but I was basically just driving by on the weekend and saw an > accident about to happen (e.g. people confusing rel and rev and > knocking sites like Ars out of the search engines). Seems it caught > mnot's eye too[6] and I should point out that I had every intention[7] > of bringing this to your attention after having extracted consensus in > the group[8]. I think link relations come relatively cheap and unless > there's something I've missed helping to put another nail in the > coffin of the URL shorteners is arguably a good thing. > > Thoughts? > > Sam > > 1. http://revcanonical.wordpress.com/ > 2. http://revcanonical.appspot.com/ > 3. http://developers.slashdot.org/article.pl?sid=09/04/12/1834205 > 4. http://code.google.com/p/shortlink/wiki/Alternatives > 5. http://code.google.com/p/shortlink/wiki/Specification > 6. http://www.mnot.net/blog/2009/04/14/rev_canonical_bad > 7. http://samj.net/2009/04/introducing-relshort-better-alternative.html > 8. http://groups.google.com/group/shortlink > > shortlink Specification > > Technical specification for the HTML/HTTP "shortlink" relation > > Introduction > > The shortlink relation allows webmasters to specify a short link to > use for the resource, thereby avoiding having to obtain one from a > potentially unreliable third party URL shortening service such as > tinyurl.com. > > Such links are useful for space-constrained applications (e.g. > microblogging including Twitter and mobile Internet) as well as any > time URLs need to be manually entered (e.g. when they are printed or > spoken). > > Note: Until such time as shortlink is officially standardised > http://purl.org/net/shortlink should be used for standards compliance. > > Details > > The shortlink appears in two places: > > within the HEAD section of the HTML document: > > > > in the Link: HTTP header: > > Link: ; rel=shortlink > > Implementation > > Servers > > Servers should implement both HTML and HTTP links for efficiency and > performance reasons. > > The shortlink should default to an automatically generated stable URI > based on an existing unique identifier (e.g. http://example.com/123). > Such identifiers may be compressed using base32 or similar (e.g. > http://example.com/3r). URIs should be case-insensitive and avoid > symbols that look or sound similar (e.g. 1 vs l), particularly when > manual entry will be required (e.g. printed, spoken). > > Publishers should also be given the option to specify a human-friendly > slug (e.g. http://example.com/promo), as users should be able to > derive information about the resource (path) and its source (domain) > from the URL. > > Where a shortlink is changed the previous URL should not be broken as > it may have been stored by users. Typically this requires maintaining > a register of mappings. > > Clients > > Clients that have already retrieved the document (e.g. web browsers, > news readers) should parse it to discover the link rel="shortlink" > element(s) and extract the href attribute from each. > > Clients that have the URL but not the document (e.g. microblogging > software) should conduct a HTTP HEAD request and extract any Link: > headers from the response. Clients should not retrieve and parse the > document unless the user specifically requests it. > > In the event that there are multiple shortlinks then the client may > choose one itself or offer the user the choice (e.g. in a drop-down > list). If the client chooses one it may do so randomly, by order > (first vs last) or by some quality of the URL (length, readability, > etc.). > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From alexey.melnikov@isode.com Wed Apr 15 00:36:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8EC3A6A21 for ; Wed, 15 Apr 2009 00:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.045 X-Spam-Level: X-Spam-Status: No, score=-1.045 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_SBL=1.551] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM-6CjsStXxx for ; Wed, 15 Apr 2009 00:36:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9296C3A6944 for ; Wed, 15 Apr 2009 00:36:38 -0700 (PDT) Received: from [92.40.91.213] (92.40.91.213.sub.mbb.three.co.uk [92.40.91.213]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 15 Apr 2009 08:37:47 +0100 Message-ID: <49E58EA2.6050200@isode.com> Date: Wed, 15 Apr 2009 08:37:06 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =JeffH , RL 'Bob' Morgan Subject: TLS server identity verification MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 07:36:39 -0000 Folks, The issue of a document describing recommended text/template for server identity verification procedure came up again while talking about advancing EPP. As an AD, I would really like for draft-hodges-server-ident-check to be published as an RFC. And I know that Chris was keen on this as well. Jeff/Bob, do you have any cycles to work on this? Regards, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From samj@samj.net Wed Apr 15 05:07:03 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102C328C129 for ; Wed, 15 Apr 2009 05:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.174 X-Spam-Level: * X-Spam-Status: No, score=1.174 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGrEOE0YHAKi for ; Wed, 15 Apr 2009 05:07:01 -0700 (PDT) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by core3.amsl.com (Postfix) with ESMTP id B65843A6BC5 for ; Wed, 15 Apr 2009 05:07:00 -0700 (PDT) Received: by qyk40 with SMTP id 40so1915536qyk.29 for ; Wed, 15 Apr 2009 05:08:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.99.149 with SMTP id u21mr19538vcn.94.1239797292337; Wed, 15 Apr 2009 05:08:12 -0700 (PDT) In-Reply-To: <49E521DB.8080403@cs.utk.edu> References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> <49E521DB.8080403@cs.utk.edu> Date: Wed, 15 Apr 2009 14:08:12 +0200 Message-ID: <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP From: Sam Johnston To: Keith Moore Content-Type: multipart/alternative; boundary=0016e64650a0340c1d046796cd11 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 12:07:03 -0000 --0016e64650a0340c1d046796cd11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Keith, Oh my, it seems we have yet another type of link relation to cater for: immutable unique identifiers ala atom:id :) On Wed, Apr 15, 2009 at 1:52 AM, Keith Moore wrote: > I think it's interesting that PURLs started out with the notion that > URLs via a 3rd party referrer could be more persistent than URLs from > the original domain, and now we're proposing that an original domain's > URLs might be more persistent than those through a 3rd party service. > Both are correct, of course, depending on circumstances. > Persistency is not the key requirement here - shortness is (and for some applications, human-friendliness). Canonical URLs (which are generally long and stuffed with SEO juice) are very much subject to change. A human friendly shortlink like http://nike.com/just-do-it is less likely to change while shortlinks based on immutable identifiers like http://nike.com/123should never change (though the resource they point at may). In general I think that the fewer human meaningful components to an > identifier, the more persistent you can make the binding between that > identifier and whatever it originally referred to. Having the > components of the identifier be meaningless reduces the temptation to > change the binding associated with an identifier (from that originally > established) to something that is more "current". (There are lots of > versions of this. If you use file and directory names in URLs, at some > point you inevitably feel the need to reorganize the directory tree - > which tends to invalidate URLs based on the old tree.) > Agreed, the more information in the URL the less persistent it will be. URLs committed to dead tree versions (e.g. references in an academic paper) are by very definition immutable so these should be able to be updated to point at the most recent/best version of the intended resource. What's not immediately clear to me is why you'd use anything other than > the stable identifier in any links within documents. I can understand > wanting to keep a set of "human friendly" identifiers that are easy for > users to remember, that might change over time, but I have a more > difficult time understanding why you'd want to use those in links. > Say I'm microblogging or texting about some campaign, for example Greenpeace's Save the Whales. Both me and my users are going to much prefer seeing http://greenpeace.com/whales than http://tinyurl.com/aZq4b- and I'm far more likely to remember the former than the latter (even if longer). So anyway, I think that having a "stable" or "persistent" link in the > HTTP and/or document header is a good idea. (Note: putting this in the > HTTP header is more general: don't restrict this to just HTML! And > putting it in the document header is somewhat risky as the link might > need to change (or not) when the document is updated - existing tools > certainly won't do the right thing in all cases.) > Agreed, except that I'm not sure the unique ID need be resolveable to the resource - just that it allow differentiating between resources. I actually think specifying rel=canonical (that's rel, not rev) solves many of the real world problems we see today. If people want to break their own links then that's their problem. > Ideally, software would recognize these headers and use the stable URL > in preference to other URLs when appropriate. So that when you create a > bookmark to a web page, the bookmark points to the stable link by > default. Or when you are editing a document and you create a link to > another document, you should get the stable link by default. I think it > should be possible to override the defaults, but it ought to be clear to > the user/editor that he's not using the stable URL. > Again this sounds like a job for the canonical URL - I'd much rather see search engines and bookmarks having URLs like http://greenpeace.com/blog/2009/04/greenpeace-helps-save-the-whales.htmlthan http://greenpeace.com/123. > I don't think this mechanism can work well without some sort of content > management system (it can be a very primitive one) that automatically > creates unique, persistent URLs for things. So it's important for web > servers to _not_ generate these headers by default, but rather, to do so > only when explicitly configured (presumably by a content management > system). > Sure, for persistent IDs. > Of course, this is trying to solve the same problems for which URNs were > invented, and I still think that URNs are a good approach. I'd like to > see any mechanism for advertising a persistent identifier be compatible > with URNs. But it doesn't bother me that people are still interested in > using URLs for this purpose. > I personally prefer UUIDv4 (random) based URNs for this, but I think it's a completely separate need from that of shortlinks. Does that make sense? Sam Sam Johnston wrote: > > Evening all, > > > > I think it's time to call the grown-ups into a discussion started by a > > handful of web developers trying to kill off URL shorteners and > > associated linkrot, opaque URLs, etc. Perhaps it's just accelerating > > change but the decidedly ordinary rev="canonical" proposal has already > > taken a life of its own, springing up a blog[1], a "30 minutes or > > less" PoC[2], a busy twitter hashtag, even a slashdot article[3] > > (submitted by the "inventor" himself no less) - but more worryingly a > > handful of high profile implementations at sites like Ars Technica > > (even if there's no clients yet that will read them). > > > > The concept is simple: rather than forcing users to rely on third > > parties like bit.ly, tinyurl.com etc. for short links the publishers > > themselves can suggest link(s) in the HTTP headers and/or HTML code. > > The resulting URL (e.g. http://example.com/promo) will generally live > > as long as the content does and won't vanish when the redirector > > disappears (as some invariably will - there's at least a 3 figure > > count of them now and probably a dozen new ones every day). It's also > > a good deal more useful to users as it can show the source (domain) > > and subject (path), and when the link is exposed via HTTP HEAD the > > performance is at least as good as third party shorteners. > > > > A bunch of alternatives to rev="canonical" have been proposed > > including > rel="short|shorter|shortcut|short_url|short_url|alternate|self|...", > > but for various reasons[4] I don't think any of them are suitable. I > > think rel="shortlink" would work nicely and is impossible to confuse > > with anything else (I got here via rel="short" and rel="shortcut"). > > I've roughed up a specification[5] so you can see the technical > > details (copied below). > > > > I'm not necessarily all that fussed about this - the concept looks > > good but I was basically just driving by on the weekend and saw an > > accident about to happen (e.g. people confusing rel and rev and > > knocking sites like Ars out of the search engines). Seems it caught > > mnot's eye too[6] and I should point out that I had every intention[7] > > of bringing this to your attention after having extracted consensus in > > the group[8]. I think link relations come relatively cheap and unless > > there's something I've missed helping to put another nail in the > > coffin of the URL shorteners is arguably a good thing. > > > > Thoughts? > > > > Sam > > > > 1. http://revcanonical.wordpress.com/ > > 2. http://revcanonical.appspot.com/ > > 3. http://developers.slashdot.org/article.pl?sid=09/04/12/1834205 > > 4. http://code.google.com/p/shortlink/wiki/Alternatives > > 5. http://code.google.com/p/shortlink/wiki/Specification > > 6. http://www.mnot.net/blog/2009/04/14/rev_canonical_bad > > 7. http://samj.net/2009/04/introducing-relshort-better-alternative.html > > 8. http://groups.google.com/group/shortlink > > > > shortlink Specification > > > > Technical specification for the HTML/HTTP "shortlink" relation > > > > Introduction > > > > The shortlink relation allows webmasters to specify a short link to > > use for the resource, thereby avoiding having to obtain one from a > > potentially unreliable third party URL shortening service such as > > tinyurl.com. > > > > Such links are useful for space-constrained applications (e.g. > > microblogging including Twitter and mobile Internet) as well as any > > time URLs need to be manually entered (e.g. when they are printed or > > spoken). > > > > Note: Until such time as shortlink is officially standardised > > http://purl.org/net/shortlink should be used for standards compliance. > > > > Details > > > > The shortlink appears in two places: > > > > within the HEAD section of the HTML document: > > > > > > > > in the Link: HTTP header: > > > > Link: ; rel=shortlink > > > > Implementation > > > > Servers > > > > Servers should implement both HTML and HTTP links for efficiency and > > performance reasons. > > > > The shortlink should default to an automatically generated stable URI > > based on an existing unique identifier (e.g. http://example.com/123). > > Such identifiers may be compressed using base32 or similar (e.g. > > http://example.com/3r). URIs should be case-insensitive and avoid > > symbols that look or sound similar (e.g. 1 vs l), particularly when > > manual entry will be required (e.g. printed, spoken). > > > > Publishers should also be given the option to specify a human-friendly > > slug (e.g. http://example.com/promo), as users should be able to > > derive information about the resource (path) and its source (domain) > > from the URL. > > > > Where a shortlink is changed the previous URL should not be broken as > > it may have been stored by users. Typically this requires maintaining > > a register of mappings. > > > > Clients > > > > Clients that have already retrieved the document (e.g. web browsers, > > news readers) should parse it to discover the link rel="shortlink" > > element(s) and extract the href attribute from each. > > > > Clients that have the URL but not the document (e.g. microblogging > > software) should conduct a HTTP HEAD request and extract any Link: > > headers from the response. Clients should not retrieve and parse the > > document unless the user specifically requests it. > > > > In the event that there are multiple shortlinks then the client may > > choose one itself or offer the user the choice (e.g. in a drop-down > > list). If the client chooses one it may do so randomly, by order > > (first vs last) or by some quality of the URL (length, readability, > > etc.). > > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > --0016e64650a0340c1d046796cd11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Keith,

Oh my, it seems we have yet another type of link relation to= cater for: immutable unique identifiers ala atom:id :)

On Wed, Apr 15, 2009 at 1:52 AM, Keith Moore <moore@cs.utk.edu> wrote:
I think it's = interesting that PURLs started out with the notion that
URLs via a 3rd party referrer could be more persistent than URLs from
the original domain, and now we're proposing that an original domain= 9;s
URLs might be more persistent than those through a 3rd party service.
Both are correct, of course, depending on circumstances.

Persistency is not the key requirement here - shortne= ss is (and for some applications, human-friendliness). Canonical URLs (whic= h are generally long and stuffed with SEO juice) are very much subject to c= hange. A human friendly shortlink like http://nike.com/just-do-it is less likely to change while shortlinks= based on immutable identifiers like http:/= /nike.com/123 should never change (though the resource they point at ma= y).

In gene= ral I think that the fewer human meaningful components to an
identifier, the more persistent you can make the binding between that
identifier and whatever it originally referred to. =A0Having the
components of the identifier be meaningless reduces the temptation to
change the binding associated with an identifier (from that originally
established) to something that is more "current". =A0(There are l= ots of
versions of this. =A0If you use file and directory names in URLs, at some point you inevitably feel the need to reorganize the directory tree -
which tends to invalidate URLs based on the old tree.)

Agreed, the more information in the URL the less pers= istent it will be. URLs committed to dead tree versions (e.g. references in= an academic paper) are by very definition immutable so these should be abl= e to be updated to point at the most recent/best version of the intended re= source.

What= 9;s not immediately clear to me is why you'd use anything other than the stable identifier in any links within documents. =A0I can understand wanting to keep a set of "human friendly" identifiers that are ea= sy for
users to remember, that might change over time, but I have a more
difficult time understanding why you'd want to use those in links.

Say I'm microblogging or texting about some campa= ign, for example Greenpeace's Save the Whales. Both me and my users are= going to much prefer seeing http:= //greenpeace.com/whales than http://tin= yurl.com/aZq4b - and I'm far more likely to remember the former tha= n the latter (even if longer).

So anyw= ay, I think that having a "stable" or "persistent" link= in the
HTTP and/or document header is a good idea. =A0(Note: putting this in the HTTP header is more general: don't restrict this to just HTML! =A0And putting it in the document header is somewhat risky as the link might
need to change (or not) when the document is updated - existing tools
certainly won't do the right thing in all cases.)

Agreed, except that I'm not sure the unique ID ne= ed be resolveable to the resource - just that it allow differentiating betw= een resources. I actually think specifying rel=3Dcanonical (that's rel,= not rev) solves many of the real world problems we see today. If people wa= nt to break their own links then that's their problem.
=A0
Ideally,= software would recognize these headers and use the stable URL
in preference to other URLs when appropriate. So that when you create a
bookmark to a web page, the bookmark points to the stable link by
default. Or when you are editing a document and you create a link to
another document, you should get the stable link by default. =A0I think it<= br> should be possible to override the defaults, but it ought to be clear to the user/editor that he's not using the stable URL.

Again this sounds like a job for the canonical URL - = I'd much rather see search engines and bookmarks having URLs like http://greenpeace.com/blog/2009/04/greenpeace-helps-save-the-whales.ht= ml than http://greenpeace.com/123= .
=A0
I don= 9;t think this mechanism can work well without some sort of content
management system (it can be a very primitive one) that automatically
creates unique, persistent URLs for things. =A0So it's important for we= b
servers to _not_ generate these headers by default, but rather, to do so only when explicitly configured (presumably by a content management system)= .

Sure, for persistent IDs.
=A0
Of course, this is trying to sol= ve the same problems for which URNs were
invented, and I still think that URNs are a good approach. =A0I'd like = to
see any mechanism for advertising a persistent identifier be compatible
with URNs. =A0But it doesn't bother me that people are still interested= in
using URLs for this purpose.

I personally prefer UUIDv4 (random) based URNs for this, but = I think it's a completely separate need from that of shortlinks. Does t= hat make sense?

Sam

Sam Johnston wrote:
> Evening all,
>
> I think it's time to call the grown-ups into a discussion started = by a
> handful of web developers trying to kill off URL shorteners and
> associated linkrot, opaque URLs, etc. Perhaps it's just accelerati= ng
> change but the decidedly ordinary rev=3D"canonical" proposal= has already
> taken a life of its own, springing up a blog[1], a "30 minutes or=
> less" PoC[2], a busy twitter hashtag, even a slashdot article[3]<= br> > (submitted by the "inventor" himself no less) - but more wor= ryingly a
> handful of high profile implementations at sites like Ars Technica
> (even if there's no clients yet that will read them).
>
> The concept is simple: rather than forcing users to rely on third
> parties like bit.ly, <= a href=3D"http://tinyurl.com" target=3D"_blank">tinyurl.com etc. for sh= ort links the publishers
> themselves can suggest link(s) in the HTTP headers and/or HTML code. > The resulting URL (e.g. http://example.com/promo) will generally live
> as long as the content does and won't vanish when the redirector > disappears (as some invariably will - there's at least a 3 figure<= br> > count of them now and probably a dozen new ones every day). It's a= lso
> a good deal more useful to users as it can show the source (domain) > and subject (path), and when the link is exposed via HTTP HEAD the
> performance is at least as good as third party shorteners.
>
> A bunch of alternatives to rev=3D"canonical" have been propo= sed
> including rel=3D"short|shorter|shortcut|short_url|short_url|alter= nate|self|...",
> but for various reasons[4] I don't think any of them are suitable.= I
> think rel=3D"shortlink" would work nicely and is impossible = to confuse
> with anything else (I got here via rel=3D"short" and rel=3D&= quot;shortcut").
> I've roughed up a specification[5] so you can see the technical > details (copied below).
>
> I'm not necessarily all that fussed about this - the concept looks=
> good but I was basically just driving by on the weekend and saw an
> accident about to happen (e.g. people confusing rel and rev and
> knocking sites like Ars out of the search engines). Seems it caught > mnot's eye too[6] and I should point out that I had every intentio= n[7]
> of bringing this to your attention after having extracted consensus in=
> the group[8]. I think link relations come relatively cheap and unless<= br> > there's something I've missed helping to put another nail in t= he
> coffin of the URL shorteners is arguably a good thing.
>
> Thoughts?
>
> Sam
>
> 1. ht= tp://revcanonical.wordpress.com/
> 2. http= ://revcanonical.appspot.com/
> 3. http://developers.slashdot.org/article.pl?sid= =3D09/04/12/1834205
> 4. http://code.google.com/p/shortlink/wiki/Alternatives > 5. http://code.google.com/p/shortlink/wiki/Specification<= br> > 6. http://www.mnot.net/blog/2009/04/14/rev_canonical_bad<= br> > 7. http://samj.net/2009/04/introducing-relshor= t-better-alternative.html
> 8. http://groups.google.com/group/shortlink
>
> shortlink Specification
>
> Technical specification for the HTML/HTTP "shortlink" relati= on
>
> Introduction
>
> The shortlink relation allows webmasters to specify a short link to > use for the resource, thereby avoiding having to obtain one from a
> potentially unreliable third party URL shortening service such as
> tinyurl.com.
>
> Such links are useful for space-constrained applications (e.g.
> microblogging including Twitter and mobile Internet) as well as any > time URLs need to be manually entered (e.g. when they are printed or > spoken).
>
> Note: Until such time as shortlink is officially standardised
> http://pur= l.org/net/shortlink should be used for standards compliance.
>
> Details
>
> The shortlink appears in two places:
>
> within the HEAD section of the HTML document:
>
> <link rel=3D"shortlink" href=3D"http://example.com/promo"> >
> in the Link: HTTP header:
>
> Link: <http:= //example.com/promo>; rel=3Dshortlink
>
> Implementation
>
> Servers
>
> Servers should implement both HTML and HTTP links for efficiency and > performance reasons.
>
> The shortlink should default to an automatically generated stable URI<= br> > based on an existing unique identifier (e.g. http://example.com/123).
> Such identifiers may be compressed using base32 or similar (e.g.
> http://example.com= /3r). URIs should be case-insensitive and avoid
> symbols that look or sound similar (e.g. 1 vs l), particularly when > manual entry will be required (e.g. printed, spoken).
>
> Publishers should also be given the option to specify a human-friendly=
> slug (e.g. http= ://example.com/promo), as users should be able to
> derive information about the resource (path) and its source (domain) > from the URL.
>
> Where a shortlink is changed the previous URL should not be broken as<= br> > it may have been stored by users. Typically this requires maintaining<= br> > a register of mappings.
>
> Clients
>
> Clients that have already retrieved the document (e.g. web browsers, > news readers) should parse it to discover the link rel=3D"shortli= nk"
> element(s) and extract the href attribute from each.
>
> Clients that have the URL but not the document (e.g. microblogging
> software) should conduct a HTTP HEAD request and extract any Link:
> headers from the response. Clients should not retrieve and parse the > document unless the user specifically requests it.
>
> In the event that there are multiple shortlinks then the client may > choose one itself or offer the user the choice (e.g. in a drop-down > list). If the client chooses one it may do so randomly, by order
> (first vs last) or by some quality of the URL (length, readability, > etc.).
=A0
> _______________________________________________<= br> > Apps-Discuss mailing list
> Apps-Discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--0016e64650a0340c1d046796cd11-- From moore@cs.utk.edu Wed Apr 15 05:36:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3303A6906 for ; Wed, 15 Apr 2009 05:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1yd0lXqFnCU for ; Wed, 15 Apr 2009 05:36:12 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 6FEB73A6909 for ; Wed, 15 Apr 2009 05:36:12 -0700 (PDT) Received: from lust.indecency.org (host65-17-26-18.birch.net [65.17.26.18]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNI79559 (AUTH admin@network-heretics.com); Wed, 15 Apr 2009 05:37:20 -0700 (PDT) Message-ID: <49E5D4FE.1010003@cs.utk.edu> Date: Wed, 15 Apr 2009 08:37:18 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sam Johnston Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> <49E521DB.8080403@cs.utk.edu> <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> In-Reply-To: <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 12:36:13 -0000 Sam Johnston wrote: > Keith, > > Oh my, it seems we have yet another type of link relation to cater > for: immutable unique identifiers ala atom:id :) > > On Wed, Apr 15, 2009 at 1:52 AM, Keith Moore > wrote: > > I think it's interesting that PURLs started out with the notion that > URLs via a 3rd party referrer could be more persistent than URLs from > the original domain, and now we're proposing that an original domain's > URLs might be more persistent than those through a 3rd party service. > Both are correct, of course, depending on circumstances. > > > Persistency is not the key requirement here - shortness is (and for > some applications, human-friendliness). Canonical URLs (which are > generally long and stuffed with SEO juice) are very much subject to > change. A human friendly shortlink like http://nike.com/just-do-it is > less likely to change while shortlinks based on immutable identifiers > like http://nike.com/123 > > should never change (though the resource they point at may). > > In general I think that the fewer human meaningful components to an > identifier, the more persistent you can make the binding between that > identifier and whatever it originally referred to. Having the > components of the identifier be meaningless reduces the temptation to > change the binding associated with an identifier (from that originally > established) to something that is more "current". (There are lots of > versions of this. If you use file and directory names in URLs, at > some > point you inevitably feel the need to reorganize the directory tree - > which tends to invalidate URLs based on the old tree.) > > > Agreed, the more information in the URL the less persistent it will > be. URLs committed to dead tree versions (e.g. references in an > academic paper) are by very definition immutable so these should be > able to be updated to point at the most recent/best version of the > intended resource. Not clear; it depends on the nature of the reference. Sometimes it's important to point to the exact same version of the resource that the referrer used. It can actually make sense to have multiple persistent names for a resource, e.g. one for the version cited, another for the most recent version. The trick is keeping all of the different references straight, using the right one in the right circumstance, and maintaining them all. > > What's not immediately clear to me is why you'd use anything other > than > the stable identifier in any links within documents. I can understand > wanting to keep a set of "human friendly" identifiers that are > easy for > users to remember, that might change over time, but I have a more > difficult time understanding why you'd want to use those in links. > > > Say I'm microblogging or texting about some campaign, for example > Greenpeace's Save the Whales. Both me and my users are going to much > prefer seeing http://greenpeace.com/whales than > http://tinyurl.com/aZq4b - and I'm far more > likely to remember the former than the latter (even if longer). That strikes me as a UI issue. The HREF link in an A element should point to a URL that won't break. Perhaps, on visiting that page, the user should see a more friendly URL is one is available. But that can also be misleading in subtle ways as the user isn't seeing the link that got him to the page he is reading. > > So anyway, I think that having a "stable" or "persistent" link in the > HTTP and/or document header is a good idea. (Note: putting this > in the > HTTP header is more general: don't restrict this to just HTML! And > putting it in the document header is somewhat risky as the link might > need to change (or not) when the document is updated - existing tools > certainly won't do the right thing in all cases.) > > > Agreed, except that I'm not sure the unique ID need be resolveable to > the resource - just that it allow differentiating between resources. To me it seems that if the ID isn't resolvable to the resource, you really haven't solved the problem of links breaking - you've just moved it. > I actually think specifying rel=canonical (that's rel, not rev) solves > many of the real world problems we see today. If people want to break > their own links then that's their problem. > > > Ideally, software would recognize these headers and use the stable URL > in preference to other URLs when appropriate. So that when you > create a > bookmark to a web page, the bookmark points to the stable link by > default. Or when you are editing a document and you create a link to > another document, you should get the stable link by default. I > think it > should be possible to override the defaults, but it ought to be > clear to > the user/editor that he's not using the stable URL. > > > Again this sounds like a job for the canonical URL - I'd much rather > see search engines and bookmarks having URLs like > http://greenpeace.com/blog/2009/04/greenpeace-helps-save-the-whales.html > than http://greenpeace.com/123. I think I see your point - but it's not immediately clear to me which form is more likely to be persistent. > > I don't think this mechanism can work well without some sort of > content > management system (it can be a very primitive one) that automatically > creates unique, persistent URLs for things. So it's important for web > servers to _not_ generate these headers by default, but rather, to > do so > only when explicitly configured (presumably by a content > management system). > > > Sure, for persistent IDs. > > > Of course, this is trying to solve the same problems for which > URNs were > invented, and I still think that URNs are a good approach. I'd > like to > see any mechanism for advertising a persistent identifier be > compatible > with URNs. But it doesn't bother me that people are still > interested in > using URLs for this purpose. > > > I personally prefer UUIDv4 (random) based URNs for this, but I think > it's a completely separate need from that of shortlinks. Does that > make sense? I understand that there's a need for shortlinks independent of persistence. But I don't think the two issues are easily teased apart. (one nice thing about non-random URNs is that there is some potential of being able to resolve them...though that's rarely worked as well as we hoped.) Keith From vkg@alcatel-lucent.com Wed Apr 15 06:38:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF1F28C14C for ; Wed, 15 Apr 2009 06:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-Ms1Fyd+mOM for ; Wed, 15 Apr 2009 06:38:31 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1544828C178 for ; Wed, 15 Apr 2009 06:38:31 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n3FDdfav001075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 08:39:41 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n3FDdeu9006083; Wed, 15 Apr 2009 08:39:40 -0500 (CDT) Message-ID: <49E5E39C.4040001@alcatel-lucent.com> Date: Wed, 15 Apr 2009 08:39:40 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> In-Reply-To: <49E58EA2.6050200@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Apps Discuss , =JeffH X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:38:32 -0000 Alexey Melnikov wrote: > Folks, > The issue of a document describing recommended text/template for server > identity verification procedure came up again while talking about > advancing EPP. > > As an AD, I would really like for draft-hodges-server-ident-check to be > published as an RFC. And I know that Chris was keen on this as well. > Jeff/Bob, do you have any cycles to work on this? In the SIP WG, we just requested publication for a draft that details mutual TLS authentication for SIP servers and clients (please see http://tools.ietf.org/html/draft-ietf-sip-domain-certs-03). This is somewhat related to what Hodges et al. is attempting to do for generic servers (as opposed to SIP servers specifically.) That said, I will be more than happy to review or help on draft-hodges-... as it moves forward. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From stpeter@stpeter.im Wed Apr 15 06:49:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD863A6B61 for ; Wed, 15 Apr 2009 06:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO3SkJXBb8kV for ; Wed, 15 Apr 2009 06:49:38 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 82F533A69CF for ; Wed, 15 Apr 2009 06:49:38 -0700 (PDT) Received: from squire.local (dsl-240-167.dynamic-dsl.frii.net [216.17.240.167]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 87808E803D; Wed, 15 Apr 2009 07:50:47 -0600 (MDT) Message-ID: <49E5E636.3030905@stpeter.im> Date: Wed, 15 Apr 2009 07:50:46 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> In-Reply-To: <49E58EA2.6050200@isode.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080002060802010800080806" Cc: Apps Discuss , =JeffH X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:49:39 -0000 This is a cryptographically signed message in MIME format. --------------ms080002060802010800080806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/15/09 1:37 AM, Alexey Melnikov wrote: > Folks, > The issue of a document describing recommended text/template for server > identity verification procedure came up again while talking about > advancing EPP. > > As an AD, I would really like for draft-hodges-server-ident-check to be > published as an RFC. +1. This would be quite helpful so that different application protocols can depend on a common base (with appropriate modifications for the particular application), or at least have some guidelines they can use to formulate identity verification text (a la RFC 3552). BTW in XMPP we have text about this in RFC 3920 and 3920bis: http://tools.ietf.org/html/draft-saintandre-rfc3920bis-09#section-15.2 > And I know that Chris was keen on this as well. > Jeff/Bob, do you have any cycles to work on this? I'd be happy to take a look. Perhaps one helpful task would be to compare the text in draft-hodges-server-ident-check against similar text in documents like draft-saintandre-rfc3921bis and draft-ietf-sip-domain-certs. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms080002060802010800080806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWZDCC BzswggYjoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wODA3MDIyMDQzMThaFw0wOTA3MDIyMDQzMThaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDBemNDejWS/iB/hQVbp2Gd5eYWYb+z1RSPbY4RQHW/apL4auhig1FhCOrN+eN+32iYp3tm K0kv/Rrhae9UzjFMzxc3QBcuj+H6kRudhawlrjeXMX7er9sqSIO0pDlaFvs7Kq0Lz7FFZL4e whqdPfK5MROPp1ucUtI5mMkYE2y6Sll04UKoCWVK4bLsTkJGMp0lnpNRG2LaMKjZldJYe7ci bkcTsnVPF4H4SVgwQbwkfw/wSS+HzOjtng3Nzz4z572WIMCwwJnfCVDJMXpdvssejkOaVl1/ +Ewqt80sjae67rD28v8sPAs7si+JIL5SYYqCw4djCSYfeMHO7R0qox3fAgMBAAGjggNuMIID ajAMBgNVHRMEBTADAgEAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwHQYDVR0OBBYEFFObPTX8kvCsGgtLWvPiSviKgJ51MIGoBgNVHSMEgaAwgZ2AFHuJ nJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEPMIIBRwYDVR0g BIIBPjCCATowggE2BgsrBgEEAYG1NwEBBTCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBv bGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBj BgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3Js MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJNQdIoQBoFf8UslzTDD7ue89LppTEBJ w5Za9ddTSfI8MEdomLK52FfLPu1JWWlzDZrwV/MHqTNqBHeXrjUxqnrERmKIXVZpIO7tEJia cIGO2LYJoCMzXxOpIcAv2H9gVlAE0ibx3gOJ6XQGz7WUdOKouWUMf9aj1SCFJOChHTe6vSPl rPjbJufQG7mwjpTrkwUos1/rznZWDCGCTUVLWiMN5XNzg8SMOurICxPborHlERiiX/ilwmL6 JBanoCQcyL45L40cFFF923FOWCXCHY0XAj/7MmVWpMl83tNRnXaYtukNJwM2C3rSEo3GTClU IjB/0feH/9uWyMGPcF8WTxcwggc7MIIGI6ADAgECAgEpMA0GCSqGSIb3DQEBBQUAMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMDgwNzAyMjA0MzE4WhcNMDkwNzAy MjA0MzE4WjCBwjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZE ZW52ZXIxIjAgBgNVBAoTGVhNUFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0 YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWlu dC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXpjQ3o1kv4gf4UFW6dhneXmFmG/s9UUj22OEUB1v2qS +GroYoNRYQjqzfnjft9omKd7ZitJL/0a4WnvVM4xTM8XN0AXLo/h+pEbnYWsJa43lzF+3q/b KkiDtKQ5Whb7OyqtC8+xRWS+HsIanT3yuTETj6dbnFLSOZjJGBNsukpZdOFCqAllSuGy7E5C RjKdJZ6TURti2jCo2ZXSWHu3Im5HE7J1TxeB+ElYMEG8JH8P8Ekvh8zo7Z4Nzc8+M+e9liDA sMCZ3wlQyTF6Xb7LHo5DmlZdf/hMKrfNLI2nuu6w9vL/LDwLO7IviSC+UmGKgsOHYwkmH3jB zu0dKqMd3wIDAQABo4IDbjCCA2owDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRTmz01/JLwrBoLS1rz4kr4ioCe dTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAQUwggElMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIB FihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8BggrBgEFBQcC AjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0 aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0 dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au c3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCTUHSK EAaBX/FLJc0ww+7nvPS6aUxAScOWWvXXU0nyPDBHaJiyudhXyz7tSVlpcw2a8FfzB6kzagR3 l641Map6xEZiiF1WaSDu7RCYmnCBjti2CaAjM18TqSHAL9h/YFZQBNIm8d4Diel0Bs+1lHTi qLllDH/Wo9UghSTgoR03ur0j5az42ybn0Bu5sI6U65MFKLNf6852Vgwhgk1FS1ojDeVzc4PE jDrqyAsT26Kx5REYol/4pcJi+iQWp6AkHMi+OS+NHBRRfdtxTlglwh2NFwI/+zJlVqTJfN7T UZ12mLbpDScDNgt60hKNxkwpVCIwf9H3h//blsjBj3BfFk8XMIIH4jCCBcqgAwIBAgIBDzAN BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMzMyWhcNMTIx MDIyMjEwMzMyWjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuaNJbhI+IMqUCKe9V4tk5V8i2K4/VpEcvnfQTtBR z2JwLAvff48f4mzUcCHwKBYWXfiw7HHUUnJL8LhUs9GyoN8/vaO3MJVQAvQMDFnvCDNC8XPv HrWMbF+FiGphvX4884uRgFuREis8yDd0sR0qZchglhcMf6YH9X+Mujvf8pvuH+s2g2D+gcdK /kmiXK+nkhjZu19xMF9b+16UQWPmsNNfaO5O9ndCF/ddBflxrdDsDXTOtRX9xYk4nsXlGW1s QhpuhmZfkkFRvcWFSIB0Gi16EBfoNsM65igm1XGYah/oa5UZw+j3wrhMl/wUej5QD0Q5UOn9 bt8KopPixeT9eQIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYD VR0OBBYEFHuJnJKXJKGERwLLdPwu9KzcMuXzMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYB BQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j cnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0E QxZBU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFp bCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEFBQADggIBAFKXBA3bChUQsRQcXEpvvKDE036U u322ZMVh8eXxw47wIGgUPqGNLZOMbWw+lcXh2I8SOt/oY/IyAp6nlVz3t+Abvl83pCJ9k5a5 zwkKGynUBdqedkIFLyMUlEXndI3AWggVdtg0imlKgzsw/08elUMu/M6W5V40R+zgCxP/h48y VZrKXZwVFLUDi2ID6PduMZMUduVQ3YLRBObwF2v4NqAnmYctGRDuDW4CGsgGAiXCUQ89IXQ9 gIXnOuSsOiwdze1VxI4kUef1qCsB/0LXkczyWxQ3NbKJqwKY5tnMoPuZ25tUR3hSM/hsV5bk az87b4TXG8tD7QI6sGNbcYuLFtEemST7mdg2df3c3JKBYcmYBcjl90hJDV1S5XY0853hSRZ1 Usw23O9tL6tfOI0e6WKCPfn+UCfemtIi8RABvEieWrgcFyP8NhZipsJnTLyfP9e/geLDAiEa 16w0Jdsc6VV4f0HJpOZ3/sPBxZqgExstTlAEG14GuwMkgFGmIb7xZOdLtGzuQ4lBsM6yTt06 8L2gthIuBBWgZiFYBu031OU2mmPSHCUgkOwBlGBN0RUkabCzqANw7MT+NmBEYEvzccNvfmKm bT6DtkD2zaSO8Zx1QnzQWm8d6AyH+N/JxX7/LKcOQUKgUmxBdYsyQOe3hOuAsx57e5QdtDhQ 9dWr2KKcMYIDvTCCA7kCAQEwgZIwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIBKTAJBgUrDgMCGgUAoIIB/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wOTA0MTUxMzUwNDZaMCMGCSqGSIb3DQEJBDEWBBQCJSr9bU2p0eZ5UIiPiSRj C9oGyTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAQ5X8Nq1bnOJe0Gywi2xQBjguZ3n6Bei6jE/tM1Wx015SpuBn7HUChfdVh+k8 Ah+6MBXdkiqpNJcDGMbPOPp187FH3ixpsQBL1X8vDdl5XzX3E+9QqqiYisxpijEoGd5ItSdy WvGWvOuZjkuxm0Aw4bKwLPlAOrVWrwFvmcj/G3Zl+DT9gemdMuGY4fSihvtTNlKkCChEhchJ MKQkFBv5fT1kFLLclSWA+CW0qEc6vDAPaqn7ooZaTusCKKrAv6o2LUoU/V6wyDrltT/03v2e D5dCWqM7Keoqg8D0iRyNEOmGUPLUDirKDT3TGaICM/VTY6YrVxjgLdXacW4dOHHE2AAAAAAA AA== --------------ms080002060802010800080806-- From sanz@denic.de Wed Apr 15 07:38:10 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24083A6E70 for ; Wed, 15 Apr 2009 07:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dvC2l1lrP9T for ; Wed, 15 Apr 2009 07:38:10 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 0E05C3A69FC for ; Wed, 15 Apr 2009 07:38:10 -0700 (PDT) Received: from notes2.fra1.osl.denic.de (notes2.fra1.osl.denic.de [10.122.50.20]) by office.denic.de with esmtp id 1Lu6Gn-0004OF-0c; Wed, 15 Apr 2009 16:39:21 +0200 In-Reply-To: <49E5E636.3030905@stpeter.im> To: Peter Saint-Andre Subject: Re: TLS server identity verification MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Marcos Sanz/Denic Message-ID: Date: Wed, 15 Apr 2009 16:39:09 +0200 X-MIMETrack: Serialize by Router on notes2/Denic at 15.04.2009 16:39:21, Serialize complete at 15.04.2009 16:39:21 Content-Type: text/plain; charset="US-ASCII" Cc: JeffH , Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:38:10 -0000 > BTW in XMPP we have text about this in RFC 3920 and 3920bis: > > http://tools.ietf.org/html/draft-saintandre-rfc3920bis-09#section-15.2 As I just mailed to the authors, there is also text in RFC 3983 (Section 6.2). FWIW I support the draft-hodges-server-ident-check initiative. Best, Marcos From eburger@standardstrack.com Thu Apr 16 16:01:08 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3153A6D5B for ; Thu, 16 Apr 2009 16:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SszmEToFJg+U for ; Thu, 16 Apr 2009 16:01:07 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id E9A5F28C15B for ; Thu, 16 Apr 2009 16:00:54 -0700 (PDT) Received: from [116.6.21.151] by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Luaak-0000Eh-5u for apps-discuss@ietf.org; Thu, 16 Apr 2009 16:01:58 -0700 Message-Id: From: Eric Burger To: apps-discuss@ietf.org In-Reply-To: <49E5D4FE.1010003@cs.utk.edu> Content-Type: multipart/signed; boundary=Apple-Mail-4--377281933; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP Date: Fri, 17 Apr 2009 07:02:02 +0800 References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> <49E521DB.8080403@cs.utk.edu> <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> <49E5D4FE.1010003@cs.utk.edu> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:01:08 -0000 --Apple-Mail-4--377281933 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Maybe I'm being an idiot, but why does the server need to know that this thing masquerading as a URL is really a URN in URL syntax? Why does the client need to know this thing advertised as a URL is not really a URL? To me, it is just an opaque string. The fact the server advertises the same resources with two opaque strings really is not my business, is it? On Apr 15, 2009, at 8:37 PM, Keith Moore wrote: > Sam Johnston wrote: >> Keith, >> >> Oh my, it seems we have yet another type of link relation to cater >> for: immutable unique identifiers ala atom:id :) >> >> On Wed, Apr 15, 2009 at 1:52 AM, Keith Moore > > wrote: >> >> I think it's interesting that PURLs started out with the notion >> that >> URLs via a 3rd party referrer could be more persistent than URLs >> from >> the original domain, and now we're proposing that an original >> domain's >> URLs might be more persistent than those through a 3rd party >> service. >> Both are correct, of course, depending on circumstances. >> >> >> Persistency is not the key requirement here - shortness is (and for >> some applications, human-friendliness). Canonical URLs (which are >> generally long and stuffed with SEO juice) are very much subject to >> change. A human friendly shortlink like http://nike.com/just-do-it is >> less likely to change while shortlinks based on immutable identifiers >> like http://nike.com/123 >> >> should never change (though the resource they point at may). >> >> In general I think that the fewer human meaningful components to >> an >> identifier, the more persistent you can make the binding between >> that >> identifier and whatever it originally referred to. Having the >> components of the identifier be meaningless reduces the >> temptation to >> change the binding associated with an identifier (from that >> originally >> established) to something that is more "current". (There are >> lots of >> versions of this. If you use file and directory names in URLs, at >> some >> point you inevitably feel the need to reorganize the directory >> tree - >> which tends to invalidate URLs based on the old tree.) >> >> >> Agreed, the more information in the URL the less persistent it will >> be. URLs committed to dead tree versions (e.g. references in an >> academic paper) are by very definition immutable so these should be >> able to be updated to point at the most recent/best version of the >> intended resource. > Not clear; it depends on the nature of the reference. Sometimes it's > important to point to the exact same version of the resource that the > referrer used. > > It can actually make sense to have multiple persistent names for a > resource, e.g. one for the version cited, another for the most recent > version. The trick is keeping all of the different references > straight, > using the right one in the right circumstance, and maintaining them > all. >> >> What's not immediately clear to me is why you'd use anything other >> than >> the stable identifier in any links within documents. I can >> understand >> wanting to keep a set of "human friendly" identifiers that are >> easy for >> users to remember, that might change over time, but I have a more >> difficult time understanding why you'd want to use those in links. >> >> >> Say I'm microblogging or texting about some campaign, for example >> Greenpeace's Save the Whales. Both me and my users are going to much >> prefer seeing http://greenpeace.com/whales than >> http://tinyurl.com/aZq4b - and I'm far more >> likely to remember the former than the latter (even if longer). > That strikes me as a UI issue. The HREF link in an A element should > point to a URL that won't break. Perhaps, on visiting that page, the > user should see a more friendly URL is one is available. But that can > also be misleading in subtle ways as the user isn't seeing the link > that > got him to the page he is reading. >> >> So anyway, I think that having a "stable" or "persistent" link >> in the >> HTTP and/or document header is a good idea. (Note: putting this >> in the >> HTTP header is more general: don't restrict this to just HTML! >> And >> putting it in the document header is somewhat risky as the link >> might >> need to change (or not) when the document is updated - existing >> tools >> certainly won't do the right thing in all cases.) >> >> >> Agreed, except that I'm not sure the unique ID need be resolveable to >> the resource - just that it allow differentiating between resources. > To me it seems that if the ID isn't resolvable to the resource, you > really haven't solved the problem of links breaking - you've just > moved it. >> I actually think specifying rel=canonical (that's rel, not rev) >> solves >> many of the real world problems we see today. If people want to break >> their own links then that's their problem. >> >> >> Ideally, software would recognize these headers and use the >> stable URL >> in preference to other URLs when appropriate. So that when you >> create a >> bookmark to a web page, the bookmark points to the stable link by >> default. Or when you are editing a document and you create a >> link to >> another document, you should get the stable link by default. I >> think it >> should be possible to override the defaults, but it ought to be >> clear to >> the user/editor that he's not using the stable URL. >> >> >> Again this sounds like a job for the canonical URL - I'd much rather >> see search engines and bookmarks having URLs like >> http://greenpeace.com/blog/2009/04/greenpeace-helps-save-the-whales.html >> than http://greenpeace.com/123. > I think I see your point - but it's not immediately clear to me which > form is more likely to be persistent. >> >> I don't think this mechanism can work well without some sort of >> content >> management system (it can be a very primitive one) that >> automatically >> creates unique, persistent URLs for things. So it's important >> for web >> servers to _not_ generate these headers by default, but rather, to >> do so >> only when explicitly configured (presumably by a content >> management system). >> >> >> Sure, for persistent IDs. >> >> >> Of course, this is trying to solve the same problems for which >> URNs were >> invented, and I still think that URNs are a good approach. I'd >> like to >> see any mechanism for advertising a persistent identifier be >> compatible >> with URNs. But it doesn't bother me that people are still >> interested in >> using URLs for this purpose. >> >> >> I personally prefer UUIDv4 (random) based URNs for this, but I think >> it's a completely separate need from that of shortlinks. Does that >> make sense? > I understand that there's a need for shortlinks independent of > persistence. But I don't think the two issues are easily teased > apart. > > (one nice thing about non-random URNs is that there is some > potential of > being able to resolve them...though that's rarely worked as well as we > hoped.) > > Keith > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-4--377281933 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MTYyMzAyMDNaMCMGCSqGSIb3 DQEJBDEWBBRODrUzqyy3S4RQgAPsI+zantOatTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQAMoiKZWjzVsKNgCQ6oL6agwWfZOW+dDwIWbxtYJlH+TYPt DSJRolTbVS1UkUtuh00HuaWL0gVUZZA76stowGoTaEiwTx2CxvSlD5Kq/WhP4TNj3TLQzZl61DMh W+nPuEnRZ+XLwnBHQ107i5a+5NTQTBIQEv4gxskRobWwItTWzZEUolniU37QXRBUdKO1xOhjUuoC kewQvzoQwVskqhrkTpEDKoFAF4g3NEPXGXNHy5HIl1nUWGMnB8aUSwbiHVeDHIOxGCJYa4os0Etv O2CUfk19Rfw353oJAPyyny4oti5g2tG7BRrQ85bvWgaOGhY5LfX8XqiyVRIFKvAHEyRXAAAAAAAA --Apple-Mail-4--377281933-- From samj@samj.net Thu Apr 16 23:08:42 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5290A28B23E for ; Thu, 16 Apr 2009 23:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsGiIz8FXI6f for ; Thu, 16 Apr 2009 23:08:41 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id E8B3E3A6D3F for ; Thu, 16 Apr 2009 23:08:40 -0700 (PDT) Received: by qyk42 with SMTP id 42so456809qyk.29 for ; Thu, 16 Apr 2009 23:09:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.72.74 with SMTP id l10mr2039747vcj.71.1239948593730; Thu, 16 Apr 2009 23:09:53 -0700 (PDT) In-Reply-To: <49E5D4FE.1010003@cs.utk.edu> References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> <49E521DB.8080403@cs.utk.edu> <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> <49E5D4FE.1010003@cs.utk.edu> Date: Fri, 17 Apr 2009 08:09:53 +0200 Message-ID: <21606dcf0904162309k70d83661uae6810f48c7f8799@mail.gmail.com> Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP From: Sam Johnston To: Keith Moore Content-Type: multipart/alternative; boundary=0016e64769627817c90467ba0771 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:08:42 -0000 --0016e64769627817c90467ba0771 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Apr 15, 2009 at 2:37 PM, Keith Moore wrote: > > > > Agreed, the more information in the URL the less persistent it will > > be. URLs committed to dead tree versions (e.g. references in an > > academic paper) are by very definition immutable so these should be > > able to be updated to point at the most recent/best version of the > > intended resource. > Not clear; it depends on the nature of the reference. Sometimes it's > important to point to the exact same version of the resource that the > referrer used. > Right, pointing at a Wikipedia article would be a good example of where this would be useful. Can we hijack the existing threading relations I wonder? I can't see why not... > It can actually make sense to have multiple persistent names for a > resource, e.g. one for the version cited, another for the most recent > version. The trick is keeping all of the different references straight, > using the right one in the right circumstance, and maintaining them all. > The most common use case (and the case for "shortlink" - though that is more of an implementor concern) is to return the latest version. > > What's not immediately clear to me is why you'd use anything other > > than > > the stable identifier in any links within documents. I can > understand > > wanting to keep a set of "human friendly" identifiers that are > > easy for > > users to remember, that might change over time, but I have a more > > difficult time understanding why you'd want to use those in links. > > > > > > Say I'm microblogging or texting about some campaign, for example > > Greenpeace's Save the Whales. Both me and my users are going to much > > prefer seeing http://greenpeace.com/whales than > > http://tinyurl.com/aZq4b - and I'm far more > > likely to remember the former than the latter (even if longer). > That strikes me as a UI issue. The HREF link in an A element should > point to a URL that won't break. Perhaps, on visiting that page, the > user should see a more friendly URL is one is available. But that can > also be misleading in subtle ways as the user isn't seeing the link that > got him to the page he is reading. > The user should see the canonical URL when they visit the page (other cruft like search parameters can be grey so it's there and editable but not confusing). This is easy to implement when you tell the user agent what rel="canonical" is. Consider the use case of a text message or TV advertisement - you're going to want to have a short link that tells you something about what you're visiting but when you access that URL you're going to be more pleasantly surprised than confused or annoyed when it gets expanded out to something more meaningful. > > I personally prefer UUIDv4 (random) based URNs for this, but I think > > it's a completely separate need from that of shortlinks. Does that > > make sense? > I understand that there's a need for shortlinks independent of > persistence. But I don't think the two issues are easily teased apart. > > (one nice thing about non-random URNs is that there is some potential of > being able to resolve them...though that's rarely worked as well as we > hoped.) > OTOH if it's not resolveable then it's going to be a lot less likely to break... Sam --0016e64769627817c90467ba0771 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2009 at 2:37 PM, Keith Moore <moore@cs.utk.edu> wrote:=A0

> Agreed, the more information in the URL the less persistent it will > be. URLs committed to dead tree versions (e.g. references in an
> academic paper) are by very definition immutable so these should be > able to be updated to point at the most recent/best version of the
> intended resource.
Not clear; =A0it depends on the nature of the reference. =A0Som= etimes it's
important to point to the exact same version of the resource that the
referrer used.

Right, pointing at a Wikipedia article would be a goo= d example of where this would be useful. Can we hijack the existing threadi= ng relations I wonder? I can't see why not...
=A0
It can actually make sense to have multiple persistent names for a
resource, e.g. one for the version cited, another for the most recent
version. =A0The trick is keeping all of the different references straight,<= br> using the right one in the right circumstance, and maintaining them all.

The most common use case (and the case for= "shortlink" - though that is more of an implementor concern) is = to return the latest version.
=A0
> =A0 =A0 What's not immediately clear to me is why you'd u= se anything other
> =A0 =A0 than
> =A0 =A0 the stable identifier in any links within documents. =A0I can = understand
> =A0 =A0 wanting to keep a set of "human friendly" identifier= s that are
> =A0 =A0 easy for
> =A0 =A0 users to remember, that might change over time, but I have a m= ore
> =A0 =A0 difficult time understanding why you'd want to use those i= n links.
>
>
> Say I'm microblogging or texting about some campaign, for example<= br> > Greenpeace's Save the Whales. Both me and my users are going to mu= ch
> prefer seeing http://greenpeace.com/whales than
> http://ti= nyurl.com/aZq4b <h= ttp://example.com/> - and I'm far more
> likely to remember the former than the latter (even if longer).
That strikes me as a UI issue. =A0The HREF link in an A element shoul= d
point to a URL that won't break. =A0 Perhaps, on visiting that page, th= e
user should see a more friendly URL is one is available. =A0But that can also be misleading in subtle ways as the user isn't seeing the link tha= t
got him to the page he is reading.

The user should see the canonical URL when= they visit the page (other cruft like search parameters can be grey so it&= #39;s there and editable but not confusing). This is easy to implement when= you tell the user agent what rel=3D"canonical" is.
=A0
Consider the use case of a text message or TV advertisement - you= 9;re going to want to have a short link that tells you something about what= you're visiting but when you access that URL you're going to be mo= re pleasantly surprised than confused or annoyed when it gets expanded out = to something more meaningful.

<sni= p>
> I personally prefer UUIDv4 (random) based URNs for this, but I think > it's a completely separate need from that of shortlinks. Does that=
> make sense?
I understand that there's a need for shortlinks independent of persistence. =A0But I don't think the two issues are easily teased apar= t.

(one nice thing about non-random URNs is that there is some potential of being able to resolve them...though that's rarely worked as well as we<= br> hoped.)

OTOH if it's not r= esolveable then it's going to be a lot less likely to break...

S= am

--0016e64769627817c90467ba0771-- From zhangguoqiang@cnnic.cn Fri Apr 17 01:16:05 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504DC3A6DA1 for ; Fri, 17 Apr 2009 01:16:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 4.908 X-Spam-Level: **** X-Spam-Status: No, score=4.908 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH54FBKPiphJ for ; Fri, 17 Apr 2009 01:16:04 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 687403A6D6F for ; Fri, 17 Apr 2009 01:15:39 -0700 (PDT) Received: (eyou send program); Fri, 17 Apr 2009 16:16:53 +0800 Message-ID: <439956213.10974@cnnic.cn> X-EYOUMAIL-SMTPAUTH: zhangguoqiang@cnnic.cn Received: from unknown (HELO cnnic-eae3fdf20) (218.241.111.8) by 159.226.7.146 with SMTP; Fri, 17 Apr 2009 16:16:53 +0800 Date: Fri, 17 Apr 2009 16:16:52 +0800 From: "zhangguoqiang" To: "Stephane Bortzmeyer" References: <200904011116363933242@cnnic.cn>, <438575712.22018@cnnic.cn> Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <200904171616524064316@cnnic.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon426548657640_=====" Cc: apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:16:05 -0000 This is a multi-part message in MIME format. --=====001_Dragon426548657640_===== Content-Type: multipart/alternative; boundary="=====003_Dragon426548657640_=====" --=====003_Dragon426548657640_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpJJ20gc3VtbWVyemluZyBvdXIgZGlzY3Vzc2lvbiBub3cuIFNvLCBTdGVwaGFuZSBCb3J0em1l dmVyLCB5b3Ugb3BpbmlvbiBpcyB0aGF0IHdpdGggSUROLCBtYW51YWwgZG9tYWluIG5hbWUgc3Vm Zml4IGNvbmZpZ3VyYXRpb24gaW4gYnJvd2VycyBhbmQgcmVkaXJlY3QsIHBlb3BsZSBjYW4gYnV5 IGFuIElETiBhbmQgYWNoaWV2ZSB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFzIGtleXdvcmQ/DQoN CkF0IGZpcnN0LCB0aGlzIHNvdW5kcyBwZXJmZWN0LiBIb3dldmVyLCBvbmUgcHJvYmxlbSByZW1h aW5zLiBTaW5jZSB0aGUgaW50ZW5zaW9uIG9mIGtleXdvcmRzIGlzIG5vdCBvbmx5IHRvIHBvaW50 IHRvIGEgc2l0ZSwgYnV0IGFsc28gYmUgY2FwYWJsZSB0byBwb2ludCBkaXJlY3RseSB0byBhIHdl YnBhZ2UgaW5zaWRlIGEgc2l0ZS4gSW4gdGhlIGtleXdvcmQgbWV0aG9kLCBpdCBpcyBlYXN5IHRv IGJ1eSBtb3JlIHRoYW4gb25lIGtleXdvcmRzIGFuZCBlYWNoIHBvaW50aW5nIHRvIGEgZGlmZmVy ZW50IHdlYnBhZ2UgaW5zaWRlIHRoZSBzaXRlLiBIb3dldmVyLCB3aXRoIHJlZGlyZWN0IG1ldGhv ZCwgaXQgaXMgbXVjaCBoYXJkZXIgdG8gZG8gc28uIA0KDQoyMDA5LTA0LTE3IA0KDQoNCg0Kemhh bmdndW9xaWFuZyANCg0KDQoNCreivP7Iy6O6IFN0ZXBoYW5lIEJvcnR6bWV5ZXIgDQq3osvNyrG8 5KO6IDIwMDktMDQtMDEgIDE2OjQ4OjMyIA0KytW8/sjLo7ogemhhbmdndW9xaWFuZyANCrOty82j uiBhcHBzLWRpc2N1c3M7IFlBTyBKaWFua2FuZyANCtb3zOKjuiBSZTogU29saWNpdGF0aW9uIGZv ciBhIGRpc2N1c3Npb24gb24gS2V5d29yZC1iYXNlZCBhZGRyZXNzaW5nIA0KIA0KT24gV2VkLCBB cHIgMDEsIDIwMDkgYXQgMTE6MTY6MzZBTSArMDgwMCwNCiB6aGFuZ2d1b3FpYW5nICA8emhhbmdn dW9xaWFuZ0Bjbm5pYy5jbiA+IHdyb3RlIA0KIGEgbWVzc2FnZSBvZiAxNTYgbGluZXMgd2hpY2gg c2FpZDoNCg0KPiBEaWZmZXJlbnQgZnJvbSBzZWFyY2ggZW5naW5lcywga2V5d29yZC1iYXNlZCBh ZGRyZXNzaW5nIGlzIGFuDQo+IGFkZHJlc3NpbmcgdGVjaG5vbG9neS4gQmFzZWQgb24gd2hldGhl ciBhIGtleXdvcmQgaXMgcmVnaXN0ZXJlZCBvcg0KPiBub3QsIHRoZSByZXNvbHV0aW9uIHJlc3Vs dCBpcyBkZXRlcm1pbnN0aWMgZm9yIGFueSBnaXZlbiBrZXl3b3JkLCANCg0KVGhlbiBpdCB3aWxs IGhhdmUgYWxsIHRoZSBwcm9ibGVtcyBvZiB0aGUgZG9tYWluIG5hbWVzLCBpbmNsdWRpbmcNCmJ1 cmVhdWNyYXRpYyByZWdpc3RyYXRpb24gcnVsZXMsIFVEUlAsIGxhd3llcnMsIElDQU5OLCBldGMu DQoNCj4gRm9yIGV4YW1wbGUsIGlmIHlvdSBhcmUgYSBibG9nZ2VyIG9mIGEgcG9ydGFsIGJsb2cg d2Vic2l0ZSwNCj4gdHlwaWNhbGx5LCB5b3UgYXJlIGFzc2lnbmVkIGEgVVJMIHRoYXQgaWRlbnRp ZmllcyB5b3VyIGJsb2cuIEl0IGlzDQo+IHVzdWFsbHkgY29tcG9zZWQgb2YgdHdvIHBhcnRzOiBh IGRvbWFpbiBuYW1lIGFuZCBhbiBJRCh0eXBpY2FsbHkgYQ0KPiBtYWdpYyBudW1iZXIpLiBTbyBo b3cgY2FuIHlvdSBhZHZlcnRpc2UgeW91ciBibG9nIHRvIHlvdXIgZnJpZW5kcz8gDQoNCnRpbnl1 cmwuY29tDQoNCkJ1dCBpdCBpcyBzaW1wbGVyIHRvIGJ1eSBhIGRvbWFpbiBuYW1lIGFuZCByZWRp cmVjdC4NCg0KPiBTbywgd2UgdGhpbmsga2V5d29yZC1iYXNlZCBhZGRyZXNzaW5nIGlzIGEgdmVy eSB1c2VmdWwgdGVjaG5pcXVlLA0KPiBlc3BlY2lhbGx5IGZvciBub24tZW5nbGlzaCBzcGVha2lu ZyBjb3VudHJpZXMuIEV2ZW4gZm9yIGVuZ2xpc2gNCj4gc3BlYWtpbmcgY291bnRyaWVzLCB0aGUg YWJvdmUgZXhhbXBsZSBhbHNvIGlsbHVzdHJhdGVzIGl0cw0KPiBwcmFjdGljYWJpbGl0eS4gVG8g aW50ZXJuYXRpb25hbGl6ZSB0aGlzIHNlcnZpY2UgYW5kIHByb3ZpZGUgY3Jvc3MNCj4gcmVzb2x1 dGlvbiBjYXBhYmlsaXR5LCB3ZSBoaWdobHkgcmVjb21tZW5kIGEgc3RhbmRhcmQgYmVpbmcNCj4g ZGV2ZWxvcHBlZC4gDQoNCkknbSB2ZXJ5IHNrZXB0aWNhbCBidXQgSSdsbCByZWFkIHlvdXIgZHJh ZnQuDQoNCj4gT3VyIGtleXdvcmQtYmFzZWQgYWRkcmVzc2luZyBkcmFmdCBpcyBhdmFpbGFibGUg YXQNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmcta2V5d29yZC1kZGRz LTAwLCB3aGljaA0KPiBzcGVjaWZpZXMga2V5d29yZC1iYXNlZCBhZGRyZXNzaW5nIGFzIGEgRERE UyBhcHBsaWNhdGlvbi4NCg0KWW91IGFwcGFyZW50bHkgZG8gbm90IG1lbnRpb24gUkZDIDIzNDUg KGtleXdvcmRzIGFyZSBhIHZlcnkgb2xkIGlkZWENCndoaWNoIGtlZXAgcG9wcGluZyB1cCBmcm9t IHRpbWUgdG8gdGltZSkuDQo= --=====003_Dragon426548657640_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjU3MjYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SSdtIHN1bW1lcnpp bmcgb3VyIGRpc2N1c3Npb24gbm93LiANClNvLCBTdGVwaGFuZSBCb3J0em1ldmVyLCB5b3Ugb3Bp bmlvbiBpcyB0aGF0IHdpdGggSUROLCBtYW51YWwgZG9tYWluIG5hbWUgc3VmZml4IA0KY29uZmln dXJhdGlvbiBpbiBicm93ZXJzIGFuZCByZWRpcmVjdCwgcGVvcGxlIGNhbiBidXkgYW4gSUROIGFu ZCBhY2hpZXZlIHRoZSANCnNhbWUgZnVuY3Rpb25hbGl0eSBhcyBrZXl3b3JkPzwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSMwMDAwODA+QXQgZmlyc3QsIHRoaXMgc291bmRzIHBlcmZlY3QuIEhvd2V2ZXIs IG9uZSBwcm9ibGVtIA0KcmVtYWlucy4gU2luY2UgdGhlIGludGVuc2lvbiBvZiBrZXl3b3JkcyBp cyBub3Qgb25seSB0byBwb2ludCB0byBhIHNpdGUsIGJ1dCANCmFsc28gYmUgY2FwYWJsZSB0byBw b2ludCBkaXJlY3RseSB0byBhIHdlYnBhZ2UgaW5zaWRlIGEgc2l0ZS4gSW4gdGhlIGtleXdvcmQg DQptZXRob2QsIGl0IGlzIGVhc3kgdG8gYnV5IG1vcmUgdGhhbiBvbmUga2V5d29yZHMgYW5kIGVh Y2ggcG9pbnRpbmcgdG8gYSANCmRpZmZlcmVudCB3ZWJwYWdlIGluc2lkZSB0aGUgc2l0ZS4gSG93 ZXZlciwgd2l0aCByZWRpcmVjdCBtZXRob2QsIGl0IGlzIG11Y2ggDQpoYXJkZXIgdG8gZG8gc28u IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNj MGMwYzAgc2l6ZT0yPjIwMDktMDQtMTcgPC9GT05UPjwvRElWPjxGT05UIA0KZmFjZT1WZXJkYW5h IGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7IEhFSUdIVDog MnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCjwvRk9OVD4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5h IGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjxTUEFOPnpoYW5nZ3VvcWlhbmc8L1NQQU4+IA0KPC9GT05U PjwvRElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj4NCjxIUj4NCjwv Rk9OVD4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPreivP7Iy6O6PC9T VFJPTkc+IFN0ZXBoYW5lIEJvcnR6bWV5ZXIgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IDIwMDktMDQtMDEm bmJzcDsgMTY6NDg6MzIgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBz aXplPTI+PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiB6aGFuZ2d1b3FpYW5nIDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPrOty82jujwvU1RST05H PiBhcHBzLWRpc2N1c3M7IFlBTyBKaWFua2FuZyANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPtb3zOKjujwvU1RST05HPiBSZTogU29saWNpdGF0 aW9uIGZvciBhIA0KZGlzY3Vzc2lvbiBvbiBLZXl3b3JkLWJhc2VkIGFkZHJlc3NpbmcgPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPk9uJm5ic3A7V2VkLCZuYnNwO0Fw ciZuYnNwOzAxLCZuYnNwOzIwMDkmbmJzcDthdCZuYnNwOzExOjE2OjM2QU0mbmJzcDsrMDgwMCw8 L0RJVj4NCjxESVY+Jm5ic3A7emhhbmdndW9xaWFuZyZuYnNwOyAmbHQ7emhhbmdndW9xaWFuZ0Bj bm5pYy5jbiANCiZndDsmbmJzcDt3cm90ZSZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDthJm5ic3A7 bWVzc2FnZSZuYnNwO29mJm5ic3A7MTU2Jm5ic3A7bGluZXMmbmJzcDt3aGljaCZuYnNwO3NhaWQ6 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7RGlmZmVyZW50Jm5ic3A7 ZnJvbSZuYnNwO3NlYXJjaCZuYnNwO2VuZ2luZXMsJm5ic3A7a2V5d29yZC1iYXNlZCZuYnNwO2Fk ZHJlc3NpbmcmbmJzcDtpcyZuYnNwO2FuPC9ESVY+DQo8RElWPiZndDsmbmJzcDthZGRyZXNzaW5n Jm5ic3A7dGVjaG5vbG9neS4mbmJzcDtCYXNlZCZuYnNwO29uJm5ic3A7d2hldGhlciZuYnNwO2Em bmJzcDtrZXl3b3JkJm5ic3A7aXMmbmJzcDtyZWdpc3RlcmVkJm5ic3A7b3I8L0RJVj4NCjxESVY+ Jmd0OyZuYnNwO25vdCwmbmJzcDt0aGUmbmJzcDtyZXNvbHV0aW9uJm5ic3A7cmVzdWx0Jm5ic3A7 aXMmbmJzcDtkZXRlcm1pbnN0aWMmbmJzcDtmb3ImbmJzcDthbnkmbmJzcDtnaXZlbiZuYnNwO2tl eXdvcmQsJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGVuJm5ic3A7aXQm bmJzcDt3aWxsJm5ic3A7aGF2ZSZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO3Byb2JsZW1zJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtkb21haW4mbmJzcDtuYW1lcywmbmJzcDtpbmNsdWRpbmc8L0RJVj4N CjxESVY+YnVyZWF1Y3JhdGljJm5ic3A7cmVnaXN0cmF0aW9uJm5ic3A7cnVsZXMsJm5ic3A7VURS UCwmbmJzcDtsYXd5ZXJzLCZuYnNwO0lDQU5OLCZuYnNwO2V0Yy48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZndDsmbmJzcDtGb3ImbmJzcDtleGFtcGxlLCZuYnNwO2lmJm5ic3A7eW91 Jm5ic3A7YXJlJm5ic3A7YSZuYnNwO2Jsb2dnZXImbmJzcDtvZiZuYnNwO2EmbmJzcDtwb3J0YWwm bmJzcDtibG9nJm5ic3A7d2Vic2l0ZSw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3R5cGljYWxseSwm bmJzcDt5b3UmbmJzcDthcmUmbmJzcDthc3NpZ25lZCZuYnNwO2EmbmJzcDtVUkwmbmJzcDt0aGF0 Jm5ic3A7aWRlbnRpZmllcyZuYnNwO3lvdXImbmJzcDtibG9nLiZuYnNwO0l0Jm5ic3A7aXM8L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwO3VzdWFsbHkmbmJzcDtjb21wb3NlZCZuYnNwO29mJm5ic3A7dHdv Jm5ic3A7cGFydHM6Jm5ic3A7YSZuYnNwO2RvbWFpbiZuYnNwO25hbWUmbmJzcDthbmQmbmJzcDth biZuYnNwO0lEKHR5cGljYWxseSZuYnNwO2E8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO21hZ2ljJm5i c3A7bnVtYmVyKS4mbmJzcDtTbyZuYnNwO2hvdyZuYnNwO2NhbiZuYnNwO3lvdSZuYnNwO2FkdmVy dGlzZSZuYnNwO3lvdXImbmJzcDtibG9nJm5ic3A7dG8mbmJzcDt5b3VyJm5ic3A7ZnJpZW5kcz8m bmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPnRpbnl1cmwuY29tPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5CdXQmbmJzcDtpdCZuYnNwO2lzJm5ic3A7c2ltcGxlciZu YnNwO3RvJm5ic3A7YnV5Jm5ic3A7YSZuYnNwO2RvbWFpbiZuYnNwO25hbWUmbmJzcDthbmQmbmJz cDtyZWRpcmVjdC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtTbywm bmJzcDt3ZSZuYnNwO3RoaW5rJm5ic3A7a2V5d29yZC1iYXNlZCZuYnNwO2FkZHJlc3NpbmcmbmJz cDtpcyZuYnNwO2EmbmJzcDt2ZXJ5Jm5ic3A7dXNlZnVsJm5ic3A7dGVjaG5pcXVlLDwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7ZXNwZWNpYWxseSZuYnNwO2ZvciZuYnNwO25vbi1lbmdsaXNoJm5ic3A7 c3BlYWtpbmcmbmJzcDtjb3VudHJpZXMuJm5ic3A7RXZlbiZuYnNwO2ZvciZuYnNwO2VuZ2xpc2g8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3NwZWFraW5nJm5ic3A7Y291bnRyaWVzLCZuYnNwO3RoZSZu YnNwO2Fib3ZlJm5ic3A7ZXhhbXBsZSZuYnNwO2Fsc28mbmJzcDtpbGx1c3RyYXRlcyZuYnNwO2l0 czwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7cHJhY3RpY2FiaWxpdHkuJm5ic3A7VG8mbmJzcDtpbnRl cm5hdGlvbmFsaXplJm5ic3A7dGhpcyZuYnNwO3NlcnZpY2UmbmJzcDthbmQmbmJzcDtwcm92aWRl Jm5ic3A7Y3Jvc3M8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3Jlc29sdXRpb24mbmJzcDtjYXBhYmls aXR5LCZuYnNwO3dlJm5ic3A7aGlnaGx5Jm5ic3A7cmVjb21tZW5kJm5ic3A7YSZuYnNwO3N0YW5k YXJkJm5ic3A7YmVpbmc8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2RldmVsb3BwZWQuJm5ic3A7PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JJ20mbmJzcDt2ZXJ5Jm5ic3A7c2tlcHRpY2Fs Jm5ic3A7YnV0Jm5ic3A7SSdsbCZuYnNwO3JlYWQmbmJzcDt5b3VyJm5ic3A7ZHJhZnQuPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7T3VyJm5ic3A7a2V5d29yZC1iYXNl ZCZuYnNwO2FkZHJlc3NpbmcmbmJzcDtkcmFmdCZuYnNwO2lzJm5ic3A7YXZhaWxhYmxlJm5ic3A7 YXQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzxBIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtemhhbmcta2V5d29yZC1kZGRzLTAwLCZuYnNwO3doaWNoIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1rZXl3b3JkLWRkZHMtMDAsJm5ic3A7d2hpY2g8 L0E+PC9ESVY+DQo8RElWPiZndDsmbmJzcDtzcGVjaWZpZXMmbmJzcDtrZXl3b3JkLWJhc2VkJm5i c3A7YWRkcmVzc2luZyZuYnNwO2FzJm5ic3A7YSZuYnNwO0RERFMmbmJzcDthcHBsaWNhdGlvbi48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPllvdSZuYnNwO2FwcGFyZW50bHkmbmJzcDtk byZuYnNwO25vdCZuYnNwO21lbnRpb24mbmJzcDtSRkMmbmJzcDsyMzQ1Jm5ic3A7KGtleXdvcmRz Jm5ic3A7YXJlJm5ic3A7YSZuYnNwO3ZlcnkmbmJzcDtvbGQmbmJzcDtpZGVhPC9ESVY+DQo8RElW PndoaWNoJm5ic3A7a2VlcCZuYnNwO3BvcHBpbmcmbmJzcDt1cCZuYnNwO2Zyb20mbmJzcDt0aW1l Jm5ic3A7dG8mbmJzcDt0aW1lKS48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon426548657640_=====-- --=====001_Dragon426548657640_===== Content-Type: text/x-vcard; name="=?gb2312?B?1cW5+se/KDEpLnZjZg==?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?gb2312?B?1cW5+se/KDEpLnZjZg==?=" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOtXFO7n6x78NCkZOOtXFufrHvw0KT1JHOkNOTklD O0xhYnMNClRFTDtXT1JLO1ZPSUNFOjAxMC01ODgxMzAzOA0KVEVMO1dPUks7Vk9JQ0U6MTM0Mzkx NDA0NzkNCkFEUjtXT1JLOjs7OztCZWlqaW5nOztDaGluYQ0KTEFCRUw7V09SSztFTkNPRElORz1R VU9URUQtUFJJTlRBQkxFOg0KDQpCZWlqaW5nDQoNCkNoaW5hDQpFTUFJTDtQUkVGO0lOVEVSTkVU OnpoYW5nZ3VvcWlhbmdAY25uaWMuY24NClJFVjoyMDA5MDQxN1QxNjE2NTJaDQpFTkQ6VkNBUkQN Cg== --=====001_Dragon426548657640_=====-- From bortzmeyer@nic.fr Fri Apr 17 03:09:05 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81A63A6D85 for ; Fri, 17 Apr 2009 03:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkmqo4WSb46H for ; Fri, 17 Apr 2009 03:09:05 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id B73733A6AED for ; Fri, 17 Apr 2009 03:09:04 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 54A251C017B; Fri, 17 Apr 2009 12:10:17 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4F71D1C0179; Fri, 17 Apr 2009 12:10:17 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 439617B0032; Fri, 17 Apr 2009 12:10:17 +0200 (CEST) Date: Fri, 17 Apr 2009 12:10:17 +0200 From: Stephane Bortzmeyer To: zhangguoqiang Subject: Re: Solicitation for a discussion on Keyword-based addressing Message-ID: <20090417101017.GB14293@nic.fr> References: <438575712.22018@cnnic.cn> <200904171616524064316@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904171616524064316@cnnic.cn> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 10:09:05 -0000 On Fri, Apr 17, 2009 at 04:16:52PM +0800, zhangguoqiang wrote a message of 192 lines which said: > you opinion is that with IDN, manual domain name suffix > configuration in browers and redirect, I believe that such "implicit TLD" configuration is *possible*, but I'm very skeptical that it would buy us anything. Keywords give you the *illusion* of simplicity but you lose the power of domain names (and of URIs). Anyway, my own summary: I have nothing against the technical protocol you suggest (NAPTR and so on), I would just prefer that dubious marketing claims about "simplicity" be removed. From alexey.melnikov@isode.com Fri Apr 17 08:48:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DC83A6D6D for ; Fri, 17 Apr 2009 08:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dyJP06EXroh for ; Fri, 17 Apr 2009 08:48:06 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8DA643A6CFA for ; Fri, 17 Apr 2009 08:48:06 -0700 (PDT) Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 17 Apr 2009 16:49:19 +0100 Message-ID: <49E8A4EA.7030008@isode.com> Date: Fri, 17 Apr 2009 16:48:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham Subject: Re: Minutes from informal IETF/W3C meeting about HTML5 work References: <0E44F8EA-C111-45AD-BF86-DA2673B28EF9@mnot.net> In-Reply-To: <0E44F8EA-C111-45AD-BF86-DA2673B28EF9@mnot.net> Content-Type: multipart/alternative; boundary="------------060209090501090008040605" Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 15:48:07 -0000 --------------060209090501090008040605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > Various folks from the IETF and W3C's HTML5 WG got together in San > Francisco last week to discuss the parts of that work. > > Rough minutes are at: > http://esw.w3.org/topic/IETF_HTML5_Meeting_March_2009 From the minutes: > MIME type registrations for text/html and application/xhtml+xml (note > HTML WG issue ISSUE-53 mediatypereg > ) > > * This item appeared to be routine business as usual. Any issues > are internal to the W3C. > * Action Item: Sam to work on reconciling the multiple uses of the > MIME types > W3C can request IESG to update the MIME type registration. I am the AD tasked with reviewing MIME type registrations from other SDOs. So people can email me if they want early/more informal reviews. --------------060209090501090008040605 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Nottingham wrote:
Various folks from the IETF and W3C's HTML5 WG got together in San  Francisco last week to discuss the parts of that work.

Rough minutes are at:
  http://esw.w3.org/topic/IETF_HTML5_Meeting_March_2009
>From the minutes:

MIME type registrations for text/html and application/xhtml+xml (note HTML WG issue ISSUE-53 mediatypereg)

  • This item appeared to be routine business as usual. Any issues are internal to the W3C.
  • Action Item: Sam to work on reconciling the multiple uses of the MIME types
W3C can request IESG to update the MIME type registration. I am the AD tasked with reviewing MIME type registrations from other SDOs. So people can email me if they want early/more informal reviews.

--------------060209090501090008040605-- From alexey.melnikov@isode.com Fri Apr 17 09:09:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F100228C113 for ; Fri, 17 Apr 2009 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67cnYhoouciR for ; Fri, 17 Apr 2009 09:09:35 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B97E13A6889 for ; Fri, 17 Apr 2009 09:09:34 -0700 (PDT) Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 17 Apr 2009 17:10:47 +0100 Message-ID: <49E8A9F1.5070407@isode.com> Date: Fri, 17 Apr 2009 17:10:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham Subject: URI/IRI revisions (was Re: Minutes from informal IETF/W3C meeting about HTML5 work) References: <0E44F8EA-C111-45AD-BF86-DA2673B28EF9@mnot.net> In-Reply-To: <0E44F8EA-C111-45AD-BF86-DA2673B28EF9@mnot.net> Content-Type: multipart/alternative; boundary="------------080208030802060706090809" Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 16:09:36 -0000 --------------080208030802060706090809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Mark Nottingham wrote: > Various folks from the IETF and W3C's HTML5 WG got together in San =20 > Francisco last week to discuss the parts of that work. > > Rough minutes are at: > http://esw.w3.org/topic/IETF_HTML5_Meeting_March_2009 From the minutes: > HTML5's URI section (DanConnolly =20 > and Larry Masinter to work on this; e.g. HTML WG action 68=20 > ) > > * We discussed IDN and URI/IRI (international domain names vs. > HTML5/W3C use of IRI). Changes to IRI would impact specs like > Atom. Larry advocated revising this spec, others were less > enthusiastic. It would be a big undertaking, and it wasn't clear > that Martin D=FCrst was available. > I talked to Martin using Skype today and he said he was available. He=20 also mentioned that he would like to have a co-editor and mentioned=20 Larry and few other names. > * Rob Sayre suggested the name "Hypertext References". This was > met with wide approval. > * > > Action Item : Dan > to reformat the document as an Internet Draft > Looking forward to reading this. --------------080208030802060706090809 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Nottingham wrote:
Various folks from the IETF and W3C's HTML5 WG got together in San  Francisco last week to discuss the parts of that work.

Rough minutes are at:
  http://esw.w3.org/topic/IETF_HTML5_Meeting_March_2009
>From the minutes:

HTML5's URI section (DanConnolly and Larry Masinter to work on this; e.g. HTML WG action 68)

  • We discussed IDN and URI/IRI (international domain names vs. HTML5/W3C use of IRI). Changes to IRI would impact specs like Atom. Larry advocated revising this spec, others were less enthusiastic. It would be a big undertaking, and it wasn't clear that Martin Dürst was available.
I talked to Martin using Skype today and he said he was available. He also mentioned that he would like to have a co-editor and mentioned Larry and few other names.
  • Rob Sayre suggested the name "Hypertext References". This was met with wide approval.

  • Action Item: Dan to reformat the document as an Internet Draft

Looking forward to reading this.

--------------080208030802060706090809-- From barryleiba.mailing.lists@gmail.com Wed Apr 22 12:23:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4830F3A6D45 for ; Wed, 22 Apr 2009 12:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuK8yfwsHLyR for ; Wed, 22 Apr 2009 12:23:53 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 517073A6C36 for ; Wed, 22 Apr 2009 12:23:53 -0700 (PDT) Received: by bwz7 with SMTP id 7so149207bwz.37 for ; Wed, 22 Apr 2009 12:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=OybNWbwyD6GqEf8coVWernnAhpOqfZZK55No7g32sFc=; b=Qt9tXodwcp6cC6KqcodKQdFjRqZWtfJgNfhrquacdlIBMKeU7+xFu1jG1z9QMlHhuD cSeColIftNHbhpZuP2i+KAkLBpU9bhaoLTv0qkQBGP9EUyc3INBFaRvRtXiJNNWi6Cgp 5XohceGYXcy1MsidO5jxHfot+jbhTsJV8opVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WMAOoDkKX7IOuEoaYJYuOdVtLfIS9dloTwrK0wHc40vIOXSVUKZZgQNXOgbzRkv7lQ S4mxI7Nvpc4efXkFi59qjm3SW+jZ3LUfoMsfxiiZfOQSgb2f0PRY15g6E3boscOPx4bj CTAnvHp4lci0VzRpSvrmE0MrgFd1NQmRxEbas= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.223.126.66 with SMTP id b2mr61384fas.3.1240428309950; Wed, 22 Apr 2009 12:25:09 -0700 (PDT) In-Reply-To: <21606dcf0904162309k70d83661uae6810f48c7f8799@mail.gmail.com> References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> <49E521DB.8080403@cs.utk.edu> <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> <49E5D4FE.1010003@cs.utk.edu> <21606dcf0904162309k70d83661uae6810f48c7f8799@mail.gmail.com> Date: Wed, 22 Apr 2009 15:25:09 -0400 X-Google-Sender-Auth: 679e2073a7f92cdf Message-ID: <6c9fcc2a0904221225o91a6966q76a6c23b1ac9d2f5@mail.gmail.com> Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP From: Barry Leiba To: Sam Johnston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Keith Moore , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 19:23:54 -0000 Hm. The problem, as I see it, with defining "persistence" is that one wants different things in different contexts. Consider these three cases of things I might write: 1 --------------------------------------------------- Note that any comments you post here are subject to my host's copyright policy: [link to current copyright policy at time of clicking]. ------------------------------------------------------ 2 --------------------------------------------------- Note that the comment you just made is subject to my host's copyright policy: [link to version of copyright policy in effect at the time of writing]. ------------------------------------------------------ 3 --------------------------------------------------- Check out the stupid typo in my host's copyright policy: [link to immutable snapshot of copyright policy at the time of writing]. ------------------------------------------------------ In case 1, I want a pointer that will always get me to the current policy at the time you click the link. In case 2, I want a pointer that will always get me to the policy that's in effect when I wrote the text, regardless of subsequent policy changes. In case 3, I want a pointer that will always get me to the version with the typo, even if they go and fix the typo without issuing a new policy version. With URL shorteners, you have no idea what you'll get, even when the link isn't broken. There's no guarantee that the content the link points to has any relation whatever to what was there when the short URL was made (if, say, the URL was set up to point to the current front page of the newspaper). With "short URLs" created by the content provider, you have a chance of at least knowing what you're getting. But what is it that you want to get, and how do you specify it. There are at least the three use cases above, and perhaps others. Barry From samj@samj.net Wed Apr 22 13:38:40 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5AE3A6BA6 for ; Wed, 22 Apr 2009 13:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtGN8ucm0wnn for ; Wed, 22 Apr 2009 13:38:39 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id 97ED73A6864 for ; Wed, 22 Apr 2009 13:38:39 -0700 (PDT) Received: by qyk42 with SMTP id 42so359170qyk.29 for ; Wed, 22 Apr 2009 13:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.96.71 with SMTP id g7mr427161vcn.5.1240432796551; Wed, 22 Apr 2009 13:39:56 -0700 (PDT) In-Reply-To: <6c9fcc2a0904221225o91a6966q76a6c23b1ac9d2f5@mail.gmail.com> References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> <49E521DB.8080403@cs.utk.edu> <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> <49E5D4FE.1010003@cs.utk.edu> <21606dcf0904162309k70d83661uae6810f48c7f8799@mail.gmail.com> <6c9fcc2a0904221225o91a6966q76a6c23b1ac9d2f5@mail.gmail.com> Date: Wed, 22 Apr 2009 22:39:56 +0200 Message-ID: <21606dcf0904221339v740d9f88l3b42e452a89cf7e7@mail.gmail.com> Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP From: Sam Johnston To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Keith Moore , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:38:40 -0000 G'day Barry, Is any of this specific to short links or does it apply across the board? I would suggest the latter. Sam on iPhone On 4/22/09, Barry Leiba wrote: > Hm. > > The problem, as I see it, with defining "persistence" is that one > wants different things in different contexts. Consider these three > cases of things I might write: > > 1 --------------------------------------------------- > Note that any comments you post here are subject to my host's > copyright policy: [link to current copyright policy at time of > clicking]. > ------------------------------------------------------ > > 2 --------------------------------------------------- > Note that the comment you just made is subject to my host's copyright > policy: [link to version of copyright policy in effect at the time of > writing]. > ------------------------------------------------------ > > 3 --------------------------------------------------- > Check out the stupid typo in my host's copyright policy: > [link to immutable snapshot of copyright policy at the time of writing]. > ------------------------------------------------------ > > In case 1, I want a pointer that will always get me to the current > policy at the time you click the link. > > In case 2, I want a pointer that will always get me to the policy > that's in effect when I wrote the text, regardless of subsequent > policy changes. > > In case 3, I want a pointer that will always get me to the version > with the typo, even if they go and fix the typo without issuing a new > policy version. > > With URL shorteners, you have no idea what you'll get, even when the > link isn't broken. There's no guarantee that the content the link > points to has any relation whatever to what was there when the short > URL was made (if, say, the URL was set up to point to the current > front page of the newspaper). > > With "short URLs" created by the content provider, you have a chance > of at least knowing what you're getting. But what is it that you want > to get, and how do you specify it. There are at least the three use > cases above, and perhaps others. > > Barry > From barryleiba@gmail.com Wed Apr 22 13:43:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F3D3A6864 for ; Wed, 22 Apr 2009 13:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OVRCD9YdnKD for ; Wed, 22 Apr 2009 13:43:25 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 198C83A679C for ; Wed, 22 Apr 2009 13:43:24 -0700 (PDT) Received: by ewy24 with SMTP id 24so192942ewy.37 for ; Wed, 22 Apr 2009 13:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=4of5AY/v5Ozbq7DqOr+lrPsyXD+iSgDnVtSgeWnZ6wg=; b=tXjxETv2fHfRd8/EQDZSm74hdNq2pN05x8kU0G7JN+ZUBouY/bRPnHWh1za+yiHpBb 8hQsMEr7fbhnIJqgK+1SPUlOi0Pa6yH97xB4c9+c7MgBPSz46/w9rPurtjiqxb2KX9G6 nSyT4Aowp8OabPQ+/jmXKkOhwOUHFoxyV+KpY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AD4lhm7nCH23TxE0t5Bu8s0cATEIfw5lkdofU8T3TfbxulB+dbcauA0p1VhvWGy9ll n9we+TzBy+V+HSTy2IP0oDEWXNWJC10raMGo7fcn/364JiZ8ZkrXAVbeX+TQHTkBrnwK vvOUXllOBwWZWYeEI9UrKLekL6BFHP+un5XDc= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.20.17 with SMTP id 17mr6742185ebt.53.1240433081818; Wed, 22 Apr 2009 13:44:41 -0700 (PDT) In-Reply-To: <21606dcf0904221339v740d9f88l3b42e452a89cf7e7@mail.gmail.com> References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> <49E521DB.8080403@cs.utk.edu> <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> <49E5D4FE.1010003@cs.utk.edu> <21606dcf0904162309k70d83661uae6810f48c7f8799@mail.gmail.com> <6c9fcc2a0904221225o91a6966q76a6c23b1ac9d2f5@mail.gmail.com> <21606dcf0904221339v740d9f88l3b42e452a89cf7e7@mail.gmail.com> Date: Wed, 22 Apr 2009 16:44:41 -0400 X-Google-Sender-Auth: cdc5f6a1a114fd7d Message-ID: <9abf48a60904221344x52a7d27ei5c53c6dd518c2e99@mail.gmail.com> Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP From: Barry Leiba To: Sam Johnston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Keith Moore , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:43:26 -0000 > Is any of this specific to short links or does it apply across the > board? I would suggest the latter. It does, but the connection to short links is that if a page offers a "short link" (or a client asks for one), there probably has to be some way to communicate the scope. Otherwise, the client or user won't know what to rely on the short link for. Barry From Nicolas.Williams@sun.com Wed Apr 22 14:33:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D4E3A68F2 for ; Wed, 22 Apr 2009 14:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.879 X-Spam-Level: X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJzJFCPIyAtq for ; Wed, 22 Apr 2009 14:33:50 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id BEF2028C264 for ; Wed, 22 Apr 2009 14:33:47 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3MLZ3xO014695 for ; Wed, 22 Apr 2009 21:35:03 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3MLZ2gw025270 for ; Wed, 22 Apr 2009 15:35:02 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3MKtSpX016407; Wed, 22 Apr 2009 15:55:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3MKtLde016406; Wed, 22 Apr 2009 15:55:21 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 22 Apr 2009 15:55:21 -0500 From: Nicolas Williams To: Barry Leiba Subject: Re: rel="shortlink" proposal for advertising short URLs in HTML/HTTP Message-ID: <20090422205521.GZ1500@Sun.COM> References: <21606dcf0904141153t3433975fh2bacf75f37353beb@mail.gmail.com> <49E521DB.8080403@cs.utk.edu> <21606dcf0904150508k210991b6gf8001c262d305a3f@mail.gmail.com> <49E5D4FE.1010003@cs.utk.edu> <21606dcf0904162309k70d83661uae6810f48c7f8799@mail.gmail.com> <6c9fcc2a0904221225o91a6966q76a6c23b1ac9d2f5@mail.gmail.com> <21606dcf0904221339v740d9f88l3b42e452a89cf7e7@mail.gmail.com> <9abf48a60904221344x52a7d27ei5c53c6dd518c2e99@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9abf48a60904221344x52a7d27ei5c53c6dd518c2e99@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: Keith Moore , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:33:50 -0000 On Wed, Apr 22, 2009 at 04:44:41PM -0400, Barry Leiba wrote: > > Is any of this specific to short links or does it apply across the > > board? I would suggest the latter. > > It does, but the connection to short links is that if a page offers a > "short link" (or a client asks for one), there probably has to be some > way to communicate the scope. Otherwise, the client or user won't > know what to rely on the short link for. Arguably the scope should be the same as for the long link. Nico -- From iljitsch@muada.com Mon Apr 27 02:11:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844293A6E95 for ; Mon, 27 Apr 2009 02:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEq+k9HvlDXX for ; Mon, 27 Apr 2009 02:11:27 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7D43A6B9E for ; Mon, 27 Apr 2009 02:11:24 -0700 (PDT) Received: from [10.1.3.180] (wlap003.it.uc3m.es [163.117.139.45]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n3R9BGCK014101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Apr 2009 11:11:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <45212F9C-51BA-4A0F-93B1-E64CD499DB81@muada.com> From: Iljitsch van Beijnum To: apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Feedback requested:FTP ALG for IPv6-to-IPv4 translation Date: Mon, 27 Apr 2009 11:10:48 +0200 References: <20090427084757.ED90228C0D0@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 09:11:28 -0000 Hi all, In the BEHAVE wg we're working on IPv6-to-IPv4 translation. One prominent protocol that has trouble with this is FTP, so we're thinking of making an FTP ALG part of this. I wrote a draft on how to do this, and I would very much like some feedback. The draft is only 6 pages. Thanks, Iljitsch van Beijnum Begin forwarded message: > Filename: draft-van-beijnum-behave-ftp64 > Revision: 01 > Title: An FTP Application Layer Gateway for IPv6-to-IPv4 translation > Creation_date: 2009-04-27 > WG ID: Independent Submission > Number_of_pages: 6 > Abstract: > The only FTP mode that works without changes through an IPv6-to-IPv4 > translator is extended passive, introduced in 1998. However, many > existing FTP servers don't support this mode, making it impossible to > support the File Transfer Protocol through an IPv6-to-IPv4 translator > without an Application Layer Gateway. This document describes the > behavior of such an ALG. http://www.ietf.org/internet-drafts/draft-van-beijnum-behave-ftp64-01.txt From iljitsch@muada.com Mon Apr 27 02:16:08 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE0028C0F1 for ; Mon, 27 Apr 2009 02:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGcQ4Dr5lEPO for ; Mon, 27 Apr 2009 02:16:08 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 8044F3A6869 for ; Mon, 27 Apr 2009 02:15:38 -0700 (PDT) Received: from [10.1.3.180] (wlap003.it.uc3m.es [163.117.139.45]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n3R9FKP7014143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Apr 2009 11:15:20 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <45212F9C-51BA-4A0F-93B1-E64CD499DB81@muada.com> From: Iljitsch van Beijnum To: apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Feedback requested:FTP ALG for IPv6-to-IPv4 translation Date: Mon, 27 Apr 2009 11:10:48 +0200 References: <20090427084757.ED90228C0D0@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 09:16:08 -0000 Hi all, In the BEHAVE wg we're working on IPv6-to-IPv4 translation. One prominent protocol that has trouble with this is FTP, so we're thinking of making an FTP ALG part of this. I wrote a draft on how to do this, and I would very much like some feedback. The draft is only 6 pages. Thanks, Iljitsch van Beijnum Begin forwarded message: > Filename: draft-van-beijnum-behave-ftp64 > Revision: 01 > Title: An FTP Application Layer Gateway for IPv6-to-IPv4 translation > Creation_date: 2009-04-27 > WG ID: Independent Submission > Number_of_pages: 6 > Abstract: > The only FTP mode that works without changes through an IPv6-to-IPv4 > translator is extended passive, introduced in 1998. However, many > existing FTP servers don't support this mode, making it impossible to > support the File Transfer Protocol through an IPv6-to-IPv4 translator > without an Application Layer Gateway. This document describes the > behavior of such an ALG. http://www.ietf.org/internet-drafts/draft-van-beijnum-behave-ftp64-01.txt From iljitsch@muada.com Mon Apr 27 02:27:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C653A6B86 for ; Mon, 27 Apr 2009 02:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.207 X-Spam-Level: X-Spam-Status: No, score=-5.207 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAzzmibSy2ZJ for ; Mon, 27 Apr 2009 02:27:46 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 7F70D3A6BD7 for ; Mon, 27 Apr 2009 02:27:46 -0700 (PDT) Received: from [10.1.3.180] (wlap003.it.uc3m.es [163.117.139.45]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n3R9RYFh014218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Apr 2009 11:27:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <9071FB27-76C0-43D1-B86C-7CC4ADD15F5F@muada.com> From: Iljitsch van Beijnum To: apps-discuss@ietf.org In-Reply-To: <45212F9C-51BA-4A0F-93B1-E64CD499DB81@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Feedback requested:FTP ALG for IPv6-to-IPv4 translation Date: Mon, 27 Apr 2009 11:27:39 +0200 References: <20090427084757.ED90228C0D0@core3.amsl.com> <45212F9C-51BA-4A0F-93B1-E64CD499DB81@muada.com> X-Mailer: Apple Mail (2.930.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 09:27:47 -0000 On 27 apr 2009, at 11:10, Iljitsch van Beijnum wrote: > In the BEHAVE wg we're working on IPv6-to-IPv4 translation. One > prominent protocol that has trouble with this is FTP, so we're > thinking of making an FTP ALG part of this. I wrote a draft on how > to do this, and I would very much like some feedback. The draft is > only 6 pages. One thing that would be good to know is whether ALL IPv6 FTP clients do EPSV or if there are also ones that do EPRT or, worse, active FTP without issuing EPRT. From lars.eggert@nokia.com Mon Apr 27 08:11:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460553A6EA7 for ; Mon, 27 Apr 2009 08:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj3NEdUBfzW5 for ; Mon, 27 Apr 2009 08:11:50 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id A74AA3A69C4 for ; Mon, 27 Apr 2009 08:11:49 -0700 (PDT) Received: from lars-2.vzbi.com (lars-2.vzbi.com [166.58.67.119]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3RFD4ff077668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2009 18:13:06 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Iljitsch van Beijnum In-Reply-To: <9071FB27-76C0-43D1-B86C-7CC4ADD15F5F@muada.com> Content-Type: multipart/signed; boundary=Apple-Mail-17-544974513; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Feedback requested:FTP ALG for IPv6-to-IPv4 translation Date: Mon, 27 Apr 2009 11:12:59 -0400 References: <20090427084757.ED90228C0D0@core3.amsl.com> <45212F9C-51BA-4A0F-93B1-E64CD499DB81@muada.com> <9071FB27-76C0-43D1-B86C-7CC4ADD15F5F@muada.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Mon, 27 Apr 2009 18:13:06 +0300 (EEST) Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 15:11:51 -0000 --Apple-Mail-17-544974513 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-4-27, at 5:27, Iljitsch van Beijnum wrote: > On 27 apr 2009, at 11:10, Iljitsch van Beijnum wrote: > >> In the BEHAVE wg we're working on IPv6-to-IPv4 translation. One >> prominent protocol that has trouble with this is FTP, so we're >> thinking of making an FTP ALG part of this. I wrote a draft on how >> to do this, and I would very much like some feedback. The draft is >> only 6 pages. > > One thing that would be good to know is whether ALL IPv6 FTP clients > do EPSV or if there are also ones that do EPRT or, worse, active FTP > without issuing EPRT. After 10+ years of IPv4 NAT, are there still FTP clients around that need ALGs? And if there are, what are the chances they can talk IPv6? Lars --Apple-Mail-17-544974513 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MjcxNTEyNTlaMCMGCSqGSIb3DQEJBDEWBBRvSLaaPpp+pqsb o8faA71T4fTosDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAbUtBTFdoxJeQIdwrbsVNUWyKxN5BuyDT7V1c9Dncyxy8RekaKLCQ avHm6d6Sxric7req2I07utXvO87hzZcZQnyK1AiuSEmVwAH24cf74JlGE+2/2edNgxESvEBSZ2GS WWs0lAbd7pCyLbX9psJr7gJanDJyxIlktx8VFt+Ja0zZobKWrYI3zAXZ2VghCTXJ1VGLCb/vwPsZ wGbwFtWUJNrARrOxTIfSx7brf+0rBZ8bhHHm6OZgUcv/m97HOZ4ghm4cSCrZAp2M+DYpvvdzMceL exG3dIfCu1URkLDgvbI7QOue3mBMzcdhfwdWNcw0dbB2XRTnvMAiDQ5Nj8wxWgAAAAAAAA== --Apple-Mail-17-544974513-- From iljitsch@muada.com Mon Apr 27 08:42:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EACD13A677D for ; Mon, 27 Apr 2009 08:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.972 X-Spam-Level: X-Spam-Status: No, score=-4.972 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV2L4yasU+iw for ; Mon, 27 Apr 2009 08:42:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D512C3A67DB for ; Mon, 27 Apr 2009 08:42:30 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.66]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n3RFgOdw016496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Apr 2009 17:42:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Feedback requested:FTP ALG for IPv6-to-IPv4 translation Date: Mon, 27 Apr 2009 17:43:14 +0200 References: <20090427084757.ED90228C0D0@core3.amsl.com> <45212F9C-51BA-4A0F-93B1-E64CD499DB81@muada.com> <9071FB27-76C0-43D1-B86C-7CC4ADD15F5F@muada.com> X-Mailer: Apple Mail (2.930.3) Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 15:42:32 -0000 On 27 apr 2009, at 17:12, Lars Eggert wrote: >> One thing that would be good to know is whether ALL IPv6 FTP clients >> do EPSV or if there are also ones that do EPRT or, worse, active FTP >> without issuing EPRT. > After 10+ years of IPv4 NAT, are there still FTP clients around that > need ALGs? And if there are, what are the chances they can talk IPv6? Well, unless they hid it really well, the command line FTP client on Windows (tested with win7 beta) only supports active FTP. It does support IPv6, though. Passive mode FTP will work through a normal NAT but not through an IPv6/IPv4 translator as it still echoes back the server's IP address. So without an ALG, you need EPSV, as this is the only type of FTP that doesn't explicitly spell out an IP address. I did some testing, and out of 25 IPv4 FTP servers I tried, 12 worked with EPSV and 13 didn't. So if we want to be compatible with more than 48% of the FTP servers we need to be able to translate EPSV into PASV and maybe also EPRT into PORT. And then we still don't have compatibility with really old school FTP clients that don't issue EPSV or EPRT but simply expect the default case of active FTP towards the default port 20. I would certainly hope those are no longer around, and certainly not on IPv6 systems. I'm less concerned about client compatibility as users can relatively easily install a different client. But if a server doesn't support EPSV IPv6-only users who want to talk to an IPv4-only FTP server through a translator are dead in the water without EPSV to PASV translation in an ALG. From hardie@qualcomm.com Mon Apr 27 09:44:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD5C3A6B17 for ; Mon, 27 Apr 2009 09:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.083 X-Spam-Level: X-Spam-Status: No, score=-103.083 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEhcsR0gJGSU for ; Mon, 27 Apr 2009 09:44:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0461D3A6F4D for ; Mon, 27 Apr 2009 09:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1240850764; x=1272386764; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20<20090427084757.ED 90228C0D0@core3.amsl.com>=0D=0A=20<45212F9C-51BA-4A0F-93B 1-E64CD499DB81@muada.com>=0D=0A=20<9071FB27-76C0-43D1-B86 C-7CC4ADD15F5F@muada.com>=0D=0A=20=0D=0A=20|Date:=20Mon,=2027=20Apr=202009 =2009:46:01=20-0700|To:=20Iljitsch=20van=20Beijnum=20,=0D=0A=20=20=20=20=20=20=20=20Lars=20Egg ert=0D=0A=09|From:=20Ted=20Hardie =20|Subject:=20Re:=20Feedback=20requ ested:FTP=20ALG=20for=20IPv6-to-IPv4=20translation|CC:=20 "apps-discuss@ietf.org"=20 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5598"=3B=20 a=3D"17494910"; bh=dkW+zvhzNkctO/UG9ZUF/wvJO3LrFUWwUjV07GtkS5Y=; b=OsVVIEYbW9ZtjUzW9tTUlAloU74rgV2u4KJTcI+qOekAT0U83MEuhw5j cV1sSmF4QEoxdOMG8LHoRXzeqAUmwV9ZB9XupO5keHFlzjkDQdA8KxE19 YbUPiqTTmr0wKqnK4o1w1Q/8jielPxwxfwzBBPbzUho2bAU0nADIfrU2H 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5598"; a="17494910" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2009 09:46:03 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3RGk3id031745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2009 09:46:03 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3RGk2O0016376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Apr 2009 09:46:03 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 27 Apr 2009 09:46:03 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 27 Apr 2009 09:46:02 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <20090427084757.ED90228C0D0@core3.amsl.com> <45212F9C-51BA-4A0F-93B1-E64CD499DB81@muada.com> <9071FB27-76C0-43D1-B86C-7CC4ADD15F5F@muada.com> Date: Mon, 27 Apr 2009 09:46:01 -0700 To: Iljitsch van Beijnum , Lars Eggert From: Ted Hardie Subject: Re: Feedback requested:FTP ALG for IPv6-to-IPv4 translation Content-Type: text/plain; charset="us-ascii" Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:44:44 -0000 At 8:43 AM -0700 4/27/09, Iljitsch van Beijnum wrote: > >I'm less concerned about client compatibility as users can relatively >easily install a different client. But if a server doesn't support >EPSV IPv6-only users who want to talk to an IPv4-only FTP server >through a translator are dead in the water without EPSV to PASV >translation in an ALG. Your end statement ("dead in the water") sounds true, but the one preceding it is somewhat questionable. The ability to install and use a new client is a real concern. Perhaps s/relatively easily/at least possibly in some environments/ ? regards, Ted From iljitsch@muada.com Mon Apr 27 12:09:29 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAA73A6FF3 for ; Mon, 27 Apr 2009 12:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbBwtZtzQVfN for ; Mon, 27 Apr 2009 12:09:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 36B4D3A6FED for ; Mon, 27 Apr 2009 12:09:28 -0700 (PDT) Received: from [192.168.0.195] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n3RJ95BD018202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Apr 2009 21:09:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <0D27E83E-E17D-4008-8722-90E363BFEC88@muada.com> From: Iljitsch van Beijnum To: Ted Hardie In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Feedback requested:FTP ALG for IPv6-to-IPv4 translation Date: Mon, 27 Apr 2009 21:09:40 +0200 References: <20090427084757.ED90228C0D0@core3.amsl.com> <45212F9C-51BA-4A0F-93B1-E64CD499DB81@muada.com> <9071FB27-76C0-43D1-B86C-7CC4ADD15F5F@muada.com> X-Mailer: Apple Mail (2.930.3) Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:09:29 -0000 On 27 apr 2009, at 18:46, Ted Hardie wrote: > Your end statement ("dead in the water") sounds true, but the one > preceding it is somewhat questionable. The ability to install and use > a new client is a real concern. Perhaps s/relatively easily/at > least possibly > in some environments/ ? Well, that text isn't in the draft so I don't think we have to carefully craft it... The point is that if it's your box or your company's box that insists on a mode of FTP that doesn't work through the NAT, there are ways to work around that, either by getting a new client, or through some sort of gateway. Obviously in some environments users may not be able to do that themselves but hopefully, if an organization uses IPv6 behind a NAT64 and they need FTP they're smart enough to make that work and not insist on broken clients only. On the other hand, getting ftp.dell.com, ftp.sun.com or ftp.lexmark.com to upgrade their servers (or, more likely, their firewalls) is probably not realistic. In the current draft, EPSV to PASV translation is SHOULD (I guess it could be MUST but nobody is forcing anyone to implement an FTP ALG in the first place), so all clients that use EPSV will work, as all FTP servers that I tested work with PASV. EPRT to PORT is MAY. So that could leave people depending on the Microsoft command line FTP client or similar in the cold. Anyone in favor of making EPRT to PORT SHOULD or MUST as well? From brad@fitzpat.com Wed Apr 29 10:48:48 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CDC03A6D07 for ; Wed, 29 Apr 2009 10:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy2TZ1GNop2l for ; Wed, 29 Apr 2009 10:48:47 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 400863A6A7D for ; Wed, 29 Apr 2009 10:48:46 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1422162yxb.49 for ; Wed, 29 Apr 2009 10:50:09 -0700 (PDT) MIME-Version: 1.0 Sender: brad@fitzpat.com Received: by 10.101.66.15 with SMTP id t15mr1197733ank.38.1241027409103; Wed, 29 Apr 2009 10:50:09 -0700 (PDT) Date: Wed, 29 Apr 2009 10:50:09 -0700 X-Google-Sender-Auth: 3776a406499e683c Message-ID: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> Subject: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 From: Brad Fitzpatrick To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=00163662e65ce04b6d0468b535d6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:14:12 -0000 --00163662e65ce04b6d0468b535d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd like to discuss the proliferation of well-known URLs, notably the new one proposed in draft-nottingham-site-meta-01. I talked to Eran Hammer-Lahav about this, but he suggested I bring it up here: I object to the use of /host-meta for two reasons: 1) I feel that /host-meta is too casual of a name and prone to collisions. It matches /^[\w\-]+$/, which I think is a subset of a fair number of sites= ' usernames. 2) There are already too many well-known URLs cluttering up the namespace: /robots.txt /favicon.ico /crossdomain.xml We can't fix those, but rather than make another one (and don't kid yourself: /host-meta won't be the last one) and make the situation worse, I propose we do the respectful thing and make a well-known directory to put this and all future well-known files in. e.g.: /;well_known/host-meta i.e. put something ugly and weird in there, like a semicolon, to minimize the chance that it interferes with people's existing URL structure. Hopefully when the next spec decides to add a new well-known URL, they put it under /;well_known/. "But host-meta is the final one, forever!", you say. I doubt it. XRD will become pass=C3=A9, or people will object to doi= ng two HTTP requests when they really want to do one, so yet another well-known UR= L will be born. Let's give it a future home now. Thoughts? - Brad --00163662e65ce04b6d0468b535d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd like to discuss the proliferation of well-known URLs, notably the n= ew one proposed in draft-nottingham-site-meta-01.

I talked to Eran H= ammer-Lahav about this, but he suggested I bring it up here:

I objec= t to the use of /host-meta for two reasons:

1) I feel that /host-meta is too casual of a name and prone to collisio= ns.=C2=A0 It matches /^[\w\-]+$/, which I think is a subset of a fair number of sites' usern= ames.

2) There are already too many well-known URLs cluttering up th= e namespace:

/robots.txt
/favicon.ico
/crossdomain.xml

We can't fix= those, but rather than make another one (and don't kid yourself: /host-meta won't be the l= ast one) and make the situation worse, I propose we do the respectful thing and= make a well-known directory to put this and all future well-known files in.=C2=A0 e.g.:

/;well_known/host-meta

i.e. put something ugly and weird in ther= e, like a semicolon, to minimize the chance that it interferes with people&= #39;s existing URL structure.

Hopefully when the next spec decides t= o add a new well-known URL, they put it under /;well_known/.=C2=A0 "Bu= t host-meta is the final one, forever!", you say.=C2=A0 I doubt it.=C2= =A0 XRD will become pass=C3=A9, or people will object to doing two HTTP req= uests when they really want to do one, so yet another well-known URL will b= e born.=C2=A0 Let's give it a future home now.

Thoughts?

- Brad

--00163662e65ce04b6d0468b535d6-- From alexey.melnikov@isode.com Wed Apr 29 11:36:41 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4EE3A689C for ; Wed, 29 Apr 2009 11:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcYr1VZTeHhg for ; Wed, 29 Apr 2009 11:36:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 45AC83A7143 for ; Wed, 29 Apr 2009 11:36:33 -0700 (PDT) Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 29 Apr 2009 19:37:54 +0100 Message-ID: <49F89E57.80708@isode.com> Date: Wed, 29 Apr 2009 19:37:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Brad Fitzpatrick Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> In-Reply-To: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:36:41 -0000 Brad Fitzpatrick wrote: > I'd like to discuss the proliferation of well-known URLs, notably the=20 > new one proposed in draft-nottingham-site-meta-01. > > I talked to Eran Hammer-Lahav about this, but he suggested I bring it=20 > up here: > > I object to the use of /host-meta for two reasons: > > 1) I feel that /host-meta is too casual of a name and prone to=20 > collisions. It matches /^[\w\-]+$/, which I think is a subset of a=20 > fair number of sites' usernames. > > 2) There are already too many well-known URLs cluttering up the namespace: > > /robots.txt > /favicon.ico > /crossdomain.xml > > We can't fix those, but rather than make another one (and don't kid=20 > yourself: /host-meta won't be the last one) and make the situation=20 > worse, I propose we do the respectful thing and make a well-known=20 > directory to put this and all future well-known files in. e.g.: > > /;well_known/host-meta > > i.e. put something ugly and weird in there, like a semicolon, to=20 > minimize the chance that it interferes with people's existing URL=20 > structure. > > Hopefully when the next spec decides to add a new well-known URL, they=20 > put it under /;well_known/. "But host-meta is the final one,=20 > forever!", you say. I doubt it. XRD will become pass=C3=A9, or people=20 > will object to doing two HTTP requests when they really want to do=20 > one, so yet another well-known URL will be born. Let's give it a=20 > future home now. > > Thoughts? This sounds sensible to me. Are you volunteering to write a draft?