From Lisa.Dusseault@messagingarchitects.com Mon Mar 2 17:31: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 DD9CC3A6803 for ; Mon, 2 Mar 2009 17:31:50 -0800 (PST) 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 Y7XLiCRgF4ty for ; Mon, 2 Mar 2009 17:31:49 -0800 (PST) Received: from mplus1.messagingarchitects.com (bastille.messagingarchitects.com [216.94.112.120]) by core3.amsl.com (Postfix) with ESMTP id 4AD353A67F7 for ; Mon, 2 Mar 2009 17:31:49 -0800 (PST) Received: from messagingarchitects.com Lisa.Dusseault@messagingarchitects.com [10.200.1.71] by mplus1.messagingarchitects.com with M+ Extreme Email Engine 2008.4.debug via secured & encrypted transport (TLS); Mon, 02 Mar 2009 20:32:00 -0500 X-MailFrom: Lisa.Dusseault@messagingarchitects.com Received: from [10.1.30.122] ([::ffff:10.1.30.122]) by messagingarchitects.com with ESMTP; Mon, 02 Mar 2009 20:31:45 -0500 Message-Id: <50C2EEAF-4840-4B14-9FBC-7325C15AAEEB@messagingarchitects.com> From: Lisa Dusseault To: Apps Discuss , Lisa Dusseault's Chairs Content-Type: multipart/alternative; boundary=Apple-Mail-36-38666620 Subject: Lisa's Apps Area Activity Report for Feb 2009 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 17:31:44 -0800 X-Mailer: Apple Mail (2.930.3) X-Mplus-Virus-Scanned: mplusversion: 2008.4.debug ; timestamp: Mon, 02 Mar 2009 20:32:00 -0500 engine: XCFAntiVirus1 Engine; version: 3902 (20090302)/1082 (20090213)/1089 (20090219)/1.009 (20070910) result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus2 Engine; version: 5.1.00/5541 result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus3 Engine; version: 5.07.0001 result: 0 ; ref: str=0001.0A010204.49AC8889.0033,ss=1,fgs=0; status: success; error: none X-Mplus-Spam-Scanned: mplusversion: 2008.4.debug ; timestamp: Mon, 02 Mar 2009 20:32:02 -0500 engine: XCFSPAM1 Engine ; version: Not Available ; level: 0 ref: 0-0-0-15619-c status: success ;error: none engine: XCFSPAM4 Engine ; version: 5.2.1/2009.02.27.00.14.45/2005.02.11.04.44.13/0/0/2007.01.28.16.09.00/2007.02.13.01.23.26/0/0/2009.01.22.21.42.10/2009.03.03.01.01.00/2009.03.02.02.40.00/2009.03.03.00.52.47/0/0/2009.02.14.00.34.21/; level: 2 ref: 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: Tue, 03 Mar 2009 01:31:50 -0000 --Apple-Mail-36-38666620 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit News, Updates BOFS scheduled in SFO: - OAUTH: charter discussed on list - YAM - MMOX: Lots of list discussion, including quite a few highly divergent proposals - XMPP There is a Bar BOF in planning for topics suggested by HTML5 requirements but that are mostly protocol-level (i.e. HTTP) features. Document Status and Progress Active documents, my action: - drat-montemurro-gsma-imei-urn (Exp): Just saw a revision from authors, don't know if it addresses DISCUSS issues - draft-ietf-usefor-usepro (PS): Confirming this is ready for IESG Evaluation 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-ietf-calsify-rfc2445bis (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-melnikov-sieve-imapext-metadata (PS): approved, announcement sent - RFC 5435: Sieve Email Filtering: Extension for Notifications - RFC 5436: Sieve Notification Mechanism: mailto - RFC 5437: Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) WG Status ALTO, HTTPBIS, IDNABIS and SIEVE are meeting in SF / IETF74. Don't forget the APPAREA meeting on Monday morning, which has a full schedule. ALTO: Some slight discussion of requirements and problem statement, leading up to meeting CALSIFY: Working through open issues HTTPBIS: Ongoing discussions on issues. IDNABIS: Ongoing discussion on replacing several character mappings with new PVALID characters and the many deep tradeoffs of doing, or not doing, this change SIEVE: Published several documents and pushing more through USEFOR: Last doc may be ready for IESG Evaluation -- state uncertain --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. --Apple-Mail-36-38666620 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
News, Updates
 - OAUTH: charter discussed = on list
 - YAM
 - MMOX: Lots of list = discussion, including quite a few highly divergent proposals

There is a Bar BOF in planning = for topics suggested by HTML5 requirements but that are mostly = protocol-level (i.e. HTTP) features.

Document Status and = Progress
Active documents, my action:
 - drat-montemurro-gsma-imei-urn (Exp): = Just saw a revision from authors, don't know if it addresses DISCUSS = issues
 - draft-ietf-usefor-usepro (PS): = Confirming this is ready for IESG = Evaluation

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-ietf-calsify-rfc2445bis (PS): = Waiting for a revision
 - draft-snell-atompub-bidi (PS): Waiting = for a revision
 - draft-wilde-sms-uri (PS): Waiting for a = revision

 - draft-melnikov-sieve-imapext-metadata = (PS): approved, announcement sent
 - RFC 5435: Sieve = Email Filtering: Extension for Notifications



CALSIFY: Working through open issues
IDNABIS: Ongoing = discussion on replacing several character mappings with new PVALID = characters and the many deep tradeoffs of doing, or not doing, this = change
SIEVE: Published several documents and pushing = more through
USEFOR: Last doc may be ready for IESG = Evaluation -- state uncertain
= --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. --Apple-Mail-36-38666620-- From ajs@shinkuro.com Tue Mar 3 08:58:11 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 A53423A679C for ; Tue, 3 Mar 2009 08:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 RAfWwz21lIcd for ; Tue, 3 Mar 2009 08:58:10 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 79C813A6A34 for ; Tue, 3 Mar 2009 08:58:07 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 41EA42FEA3F8 for ; Tue, 3 Mar 2009 16:58:34 +0000 (UTC) Date: Tue, 3 Mar 2009 11:58:32 -0500 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: What do apps developers need from DNS? Message-ID: <20090303165832.GG3849@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Tue, 03 Mar 2009 16:58:11 -0000 Dear colleagues, I'm one of the co-chairs of the DNSEXT working group. I've lately been wondering, "What do applications want?" and I thought it would be better to ask some people than to speculate blindly. The DNS appears to be an important protocol for applications, but those of us who are charged with maintaining the protocol are sometimes confronted with what seems like two opposite pieces of evidence. On the one hand, we hear a lot about how difficult it is to get DNS data to applications and how impossible it is to introduce a new RRTYPE (not because of the assignment procedures -- which are now pretty streamlined -- but because of the deployment problems). On the other hand, we keep seeing the application of the DNS to new problems, sometimes with the use of a TXT record (and the attendant problems) and sometimes with the use of new RRTYPEs. We want to understand what the issues are that application writers have with the DNS -- what are the problems, why does everyone like TXT records so much, and how could DNS work better for you? Now is a particularly good time to produce a wish list, because it is possible that some APIs will be built in order to make DNSSEC data more easily available. If you have other things you want to reach down and grab at the same time, this would be a good time to ask. (That said, I'm not an OS manufacturer, so I can't promise that any particular desire will be met.) Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From simon@josefsson.org Tue Mar 3 09:06: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 864B13A697B for ; Tue, 3 Mar 2009 09:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 Od4elW3iDtMI for ; Tue, 3 Mar 2009 09:06:54 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id A771B3A679C for ; Tue, 3 Mar 2009 09:06:54 -0800 (PST) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1LeY5N-0008VZ-TK; Tue, 03 Mar 2009 18:07:18 +0100 From: Simon Josefsson To: Andrew Sullivan Subject: Re: What do apps developers need from DNS? References: <20090303165832.GG3849@shinkuro.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090303:ajs@shinkuro.com::64B+Uux8qCHwamun:CB25 X-Hashcash: 1:22:090303:apps-discuss@ietf.org::vAtu2Dsiply7Rmv7:Nac9 Date: Tue, 03 Mar 2009 18:07:16 +0100 In-Reply-To: <20090303165832.GG3849@shinkuro.com> (Andrew Sullivan's message of "Tue, 3 Mar 2009 11:58:32 -0500") Message-ID: <87vdqq358b.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 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: Tue, 03 Mar 2009 17:06:55 -0000 Andrew Sullivan writes: > Dear colleagues, > > I'm one of the co-chairs of the DNSEXT working group. I've lately > been wondering, "What do applications want?" and I thought it would be > better to ask some people than to speculate blindly. Having a standard API to retrieve arbitrary DNS data would be immensely useful. I recall multiple efforts in this area (the getrrinfo API, etc), but either nothing has been standardized or were never widely implemented. If that doesn't happen, at least an interface to retrieve DNS SRV records would be useful to standardize. getsrvinfo? Right now some of my applications use res_query() and contains a DNS parser to get at SRV records. This feels quite backwards. I had some hopes that interfaces could be built using standard URL interfaces (hence RFC 4501) that returned MIME tagged data (hence RFC 4027) although this hasn't happened. Maybe what is missing is a patch to implement this in, e.g., Curl... /Simon From dave@cridland.net Tue Mar 3 09:37: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 6812E3A6774 for ; Tue, 3 Mar 2009 09:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZKITNGN9mlY for ; Tue, 3 Mar 2009 09:37:17 -0800 (PST) Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by core3.amsl.com (Postfix) with ESMTP id 248473A67A4 for ; Tue, 3 Mar 2009 09:37:17 -0800 (PST) Received: from invsysm1 (shiny.isode.com [62.3.217.250]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Tue, 3 Mar 2009 17:38:35 +0000 Subject: Re: What do apps developers need from DNS? References: <20090303165832.GG3849@shinkuro.com> In-Reply-To: <20090303165832.GG3849@shinkuro.com> MIME-Version: 1.0 Message-Id: <14982.1236101855.826196@invsysm1> Date: Tue, 03 Mar 2009 17:37:35 +0000 From: Dave Cridland To: General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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, 03 Mar 2009 17:37:18 -0000 On Tue Mar 3 16:58:32 2009, Andrew Sullivan wrote: > I'm one of the co-chairs of the DNSEXT working group. I've lately > been wondering, "What do applications want?" and I thought it would > be > better to ask some people than to speculate blindly. As Simon says, DNS is low-level, and apps implmentors don't really like getting our hands that dirty. As things stand, not only do we have to kick bits about, but we have different ways of kicking bits about in each flavour OS. Standard APIs would go a long way to solve this - it'd be fine if these were high-level APIs easily shimmed on top of existing OS DNS magic. FWIW, I'd love to see more deployment of NAPTR, for instance, and such an API could support that along with SRV. Just the SRV would get immediate and happy usage, though, by XMPP and RadioDNS and ... Dave. > The DNS appears to be an important protocol for applications, but > those of us who are charged with maintaining the protocol are > sometimes confronted with what seems like two opposite pieces of > evidence. On the one hand, we hear a lot about how difficult it is > to > get DNS data to applications and how impossible it is to introduce a > new RRTYPE (not because of the assignment procedures -- which are > now > pretty streamlined -- but because of the deployment problems). On > the > other hand, we keep seeing the application of the DNS to new > problems, > sometimes with the use of a TXT record (and the attendant problems) > and sometimes with the use of new RRTYPEs. We want to understand > what > the issues are that application writers have with the DNS -- what > are > the problems, why does everyone like TXT records so much, and how > could DNS work better for you? Now is a particularly good time to > produce a wish list, because it is possible that some APIs will be > built in order to make DNSSEC data more easily available. If you > have > other things you want to reach down and grab at the same time, this > would be a good time to ask. (That said, I'm not an OS > manufacturer, > so I can't promise that any particular desire will be met.) > > Best regards, > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stig.venaas@uninett.no Wed Mar 4 00:48:36 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 BB36828C322 for ; Wed, 4 Mar 2009 00:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a71HJiYKyeF for ; Wed, 4 Mar 2009 00:48:36 -0800 (PST) Received: from regensburg.uninett.no (regensburg.uninett.no [IPv6:2001:700:0:526:158:38:180:100]) by core3.amsl.com (Postfix) with ESMTP id A6FBA28C307 for ; Wed, 4 Mar 2009 00:48:35 -0800 (PST) Received: from [172.16.192.12] (h-213.61.134.75.host.de.colt.net [213.61.134.75]) by regensburg.uninett.no (Postfix) with ESMTPSA id DAC8170396; Wed, 4 Mar 2009 09:49:01 +0100 (CET) Message-ID: <49AE4090.8030804@uninett.no> Date: Wed, 04 Mar 2009 09:49:20 +0100 From: Stig Venaas User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dave Cridland Subject: Re: What do apps developers need from DNS? References: <20090303165832.GG3849@shinkuro.com> <14982.1236101855.826196@invsysm1> In-Reply-To: <14982.1236101855.826196@invsysm1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General discussion of application-layer protocols 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, 04 Mar 2009 08:48:36 -0000 Dave Cridland wrote: [...] > FWIW, I'd love to see more deployment of NAPTR, for instance, and such > an API could support that along with SRV. I've been writing a couple of applications with code for looking up SRV and I've been wishing there were some standard API. I would definitely like to see that. NAPTR would be good also. Stig > Just the SRV would get immediate and happy usage, though, by XMPP and > RadioDNS and ... > > Dave. From bortzmeyer@nic.fr Wed Mar 4 01:05: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 8D5BD3A6883 for ; Wed, 4 Mar 2009 01:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, 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 Ie+UjTHGhYTw for ; Wed, 4 Mar 2009 01:05:04 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 4592428C1BB for ; Wed, 4 Mar 2009 01:05:04 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 39AB31C00FD; Wed, 4 Mar 2009 10:00:29 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 33F101C00FA; Wed, 4 Mar 2009 10:00:29 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 31679A1D982; Wed, 4 Mar 2009 10:00:29 +0100 (CET) Date: Wed, 4 Mar 2009 10:00:29 +0100 From: Stephane Bortzmeyer To: Simon Josefsson Subject: Re: What do apps developers need from DNS? Message-ID: <20090304090029.GB32539@nic.fr> References: <20090303165832.GG3849@shinkuro.com> <87vdqq358b.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vdqq358b.fsf@mocca.josefsson.org> 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: Wed, 04 Mar 2009 09:05:05 -0000 On Tue, Mar 03, 2009 at 06:07:16PM +0100, Simon Josefsson wrote a message of 29 lines which said: > Having a standard API to retrieve arbitrary DNS data would be immensely > useful. On the other hand, most applications should not deal with DNS directly (because it would tie them to a specific directory, preventing future evolutions to things like LDAP or local files). I'm glad that apps use getaddrinfo(), not res_query(). > If that doesn't happen, at least an interface to retrieve DNS SRV > records would be useful to standardize. getsrvinfo? May be starting from an existing library and deciding its API is the de facto standard? I suggest Ruli . > Right now some of my applications use res_query() and contains a DNS > parser to get at SRV records. This feels quite backwards. Why not using Ruli (or another existing library)? > I had some hopes that interfaces could be built using standard URL > interfaces (hence RFC 4501) that returned MIME tagged data (hence > RFC 4027) although this hasn't happened. Maybe what is missing is a > patch to implement this in, e.g., Curl... Very good idea, IMHO. From jaap@bartok.nlnetlabs.nl Wed Mar 4 01:15: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 3BC4228C378 for ; Wed, 4 Mar 2009 01:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 NqFFmiDp34Qe for ; Wed, 4 Mar 2009 01:15:14 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id 2E8E928C370 for ; Wed, 4 Mar 2009 01:15:13 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n249FbEf049356; Wed, 4 Mar 2009 10:15:37 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200903040915.n249FbEf049356@bartok.nlnetlabs.nl> To: Stephane Bortzmeyer Subject: Re: What do apps developers need from DNS? In-reply-to: Your message of Wed, 04 Mar 2009 10:00:29 +0100. <20090304090029.GB32539@nic.fr> Date: Wed, 04 Mar 2009 10:15:37 +0100 From: Jaap Akkerhuis X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (bartok.nlnetlabs.nl [127.0.0.1]); Wed, 04 Mar 2009 10:15:37 +0100 (CET) Cc: Simon Josefsson , 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, 04 Mar 2009 09:15:15 -0000 > Right now some of my applications use res_query() and contains a DNS > parser to get at SRV records. This feels quite backwards. Why not using Ruli (or another existing library)? Another shameless plug: ldns might do what you want, see http://www.nlnetlabs.nl/projects/ldns/ jaap From pawal@blipp.com Wed Mar 4 01:27: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 925D328C33B for ; Wed, 4 Mar 2009 01:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N26tjjbXzj7t for ; Wed, 4 Mar 2009 01:27:14 -0800 (PST) Received: from vic20.blipp.com (cl-682.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:2a9::2]) by core3.amsl.com (Postfix) with ESMTP id 2BC8A3A6A7D for ; Wed, 4 Mar 2009 01:27:14 -0800 (PST) Received: from randombot.office.nic.se (wifi2-103.nic.se [212.247.204.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id EF7E938106; Wed, 4 Mar 2009 10:27:38 +0100 (CET) Message-Id: <775E63DB-7ECA-475B-AEAC-B5A0FF2C3C74@blipp.com> From: Patrik Wallstrom To: apps-discuss@ietf.org In-Reply-To: <200903040915.n249FbEf049356@bartok.nlnetlabs.nl> Content-Type: multipart/signed; boundary=Apple-Mail-5-153620864; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: What do apps developers need from DNS? Date: Wed, 4 Mar 2009 10:27:35 +0100 References: <200903040915.n249FbEf049356@bartok.nlnetlabs.nl> X-Mailer: Apple Mail (2.930.3) Cc: Simon Josefsson , Jaap Akkerhuis 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, 04 Mar 2009 09:27:15 -0000 --Apple-Mail-5-153620864 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 4, 2009, at 10:15 AM, Jaap Akkerhuis wrote: > >> Right now some of my applications use res_query() and contains a DNS >> parser to get at SRV records. This feels quite backwards. > > Why not using Ruli (or another existing library)? > > Another shameless plug: ldns might do what you want, see > http://www.nlnetlabs.nl/projects/ldns/ Please also take a look on how DNS with DNSSEC is implemented in DKIM- milter. http://sourceforge.net/mailarchive/forum.php?thread_name=20081022115814.R21752%40protagonist.smi.sendmail.com&forum_name=dkim-milter-discuss ( http://shorl.com/fapruhuvisoby ) It is using libunbound also from NLNet Labs, as part of Unbound. -- patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956 --Apple-Mail-5-153620864 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwXZBzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wODEwMDUyMDI2MTZaFw0x MDEwMDUyMDI2MTZaMDsxGTAXBgNVBAMUEFBhdHJpayBXYWxsc3Ry9m0xHjAcBgkqhkiG9w0BCQEW D3Bhd2FsQGJsaXBwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOSneTPF/lsC 1YXWLI1a4KDIMY4b1cfR2a67cdIAKS9zcIpeIW5nlFk79vJDgf6RJgsTE/skLZc7Prv5FaMVm4FR uQEAr1x/w2SKh7eWgG6qnTS21bm2AKLD/S7sbDdfl6ysIaqczl26SUPl6RsRWJFW/j+hkPTmLxmB cMihw5CZMU7IKT/ViV+eOC63X0ecIHgDFjOHb/EsD3dh5D5HDXKF9z05Pr+uuCLRA8H/UWHj2BRh suNvMQKRyYVdvCENnqO/0xG+iuOd/puihYVxOaP358AZLBjSOwsqPk7zmSGPVh0EPwqg3L7kuvJK uq9KF2PSjiimosryC2VzDj8JGa0CAwEAAaOB+zCB+DAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIB DQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0 dHA6Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGG Fmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwGgYDVR0RBBMwEYEPcGF3YWxAYmxpcHAuY29tMA0GCSqG SIb3DQEBBQUAA4ICAQCeGr6XkqSIqi0hsYTMP66rYVTUe17p4tIWkW19SzMGnQ1ON/3d1OK9p1db vAFdQgaEYeVHaFRySjkQJPhTwLZQcJxZ7qjysrd9051Cbib6+e05wnvRVB69YtBFZeMg9ec9xGZh BuIcHO0cBd9vrPCWDNWtTEGkBRmwCtmLejorrNuaMvSlWQBid4W/MuuKPiU9Y8qHUJBi07UIlZof mo5041nPtF0uDMNWNVaBwcgPhkJAGK0MBkIy1elUJUcRDkWSfVmFPoxlcvQsyNzK+43yfNvW7tus n3Olfg7Yvx6MjAPDiOcVtCA/qSTpHmVEiXzF1IEO9+Py24VhMDbrTnJUgWCldRSJoKgiGkiLMqOW P8QAbeNKBIxEVD+vXt8Ytakht+hGFmM2o0pHVyIScHK+UBBFlw9WMddvr6oArYK0rwaNqIShgBdg OOzQBuzm7pxK129Ni0Xe0VKU9wiYZV9sFxnOTV9PBUthVJzhaxRddWpRgy+tOUk1e1eVFeKkL8lQ w6DzH/XbfQUGAlAJACA6F6QcJfVk9LRGaszx9P2lMMMp8Zt/FtS0/3bjiGTyy4a0JxMe3KGndQyB N1SGvV644sz138V5ITRrz2PuQ2qdz4s6Ry7o6+5ylS6rzEUbx26iT6gvpwzX5GIKJ6SWtYve5cME bmShvv3sLCLoMk7QTDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMF2QcwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzA0MDkyNzM2WjAj BgkqhkiG9w0BCQQxFgQUsvMldXzlcH73iiSKidFp4sUJGNQwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBdkHMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBdkHMA0GCSqGSIb3 DQEBAQUABIIBALYtaRSsq2j8paF/0VvEqZaK43/rrYMg6DvIusii7FbVn8ZOPHhuf6nIJjF6rzbr yX+URckMjnChD0vd8uQLcpQZ7WlEBj2zxJP1lc2CLvskUBLzKzxcKPsV+tg4mpW/7QHOV3XqRVjP pk+N1Z6w5yr4HmYOtErhKMyIPA3WOL4GuRPzDuvgktUbWIqofya/9zYSfzDuXO2vlFOHZMTwHVwQ 3SM9ilvjowQEvEzo2jkDk3TkOUEsZQlFmUmQOAJ2MQfm8dok6b9ofVJ9MGj2jW+wXIxHsRnkvhaD mZnsTX7229p1C4VJjHnwy70Hte5V8+IR8ws/LPFzsjnzCQkSZA4AAAAAAAA= --Apple-Mail-5-153620864-- From moore@network-heretics.com Wed Mar 4 11: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 DF27328C44B for ; Wed, 4 Mar 2009 11:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdEibWJ74aZc for ; Wed, 4 Mar 2009 11:01:28 -0800 (PST) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 255BF28C1C8 for ; Wed, 4 Mar 2009 11:01:28 -0800 (PST) Received: from lust.indecency.org (adsl-068-153-245-140.sip.ard.bellsouth.net [68.153.245.140]) by m1.imap-partners.net (MOS 3.10.3-GA) with ESMTP id BKA28841 (AUTH admin@network-heretics.com) for apps-discuss@ietf.org; Wed, 4 Mar 2009 11:01:55 -0800 (PST) Message-ID: <49AED022.7080007@network-heretics.com> Date: Wed, 04 Mar 2009 14:01:54 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Andrew Sullivan Subject: Re: What do apps developers need from DNS? References: <20090303165832.GG3849@shinkuro.com> In-Reply-To: <20090303165832.GG3849@shinkuro.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, 04 Mar 2009 19:01:29 -0000 I'll add mine to the list of people wanting a standard API that isn't limited to address lookups. IMHO, the API needs to be able to handle asynchronous queries rather than simply waiting for a response. The API needs to be DNS ONLY. No /etc/hosts, NIS, netinfo, LLMNR, or Microsoft lookups - at least, not unless explcitly indicated by the app. on a more ambitious level... 1. Speaking of LLMNR, there is a real need to resolve the tussle between local lookups (say on an ad hoc network or one that is disconnected from its DNS server) and DNS lookups. (and no, putting LLMNR on a separate port did not solve the problem). IMHO it should be possible for each host to be the master of its own domain, so to speak, so that it maintains the authoritative copy of the RRs for its domain, and any other servers that are advertised via NS records are secondaries. Then there should be no difference between LLMNR-style lookups and DNS lookups that follow an NS chain from the root - other than needing DNSSEC authentication before trusting the former. (note that the host doesn't actually need to provide its own DNS server for ordinary queries, though it might want to do so for LLMNR). I think this actually is possible with existing protocols but IMHO this ought to become the normal mode of operation. Especially with so many mobile hosts these days. Right now we have the situation where things like consumer grade routers want to impose their own DNS proxies/caches so that they can implement local names - and in doing so they inevitably break things because e.g. they don't do caching correctly. This would also help resolve the problem that DNS is often out of sync with reality because different people maintain the DNS servers than maintain the hosts. E.g. if applications could create their own SRV/NAPTR RRs then those RRs would be much more likely to accurately reflect reality. Right now SRV records are just another way for the app to break. 2. DNS is extraordinarly easy to misconfigure. I'm not sure that the protocols need changing to fix this problem, so much as having better administrative interfaces, and administrative interfaces that are well-defined across implementations. For instance, separately specifying the NS record, kind of DNS updating, server names/addresses for the peers, and authentication credentials is a pain in the wazoo; to say nothing of the steps required to copy that information to the peer, tickle the DNS servers to get them to recognize the configuration change, and test the new configuration to make sure it works. It's not rocket science, but even for one who understands it, it's easy to forget a step or to do something wrong. People who don't do this every day are especially prone to making such errors. Keith From mnot@mnot.net Thu Mar 5 19:13: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 EABA13A67B1 for ; Thu, 5 Mar 2009 19:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XRCh3TaadYWH for ; Thu, 5 Mar 2009 19:13:53 -0800 (PST) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id F037C3A657C for ; Thu, 5 Mar 2009 19:13:52 -0800 (PST) Received: from [192.168.1.6] (unknown [118.208.244.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5EF5C23E3AB; Thu, 5 Mar 2009 22:14:20 -0500 (EST) Message-Id: From: Mark Nottingham To: HTTP Working Group 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: HTTPbis status Date: Fri, 6 Mar 2009 14:14:10 +1100 X-Mailer: Apple Mail (2.930.3) 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, 06 Mar 2009 03:13:54 -0000 HTTPbis will be meeting at IETF74; draft agenda available at: http://www.ietf.org/proceedings/09mar/agenda/httpbis.txt Note that we've provisionally left some time at the end of the meeting to discuss HTTP-related drafts that are not currently within the scope of HTTPbis (time permitting). If you have such a draft and would like to give a *brief* presentation on it, please contact me. * HTTP Revision We've had a quiet period in the last few months, but the editors have been working in the background; they expect to have the -06 generation of the HTTPbis drafts published before the meeting; they will incorporate more editorial changes (including the ABNF conversion) as well as several issue resolution proposals for consideration by the WG. * Security Properties The security properties document is currently expired. Although it is a chartered deliverable, there doesn't currently seem to be a will in the WG to complete it, and its editors believe that it is not currently complete. The future of this document is one of the things that we'll discuss in San Francisco. Cheers, -- Mark Nottingham http://www.mnot.net/ From leifj@it.su.se Sun Mar 8 08:23: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 239C23A67FB for ; Sun, 8 Mar 2009 08:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=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 QZewna6hMNIq for ; Sun, 8 Mar 2009 08:23:18 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 2337F3A67D1 for ; Sun, 8 Mar 2009 08:23:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 5A4A13C4F3; Sun, 8 Mar 2009 16:23:49 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27066-01-70; Sun, 8 Mar 2009 16:23:48 +0100 (CET) Received: from k2.mnt.se (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id C06403C4A3; Sun, 8 Mar 2009 16:23:48 +0100 (CET) From: Leif Johansson To: apps-discuss@ietf.org Subject: Re: What do apps developers need from DNS? Date: Sun, 8 Mar 2009 16:23:38 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <20090303165832.GG3849@shinkuro.com> In-Reply-To: <20090303165832.GG3849@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1838954.409GFR0U89"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903081623.45644.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se 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: Sun, 08 Mar 2009 15:23:19 -0000 --nextPart1838954.409GFR0U89 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 03 March 2009 17:58:32 Andrew Sullivan wrote: > Dear colleagues, > > I'm one of the co-chairs of the DNSEXT working group. I've lately > been wondering, "What do applications want?" and I thought it would be > better to ask some people than to speculate blindly. It is also important to ask what can application developers expect from=20 deployers wrt DNS. I've seen several schemes fail even though they used DNS "the right way" (TM) because getting anything past the local DNS weenie proved impossible except where the local DNS weenie=20 had interest and clue. Why is this? Possibly DNS isn't regarded as providing _direct_ business=20 value so it is difficult to motivate changes to DNS infrastructure to=20 support applications (beyond getaddrinfo). Possibly the risk of making changes to DNS (deploying an application which changes the usage pattern of the enterprise DNS *is* a risk) given its central role is viewed= =20 as always too high a risk. If DNS is going to support applications beyond getaddrinfo then APIs are certainly important but equally important is to get major DNS=20 implementors to subscribe to the notion that DNS has a role to play beyond getaddrinfo. They will then offer products that allow even the most clueless of DNS weenie to stick NAPTR records for ENUM or=20 key records for DKIM in their zone without (undue) hesitation. Cheers Leif --nextPart1838954.409GFR0U89 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmz4vsACgkQ8Jx8FtbMZnewRQCeMGXYjail9vVsGakyJlMM73AV e+UAoIm3tMKTTCiN60VgEiAai4gDUxAi =ef3g -----END PGP SIGNATURE----- --nextPart1838954.409GFR0U89-- From balfanz@google.com Thu Mar 5 09:01: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 796FB28C38B for ; Thu, 5 Mar 2009 09:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.073 X-Spam-Level: X-Spam-Status: No, score=-101.073 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=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 JQGYvj9j8CjL for ; Thu, 5 Mar 2009 09:01:05 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 65A5D28C0D0 for ; Thu, 5 Mar 2009 09:01:05 -0800 (PST) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n25H1XkD019883 for ; Thu, 5 Mar 2009 09:01:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1236272494; bh=zc8c2czxTTPX789dkRIVphXKxnY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=L 8h0B+ITSCrrwipgv1aNc4CSVelWOzkDTtqo6GTei4sFofsfFDskLWHoexeczyRApcNf trpESUwQKjN3BoddDA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=gp9KQFzyQsYwUsFzrevE0wufFC2ckFADWemOf1wZXRW6aVDqxC9waQ69Jbkt0VPX6 Kim/67N6bfi6jDOhJhkvQ== Received: from wf-out-1314.google.com (wfa25.prod.google.com [10.142.1.25]) by zps19.corp.google.com with ESMTP id n25H1Vdt026864 for ; Thu, 5 Mar 2009 09:01:32 -0800 Received: by wf-out-1314.google.com with SMTP id 25so18474wfa.27 for ; Thu, 05 Mar 2009 09:01:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.110.10 with SMTP id i10mr602470wfc.300.1236272491771; Thu, 05 Mar 2009 09:01:31 -0800 (PST) In-Reply-To: References: <20090213071502.24CF93A684E@core3.amsl.com> Date: Thu, 5 Mar 2009 09:01:31 -0800 Message-ID: <60c552b80903050901q2973e1a3g8ee43b2980969e88@mail.gmail.com> Subject: Re: FW: I-D Action:draft-hammer-discovery-02.txt From: Dirk Balfanz To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636e90f35b7b9a20464621ee6 X-System-Of-Record: true X-Mailman-Approved-At: Mon, 09 Mar 2009 10:12:06 -0700 Cc: "apps-discuss@ietf.org" , "www-talk@w3.org" , "www-tag@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: Thu, 05 Mar 2009 17:01:06 -0000 --001636e90f35b7b9a20464621ee6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Minor nit: the Link-Pattern examples throughout the spec don't have semicolons before link parameters, while the syntax definition in Section 6 requires them. To be consistent with the syntax of Link:s I would think that the syntax definition is right, and the examples are wrong. Dirk. On Thu, Feb 12, 2009 at 11:18 PM, Eran Hammer-Lahav wrote: > Please discuss on the www-talk@w3.org list. > > For those who have read previous revisions (thanks!), please note that > except for Appendix B, the rest of the spec was significantly changed and a > fresh read is recommended. > > Thanks, > > EHL > > > ------ Forwarded Message > > *From: * > *Reply-To: * > *Date: *Fri, 13 Feb 2009 00:15:02 -0700 > *To: * > *Subject: *I-D Action:draft-hammer-discovery-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Link-based Resource Descriptor Discovery > Author(s) : E. Hammer-Lahav > Filename : draft-hammer-discovery-02.txt > Pages : 25 > Date : 2009-02-12 > > This memo describes a process for obtaining information about a > resource identified by a URI. The 'information about a resource', a > resource descriptor, provides machine-readable information that aims > to increase interoperability and enhance the interaction with the > resource. This memo only defines the process for locating and > obtaining the descriptor, but leaves the descriptor format and its > interpretation out of scope. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hammer-discovery-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------ End of Forwarded Message > --001636e90f35b7b9a20464621ee6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Minor nit: the Link-Pattern examples throughout the spec don't have sem= icolons before link parameters, while the syntax definition in Section 6 re= quires them. To be consistent with the syntax of Link:s I would think that = the syntax definition is right, and the examples are wrong.

Dirk.

On Thu, Feb 12, 2009 at 11:18 P= M, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Please discuss on the www-talk@w3.org list.

For those who have read previous revisions (thanks!), please note that exce= pt for Appendix B, the rest of the spec was significantly changed and a fre= sh read is recommended.

Thanks,

EHL


------ Forwarded Message
From: <Internet-Drafts@ietf.org>
Reply-To: <internet-drafts@ietf.org>
Date: Fri, 13 Feb 2009 00:15:02 -0700
To: <i= -d-announce@ietf.org>
Subject: I-D Action:draft-hammer-discovery-02.txt


A New Internet-Draft is available from th= e on-line Internet-Drafts directories.

=A0=A0=A0=A0=A0=A0=A0=A0Title =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: Link-based Re= source Descriptor Discovery
=A0=A0=A0=A0=A0=A0=A0=A0Author(s) =A0=A0=A0=A0=A0=A0: E. Hammer-Lahav
=A0=A0=A0=A0=A0=A0=A0=A0Filename =A0=A0=A0=A0=A0=A0=A0: draft-hammer-discov= ery-02.txt
=A0=A0=A0=A0=A0=A0=A0=A0Pages =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 25
=A0=A0=A0=A0=A0=A0=A0=A0Date =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2009-02-12<= br>
This memo describes a process for obtaining information about a
resource identified by a URI. =A0The 'information about a resource'= , a
resource descriptor, provides machine-readable information that aims
to increase interoperability and enhance the interaction with the
resource. =A0This memo only defines the process for locating and
obtaining the descriptor, but leaves the descriptor format and its
interpretation out of scope.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hammer-disco= very-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------ End of Forwarded Message

--001636e90f35b7b9a20464621ee6-- From Lisa.Dusseault@messagingarchitects.com Mon Mar 9 16:06: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 998B03A67F2 for ; Mon, 9 Mar 2009 16:06:39 -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 TWbgssOTkdOL for ; Mon, 9 Mar 2009 16:06:38 -0700 (PDT) Received: from mplus1.messagingarchitects.com (bastille.messagingarchitects.com [216.94.112.120]) by core3.amsl.com (Postfix) with ESMTP id 4E9D03A6884 for ; Mon, 9 Mar 2009 16:06:38 -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; Mon, 09 Mar 2009 19:07:38 -0400 X-MailFrom: Lisa.Dusseault@messagingarchitects.com Message-Id: <70831E36-6F17-4420-8651-9AEE42BC1DC2@messagingarchitects.com> From: Lisa Dusseault To: General discussion of application-layer protocols Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: APPAREA agenda Date: Mon, 9 Mar 2009 16:07:09 -0700 X-Mailer: Apple Mail (2.930.3) X-Mplus-Virus-Scanned: mplusversion: 2008.4.release ; timestamp: Mon, 09 Mar 2009 19:07:38 -0400 engine: XCFAntiVirus1 Engine; version: 3922 (20090309)/1082 (20090213)/1091 (20090309)/1.009 (20070910) result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus2 Engine; version: 5.1.00/5548 result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus3 Engine; version: 5.07.0001 result: 0 ; ref: str=0001.0A01020A.49B5A11F.0036,ss=1,fgs=0; status: success; error: none X-Mplus-Spam-Scanned: mplusversion: 2008.4.release ; timestamp: Mon, 09 Mar 2009 19:07:39 -0400 engine: XCFSPAM1 Engine ; version: Not Available ; level: 0 ref: 0-0-0-3049-c status: success ;error: none engine: XCFSPAM4 Engine ; version: 5.2.1/2009.03.09.21.36.51/2005.02.11.04.44.13/0/0/2007.01.28.16.09.00/2007.02.13.01.23.26/0/0/2009.01.22.21.42.10/2009.03.09.22.01.46/2009.03.09.01.40.00/2009.03.09.22.12.27/0/0/2009.02.14.00.34.21/; 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: Mon, 09 Mar 2009 23:06:39 -0000 I'm about to post this APPAREA agenda. Lots of interesting topics, =20 hope to see you all in 2 weeks. APPAREA AGENDA 9:00 Scribe & agenda bash 9:05 Brief IPR and Copyright update -- Lisa D 9:20 Resource discovery -- Eran Hammer-Lahav draft-hammer-discovery-02 9:30 Server/service Discovery -- Stuart Cheshire draft-cheshire-dnsext-dns-sd-05 9:40 Timezones definitions -- Cyrus Daboo 9:50 SCRAM SASL implications for you -- Alexey Melnikov 10:00 Bidirectional HTTP: BOSH, Bayeux, COMET, WebSockets or other? Peter Saint-Andr=E9, Salvatore Loreto, Greg Wilkins = =09 http://xmpp.org/extensions/xep-0124.html http://svn.cometd.org/trunk/bayeux/bayeux.html draft-hixie-thewebsocketprotocol-02.txt 10:30 Intro to MMOX -- David Levine 11:00 YAM preview -- Tony Hansen 11:15 XMPP preview -- Peter Saint-Andr=E9 11:25 Quick status from WG chairs if we still have time. Lisa= --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. From julian.reschke@gmx.de Tue Mar 10 03:06:38 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 08EFB3A6A03 for ; Tue, 10 Mar 2009 03:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.269 X-Spam-Level: X-Spam-Status: No, score=-5.269 tagged_above=-999 required=5 tests=[AWL=-2.670, 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 zyKhUqL05Ujl for ; Tue, 10 Mar 2009 03:06:37 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B485A3A684C for ; Tue, 10 Mar 2009 03:06:36 -0700 (PDT) Received: (qmail invoked by alias); 10 Mar 2009 10:07:09 -0000 Received: from p508FD1B4.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.209.180] by mail.gmx.net (mp070) with SMTP; 10 Mar 2009 11:07:09 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/fN+Vl0PvfSxcmxy73oZv8lvqXq2nyXRDW1wDXtW gRyzMjAnRrhse0 Message-ID: <49B63BC6.4000403@gmx.de> Date: Tue, 10 Mar 2009 11:07:02 +0100 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: HTTP Working Group Subject: -06 drafts, was: HTTPbis status References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 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: Tue, 10 Mar 2009 10:06:38 -0000 Mark Nottingham wrote: > ... > * HTTP Revision > > We've had a quiet period in the last few months, but the editors have > been working in the background; they expect to have the -06 generation > of the HTTPbis drafts published before the meeting; they will > incorporate more editorial changes (including the ABNF conversion) as > well as several issue resolution proposals for consideration by the WG. > ... These drafts have been submitted yesterday. They contain quite a number of substantive changes, plus major rewrites in Parts 1 (URIs, Connections, and Message Parsing) and 6 (Caching). All non-editorial changes should be mentioned in the "Changes Since ..." appendices; diffs are available from tools.ietf.org (linked from the HTMLized versions) and from . The top changes are: - Many parts of Part 6 (Caching) have been rewritten from scratch, resulting in a more concise spec. There are several open issues and TODOs related to this change, so please carefully review this part in general, and also pay attention to the inlined comments. - All the issues around the BNF format and implied LWS have been resolved, see for details. - In Part 1, the HTTP URL definition has been updated to be based on RFC 3986, quite some text in the introductory chapters has been updated, and lots of URI related history (better summarized in RFC 3986) has been removed. We think the issue below have been resolved with these drafts, and are planning to close them soon: - #30: "Header LWS" () - #63: "RFC2047 encoded words" () - #74: "Character Encodings in TEXT" () - #77: "Line folding" () - #83: "OPTIONS * and proxies" () - #85: "Custom Ranges" () - #111: "Use of TEXT" () Best regards, Julian From lisa.dusseault@gmail.com Wed Mar 11 12:55: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 186763A6809; Wed, 11 Mar 2009 12:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 5EWf7nAaLfm2; Wed, 11 Mar 2009 12:55:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id B0FA33A684C; Wed, 11 Mar 2009 12:55:16 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so141872rvb.49 for ; Wed, 11 Mar 2009 12:55:53 -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=KoR4VImeDygjK+x2f0n6og1u6QMo9K3ZdP57AR1QhH0=; b=gOmsMCZATvmGBbl7ul2PneMc502bW0JUhmgG0UPvld3YIjiRFIAgawckuFzfOw+UN0 LZhyJ93HwWo+JOKIgWwB/HMMSYWmA0FHCrHxPiEO43YYQHbTQSTuyjDqWAp35tIoNIyU rNF6xuaZ7cbqt+RoriGaeeaC+S+u20uaitR14= 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=JkDO8eOFHdMbaZpSSy39fg4f+69g+3CHC3jM/T9EASvZS64Uze9f1mLSnK0a/cfMHD 44HS4SpCk8N7znF+EJsMt/9jkA2PcH3arucFLLvsi5tAN4kzauIxRCJ29Uur9TO1FR6Z NEZyJeYQKvQHQujzq+TXxkXhkGDq4UFhJnqqs= MIME-Version: 1.0 Received: by 10.141.26.19 with SMTP id d19mr4547909rvj.184.1236801353365; Wed, 11 Mar 2009 12:55:53 -0700 (PDT) Date: Wed, 11 Mar 2009 12:55:53 -0700 Message-ID: Subject: Re: [mmox] reverse http I-D From: Lisa Dusseault To: lenglish5@cox.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmox@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: Wed, 11 Mar 2009 19:55:22 -0000 There's a lot more moving parts to RHTTP than just virtual worlds. XMPP has BOSH, and AJAX and AJAJ everywhere often use Bayeux or COMET. Meanwhile, the HTML5 Working Group submitted their Web Sockets design to the IETF. I bear definite responsibility for the combined timing, although for none of the specific protocols, because it appeared to me the time was more than ripe to unify this space somewhat. I've asked people to present at the APPAREA meeting on monday morning. If people would also not call it an RFC yet that would make me happy, for whatever that's worth :) Lisa On Sun, Mar 8, 2009 at 12:25 AM, Lawson English wrote: > Hey grats to Zero Linden (Mark Lentczner) and Donovan Preston =A0for gett= ing > this out. Will make virtual worlds communication much more robust in the > long run, I think: > > > http://www.ietf.org/internet-drafts/draft-lentczner-rhttp-00.txt > > > Lawson > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From Hannes.Tschofenig@gmx.net Wed Mar 18 01:56: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 0E4093A67FC for ; Wed, 18 Mar 2009 01:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[AWL=1.270, BAYES_00=-2.599, GB_I_LETTER=-2, 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 XrDBCER2grHJ for ; Wed, 18 Mar 2009 01:56:16 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 075983A6822 for ; Wed, 18 Mar 2009 01:56:15 -0700 (PDT) Received: (qmail invoked by alias); 18 Mar 2009 08:56:58 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp022) with SMTP; 18 Mar 2009 09:56:58 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/dnXQIgeLd2coMFWPtqK3oL8fdb87Y3TTvoGl+ZC YwhcuXR1hJNv54 From: "Hannes Tschofenig" To: Subject: OAuth Date: Wed, 18 Mar 2009 10:58:09 +0200 Message-ID: <000801c9a7a7$a9979370$9c11a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C9A7B8.6D206370" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acmnp6kZM2EZVgmWSGeyejbp1LQHgg== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5,0.51 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, 18 Mar 2009 08:56:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C9A7B8.6D206370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I would like to point you to the Open Web authentication BOF on Monday, 1300-1500, in Continental 4. Your review comments regarding application layer design aspects are highly appreciated. Here is the link to the latest version of the OAuth draft: http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt Ciao Hannes >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf Of ext Eran Hammer-Lahav >Sent: 10 March, 2009 07:34 >To: oauth@ietf.org >Subject: Re: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt > >Forgot to mention the blog post is: > >http://www.hueniverse.com/hueniverse/2009/03/oauth-core-10-reborn.html > >EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf >> Of Eran Hammer-Lahav >> Sent: Monday, March 09, 2009 10:20 PM >> To: oauth@ietf.org >> Subject: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt >> >> I spent the last 3 days writing the entire spec from scratch (except >> for the security consideration section which was just >adjusted to the >> new terminology). The new revision is based on feedback I collected >> over the past year for the original specification. The main >> differences >> are: >> >> * Terminology. Gone are the confusing terms (consumer, >request token, >> consumer key, etc.). Instead I am using terms from the HTTP spec, >> slightly adjusted. >> >> * Structure. The previous revision mixed authentication with >> authorization and had very little reason to the way >normative text was >> placed across sections. The new structure splits the spec in >two. The >> first part talks about how to make authenticated requests using two >> sets of credentials. The second part offers a method (one of >many) for >> getting a token via redirection. >> >> * Encoding. The biggest issue with the previous revision was >confusion >> over parameter encoding and the signature base string. I cleaned up >> that section, added new examples, and removed a couple >instruction to >> encode the signature (bugs). If followed to the letter, the >spec would >> break all existing implementations... The good thing is it is >> confusing enough that most people understood it the wrong way (which >> is actually the right way). Take a look at the old section >about PLAINTEXT: >> >> --- >> oauth_signature is set to the concatenated encoded values of the >> Consumer Secret and Token Secret, separated by a '&' >character (ASCII >> code 38), even if either secret is empty. The result MUST be encoded >> again. >> --- >> >> 'The result MUST be encoded again' is just plain wrong. It >is encoded >> again but according to the parameter transmission method, not the >> special way OAuth does it, and the spec as written would actually >> double encode it. >> >> * Normative requirements. The spec previously contained many >MUSTs and >> SHOULDs about stuff that could not be verified like >documentation and >> obtaining client credentials. I took out all the ones that didn't >> actually made any practical difference. >> >> I'm sure there is more, since this is practically a brand new spec >> (same exact protocol). Please read and provide feedback. >> >> EHL >> >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org >> Sent: Monday, March 09, 2009 4:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-hammer-oauth-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : The OAuth Core Protocol >> Author(s) : E. Hammer-Lahav, B. Cook >> Filename : draft-hammer-oauth-01.txt >> Pages : 33 >> Date : 2009-03-09 >> >> This document specifies the OAuth core protocol. OAuth provides a >> method for clients to access server resources on behalf of another >> party (such a different client or an end user). It also provides a >> redirection-based user agent process for end users to >authorize access >> to clients by substituting their credentials (typically, a username >> and password pair) with a different set of delegation- specific >> credentials. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >_______________________________________________ >oauth mailing list >oauth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > ------=_NextPart_000_0009_01C9A7B8.6D206370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OAuth

Hi all,

I would like to point you to the = Open Web authentication BOF on Monday, 1300-1500, in Continental 4. =

Your review comments regarding = application layer design aspects are highly appreciated. Here is the = link to the latest version of the OAuth draft:

http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt=

Ciao
Hannes

>-----Original = Message-----
>From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org]
>On Behalf Of ext Eran = Hammer-Lahav
>Sent: 10 March, 2009 = 07:34
>To: oauth@ietf.org
>Subject: Re: [oauth] FW: I-D = Action:draft-hammer-oauth-01.txt
>
>Forgot to mention the blog = post is:
>
>http://www.hueniverse.com/hueniverse/2009/03/oauth-core-10-reborn.ht= ml
>
>EHL
>
>> -----Original = Message-----
>> From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
>On Behalf
>> Of Eran = Hammer-Lahav
>> Sent: Monday, March 09, = 2009 10:20 PM
>> To: = oauth@ietf.org
>> Subject: [oauth] FW: = I-D Action:draft-hammer-oauth-01.txt
>>
>> I spent the last 3 days = writing the entire spec from scratch (except
>> for the security = consideration section which was just
>adjusted to the
>> new terminology). The = new revision is based on feedback I collected
>> over the past year for = the original specification. The main
>> differences
>> are:
>>
>> * Terminology. Gone are = the confusing terms (consumer,
>request token,
>> consumer key, etc.). = Instead I am using terms from the HTTP spec,
>> slightly = adjusted.
>>
>> * Structure. The = previous revision mixed authentication with
>> authorization and had = very little reason to the way
>normative text was
>> placed across sections. = The new structure splits the spec in
>two. The
>> first part talks about = how to make authenticated requests using two
>> sets of credentials. = The second part offers a method (one of
>many) for
>> getting a token via = redirection.
>>
>> * Encoding. The biggest = issue with the previous revision was
>confusion
>> over parameter encoding = and the signature base string. I cleaned up
>> that section, added new = examples, and removed a couple
>instruction to
>> encode the signature = (bugs). If followed to the letter, the
>spec would
>> break all existing = implementations... The good thing is it is
>> confusing enough that = most people understood it the wrong way (which
>> is actually the right = way). Take a look at the old section
>about PLAINTEXT:
>>
>> ---
>> oauth_signature is set = to the concatenated encoded values of the
>> Consumer Secret and = Token Secret, separated by a '&'
>character (ASCII
>> code 38), even if = either secret is empty. The result MUST be encoded
>> again.
>> ---
>>
>> 'The result MUST be = encoded again' is just plain wrong. It
>is encoded
>> again but according to = the parameter transmission method, not the
>> special way OAuth does = it, and the spec as written would actually
>> double encode = it.
>>
>> * Normative = requirements. The spec previously contained many
>MUSTs and
>> SHOULDs about stuff = that could not be verified like
>documentation and
>> obtaining client = credentials. I took out all the ones that didn't
>> actually made any = practical difference.
>>
>> I'm sure there is more, = since this is practically a brand new spec
>> (same exact protocol). = Please read and provide feedback.
>>
>> EHL
>>
>>
>>
>> -----Original = Message-----
>> From: = i-d-announce-bounces@ietf.org [mailto:i-d-announce-
>> bounces@ietf.org] On = Behalf Of Internet-Drafts@ietf.org
>> Sent: Monday, March 09, = 2009 4:45 PM
>> To: = i-d-announce@ietf.org
>> Subject: I-D = Action:draft-hammer-oauth-01.txt
>>
>> A New Internet-Draft is = available from the on-line Internet-Drafts
>> directories.
>>
>> =      = Title           : The = OAuth Core Protocol
>> =      Author(s)       : = E. Hammer-Lahav, B. Cook
>> =      = Filename        : = draft-hammer-oauth-01.txt
>> =      = Pages           : = 33
>> =      = Date            : = 2009-03-09
>>
>> This document specifies = the OAuth core protocol.  OAuth provides a
>> method for clients to = access server resources on behalf of another
>> party (such a different = client or an end user).  It also provides a
>> redirection-based user = agent process for end users to
>authorize access
>> to clients by = substituting their credentials (typically, a username
>> and password pair) with = a different set of delegation- specific
>> credentials.
>>
>> A URL for this = Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt=
>>
>> Internet-Drafts are = also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which = will enable a MIME compliant mail reader
>> implementation to = automatically retrieve the ASCII version of the
>> Internet-Draft.
>_______________________________________________
>oauth mailing list
>oauth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>



------=_NextPart_000_0009_01C9A7B8.6D206370-- From dave@cridland.net Wed Mar 18 02:25: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 A8A553A684D for ; Wed, 18 Mar 2009 02:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 IrcgFQ5HfrJW for ; Wed, 18 Mar 2009 02:25:02 -0700 (PDT) Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by core3.amsl.com (Postfix) with ESMTP id BA1BB3A67A3 for ; Wed, 18 Mar 2009 02:25:01 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Wed, 18 Mar 2009 09:26:37 +0000 Subject: Re: OAuth References: <000801c9a7a7$a9979370$9c11a20a@nsnintra.net> In-Reply-To: <000801c9a7a7$a9979370$9c11a20a@nsnintra.net> MIME-Version: 1.0 Message-Id: <30372.1237368337.053659@peirce.dave.cridland.net> Date: Wed, 18 Mar 2009 09:25:37 +0000 From: Dave Cridland To: General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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, 18 Mar 2009 09:25:06 -0000 On Wed Mar 18 08:58:09 2009, Hannes Tschofenig wrote: > Hi all, > > I would like to point you to the Open Web authentication BOF on > Monday, > 1300-1500, in Continental 4. > > Your review comments regarding application layer design aspects are > highly > appreciated. Here is the link to the latest version of the OAuth > draft: > http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt > > I would note that there has been some effort to use OAuth in the XMPP community, see XEP-0235 - http://xmpp.org/extensions/xep-0235.html - which uses XMPP instead of HTTP. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From mnot@mnot.net Mon Mar 23 09:31: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 A5E7228C1D0 for ; Mon, 23 Mar 2009 09:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.817 X-Spam-Level: X-Spam-Status: No, score=-4.817 tagged_above=-999 required=5 tests=[AWL=-2.218, 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 WUh-nWYr5KMA for ; Mon, 23 Mar 2009 09:31:49 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 4A98D28C1D3 for ; Mon, 23 Mar 2009 09:31:48 -0700 (PDT) Received: from dhcp-56db.meeting.ietf.org (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 1C7B3D0BA8; Mon, 23 Mar 2009 12:32:36 -0400 (EDT) Message-Id: From: Mark Nottingham To: Dan Connolly In-Reply-To: <49C7B50C.7040709@w3.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: Re: "Web Addresses in HTML 5", URIs, URLs, IRIs Date: Mon, 23 Mar 2009 09:32:32 -0700 References: <49C7B50C.7040709@w3.org> X-Mailer: Apple Mail (2.930.3) Cc: uri@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: Mon, 23 Mar 2009 16:31:50 -0000 Hi Dan, What's the intended venue and status for this work (if known)? Cheers, On 23/03/2009, at 9:13 AM, Dan Connolly wrote: > This was, until recently, part of the HTML 5 spec. It's > been suggested that it applies beyond HTML 5, e.g. XMLHTTPRequest, > and perhaps Jabber etc. > > > Web addresses in HTML 5 > Editor's Draft 20 March 2009 > > Editors: > Dan Connolly, Midwest Web Sense LLC and W3C > C. M. Sperberg-McQueen, Black Mesa Technologies LLC > > Abstract > > This specification defines the handling of Web addresses for > Hypertext Markup Language (HTML) 5, the fifth major revision of the > core language of the World Wide Web. In this version, special > attention has been given to defining clear conformance criteria for > user agents in an effort to improve interoperability. > > Publication mechanics are a little goofy at this point; the 20 March > draft is available at: > http://homer.w3.org/~connolly/projects/urlp/raw-file/008373680cae/wah5/draft.html > > The 17 March draft is available attached to... > > "Web addresses in HTML 5" for review (ISSUE-56 urls-webarch) Dan > Connolly (Wednesday, 18 March) > http://lists.w3.org/Archives/Public/public-html/2009Mar/0444.html > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > > -- Mark Nottingham http://www.mnot.net/ From eburger@standardstrack.com Mon Mar 23 09:59: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 C07223A6A66 for ; Mon, 23 Mar 2009 09:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.640, 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 E45aNWr9Xerk for ; Mon, 23 Mar 2009 09:59:48 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 0F4933A67E7 for ; Mon, 23 Mar 2009 09:59:47 -0700 (PDT) Received: from [130.129.99.253] (port=50244 helo=dhcp-63fd.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LlnVo-0004yY-8W for apps-discuss@ietf.org; Mon, 23 Mar 2009 10:00:32 -0700 Message-Id: From: Eric Burger To: apps-discuss@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-10--325469354; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: IPR Date: Mon, 23 Mar 2009 09:54:11 -0700 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: Mon, 23 Mar 2009 16:59:48 -0000 --Apple-Mail-10--325469354 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit In the SIP Forum, we're spending literally thousands of dollars on legal fees to bring our IPR policy into the 21st Century. As the fellow from Nokia mentioned, there are serious anti-trust issues to consider. As Ted mentioned, if the policy becomes too onerous, then people will be told by their employers not to participate. I would also offer that having a special IPR policy for Apps from the rest of the IETF can create legal problems, as well. Echoing Dave here: as someone who is doing a lot of IPR work right now, I am amazed at how little the legal system makes sense. As engineers, we expect things to work in a rational, logical manner. Well, the legal system is logical, but to an outsider the logic is incredibly complex and counter-intuitive. What this means is if we do create a policy (which I am NOT in favor of), we will need to spend a few thousand on lawyers, too. --Apple-Mail-10--325469354 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjMxNjU0MTJaMCMGCSqGSIb3 DQEJBDEWBBS3DpWNT1lIutqhnsNgDbNxvEhfYzCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQCtdavQZBpgE4hjemdmrYgnGAhAh16g8UsjnjwP/bq5R1gf QYXzgaFAvNTiyPYWIy4doEaYYeWPEAP2JidXWP8JVkItB0ZlOAiabb/ZtPrAt3Vaav9OpoQWP/WN +LW9j+MgtJ4ib38brZciLerRzAIMb9Mu91WIvLOfL3k2juULy76vvfPi05/gAiZU3LHAgxJn7oK5 ze6M9Leya7Z52/Edz+08pSSiGkVdFlRyIYRU0Q+LegSyTvTpvx5TQWYTmogZCRZrBff1cSVjxxN/ FvWZ9fOyQ+2T4aOtw+t3bMbPI5LFPeSK+bqf2sZ5V0R8Fdfo54aDWOlo92DPfNJGYnSgAAAAAAAA --Apple-Mail-10--325469354-- From john-ietf@jck.com Mon Mar 23 11:01:20 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 703E43A68AF for ; Mon, 23 Mar 2009 11:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 ca9rG7rEkswe for ; Mon, 23 Mar 2009 11:01:19 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 866AF3A69AF for ; Mon, 23 Mar 2009 11:01:19 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LloTQ-0001H7-HH; Mon, 23 Mar 2009 14:02:08 -0400 Date: Mon, 23 Mar 2009 14:02:05 -0400 From: John C Klensin To: Eric Burger , apps-discuss@ietf.org Subject: Re: IPR Message-ID: In-Reply-To: References: 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 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, 23 Mar 2009 18:01:20 -0000 +1 (or several) --On Monday, March 23, 2009 09:54 -0700 Eric Burger wrote: > In the SIP Forum, we're spending literally thousands of > dollars on legal fees to bring our IPR policy into the 21st > Century. As the fellow from Nokia mentioned, there are > serious anti-trust issues to consider. As Ted mentioned, if > the policy becomes too onerous, then people will be told by > their employers not to participate. > > I would also offer that having a special IPR policy for Apps > from the rest of the IETF can create legal problems, as well. > > Echoing Dave here: as someone who is doing a lot of IPR work > right now, I am amazed at how little the legal system makes > sense. As engineers, we expect things to work in a rational, > logical manner. Well, the legal system is logical, but to an > outsider the logic is incredibly complex and > counter-intuitive. What this means is if we do create a > policy (which I am NOT in favor of), we will need to spend a > few thousand on lawyers, too. From eburger@standardstrack.com Mon Mar 23 11:04: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 56B5E3A69A2 for ; Mon, 23 Mar 2009 11:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.548, 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 76M1ElAmxRHg for ; Mon, 23 Mar 2009 11:04:41 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 998AC3A68AF for ; Mon, 23 Mar 2009 11:04:41 -0700 (PDT) Received: from [130.129.99.253] (port=51213 helo=dhcp-63fd.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LloWc-0006sR-Ll for apps-discuss@ietf.org; Mon, 23 Mar 2009 11:05:26 -0700 Message-Id: From: Eric Burger To: apps-discuss@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-10--321190341; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Update to BCP 56 :-) Date: Mon, 23 Mar 2009 11:05:30 -0700 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: Mon, 23 Mar 2009 18:04:42 -0000 --Apple-Mail-10--321190341 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit If there are so many different ways of doing it, and they are all broken, that sounds like a RESEARCH project to me. --Apple-Mail-10--321190341 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjMxODA1MzFaMCMGCSqGSIb3 DQEJBDEWBBT/vSS9y6z/XjMmmBqRN++l9eqZlDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBlJSxkQrBBl6Zdb5sPGqjuSRHPDHVzFjq0CHXLEUI6At0/ JKEwjlXplnM3mHjWcOnyFPBy20hAD2N2/oyor6TJj1TIRsJ4e7UbkKDDNkXY0EgFoBp+dIszUTT5 vNtx18bqJiiGgOHwfpFkJDP4suLBVOWEI1CPzNz5o4vA5E0jgaVCO4LtjJVuKZVQerDUjxp4xoO4 ru/KFOHipMiZqVAtZjFfs6r++n4NbSx3g1gNLI4lJfIQfW77vHatK74wJwya1hp74ziTjNztkaAP 5o53IQS6hJJO4PNYHorjholOIv6ZFD5+l5uaLCMz/CbTGoSD+LYfgnLqO+ZtXfJCBEunAAAAAAAA --Apple-Mail-10--321190341-- From stpeter@stpeter.im Mon Mar 23 11:16: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 48B593A6B18 for ; Mon, 23 Mar 2009 11:16:17 -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 SqS9Kzxn0rvP for ; Mon, 23 Mar 2009 11:16:05 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id EBF4D3A6C46 for ; Mon, 23 Mar 2009 11:16:03 -0700 (PDT) Received: from dhcp-11ba.meeting.ietf.org (dhcp-11ba.meeting.ietf.org [130.129.17.186]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id D1266E8002; Mon, 23 Mar 2009 12:16:53 -0600 (MDT) Message-ID: <49C7D214.9010804@stpeter.im> Date: Mon, 23 Mar 2009 11:16:52 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Eric Burger Subject: Re: Update to BCP 56 :-) References: In-Reply-To: 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="------------ms000206070204030407040008" 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, 23 Mar 2009 18:16:17 -0000 This is a cryptographically signed message in MIME format. --------------ms000206070204030407040008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/23/09 11:05 AM, Eric Burger wrote: > If there are so many different ways of doing it, and they are all > broken, that sounds like a RESEARCH project to me. Yes, I had that impression as well. I assume you're talking about all the bidirectional HTTP approaches from the AppArea general discussion this morning. :) Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms000206070204030407040008 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 DQEJBTEPFw0wOTAzMjMxODE2NTJaMCMGCSqGSIb3DQEJBDEWBBSXZ3nt4BnCBYHQMA9dFjGO ziIfBjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAZGhqPWcDtc25NGWQAZMwGoZaQ25pQxfv5bapP7GW9Gu/hhBanUMXwU53ng86 Xc/YvbQMwck2OssoJcS3KwVwSWPjOsW20ZxLP0RAVhsuIFAaMHishnEhYARTPuI7tusTBik5 57gee+S6ViiCcr8SmwNje6sd/++XWSWP1hY8Z6UuhNzL4Lw3o3bPWwQKmJLLQRtoydc+egb8 trzuwEr3yzImPXzFL9tbt6A6ztoRMYKcUSEKOzzkpyxAA8vTSKKmjqaUuKspGDnfltur5SWv +uGeSsJroXMpyo2LvFfsakyJvuzS77uR0NjNp/ExXm2WwJ5iBw8MCmo+eNe1Ru0w3AAAAAAA AA== --------------ms000206070204030407040008-- From eburger@standardstrack.com Mon Mar 23 13:41: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 CED563A6BE3 for ; Mon, 23 Mar 2009 13:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.480, 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 hIGpvBCpdN9f for ; Mon, 23 Mar 2009 13:41:57 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 1F86A3A6ABE for ; Mon, 23 Mar 2009 13:41:57 -0700 (PDT) Received: from [130.129.99.253] (port=52034 helo=dhcp-63fd.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Llqyk-0005uy-VA; Mon, 23 Mar 2009 13:42:41 -0700 Message-Id: <70ADE4DE-5FD9-4C62-AA3D-2E1AC08CD939@standardstrack.com> From: Eric Burger To: Peter Saint-Andre In-Reply-To: <49C7D214.9010804@stpeter.im> Content-Type: multipart/signed; boundary=Apple-Mail-20--311765740; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Update to BCP 56 :-) Date: Mon, 23 Mar 2009 13:42:35 -0700 References: <49C7D214.9010804@stpeter.im> 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: 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, 23 Mar 2009 20:41:57 -0000 --Apple-Mail-20--311765740 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Correct (the four broken, incompatible, and politically incompatible bidirectional HTTP approaches). BTW, would that not be a Transport Area Research Group, not Applications? On Mar 23, 2009, at 11:16 AM, Peter Saint-Andre wrote: > On 3/23/09 11:05 AM, Eric Burger wrote: >> If there are so many different ways of doing it, and they are all >> broken, that sounds like a RESEARCH project to me. > > Yes, I had that impression as well. > > I assume you're talking about all the bidirectional HTTP approaches > from > the AppArea general discussion this morning. :) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > --Apple-Mail-20--311765740 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjMyMDQyMzVaMCMGCSqGSIb3 DQEJBDEWBBTkaR6Y7jxZpjUnK3dBGN62ozgwxjCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQARs7agGe0+Jbj/H9+WzmJoJk+2xgErjTmZ0fvH/h+Wm0Ee DhG6pf+RITqW0Y1e9aHkMgF7YVSCMr8yBEhLCChCQocjwX5XkNmpfQHS8vjo60puzEiXkCyX9Bt0 ZAVfeh3tNKUghgWzjTJGKA7I8Zl2rJWNrsumg72NgYU8iNHu765vuXg2WjnXuTUQZawUKuZFI5oR SGgDcu7Qi5fRi6/gncHJjmNUpHvNeiWnYLdJxJDppmeFmpUpcIzJ2LsnLqSzlHkBVoHtujV3QLDR v92luZIRTIFre0JVawxIRSIPi/77wCAESkKWKKU1Af4he7BXwSk+J69n7f4+x7h8W8y/AAAAAAAA --Apple-Mail-20--311765740-- From Martin.Thomson@andrew.com Tue Mar 24 02:06: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 016203A67D0 for ; Tue, 24 Mar 2009 02:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 iEkoqTOAUMFF for ; Tue, 24 Mar 2009 02:06:08 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B679B3A67B1 for ; Tue, 24 Mar 2009 02:06:07 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_24_04_27_02 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Mar 2009 04:27:02 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 04:06:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 x-cr-puzzleid: {AAE1B5BB-5464-455E-9E38-D6B6D851D590} Content-class: urn:content-classes:message x-cr-hashedpuzzle: AhRc Al7g AwyL BVx5 CF07 DAta DoEe EJBr Eq71 FPnK GYXd I93X JWgF KOnH KpJ4 KxrJ; 1; YQBwAHAAcwAtAGQAaQBzAGMAdQBzAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {AAE1B5BB-5464-455E-9E38-D6B6D851D590}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Tue, 24 Mar 2009 09:06:52 GMT; UwB0AHIAYQB3AG0AYQBuADoAIABQAFQAVABIAA== Subject: Strawman: PTTH Date: Tue, 24 Mar 2009 04:06:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Strawman: PTTH Thread-Index: AcmsX9+FaJZtRMfQQ5Cp7AGkN/78Fg== From: "Thomson, Martin" To: X-OriginalArrivalTime: 24 Mar 2009 09:06:57.0156 (UTC) FILETIME=[E2135C40:01C9AC5F] 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, 24 Mar 2009 09:06:10 -0000 Rm9sa3MsDQoNCkkndmUgYmVlbiBpbnRlcmVzdGVkIGluIHNvbHZpbmcgdGhlIEhUVFAgcHJvYmxl bSBkaXNjdXNzZWQgdG9kYXkgZm9yIHF1aXRlIHNvbWUgdGltZS4gIEkndmUgcmV2aWV3ZWQgYWxs IHRoZSBwcm9wb3NhbHMgcmV2aWV3ZWQuICBUd28gdGhpbmdzIHN0cmlrZSBtZToNCg0KIC0gQk9T SCBhbmQgQmF5ZXV4IGJvdGggYWRkcmVzcyB0aGUgcmVhbCBwcm9ibGVtLiAgTmFtZWx5OiBob3cg dGhpcyB3b3JrcyBpbiB0aGUgd29ybGQgdGhhdCBleGlzdHMgcmlnaHQgbm93LiAgVGhleSBkbyB0 aGlzIHdpdGggbG9uZyBwb2xsaW5nLiAgVGhpcyBpcyBhIGdvb2Qgc29sdXRpb24gdGhhdCB3ZSBr bm93IHdvcmtzLiAgckhUVFAgYW5kIFdlYnNvY2tldHMgYXJlIG5ldyBwcm90b2NvbHMgdGhhdCBt aWdodCB3b3JrLCBidXQgSSBoYXZlIG15IHJlc2VydmF0aW9ucy4NCg0KIC0gQk9TSCBhbmQgQmF5 ZXV4IHNlZW0gdG8gYmUgd2F5IG92ZXItZW5naW5lZXJlZC4gIENoYW5uZWxzIGFuZCBzZXNzaW9u cyBhbmQgYWxsIHRoYXQgc3R1ZmYgaXNuJ3QgSFRUUCAtIEhUVFAgaXMsIHdoZW4geW91IGdldCBy aWdodCBkb3duIHRvIGl0LCBwcmV0dHkgZHVtYi4gIFRoYXQncyBhIHZpcnR1ZSB0aGF0IGlzIGxv c3QuDQoNCkkgYW0gdHJ1bHkgc3VycHJpc2VkIHRoYXQgbm8tb25lIGhhcyBzdWdnZXN0ZWQgdGhp cyBwYXJ0aWN1bGFyIGlkZWEsIHNvIEknbGwgZG8gYSBicmllZiBkZXNjcmlwdGlvbiBhbmQgaG9w ZWZ1bGx5IEkgY2FuIHRoZW4gc2xlZXAuDQoNCn5+fg0KDQo9PT1QVFRIOyBvciBIVFRQLCBvdmVy IGVhc3kgKG9uIHRoaXMgbm90ZSwgSSdkIGxpa2UgdG8gZmluZCBhIG5hc3R5IGJhY2tyb255bSBm b3IgUFRUSCwgYnV0IFByb3RvY29sIFRoYXQgVHdlYWtzL1R3aXN0cy9UdXJucyBIVFRQIGtpbmRh IHN1Y2tzKSANCg0KQSBmcmlnaHRlbmluZ2x5IHNpbXBsZSBpZGVhOiBsb25nIHBvbGxpbmcgKyBi YWNrLXRvLWZyb250IEhUVFAgcmVxdWVzdHMgaW5zaWRlIG90aGVyIEhUVFAgcmVxdWVzdHMuDQoN Cj09VGVybWlub2xvZ3k6DQoNCkNsaWVudCBhbmQgc2VydmVyIGNhbiBiZSBtaXNsZWFkaW5nIGlu IHRoaXMgY29udGV4dC4gIFJGQyAzMDgwIGRlYWxzIHdpdGggdGhpcyBwcm9ibGVtIGFscmVhZHkg LSBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgYW5kIHJl cXVlc3QvcmVzcG9uc2UgZXhjaGFuZ2VzLiAgSSdsbCBib3Jyb3cgdGhvc2UgdGVybXMuDQoNCklu aXRpYXRpbmcgUGVlciAtIHRoZSAiY2xhc3NpY2FsIiBIVFRQIGNsaWVudCwgdGhlIHBlZXIgdGhh dCBlc3RhYmxpc2hlcyB0aGUgVENQIGNvbm5lY3Rpb24uDQpMaXN0ZW5pbmcgUGVlciAtIHRoZSAi Y2xhc3NpY2FsIiBIVFRQIHNlcnZlciwgdGhlIHBlZXIgdGhhdCBsaXN0ZW5zIGZvciBUQ1AgY29u bmVjdGlvbnMuDQpDbGllbnQgUGVlciAtIHRoZSBwZWVyIHRoYXQgaXMgbWFraW5nIFBUVEggcmVx dWVzdHMgKEhUVFAgc2VydmVyKQ0KU2VydmluZyBQZWVyIC0gdGhlIHBlZXIgdGhhdCBpcyBzZXJ2 aW5nIFBUVEggcmVxdWVzdHMgKEhUVFAgY2xpZW50KQ0KDQo9PU92ZXJ2aWV3IG9mIG9wZXJhdGlv bg0KDQpBcHBsaWNhdGlvbiBzZW1hbnRpY3MgZXN0YWJsaXNoIHRoZSBuZWVkIGZvciBhbiBIVFRQ IHBlZXIgdG8gZXN0YWJsaXNoIGEgUFRUSCAic2Vzc2lvbiIuICBBIHBhcnQgb2YgdGhpcyBpbmNs dWRlcyBhIFVSSSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBmZWVkcyB0byB0aGUgaW5pdGlhdGluZyBw ZWVyIHdpdGggdGhlIGV4cGVjdGF0aW9uIHRoYXQgYSBQVFRIIHNlc3Npb24gaXMgZXN0YWJsaXNo ZWQuICBUaGUgaW5pdGlhdGluZyBwZWVyIG9wZW5zIGEgY29ubmVjdGlvbiB0byB0aGUgbGlzdGVu aW5nIHBlZXIgYW5kIHNlbmRzIGFuIEhUVFAgUE9TVCByZXF1ZXN0Og0KDQogIFBPU1QgL3B0dGgv cGF0aCBIVFRQLzEuMQ0KICBIb3N0OiBzZXJ2ZXIubmFtZS5leGFtcGxlDQogIENvbnRlbnQtTGVu Z3RoOiAwDQoNCkxvbmcgcG9sbGluZyBlbnN1ZXMuICBPbiB0aW1lb3V0IHRoZSBsaXN0ZW5pbmcg cGVlciBzZW5kcyBhbiBIVFRQIHJlc3BvbnNlIHRoYXQgZG9lc24ndCBjb250YWluIGFuIEhUVFAg cmVxdWVzdCwgdGhhdCByZXNwb25zZSBpcyBkaXNjYXJkZWQgYnkgdGhlIGluaXRpYXRpbmcgcGVl ciBhbmQgYSBuZXcsIGVtcHR5IHJlcXVlc3QgaXMgc2VudC4gIA0KDQpJZiB0aGUgY2xpZW50IHBl ZXIgbmVlZHMgdG8gc2VuZCBzb21ldGhpbmcgaXQgc2VuZHMgYW4gSFRUUCByZXNwb25zZSB0aGF0 IGNvbnRhaW5zIGFuIEhUVFAgcmVxdWVzdDoNCg0KICBIVFRQLzEuMSAyMDAgT0sNCiAgQ29udGVu dC1UeXBlOiBhcHBsaWNhdGlvbi9odHRwDQogIENvbnRlbnQtTGVuZ3RoOiAuLi4NCg0KICBHRVQg L2luZGV4Lmh0bWwgSFRUUC8xLjENCiAgSG9zdDogDQoNCg0KVGhlIHNlcnZpbmcgcGVlciBpbmNs dWRlcyB0aGUgcmVzcG9uc2UgaW4gdGhlIG5leHQgcmVxdWVzdCBpdCBzZW5kcy4gIFRoaXMgYWxz byBzZXJ2ZXMgYXMgdGhlIG1lYW5zIGJ5IHdoaWNoIHRoZSBuZXh0IHJlcXVlc3QgbWlnaHQgYmUg YWNxdWlyZWQ6DQoNCiAgUE9TVCAvcHR0aC9wYXRoIEhUVFAvMS4xDQogIEhvc3Q6IHNlcnZlci5u YW1lLmV4YW1wbGUNCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9odHRwDQogIENvbnRlbnQt TGVuZ3RoOiAuLi4NCg0KICBIVFRQLzEuMSAyMDAgT0sNCiAgQ29udGVudC1UeXBlOiBhcHBsaWNh dGlvbi94aHRtbCt4bWwNCg0KICAuLi5jb250ZW50Li4uDQoNCg0KPT1Qcm90b2NvbCBwaWVjZXMN Cg0KQSBuZXcgTUlNRSB0eXBlOiBhcHBsaWNhdGlvbi9odHRwIG9yIHNvbWUgc3VjaCB0byBkaXN0 aW5ndWlzaCBtZXNzYWdlIGJvZGllcy4NCg0KUG9zc2libHk6IGFuIEhUVFAgaGVhZGVyIHRoYXQg aW5kaWNhdGVzIHRoYXQgYW4gSFRUUCByZXF1ZXN0IGlzIGFuIGluaXRpYXRpbmcgbWVzc2FnZS4g SG93ZXZlciwgSSBjb25zaWRlciBpdCBsaWtlbHkgdGhhdCB0aGlzIGlzIG5vdCBhY3R1YWxseSBu ZWNlc3NhcnkuICBUaGUgZXhwZWN0YXRpb24gaXMgc2V0IGJ5IHRoZSBhcHBsaWNhdGlvbiwgYW5k IHRoZSBNSU1FLXR5cGUgaXMgYSBmdXJ0aGVyIGluZGljYXRpb24gdGhhdCB0aGlzIGJlaGF2aW91 ciBpcyBkZXNpcmVkLg0KDQo9PUxpbWl0YXRpb25zIGFuZCB0aGluZ3MgdG8gbG9vayBpbnRvIGZ1 cnRoZXINCg0KUGlwZWxpbmluZyBpcyBtb3JlIG9yIGxlc3MgaW1wb3NzaWJsZSB3aXRoIHRoaXMg YXBwcm9hY2guICBTaW5jZSBhIHJlc3BvbnNlIGZyb20gdGhlIHNlcnZpbmcgcGVlciBpcyBleHBl Y3RlZCBvbiB0aGUgbmV4dCBIVFRQIHJlcXVlc3QgcmVjZWl2ZWQgYnkgdGhlIGNsaWVudCBwZWVy LCB0aGUgc2VydmluZy9pbml0aWF0aW5nIHBlZXIgY2Fubm90IHBpcGVsaW5lIHJlcXVlc3RzLiAg VGhpcyBtaWdodCBuZWVkIHRvIGJlIGxvb2tlZCBpbnRvIGlmIHRoZSBwcm9ibGVtIGlzIGNvbnNp ZGVyZWQgYXMgYmVpbmcgd29ydGggc29sdmluZy4gIFRoaXMgaXMgdGhlIG9ubHkgbWFqb3IgY29u Y2VybiBJJ3ZlIHJ1biBpbnRvLg0KDQpUdW5pbmcgdGhlIHRpbWVvdXQgaXMgc29tZXRoaW5nIHRo YXQgY291bGQgYmUgbG9va2VkIGF0LCBidXQgdGhpcyBpcyBhIHByb2JsZW0gdGhhdCBhcHBsaWVz IGluIGdlbmVyYWwgdG8gYWxsIGxvbmctcG9sbGluZyBhcHByb2FjaGVzLg0KDQpJIGhhdmVuJ3Qg ZG9uZSBhIHRob3JvdWdoIGNoZWNrIG9mIEhUVFAgaGVhZGVycywgYnV0IEkgZG9uJ3QgYWN0dWFs bHkgdGhpbmsgdGhhdCB0aGVyZSBpcyBhbnkgbmVlZCBmb3IgYW55dGhpbmcgbW9yZSBjb21wbGlj YXRlZCB0aGFuIHRoaXMuICBMaXN0ZW5pbmcgcGVlcnMgbWlnaHQgbGlrZSB0byB1c2UgQ2FjaGUt Q29udHJvbDogcHJpdmF0ZSBpbiByZXNwb25zZXMgdG8gcHJldmVudCBjYWNoaW5nLCBhbmQgc28g Zm9ydGgsIGJ1dCBJIGRvbid0IGFjdHVhbGx5IHRoaW5rIHRoYXQgdGhlcmUgaXMgbXVjaCBtb3Jl IHJlcXVpcmVkIGhlcmUuICBTb21lIGhlYWRlcnMgYXJlIHBvaW50bGVzcyBvbiB0aGUgbmVzdGVk IHJlcXVlc3QsIHN1Y2ggYXMgcHJveHkgYXV0aGVudGljYXRpb24gaGVhZGVycyBvciB0cmFuc2Zl ci1lbmNvZGluZywgYnV0IC0gYWdhaW4gLSB0aG9zZSBhcmUgc2Vjb25kYXJ5IGlzc3Vlcy4gIEkg bmVlZCB0byBnbyB0aHJvdWdoIExpc2EncyBtaW5pIHVzaW5nLWh0dHAgY2hlY2tsaXN0IChCQ1A1 NmJpcykgLSB0aGVyZSBhcmUgcHJvYmFibHkgb3RoZXIgY2x1ZXMgdGhlcmUgYXMgdG8gd2hhdCBl bHNlIG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQuDQoNCj09SW1wbGVtZW50YXRpb24NCg0KVGhpcyBp cyBlYXN5IHRvIGltcGxlbWVudC4gIFRoZSBsaXN0ZW5pbmcvY2xpZW50IHBlZXIgaXMgdmVyeSBl YXN5LiAgVGhpcyBpcyBlc3BlY2lhbGx5IHRydWUgd2l0aCB0aGluZ3MgbGlrZSBKZXR0eSBjb250 aW51YXRpb25zIHdoZXJlIHlvdSBjYW4gc2l0IHdhaXRpbmcgYWxtb3N0IGluZGVmaW5pdGVseS4N Cg0KVGhlIGluaXRpYXRpbmcvc2VydmluZyBwZWVyIGNhbiBiZSBpbXBsZW1lbnRlZCBieSByYW1t aW5nIGFuIEhUVFAgY2xpZW50IHRvZ2V0aGVyIHdpdGggYW4gSFRUUCBzZXJ2ZXIuICBUaGUgSFRU UCBjbGllbnQgbWFrZXMgdGhlIGxvbmcgcG9sbHMuICBJZiBhIHJlc3BvbnNlIGNvbWVzIGJhY2sg d2l0aCBhbiBhcHBsaWNhdGlvbi9odHRwIGJvZHksIGl0IGV4dHJhY3RzIHRoYXQgcmVzcG9uc2Ug YW5kIHNlbmRzIHRoYXQgYXMgYSByZXF1ZXN0IHRvIHRoZSBIVFRQIHNlcnZlci4gIFRoZSByZXNw b25zZSBmcm9tIHRoZSBIVFRQIHNlcnZlciBpcyBzZW50IHRvIHRoZSBsaXN0ZW5pbmcvY2xpZW50 IHBlZXIgaW4gdGhlIG5leHQgcmVxdWVzdC4NCg0Kfn5+DQoNCkkgY2FuJ3QgaGVscCBidXQgdGhp bmsgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyBsaWtlIHdoYXQgTWFyayBOb3R0aW5naGFtIHdhcyBo aW50aW5nIGF0IHdpdGggaGlzIGNvbW1lbnRzIGF0IHRoZSBtaWMgdG9kYXkuDQoJDQpObyBkb3Vi dCB0aGVyZSBhcmUgZHJhd2JhY2tzLCBiZWNhdXNlIHRoaXMgaXMgYWxtb3N0IHRvbyBzaW1wbGUu ICBPZiBjb3Vyc2UsIGl0IGluaGVyaXRzIGEgZ3JlYXQgZGVhbCBvZiB0aGUgY2hhcmFjdGVyaXN0 aWNzIG9mIEhUVFAsIGJvdGggZ29vZCBhbmQgYmFkLiAgSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhl IHBpcGVsaW5pbmcgdGhpbmcgaXMgYSBzaG93c3RvcHBlciwgb3Igd2hldGhlciB0aGVyZSBhcmUg b3RoZXIgdGhpbmdzIHRoYXQgSSd2ZSBtaXNzZWQuIA0KDQpJIHRob3VnaHQgaXQgd29ydGggc2hh cmluZywgaWYgb25seSB0byBlbnJpY2ggdGhlIGRpc2N1c3Npb24uICANCg0KRnJvbSBkZWVwIGlu IHRoZSB0d2lsaWdodCB6b25lLA0KTWFydGluDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCBy ZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBv ciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg aXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRl bGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBp cyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpb bWYyXQ0K From Martin.Thomson@andrew.com Tue Mar 24 02:40: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 1FA493A6CCE for ; Tue, 24 Mar 2009 02:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 DBbWorWhvZ0Y for ; Tue, 24 Mar 2009 02:40:01 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B4EF63A6CCB for ; Tue, 24 Mar 2009 02:40:00 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_24_05_00_56 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Mar 2009 05:00:56 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 04:40:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: Strawman: PTTH Date: Tue, 24 Mar 2009 04:40:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Strawman: PTTH Thread-Index: AcmsX9+FaJZtRMfQQ5Cp7AGkN/78FgABCDdQ References: From: "Thomson, Martin" To: X-OriginalArrivalTime: 24 Mar 2009 09:40:51.0070 (UTC) FILETIME=[9E6201E0:01C9AC64] 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, 24 Mar 2009 09:40:03 -0000 Li4uc3RpbGwgbm90IHNsZWVwaW5nLi4uDQoNCk9uIGNvbnNpZGVyYXRpb246IGlnbm9yZSB3aGF0 IEkgc2FpZCBhYm91dCBwaXBlbGluaW5nOyBJIHdvcmtlZCBpdCBvdXQuICBUaGUgbGlzdGVuaW5n L2NsaWVudCBwZWVyIGNhbiBqdXN0IGlnbm9yZSByZXF1ZXN0cyB0aGF0IGRvbid0IGNvbnRhaW4g dGhlIGFwcGxpY2F0aW9uL2h0dHAgTUlNRSB0eXBlLiAgT3JkZXJpbmcgdGhlbiByZW1haW5zIHRo ZSBzb2xlIG1lYW5zIG9mIHJlcXVlc3QvcmVzcG9uc2UgY29ycmVsYXRpb24uICBObyBoZWFkZXJz IG5lZWRlZC4NCg0KT24gY29ubmVjdGlvbiBjbG9zZTogIHRoZSBsaXN0ZW5pbmcvY2xpZW50IHBl ZXIgbmVlZHMgYSB3YXkgb2YgdW5hbWJpZ3VvdXNseSB0ZWxsaW5nIHRoZSBpbml0aWF0aW5nL3Nl cnZpbmcgcGVlciB0aGF0IGl0J3MgZmluaXNoZWQuICBUaGlzIG1pZ2h0IGJlIGFuIGFwcGxpY2F0 aW9uLWxheWVyIHRoaW5nLCBidXQgYXMgYSBzdWdnZXN0aW9uLCBDb25uZWN0aW9uOiBjbG9zZSB3 b3VsZCBwcm9iYWJseSB3b3JrIHdlbGwgZW5vdWdoLiAgVGhlIGNsaWVudCBzaG91bGQgcHJvYmFi bHkga2VlcCB0cnlpbmcgdW50aWwgaXQgc2VlcyBvbmUgb2YgdGhlc2UgYmVjYXVzZSBpdCBjYW4n dCBiZSBzdXJlIHRoYXQgYSBjb25uZWN0aW9uIGRyb3AgaXNuJ3QgZm9yIG90aGVyIHJlYXNvbnMg KGUuZy4gYSBwcm94eSB0aW1lb3V0KS4NCg0KSW5zb21uaWFjYWxseSwNCk1hcnRpbg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLQ0KPiBib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgVGhvbXNvbiwgTWFydGluDQo+IFNlbnQ6IFR1ZXNkYXksIDI0IE1hcmNoIDIwMDkgMjow NyBBTQ0KPiBUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IFN1YmplY3Q6IFN0cmF3bWFuOiBQ VFRIDQo+IA0KPiBGb2xrcywNCj4gDQo+IEkndmUgYmVlbiBpbnRlcmVzdGVkIGluIHNvbHZpbmcg dGhlIEhUVFAgcHJvYmxlbSBkaXNjdXNzZWQgdG9kYXkgZm9yDQo+IHF1aXRlIHNvbWUgdGltZS4g IEkndmUgcmV2aWV3ZWQgYWxsIHRoZSBwcm9wb3NhbHMgcmV2aWV3ZWQuICBUd28gdGhpbmdzDQo+ IHN0cmlrZSBtZToNCj4gDQo+ICAtIEJPU0ggYW5kIEJheWV1eCBib3RoIGFkZHJlc3MgdGhlIHJl YWwgcHJvYmxlbS4gIE5hbWVseTogaG93IHRoaXMNCj4gd29ya3MgaW4gdGhlIHdvcmxkIHRoYXQg ZXhpc3RzIHJpZ2h0IG5vdy4gIFRoZXkgZG8gdGhpcyB3aXRoIGxvbmcNCj4gcG9sbGluZy4gIFRo aXMgaXMgYSBnb29kIHNvbHV0aW9uIHRoYXQgd2Uga25vdyB3b3Jrcy4gIHJIVFRQIGFuZA0KPiBX ZWJzb2NrZXRzIGFyZSBuZXcgcHJvdG9jb2xzIHRoYXQgbWlnaHQgd29yaywgYnV0IEkgaGF2ZSBt eQ0KPiByZXNlcnZhdGlvbnMuDQo+IA0KPiAgLSBCT1NIIGFuZCBCYXlldXggc2VlbSB0byBiZSB3 YXkgb3Zlci1lbmdpbmVlcmVkLiAgQ2hhbm5lbHMgYW5kDQo+IHNlc3Npb25zIGFuZCBhbGwgdGhh dCBzdHVmZiBpc24ndCBIVFRQIC0gSFRUUCBpcywgd2hlbiB5b3UgZ2V0IHJpZ2h0DQo+IGRvd24g dG8gaXQsIHByZXR0eSBkdW1iLiAgVGhhdCdzIGEgdmlydHVlIHRoYXQgaXMgbG9zdC4NCj4gDQo+ IEkgYW0gdHJ1bHkgc3VycHJpc2VkIHRoYXQgbm8tb25lIGhhcyBzdWdnZXN0ZWQgdGhpcyBwYXJ0 aWN1bGFyIGlkZWEsIHNvDQo+IEknbGwgZG8gYSBicmllZiBkZXNjcmlwdGlvbiBhbmQgaG9wZWZ1 bGx5IEkgY2FuIHRoZW4gc2xlZXAuDQo+IA0KPiB+fn4NCj4gDQo+ID09PVBUVEg7IG9yIEhUVFAs IG92ZXIgZWFzeSAob24gdGhpcyBub3RlLCBJJ2QgbGlrZSB0byBmaW5kIGEgbmFzdHkNCj4gYmFj a3JvbnltIGZvciBQVFRILCBidXQgUHJvdG9jb2wgVGhhdCBUd2Vha3MvVHdpc3RzL1R1cm5zIEhU VFAga2luZGENCj4gc3Vja3MpDQo+IA0KPiBBIGZyaWdodGVuaW5nbHkgc2ltcGxlIGlkZWE6IGxv bmcgcG9sbGluZyArIGJhY2stdG8tZnJvbnQgSFRUUCByZXF1ZXN0cw0KPiBpbnNpZGUgb3RoZXIg SFRUUCByZXF1ZXN0cy4NCj4gDQo+ID09VGVybWlub2xvZ3k6DQo+IA0KPiBDbGllbnQgYW5kIHNl cnZlciBjYW4gYmUgbWlzbGVhZGluZyBpbiB0aGlzIGNvbnRleHQuICBSRkMgMzA4MCBkZWFscw0K PiB3aXRoIHRoaXMgcHJvYmxlbSBhbHJlYWR5IC0gZGlmZmVyZW50aWF0aW5nIGJldHdlZW4gY29u bmVjdGlvbg0KPiBlc3RhYmxpc2htZW50IGFuZCByZXF1ZXN0L3Jlc3BvbnNlIGV4Y2hhbmdlcy4g IEknbGwgYm9ycm93IHRob3NlIHRlcm1zLg0KPiANCj4gSW5pdGlhdGluZyBQZWVyIC0gdGhlICJj bGFzc2ljYWwiIEhUVFAgY2xpZW50LCB0aGUgcGVlciB0aGF0DQo+IGVzdGFibGlzaGVzIHRoZSBU Q1AgY29ubmVjdGlvbi4NCj4gTGlzdGVuaW5nIFBlZXIgLSB0aGUgImNsYXNzaWNhbCIgSFRUUCBz ZXJ2ZXIsIHRoZSBwZWVyIHRoYXQgbGlzdGVucyBmb3INCj4gVENQIGNvbm5lY3Rpb25zLg0KPiBD bGllbnQgUGVlciAtIHRoZSBwZWVyIHRoYXQgaXMgbWFraW5nIFBUVEggcmVxdWVzdHMgKEhUVFAg c2VydmVyKQ0KPiBTZXJ2aW5nIFBlZXIgLSB0aGUgcGVlciB0aGF0IGlzIHNlcnZpbmcgUFRUSCBy ZXF1ZXN0cyAoSFRUUCBjbGllbnQpDQo+IA0KPiA9PU92ZXJ2aWV3IG9mIG9wZXJhdGlvbg0KPiAN Cj4gQXBwbGljYXRpb24gc2VtYW50aWNzIGVzdGFibGlzaCB0aGUgbmVlZCBmb3IgYW4gSFRUUCBw ZWVyIHRvIGVzdGFibGlzaA0KPiBhIFBUVEggInNlc3Npb24iLiAgQSBwYXJ0IG9mIHRoaXMgaW5j bHVkZXMgYSBVUkkgdGhhdCB0aGUgYXBwbGljYXRpb24NCj4gZmVlZHMgdG8gdGhlIGluaXRpYXRp bmcgcGVlciB3aXRoIHRoZSBleHBlY3RhdGlvbiB0aGF0IGEgUFRUSCBzZXNzaW9uDQo+IGlzIGVz dGFibGlzaGVkLiAgVGhlIGluaXRpYXRpbmcgcGVlciBvcGVucyBhIGNvbm5lY3Rpb24gdG8gdGhl DQo+IGxpc3RlbmluZyBwZWVyIGFuZCBzZW5kcyBhbiBIVFRQIFBPU1QgcmVxdWVzdDoNCj4gDQo+ ICAgUE9TVCAvcHR0aC9wYXRoIEhUVFAvMS4xDQo+ICAgSG9zdDogc2VydmVyLm5hbWUuZXhhbXBs ZQ0KPiAgIENvbnRlbnQtTGVuZ3RoOiAwDQo+IA0KPiBMb25nIHBvbGxpbmcgZW5zdWVzLiAgT24g dGltZW91dCB0aGUgbGlzdGVuaW5nIHBlZXIgc2VuZHMgYW4gSFRUUA0KPiByZXNwb25zZSB0aGF0 IGRvZXNuJ3QgY29udGFpbiBhbiBIVFRQIHJlcXVlc3QsIHRoYXQgcmVzcG9uc2UgaXMNCj4gZGlz Y2FyZGVkIGJ5IHRoZSBpbml0aWF0aW5nIHBlZXIgYW5kIGEgbmV3LCBlbXB0eSByZXF1ZXN0IGlz IHNlbnQuDQo+IA0KPiBJZiB0aGUgY2xpZW50IHBlZXIgbmVlZHMgdG8gc2VuZCBzb21ldGhpbmcg aXQgc2VuZHMgYW4gSFRUUCByZXNwb25zZQ0KPiB0aGF0IGNvbnRhaW5zIGFuIEhUVFAgcmVxdWVz dDoNCj4gDQo+ICAgSFRUUC8xLjEgMjAwIE9LDQo+ICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlv bi9odHRwDQo+ICAgQ29udGVudC1MZW5ndGg6IC4uLg0KPiANCj4gICBHRVQgL2luZGV4Lmh0bWwg SFRUUC8xLjENCj4gICBIb3N0Og0KPiANCj4gDQo+IFRoZSBzZXJ2aW5nIHBlZXIgaW5jbHVkZXMg dGhlIHJlc3BvbnNlIGluIHRoZSBuZXh0IHJlcXVlc3QgaXQgc2VuZHMuDQo+IFRoaXMgYWxzbyBz ZXJ2ZXMgYXMgdGhlIG1lYW5zIGJ5IHdoaWNoIHRoZSBuZXh0IHJlcXVlc3QgbWlnaHQgYmUNCj4g YWNxdWlyZWQ6DQo+IA0KPiAgIFBPU1QgL3B0dGgvcGF0aCBIVFRQLzEuMQ0KPiAgIEhvc3Q6IHNl cnZlci5uYW1lLmV4YW1wbGUNCj4gICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2h0dHANCj4g ICBDb250ZW50LUxlbmd0aDogLi4uDQo+IA0KPiAgIEhUVFAvMS4xIDIwMCBPSw0KPiAgIENvbnRl bnQtVHlwZTogYXBwbGljYXRpb24veGh0bWwreG1sDQo+IA0KPiAgIC4uLmNvbnRlbnQuLi4NCj4g DQo+IA0KPiA9PVByb3RvY29sIHBpZWNlcw0KPiANCj4gQSBuZXcgTUlNRSB0eXBlOiBhcHBsaWNh dGlvbi9odHRwIG9yIHNvbWUgc3VjaCB0byBkaXN0aW5ndWlzaCBtZXNzYWdlDQo+IGJvZGllcy4N Cj4gDQo+IFBvc3NpYmx5OiBhbiBIVFRQIGhlYWRlciB0aGF0IGluZGljYXRlcyB0aGF0IGFuIEhU VFAgcmVxdWVzdCBpcyBhbg0KPiBpbml0aWF0aW5nIG1lc3NhZ2UuIEhvd2V2ZXIsIEkgY29uc2lk ZXIgaXQgbGlrZWx5IHRoYXQgdGhpcyBpcyBub3QNCj4gYWN0dWFsbHkgbmVjZXNzYXJ5LiAgVGhl IGV4cGVjdGF0aW9uIGlzIHNldCBieSB0aGUgYXBwbGljYXRpb24sIGFuZCB0aGUNCj4gTUlNRS10 eXBlIGlzIGEgZnVydGhlciBpbmRpY2F0aW9uIHRoYXQgdGhpcyBiZWhhdmlvdXIgaXMgZGVzaXJl ZC4NCj4gDQo+ID09TGltaXRhdGlvbnMgYW5kIHRoaW5ncyB0byBsb29rIGludG8gZnVydGhlcg0K PiANCj4gUGlwZWxpbmluZyBpcyBtb3JlIG9yIGxlc3MgaW1wb3NzaWJsZSB3aXRoIHRoaXMgYXBw cm9hY2guICBTaW5jZSBhDQo+IHJlc3BvbnNlIGZyb20gdGhlIHNlcnZpbmcgcGVlciBpcyBleHBl Y3RlZCBvbiB0aGUgbmV4dCBIVFRQIHJlcXVlc3QNCj4gcmVjZWl2ZWQgYnkgdGhlIGNsaWVudCBw ZWVyLCB0aGUgc2VydmluZy9pbml0aWF0aW5nIHBlZXIgY2Fubm90DQo+IHBpcGVsaW5lIHJlcXVl c3RzLiAgVGhpcyBtaWdodCBuZWVkIHRvIGJlIGxvb2tlZCBpbnRvIGlmIHRoZSBwcm9ibGVtIGlz DQo+IGNvbnNpZGVyZWQgYXMgYmVpbmcgd29ydGggc29sdmluZy4gIFRoaXMgaXMgdGhlIG9ubHkg bWFqb3IgY29uY2VybiBJJ3ZlDQo+IHJ1biBpbnRvLg0KPiANCj4gVHVuaW5nIHRoZSB0aW1lb3V0 IGlzIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGxvb2tlZCBhdCwgYnV0IHRoaXMgaXMgYQ0KPiBw cm9ibGVtIHRoYXQgYXBwbGllcyBpbiBnZW5lcmFsIHRvIGFsbCBsb25nLXBvbGxpbmcgYXBwcm9h Y2hlcy4NCj4gDQo+IEkgaGF2ZW4ndCBkb25lIGEgdGhvcm91Z2ggY2hlY2sgb2YgSFRUUCBoZWFk ZXJzLCBidXQgSSBkb24ndCBhY3R1YWxseQ0KPiB0aGluayB0aGF0IHRoZXJlIGlzIGFueSBuZWVk IGZvciBhbnl0aGluZyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhpcy4NCj4gTGlzdGVuaW5nIHBl ZXJzIG1pZ2h0IGxpa2UgdG8gdXNlIENhY2hlLUNvbnRyb2w6IHByaXZhdGUgaW4gcmVzcG9uc2Vz DQo+IHRvIHByZXZlbnQgY2FjaGluZywgYW5kIHNvIGZvcnRoLCBidXQgSSBkb24ndCBhY3R1YWxs eSB0aGluayB0aGF0IHRoZXJlDQo+IGlzIG11Y2ggbW9yZSByZXF1aXJlZCBoZXJlLiAgU29tZSBo ZWFkZXJzIGFyZSBwb2ludGxlc3Mgb24gdGhlIG5lc3RlZA0KPiByZXF1ZXN0LCBzdWNoIGFzIHBy b3h5IGF1dGhlbnRpY2F0aW9uIGhlYWRlcnMgb3IgdHJhbnNmZXItZW5jb2RpbmcsIGJ1dA0KPiAt IGFnYWluIC0gdGhvc2UgYXJlIHNlY29uZGFyeSBpc3N1ZXMuICBJIG5lZWQgdG8gZ28gdGhyb3Vn aCBMaXNhJ3MgbWluaQ0KPiB1c2luZy1odHRwIGNoZWNrbGlzdCAoQkNQNTZiaXMpIC0gdGhlcmUg YXJlIHByb2JhYmx5IG90aGVyIGNsdWVzIHRoZXJlDQo+IGFzIHRvIHdoYXQgZWxzZSBuZWVkcyB0 byBiZSBjb25zaWRlcmVkLg0KPiANCj4gPT1JbXBsZW1lbnRhdGlvbg0KPiANCj4gVGhpcyBpcyBl YXN5IHRvIGltcGxlbWVudC4gIFRoZSBsaXN0ZW5pbmcvY2xpZW50IHBlZXIgaXMgdmVyeSBlYXN5 Lg0KPiBUaGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSB3aXRoIHRoaW5ncyBsaWtlIEpldHR5IGNvbnRp bnVhdGlvbnMgd2hlcmUgeW91DQo+IGNhbiBzaXQgd2FpdGluZyBhbG1vc3QgaW5kZWZpbml0ZWx5 Lg0KPiANCj4gVGhlIGluaXRpYXRpbmcvc2VydmluZyBwZWVyIGNhbiBiZSBpbXBsZW1lbnRlZCBi eSByYW1taW5nIGFuIEhUVFANCj4gY2xpZW50IHRvZ2V0aGVyIHdpdGggYW4gSFRUUCBzZXJ2ZXIu ICBUaGUgSFRUUCBjbGllbnQgbWFrZXMgdGhlIGxvbmcNCj4gcG9sbHMuICBJZiBhIHJlc3BvbnNl IGNvbWVzIGJhY2sgd2l0aCBhbiBhcHBsaWNhdGlvbi9odHRwIGJvZHksIGl0DQo+IGV4dHJhY3Rz IHRoYXQgcmVzcG9uc2UgYW5kIHNlbmRzIHRoYXQgYXMgYSByZXF1ZXN0IHRvIHRoZSBIVFRQIHNl cnZlci4NCj4gVGhlIHJlc3BvbnNlIGZyb20gdGhlIEhUVFAgc2VydmVyIGlzIHNlbnQgdG8gdGhl IGxpc3RlbmluZy9jbGllbnQgcGVlcg0KPiBpbiB0aGUgbmV4dCByZXF1ZXN0Lg0KPiANCj4gfn5+ DQo+IA0KPiBJIGNhbid0IGhlbHAgYnV0IHRoaW5rIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcgbGlr ZSB3aGF0IE1hcmsgTm90dGluZ2hhbQ0KPiB3YXMgaGludGluZyBhdCB3aXRoIGhpcyBjb21tZW50 cyBhdCB0aGUgbWljIHRvZGF5Lg0KPiANCj4gTm8gZG91YnQgdGhlcmUgYXJlIGRyYXdiYWNrcywg YmVjYXVzZSB0aGlzIGlzIGFsbW9zdCB0b28gc2ltcGxlLiAgT2YNCj4gY291cnNlLCBpdCBpbmhl cml0cyBhIGdyZWF0IGRlYWwgb2YgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiBIVFRQLCBib3RoDQo+ IGdvb2QgYW5kIGJhZC4gIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBwaXBlbGluaW5nIHRoaW5n IGlzIGENCj4gc2hvd3N0b3BwZXIsIG9yIHdoZXRoZXIgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0 aGF0IEkndmUgbWlzc2VkLg0KPiANCj4gSSB0aG91Z2h0IGl0IHdvcnRoIHNoYXJpbmcsIGlmIG9u bHkgdG8gZW5yaWNoIHRoZSBkaXNjdXNzaW9uLg0KPiANCj4gRnJvbSBkZWVwIGluIHRoZSB0d2ls aWdodCB6b25lLA0KPiBNYXJ0aW4NCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVz aWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQo+IGNvbnRhaW4gcHJpdmlsZWdlZCwgcHJv cHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLg0KPiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+IGltbWVk aWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YN Cj4gdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IFttZjJdDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEFwcHMtRGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gQXBw cy1EaXNjdXNzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXBwcy1kaXNjdXNzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQg bWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0 ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwu ICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From eburger@standardstrack.com Tue Mar 24 02:43: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 4AD453A68E4 for ; Tue, 24 Mar 2009 02:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 PIQYK09na3kd for ; Tue, 24 Mar 2009 02:43:07 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 0E0F83A684C for ; Tue, 24 Mar 2009 02:43:07 -0700 (PDT) Received: from [130.129.69.204] (port=55037 helo=dhcp-45cc.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lm3Ap-0000oz-Uo; Tue, 24 Mar 2009 02:43:56 -0700 Message-Id: From: Eric Burger To: "Thomson, Martin" In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-44--264885500; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Strawman: PTTH Date: Tue, 24 Mar 2009 02:43:55 -0700 References: 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: 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, 24 Mar 2009 09:43:08 -0000 --Apple-Mail-44--264885500 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Again, this feels like (1) a research project and (2) a transport (NOT applications) problem. Yes, we are speaking about HTTP here. No, we are not talking about the application running on HTTP, but the transport of data. That is a transport, not applications, issue. On Mar 24, 2009, at 2:06 AM, Thomson, Martin wrote: > Folks, > > I've been interested in solving the HTTP problem discussed today for > quite some time. I've reviewed all the proposals reviewed. Two > things strike me: > > - BOSH and Bayeux both address the real problem. Namely: how this > works in the world that exists right now. They do this with long > polling. This is a good solution that we know works. rHTTP and > Websockets are new protocols that might work, but I have my > reservations. > > - BOSH and Bayeux seem to be way over-engineered. Channels and > sessions and all that stuff isn't HTTP - HTTP is, when you get right > down to it, pretty dumb. That's a virtue that is lost. > > I am truly surprised that no-one has suggested this particular idea, > so I'll do a brief description and hopefully I can then sleep. > > ~~~ > > ===PTTH; or HTTP, over easy (on this note, I'd like to find a nasty > backronym for PTTH, but Protocol That Tweaks/Twists/Turns HTTP kinda > sucks) > > A frighteningly simple idea: long polling + back-to-front HTTP > requests inside other HTTP requests. > > ==Terminology: > > Client and server can be misleading in this context. RFC 3080 deals > with this problem already - differentiating between connection > establishment and request/response exchanges. I'll borrow those > terms. > > Initiating Peer - the "classical" HTTP client, the peer that > establishes the TCP connection. > Listening Peer - the "classical" HTTP server, the peer that listens > for TCP connections. > Client Peer - the peer that is making PTTH requests (HTTP server) > Serving Peer - the peer that is serving PTTH requests (HTTP client) > > ==Overview of operation > > Application semantics establish the need for an HTTP peer to > establish a PTTH "session". A part of this includes a URI that the > application feeds to the initiating peer with the expectation that a > PTTH session is established. The initiating peer opens a connection > to the listening peer and sends an HTTP POST request: > > POST /ptth/path HTTP/1.1 > Host: server.name.example > Content-Length: 0 > > Long polling ensues. On timeout the listening peer sends an HTTP > response that doesn't contain an HTTP request, that response is > discarded by the initiating peer and a new, empty request is sent. > > If the client peer needs to send something it sends an HTTP response > that contains an HTTP request: > > HTTP/1.1 200 OK > Content-Type: application/http > Content-Length: ... > > GET /index.html HTTP/1.1 > Host: > > > The serving peer includes the response in the next request it > sends. This also serves as the means by which the next request > might be acquired: > > POST /ptth/path HTTP/1.1 > Host: server.name.example > Content-Type: application/http > Content-Length: ... > > HTTP/1.1 200 OK > Content-Type: application/xhtml+xml > > ...content... > > > ==Protocol pieces > > A new MIME type: application/http or some such to distinguish > message bodies. > > Possibly: an HTTP header that indicates that an HTTP request is an > initiating message. However, I consider it likely that this is not > actually necessary. The expectation is set by the application, and > the MIME-type is a further indication that this behaviour is desired. > > ==Limitations and things to look into further > > Pipelining is more or less impossible with this approach. Since a > response from the serving peer is expected on the next HTTP request > received by the client peer, the serving/initiating peer cannot > pipeline requests. This might need to be looked into if the problem > is considered as being worth solving. This is the only major > concern I've run into. > > Tuning the timeout is something that could be looked at, but this is > a problem that applies in general to all long-polling approaches. > > I haven't done a thorough check of HTTP headers, but I don't > actually think that there is any need for anything more complicated > than this. Listening peers might like to use Cache-Control: private > in responses to prevent caching, and so forth, but I don't actually > think that there is much more required here. Some headers are > pointless on the nested request, such as proxy authentication > headers or transfer-encoding, but - again - those are secondary > issues. I need to go through Lisa's mini using-http checklist > (BCP56bis) - there are probably other clues there as to what else > needs to be considered. > > ==Implementation > > This is easy to implement. The listening/client peer is very easy. > This is especially true with things like Jetty continuations where > you can sit waiting almost indefinitely. > > The initiating/serving peer can be implemented by ramming an HTTP > client together with an HTTP server. The HTTP client makes the long > polls. If a response comes back with an application/http body, it > extracts that response and sends that as a request to the HTTP > server. The response from the HTTP server is sent to the listening/ > client peer in the next request. > > ~~~ > > I can't help but think that this is something like what Mark > Nottingham was hinting at with his comments at the mic today. > > No doubt there are drawbacks, because this is almost too simple. Of > course, it inherits a great deal of the characteristics of HTTP, > both good and bad. I'm not sure whether the pipelining thing is a > showstopper, or whether there are other things that I've missed. > > I thought it worth sharing, if only to enrich the discussion. > > From deep in the twilight zone, > Martin > > > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-44--264885500 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjQwOTQzNTZaMCMGCSqGSIb3 DQEJBDEWBBRpPuvArHj+PW07OCUNcycXD9bgoDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBrOfLqZ0zSxtd6TnDHlSD0D0XveVMfWNh2zBALLso/E26f iIc2CL7J5pgecz86DpBrci7WNefpp1NS/jGPdcExk8jKesDaQlvgcDOUXJurbUybJXfHb8Yp9CZ5 uP8CfFFZFzjLBniknG1esYOR3jfncQNS+B8vKhtxpPOQkEhxVaq//BD+PJAEUZzOHIlHcaXve4Bm wMIcdYtP4naVirfcOHUfiFHl9rm3batgm68B/GxljIaXxO+VbpdtFYAxtIdZF3ir+olLhsjLRSJK Mn2xqrbnZTaxqTvOuh2C35DiCFmK/TMv3gyFpHeuhHDPGHfzD5hC1fzoSCtLtQb4nmHYAAAAAAAA --Apple-Mail-44--264885500-- From tonyg@lshift.net Tue Mar 24 06:37: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 9D2EF28C272 for ; Tue, 24 Mar 2009 06:37:18 -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 Ss5AQIE1iCZ4 for ; Tue, 24 Mar 2009 06:37:17 -0700 (PDT) Received: from agentk.lshift.net (host226.lshift.net [195.172.218.226]) by core3.amsl.com (Postfix) with ESMTP id 56AB028C14F for ; Tue, 24 Mar 2009 06:37:17 -0700 (PDT) Received: from shortstop.lshift.net ([10.224.189.87]) by agentk.lshift.net with esmtpsa (SSL 3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Lm6pB-0003b3-QJ; Tue, 24 Mar 2009 13:37:57 +0000 Message-ID: <49C8E22C.90005@lshift.net> Date: Tue, 24 Mar 2009 13:37:48 +0000 From: Tony Garnock-Jones User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: Strawman: PTTH References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Score: -1.4 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, 24 Mar 2009 13:37:18 -0000 Thomson, Martin wrote: > I am truly surprised that no-one has suggested this particular idea, so I'll do a brief description and hopefully I can then sleep. Check out http://www.reversehttp.net/reverse-http-spec.html. Abstract: "This document describes a dynamic, ReST-style means of enrolment and participation in an HTTP network. The message/http and application/http MIME types defined by RFC 2616 are used to build a dynamically-configurable "Remote CGI" service. "Joining the World Wide Web as an HTTP server has been an ad-hoc, manual process. By using the protocol defined here, programs can provide services to the Web just as easily as they request services from the Web." It's almost exactly what you describe. An implementation is available: http://www.reversehttp.net/download.html There are online demos of web-server-in-a-browser using it: http://www.reversehttp.net/demos/ Other demos of AMQP-style relaying and queueing are not yet polished enough for release, but are lurking the git repo for those curious enough. Regards, Tony -- [][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211 [][] LShift Ltd | Tel: +44 (0)20 7729 7060 [] [] http://www.lshift.net/ | Email: tonyg@lshift.net From tonyg@lshift.net Tue Mar 24 06:52: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 19E4128C28F for ; Tue, 24 Mar 2009 06:52:05 -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 mUa4Pe2PMWM4 for ; Tue, 24 Mar 2009 06:52:04 -0700 (PDT) Received: from agentk.lshift.net (host226.lshift.net [195.172.218.226]) by core3.amsl.com (Postfix) with ESMTP id F184028C289 for ; Tue, 24 Mar 2009 06:52:03 -0700 (PDT) Received: from shortstop.lshift.net ([10.224.189.87]) by agentk.lshift.net with esmtpsa (SSL 3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Lm73k-0003lv-M6; Tue, 24 Mar 2009 13:52:52 +0000 Message-ID: <49C8E5B4.2020103@lshift.net> Date: Tue, 24 Mar 2009 13:52:52 +0000 From: Tony Garnock-Jones User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Eric Burger Subject: Re: Strawman: PTTH References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Score: -1.4 Cc: apps-discuss@ietf.org, "Thomson, Martin" 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, 24 Mar 2009 13:52:05 -0000 Eric Burger wrote: > Again, this feels like (1) a research project and (2) a transport (NOT > applications) problem. Yes, we are speaking about HTTP here. No, we are > not talking about the application running on HTTP, but the transport of > data. That is a transport, not applications, issue. You have a point. I think there are two important issues being addressed here, one a transport issue and one an applications issue. The issues, as I see them: (1) - Given that a program wants to provide HTTP services to the world, how does it do so? (TRANSPORT) (2) - Once a program can both issue *and respond to* HTTP requests, without undue effort, what kinds of new applications arise? (APPLICATIONS) Reverse HTTP in all its forms -- the Upgrade-header based one and the JSON encoding of HTTP that Lentczner and Preston have been working with, as well as the message/http-based one that Martin Thompson proposed just before and that I've been working with for a while -- solves a very low-level issue: how to get HTTP requests out from, and HTTP responses in to, a Point Of Attachment for an *HTTP* network. The spec I linked to in my previous message also addresses a closely related issue: *enrolment* in an HTTP network; that is, how the rHTTP service is assigned a portion of URL-space that it is responsible for. One might think of this aspect of it as providing a win equivalent to that given by DHCP when compared to static configuration of IP addresses. Using the enrolment protocol I describe allows a form of address autoconfiguration for HTTP networks that to my knowledge doesn't exist anywhere else yet. The alternative, the status quo, is equivalent to static IP address assignment: the manual DNS and firewall configuration, the manual installation of apache or equivalent. So, given all that: is this the right forum for discussion of rHTTP and friends? Regards, Tony -- [][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211 [][] LShift Ltd | Tel: +44 (0)20 7729 7060 [] [] http://www.lshift.net/ | Email: tonyg@lshift.net From mark@coactus.com Tue Mar 24 07:29: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 C816A28C10B for ; Tue, 24 Mar 2009 07:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.827 X-Spam-Level: X-Spam-Status: No, score=-100.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TRNFER=2.3, 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 zYJsMi-+E0hF for ; Tue, 24 Mar 2009 07:29:19 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 31CA63A6A56 for ; Tue, 24 Mar 2009 07:29:17 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so4063083ywh.49 for ; Tue, 24 Mar 2009 07:30:08 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.151.6.15 with SMTP id j15mr15111977ybi.65.1237905008645; Tue, 24 Mar 2009 07:30:08 -0700 (PDT) Date: Tue, 24 Mar 2009 07:30:08 -0700 X-Google-Sender-Auth: eeed498d2fec3c9e Message-ID: Subject: Application or transport? From: Mark Baker To: Eric Burger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, "Thomson, Martin" 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, 24 Mar 2009 14:29:19 -0000 Eric, 2009/3/24 Eric Burger : > Again, this feels like (1) a research project and (2) a transport (NOT > applications) problem. =A0Yes, we are speaking about HTTP here. No, we ar= e not > talking about the application running on HTTP, Of course, but neither are we talking about that application when we call HTTP an application protocol. > but the transport of data. > =A0That is a transport, not applications, issue. No, this is about the trans*fer* of data. Requests and responses are application layer concepts. Mark. From salvatore.loreto@ericsson.com Tue Mar 24 08:12: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 E943E28C272 for ; Tue, 24 Mar 2009 08:12:54 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=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 s9PuxOSfMRFH for ; Tue, 24 Mar 2009 08:12:54 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2EB6D28C2C2 for ; Tue, 24 Mar 2009 08:12:50 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB0B520B1E; Tue, 24 Mar 2009 16:13:39 +0100 (CET) X-AuditID: c1b4fb3c-acf5dbb000003f6e-80-49c8f8a3a698 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 89D20207C9; Tue, 24 Mar 2009 16:13:39 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 16:13:38 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 16:13:38 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 823D7245D; Tue, 24 Mar 2009 17:13:38 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 47922219E5; Tue, 24 Mar 2009 17:13:38 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 070EC219D0; Tue, 24 Mar 2009 17:13:36 +0200 (EET) Message-ID: <49C8F8A0.1070702@ericsson.com> Date: Tue, 24 Mar 2009 17:13:36 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Tony Garnock-Jones Subject: Re: Strawman: PTTH References: <49C8E5B4.2020103@lshift.net> In-Reply-To: <49C8E5B4.2020103@lshift.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 24 Mar 2009 15:13:38.0646 (UTC) FILETIME=[1BFC4F60:01C9AC93] X-Brightmail-Tracker: AAAAAA== Cc: apps-discuss@ietf.org, "Thomson, Martin" 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, 24 Mar 2009 15:12:55 -0000 I would tend to agree that the websocket proposal is more a transport issue that an application one: it try to solve the problem of how to open a socket in a Web Browser or generally in a Web environment using HTTP, but the other one are all about how to transport data, in both the direction, using HTTP that means using HTTP as a transport Sal Tony Garnock-Jones wrote: > Eric Burger wrote: > >> Again, this feels like (1) a research project and (2) a transport (NOT >> applications) problem. Yes, we are speaking about HTTP here. No, we are >> not talking about the application running on HTTP, but the transport of >> data. That is a transport, not applications, issue. >> > > You have a point. I think there are two important issues being addressed > here, one a transport issue and one an applications issue. > > The issues, as I see them: > > (1) - Given that a program wants to provide HTTP services to the world, > how does it do so? (TRANSPORT) > > (2) - Once a program can both issue *and respond to* HTTP requests, > without undue effort, what kinds of new applications arise? > (APPLICATIONS) > > Reverse HTTP in all its forms -- the Upgrade-header based one and the > JSON encoding of HTTP that Lentczner and Preston have been working with, > as well as the message/http-based one that Martin Thompson proposed just > before and that I've been working with for a while -- solves a very > low-level issue: how to get HTTP requests out from, and HTTP responses > in to, a Point Of Attachment for an *HTTP* network. > > The spec I linked to in my previous message also addresses a closely > related issue: *enrolment* in an HTTP network; that is, how the rHTTP > service is assigned a portion of URL-space that it is responsible for. > One might think of this aspect of it as providing a win equivalent to > that given by DHCP when compared to static configuration of IP > addresses. Using the enrolment protocol I describe allows a form of > address autoconfiguration for HTTP networks that to my knowledge doesn't > exist anywhere else yet. The alternative, the status quo, is equivalent > to static IP address assignment: the manual DNS and firewall > configuration, the manual installation of apache or equivalent. > > So, given all that: is this the right forum for discussion of rHTTP and > friends? > > Regards, > Tony > From connolly@w3.org Mon Mar 23 09:12: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 2D1C228C15F for ; Mon, 23 Mar 2009 09:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 v3ns0NqRROs8 for ; Mon, 23 Mar 2009 09:12:08 -0700 (PDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 30A2E28C154 for ; Mon, 23 Mar 2009 09:12:08 -0700 (PDT) Received: from dhcp-129b.meeting.ietf.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 94FD54EF2F; Mon, 23 Mar 2009 12:12:57 -0400 (EDT) Message-ID: <49C7B50C.7040709@w3.org> Date: Mon, 23 Mar 2009 09:13:00 -0700 From: Dan Connolly User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: uri@w3.org, apps-discuss@ietf.org Subject: "Web Addresses in HTML 5", URIs, URLs, IRIs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Mar 2009 11:10:55 -0700 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, 23 Mar 2009 16:12:09 -0000 This was, until recently, part of the HTML 5 spec. It's been suggested that it applies beyond HTML 5, e.g. XMLHTTPRequest, and perhaps Jabber etc. Web addresses in HTML 5 Editor's Draft 20 March 2009 Editors: Dan Connolly, Midwest Web Sense LLC and W3C C. M. Sperberg-McQueen, Black Mesa Technologies LLC Abstract This specification defines the handling of Web addresses for Hypertext Markup Language (HTML) 5, the fifth major revision of the core language of the World Wide Web. In this version, special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability. Publication mechanics are a little goofy at this point; the 20 March draft is available at: http://homer.w3.org/~connolly/projects/urlp/raw-file/008373680cae/wah5/draft.html The 17 March draft is available attached to... "Web addresses in HTML 5" for review (ISSUE-56 urls-webarch) Dan Connolly (Wednesday, 18 March) http://lists.w3.org/Archives/Public/public-html/2009Mar/0444.html -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ From annevk@opera.com Mon Mar 23 09:56: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 061A228C1D2 for ; Mon, 23 Mar 2009 09:56:50 -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 KDsVOF8wAuUR for ; Mon, 23 Mar 2009 09:56:49 -0700 (PDT) Received: from smtp.opera.com (sam.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id CC99728C1DC for ; Mon, 23 Mar 2009 09:56:48 -0700 (PDT) Received: from annevk-t60.oslo.opera.com (ip4da3f3cb.direct-adsl.nl.0.163.77.in-addr.arpa [77.163.243.203] (may be forged)) (authenticated bits=0) by smtp.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n2NGvY2T017666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Mar 2009 16:57:35 GMT Date: Mon, 23 Mar 2009 17:57:31 +0100 To: "Dan Connolly" , uri@w3.org, apps-discuss@ietf.org Subject: Re: "Web Addresses in HTML 5", URIs, URLs, IRIs From: "Anne van Kesteren" Organization: Opera Software ASA Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <49C7B50C.7040709@w3.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <49C7B50C.7040709@w3.org> User-Agent: Opera Mail/9.62 (Linux) X-Mailman-Approved-At: Tue, 24 Mar 2009 11:10:55 -0700 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, 23 Mar 2009 16:56:50 -0000 On Mon, 23 Mar 2009 17:13:00 +0100, Dan Connolly wrote: > This was, until recently, part of the HTML 5 spec. It's > been suggested that it applies beyond HTML 5, e.g. XMLHTTPRequest, > and perhaps Jabber etc. I think this can address the longstanding issue for url() in CSS as well. I have a feeling the algorithm is also used for HTTP (though with a more limited input of course) as browsers handle spaces and other incorrect characters "fine" in e.g. the Location header. -- Anne van Kesteren http://annevankesteren.nl/ From connolly@w3.org Mon Mar 23 10:29: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 3E1373A6A05 for ; Mon, 23 Mar 2009 10:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.995 X-Spam-Level: X-Spam-Status: No, score=-9.995 tagged_above=-999 required=5 tests=[AWL=0.604, 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 ByopQvl-O98g for ; Mon, 23 Mar 2009 10:29:30 -0700 (PDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 771E43A67E2 for ; Mon, 23 Mar 2009 10:29:30 -0700 (PDT) Received: from dhcp-129b.meeting.ietf.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id DA5FE4EED7; Mon, 23 Mar 2009 13:30:19 -0400 (EDT) Message-ID: <49C7C72D.2070202@w3.org> Date: Mon, 23 Mar 2009 10:30:21 -0700 From: Dan Connolly User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: "Web Addresses in HTML 5", URIs, URLs, IRIs References: <49C7B50C.7040709@w3.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Mar 2009 11:10:55 -0700 Cc: uri@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: Mon, 23 Mar 2009 17:29:31 -0000 Mark Nottingham wrote: > Hi Dan, > > What's the intended venue and status for this work (if known)? Not known. I suppose the purpose of my message is to research the optimal venue and status. It was published Feb 2009 in the W3C Recommendation track as part of HTML 5 http://www.w3.org/TR/2009/WD-html5-20090212/infrastructure.html#urls but it's not at all clear that people with expertise in URIs are likely to discover it under the title "HTML 5". So I'm here at the IETF (in person and on apps-discuss) trying figure out who is interested to participate and what venue(s) would work well/best. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ From lisa.dusseault@gmail.com Tue Mar 24 11:16: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 B890028C299 for ; Tue, 24 Mar 2009 11:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 wHtnMju3+Gjl for ; Tue, 24 Mar 2009 11:16:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 1D15228C26B for ; Tue, 24 Mar 2009 11:16:34 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2333878rvb.49 for ; Tue, 24 Mar 2009 11:17:25 -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=woqo5Ws1Jmkgd7HQaxsUmLyU0UYABk8+knVKSfu0un8=; b=iEiLlVfBGORUlWbm9vlSA7eS9pDlXFIPIj+ZCVpKlFMGS4rQ51KE0q666y/uSGwsri xJjKLG1maupkcwKoBwUB3tRnTuMrGNSD2cmsyCGVpAiSNgwLfpoDHqY7LSW05HWb2j4Y ull0kcINeJ22ZTlRDkiyoVuG88ThXMudO+CYk= 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=uasTPm9rxZFxhIQhWYgLwW7QeJWdehcNjtVPS6vVorlioTTEeJ7GssjAPQXze39YOT TO2+n1O1340XrovFuWXlJigZDaErAUBcm3SFj5F6AKC0byxbV3jPzceI4gbdz9N1k8kz /MyMDf6OREen8I66l44JfNeQulUaJFbcAZFRo= MIME-Version: 1.0 Received: by 10.140.157.1 with SMTP id f1mr3057974rve.196.1237918645417; Tue, 24 Mar 2009 11:17:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2009 11:17:25 -0700 Message-ID: Subject: Re: Strawman: PTTH From: Lisa Dusseault To: Eric Burger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, "Thomson, Martin" 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, 24 Mar 2009 18:16:34 -0000 2009/3/24 Eric Burger : > Again, this feels like (1) a research project and (2) a transport (NOT > applications) problem. =A0Yes, we are speaking about HTTP here. No, we ar= e not > talking about the application running on HTTP, but the transport of data. > =A0That is a transport, not applications, issue. 1. It really is not a research project. At least three different systems are deployed and working and have been for a while. 2. It really belongs in APPS, not because of an increasingly-inaccurate layering model for areas, but because APPS area collects HTTP experts. Lisa From stpeter@stpeter.im Tue Mar 24 13:50: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 B87DC28C2F8 for ; Tue, 24 Mar 2009 13:50:40 -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 c9D+qmAyDoXQ for ; Tue, 24 Mar 2009 13:50:39 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 6C7E828C11B for ; Tue, 24 Mar 2009 13:50:39 -0700 (PDT) Received: from squire.local (unknown [171.69.125.87]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 9F826E8002 for ; Tue, 24 Mar 2009 14:51:30 -0600 (MDT) Message-ID: <49C947D2.4000609@stpeter.im> Date: Tue, 24 Mar 2009 13:51:30 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: HyBi breakfast BOF? 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="------------ms070508070403030903000803" 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, 24 Mar 2009 20:50:40 -0000 This is a cryptographically signed message in MIME format. --------------ms070508070403030903000803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I think it might be helpful to hold an informal birds of a feather about what I'm calling "Hypertext Bidirectional" (HyBi for short, other catchy acronyms are welcome!). Unfortunately I need to depart mid-day tomorrow so I'm wondering if perhaps we can hold a breakfast BOF, say at 7:30 or 8:00 Wednesday morning? Depending on how many people indicate interest we could go to Lori's Diner (their biggest table seats 8) or someplace with a bit more space. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070508070403030903000803 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 DQEJBTEPFw0wOTAzMjQyMDUxMzBaMCMGCSqGSIb3DQEJBDEWBBSYJFhHWbroRiSHXb2uDuCe ZPtKrTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAkAoiEoNQ14yFF+0XkshbYnzw2eu/9/Gw6v30TjTMmjHKHWIlOfoU+2R36V+B 0/7EGxRondfWeJTw0NqEsysflJ+pm+G680V3+TeUf8TIPpx64MBsVQYCjCI1nR8b/+6u4t7v 606TCd8WdXVNfyePdU+R6qa/+Xq9XDXqqwGP+xKHTMvEXL5JJ488nqU2uzDMMkjfBFPsvVB1 zzGRG7ncEsuVOv4T1kaCM8xnQ1aA1cRk0UnIiC0z1AAbSONT/mFbTtIo33RwQyTYopLDUein x9NE6KIk1CHIme2uwB5ZSgNuZnUTq2cMdeahcPHUMVt7jCkL7oCp7RZtiFdYmycTJAAAAAAA AA== --------------ms070508070403030903000803-- From eburger@standardstrack.com Tue Mar 24 13:56: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 A97AD3A6BFF for ; Tue, 24 Mar 2009 13:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, 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 fI7zdMTgYO0L for ; Tue, 24 Mar 2009 13:56:04 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 95DB53A6B1E for ; Tue, 24 Mar 2009 13:56:04 -0700 (PDT) Received: from [130.129.87.195] (port=59265 helo=dhcp-57c3.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LmDg1-0002o1-Hs; Tue, 24 Mar 2009 13:56:49 -0700 Message-Id: From: Eric Burger To: Lisa Dusseault In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-94--224505803; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Strawman: PTTH Date: Tue, 24 Mar 2009 13:56:55 -0700 References: 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: 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, 24 Mar 2009 20:56:05 -0000 --Apple-Mail-94--224505803 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Compromise? If we do do something, can we have a TSV expert assigned to the group, just as we have Security Experts assigned to a group? On Mar 24, 2009, at 11:17 AM, Lisa Dusseault wrote: > 2009/3/24 Eric Burger : >> Again, this feels like (1) a research project and (2) a transport >> (NOT >> applications) problem. Yes, we are speaking about HTTP here. No, >> we are not >> talking about the application running on HTTP, but the transport of >> data. >> That is a transport, not applications, issue. > > 1. It really is not a research project. At least three different > systems are deployed and working and have been for a while. > > 2. It really belongs in APPS, not because of an > increasingly-inaccurate layering model for areas, but because APPS > area collects HTTP experts. > > Lisa --Apple-Mail-94--224505803 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjQyMDU2NTVaMCMGCSqGSIb3 DQEJBDEWBBQbVma2AZ8nq9WEoYlC8rr1t+rvnTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQAnzfbizKC+3mOjIHNsYOxNOnHUaWMBkV96CN/HNM5yqcUe ul/L8UL40TKRcPdG79DV9AiJ+xdmTR9pTu76BgH9is7TRShS8vBsBPTECuDLm+ST1SgytAVMagay q6zNIWRjmKP/SMKeNWQ9BuY62lhBd42lL3NZkg0Ft97/R/3p//fpEbkCDaXmhR8KjAqsLE6mP2WV VzPcMb4gxTdRv4H3KU6NmJ9Hbc7HiaULyP0Tl7f/7BqPkbJD2JRKvSNyNdTCulquwOQ/T7ab4NC+ sE7dnyemDgRzMihmooa+2bSDflWZxnfX5Ut3nqxdTKuMMHWR9VyK8JV+mNZXFXE6LjGuAAAAAAAA --Apple-Mail-94--224505803-- From salvatore.loreto@ericsson.com Tue Mar 24 13:58:20 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 668E83A6C68 for ; Tue, 24 Mar 2009 13:58:20 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=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 3KhzA90e+S7T for ; Tue, 24 Mar 2009 13:58:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 42DF93A6989 for ; Tue, 24 Mar 2009 13:58:19 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6983520CE7; Tue, 24 Mar 2009 21:59:09 +0100 (CET) X-AuditID: c1b4fb3c-acf5dbb000003f6e-ec-49c9499dd442 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3C03F20831; Tue, 24 Mar 2009 21:59:09 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 21:59:08 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 21:59:08 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 93B6223F6; Tue, 24 Mar 2009 22:59:08 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5E529219E5; Tue, 24 Mar 2009 22:59:08 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 55B5A219E4; Tue, 24 Mar 2009 22:59:07 +0200 (EET) Message-ID: <49C9499A.3030308@ericsson.com> Date: Tue, 24 Mar 2009 22:59:06 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Eric Burger Subject: Re: Strawman: PTTH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 24 Mar 2009 20:59:08.0707 (UTC) FILETIME=[60109730:01C9ACC3] X-Brightmail-Tracker: AAAAAA== 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, 24 Mar 2009 20:58:20 -0000 good idea/compromise ! /Sal Eric Burger wrote: > Compromise? If we do do something, can we have a TSV expert assigned > to the group, just as we have Security Experts assigned to a group? > > On Mar 24, 2009, at 11:17 AM, Lisa Dusseault wrote: > >> 2009/3/24 Eric Burger : >>> Again, this feels like (1) a research project and (2) a transport (NOT >>> applications) problem. Yes, we are speaking about HTTP here. No, we >>> are not >>> talking about the application running on HTTP, but the transport of >>> data. >>> That is a transport, not applications, issue. >> >> 1. It really is not a research project. At least three different >> systems are deployed and working and have been for a while. >> >> 2. It really belongs in APPS, not because of an >> increasingly-inaccurate layering model for areas, but because APPS >> area collects HTTP experts. >> >> Lisa > > ------------------------------------------------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From salvatore.loreto@ericsson.com Tue Mar 24 15:00: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 20A0A3A6A78 for ; Tue, 24 Mar 2009 15:00:17 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=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 CdiTWr7uGe91 for ; Tue, 24 Mar 2009 15:00:16 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 484F53A6991 for ; Tue, 24 Mar 2009 15:00:16 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AF9C8204D3; Tue, 24 Mar 2009 23:01:06 +0100 (CET) X-AuditID: c1b4fb3e-aafb3bb000006d6d-73-49c9582293ed Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 95C0220026; Tue, 24 Mar 2009 23:01:06 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 23:01:06 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 23:01:05 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BD4AE245B; Wed, 25 Mar 2009 00:01:05 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 88BBC219E5; Wed, 25 Mar 2009 00:01:05 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A5A78219D0; Wed, 25 Mar 2009 00:01:04 +0200 (EET) Message-ID: <49C9581E.6010000@ericsson.com> Date: Wed, 25 Mar 2009 00:01:02 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: HyBi breakfast BOF? References: <49C947D2.4000609@stpeter.im> In-Reply-To: <49C947D2.4000609@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 24 Mar 2009 22:01:05.0647 (UTC) FILETIME=[07889FF0:01C9ACCC] X-Brightmail-Tracker: AAAAAA== 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, 24 Mar 2009 22:00:17 -0000 great idea, I am interested /Sal Peter Saint-Andre wrote: > I think it might be helpful to hold an informal birds of a feather about > what I'm calling "Hypertext Bidirectional" (HyBi for short, other catchy > acronyms are welcome!). Unfortunately I need to depart mid-day tomorrow > so I'm wondering if perhaps we can hold a breakfast BOF, say at 7:30 or > 8:00 Wednesday morning? Depending on how many people indicate interest > we could go to Lori's Diner (their biggest table seats 8) or someplace > with a bit more space. > > Peter > > > ------------------------------------------------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From lisa.dusseault@gmail.com Tue Mar 24 15:47: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 BEB723A68D3 for ; Tue, 24 Mar 2009 15:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 MVECUhyKGG1I for ; Tue, 24 Mar 2009 15:47:32 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id DA49E3A68B1 for ; Tue, 24 Mar 2009 15:47:31 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2429717rvb.49 for ; Tue, 24 Mar 2009 15:48:23 -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=AfhwSKWcVK/8H72sYA6ap/jSTbR7kWGRLOdhiI2rS4g=; b=M9PwcoSf8L74qF9WdYnqMV0ABZJEpmFTi4JZyZjNdhv+MvE5Dj9Y5fdIWvLjw4FF2C 2FnVQbNTTA5Ti2bpKsgeSNnsfKOx2e0e7Mzv7X8UVy+p1L5KA/J4ooZUvxNi66BxBFjs WGK1hvp5+H21A/e6kTOTRIYrnuedyI2kwVJJE= 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=W58YVL/0tMKVH2pk+E+0CmGh6s393RHMpqbWG6FnaDf2tq1P7yBkrMWbuYflchDvDS QG+hKLp1J3vOAnOl0etT4p+ZGulwSfmxEeX/mpQmqLPBHGrZVY+MiYhil6qkEAZuE8Vr ckttV7bhQnthgiUytJTqlTjYqHXnOGqrb4C4M= MIME-Version: 1.0 Received: by 10.141.145.11 with SMTP id x11mr3175979rvn.236.1237934903180; Tue, 24 Mar 2009 15:48:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2009 15:48:23 -0700 Message-ID: Subject: Re: Strawman: PTTH From: Lisa Dusseault To: Eric Burger Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 24 Mar 2009 22:47:32 -0000 You bet! Lisa On Tue, Mar 24, 2009 at 1:56 PM, Eric Burger w= rote: > Compromise? =A0If we do do something, can we have a TSV expert assigned t= o the > group, just as we have Security Experts assigned to a group? > > On Mar 24, 2009, at 11:17 AM, Lisa Dusseault wrote: > >> 2009/3/24 Eric Burger : >>> >>> Again, this feels like (1) a research project and (2) a transport (NOT >>> applications) problem. =A0Yes, we are speaking about HTTP here. No, we = are >>> not >>> talking about the application running on HTTP, but the transport of dat= a. >>> =A0That is a transport, not applications, issue. >> >> 1. =A0It really is not a research project. =A0At least three different >> systems are deployed and working and have been for a while. >> >> 2. =A0It really belongs in APPS, not because of an >> increasingly-inaccurate layering model for areas, but because APPS >> area collects HTTP experts. >> >> Lisa > > From alexey.melnikov@isode.com Tue Mar 24 17:51: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 7E8263A69E1 for ; Tue, 24 Mar 2009 17:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 JKVUgi7AOtYN for ; Tue, 24 Mar 2009 17:51:56 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B270F3A6880 for ; Tue, 24 Mar 2009 17:51:56 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 25 Mar 2009 00:52:47 +0000 Message-ID: <49C98049.5090408@isode.com> Date: Tue, 24 Mar 2009 17:52:25 -0700 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: Peter Saint-Andre Subject: Re: HyBi breakfast BOF? References: <49C947D2.4000609@stpeter.im> In-Reply-To: <49C947D2.4000609@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed 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, 25 Mar 2009 00:51:57 -0000 Peter Saint-Andre wrote: >I think it might be helpful to hold an informal birds of a feather about >what I'm calling "Hypertext Bidirectional" (HyBi for short, other catchy >acronyms are welcome!). Unfortunately I need to depart mid-day tomorrow >so I'm wondering if perhaps we can hold a breakfast BOF, say at 7:30 or >8:00 Wednesday morning? Depending on how many people indicate interest >we could go to Lori's Diner (their biggest table seats 8) or someplace >with a bit more space. > I will come to this. Should we meet 7:15 in the Hilton lobby? From stpeter@stpeter.im Tue Mar 24 18:03:11 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 BFF983A6A88 for ; Tue, 24 Mar 2009 18:03:11 -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 agd6ezDGFpbh for ; Tue, 24 Mar 2009 18:03:11 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 058403A695D for ; Tue, 24 Mar 2009 18:02:58 -0700 (PDT) Received: from squire.local (unknown [171.69.125.87]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 4FC6EE8002; Tue, 24 Mar 2009 19:03:49 -0600 (MDT) Message-ID: <49C982F4.1030209@stpeter.im> Date: Tue, 24 Mar 2009 18:03:48 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: HyBi breakfast BOF? References: <49C947D2.4000609@stpeter.im> <49C98049.5090408@isode.com> In-Reply-To: <49C98049.5090408@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="------------ms020305060609030507010300" 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, 25 Mar 2009 01:03:11 -0000 This is a cryptographically signed message in MIME format. --------------ms020305060609030507010300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/24/09 5:52 PM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> I think it might be helpful to hold an informal birds of a feather about >> what I'm calling "Hypertext Bidirectional" (HyBi for short, other catchy >> acronyms are welcome!). Unfortunately I need to depart mid-day tomorrow >> so I'm wondering if perhaps we can hold a breakfast BOF, say at 7:30 or >> 8:00 Wednesday morning? Depending on how many people indicate interest >> we could go to Lori's Diner (their biggest table seats 8) or someplace >> with a bit more space. >> > I will come to this. Should we meet 7:15 in the Hilton lobby? How about 7:30? 7:15 feels a bit early to me. :) Depending on how many people appear, we can decide whether to eat at the Hilton or go around the corner. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms020305060609030507010300 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 DQEJBTEPFw0wOTAzMjUwMTAzNDhaMCMGCSqGSIb3DQEJBDEWBBQa8SG/CXH8D1EJafsE2Dkx JJdXPjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAdC61K7Qip/oQS+IYcPUztBGbBYGV4ryXnfGIBadmDynVq/doLWkD+vlzU+gP J0ti7XWpTHlrqtguZC7xh4qq2hNQuxRCNfDpaHgrQwBQDKgMUyWoYmHjqU8lZWB2Iwth8Kt/ VMd5XIaZlm3HGuR4AgPZVnAezkYFMutCIwa2hfeDHDdqqQu2Ldzz/oC5IUpqTjj0B7WqG6JX wDYnqb6D91awx6PHwYLxt6IedUdZQhMtTzUGX8ILttToWuk56BavrX+QVMjzpfLVo5P4R0+8 5jforG2B/sTVdV1rbs/F3UqOz1hulf9qxhst1WihpiUaA9DCqHv05H26r/yp+dB8cQAAAAAA AA== --------------ms020305060609030507010300-- From alexey.melnikov@isode.com Tue Mar 24 18:06: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 025F33A695D for ; Tue, 24 Mar 2009 18:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 VaEyR7pstbXM for ; Tue, 24 Mar 2009 18:06:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1EF4F3A68A7 for ; Tue, 24 Mar 2009 18:06:21 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 25 Mar 2009 01:07:11 +0000 Message-ID: <49C983AA.1090305@isode.com> Date: Tue, 24 Mar 2009 18:06:50 -0700 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: Peter Saint-Andre Subject: Re: HyBi breakfast BOF? References: <49C947D2.4000609@stpeter.im> <49C98049.5090408@isode.com> <49C982F4.1030209@stpeter.im> In-Reply-To: <49C982F4.1030209@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed 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, 25 Mar 2009 01:06:22 -0000 Peter Saint-Andre wrote: >On 3/24/09 5:52 PM, Alexey Melnikov wrote: > > >>Peter Saint-Andre wrote: >> >> >>>I think it might be helpful to hold an informal birds of a feather about >>>what I'm calling "Hypertext Bidirectional" (HyBi for short, other catchy >>>acronyms are welcome!). Unfortunately I need to depart mid-day tomorrow >>>so I'm wondering if perhaps we can hold a breakfast BOF, say at 7:30 or >>>8:00 Wednesday morning? Depending on how many people indicate interest >>>we could go to Lori's Diner (their biggest table seats 8) or someplace >>>with a bit more space. >>> >>> >>I will come to this. Should we meet 7:15 in the Hilton lobby? >> >> >How about 7:30? 7:15 feels a bit early to me. :) Depending on how many >people appear, we can decide whether to eat at the Hilton or go around >the corner. > > 9:00am would be even better, but unfortunately I have a meeting to attend ;-). So yes, 7:30am in the lobby is fine. From stpeter@stpeter.im Tue Mar 24 23:03:12 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 C105F3A6359 for ; Tue, 24 Mar 2009 23:03:12 -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 0-2c3LAk8wly for ; Tue, 24 Mar 2009 23:03:12 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 7B91B3A6C25 for ; Tue, 24 Mar 2009 23:03:08 -0700 (PDT) Received: from dhcp-11ba.meeting.ietf.org (dhcp-11ba.meeting.ietf.org [130.129.17.186]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id BBE25E8002; Wed, 25 Mar 2009 00:03:59 -0600 (MDT) Message-ID: <49C9C93D.5000904@stpeter.im> Date: Tue, 24 Mar 2009 23:03:41 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: HyBi breakfast BOF? References: <49C947D2.4000609@stpeter.im> <49C98049.5090408@isode.com> <49C982F4.1030209@stpeter.im> <49C983AA.1090305@isode.com> In-Reply-To: <49C983AA.1090305@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="------------ms070205080402010106000200" 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, 25 Mar 2009 06:03:12 -0000 This is a cryptographically signed message in MIME format. --------------ms070205080402010106000200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/24/09 6:06 PM, Alexey Melnikov wrote: > 9:00am would be even better, but unfortunately I have a meeting to > attend ;-). > So yes, 7:30am in the lobby is fine. OK, see you all then. :) Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070205080402010106000200 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 DQEJBTEPFw0wOTAzMjUwNjAzNDFaMCMGCSqGSIb3DQEJBDEWBBQHlLZuqbPLc4cSGz5WAezP mtn7wDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAgeBKrWQ8rtRs9bIzs8bW3dLSger3cN4wYB3ZHP56qnWqFoNjkE4xApc3gTgH DewoDss0z22qGlyVgUodF3rACO/mA+TMDAQv/S44PQj2DKcvkIppBtbFFoYoDlPMHAy0yiXd 9B57Q4z/AFeNWvZfpNsGxx8PPljVb0+iioG0FOmDx3h/JEH2wLMbCZpEfCwypIZ95K1BA3M+ v//5v89bWvvpqaNPf9YJzKHIMYdui0R1WmiUz7XA7vVixY2NHvdoDYi26K1SlbYPUF0sWFN6 9bq5umOyxp2CeKS7lBNBKqw+6otJu5G2wfPxF8UeSTGHP0mDW0sCra7ew4FyIk7SSwAAAAAA AA== --------------ms070205080402010106000200-- From eburger@standardstrack.com Wed Mar 25 07:12: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 5D8BC3A6B16 for ; Wed, 25 Mar 2009 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 eJYTdvZ0wqpm for ; Wed, 25 Mar 2009 07:12:01 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 810293A68B8 for ; Wed, 25 Mar 2009 07:12:01 -0700 (PDT) Received: from [130.129.69.204] (port=63454 helo=dhcp-45cc.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LmTqc-00039e-4H; Wed, 25 Mar 2009 07:12:50 -0700 Message-Id: <550CE632-955A-4899-A978-221F1F5D714C@standardstrack.com> From: Eric Burger To: Peter Saint-Andre In-Reply-To: <49C9C93D.5000904@stpeter.im> Content-Type: multipart/signed; boundary=Apple-Mail-126--162348413; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: HyBi breakfast BOF? Date: Wed, 25 Mar 2009 07:12:52 -0700 References: <49C947D2.4000609@stpeter.im> <49C98049.5090408@isode.com> <49C982F4.1030209@stpeter.im> <49C983AA.1090305@isode.com> <49C9C93D.5000904@stpeter.im> 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: 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, 25 Mar 2009 14:12:02 -0000 --Apple-Mail-126--162348413 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Let me know how it goes. I have another Ad Hoc this morning :-( On Mar 24, 2009, at 11:03 PM, Peter Saint-Andre wrote: > On 3/24/09 6:06 PM, Alexey Melnikov wrote: > >> 9:00am would be even better, but unfortunately I have a meeting to >> attend ;-). >> So yes, 7:30am in the lobby is fine. > > OK, see you all then. :) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-126--162348413 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjUxNDEyNTNaMCMGCSqGSIb3 DQEJBDEWBBSBX4Qth1VCl95Mn3dcnrTcWbz1DjCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQAMqlkGMUPkugA+G8wzdqlRLpRpmNt4kgtogYv9yHqfyOv5 I6MAbXSK31/IqwhXiDmr1c8SpV05rfV1AMpOPKRzI11sziPs5I9kVHlOVNWBdpZFE3bRTTyg939V z3URJP2weGy9MyMC4J4O7QIoDm+ffjCYFTR0rOWCVhrJU9PJScDWKz9H6FVoUkYb6QuCma7a9FUB vhfuFyLNL22/7PGxs0AUj3QMAIek65kzgEEZw4eM98KHnRDroC3rQYD+H+/o8wyWmpDaBLNp4fqC dj27Z/3XekY73v1v55TSQo1Wx+hJ+Z0BnMVqg8gZJ3X+zTEabhkun+WaALBOe4bxzNiqAAAAAAAA --Apple-Mail-126--162348413-- From Jeff.Hodges@KingsMountain.com Wed Mar 25 10:13:12 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 A2EEA3A6D63 for ; Wed, 25 Mar 2009 10:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 bGbEFcwt0OrR for ; Wed, 25 Mar 2009 10:13:11 -0700 (PDT) Received: from outbound-mail-28.bluehost.com (outbound-mail-28.bluehost.com [69.89.17.198]) by core3.amsl.com (Postfix) with SMTP id F19323A69C9 for ; Wed, 25 Mar 2009 10:12:43 -0700 (PDT) Received: (qmail 27412 invoked by uid 0); 25 Mar 2009 16:13:29 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by outboundproxy2.bluehost.com with SMTP; 25 Mar 2009 16:13:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=b5EAbPOwdOS0lfXzZzncjAn/3gRvkLwzv3sA2oyiLg8yg1IO5sB/XUNrSA9M9LNH/Mk2e/kpw30U20frdVeZuy+2PwwHJWAN2zHQSeYLkyJePfdAk4YI3lODmyNHiHgt; Received: from [130.129.87.201] by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LmWfY-0007XI-2P for apps-discuss@ietf.org; Wed, 25 Mar 2009 11:13:36 -0600 Message-ID: <49CA6647.60301@KingsMountain.com> Date: Wed, 25 Mar 2009 10:13:43 -0700 From: =JeffH User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: HyBi breakfast BOF? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.87.201 authed with jeff.hodges+kingsmountain.com} 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, 25 Mar 2009 17:13:12 -0000 I was unable to get up here to SF early enough to join you. A summary to this list would be nice if someone would be so kind. thanks, =JeffH From stpeter@stpeter.im Wed Mar 25 10:22: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 8F9E13A6B70 for ; Wed, 25 Mar 2009 10:22:25 -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 TOSrcwu4yTje for ; Wed, 25 Mar 2009 10:22:24 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 928B93A6D26 for ; Wed, 25 Mar 2009 10:22:24 -0700 (PDT) Received: from dhcp-11ba.meeting.ietf.org (dhcp-11ba.meeting.ietf.org [130.129.17.186]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 26E4AE8002; Wed, 25 Mar 2009 11:23:16 -0600 (MDT) Message-ID: <49CA6883.9030103@stpeter.im> Date: Wed, 25 Mar 2009 10:23:15 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: =JeffH Subject: Re: HyBi breakfast BOF? References: <49CA6647.60301@KingsMountain.com> In-Reply-To: <49CA6647.60301@KingsMountain.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="------------ms080301080308000209000009" 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, 25 Mar 2009 17:22:25 -0000 This is a cryptographically signed message in MIME format. --------------ms080301080308000209000009 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/25/09 10:13 AM, =JeffH wrote: > I was unable to get up here to SF early enough to join you. > > A summary to this list would be nice if someone would be so kind. I'll strive to do that here soon. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms080301080308000209000009 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 DQEJBTEPFw0wOTAzMjUxNzIzMTVaMCMGCSqGSIb3DQEJBDEWBBT9yzCZAMvI1+dV9HGY/atH o89r1zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAniWED1DCQcsY1D7Vu5lA1DJfLsd0KlneFAZq0ZXETPX2fFbfDYJyav7E/XB1 7ZSfx2vHWIyUlrGdJtWcn3LDA+JtPkVSaDOJqiEuNdtwBDfjFPVI2Eglrz+NTwv1amYv9+dv Mnxv/1Xo85VKj5u+sG1MlVGUu6h+MpRBZd/BvV9RX1nrkoiossevDj/7c5KJPNmkfebh/Bze r3dPcMiAu1Z3Kk+gFsQ3paVgwJC0if5yBhyoWceJwTUescyNqHQxLgYJtmuBenXKsDKAXElQ ciy7ay0SMVj8cjatfJ8918X5nCoEeohWnu646L+s66C6i05qOXUnCxCNnf1NSIEEAwAAAAAA AA== --------------ms080301080308000209000009-- From stpeter@stpeter.im Thu Mar 26 15:59: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 E2F263A67CC for ; Thu, 26 Mar 2009 15:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 nGzwwm6+15X6 for ; Thu, 26 Mar 2009 15:59:54 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id E6A1F3A676A for ; Thu, 26 Mar 2009 15:59:53 -0700 (PDT) Received: from squire.local (dsl-251-36.dynamic-dsl.frii.net [216.17.251.36]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 0AB1EE8002 for ; Thu, 26 Mar 2009 17:00:46 -0600 (MDT) Message-ID: <49CC091E.3090302@stpeter.im> Date: Thu, 26 Mar 2009 17:00:46 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: HyBi breakfast BOF? References: <49CA6647.60301@KingsMountain.com> In-Reply-To: <49CA6647.60301@KingsMountain.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="------------ms030608050200070801080009" 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, 26 Mar 2009 22:59:55 -0000 This is a cryptographically signed message in MIME format. --------------ms030608050200070801080009 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/25/09 11:13 AM, =JeffH wrote: > A summary to this list would be nice if someone would be so kind. Here goes... Participants: Joe Hildebrand Markus Isomaki Salvatore Loreto Alexey Melnikov Mark Nottingham Peter Saint-Andre Martin Thomson Conclusions: Broad consensus that it would be valuable to hold a BOF on this topic at a future IETF meeting. Possible I-Ds: 1. Best Practices. Topics might include: how to do framing, what kind of connection methods are appropriate, the security considerations to address, the relationship of these technologies to the browser security model, the need to minimize the impact on Internet infrastructure with respect to bandwidth usage and architectural sanity, etc. 2. Use Cases. Explore how existing technologies are being used, the design decisions that made these uses possible, etc. 3. Requirements. If the IETF were to take on work in this space, what requirements would guide the work? 4. Connection Semantics. This might take the form of an HTTP extension for long polling, including request tracking, duplication and retry methods, architecture(s), rendezvous logic between browser, "proxy", and backend application server, addressing (including possibly the use of URI templates). (Naturally, it's possible that some of these topics would be folded into fewer than four documents.) I'd appreciate it if those who were there could let me know what I've missed. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms030608050200070801080009 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 DQEJBTEPFw0wOTAzMjYyMzAwNDZaMCMGCSqGSIb3DQEJBDEWBBTOje+BpLKGcE99K4XWw1ee ckh+hjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAqQV0G3so2kk6ZqEvTllVRUmoljFqTv/y7wyOtbvN0piD8KXG5MlEiRvaxcFy VZJ4BFk5IecIvMlUYzZoyRbj4yupt2W6KRpZobw4blQHX8aHmHf+4rfAcDKMp5K4KkjR7VmF FrMdpAyuqCu+sXX+Ix4u+akVTq/E8wlnOMlW2u9wlBvskYKGWQOPQY730E226i1dUMzsAZpY ytEaKEpWFyAVQ8VvIzR1YgbANU8qYaZMnFKc78IIXShb0KYwaBjiSwAAHeXLLnfgliyTylXT bnvozRSXQzADdDf9pHw8+5MamkabGc7F1PXHC780+vfds20cjc44bQoYVN2FUc7LpQAAAAAA AA== --------------ms030608050200070801080009-- From enrico.marocco@telecomitalia.it Fri Mar 27 13:36: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 675A13A6BC6 for ; Fri, 27 Mar 2009 13:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 cdhLjsSz9UVF for ; Fri, 27 Mar 2009 13:36:32 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 35BAC3A6B74 for ; Fri, 27 Mar 2009 13:36:32 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 27 Mar 2009 21:37:24 +0100 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 27 Mar 2009 21:37:24 +0100 Message-ID: <49CD3900.6000908@telecomitalia.it> Date: Fri, 27 Mar 2009 13:37:20 -0700 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: "Lisa.Dusseault@messagingarchitects.com" Subject: ALTO meeting report (as for 2461, s. 6.1) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040407070304000801080006" Cc: apps-discuss@ietf.org, Jon Peterson , "Vijay K. Gurbani" 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, 27 Mar 2009 20:36:33 -0000 --------------ms040407070304000801080006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Concrete outcome: rough consensus (no hums against, many for) for adopting draft-marocco-alto-problem-statement and draft-kiesel-alto-reqs, the former to be published soon, the latter to stay alive for a while. Intensive discussion about solution proposals, some common ground found. Initial discussion of discovery mechanisms, to keep in sync with related work going on in other groups (geopriv, apparea, vcarddav?). Two contributions in the form of surveys have been presented. Nick Weaver didn't make it to present the work about edge-caches; however, he sent the slide (online on the proceedings page) and asked for feedback from whoever may be interested in the topic. Narrative minutes to come soon. -- Ciao, Enrico --------------ms040407070304000801080006 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyOTEzMDExOVoX DTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilXiec5xWsN2DuaGvHSz4IeWJlPiP7z UnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hjh1LTYcF1WnggMZoaH/ktb6dMCHvO oYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HYLIQxqyORJ+snLSmiA7xLX1L5Gy+t W950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzclaS0SWzKMeHg3sjdI2tKxuf3eBb0v1 +XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY78X26J2y3N61DoZHYwYyNowIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCn ZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78ZIxGWKphMQ/iAAb0tuW+VdrAZpih a7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeDWCgiCKwRRemFHM1G7lWtKt6tHrfe +BCmVslPGk2aphSk2KBAFbgCiTCCAzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA4MDMyOTEzMDExOVoXDTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilX iec5xWsN2DuaGvHSz4IeWJlPiP7zUnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hj h1LTYcF1WnggMZoaH/ktb6dMCHvOoYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HY LIQxqyORJ+snLSmiA7xLX1L5Gy+tW950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzcla S0SWzKMeHg3sjdI2tKxuf3eBb0v1+XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY7 8X26J2y3N61DoZHYwYyNowIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQCnZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78 ZIxGWKphMQ/iAAb0tuW+VdrAZpiha7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeD WCgiCKwRRemFHM1G7lWtKt6tHrfe+BCmVslPGk2aphSk2KBAFbgCiTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQHkwADQ1DCVPe59HtQFsbuDAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjcyMDM3MjBaMCMG CSqGSIb3DQEJBDEWBBR8MrZGcz0+6it+OSEhvTTa/sYxjzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAC1YtKe+OPmO mJ/WNixoNTpPj1Y1+1GCDlBX8VD9ojlwPJR82LGD9GGHzopgTwryj/SyLzTVTR08xjL+7+aZ N1PZg1FJdCcUmIWXLDW2LjLaeC+rkPKjvinP/Qn9LDKCGf7OYZv8efMi9S+GijVwmsDoSJ9I kzn+XBQET2vQpPAKqvVBH6Lh1m0jQ6orQylA8gWBNsQYF+Zysr3RAjOibD0a1dOCwh7I0UeB 3fiQIwFVz/tD86tGEy2do8e021q7tVMYfcxqOU5CrH6oe1NFxHO3/hh8L+U63+FIZpLmo+VC JkAguT7y5i80FsRfTS2JfGxgQQDehDLsubgIEoq5lucAAAAAAAA= --------------ms040407070304000801080006-- From theo@crazygreek.co.uk Sun Mar 29 06:05:11 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 B308C3A68BC for ; Sun, 29 Mar 2009 06:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wCZuhuuoJ+3e for ; Sun, 29 Mar 2009 06:05:10 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with SMTP id 3432B3A67A6 for ; Sun, 29 Mar 2009 06:05:10 -0700 (PDT) Received: from source ([72.14.220.155]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSc9yPiz6ULgCeTMYd8BARG4jUzPvL5tL@postini.com; Sun, 29 Mar 2009 06:06:07 PDT Received: by fg-out-1718.google.com with SMTP id e21so243058fga.15 for ; Sun, 29 Mar 2009 06:06:06 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 29 Mar 2009 14:05:49 +0100 Received: by 10.86.76.16 with SMTP id y16mr895255fga.46.1238331964375; Sun, 29 Mar 2009 06:06:04 -0700 (PDT) Message-ID: <167dfb9b0903290605m606a0ee8v13f1afede2d1c8f3@mail.gmail.com> Subject: Generic URI syntax incompatible with IPv6 addresses in SIP URIs From: Theo Zourzouvillys 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: Sun, 29 Mar 2009 13:05:11 -0000 Hi, sip URI's (along with a bunch of others, such as iax, im, pres, and xmpp) allow embedded IPv6 literals in their URIs, but match path-rootless in RFC 3986, which does not allow '[' and ']' - these are only allowed in authority. This means that a generic URI parser will treat an IPv6 SIP URI as invalid unless it is aware of SIP URIs. I documented it earlier in the month here: http://crazygreek.co.uk/b/2009/03/sip-uri-syntax-is-broken-with-ipv6.html I'd appreciate feedback on how to best proceed to get this fixed? Kind regards, ~ Theo From mnot@mnot.net Mon Mar 30 02:07: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 F2B873A6A80 for ; Mon, 30 Mar 2009 02:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.913 X-Spam-Level: X-Spam-Status: No, score=-4.913 tagged_above=-999 required=5 tests=[AWL=-2.314, 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 kGFS9nmV5W7i for ; Mon, 30 Mar 2009 02:07:32 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 1CA4B3A6ACB for ; Mon, 30 Mar 2009 02:07:31 -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 3017BD05B1; Mon, 30 Mar 2009 05:08:27 -0400 (EDT) Message-Id: <0E44F8EA-C111-45AD-BF86-DA2673B28EF9@mnot.net> From: Mark Nottingham To: HTTP Working Group , 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: Minutes from informal IETF/W3C meeting about HTML5 work Date: Mon, 30 Mar 2009 20:08:25 +1100 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, 30 Mar 2009 09:07:33 -0000 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 Cheers, -- Mark Nottingham http://www.mnot.net/ From lear@cisco.com Mon Mar 30 06:38: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 EE6F43A6A40 for ; Mon, 30 Mar 2009 06:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.831 X-Spam-Level: X-Spam-Status: No, score=-7.831 tagged_above=-999 required=5 tests=[AWL=-1.232, 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 15kBHh0C2aLU for ; Mon, 30 Mar 2009 06:38:52 -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 E9ECB3A6C42 for ; Mon, 30 Mar 2009 06:38:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,446,1233532800"; d="scan'208";a="276666469" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 13:39: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 n2UDdmA4016726 for ; Mon, 30 Mar 2009 15:39:48 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-105-41.cisco.com [10.61.105.41]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UDdlKq016150 for ; Mon, 30 Mar 2009 13:39:48 GMT Message-ID: <49D0CBA3.7090409@cisco.com> Date: Mon, 30 Mar 2009 15:39:47 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090329 Shredder/3.0b3pre MIME-Version: 1.0 To: Apps Discuss Subject: supposing one would want to create a new URN space for timezones... Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=411; t=1238420388; x=1239284388; 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:=20supposing=20one=20would=20want=20to=20create=20 a=20new=20URN=20space=20for=20timezones... |Sender:=20; bh=o/BK9u1XxRTBN6YT7QRZTlESmv8O6jHezJDncGywE+Y=; b=IRyTS4Bp/de/azehdGC2NSVcEmygpqU0e2a3Mi/hD95KjOW+iEZ2OIsYZu woPyhOzi3m5cMBIxwhT+uagppQFkLzArUeQWcOuqcgruRmaqWhR2W/Mv911N oRlXNQkN+A; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 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, 30 Mar 2009 13:38:57 -0000 ... would this amount to a new NID, or is there someplace we should hang this? My thinking by the way would be something like the following: ...:TIMEZONE:Authority:Timezone Name where authority would be (at least initially) one of three things: 1. Olson 2. IEEE 3. Microsoft The need for interoperability dictates one preferred method, which IMHO should be Olson. Thoughts? Eliot From timur.shemsedinov@gmail.com Mon Mar 30 07:32:38 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 8DC083A69C2 for ; Mon, 30 Mar 2009 07:32:38 -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 DzQ3xcQVYc11 for ; Mon, 30 Mar 2009 07:32:37 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 486CF3A6BE1 for ; Mon, 30 Mar 2009 07:32:36 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so937048fga.16 for ; Mon, 30 Mar 2009 07:33:34 -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=dcLh6Hkq1jUZ4qNqCif314Df64gtj5F+MaZsMbH1MRE=; b=pm5gtI1Nt93inGQj5IsL8LLJRPTztsRxYejuseJp8w2n3JrniZjqwPN/bEeYkwikxL DmDoZfuIBdW5RrncH6wDI8KORPKxmgn7Xl69U1gLhYoOHl08ON6h60dRjZnGKZKBJl7N MDED7qY/jZBZif8yr5wyF85crBrvmwsIE700A= 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=avcLQuCWxo2Zb2N1YtfWwrQk3dQCHMnWexrP/Z0jnmhIgrjJRAxBBh/SUHBOc4Uw4C pxHKpAUAlwR7UC3LyaPr4XjjmjHIW3Hg19dMc7xyWqduMi8ThmyLV/zDXLzvZeCGzA0N Wk8bbpfwlME1MZbFX2MA8IfjPt1kE0bYez6nE= MIME-Version: 1.0 Received: by 10.86.61.13 with SMTP id j13mr2639048fga.65.1238423614044; Mon, 30 Mar 2009 07:33:34 -0700 (PDT) In-Reply-To: <49D0CBA3.7090409@cisco.com> References: <49D0CBA3.7090409@cisco.com> Date: Mon, 30 Mar 2009 16:33:34 +0200 Message-ID: <248bcd790903300733x1c48ddabr976439cb19843152@mail.gmail.com> Subject: Re: supposing one would want to create a new URN space for timezones... From: Timur Shemsedinov To: Eliot Lear Content-Type: multipart/alternative; boundary=000e0cd24e2298bc75046656f709 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: Mon, 30 Mar 2009 14:32:38 -0000 --000e0cd24e2298bc75046656f709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It's a good idea, I am in need of such URN for a long time. But I must note that: 1. Timezones are independent from authority. Timezones regulation is in jurisdiction of local government of each territory. 2. Timezones are not stable from year to year, regulation can be changed by local government. 3. Timezones are related to Lat/Long coordinates, so we can resolve Lat/Long to timezone. 4. Daylight saving time should be considered too. 5. Which language do you prefer to name timezones? English / why not local languages? I have following proposition: 1. Combine time, geographical coordinates and timezones in one URN 2. Develop mechanism for resolving Lat/Long to Timezone and backward, global time to local time and backward On Mon, Mar 30, 2009 at 3:39 PM, Eliot Lear wrote: > ... would this amount to a new NID, or is there someplace we should hang > this? > > My thinking by the way would be something like the following: > > ...:TIMEZONE:Authority:Timezone Name > > where authority would be (at least initially) one of three things: > > 1. Olson > 2. IEEE > 3. Microsoft > > The need for interoperability dictates one preferred method, which IMHO > should be Olson. > > Thoughts? > > Eliot > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --000e0cd24e2298bc75046656f709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's a good idea, I am in need of such URN for a long time.
But I mu= st note that:
1. Timezones are independent from authority. Timezones reg= ulation is in jurisdiction of local government of each territory.
2. Tim= ezones are not stable from year to year, regulation can be changed by local= government.
3. Timezones are related to Lat/Long coordinates, so we can resolve Lat/Lon= g to timezone.
4. Daylight saving time should be considered too.
5. W= hich language do you prefer to name timezones? English / why not local lang= uages?

I have following proposition:
1. Combine time, geographical coordina= tes and timezones in one URN
2. Develop mechanism for resolving Lat/Long= to Timezone and backward, global time to local time and backward

On Mon, Mar 30, 2009 at 3:39 PM, Eliot Lear <lear@cisco.com><= /span> wrote:
... would this amount to a new NID, or is there someplace we should hang th= is?

My thinking by the way would be something like the following:

...:TIMEZONE:Authority:Timezone Name

where authority would be (at least initially) one of three things:

1. =A0Olson
2. =A0IEEE
3. =A0Microsoft

The need for interoperability dictates one preferred method, which IMHO sho= uld be Olson.

Thoughts?

Eliot
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--000e0cd24e2298bc75046656f709-- From cyrus@daboo.name Mon Mar 30 07:43: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 EBC473A6985 for ; Mon, 30 Mar 2009 07:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=-0.523, 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 dpj1MTTHPXIQ for ; Mon, 30 Mar 2009 07:43:51 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 0D4DD3A68B1 for ; Mon, 30 Mar 2009 07:43:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id ED7731313946; Mon, 30 Mar 2009 10:44:48 -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 dLsqRhGoqXXb; Mon, 30 Mar 2009 10:44:48 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id A6543131393F; Mon, 30 Mar 2009 10:44:46 -0400 (EDT) Date: Mon, 30 Mar 2009 10:44:40 -0400 From: Cyrus Daboo To: Eliot Lear , Apps Discuss Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: In-Reply-To: <49D0CBA3.7090409@cisco.com> References: <49D0CBA3.7090409@cisco.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=1294 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, 30 Mar 2009 14:43:52 -0000 Hi Eliot, --On March 30, 2009 3:39:47 PM +0200 Eliot Lear wrote: > ... would this amount to a new NID, or is there someplace we should hang > this? > > My thinking by the way would be something like the following: > > ...:TIMEZONE:Authority:Timezone Name > > where authority would be (at least initially) one of three things: > > 1. Olson > 2. IEEE > 3. Microsoft > > The need for interoperability dictates one preferred method, which IMHO > should be Olson. > > Thoughts? First point: we should refer to Olson, Microsoft etc as "publishers" not "authorities". "Authorities" are the actual governments or other equivalent bodies that make the rules defining a timezone. The other thing is that at CalConnect we see the need for timezone names that all publishers can agree on that allow correlation of timezone published by each. As such a registry of timezone ids independent of publisher is needed. Something like: urn:tzid:<> or perhaps with a uuid instead of the name (to avoid "political" issue wrt timezone languages, government recognition etc). There should then be a separate registry of timezone publishers. Then a "fully qualified" timezone identifier could include the publisher name as well - but that would be optional. -- Cyrus Daboo From lear@cisco.com Mon Mar 30 07:54:12 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 04A743A6A29 for ; Mon, 30 Mar 2009 07:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.795 X-Spam-Level: X-Spam-Status: No, score=-7.795 tagged_above=-999 required=5 tests=[AWL=-1.196, 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 4D9US0eoikvv for ; Mon, 30 Mar 2009 07:54:11 -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 177863A68B1 for ; Mon, 30 Mar 2009 07:54:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,446,1233532800"; d="scan'208";a="148195188" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2009 14:55:08 +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 n2UEt7Wo021196; Mon, 30 Mar 2009 16:55:07 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-105-41.cisco.com [10.61.105.41]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UEt7lL016309; Mon, 30 Mar 2009 14:55:07 GMT Message-ID: <49D0DD4B.8020803@cisco.com> Date: Mon, 30 Mar 2009 16:55:07 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090329 Shredder/3.0b3pre 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> 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=1047; t=1238424907; x=1239288907; 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=20want=20to=20c reate=20a=20new=20URN=20space=20for=09timezones... |Sender:=20; bh=PLGrjD2TMQIqFqF+cJURrw36wySpdptzg/AfE+5X/DA=; b=JRjSVe95BzOnNY7q3Livus0mktdr9GyJ6Lx9bNivAeWPMk0aIk5PHgSR7r Tv2krfXfgqRHuj0BW/3aUAdj7gqeOPdSMGlv8qVcvNA0L1LpfTdZfJRHqao1 LgElUlcHxg; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 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: Mon, 30 Mar 2009 14:54:12 -0000 Cyrus, Thanks. Please see below: On 3/30/09 4:44 PM, Cyrus Daboo wrote: > > First point: we should refer to Olson, Microsoft etc as "publishers" > not "authorities". "Authorities" are the actual governments or other > equivalent bodies that make the rules defining a timezone. Clearly not authorities as it has already caused confusion. > > The other thing is that at CalConnect we see the need for timezone > names that all publishers can agree on that allow correlation of > timezone published by each. As such a registry of timezone ids > independent of publisher is needed. Something like: > > urn:tzid:<> > > or perhaps with a uuid instead of the name (to avoid "political" issue > wrt timezone languages, government recognition etc). URN can't have is one name resolving to two values. I think resolution would cause the same concerns you are fighting today. An alternative would be to reference the publisher within the standard and update that as might be required in the future. Eliot From cyrus@daboo.name Mon Mar 30 08:02: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 AA7A628C0FF for ; Mon, 30 Mar 2009 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=-0.485, 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 UjlHph8CM+r0 for ; Mon, 30 Mar 2009 08:02:03 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 6AE753A6C43 for ; Mon, 30 Mar 2009 08:02:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 770CA1313A47; Mon, 30 Mar 2009 11:03: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 gric60DcGA-k; Mon, 30 Mar 2009 11:03:00 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 6D8711313A40; Mon, 30 Mar 2009 11:02:59 -0400 (EDT) Date: Mon, 30 Mar 2009 11:02:56 -0400 From: Cyrus Daboo To: Timur Shemsedinov , Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <5CBC4C4D1822C6A4B5F45502@caldav.corp.apple.com> In-Reply-To: <248bcd790903300733x1c48ddabr976439cb19843152@mail.gmail.com> References: <49D0CBA3.7090409@cisco.com> <248bcd790903300733x1c48ddabr976439cb19843152@mail.gmail.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=3079 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: Mon, 30 Mar 2009 15:02:04 -0000 Hi Timur, --On March 30, 2009 4:33:34 PM +0200 Timur Shemsedinov wrote: > It's a good idea, I am in need of such URN for a long time. > But I must note that: > 1. Timezones are independent from authority. Timezones regulation is in > jurisdiction of local government of each territory. Right. I prefer to use the term "publisher" to describe the source of timezone data. > 2. Timezones are not stable from year to year, regulation can be changed > by local government. Absolutely - what is more changes can occur at very short notice (sometimes only a few weeks) Any timezone publishing service needs to be able to react quickly. > 3. Timezones are related to Lat/Long coordinates, so we can resolve > Lat/Long to timezone. I prefer to leave Lat/Long out of timezones definitions - the timezone definition should be just the offset and DST rules only plus the identifier. A separate service can then be used to map lat/long to tzids as needed (e.g. ). This makes sense because different geographic areas often adopt timezones from other areas over time. Plus defining lat-long is complex - its not just a single point - you need to describe a geographic area - i.e. polygons - and include "exclusions" for areas nested inside others. > 4. Daylight saving time should be considered too. That is implicit in a timezone definition (at least as far as iCalendar RFC2445 data is concerned). > 5. Which language do you prefer to name timezones? English / why not > local languages? Internationalization of timezone names is an issue. That is why we may need to go with some for of uuid to identify unique timezones - then define a separate mapping to localized names for each of those. > I have following proposition: > 1. Combine time, geographical coordinates and timezones in one URN > 2. Develop mechanism for resolving Lat/Long to Timezone and backward, > global time to local time and backward Lat/long can be covered by services like . For timezone data itself CalConnect is working on an XML data format (based on RFC2445 type rules and Olson style zone/rule data) that would be used to define ongoing and historic offsets and DST rules. The goal is to make this compatible with RFC2445 VTIMEZONE data as well as Olson and make it easy to derive zoneinfo files (as is done today direct from Olson data). Hopefully the work that CalConnect has done will be submitted to the IETF in the form of a set of drafts within the next month or two so that we can move discussion over to the IETF for proper standardization. In addition to registries we are also working on a RESTful HTTP service for retrieval of timezone information from a "provider" - that service includes some rich apis to allow "thin" clients to retrieve offset information directly from the server, avoiding the need for those clients to actually handle the sometimes (often) complex rules involved in DST. -- Cyrus Daboo From rohan.mahy@gmail.com Mon Mar 30 08:35: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 617433A691E for ; Mon, 30 Mar 2009 08:35:19 -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 Z9KkmMLvB0+Y for ; Mon, 30 Mar 2009 08:35:18 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.245]) by core3.amsl.com (Postfix) with ESMTP id 977193A69FD for ; Mon, 30 Mar 2009 08:35:18 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id k29so2316106rvb.34 for ; Mon, 30 Mar 2009 08:36:16 -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=Vg9M/KGReI6lJyBrKiKf4SIrjExMnFYD1dT6EcvGarE=; b=wFejBFBAxo3axk7aL/plTl311xzhNpR08nKY2YJrXwy2q/5FjXX4k1I40Iv+E4QLsb A2gkLUWV4REDlncSj4Mg6lolnb7ioq9HEAdJ4qSg9ZCNgKjSCIyXbARPz1fzryDorLVL A+n7sVq7yf5TyN7H7mJTHk0hhUuuRUwOcU/b0= 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=Z2pAGRP2ADyn6DrnigFSSqIBejZO9SWrpGaP2CGP1Nney3rXE2+GFAPL1HBbF7IJhY 1XsD9gTdkFYQ03KItpxo5cohx+k58PEF7jT4N2F+BLI1FF1K5dDjTC3td+xZJhUZbCXk eHUqQwNSz5oVdqex8dQEbDO9bETCWvwZmMDyU= MIME-Version: 1.0 Received: by 10.141.201.1 with SMTP id d1mr2902396rvq.142.1238427376857; Mon, 30 Mar 2009 08:36:16 -0700 (PDT) In-Reply-To: <5CBC4C4D1822C6A4B5F45502@caldav.corp.apple.com> References: <49D0CBA3.7090409@cisco.com> <248bcd790903300733x1c48ddabr976439cb19843152@mail.gmail.com> <5CBC4C4D1822C6A4B5F45502@caldav.corp.apple.com> Date: Mon, 30 Mar 2009 08:36:16 -0700 Message-ID: <953beacc0903300836p67271497ua264242049c5bc69@mail.gmail.com> Subject: Re: supposing one would want to create a new URN space for timezones... From: Rohan Mahy To: Cyrus Daboo Content-Type: multipart/alternative; boundary=000e0cd14964e0b454046657d7f4 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: Mon, 30 Mar 2009 15:35:19 -0000 --000e0cd14964e0b454046657d7f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Mar 30, 2009 at 8:02 AM, Cyrus Daboo wrote: > 5. Which language do you prefer to name timezones? English / why not >> local languages? >> > > Internationalization of timezone names is an issue. That is why we may need > to go with some for of uuid to identify unique timezones - then define a > separate mapping to localized names for each of those. AFAIK, the canonical timezone name is a string which contains the publisher name and is unique in the publisher's namespace. It can be in some natural language or it can be a UUID, but that is up to the publisher. There can be lots of other names for the timezone in various natural languages, but the publisher gets to pick a name that the computer uses. thanks, -rohan --000e0cd14964e0b454046657d7f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 30, 2009 at 8:02 AM, Cyrus D= aboo <cyrus@daboo.= name> wrote:
5. Which language do you p= refer to name timezones? English / why not
local languages?

Internationalization of timezone names is an issue. That is why we may need= to go with some for of uuid to identify unique timezones - then define a s= eparate mapping to localized names for each of those.

AFAIK, the canonical timezone name is a string which contain= s the publisher name and is unique in the publisher's namespace. It can= be in some natural language or it can be a UUID, but that is up to the pub= lisher. =A0There can be lots of other names for the timezone in various nat= ural languages, but the publisher gets to pick a name that the computer use= s.

thanks,
-rohan
--000e0cd14964e0b454046657d7f4-- From moore@network-heretics.com Mon Mar 30 08:48:37 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 74A203A68DF for ; Mon, 30 Mar 2009 08:48:37 -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 zw8qSCd7L5B5 for ; Mon, 30 Mar 2009 08:48:36 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id A92763A67D2 for ; Mon, 30 Mar 2009 08:48:36 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMD97288 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 08:49:32 -0700 (PDT) Message-ID: <49D0EA0A.3020900@network-heretics.com> Date: Mon, 30 Mar 2009 10:49:30 -0500 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> In-Reply-To: <49D0CBA3.7090409@cisco.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: Mon, 30 Mar 2009 15:48:37 -0000 I guess I have to wonder how to get the persistence we expect from URNs when using them to name timezones. The problem is that timezone boundaries change over time. Say, for example, you define a timezone named X and at the time you define it, it happens to apply to both City A and City B. At some later date, political boundaries change. This causes timezone boundaries to be realigned, and A and B are no longer in the same timezone. This creates a tension between different uses of name X - does it apply to the timezone in city A or that in city B? (Or even more subtly - say that the GMT offset for A and B remains the same after the change, but the rules for transition to/from "summer time" are different. In this case it's even less clear which one is the "old" timezone and which one is the "new" one.) This kind of tension happens all the time with names for things, so timezones really aren't exceptional in that regard. The problem comes when we try to make those names have URN semantics. -- But if you really want to do this, I think you need to define them in terms of political entities, because it's the political entities that define the timezones. Say: URN:TZ:US.Eastern US eastern time zone URN:TZ:US.IN.central timezone in central Indiana Use ISO 3166 country codes because the binding between those and the countries they refer to will be unambiguous. e.g. Even if Bezerkistan splits up into two separate countries and both of them claim Bezerkistan's country code, ISO will presumably find some way to sort things out. I don't think the publisher should be part of the timezone URN, because really you aren't trying to define an event in terms of the timezone as published by Olson or IEEE or whomever - you're trying to define an event relative to whatever the US.Eastern timezone happens to be. Keith From tonyg@lshift.net Mon Mar 30 09:05: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 671763A696D for ; Mon, 30 Mar 2009 09:05:40 -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 W2yLirwWH4RZ for ; Mon, 30 Mar 2009 09:05:39 -0700 (PDT) Received: from agentk.lshift.net (host226.lshift.net [195.172.218.226]) by core3.amsl.com (Postfix) with ESMTP id 94B023A6898 for ; Mon, 30 Mar 2009 09:05:39 -0700 (PDT) Received: from shortstop.lshift.net ([10.224.189.87]) by agentk.lshift.net with esmtpsa (SSL 3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LoK0J-0003MB-LI; Mon, 30 Mar 2009 17:06:31 +0100 Message-ID: <49D0EE03.5010501@lshift.net> Date: Mon, 30 Mar 2009 17:06:27 +0100 From: Tony Garnock-Jones User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) 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> In-Reply-To: <49D0EA0A.3020900@network-heretics.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Score: -1.2 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: Mon, 30 Mar 2009 16:05:40 -0000 Keith Moore wrote: > I guess I have to wonder how to get the persistence we expect from URNs > when using them to name timezones. The problem is that timezone > boundaries change over time. They could be given in terms of publisher and edition. URN:TZ:Olsen:2009d:Europe/London ("Europe/London as defined by Olsen database version 2009d.") That way, it's always unambiguous and stable in the face of evolution. > But if you really want to do this, I think you need to define them in > terms of political entities, because it's the political entities that > define the timezones. One could treat a political entity as a publisher. The edition string then would be a reference to the law that introduced the definition: URN:TZ:US:T15.USC.6.IX.260a.19960116:PST URN:TZ:US:XO11751.38FR34725.19731215:PST Yuck. I prefer Olsen's edition names :) Regards, Tony From rohan.mahy@gmail.com Mon Mar 30 09:10: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 1A8DD3A6D34 for ; Mon, 30 Mar 2009 09:10:24 -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 oJ5SY9tYcqLk for ; Mon, 30 Mar 2009 09:10:22 -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 24E473A6D3B for ; Mon, 30 Mar 2009 09:10:21 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id k29so2329678rvb.34 for ; Mon, 30 Mar 2009 09:11:09 -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=mxVYk0R0roXXH6dCd6ucbRsgvldUuLu3bRhFH3LETP4=; b=KNsUgFDqRM16GrQTMTZmdgEszI56K0eS4oRt7mKuZE1MQ8ux52jGvLSfOV7B7ajUOt VbGw6QSr1mQSBVRs4yyHRR2W6MOXOykUb5sp1273aqNNdhk/oiR7aAiYsbFQ7QzopN0w upgoUVzebqMWnhQYPCh1rZlRQb7aY3g04uKd8= 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=Z6z0XEV666g7rf3xKq8cbmTQ2UDWsby+xa/gJq7Fw2d9zSEFC/wNWqyMyHdNf6Ul5m ru1QImec4Jbt7M/2A3o+unqV/d/IzLh8qCtN/LPZH4CPM9gUEC4YoX0fbtVMXea12nP/ SHqcUuuI4440L7yAqZ7XuZ5s89J/bWAx1d/t8= MIME-Version: 1.0 Received: by 10.140.247.13 with SMTP id u13mr2904599rvh.288.1238429469734; Mon, 30 Mar 2009 09:11:09 -0700 (PDT) In-Reply-To: <49D0EA0A.3020900@network-heretics.com> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> Date: Mon, 30 Mar 2009 09:11:09 -0700 Message-ID: <953beacc0903300911r45771e24y3b6b296be736a4ec@mail.gmail.com> Subject: Re: supposing one would want to create a new URN space for timezones... From: Rohan Mahy To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd106269f78b004665854e2 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: Mon, 30 Mar 2009 16:10:24 -0000 --000e0cd106269f78b004665854e2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Keith, There are two separate things we keep track of: a) What geographic regions are in what timezone at a specific moment of time. We are not discussing this case at the moment. Solving this is hampered by the fact that more than one authority can claim rights to define timezone rules for the same piece of ground (ex: Kashmir). The good news is that usually a user or administrator picks a timezone and most timezones don't have this problem. Note that Indiana and Arizona do not move back and forth from one time zone to another. They have their own timezones. b) What the time offset rules are for a specific timezone. Timezone publishers already keep track of when the rules for a specific timezone change. When the US recently changed the dates that daylight savings time starts and ends, the timezone rules for US-Eastern, US-Pacific, etc. has enough information to calculate both past and future times. Likewise, when Brazil postponed the start of daylight savings time because the pope was in town and someone forgot to calculate the change in offset when reserving satellite time, the timezone rules in the Olson database reflect that one-time historic event and can calculate dates and times correctly back to 1970. This whole area is well studied by folks outside the IETF. If not a "solved" problem it is basically a very well managed problem. What is not solved is how to represent these timezones in a URN. What many people realized is that the "authorities" are a lousy source of timezone data and that is why the publishers exist. They exist because they are independent and are only interested in delivering accurate timezone information. Therefore people trust them more than anyone else to deliver useful timezone information. If ever there is some disagreement between the tz rules of two publishers, the user/administrator/programmer should be able to pick one. Also there is no agreement on the canonical names among publishers. Therefore it makes sense that the URN contain the name of the publisher. This URN should be used by the computer only and only a corresponding localized human readable string should be presented to the end user. thanks, -rohan On Mon, Mar 30, 2009 at 8:49 AM, Keith Moore wrote: > I guess I have to wonder how to get the persistence we expect from URNs > when using them to name timezones. The problem is that timezone > boundaries change over time. > > Say, for example, you define a timezone named X and at the time you > define it, it happens to apply to both City A and City B. At some later > date, political boundaries change. This causes timezone boundaries to > be realigned, and A and B are no longer in the same timezone. This > creates a tension between different uses of name X - does it apply to > the timezone in city A or that in city B? > > (Or even more subtly - say that the GMT offset for A and B remains the > same after the change, but the rules for transition to/from "summer > time" are different. In this case it's even less clear which one is the > "old" timezone and which one is the "new" one.) > > This kind of tension happens all the time with names for things, so > timezones really aren't exceptional in that regard. The problem comes > when we try to make those names have URN semantics. > > -- > > But if you really want to do this, I think you need to define them in > terms of political entities, because it's the political entities that > define the timezones. Say: > > URN:TZ:US.Eastern US eastern time zone > URN:TZ:US.IN.central timezone in central Indiana > > Use ISO 3166 country codes because the binding between those and the > countries they refer to will be unambiguous. e.g. Even if Bezerkistan > splits up into two separate countries and both of them claim > Bezerkistan's country code, ISO will presumably find some way to sort > things out. > > I don't think the publisher should be part of the timezone URN, because > really you aren't trying to define an event in terms of the timezone as > published by Olson or IEEE or whomever - you're trying to define an > event relative to whatever the US.Eastern timezone happens to be. > > Keith > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --000e0cd106269f78b004665854e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Keith,

There are two separate things we keep track of:
a) What geographic regions are in what timezone at a specific mome= nt of time. We are not discussing this case at the moment. Solving this is = hampered by the fact that more than one authority can claim rights to defin= e timezone rules for the same piece of ground (ex: Kashmir). The good news = is that usually a user or administrator picks a timezone and most timezones= don't have this problem. =A0Note that Indiana and Arizona do not move = back and forth from one time zone to another. They have their own timezones= .

b) What the time offset rules are for a specific timezo= ne.=A0Timezone publishers already keep track of when the rules for a specif= ic timezone change. =A0When the US recently changed the dates that daylight= savings time starts and ends, the timezone rules for US-Eastern, US-Pacifi= c, etc. has enough information to calculate both past and future times. Lik= ewise, when Brazil postponed the start of daylight savings time because the= pope was in town and someone forgot to calculate the change in offset when= reserving satellite time, the timezone rules in the Olson database reflect= that one-time historic event and can calculate dates and times correctly b= ack to 1970.

This whole area is well studied by folks outside the IE= TF. If not a "solved" problem it is basically a very well managed= problem. What is not solved is how to represent these timezones in a URN.<= /div>

What many people realized is that the "authorities= " are a lousy source of timezone data and that is why the publishers e= xist. They exist because they are independent and are only interested in de= livering accurate timezone information. Therefore people trust them more th= an anyone else to deliver useful timezone information. If ever there is som= e disagreement between the tz rules of two publishers, the user/administrat= or/programmer should be able to pick one. Also there is no agreement on the= canonical names among publishers. Therefore it makes sense that the URN co= ntain the name of the publisher. This URN should be used by the computer on= ly and only a corresponding localized human readable string should be prese= nted to the end user.

thanks,
-rohan


<= div class=3D"gmail_quote">On Mon, Mar 30, 2009 at 8:49 AM, Keith Moore <moore@netwo= rk-heretics.com> wrote:
I guess I have to wonder how to get the per= sistence we expect from URNs
when using them to name timezones. =A0The problem is that timezone
boundaries change over time.

Say, for example, you define a timezone named X and at the time you
define it, it happens to apply to both City A and City B. =A0At some later<= br> date, political boundaries change. =A0This causes timezone boundaries to be realigned, and A and B are no longer in the same timezone. =A0This
creates a tension between different uses of name X - does it apply to
the timezone in city A or that in city B?

(Or even more subtly - say that the GMT offset for A and B remains the
same after the change, but the rules for transition to/from "summer time" are different. =A0In this case it's even less clear which on= e is the
"old" timezone and which one is the "new" one.)

This kind of tension happens all the time with names for things, so
timezones really aren't exceptional in that regard. =A0The problem come= s
when we try to make those names have URN semantics.

--

But if you really want to do this, I think you need to define them in
terms of political entities, because it's the political entities that define the timezones. =A0Say:

URN:TZ:US.Eastern =A0 =A0 =A0 =A0 =A0 =A0 =A0 US eastern time zone
URN:TZ:US.IN.central =A0 =A0 =A0 =A0 =A0 =A0timezone in central Indiana

Use ISO 3166 country codes because the binding between those and the
countries they refer to will be unambiguous. =A0e.g. Even if Bezerkistan splits up into two separate countries and both of them claim
Bezerkistan's country code, ISO will presumably find some way to sort things out.

I don't think the publisher should be part of the timezone URN, because=
really you aren't trying to define an event in terms of the timezone as=
published by Olson or IEEE or whomever - =A0you're trying to define an<= br> event relative to whatever the US.Eastern timezone happens to be.

Keith
__________________________________= _____________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--000e0cd106269f78b004665854e2-- From fanf2@hermes.cam.ac.uk Mon Mar 30 09:13: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 0A0153A6AD6 for ; Mon, 30 Mar 2009 09:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 HKvKVWZAaUJb for ; Mon, 30 Mar 2009 09:13:13 -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 782013A6D3B for ; Mon, 30 Mar 2009 09:13:13 -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]:39467) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1LoK7l-0005UB-3s (Exim 4.70) (return-path ); Mon, 30 Mar 2009 17:14:09 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LoK7l-0005qV-63 (Exim 4.67) (return-path ); Mon, 30 Mar 2009 17:14:09 +0100 Date: Mon, 30 Mar 2009 17:14:09 +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: <49D0EA0A.3020900@network-heretics.com> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@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 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, 30 Mar 2009 16:13:15 -0000 On Mon, 30 Mar 2009, Keith Moore wrote: > I guess I have to wonder how to get the persistence we expect from URNs > when using them to name timezones. What properties do you want to be persistent? I can't think of anything about timezones that has any guarantee of persistence. The only sure thing is to refer to local time at a particular location, with a fairly high-resolution concept of location (e.g. per county in many US states). Unfortunately this makes the problem of tz naming thousands of times larger than the number of distinct timezones. > But if you really want to do this, I think you need to define them in > terms of political entities, because it's the political entities that > define the timezones. But which political entity is responsible for the time in a given location is not stable, and furthermore the political arrangements are unnecessarily obscure for the purpose of keeping tz rules. 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 Mon Mar 30 09:13: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 99D923A6B00 for ; Mon, 30 Mar 2009 09:13: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 JtksI77JKW16 for ; Mon, 30 Mar 2009 09:13: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 C0DFA3A6AD6 for ; Mon, 30 Mar 2009 09:13:49 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMD99938 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 09:14:44 -0700 (PDT) Message-ID: <49D0EFF1.6050402@network-heretics.com> Date: Mon, 30 Mar 2009 11:14:41 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Garnock-Jones 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> In-Reply-To: <49D0EE03.5010501@lshift.net> 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: Mon, 30 Mar 2009 16:13:50 -0000 Tony Garnock-Jones wrote: > Keith Moore wrote: >> I guess I have to wonder how to get the persistence we expect from URNs >> when using them to name timezones. The problem is that timezone >> boundaries change over time. > > They could be given in terms of publisher and edition. > > URN:TZ:Olsen:2009d:Europe/London > > ("Europe/London as defined by Olsen database version 2009d.") > > That way, it's always unambiguous and stable in the face of evolution. Then you won't recognize that two timezones are the same when they're defined in terms of different publishers, or the same publisher and different editions (even when the rules for that timezone didn't change between editions). Do you really want timezone identifiers that all change every time somebody, somewhere in the world, changes the definition of a single timezone? (why do people want timezone URNs anyway?) >> But if you really want to do this, I think you need to define them in >> terms of political entities, because it's the political entities that >> define the timezones. > > One could treat a political entity as a publisher. The edition string > then would be a reference to the law that introduced the definition: > > URN:TZ:US:T15.USC.6.IX.260a.19960116:PST > URN:TZ:US:XO11751.38FR34725.19731215:PST The thing is, I don't think we want the notion of a timezone URN to apply only to GMT offset and summer time transition rules that are/were valid for a specific period of time. I think we want the notion of timezone to apply to the set of rules in place for a particular location independent of any changes to those rules. Keith From moore@network-heretics.com Mon Mar 30 09:16: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 6478E3A6AA1 for ; Mon, 30 Mar 2009 09:16:41 -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 lnBbn-9zpR0b for ; Mon, 30 Mar 2009 09:16:40 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 96DC33A6A47 for ; Mon, 30 Mar 2009 09:16:40 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME00214 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 09:17:35 -0700 (PDT) Message-ID: <49D0F09B.5040206@network-heretics.com> Date: Mon, 30 Mar 2009 11:17:31 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <953beacc0903300911r45771e24y3b6b296be736a4ec@mail.gmail.com> In-Reply-To: <953beacc0903300911r45771e24y3b6b296be736a4ec@mail.gmail.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: Mon, 30 Mar 2009 16:16:41 -0000 Rohan Mahy wrote: > Keith, > > There are two separate things we keep track of: > a) What geographic regions are in what timezone at a specific moment of > time. We are not discussing this case at the moment. Solving this is > hampered by the fact that more than one authority can claim rights to > define timezone rules for the same piece of ground (ex: Kashmir). The > good news is that usually a user or administrator picks a timezone and > most timezones don't have this problem. Note that Indiana and Arizona > do not move back and forth from one time zone to another. They have > their own timezones. > > b) What the time offset rules are for a specific timezone. Timezone > publishers already keep track of when the rules for a specific timezone > change. When the US recently changed the dates that daylight savings > time starts and ends, the timezone rules for US-Eastern, US-Pacific, > etc. has enough information to calculate both past and future times. > Likewise, when Brazil postponed the start of daylight savings time > because the pope was in town and someone forgot to calculate the change > in offset when reserving satellite time, the timezone rules in the Olson > database reflect that one-time historic event and can calculate dates > and times correctly back to 1970. > > This whole area is well studied by folks outside the IETF. If not a > "solved" problem it is basically a very well managed problem. What is > not solved is how to represent these timezones in a URN. yes, I understand all of the above. > What many people realized is that the "authorities" are a lousy source > of timezone data and that is why the publishers exist. They exist > because they are independent and are only interested in delivering > accurate timezone information. Therefore people trust them more than > anyone else to deliver useful timezone information. If ever there is > some disagreement between the tz rules of two publishers, the > user/administrator/programmer should be able to pick one. Also there is > no agreement on the canonical names among publishers. Therefore it makes > sense that the URN contain the name of the publisher. no, it doesn't follow. because what the publishers are doing is still trying to reflect the laws that are put in place by the authorities. Keith From cyrus@daboo.name Mon Mar 30 09:26: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 C52203A6C32 for ; Mon, 30 Mar 2009 09:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=-0.453, 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 AIvuq6QM9Hcp for ; Mon, 30 Mar 2009 09:26:14 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id C49563A67D2 for ; Mon, 30 Mar 2009 09:26:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id D336213145F2; Mon, 30 Mar 2009 12:27:10 -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 6c2+Z+jGmLwL; Mon, 30 Mar 2009 12:27:10 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id CD5B113145EB; Mon, 30 Mar 2009 12:27:07 -0400 (EDT) Date: Mon, 30 Mar 2009 12:27:02 -0400 From: Cyrus Daboo To: Keith Moore , Tony Garnock-Jones Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.com> In-Reply-To: <49D0EFF1.6050402@network-heretics.com> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <49D0EFF1.6050402@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=1869 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: Mon, 30 Mar 2009 16:26:14 -0000 Hi Keith, --On March 30, 2009 11:14:41 AM -0500 Keith Moore wrote: >> They could be given in terms of publisher and edition. >> >> URN:TZ:Olsen:2009d:Europe/London >> >> ("Europe/London as defined by Olsen database version 2009d.") >> >> That way, it's always unambiguous and stable in the face of evolution. > > Then you won't recognize that two timezones are the same when they're > defined in terms of different publishers, or the same publisher and > different editions (even when the rules for that timezone didn't change > between editions). > > Do you really want timezone identifiers that all change every time > somebody, somewhere in the world, changes the definition of a single > timezone? Right - and this is the critical point of interoperability that we want to solve in the Calendaring & Scheduling space. The key thing to remember is that "urn:tzid:Europe/London" contains the full historical information and current ongoing rules for that timezone definition. Clients/servers can then rely on that so that we can pass timezone data "by reference" instead of "by value". iCalendar RFC2445 currently requires all appropriate VTIMEZONE objects to be included in a VCALENDAR stream that references a timezone - this results in a lot of duplicate data being sent each time a VCALENDAR object is exchanged One goal for this work is to eliminate the need to send the actual VTIMEZONE data - instead we want the iCalendar objects to refer to the new "standard timezones" with the guarantee that each party on either side of the exchange of data has the exact same definition that they can rely on to calculate UTC times etc. The publisher and version information would be meta-data included with the timezone data that "providers" (as per my apps area slides) make available to "consumers". -- Cyrus Daboo From moore@network-heretics.com Mon Mar 30 09:29: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 6635C3A6A71 for ; Mon, 30 Mar 2009 09:29:33 -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 T-KaXcPq7Dtn for ; Mon, 30 Mar 2009 09:29: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 A8BC13A67D2 for ; Mon, 30 Mar 2009 09:29:32 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME01566 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 09:30:24 -0700 (PDT) Message-ID: <49D0F39E.3080206@network-heretics.com> Date: Mon, 30 Mar 2009 11:30:22 -0500 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> In-Reply-To: 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: Mon, 30 Mar 2009 16:29:33 -0000 Tony Finch wrote: > On Mon, 30 Mar 2009, Keith Moore wrote: > >> I guess I have to wonder how to get the persistence we expect from URNs >> when using them to name timezones. > > What properties do you want to be persistent? I can't think of anything > about timezones that has any guarantee of persistence. The binding between a URN and the concept that it names needs to be persistent. Otherwise use of URNs is out of scope. That doesn't say that if you use a URN to name a timezone, that the rules associated with the timezone can never change, or that the areas in which that timezone is used can never change. But the binding between the URN and the set of rules cannot change. You can't say one day that URN:TZ:FOO means US/Eastern time and the next day it means US/Pacific time. >> But if you really want to do this, I think you need to define them in >> terms of political entities, because it's the political entities that >> define the timezones. > > But which political entity is responsible for the time in a given location > is not stable, 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. A timezone is just a set of rules for calculating GMT offset. They tend to be defined by political entities and they are usually applied to particular regions. But there's no inherent relation between the location of an event and any particular timezone. If someone in Europe wants to schedule a conference call at 4 pm US/Eastern time (say for the benefit of an American participant), they're free to do so. Keith From moore@network-heretics.com Mon Mar 30 09:38: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 C3FB33A6C62 for ; Mon, 30 Mar 2009 09:38:19 -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 IDe93k7-CNMl for ; Mon, 30 Mar 2009 09:38: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 EDEA43A6A18 for ; Mon, 30 Mar 2009 09:38:18 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME02560 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 09:39:11 -0700 (PDT) Message-ID: <49D0F5AD.2020509@network-heretics.com> Date: Mon, 30 Mar 2009 11:39:09 -0500 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> In-Reply-To: <0E84C659A9CDD2BBCA99F7D3@caldav.corp.apple.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: Mon, 30 Mar 2009 16:38:19 -0000 Cyrus Daboo wrote: > Hi Keith, > > --On March 30, 2009 11:14:41 AM -0500 Keith Moore > wrote: > >>> They could be given in terms of publisher and edition. >>> >>> URN:TZ:Olsen:2009d:Europe/London >>> >>> ("Europe/London as defined by Olsen database version 2009d.") >>> >>> That way, it's always unambiguous and stable in the face of evolution. >> >> Then you won't recognize that two timezones are the same when they're >> defined in terms of different publishers, or the same publisher and >> different editions (even when the rules for that timezone didn't change >> between editions). >> >> Do you really want timezone identifiers that all change every time >> somebody, somewhere in the world, changes the definition of a single >> timezone? > > Right - and this is the critical point of interoperability that we want > to solve in the Calendaring & Scheduling space. The key thing to > remember is that "urn:tzid:Europe/London" contains the full historical > information and current ongoing rules for that timezone definition. I realize this is heretical in some circles, but I'll claim that embedding the city name in a timezone name is a bug - or at least suboptimal. It doesn't seem so much like a bug when you use the name of a major city such as London or Chicago, because everyone knows about them and we don't expect them to split up. And their is a tendency for people to align their activities according to the timezone in a nearby major city. Still, for locations that aren't terribly close to a big city, it's not always clear which definition applies, and the boundaries at which a city's timezone applies tend to shift over time. Keith From cyrus@daboo.name Mon Mar 30 09:48: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 46D2828C11E for ; Mon, 30 Mar 2009 09:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=-0.425, 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 f1KkXXVUivTL for ; Mon, 30 Mar 2009 09:48:41 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 8634E28C11D for ; Mon, 30 Mar 2009 09:48:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8F0861314717; Mon, 30 Mar 2009 12:49:37 -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 BL51-UkO+4Vv; Mon, 30 Mar 2009 12:49:37 -0400 (EDT) Received: from [17.101.35.28] (unknown [17.101.35.28]) by daboo.name (Postfix) with ESMTP id BD6ED1314710; Mon, 30 Mar 2009 12:49:34 -0400 (EDT) Date: Mon, 30 Mar 2009 12:49:32 -0400 From: Cyrus Daboo To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: In-Reply-To: <49D0F5AD.2020509@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> 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=1547 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: Mon, 30 Mar 2009 16:48:42 -0000 Hi Keith, --On March 30, 2009 11:39:09 AM -0500 Keith Moore wrote: >> Right - and this is the critical point of interoperability that we want >> to solve in the Calendaring & Scheduling space. The key thing to >> remember is that "urn:tzid:Europe/London" contains the full historical >> information and current ongoing rules for that timezone definition. > > I realize this is heretical in some circles, but I'll claim that > embedding the city name in a timezone name is a bug - or at least > suboptimal. It doesn't seem so much like a bug when you use the name of > a major city such as London or Chicago, because everyone knows about > them and we don't expect them to split up. And their is a tendency for > people to align their activities according to the timezone in a nearby > major city. Still, for locations that aren't terribly close to a big > city, it's not always clear which definition applies, and the boundaries > at which a city's timezone applies tend to shift over time. Right. That is one of the reasons I think I would prefer to have a uuid as the actual registered identifier with perhaps an "also known as" field in the registry with the Olson-style names. One of the roles of a timezone "publisher" or "provider" would be to include a mapping table from the uuids to localized names that can be presented to users - how that data is generated is out of scope for us - all that matters is that we provide the necessary apis and data fields to allow it to be used. -- Cyrus Daboo From lear@cisco.com Mon Mar 30 10: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 6C9733A6C8C for ; Mon, 30 Mar 2009 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.76 X-Spam-Level: X-Spam-Status: No, score=-9.76 tagged_above=-999 required=5 tests=[AWL=0.839, 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 fVwW+bEi3Fiw for ; Mon, 30 Mar 2009 10:48:06 -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 393993A6C62 for ; Mon, 30 Mar 2009 10:48:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,447,1233532800"; d="scan'208";a="37057260" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2009 17:49:03 +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 n2UHn3pk007704; Mon, 30 Mar 2009 19:49:03 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-107-11.cisco.com [10.61.107.11]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UHn2VP008617; Mon, 30 Mar 2009 17:49:03 GMT Message-ID: <49D1060E.2030709@cisco.com> Date: Mon, 30 Mar 2009 19:49:02 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090329 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> In-Reply-To: <49D0F5AD.2020509@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=469; t=1238435343; x=1239299343; 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=20want=20to=20c reate=20a=09new=09URN=09space=09for=09timezones... |Sender:=20; bh=230LETIPYnUgMNVLjmh/urXtl/Gtb9GRL16rHmzuf2c=; b=RY354PtUlLia1fhIzXxD6iKLo4CBJjFCoHB2pGZwr7p7lPaMEju8gvgQ7g qzXfZR7AsGY/vSpT/whEtA6aalojpnmnTLw4CM5NW9v9uKLY1jxbmkfkwLWt HQu9wS6DDg; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 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: Mon, 30 Mar 2009 17:48:07 -0000 Guys, Realistically I don't think we get to have a say on how the publishers choose their keys for information. I also don't think we get to tell them what language they do it in. Doing so gets someone into a full time job just to keep the mapping between IANA names and their names. Let's not do that. Introducing any coherency concerns would be bad. This needs to be light weight. If you want to localize, do it in your implementation. Eliot From timur.shemsedinov@gmail.com Mon Mar 30 11:32: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 E7D9028C110 for ; Mon, 30 Mar 2009 11:32:05 -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 mtbsaKKyxoYq for ; Mon, 30 Mar 2009 11:32:05 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 4C5A63A69BC for ; Mon, 30 Mar 2009 11:32:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so1004381fga.16 for ; Mon, 30 Mar 2009 11:33:00 -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=lW0ft39NuA/UHa2t7p3/wH5mWlAZ4rkLrECJrvpo9vI=; b=IVaSDv5VNbOU5HomnlPp9ePLRs858qpHMRRFa5KXmicEFJhate/O6IKPdIPbglKnzb 4z1soKtBWPm+0qXIqu3BegvbS3yr4SxVkMOJHeTRg3dHCY2LUf/cW9gIjmwdo4WNO17U 8zSYi4qL62IkdZcAumhMPkVrLTjIKa0xEpTQE= 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=XSvGJMAX8ub9j7jMlocwoxmJemgMrtOxpo/r2woqkGyaUw1r3w9QamdAXhn4B2VNG6 Mis9R/sQyPwq/hJ4Vrh/7YfLxiB3xiyF0K7G3MNq4G6KY7mD/EHaVwIb+HfieDbYnArj 1enYF4yrm/pg8R2zvGMJhNsoqeRoBICjPoC1c= MIME-Version: 1.0 Received: by 10.86.36.17 with SMTP id j17mr4523017fgj.36.1238437980910; Mon, 30 Mar 2009 11:33:00 -0700 (PDT) In-Reply-To: <49D1060E.2030709@cisco.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> Date: Mon, 30 Mar 2009 21:33:00 +0300 Message-ID: <248bcd790903301133w37754a57p14989d53589918a8@mail.gmail.com> Subject: Re: supposing one would want to create a new URN space for timezones... From: Timur Shemsedinov To: Eliot Lear Content-Type: multipart/alternative; boundary=000e0cd24492edb68804665a4f83 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: Mon, 30 Mar 2009 18:32:06 -0000 --000e0cd24492edb68804665a4f83 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Mar 30, 2009 at 8:49 PM, Eliot Lear wrote: > > Realistically I don't think we get to have a say on how the publishers > choose their keys for information. I also don't think we get to tell them > what language they do it in. Doing so gets someone into a full time job > just to keep the mapping between IANA names and their names. Let's not do > that. Introducing any coherency concerns would be bad. This needs to be > light weight. If you want to localize, do it in your implementation. I believe that Timezones are same thing as NS so we need something like DNS, including 4 things: 1. unique identification (URN) 2. Timezones database (or databases) to hold daylight saving, history on mapping to territories and date periods. Such databases should be stored in any format depending on realization but having unified fields. 3. resolving algorithm with common interface 4. resolving services implementing algorithm but compatible with each other I think we need special RFC to regulate timezones resolution (based on ISO). ~Timur --000e0cd24492edb68804665a4f83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 30, 2009 at 8:49 PM, Eliot Lear <lear@cisco.com> wrote:

I believe that Timezones are same thing as NS so we need something= like DNS, including 4 things:
1. unique identification (URN)
2. Time= zones database (or databases) to hold daylight saving, history on mapping t= o territories and date periods. Such databases should be stored in any form= at depending on realization but having unified fields.
3. resolving algorithm with common interface
4. resolving services imple= menting algorithm but compatible with each other

I think= we need special RFC to regulate timezones resolution (based on ISO).

~Timur
--000e0cd24492edb68804665a4f83-- From patrik@frobbit.se Mon Mar 30 11:46: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 552943A6C62 for ; Mon, 30 Mar 2009 11:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 lOD8NwolXXWW for ; Mon, 30 Mar 2009 11:46:24 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 5A27C3A6898 for ; Mon, 30 Mar 2009 11:46:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 242924576C59; Mon, 30 Mar 2009 20:47:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65DM1mtYoMm3; Mon, 30 Mar 2009 20:47:20 +0200 (CEST) Received: from [192.168.1.95] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 84F694576C46; Mon, 30 Mar 2009 20:47:20 +0200 (CEST) Message-Id: <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Keith Moore In-Reply-To: <49D0F5AD.2020509@network-heretics.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-35-286118246" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: supposing one would want to create a new URN space for timezones... Date: Mon, 30 Mar 2009 20:47:19 +0200 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> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) 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: Mon, 30 Mar 2009 18:46:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-35-286118246 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 30 mar 2009, at 18.39, Keith Moore wrote: > I realize this is heretical in some circles, but I'll claim that > embedding the city name in a timezone name is a bug - or at least > suboptimal. Yes, but... What you want to do when you use a timezone is to say that an event is at a specific time according to a specific timezone. How you name that timezone does not matter. Right? The mapping from locality/lat/long etc to timezone name can in theory be calculated. And this mapping might also change over time. I think therefore in practice, as "events" often are bound to a named location that you want to go from that location (say London) together with time at that location to the time in UTC. So in reality you will probably have names of cities there... paf --Apple-Mail-35-286118246 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJ0RO3rMabGguI180RAlSzAKCakyYI76nKU35BUk0doO01WQbdpQCfVg72 P69IfJU+HqPpltZFXg1bcZQ= =hSGA -----END PGP SIGNATURE----- --Apple-Mail-35-286118246-- From mnot@mnot.net Mon Mar 30 12:08: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 6F8123A6A3C for ; Mon, 30 Mar 2009 12:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.874 X-Spam-Level: X-Spam-Status: No, score=-4.874 tagged_above=-999 required=5 tests=[AWL=-2.275, 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 drz-MxgHAGlj for ; Mon, 30 Mar 2009 12:08:26 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id DC1943A67CF for ; Mon, 30 Mar 2009 12:08:25 -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 B2AF4D05C6; Mon, 30 Mar 2009 15:09:20 -0400 (EDT) Message-Id: <67830A60-4ACD-4646-9C46-9B168E7D305A@mnot.net> From: Mark Nottingham To: Apps Discuss , HTTP Working Group 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: New mailing list: hybi (HTTP "long poll" and related protocols) Date: Tue, 31 Mar 2009 06:09:17 +1100 X-Mailer: Apple Mail (2.930.3) Cc: Mark Lentczner , Ian Hickson , Sam Ruby , Greg Wilkins 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, 30 Mar 2009 19:08:27 -0000 As discussed in the APPS area meeting last week, a new mailing list has been created to discuss the standards implications and actions related to HTTP "long poll" techniques (e.g., COMET, BOSH) as well as new protocols that serve similar use cases (e.g., WebSockets, rHTTP). See: https://www.ietf.org/mailman/listinfo/hybi Cheers, -- Mark Nottingham http://www.mnot.net/ From moore@network-heretics.com Mon Mar 30 12:18: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 C3BD23A68BB for ; Mon, 30 Mar 2009 12:18:27 -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 WR9LIdthnxSB for ; Mon, 30 Mar 2009 12:18: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 F17F53A6898 for ; Mon, 30 Mar 2009 12:18:26 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME21152 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 12:18:56 -0700 (PDT) Message-ID: <49D11B1A.9000806@network-heretics.com> Date: Mon, 30 Mar 2009 14:18:50 -0500 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> In-Reply-To: <49D1060E.2030709@cisco.com> Content-Type: text/plain; charset=UTF-8 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: Mon, 30 Mar 2009 19:18:27 -0000 Eliot Lear wrote: > Guys, > > Realistically I don't think we get to have a say on how the publishers > choose their keys for information. I also don't think we get to tell > them what language they do it in. Doing so gets someone into a full > time job just to keep the mapping between IANA names and their names. > Let's not do that. Introducing any coherency concerns would be bad. > This needs to be light weight. If you want to localize, do it in your > implementation. If I understand you correctly, I think you're saying that URNs are not applicable for this problem. Keith From moore@network-heretics.com Mon Mar 30 12:28: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 CDA693A69E9 for ; Mon, 30 Mar 2009 12:28:46 -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, 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 7P98mtsqNKYW for ; Mon, 30 Mar 2009 12:28: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 32AA83A695F for ; Mon, 30 Mar 2009 12:28:46 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME22303 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 12:29:37 -0700 (PDT) Message-ID: <49D11D9F.2060407@network-heretics.com> Date: Mon, 30 Mar 2009 14:29:35 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 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> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> In-Reply-To: <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Mon, 30 Mar 2009 19:28:46 -0000 Patrik Fältström wrote: > On 30 mar 2009, at 18.39, Keith Moore wrote: > >> I realize this is heretical in some circles, but I'll claim that >> embedding the city name in a timezone name is a bug - or at least >> suboptimal. > > Yes, but... > > What you want to do when you use a timezone is to say that an event is > at a specific time according to a specific timezone. How you name that > timezone does not matter. Right? I think it's easy to name time zones in such a way as to cause confusion. > The mapping from locality/lat/long etc to timezone name can in theory be calculated. And this mapping might > also change over time. > > I think therefore in practice, as "events" often are bound to a named > location that you want to go from that location (say London) together > with time at that location to the time in UTC. So in reality you will > probably have names of cities there... London is a misleading example. What happens if the event is in Crossville, Tennessee? It's very close to the boundary between Eastern and Central timezones in the US. Should they be forced to choose between naming their events after the time in Chicago or New York? They might not even know that Chicago is on Central time in the US, but they do know that their local timezone is Central time. (and there's been talk from time to time about Chicago moving to Eastern time to better align itself with New York...) Keith From patrik@frobbit.se Mon Mar 30 12:32: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 B79433A695F for ; Mon, 30 Mar 2009 12:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 0MijJQGnAZbo for ; Mon, 30 Mar 2009 12:32:39 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id C26103A6CAE for ; Mon, 30 Mar 2009 12:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 4A91E4579391; Mon, 30 Mar 2009 21:33:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT2lHuiZGgqE; Mon, 30 Mar 2009 21:33:35 +0200 (CEST) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 95D5C4579386; Mon, 30 Mar 2009 21:33:35 +0200 (CEST) Message-Id: <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Keith Moore In-Reply-To: <49D11D9F.2060407@network-heretics.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: supposing one would want to create a new URN space for timezones... Date: Mon, 30 Mar 2009 21:33:34 +0200 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> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> X-Mailer: Apple Mail (2.930.3) 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: Mon, 30 Mar 2009 19:32:39 -0000 On 30 mar 2009, at 21.29, Keith Moore wrote: > London is a misleading example. What happens if the event is in > Crossville, Tennessee? It's very close to the boundary between > Eastern > and Central timezones in the US. Should they be forced to choose > between naming their events after the time in Chicago or New York? > They > might not even know that Chicago is on Central time in the US, but > they > do know that their local timezone is Central time. (and there's been > talk from time to time about Chicago moving to Eastern time to better > align itself with New York...) First of all, I think the publisher of the timezone information should be able to decide on whatever namespace they want to use. That is sort of the competition between publishers, right? Secondly, I think they could use the name "Crossville, Tennessee, USA" as their timezone entry. That makes it easier for them to later do whatever they want. Patrik From moore@cs.utk.edu Mon Mar 30 12:42: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 DA1193A6C77 for ; Mon, 30 Mar 2009 12:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 ppXlu4h-fYoJ for ; Mon, 30 Mar 2009 12:42: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 1524F3A6A3C for ; Mon, 30 Mar 2009 12:42:01 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME23751 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 12:42:41 -0700 (PDT) Message-ID: <49D120AD.6020408@cs.utk.edu> Date: Mon, 30 Mar 2009 14:42:37 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 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> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> In-Reply-To: <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> 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 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, 30 Mar 2009 19:42:03 -0000 Patrik Fältström wrote:
First of all, I think the publisher of the timezone information should be able to decide on whatever namespace they want to use. That is sort of the competition between publishers, right?
well, it sort of sucks if you're trying to interpret an event with a timezone and you don't have access to that publisher's information. 
Secondly, I think they could use the name "Crossville, Tennessee, USA" as their timezone entry. That makes it easier for them to later do whatever they want.
if the publisher supports it.   but do we really expect publishers to document and keep track of timezones for every city and town on earth?  and if we make timezones very fine-grained, how does this affect the ability to resolve timezone information?

(granted, these days we have access to detailed map data for a good percentage of the earth's land mass, so maybe it's not that farfetched...)

Keith

From lear@cisco.com Mon Mar 30 13: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 6BDAF3A68B4 for ; Mon, 30 Mar 2009 13:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.783 X-Spam-Level: X-Spam-Status: No, score=-7.783 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 golOwHf+Q9y2 for ; Mon, 30 Mar 2009 13:09:34 -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 94C793A6358 for ; Mon, 30 Mar 2009 13:09:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,448,1233532800"; d="scan'208,217";a="276903959" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 20:10:31 +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 n2UKAVZM023569; Mon, 30 Mar 2009 22:10:31 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-107-11.cisco.com [10.61.107.11]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UKAUVX002379; Mon, 30 Mar 2009 20:10:31 GMT Message-ID: <49D12736.9010402@cisco.com> Date: Mon, 30 Mar 2009 22:10:30 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090329 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> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> In-Reply-To: <49D120AD.6020408@cs.utk.edu> Content-Type: multipart/alternative; boundary="------------080104010703030201060307" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2980; t=1238443831; x=1239307831; 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=20to=20c reate=09a=09new=09URN=09space=09for=09timezones... |Sender:=20; bh=3L7N90t8NNw/oVGOVaTSZZ6fJSTR6Fe2FJ3Aije7SIs=; b=DWdlyFb+xmuhpuiPkByNw5Og3UbYW1Q7XCDcHiyzJ2DWXIlYwrR8A/KAWp oxt5mDX/ZfY2s6+Eu2sH8f0r7OjnKsTUZfmORve22TOHyzGG+eIa4Y8Z7+jN Ep1qirAD15; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 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: Mon, 30 Mar 2009 20:09:35 -0000 This is a multi-part message in MIME format. --------------080104010703030201060307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/30/09 9:42 PM, Keith Moore wrote: > Patrik Fältström wrote: >> First of all, I think the publisher of the timezone information >> should be able to decide on whatever namespace they want to use. That >> is sort of the competition between publishers, right? > well, it sort of sucks if you're trying to interpret an event with a > timezone and you don't have access to that publisher's information. >> Secondly, I think they could use the name "Crossville, Tennessee, >> USA" as their timezone entry. That makes it easier for them to later >> do whatever they want. > if the publisher supports it. but do we really expect publishers to > document and keep track of timezones for every city and town on > earth? and if we make timezones very fine-grained, how does this > affect the ability to resolve timezone information? > > (granted, these days we have access to detailed map data for a good > percentage of the earth's land mass, so maybe it's not that farfetched...) --------------080104010703030201060307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/30/09 9:42 PM, Keith Moore wrote:
Patrik Fältström wrote:
First of all, I think the publisher of the timezone information should be able to decide on whatever namespace they want to use. That is sort of the competition between publishers, right?
well, it sort of sucks if you're trying to interpret an event with a timezone and you don't have access to that publisher's information. 
Secondly, I think they could use the name "Crossville, Tennessee, USA" as their timezone entry. That makes it easier for them to later do whatever they want.
if the publisher supports it.   but do we really expect publishers to document and keep track of timezones for every city and town on earth?  and if we make timezones very fine-grained, how does this affect the ability to resolve timezone information?

(granted, these days we have access to detailed map data for a good percentage of the earth's land mass, so maybe it's not that farfetched...)

--------------080104010703030201060307-- From lear@cisco.com Mon Mar 30 13:15: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 77A293A6901 for ; Mon, 30 Mar 2009 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.751 X-Spam-Level: X-Spam-Status: No, score=-7.751 tagged_above=-999 required=5 tests=[AWL=-1.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DMHj5oXc7G-j for ; Mon, 30 Mar 2009 13:15:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 67D0B3A6846 for ; Mon, 30 Mar 2009 13:15:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,448,1233532800"; d="scan'208,217";a="148534412" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-2.cisco.com with ESMTP; 30 Mar 2009 20:16:27 +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 n2UKGQnU024686; Mon, 30 Mar 2009 22:16:26 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-107-11.cisco.com [10.61.107.11]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UKGQ72003499; Mon, 30 Mar 2009 20:16:26 GMT Message-ID: <49D1289A.4070803@cisco.com> Date: Mon, 30 Mar 2009 22:16:26 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090329 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> <0E7911A5-E811-4F96-8D68-F24F39D76066@frobbit.se> <49D11D9F.2060407@network-heretics.com> <301180E3-F666-4E59-AABD-53351F9CF4CE@frobbit.se> <49D120AD.6020408@cs.utk.edu> In-Reply-To: <49D120AD.6020408@cs.utk.edu> Content-Type: multipart/alternative; boundary="------------050304060304030608080000" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4343; t=1238444186; x=1239308186; 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=20to=20c reate=09a=09new=09URN=09space=09for=09timezones... |Sender:=20; bh=rENsc4wKLYBrYDfON/4ySnhStAxncG2xzd8VF42L3DU=; b=a10swRhz14byRqogsS2CQHz1UrEwKVZMPRlQH2hGhCKfQPf3qmTuX4BWt1 qHkzegWcG6saDdprN7Vpyn+XHJh8H2K109M+RQgameqZFDqlYgwOAUsoRB6k 2Q6AQwSu4q; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 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: Mon, 30 Mar 2009 20:15:31 -0000 This is a multi-part message in MIME format. --------------050304060304030608080000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sorry- let's try this again: On 3/30/09 9:42 PM, Keith Moore wrote: > Patrik Fältström wrote: >> First of all, I think the publisher of the timezone information >> should be able to decide on whatever namespace they want to use. That >> is sort of the competition between publishers, right? > well, it sort of sucks if you're trying to interpret an event with a > timezone and you don't have access to that publisher's information. Yes. There needs to be some standard for availability. I wouldn't want a plethora of these things anyway. That just makes for the nightmare that in fact Cyrus is trying to recover from. And so I would suggest setting the bar pretty high before making something a legitimate standard option. >> Secondly, I think they could use the name "Crossville, Tennessee, >> USA" as their timezone entry. That makes it easier for them to later >> do whatever they want. > if the publisher supports it. but do we really expect publishers to > document and keep track of timezones for every city and town on > earth? and if we make timezones very fine-grained, how does this > affect the ability to resolve timezone information? There *is* an entrenched defacto standard here already. The folks on the tz mailing list have a remarkable and under-appreciated track record. The only reason we should want anything more than what there is today, is that some of us are uncomfortable with the succession planning of that team. A URN was the best way I could think of to future proof us against the remote possibility of drastically bad happening. Eliot --------------050304060304030608080000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Sorry- let's try this again:


On 3/30/09 9:42 PM, Keith Moore wrote:
Patrik Fältström wrote:
First of all, I think the publisher of the timezone information should be able to decide on whatever namespace they want to use. That is sort of the competition between publishers, right?
well, it sort of sucks if you're trying to interpret an event with a timezone and you don't have access to that publisher's information.

Yes.  There needs to be some standard for availability.  I wouldn't want a plethora of these things anyway.  That just makes for the nightmare that in fact Cyrus is trying to recover from.  And so I would suggest setting the bar pretty high before making something a legitimate standard option.

Secondly, I think they could use the name "Crossville, Tennessee, USA" as their timezone entry. That makes it easier for them to later do whatever they want.
if the publisher supports it.   but do we really expect publishers to document and keep track of timezones for every city and town on earth?  and if we make timezones very fine-grained, how does this affect the ability to resolve timezone information?

There *is* an entrenched defacto standard here already.   The folks on the tz mailing list have a remarkable and under-appreciated track record.  The only reason we should want anything more than what there is today, is that some of us are uncomfortable with the succession planning of that team.  A URN was the best way I could think of to future proof us against the remote possibility of drastically bad happening.

Eliot
--------------050304060304030608080000-- From moore@cs.utk.edu Mon Mar 30 13:22:11 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 B94953A6968 for ; Mon, 30 Mar 2009 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=0.895, 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 qUBoRCUhJMB1 for ; Mon, 30 Mar 2009 13:22:11 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 1F5033A6846 for ; Mon, 30 Mar 2009 13:22:11 -0700 (PDT) Received: from lust.indecency.org (68-31-145-121.pools.spcsdns.net [68.31.145.121]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME28354 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 13:23:05 -0700 (PDT) Message-ID: <49D12A26.4080307@cs.utk.edu> Date: Mon, 30 Mar 2009 15:23:02 -0500 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> <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> In-Reply-To: <49D1289A.4070803@cisco.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Mon, 30 Mar 2009 20:22:11 -0000  
if the publisher supports it.   but do we really expect publishers to document and keep track of timezones for every city and town on earth?  and if we make timezones very fine-grained, how does this affect the ability to resolve timezone information?

There *is* an entrenched defacto standard here already.   The folks on the tz mailing list have a remarkable and under-appreciated track record.  The only reason we should want anything more than what there is today, is that some of us are uncomfortable with the succession planning of that team.  A URN was the best way I could think of to future proof us against the remote possibility of drastically bad happening.
I honestly don't see how using URNs solves the problem.   If there's nobody around to maintain the timezone databases, nobody who does a good enough job to retain the trust of the software implementors of the world, URN timezone names won't help.

Keith

From Nicolas.Williams@sun.com Mon Mar 30 13:32: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 CFDA73A6D83 for ; Mon, 30 Mar 2009 13:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=0.326, 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 TsJ5vdcU5yR0 for ; Mon, 30 Mar 2009 13:32:41 -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 B40FA3A6D84 for ; Mon, 30 Mar 2009 13:32:38 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2UKXYhj018626 for ; Mon, 30 Mar 2009 20:33:37 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 n2UKXY7G038288 for ; Mon, 30 Mar 2009 14:33:34 -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 n2UKOJsG014270; Mon, 30 Mar 2009 15:24:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2UKOE0K014269; Mon, 30 Mar 2009 15:24:14 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Mar 2009 15:24:14 -0500 From: Nicolas Williams To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090330202413.GF9992@Sun.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D0F5AD.2020509@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: Mon, 30 Mar 2009 20:32:41 -0000 On Mon, Mar 30, 2009 at 11:39:09AM -0500, Keith Moore wrote: > I realize this is heretical in some circles, but I'll claim that > embedding the city name in a timezone name is a bug - or at least > suboptimal. Hear hear! - People know the names of their local timezones. - People don't necessarily live in cities famous enough to appear in timezone names. - People don't necessarily know the timezones of other cities that are famous enough to appear in timezone names. - Some time zones don't relate to famous nearby cities (think of Indiana's time zones). - There are timezones which are not near any famous cities. Yes, names like "PDT", "CST", ... are very country/language-specific, so what? I can learn the ones that are relevant to my activities. And I could find any others given a reasonable directory. That's what we really need: a directory (registry!) of timezone name and country/city name -> GMT offset + daylight savings rules. Also to be registered: coordinates defining the shape and size of each timezone. Given such a directory/registry then URNs that encode city names, names like "PDT", coordinates, and just plain GMT+-offset would all be useful. Nico -- From marc.blanchet@viagenie.ca Mon Mar 30 14:33: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 7EDEA3A6CBE for ; Mon, 30 Mar 2009 14:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 K5cbVVhY7eG2 for ; Mon, 30 Mar 2009 14:33:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5F1113A684D for ; Mon, 30 Mar 2009 14:33:33 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 8101229E1583; Mon, 30 Mar 2009 17:34:31 -0400 (EDT) Message-ID: <49D13AE6.9060004@viagenie.ca> Date: Mon, 30 Mar 2009 17:34:30 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 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> <20090330202413.GF9992@Sun.COM> In-Reply-To: <20090330202413.GF9992@Sun.COM> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Mon, 30 Mar 2009 21:33:34 -0000 I think we(ietf) should: - document/refer to existing practice which is widely used (i.e. Olson db and any other) - keep room for additional interesting work - not try to invent a new scheme for timezones for now. to me, the work is more about how we document/refer the existing practice instead of going into new stuff. If external references are not stable or consistent or ..., then we should look into owning it. if there are ok, then we should only refer to it. marc. Nicolas Williams a écrit : > On Mon, Mar 30, 2009 at 11:39:09AM -0500, Keith Moore wrote: >> I realize this is heretical in some circles, but I'll claim that >> embedding the city name in a timezone name is a bug - or at least >> suboptimal. > > Hear hear! > > - People know the names of their local timezones. > - People don't necessarily live in cities famous enough to appear in > timezone names. > - People don't necessarily know the timezones of other cities that are > famous enough to appear in timezone names. > - Some time zones don't relate to famous nearby cities (think of > Indiana's time zones). > - There are timezones which are not near any famous cities. > > Yes, names like "PDT", "CST", ... are very country/language-specific, so > what? I can learn the ones that are relevant to my activities. And I > could find any others given a reasonable directory. > > That's what we really need: a directory (registry!) of timezone name and > country/city name -> GMT offset + daylight savings rules. Also to be > registered: coordinates defining the shape and size of each timezone. > > Given such a directory/registry then URNs that encode city names, names > like "PDT", coordinates, and just plain GMT+-offset would all be useful. > > Nico -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From lisa.dusseault@gmail.com Mon Mar 30 15:56: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 C83903A6A3C for ; Mon, 30 Mar 2009 15:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=1.176, 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 45r3eiew+eSQ for ; Mon, 30 Mar 2009 15:56:00 -0700 (PDT) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.149]) by core3.amsl.com (Postfix) with ESMTP id DEEB83A69A1 for ; Mon, 30 Mar 2009 15:55:59 -0700 (PDT) Received: by qw-out-1920.google.com with SMTP id 5so1615954qwc.22 for ; Mon, 30 Mar 2009 15:56:58 -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=LhhjvPKPPHEYSdmxDqgf0XvJVkDkH7QgH/TEduxD3Iw=; b=AJD48XR+tw8QOdJ1Two9VdpPbG4DWVP7TS1oNijigcWOXGHLaGuv8YMBH3kHFz0Dkn BI3zKNsqQScDHpl8WePPLlv4vxIU6duGa4+NM9CmPeGpOm5Y2g/scEsQ9+4JNahPmypL Iw+X6N93cadwGy/A9wxjtcWRAchS18BWjrwJQ= 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=NLzzDiYpYpIp/IgtdiJkIP06eYhTslHCHNDCzEAimar+pvbhfm5pDkjtHtnsTl7F/f S5N7ANjCGoesIbPOHHfz98Nxps8vEsAX+totPVTmbcTN9s0wmDoOOpLyiXWm1d0judwF t/cAmPhwkhT2aqbgmUt2z7by+ZaZvdtjv7zLc= MIME-Version: 1.0 Received: by 10.220.73.203 with SMTP id r11mr1930115vcj.61.1238453817210; Mon, 30 Mar 2009 15:56:57 -0700 (PDT) In-Reply-To: <49D0F39E.3080206@network-heretics.com> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> Date: Mon, 30 Mar 2009 15:56:57 -0700 Message-ID: Subject: Re: supposing one would want to create a new URN space for timezones... From: Lisa Dusseault To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 30 Mar 2009 22:56:00 -0000 On Mon, Mar 30, 2009 at 9:30 AM, Keith Moore w= rote: > It doesn't matter. =A0The 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. For example, a persistent URN could point to US/California timezone information, for the period over which that area has consistent timezone information. If in 2013 California timezones splits into Norcal and Socal, the US/California URN could point to a timezone information resource that says "I end in 2013", and two new URNs could be created to point to US/California/NorCal and US/California/SoCal. The resource referenced by the first URN could even point to the two new things once they're known. I imagine that if an area is ever joined-- if the eastern bit of Oregon ever rejoined Oregon -- we'd preserve the more granular divisions anyway for as long as clients refer to them (forever). And in general we've seen that city names, though there are language variants, are on the whole more stable than political divisions. An example, you might have both Europe/Cheb and Europe/Eger, a city with two names but either more stable than referring to the controller of the area of Sudetenland. It's also OK if Europe/Wien or Europe/Prague also refer to the same timezone definitions or different ones. S Lisa From Martin.Thomson@andrew.com Mon Mar 30 16:08: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 932B33A6934 for ; Mon, 30 Mar 2009 16:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 mpHHOrfMA5Zr for ; Mon, 30 Mar 2009 16:08:58 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3EE3D3A68DF for ; Mon, 30 Mar 2009 16:08:58 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_30_18_30_08 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 30 Mar 2009 18:30:08 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 18:09:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B18C.A353552C" Subject: RE: supposing one would want to create a new URN space for timezones... Date: Mon, 30 Mar 2009 18:09:53 -0500 Message-ID: In-Reply-To: <248bcd790903300733x1c48ddabr976439cb19843152@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: supposing one would want to create a new URN space for timezones... Thread-Index: AcmxRIWNMzkZaKMcTEeInijzpbfT0wAR6ebA References: <49D0CBA3.7090409@cisco.com> <248bcd790903300733x1c48ddabr976439cb19843152@mail.gmail.com> From: "Thomson, Martin" To: "Timur Shemsedinov" , "Eliot Lear" X-OriginalArrivalTime: 30 Mar 2009 23:09:55.0396 (UTC) FILETIME=[A388D040:01C9B18C] 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: Mon, 30 Mar 2009 23:08:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B18C.A353552C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgYSBwcm90b2NvbCBkZWZpbmVkIGluIHRoZSBJRVRGIGZvciByZXNvbHZpbmcgYSBs b2NhdGlvbiAobGF0L2xuZykgdG8gYSBVUk4uICBJbml0aWFsbHksIHRoaXMgd2FzIGRlZmluZWQg c28gdGhhdCB5b3UgY291bGQgZmluZCB5b3VyIGxvY2FsIGVtZXJnZW5jeSBzZXJ2aWNlcyBVUkks IGJ1dCBpdCB3b3VsZCB3b3JrIHF1aXRlIHdlbGwgZm9yIFRacy4gIFJGQyA1MjIyIChMb1NUKS4g IEhvd2V2ZXIsIGEgcmV2ZXJzZSBtYXBwaW5nIGlzIG5vdCBkZWZpbmVkLg0KDQogDQoNCkZyb206 IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW11ciBTaGVtc2VkaW5vdg0KU2VudDogVHVlc2Rh eSwgMzEgTWFyY2ggMjAwOSAxOjM0IEFNDQpUbzogRWxpb3QgTGVhcg0KQ2M6IEFwcHMgRGlzY3Vz cw0KU3ViamVjdDogUmU6IHN1cHBvc2luZyBvbmUgd291bGQgd2FudCB0byBjcmVhdGUgYSBuZXcg VVJOIHNwYWNlIGZvciB0aW1lem9uZXMuLi4NCg0KIA0KDQpJdCdzIGEgZ29vZCBpZGVhLCBJIGFt IGluIG5lZWQgb2Ygc3VjaCBVUk4gZm9yIGEgbG9uZyB0aW1lLg0KQnV0IEkgbXVzdCBub3RlIHRo YXQ6DQoxLiBUaW1lem9uZXMgYXJlIGluZGVwZW5kZW50IGZyb20gYXV0aG9yaXR5LiBUaW1lem9u ZXMgcmVndWxhdGlvbiBpcyBpbiBqdXJpc2RpY3Rpb24gb2YgbG9jYWwgZ292ZXJubWVudCBvZiBl YWNoIHRlcnJpdG9yeS4NCjIuIFRpbWV6b25lcyBhcmUgbm90IHN0YWJsZSBmcm9tIHllYXIgdG8g eWVhciwgcmVndWxhdGlvbiBjYW4gYmUgY2hhbmdlZCBieSBsb2NhbCBnb3Zlcm5tZW50Lg0KMy4g VGltZXpvbmVzIGFyZSByZWxhdGVkIHRvIExhdC9Mb25nIGNvb3JkaW5hdGVzLCBzbyB3ZSBjYW4g cmVzb2x2ZSBMYXQvTG9uZyB0byB0aW1lem9uZS4NCjQuIERheWxpZ2h0IHNhdmluZyB0aW1lIHNo b3VsZCBiZSBjb25zaWRlcmVkIHRvby4NCjUuIFdoaWNoIGxhbmd1YWdlIGRvIHlvdSBwcmVmZXIg dG8gbmFtZSB0aW1lem9uZXM/IEVuZ2xpc2ggLyB3aHkgbm90IGxvY2FsIGxhbmd1YWdlcz8NCg0K SSBoYXZlIGZvbGxvd2luZyBwcm9wb3NpdGlvbjoNCjEuIENvbWJpbmUgdGltZSwgZ2VvZ3JhcGhp Y2FsIGNvb3JkaW5hdGVzIGFuZCB0aW1lem9uZXMgaW4gb25lIFVSTg0KMi4gRGV2ZWxvcCBtZWNo YW5pc20gZm9yIHJlc29sdmluZyBMYXQvTG9uZyB0byBUaW1lem9uZSBhbmQgYmFja3dhcmQsIGds b2JhbCB0aW1lIHRvIGxvY2FsIHRpbWUgYW5kIGJhY2t3YXJkDQoNCk9uIE1vbiwgTWFyIDMwLCAy MDA5IGF0IDM6MzkgUE0sIEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPiB3cm90ZToNCg0KLi4u IHdvdWxkIHRoaXMgYW1vdW50IHRvIGEgbmV3IE5JRCwgb3IgaXMgdGhlcmUgc29tZXBsYWNlIHdl IHNob3VsZCBoYW5nIHRoaXM/DQoNCk15IHRoaW5raW5nIGJ5IHRoZSB3YXkgd291bGQgYmUgc29t ZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZzoNCg0KLi4uOlRJTUVaT05FOkF1dGhvcml0eTpUaW1l em9uZSBOYW1lDQoNCndoZXJlIGF1dGhvcml0eSB3b3VsZCBiZSAoYXQgbGVhc3QgaW5pdGlhbGx5 KSBvbmUgb2YgdGhyZWUgdGhpbmdzOg0KDQoxLiAgT2xzb24NCjIuICBJRUVFDQozLiAgTWljcm9z b2Z0DQoNClRoZSBuZWVkIGZvciBpbnRlcm9wZXJhYmlsaXR5IGRpY3RhdGVzIG9uZSBwcmVmZXJy ZWQgbWV0aG9kLCB3aGljaCBJTUhPIHNob3VsZCBiZSBPbHNvbi4NCg0KVGhvdWdodHM/DQoNCkVs aW90DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXBw cy1EaXNjdXNzIG1haWxpbmcgbGlzdA0KQXBwcy1EaXNjdXNzQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0KDQogDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUg ZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHBy b3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0K dGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpbbWYyXQ0K ------_=_NextPart_001_01C9B18C.A353552C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxl Pg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxk aXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzI0NDA2MSc+VGhlcmUgaXMgYSBwcm90b2NvbCBkZWZpbmVkIGluIHRoZSBJRVRGIGZvciByZXNv bHZpbmcgYSBsb2NhdGlvbg0KKGxhdC9sbmcpIHRvIGEgVVJOLsKgIEluaXRpYWxseSwgdGhpcyB3 YXMgZGVmaW5lZCBzbyB0aGF0IHlvdSBjb3VsZCBmaW5kIHlvdXINCmxvY2FsIGVtZXJnZW5jeSBz ZXJ2aWNlcyBVUkksIGJ1dCBpdCB3b3VsZCB3b3JrIHF1aXRlIHdlbGwgZm9yIFRacy7CoCBSRkMg NTIyMg0KKExvU1QpLsKgIEhvd2V2ZXIsIGEgcmV2ZXJzZSBtYXBwaW5nIGlzIG5vdCBkZWZpbmVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6DQoiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz4gYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcNClttYWls dG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+VGlt dXIgU2hlbXNlZGlub3Y8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgMzEgTWFyY2ggMjAwOSAx OjM0IEFNPGJyPg0KPGI+VG86PC9iPiBFbGlvdCBMZWFyPGJyPg0KPGI+Q2M6PC9iPiBBcHBzIERp c2N1c3M8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHN1cHBvc2luZyBvbmUgd291bGQgd2FudCB0 byBjcmVhdGUgYSBuZXcgVVJOIHNwYWNlIGZvcg0KdGltZXpvbmVzLi4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+SXQncyBhIGdvb2QgaWRlYSwgSSBhbSBpbiBuZWVkDQpvZiBzdWNoIFVSTiBmb3Ig YSBsb25nIHRpbWUuPGJyPg0KQnV0IEkgbXVzdCBub3RlIHRoYXQ6PGJyPg0KMS4gVGltZXpvbmVz IGFyZSBpbmRlcGVuZGVudCBmcm9tIGF1dGhvcml0eS4gVGltZXpvbmVzIHJlZ3VsYXRpb24gaXMg aW4NCmp1cmlzZGljdGlvbiBvZiBsb2NhbCBnb3Zlcm5tZW50IG9mIGVhY2ggdGVycml0b3J5Ljxi cj4NCjIuIFRpbWV6b25lcyBhcmUgbm90IHN0YWJsZSBmcm9tIHllYXIgdG8geWVhciwgcmVndWxh dGlvbiBjYW4gYmUgY2hhbmdlZCBieQ0KbG9jYWwgZ292ZXJubWVudC48YnI+DQozLiBUaW1lem9u ZXMgYXJlIHJlbGF0ZWQgdG8gTGF0L0xvbmcgY29vcmRpbmF0ZXMsIHNvIHdlIGNhbiByZXNvbHZl IExhdC9Mb25nIHRvDQp0aW1lem9uZS48YnI+DQo0LiBEYXlsaWdodCBzYXZpbmcgdGltZSBzaG91 bGQgYmUgY29uc2lkZXJlZCB0b28uPGJyPg0KNS4gV2hpY2ggbGFuZ3VhZ2UgZG8geW91IHByZWZl ciB0byBuYW1lIHRpbWV6b25lcz8gRW5nbGlzaCAvIHdoeSBub3QgbG9jYWwNCmxhbmd1YWdlcz88 YnI+DQo8YnI+DQpJIGhhdmUgZm9sbG93aW5nIHByb3Bvc2l0aW9uOjxicj4NCjEuIENvbWJpbmUg dGltZSwgZ2VvZ3JhcGhpY2FsIGNvb3JkaW5hdGVzIGFuZCB0aW1lem9uZXMgaW4gb25lIFVSTjxi cj4NCjIuIERldmVsb3AgbWVjaGFuaXNtIGZvciByZXNvbHZpbmcgTGF0L0xvbmcgdG8gVGltZXpv bmUgYW5kIGJhY2t3YXJkLCBnbG9iYWwNCnRpbWUgdG8gbG9jYWwgdGltZSBhbmQgYmFja3dhcmQ8 bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPk9uIE1vbiwgTWFy IDMwLCAyMDA5IGF0IDM6MzkgUE0sIEVsaW90IExlYXIgJmx0OzxhDQpocmVmPSJtYWlsdG86bGVh ckBjaXNjby5jb20iPmxlYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4uLi4gd291bGQgdGhpcyBhbW91bnQgdG8gYSBuZXcgTklE LCBvciBpcyB0aGVyZSBzb21lcGxhY2Ugd2UNCnNob3VsZCBoYW5nIHRoaXM/PGJyPg0KPGJyPg0K TXkgdGhpbmtpbmcgYnkgdGhlIHdheSB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93 aW5nOjxicj4NCjxicj4NCi4uLjpUSU1FWk9ORTpBdXRob3JpdHk6VGltZXpvbmUgTmFtZTxicj4N Cjxicj4NCndoZXJlIGF1dGhvcml0eSB3b3VsZCBiZSAoYXQgbGVhc3QgaW5pdGlhbGx5KSBvbmUg b2YgdGhyZWUgdGhpbmdzOjxicj4NCjxicj4NCjEuICZuYnNwO09sc29uPGJyPg0KMi4gJm5ic3A7 SUVFRTxicj4NCjMuICZuYnNwO01pY3Jvc29mdDxicj4NCjxicj4NClRoZSBuZWVkIGZvciBpbnRl cm9wZXJhYmlsaXR5IGRpY3RhdGVzIG9uZSBwcmVmZXJyZWQgbWV0aG9kLCB3aGljaCBJTUhPIHNo b3VsZA0KYmUgT2xzb24uPGJyPg0KPGJyPg0KVGhvdWdodHM/PGJyPg0KPGJyPg0KRWxpb3Q8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFw cHMtRGlzY3VzcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QXBwcy1EaXNjdXNz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QXBwcy1EaXNjdXNzQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNj dXNzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hcHBzLWRpc2N1c3M8L2E+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGJy Pjxicj48dGFibGUgYmdjb2xvcj13aGl0ZSBzdHlsZT0iY29sb3I6YmxhY2siPjx0cj48dGQ+PGJy Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aXMmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtkZXNpZ25hdGVkJm5ic3A7cmVj aXBpZW50Jm5ic3A7b25seSZuYnNwO2FuZCZuYnNwO21heTxicj4NCmNvbnRhaW4mbmJzcDtwcml2 aWxlZ2VkLCZuYnNwO3Byb3ByaWV0YXJ5LCZuYnNwO29yJm5ic3A7b3RoZXJ3aXNlJm5ic3A7cHJp dmF0ZSZuYnNwO2luZm9ybWF0aW9uLiZuYnNwOyZuYnNwOzxicj4NCklmJm5ic3A7eW91Jm5ic3A7 aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7aXQmbmJzcDtpbiZuYnNwO2Vycm9yLCZuYnNwO3BsZWFz ZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO3NlbmRlcjxicj4NCmltbWVkaWF0ZWx5Jm5ic3A7 YW5kJm5ic3A7ZGVsZXRlJm5ic3A7dGhlJm5ic3A7b3JpZ2luYWwuJm5ic3A7Jm5ic3A7QW55Jm5i c3A7dW5hdXRob3JpemVkJm5ic3A7dXNlJm5ic3A7b2Y8YnI+DQp0aGlzJm5ic3A7ZW1haWwmbmJz cDtpcyZuYnNwO3Byb2hpYml0ZWQuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KW21mMl08L3RkPjwvdHI+PC90YWJsZT48L2JvZHk+DQoNCjwvaHRtbD4N Cg== ------_=_NextPart_001_01C9B18C.A353552C-- From patrik@frobbit.se Mon Mar 30 20:03: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 2FE8528C0FF for ; Mon, 30 Mar 2009 20:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 r20OIURjkCZ0 for ; Mon, 30 Mar 2009 20:03:02 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 8CDC03A6AD6 for ; Mon, 30 Mar 2009 20:02:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 43B86458AE44; Tue, 31 Mar 2009 05:03:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZbOWKnczD38; Tue, 31 Mar 2009 05:03:55 +0200 (CEST) Received: from [192.168.1.95] (frobbit.cust.teleservice.net [85.30.128.225]) by srv01.frobbit.se (Postfix) with ESMTP id 68B48458AE35; Tue, 31 Mar 2009 05:03:55 +0200 (CEST) Message-Id: <6D5353F6-C403-472C-AACC-A526D1B042F2@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Nicolas Williams In-Reply-To: <20090330202413.GF9992@Sun.COM> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-47-315914121" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: supposing one would want to create a new URN space for timezones... Date: Tue, 31 Mar 2009 05:03:55 +0200 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> <20090330202413.GF9992@Sun.COM> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) 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: Tue, 31 Mar 2009 03:03:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-47-315914121 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 30 mar 2009, at 22.24, Nicolas Williams wrote: > Yes, names like "PDT", "CST", ... are very country/language- > specific, so > what? I can learn the ones that are relevant to my activities. And I > could find any others given a reasonable directory. > > That's what we really need: a directory (registry!) of timezone name > and > country/city name -> GMT offset + daylight savings rules. Also to be > registered: coordinates defining the shape and size of each timezone. I think we look at two different problems here, and Eliot suggested we should solve one of them (the first): 1. Have one way of globally naming the timezone entries, including past and future history, without injecting ourselves in the work the publishers of the TZ databases do, and definitely not injecting ourselves into the work the parties do that define the TZ entries. 2. Have a way to know, given city/lat/long/whatever, what TZ entry to use (over time). I claim Eliot asked for a solution to the first, not the 2nd. Patrik --Apple-Mail-47-315914121 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJ0YgbrMabGguI180RAgJXAJ97R/BrppzOA5drVH3LUxs6UcpVyACeO2mW mVogONPplpAx3JTkd6eZteg= =Z3GR -----END PGP SIGNATURE----- --Apple-Mail-47-315914121-- From patrik@frobbit.se Mon Mar 30 20: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 699993A6B68 for ; Mon, 30 Mar 2009 20:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 8m+qWh2hepCU for ; Mon, 30 Mar 2009 20:04:29 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 6A9CC3A6AF5 for ; Mon, 30 Mar 2009 20:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D0FF3458AEDB; Tue, 31 Mar 2009 05:05:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iib6qbY+Yx67; Tue, 31 Mar 2009 05:05:27 +0200 (CEST) Received: from [192.168.1.95] (frobbit.cust.teleservice.net [85.30.128.225]) by srv01.frobbit.se (Postfix) with ESMTP id 0FE71458AECC; Tue, 31 Mar 2009 05:05:27 +0200 (CEST) Message-Id: <5536EC67-B4E1-4E68-AA1B-806678D1E9D8@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lisa Dusseault In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-48-316006017" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: supposing one would want to create a new URN space for timezones... Date: Tue, 31 Mar 2009 05:05:27 +0200 References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) 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: Tue, 31 Mar 2009 03:04:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-48-316006017 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 31 mar 2009, at 00.56, Lisa Dusseault wrote: > 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. I would be MUCH more reliable to have the URN in an iCal object than, as often today, the TZ rule itself. Specifically for events in the future... Patrik --Apple-Mail-48-316006017 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJ0Yh3rMabGguI180RAmxWAJ9oUEFbljkMTloAg9+ppEKpDs0irACaAnoU txE/DEHAY3mOvpSrfc/jePw= =wYRS -----END PGP SIGNATURE----- --Apple-Mail-48-316006017-- From moore@network-heretics.com Mon Mar 30 20:22: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 3FC3D28C0D0 for ; Mon, 30 Mar 2009 20:22: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 EkuYJNUxksgj for ; Mon, 30 Mar 2009 20:22: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 734C53A682A for ; Mon, 30 Mar 2009 20:22:46 -0700 (PDT) Received: from lust.indecency.org (173-6-24-146.pools.spcsdns.net [173.6.24.146] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME67218 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 20:23:37 -0700 (PDT) Message-ID: <49D18CB7.4010409@network-heretics.com> Date: Mon, 30 Mar 2009 22:23:35 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Lisa Dusseault 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> In-Reply-To: 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: Tue, 31 Mar 2009 03:22:50 -0000 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. > > For example, a persistent URN could point to US/California timezone > information, for the period over which that area has consistent > timezone information. If in 2013 California timezones splits into > Norcal and Socal, the US/California URN could point to a timezone > information resource that says "I end in 2013", and two new URNs could > be created to point to US/California/NorCal and US/California/SoCal. > The resource referenced by the first URN could even point to the two > new things once they're known. yes you could do that. and it's fine, as long as you don't issue a new URN every time the definition of a timezone changes. but you really don't want to include any kind of precise geographic information in the URN - no more precise than necessary. for most of the world, an ISO 3166 country code should be sufficient to define the timezone. for those few countries large enough (in longitude) to have multiple timezones, the country code + the accepted abbreviations of the timezone names used in those countries should be sufficient. (beware: I18N considerations might lurk here) there might be a few special cases, like the 3 timezones in Indiana, but the special cases can be expected to be relatively few. similarly for the occasions when it's necessary to deprecate a timezone name in favor of one or more new ones. Keith From patrik@frobbit.se Mon Mar 30 20:31: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 F343B3A6880 for ; Mon, 30 Mar 2009 20:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 W9PzRs3zaEIp for ; Mon, 30 Mar 2009 20:31:16 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id ECA0E3A67D8 for ; Mon, 30 Mar 2009 20:31:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id E1144458C504; Tue, 31 Mar 2009 05:32:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh7ehJY-FTdW; Tue, 31 Mar 2009 05:32:13 +0200 (CEST) Received: from [192.168.1.95] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 44DE6458C4F9; Tue, 31 Mar 2009 05:32:13 +0200 (CEST) Message-Id: <001514EC-4705-4DC9-A9AD-F960B0FBAD03@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Keith Moore In-Reply-To: <49D18CB7.4010409@network-heretics.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-55-317610942" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: supposing one would want to create a new URN space for timezones... Date: Tue, 31 Mar 2009 05:32:12 +0200 References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <49D18CB7.4010409@network-heretics.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) 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: Tue, 31 Mar 2009 03:31:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-55-317610942 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 31 mar 2009, at 05.23, Keith Moore wrote: > yes you could do that. and it's fine, as long as you don't issue a > new > URN every time the definition of a timezone changes. but you really > don't want to include any kind of precise geographic information in > the > URN - no more precise than necessary. Good point. I just took for granted that the URN was referring to a specific TZ "entry" (like "sweden") and what you got back was multiple TZ rules, each having a time interval when it is/was/will be valid. To know which one of the rules to use, you have to take the time of the event you want to do the calculations on, and select the portion of the returned data you are interested in. Patrik --Apple-Mail-55-317610942 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJ0Y68rMabGguI180RAgxAAJ97qJ5IkL3qh6R6SITD/9BP86zM1gCeIY4b 1D1CUZQJpcVuk/TOazZvTCA= =igk2 -----END PGP SIGNATURE----- --Apple-Mail-55-317610942-- From moore@network-heretics.com Mon Mar 30 20:48: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 1C8A428C121 for ; Mon, 30 Mar 2009 20:48:08 -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, 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 3rpHWVVITFUj for ; Mon, 30 Mar 2009 20:48: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 7AF2028C100 for ; Mon, 30 Mar 2009 20:48:07 -0700 (PDT) Received: from lust.indecency.org (173-6-24-146.pools.spcsdns.net [173.6.24.146] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME69703 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 20:49:01 -0700 (PDT) Message-ID: <49D192AB.4090800@network-heretics.com> Date: Mon, 30 Mar 2009 22:48:59 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 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> <5536EC67-B4E1-4E68-AA1B-806678D1E9D8@frobbit.se> In-Reply-To: <5536EC67-B4E1-4E68-AA1B-806678D1E9D8@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Tue, 31 Mar 2009 03:48:08 -0000 Patrik Fältström wrote: > On 31 mar 2009, at 00.56, Lisa Dusseault wrote: > >> 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. > > I would be MUCH more reliable to have the URN in an iCal object than, as > often today, the TZ rule itself. Specifically for events in the future... with or without URN resolution to online versions of those iCalendar rules? Keith From patrik@frobbit.se Mon Mar 30 20:50: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 5902128C11F for ; Mon, 30 Mar 2009 20:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 58KavJf0bc-t for ; Mon, 30 Mar 2009 20:50:08 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 5CE4428C100 for ; Mon, 30 Mar 2009 20:50:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id EBCC6458C92C; Tue, 31 Mar 2009 05:51:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY0RTGGcF-i8; Tue, 31 Mar 2009 05:51:05 +0200 (CEST) Received: from [192.168.1.95] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 49F8E458C921; Tue, 31 Mar 2009 05:51:05 +0200 (CEST) Message-Id: <839ED2E2-3179-4192-AC4F-2CDA5CAC2D1E@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Keith Moore In-Reply-To: <49D192AB.4090800@network-heretics.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-57-318713856" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: supposing one would want to create a new URN space for timezones... Date: Tue, 31 Mar 2009 05:50:35 +0200 References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <5536EC67-B4E1-4E68-AA1B-806678D1E9D8@frobbit.se> <49D192AB.4090800@network-heretics.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) 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: Tue, 31 Mar 2009 03:50:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-57-318713856 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 31 mar 2009, at 05.48, Keith Moore wrote: > Patrik F=E4ltstr=F6m wrote: >> On 31 mar 2009, at 00.56, Lisa Dusseault wrote: >> >>> 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 =20 >>> point >>> at which the URN ceases to refer to a single timezone. >> >> I would be MUCH more reliable to have the URN in an iCal object =20 >> than, as >> often today, the TZ rule itself. Specifically for events in the =20 >> future... > > with or without URN resolution to online versions of those iCalendar =20= > rules? I always prefer with, if possible. Given a unique name (for the series of rules), please give the rules =20 back. I see it being possible to do URN resolution of some kind as part of =20 that, yes. Patrik --Apple-Mail-57-318713856 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJ0ZMLrMabGguI180RAoD0AJ9JCPzySvZPJ7uP8BSRANorEAzG7ACePa3v BIDVuKWtYoNqGxZLFHs1I5I= =G59A -----END PGP SIGNATURE----- --Apple-Mail-57-318713856-- From moore@network-heretics.com Mon Mar 30 20: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 BDE173A68A6 for ; Mon, 30 Mar 2009 20:58:15 -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 KTXFy5sdyB3s for ; Mon, 30 Mar 2009 20:58:15 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 151653A65A6 for ; Mon, 30 Mar 2009 20:58:15 -0700 (PDT) Received: from lust.indecency.org (173-6-24-146.pools.spcsdns.net [173.6.24.146] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME70554 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 20:58:07 -0700 (PDT) Message-ID: <49D194CC.80100@network-heretics.com> Date: Mon, 30 Mar 2009 23:58:04 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: supposing one would want to create a new URN space for timezones... References: <49D0CBA3.7090409@cisco.com> <248bcd790903300733x1c48ddabr976439cb19843152@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Tue, 31 Mar 2009 03:58:15 -0000 Thomson, Martin wrote: > There is a protocol defined in the IETF for resolving a location > (lat/lng) to a URN. Initially, this was defined so that you could find > your local emergency services URI, but it would work quite well for > TZs. RFC 5222 (LoST). However, a reverse mapping is not defined. separate problem. let's get the basic URNs defined first, then the resolution for those URNs. note that global mapping lat/lng to tz names is a geopolitical mine field. we *really* do not want to get IETF, IANA, ISOC, or any I* (except perhaps ISO or ITU :) ) into the business of deciding which country a particular lat/lng pair falls into. that's enough to start a war, or at least get traffic to the resolution server banned in several countries. Keith From fluffy@cisco.com Mon Mar 30 20:59: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 812B228C121 for ; Mon, 30 Mar 2009 20:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.431 X-Spam-Level: X-Spam-Status: No, score=-106.431 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 pdwm0CtruQQK for ; Mon, 30 Mar 2009 20:58:59 -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 B298D3A69F2 for ; Mon, 30 Mar 2009 20:58:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,450,1233532800"; d="scan'208";a="277127140" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2009 03:59:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2V3xwqO019342; Mon, 30 Mar 2009 20:59:58 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2V3xvKl010992; Tue, 31 Mar 2009 03:59:57 GMT From: Cullen Jennings To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6D5353F6-C403-472C-AACC-A526D1B042F2@frobbit.se> Impp: xmpp:cullenfluffyjennings@jabber.org 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> <20090330202413.GF9992@Sun.COM> <6D5353F6-C403-472C-AACC-A526D1B042F2@frobbit.se> Message-Id: <72E8BA2D-AAA3-4787-A33F-50FCA052A3B7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 21:59:56 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=273; t=1238471998; x=1239335998; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20supposing=20one=20would=20want=20to=20c reate=20a=09new=09URN=09space=09for=09timezones... |Sender:=20; bh=tV6Ek0sHms+ipbQHuN5tLUqqCYomd/NTOKoLPjCmysQ=; b=assUrriqJDNJzwBGdZiM25NtfHqex3BMGHnGqccJUMNrfzV64g+CAONfLC FAXVfAm3i3rw4QfYxgP7SLD6cpw1UJ8EcdOJ8aG68obiH2kGJYtx2tCLjhyj gsKyoofJOR; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Apps Discuss , Eliot Lear , 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: Tue, 31 Mar 2009 03:59:00 -0000 On Mar 30, 2009, at 9:03 PM, Patrik F=E4ltstr=F6m wrote: > 2. Have a way to know, given city/lat/long/whatever, what TZ entry =20 > to use (over time). This is a hair-brain idea but .... LOST might be a protocol that was a =20= good match to solve the second. From moore@network-heretics.com Mon Mar 30 20:59:20 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 054E928C100 for ; Mon, 30 Mar 2009 20:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 MO0Vhp6CBOYM for ; Mon, 30 Mar 2009 20:59:19 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 100F73A68D2 for ; Mon, 30 Mar 2009 20:59:19 -0700 (PDT) Received: from lust.indecency.org (173-6-24-146.pools.spcsdns.net [173.6.24.146] (may be forged)) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BME70682 (AUTH admin@network-heretics.com); Mon, 30 Mar 2009 20:59:13 -0700 (PDT) Message-ID: <49D1950F.8050300@network-heretics.com> Date: Mon, 30 Mar 2009 23:59:11 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 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> <5536EC67-B4E1-4E68-AA1B-806678D1E9D8@frobbit.se> <49D192AB.4090800@network-heretics.com> <839ED2E2-3179-4192-AC4F-2CDA5CAC2D1E@frobbit.se> In-Reply-To: <839ED2E2-3179-4192-AC4F-2CDA5CAC2D1E@frobbit.se> 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: Tue, 31 Mar 2009 03:59:20 -0000 >>> I would be MUCH more reliable to have the URN in an iCal object than, as >>> often today, the TZ rule itself. Specifically for events in the >>> future... >> >> with or without URN resolution to online versions of those iCalendar >> rules? > > I always prefer with, if possible. I'd love to see it. But who would pay to run the servers? From cyrus@daboo.name Mon Mar 30 21:11:20 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 940E628C12C for ; Mon, 30 Mar 2009 21:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=-1.236, 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 U6mwTgyLVy-l for ; Mon, 30 Mar 2009 21:11:19 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 94C5128C130 for ; Mon, 30 Mar 2009 21:11:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 14EC31318515; Tue, 31 Mar 2009 00:12:18 -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 FkD0H1Irw08u; Tue, 31 Mar 2009 00:12:17 -0400 (EDT) Received: from [17.101.35.28] (unknown [10.0.1.1]) by daboo.name (Postfix) with ESMTP id 4E4581318507; Tue, 31 Mar 2009 00:12:16 -0400 (EDT) Date: Tue, 31 Mar 2009 00:12:15 -0400 From: Cyrus Daboo To: Keith Moore , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: In-Reply-To: <49D1950F.8050300@network-heretics.com> References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <5536EC67-B4E1-4E68-AA1B-806678D1E9D8@frobbit.se> <49D192AB.4090800@network-heretics.com> <839ED2E2-3179-4192-AC4F-2CDA5CAC2D1E@frobbit.se> <49D1950F.8050300@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=1335 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: Tue, 31 Mar 2009 04:11:20 -0000 Hi Keith, --On March 30, 2009 11:59:11 PM -0400 Keith Moore wrote: >>> with or without URN resolution to online versions of those iCalendar >>> rules? >> >> I always prefer with, if possible. > > I'd love to see it. But who would pay to run the servers? Well that is what we have been talking about in CalConnect. The key thing is who benefits from this - mostly the OS vendors who would be able to push timely updates to timezone data out without having to do a a full OS update/patch etc. Also anyone with a Calendaring & Scheduling service would likely offer something similar (and probably already do in some fashion). A good comparison would be to NTP - most OS's come configured with an ntp server - several OS vendors run there own - I would expect to see the same thing happen for timezones. Admittedly this would be a "bigger" service than NTP. This is somewhat reflected in the diagram in my apps area slides that show a tiered architecture for what we call "providers" - organizations offering a timezone service to "consumers". We would expect to see a few large organizations offering "tier 1" services, and then possibly many others offering a "tier 2" service more closely located with the actual "consumer" - these would be caches of the tier 1 servers. -- Cyrus Daboo From duerst@it.aoyama.ac.jp Tue Mar 31 03:32: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 6570C3A6B7E for ; Tue, 31 Mar 2009 03:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.517 X-Spam-Level: X-Spam-Status: No, score=0.517 tagged_above=-999 required=5 tests=[AWL=0.307, 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 yYN3e7ueR5Q7 for ; Tue, 31 Mar 2009 03:32:40 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 8C6C33A68CD for ; Tue, 31 Mar 2009 03:32:38 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n2VAWVPl015050 for ; Tue, 31 Mar 2009 19:33:27 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 6253_3d63d6c4_1ddf_11de_94d1_001d0969ab06; Tue, 31 Mar 2009 19:32:31 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57993) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 31 Mar 2009 19:23:50 +0900 Message-ID: <49D1F12D.3040009@it.aoyama.ac.jp> Date: Tue, 31 Mar 2009 19:32:13 +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> In-Reply-To: <0E44F8EA-C111-45AD-BF86-DA2673B28EF9@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Tue, 31 Mar 2009 10:32:41 -0000 [copied to public-iri@w3.org, which should be used for all public discussion related to IRIs] On 2009/03/30 18:08, 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 there: >>>> - 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. - Rob Sayre suggested the name "Hypertext References". This was met with wide approval. - Action Item: Dan to reformat the document as an Internet Draft >>>> Some comments: - My ability is limited, but not zero. Just recently, I had a major blackout period due to upgrading of notebook/OS/emailer/... Not quite out of it yet. (At least, I'm now able to write my name correctly in email after all these years of working hard for internationalization on the Web :-(. - I managed to absorb a major 'variant' of IRIs for the XML folks under the name 'Legacy Extended IRIs' (see http://tools.ietf.org/html/draft-duerst-iri-bis-05#section-7). Much of that text was originally from the XML side (thanks to Norm Walsh, Richard Tobin, Henry Thomson), but I tweaked it quite a bit for tone, and we went back and forth to try and make sure we had all the differences covered. I think the exercise was successful in the sense that it was satisfactory for the parties involved (XML specs community and IRI spec authorship), and paper (or these days electrons) is patient anyway. I'm still not sure what kind of reaction there will be from a wider community (hint, hint: feedback welcome!) - The motivation for doing the above were about as follows: - It's better to have everything in place, so people can look it up in one go. - It's better to have it under the same name, and not send the wrong message with names (the originally proposed name for LEIRIs was "human readable identifiers", which was misleading in many ways) - It's better to allow it but warn against it than to ignore it in silence. - The IRI spec (some pre RFC 3987 drafts) allowed spaces and some other strictly ASCII non-URI characters, which was the reason they got allowed is some XML specs, so part of the reason was that the IRI spec also bore some responsibility. - Last time I looked at the discrepancies between the URI/IRI specs (RFC 3986/7) and the HTML practice (as far as documented), my impression was that some parts of it could rather easily be absorbed/buffered in the IRI spec, but for some others, the URI spec would be more appropriate. As an example, I think what HTML browsers do with buggy %-encoding sequences has nothing to do with the first I in IRI, which stands for Internationalization. So much for the moment. Regards, Martin. From mnot@mnot.net Tue Mar 31 04:09: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 AC9C73A68D6 for ; Tue, 31 Mar 2009 04:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.782 X-Spam-Level: X-Spam-Status: No, score=-4.782 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 rnyv8gufSjSN for ; Tue, 31 Mar 2009 04:09:44 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 73A5E3A682A for ; Tue, 31 Mar 2009 04:09:44 -0700 (PDT) Received: from [192.168.1.1] (unknown [118.208.230.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3AB7723E3AB; Tue, 31 Mar 2009 07:10:38 -0400 (EDT) Message-Id: <295EC891-EF33-4400-89AF-020BCBBB4A9C@mnot.net> From: Mark Nottingham To: =?ISO-8859-1?Q?=22Martin_J._D=FCrst=22?= In-Reply-To: <49D1F12D.3040009@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Minutes from informal IETF/W3C meeting about HTML5 work Date: Tue, 31 Mar 2009 22:10:27 +1100 References: <0E44F8EA-C111-45AD-BF86-DA2673B28EF9@mnot.net> <49D1F12D.3040009@it.aoyama.ac.jp> X-Mailer: Apple Mail (2.930.3) 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: Tue, 31 Mar 2009 11:09:45 -0000 Just thinking out loud -- is it *really* a good idea to have separate =20= URI and IRI lists? Cheers, On 31/03/2009, at 9:32 PM, Martin J. D=FCrst wrote: > [copied to public-iri@w3.org, which should be used for all public =20 > discussion related to IRIs] > > On 2009/03/30 18:08, 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 > > =46rom there: > > >>>> > - 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=FCrst was available. > - Rob Sayre suggested the name "Hypertext References". > This was met with wide approval. > - Action Item: Dan to reformat the document as an Internet Draft > >>>> > > Some comments: > > - My ability is limited, but not zero. Just recently, I had a major > blackout period due to upgrading of notebook/OS/emailer/... Not > quite out of it yet. (At least, I'm now able to write my name > correctly in email after all these years of working hard for > internationalization on the Web :-(. > > - I managed to absorb a major 'variant' of IRIs for the XML folks > under the name 'Legacy Extended IRIs' > (see http://tools.ietf.org/html/draft-duerst-iri-bis-05#section-7). > Much of that text was originally from the XML side (thanks to > Norm Walsh, Richard Tobin, Henry Thomson), but I tweaked it quite > a bit for tone, and we went back and forth to try and make sure > we had all the differences covered. > I think the exercise was successful in the sense that it was > satisfactory for the parties involved (XML specs community and > IRI spec authorship), and paper (or these days electrons) is > patient anyway. I'm still not sure what kind of reaction there > will be from a wider community (hint, hint: feedback welcome!) > > - The motivation for doing the above were about as follows: > - It's better to have everything in place, so people can look it > up in one go. > - It's better to have it under the same name, and not send the > wrong message with names (the originally proposed name for > LEIRIs was "human readable identifiers", which was misleading > in many ways) > - It's better to allow it but warn against it than to ignore it > in silence. > - The IRI spec (some pre RFC 3987 drafts) allowed spaces and some > other strictly ASCII non-URI characters, which was the reason > they got allowed is some XML specs, so part of the reason was > that the IRI spec also bore some responsibility. > > - Last time I looked at the discrepancies between the URI/IRI > specs (RFC 3986/7) and the HTML practice (as far as documented), > my impression was that some parts of it could rather easily > be absorbed/buffered in the IRI spec, but for some others, > the URI spec would be more appropriate. As an example, I think > what HTML browsers do with buggy %-encoding sequences has > nothing to do with the first I in IRI, which stands for > Internationalization. > > So much for the moment. Regards, Martin. > -- Mark Nottingham http://www.mnot.net/ From fanf2@hermes.cam.ac.uk Tue Mar 31 04:41: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 3F0713A6C5D for ; Tue, 31 Mar 2009 04:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.954 X-Spam-Level: X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=0.645, 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 Fc5gr6QPdtOT for ; Tue, 31 Mar 2009 04:41:34 -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 199153A69BC for ; Tue, 31 Mar 2009 04:41:33 -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]:44197) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1LocMQ-0004Z6-PM (Exim 4.70) (return-path ); Tue, 31 Mar 2009 12:42:30 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LocMQ-0001nX-RS (Exim 4.67) (return-path ); Tue, 31 Mar 2009 12:42:30 +0100 Date: Tue, 31 Mar 2009 12:42:30 +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: <49D18CB7.4010409@network-heretics.com> Message-ID: References: <49D0CBA3.7090409@cisco.com> <49D0EA0A.3020900@network-heretics.com> <49D0F39E.3080206@network-heretics.com> <49D18CB7.4010409@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 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 11:41:35 -0000 On Mon, 30 Mar 2009, Keith Moore wrote: > > for those few countries large enough (in longitude) to have multiple > timezones, the country code + the accepted abbreviations of the timezone > names used in those countries should be sufficient. That isn't sufficient in the USA because of Nevada and Indiana, nor in Australia because they don't have standard abbreviated timezone names, nor in China because of the unofficial Uighur timezone. You're going to have to invent timezone names in many cases. You also need more fine-grained timezones if your tz database goes back any length of time. The history in the USA was very messy before the federal government enforced uniform rules. 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 Tue Mar 31 07:46:38 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 F39973A6D67 for ; Tue, 31 Mar 2009 07:46:37 -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 HtIoyPqRpOAb for ; Tue, 31 Mar 2009 07:46:37 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 4E02028C14F for ; Tue, 31 Mar 2009 07:46:37 -0700 (PDT) Received: from lust.indecency.org (70-11-67-179.pools.spcsdns.net [70.11.67.179]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMF31701 (AUTH admin@network-heretics.com); Tue, 31 Mar 2009 07:47:26 -0700 (PDT) Message-ID: <49D22CFB.9000005@cs.utk.edu> Date: Tue, 31 Mar 2009 10:47:23 -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> <49D0F39E.3080206@network-heretics.com> <49D18CB7.4010409@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 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 14:46:38 -0000 Tony Finch wrote: 
On Mon, 30 Mar 2009, Keith Moore wrote:

for those few countries large enough (in longitude) to have multiple
timezones, the country code + the accepted abbreviations of the timezone
names used in those countries should be sufficient.


That isn't sufficient in the USA because of Nevada and Indiana, nor in
Australia because they don't have standard abbreviated timezone names, nor
in China because of the unofficial Uighur timezone. You're going to have
to invent timezone names in many cases.
Agreed.  (I did say "there might be a few special cases"...)
You also need more fine-grained timezones if your tz database goes back
any length of time. The history in the USA was very messy before the
federal government enforced uniform rules.
For our purposes, I'm not sure it's necessary to create URNs for timezones that no longer exist.  Other names could be created for these by database publishers if they so chose.

Keith

From lisa.dusseault@gmail.com Tue Mar 31 12:30:37 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 247A83A6817 for ; Tue, 31 Mar 2009 12:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 bl3bDYa0NqDH for ; Tue, 31 Mar 2009 12:30:35 -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 AC84F28C18E for ; Tue, 31 Mar 2009 12:30:35 -0700 (PDT) Received: by qyk36 with SMTP id 36so1002202qyk.29 for ; Tue, 31 Mar 2009 12:31:34 -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=QU+7il4r2ycIP56OJLaLdbCU0MnV25V0kwvUzfUE+tI=; b=QXejzVPTbKopBtjiAUxmYbPx9FQ+vEqka96vjHP2h8Bk3uk5p2sivAPHXpXxLbkWjM cBQAIx/8G3mGyplaRUL6P++kOKGwhP6Kq4RWKjCAbU7/XxOP7wbb5UMM+ldl18ydgL+6 vuUvI9yjZqGOA3ePfgcadb8rKdLMkwg+TC0J4= 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=iwoCbTROcaUgYcgIM7G29g45VQhENCchyuQDJjPr61VrMRFnjIPBL0SidVebK6wRiN QEPCedC5zALunU5Z/yTpngcE6+6Kr1Seb7ikRFZy910QEu2S6Gu0cCp3MjqG4ezlMMGs RGyxEeaGLdNx4GBGfy4GFD8eGODxzyPdrZqd0= MIME-Version: 1.0 Received: by 10.220.46.3 with SMTP id h3mr2697974vcf.38.1238527893206; Tue, 31 Mar 2009 12:31:33 -0700 (PDT) In-Reply-To: <167dfb9b0903290605m606a0ee8v13f1afede2d1c8f3@mail.gmail.com> References: <167dfb9b0903290605m606a0ee8v13f1afede2d1c8f3@mail.gmail.com> Date: Tue, 31 Mar 2009 12:31:32 -0700 Message-ID: Subject: Re: Generic URI syntax incompatible with IPv6 addresses in SIP URIs From: Lisa Dusseault To: Theo Zourzouvillys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 19:30:37 -0000 There is at least one relevant list: public-iri@w3.org. I believe that's where discussion of updating the base URI specs is moving? I'm trying to join myself. Lisa On Sun, Mar 29, 2009 at 6:05 AM, Theo Zourzouvillys wrote: > Hi, > > sip URI's (along with a bunch of others, such as iax, im, pres, and > xmpp) =A0allow embedded IPv6 literals in their URIs, but match > path-rootless in RFC 3986, which does not allow '[' and ']' - these > are only allowed in authority. =A0This means that a generic URI parser > will treat an IPv6 SIP URI as invalid unless it is aware of SIP URIs. > > I documented it earlier in the month here: > > =A0http://crazygreek.co.uk/b/2009/03/sip-uri-syntax-is-broken-with-ipv6.h= tml > > I'd appreciate feedback on how to best proceed to get this fixed? > > Kind regards, > > =A0~ Theo > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From Nicolas.Williams@sun.com Tue Mar 31 13:22: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 859C83A6DCD for ; Tue, 31 Mar 2009 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.319, 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 L3Y3Mf1Shov1 for ; Tue, 31 Mar 2009 13:22:32 -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 AD7E43A67FD for ; Tue, 31 Mar 2009 13:22:32 -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 n2VKNVXL003905 for ; Tue, 31 Mar 2009 20:23:32 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 n2VKNVi2047586 for ; Tue, 31 Mar 2009 14:23:31 -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 n2VKEFVO014772; Tue, 31 Mar 2009 15:14:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2VKECvh014771; Tue, 31 Mar 2009 15:14:12 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 31 Mar 2009 15:14:12 -0500 From: Nicolas Williams To: Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090331201412.GL9992@Sun.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D1060E.2030709@cisco.com> User-Agent: Mutt/1.5.7i 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: Tue, 31 Mar 2009 20:22:33 -0000 On Mon, Mar 30, 2009 at 07:49:02PM +0200, Eliot Lear wrote: > Realistically I don't think we get to have a say on how the publishers > choose their keys for information. I also don't think we get to tell > them what language they do it in. Doing so gets someone into a full > time job just to keep the mapping between IANA names and their names. > Let's not do that. Introducing any coherency concerns would be bad. > This needs to be light weight. If you want to localize, do it in your > implementation. I'd like to agree, particularly as to localization. But the key thing is: besides a timezone name you also need the ability to convert a date + timestamp + timezone name into GMT/UTC +-offset. I don't see how you get to do that _interoperably_ without defining at least a timezone _name_ registry. E.g., my software says "US/Chicago" and yours says US/Dallas" when they mean "US/Central" -- no interop. If we never exchange time data using timezone names but GMT/UTC +- offset then there's no interop problem. But if we do exchange time data using timezone names then what is to be the meaning of a registered timezone name if the timezone itself is not defined (or its definition referenced from) where the name is defined?? A timezone registry seems necessary, and it should at the very, very least resolve timzone names to country name and, preferably, also the relevant government agency/registrar and local timezone names (e.g., US/Chicago -> CST & CDT). Yes, software publishers can just include a version compiled from public sources -- we already do. That's why "country/city" is so appealing for timezone naming: the country that has the authority over the definition of a city's timezone is clear from the name. Of course, you'd better hope there aren't "twin cities" with similar names but in different states/provinces/whatever and with different timezones... :) And that we all agree as to which city names to use. Also, this isn't what I call user-friendly (see my earlier post), but at least it's feasible from a software development p.o.v., so I think we're likely to get stuck with "country/city" in UIs and GMT/UTC +- offset on the wire. Which means: we don't need a timezone URN. Nico -- From moore@network-heretics.com Tue Mar 31 13:51: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 70F453A6AA4 for ; Tue, 31 Mar 2009 13:51: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 F9i4tM9oE6ra for ; Tue, 31 Mar 2009 13:51: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 86FEE3A67F3 for ; Tue, 31 Mar 2009 13:51:31 -0700 (PDT) Received: from lust.indecency.org (99-205-97-246.pools.spcsdns.net [99.205.97.246]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMF79804 (AUTH admin@network-heretics.com); Tue, 31 Mar 2009 13:52:18 -0700 (PDT) Message-ID: <49D28280.3080406@network-heretics.com> Date: Tue, 31 Mar 2009 16:52:16 -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> <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> In-Reply-To: <20090331201412.GL9992@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: Tue, 31 Mar 2009 20:51:32 -0000 Nicolas Williams wrote: > On Mon, Mar 30, 2009 at 07:49:02PM +0200, Eliot Lear wrote: >> Realistically I don't think we get to have a say on how the publishers >> choose their keys for information. I also don't think we get to tell >> them what language they do it in. Doing so gets someone into a full >> time job just to keep the mapping between IANA names and their names. >> Let's not do that. Introducing any coherency concerns would be bad. >> This needs to be light weight. If you want to localize, do it in your >> implementation. 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. > I'd like to agree, particularly as to localization. But the key thing > is: besides a timezone name you also need the ability to convert a date > + timestamp + timezone name into GMT/UTC +-offset. I don't see how you > get to do that _interoperably_ without defining at least a timezone > _name_ registry. E.g., my software says "US/Chicago" and yours says > US/Dallas" when they mean "US/Central" -- no interop. If we never > exchange time data using timezone names but GMT/UTC +- offset then > there's no interop problem. Actually, there's still an interop problem when the timezone definition changes between the time that the software is shipped and the time of any events. This actually happened for a large part of Australia several years ago, and (despite what must have seemed like a lot of lead time to the US Congress as of the last time they changed DST rules) it seems to be happening in the US now. (I'm currently sitting in a coffee shop, and I've overheard a complaint about exactly this within the last hour.) The reason that iCalendar has support for timezone names is because timezone definitions do sometimes change without much prior notice. > But if we do exchange time data using timezone names then what is to be > the meaning of a registered timezone name if the timezone itself is not > defined (or its definition referenced from) where the name is defined?? 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. The registry can be extensible, like the one we have for language codes. That way, if we miss some important timezones, others can request that they be added. > A timezone registry seems necessary, and it should at the very, very > least resolve timzone names to country name and, preferably, also the > relevant government agency/registrar and local timezone names (e.g., > US/Chicago -> CST & CDT). Yes, software publishers can just include a > version compiled from public sources -- we already do. I don't see any requirement that the standard timezone definitions map from city name (or for that matter lat/lng) to standard timezone name. (yes, such a registry would be useful, but I don't think IETF wants to compile/maintain that registry any more than it wants to compile/maintain its own registry of timezone periods and GMT offsets for all of the timezones of the world. we can leave that work to others. and as you point out, existing public sources already provide that.) > That's why "country/city" is so appealing for timezone naming: the > country that has the authority over the definition of a city's timezone > is clear from the name. let me make this really clear - country/city sucks for timezone naming if you don't happen to live in or very near that city. it's simply not acceptable as a general scheme. (it might be okay for the odd corner cases.) > Which means: we don't need a timezone URN. since the premise is false, it doesn't support the conclusion. I'll reserve judgment on whether URNs are suitable, but we need standard timezone identifiers so that we can get interop between timezone databases supplied by different publishers - at least for those "major" timezones that are defined/maintained by governments (perhaps major religious bodies also) and heavily used for scheduling future events. that's not to say that such publishers have to change the names that they're currently using. but it would be nice if (and we could recommend) that they support the ability to map from their own definitions to IETF-standard timezone names (when equivalent names exist). and we could recommend that implementations of iCalendar and other protocols include IETF-standard timezone names in event descriptions. Keith From lisa.dusseault@gmail.com Tue Mar 31 13:56: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 695103A6A6A for ; Tue, 31 Mar 2009 13:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 UTL5y5Xjxmet for ; Tue, 31 Mar 2009 13:56:13 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 86F9A3A67F3 for ; Tue, 31 Mar 2009 13:56:13 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2717611rvb.49 for ; Tue, 31 Mar 2009 13:57:13 -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=GAQN7X5zFao4ecl9Ymz3UgTqMQ+tp4iXFuo6g7Xq9uc=; b=xfMswQSnuajD5OGEELntyRUUJoTMqPawj41BXtl5HiC8g2ZVwCcyVx+rrlGRSIcVTC SRneOmrg94J0PbrqqsHXjC7Z1RWmPAnvkzqk7ItCWW0EdpARC8UbA/m2/tNdivkgR2+y XSS2t/GkBNUFi9rQ+aQmZa73abdzv9MQzneRE= 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=mNrrvVdVp1yhowK9nAf9RLvf1hSLtS/C5/wpsiM5YnEq6h8fobz2kd+FyTOfFUcwlu wOXYnYMfN6xFcVl9oNiTwXsFvIVd9CsKhc5u6CzUf5Ho1T1kPgmrx3kHbkB8YgVnfig2 HMyj5ddRHpjlnDEg/wcc9Eu0lsBNA8I2Fogn8= MIME-Version: 1.0 Received: by 10.140.193.16 with SMTP id q16mr3650968rvf.38.1238533033072; Tue, 31 Mar 2009 13:57:13 -0700 (PDT) In-Reply-To: References: <167dfb9b0903290605m606a0ee8v13f1afede2d1c8f3@mail.gmail.com> Date: Tue, 31 Mar 2009 13:57:13 -0700 Message-ID: Subject: Re: Generic URI syntax incompatible with IPv6 addresses in SIP URIs From: Lisa Dusseault To: Mark Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:56:14 -0000 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. Lisa On Tue, Mar 31, 2009 at 1:29 PM, Mark Baker wrote: > 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? =A0I hadn't heard anything about that. =A0I would have > thought uri@w3.org would be the place to take this. > > Mark. > From julian.reschke@gmx.de Tue Mar 31 14:04: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 2B0333A6A96 for ; Tue, 31 Mar 2009 14:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-2.200, 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 ztUorc8ggII8 for ; Tue, 31 Mar 2009 14:04:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CCEC03A6912 for ; Tue, 31 Mar 2009 14:04:49 -0700 (PDT) Received: (qmail invoked by alias); 31 Mar 2009 21:05:47 -0000 Received: from p508FFA32.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.250.50] by mail.gmx.net (mp005) with SMTP; 31 Mar 2009 23:05:47 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+FT/8Jxj2FN6zK0oueaY9pM9INlJa7cys1e+yRzz jAxxQxRbQGC7rp Message-ID: <49D285A6.6060104@gmx.de> Date: Tue, 31 Mar 2009 23:05:42 +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: Lisa Dusseault Subject: Re: Generic URI syntax incompatible with IPv6 addresses in SIP URIs References: <167dfb9b0903290605m606a0ee8v13f1afede2d1c8f3@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 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: Tue, 31 Mar 2009 21:04:51 -0000 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 From Nicolas.Williams@sun.com Tue Mar 31 14:35: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 6F5C33A6AA4 for ; Tue, 31 Mar 2009 14:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=0.317, 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 DQvCGpnIKhad for ; Tue, 31 Mar 2009 14:35:23 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 874AD3A67ED for ; Tue, 31 Mar 2009 14:35:23 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2VLaMKq024427 for ; Tue, 31 Mar 2009 21:36:23 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 n2VLaMfO046972 for ; Tue, 31 Mar 2009 15:36:22 -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 n2VLR46H014914; Tue, 31 Mar 2009 16:27:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2VLR3CC014913; Tue, 31 Mar 2009 16:27:03 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 31 Mar 2009 16:27:03 -0500 From: Nicolas Williams To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090331212703.GR9992@Sun.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D28280.3080406@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: Tue, 31 Mar 2009 21:35:24 -0000 On Tue, Mar 31, 2009 at 04:52:16PM -0400, Keith Moore wrote: > Nicolas Williams wrote: > > That's why "country/city" is so appealing for timezone naming: the > > country that has the authority over the definition of a city's timezone > > is clear from the name. > > let me make this really clear - country/city sucks for timezone naming > if you don't happen to live in or very near that city. it's simply not > acceptable as a general scheme. (it might be okay for the odd corner > cases.) Let me be clear too: I've said the same thing earlier and stand by that; I in no way endorse the use of "country/city" as timezone names. > > Which means: we don't need a timezone URN. > > since the premise is false, it doesn't support the conclusion. Which part of the premise is wrong? That we don't need timezone names on the wire? We don't -- send GMT +- offset or both, GMT +- offset and localized time. That "country/city" is a solution? True, it's an abobinable solution, but it is what has been deployed too often. > I'll reserve judgment on whether URNs are suitable, but we need standard > timezone identifiers so that we can get interop between timezone > databases supplied by different publishers - at least for those "major" > timezones that are defined/maintained by governments (perhaps major > religious bodies also) and heavily used for scheduling future events. I agree, but for this you need a registry of accepted timezone names, replete with links to actual authorities. And note that it's entirely possible for politicians to create new timezones and abandon old ones (again, think of State of Indiana-like cases), which means that *any* registry is going to have a modicum of interaction with those authorities. IMO this sort of issue is best left to international standards development organizations with national representation (think ISO), not the IETF. Nico -- From moore@network-heretics.com Tue Mar 31 15:10: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 E66003A6ADB for ; Tue, 31 Mar 2009 15:10: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 kN--MMN1sH9j for ; Tue, 31 Mar 2009 15:10: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 C67993A6869 for ; Tue, 31 Mar 2009 15:10:12 -0700 (PDT) Received: from lust.indecency.org (99-205-97-246.pools.spcsdns.net [99.205.97.246]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMF87715 (AUTH admin@network-heretics.com); Tue, 31 Mar 2009 15:11:09 -0700 (PDT) Message-ID: <49D294FA.7080501@network-heretics.com> Date: Tue, 31 Mar 2009 18:11:06 -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> <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> In-Reply-To: <20090331212703.GR9992@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: Tue, 31 Mar 2009 22:10:15 -0000 Nicolas Williams wrote: > On Tue, Mar 31, 2009 at 04:52:16PM -0400, Keith Moore wrote: >> Nicolas Williams wrote: >>> That's why "country/city" is so appealing for timezone naming: the >>> country that has the authority over the definition of a city's timezone >>> is clear from the name. >> let me make this really clear - country/city sucks for timezone naming >> if you don't happen to live in or very near that city. it's simply not >> acceptable as a general scheme. (it might be okay for the odd corner >> cases.) > > Let me be clear too: I've said the same thing earlier and stand by that; > I in no way endorse the use of "country/city" as timezone names. okay, maybe I misunderstood you. >>> Which means: we don't need a timezone URN. >> since the premise is false, it doesn't support the conclusion. > > Which part of the premise is wrong? That we don't need timezone names > on the wire? We don't -- send GMT +- offset or both, GMT +- offset and > localized time. strongly disagree. systems that do that are widely deployed, and (predictably) break when TZ rules change. > That "country/city" is a solution? True, it's an abobinable solution, but it is what has been deployed too often. certainly agree about the last part. >> I'll reserve judgment on whether URNs are suitable, but we need standard >> timezone identifiers so that we can get interop between timezone >> databases supplied by different publishers - at least for those "major" >> timezones that are defined/maintained by governments (perhaps major >> religious bodies also) and heavily used for scheduling future events. > > I agree, but for this you need a registry of accepted timezone names, > replete with links to actual authorities. I'd almost be fine with the names being UUIDs but I think that they'd be more widely accepted if they were ASCII names that could be understood by humans. The ability to look at a name and have confidence that it's the right name is pretty useful. 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. So US.W0005 for Eastern time, US.W0006 for Central, etc. (W for west of GMT, E for east of GMT). Of course the convention would not work for all cases but it might avoid some of the ratholes. You could even have naming conventions for "does not use summer time" like US.W0006-NST and avoid trying to name those regions in Indiana. > And note that it's entirely possible for politicians to create new > timezones and abandon old ones (again, think of State of Indiana-like > cases), which means that *any* registry is going to have a modicum of > interaction with those authorities. > > IMO this sort of issue is best left to international standards > development organizations with national representation (think ISO), not > the IETF. I've made similar statements in the past. If they're willing to take this on, so much the better. But I think the best way to make that happen is for IETF to get things off to a good start, and then state a willingness for ISO or whomever (who knows, maybe even ICAO, they have as much interest in it as anybody) to take this over. Keith From Nicolas.Williams@sun.com Tue Mar 31 15:31:20 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 9C6563A6997 for ; Tue, 31 Mar 2009 15:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.731 X-Spam-Level: X-Spam-Status: No, score=-5.731 tagged_above=-999 required=5 tests=[AWL=0.315, 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 PIcp7ZYmp2wm for ; Tue, 31 Mar 2009 15:31:20 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id D795E3A6869 for ; Tue, 31 Mar 2009 15:31:19 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2VMWJQE005615 for ; Tue, 31 Mar 2009 22:32:19 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 n2VMWJTV006476 for ; Tue, 31 Mar 2009 16:32:19 -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 n2VMN30k014951; Tue, 31 Mar 2009 17:23:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2VMN2uD014950; Tue, 31 Mar 2009 17:23:02 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 31 Mar 2009 17:23:02 -0500 From: Nicolas Williams To: Keith Moore Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090331222302.GT9992@Sun.COM> References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D294FA.7080501@network-heretics.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Eliot Lear , mankin@psg.com 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 22:31:20 -0000 On Tue, Mar 31, 2009 at 06:11:06PM -0400, Keith Moore wrote: > > IMO this sort of issue is best left to international standards > > development organizations with national representation (think ISO), not > > the IETF. > > I've made similar statements in the past. If they're willing to take > this on, so much the better. But I think the best way to make that > happen is for IETF to get things off to a good start, and then state a > willingness for ISO or whomever (who knows, maybe even ICAO, they have > as much interest in it as anybody) to take this over. 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. Cheers, Nico -- From moore@network-heretics.com Tue Mar 31 15:36: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 DFEC23A6869 for ; Tue, 31 Mar 2009 15:36:57 -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 W3dTze77RI0O for ; Tue, 31 Mar 2009 15:36: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 326793A67B4 for ; Tue, 31 Mar 2009 15:36:57 -0700 (PDT) Received: from lust.indecency.org (99-205-97-246.pools.spcsdns.net [99.205.97.246]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMF90016 (AUTH admin@network-heretics.com); Tue, 31 Mar 2009 15:37:54 -0700 (PDT) Message-ID: <49D29B3F.1080607@network-heretics.com> Date: Tue, 31 Mar 2009 18:37:51 -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: <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> <20090331222302.GT9992@Sun.COM> In-Reply-To: <20090331222302.GT9992@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Eliot Lear , mankin@psg.com 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 22:36:58 -0000 Nicolas Williams wrote: > On Tue, Mar 31, 2009 at 06:11:06PM -0400, Keith Moore wrote: >>> IMO this sort of issue is best left to international standards >>> development organizations with national representation (think ISO), not >>> the IETF. >> I've made similar statements in the past. If they're willing to take >> this on, so much the better. But I think the best way to make that >> happen is for IETF to get things off to a good start, and then state a >> willingness for ISO or whomever (who knows, maybe even ICAO, they have >> as much interest in it as anybody) to take this over. > > 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. biggest danger I see in having ISO do that is that (a) it would take too long and (b) it would be done by people who are much more distant from software development and UI concerns that IETF participants. Keith From Nicolas.Williams@sun.com Tue Mar 31 15:41:36 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 4A69B3A6B6C for ; Tue, 31 Mar 2009 15:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.733 X-Spam-Level: X-Spam-Status: No, score=-5.733 tagged_above=-999 required=5 tests=[AWL=0.313, 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 2UqxyMzHaKJQ for ; Tue, 31 Mar 2009 15:41:35 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 5E09B3A6B76 for ; Tue, 31 Mar 2009 15:41:35 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2VMgZSP008103 for ; Tue, 31 Mar 2009 22:42:35 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 n2VMgY2J014607 for ; Tue, 31 Mar 2009 16:42:34 -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 n2VMXIRE014961; Tue, 31 Mar 2009 17:33:18 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2VMXIk7014960; Tue, 31 Mar 2009 17:33:18 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 31 Mar 2009 17:33:18 -0500 From: Nicolas Williams To: Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090331223318.GU9992@Sun.COM> References: <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49D1289A.4070803@cisco.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , Keith Moore , 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: Tue, 31 Mar 2009 22:41:36 -0000 On Mon, Mar 30, 2009 at 10:16:26PM +0200, Eliot Lear wrote: > On 3/30/09 9:42 PM, Keith Moore wrote: > >Patrik Fältström wrote: > >>Secondly, I think they could use the name "Crossville, Tennessee, > >>USA" as their timezone entry. That makes it easier for them to later > >>do whatever they want. > >if the publisher supports it. but do we really expect publishers to > >document and keep track of timezones for every city and town on > >earth? and if we make timezones very fine-grained, how does this > >affect the ability to resolve timezone information? > > There *is* an entrenched defacto standard here already. The folks on > the tz mailing list have a remarkable and under-appreciated track > record. The only reason we should want anything more than what there is > today, is that some of us are uncomfortable with the succession planning > of that team. A URN was the best way I could think of to future proof > us against the remote possibility of drastically bad happening. A timezone URN without a registry will not solve the problem -- every publisher will be free to coin their own timezone URNs, leaving us with the exact same problem that we have now (non-interoperable timezone names, mismatches in publisher-provider timezone data, worrying about "tz mailing list" "succession planning", and so on)... ...unless the new timezone URNs were all based on, say, {coordinates to within some standard resolution, [season]}, in which case we could all agree on timezone URNs, always (provided reasonably accurate position information) but still we'd need publisher-provided TZ name->{TZ UTC/GMT offset + DST info} resolution services. 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. :) Nico -- From cyrus@daboo.name Tue Mar 31 15:53: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 B58923A6869 for ; Tue, 31 Mar 2009 15:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-1.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 B8g73KPwXwiJ for ; Tue, 31 Mar 2009 15:53:37 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id DEAE43A67B4 for ; Tue, 31 Mar 2009 15:53:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 46AE7131FBE4; Tue, 31 Mar 2009 18:54:36 -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 R-22gCq-ufSn; Tue, 31 Mar 2009 18:54:36 -0400 (EDT) Received: from [10.0.1.230] (chewy.daboo.name [10.0.1.230]) by daboo.name (Postfix) with ESMTP id 5FE39131FBD6; Tue, 31 Mar 2009 18:54:35 -0400 (EDT) Date: Tue, 31 Mar 2009 18:54:30 -0400 From: Cyrus Daboo To: Nicolas Williams , Eliot Lear Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: In-Reply-To: <20090331223318.GU9992@Sun.COM> References: <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <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> 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 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: Tue, 31 Mar 2009 22:53:43 -0000 Hi Nicolas, --On March 31, 2009 5:33:18 PM -0500 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. :) I disagree that authorities should have anything to do with this. We will never get governments etc all on board with this. As I recall Pete Resnick mentioned he had tried something like this in the past and failed. The most important thing we need is a standard set of identifiers that are guaranteed to refer to the same timezone definitions (rules, offsets etc). That is the key thing needed for interoperability across calendaring and scheduling systems. -- Cyrus Daboo From Nicolas.Williams@sun.com Tue Mar 31 16:15: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 33F5A28C1BA for ; Tue, 31 Mar 2009 16:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.735 X-Spam-Level: X-Spam-Status: No, score=-5.735 tagged_above=-999 required=5 tests=[AWL=0.311, 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 tlG+04oTeN-n for ; Tue, 31 Mar 2009 16:14:59 -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 98A9D28C10A for ; Tue, 31 Mar 2009 16:14:58 -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 n2VNFwpe009635 for ; Tue, 31 Mar 2009 23:15:58 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 n2VNFwCR039514 for ; Tue, 31 Mar 2009 17:15:58 -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 n2VN6gCc015068; Tue, 31 Mar 2009 18:06:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2VN6eGe015067; Tue, 31 Mar 2009 18:06:40 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 31 Mar 2009 18:06:40 -0500 From: Nicolas Williams To: Cyrus Daboo Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <20090331230639.GX9992@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> 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: Tue, 31 Mar 2009 23:15:00 -0000 On Tue, Mar 31, 2009 at 06:54:30PM -0400, Cyrus Daboo wrote: > Hi Nicolas, > > --On March 31, 2009 5:33:18 PM -0500 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. :) > > I disagree that authorities should have anything to do with this. We will > never get governments etc all on board with this. As I recall Pete Resnick > mentioned he had tried something like this in the past and failed. ISO does get things done. Slowly, perhaps, but we (the IETF) are not necessarily much faster. I realize that Pete Resnick is one of the liasons to the ISO, but ISTM that Allison Mankin is the relevant liason here (please correct me if I'm wrong!). If Peter and Allison say "forget asking the ISO," fine. > The most important thing we need is a standard set of identifiers that are > guaranteed to refer to the same timezone definitions (rules, offsets etc). 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. > That is the key thing needed for interoperability across calendaring and > scheduling systems. I agree with this. From cyrus@daboo.name Tue Mar 31 17:33: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 BA5693A6AAB for ; Tue, 31 Mar 2009 17:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=-0.985, 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 QYbTKtnAg8QE for ; Tue, 31 Mar 2009 17:33:33 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id A9C133A6AA8 for ; Tue, 31 Mar 2009 17:33:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E594A132044C; Tue, 31 Mar 2009 20:34:31 -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 6O3nW9ymbzsU; Tue, 31 Mar 2009 20:34:31 -0400 (EDT) Received: from [17.101.35.28] (unknown [10.0.1.1]) by daboo.name (Postfix) with ESMTP id 9C4DF1320441; Tue, 31 Mar 2009 20:34:30 -0400 (EDT) Date: Tue, 31 Mar 2009 20:34:29 -0400 From: Cyrus Daboo To: Nicolas Williams Subject: Re: supposing one would want to create a new URN space for timezones... Message-ID: <6F7F1C3941B4D89695982BCC@dhcp-43ed.meeting.ietf.org> In-Reply-To: <20090331230639.GX9992@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> <20090331230639.GX9992@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=2120 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 00:33:33 -0000 Hi Nicolas, --On March 31, 2009 6:06:40 PM -0500 Nicolas Williams wrote: >> The most important thing we need is a standard set of identifiers that >> are guaranteed to refer to the same timezone definitions (rules, >> offsets etc). > > 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. What is being proposed is a registry and a service. The registry defines the standard set of names that allow "consumers" to interoperate. "consumers" get matching timezone definitions by asking their "provider" (offering a timezone service) to return the data to them. "providers" get their data from one or more "publishers", optionally adding useful meta-data (who the publisher is, what version of data they have, geo information, whatever). The service takes care of handling updates to changes in the data. "publishers" get their data in whatever way is appropriate for them. In the case of an Olson style service, that would involve "contributors" spotting local changes to timezone definitions and posting those back to the publisher to incorporate into their data. As Elliot has noted on several occasions, the way Olson works right now is pretty good. Some things need to be tweaked: guaranteed longevity of service, digital signatures on the data etc. The goal here is not to put the data into the registry, just the names. Given that this is an internet-wide service, a typical registrar (e.g. IANA) is not going to be able to scale to the demand from "consumers" (which will potentially be every desktop and mobile device and more). The "providers" are the ones who offer a scalable solution using whatever operational model makes sense for them, but using the standard timezone service apis we define. Really I see the only issue as being one of whether the timezone identifiers are specific to publishers or not. If they are, then someone (presumably the "providers") will have to maintain some kind of mapping to allow some degree of interoperability. -- Cyrus Daboo From zhangguoqiang@cnnic.cn Tue Mar 31 20:15: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 D845E3A687B for ; Tue, 31 Mar 2009 20:15:40 -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.005 X-Spam-Level: ** X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, J_CHICKENPOX_93=0.6, 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 U-6YVKBqy49Y for ; Tue, 31 Mar 2009 20:15:39 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 1E8673A6830 for ; Tue, 31 Mar 2009 20:15:38 -0700 (PDT) Received: (eyou send program); Wed, 01 Apr 2009 11:16:37 +0800 Message-ID: <438555797.29182@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 11:16:37 +0800 Date: Wed, 1 Apr 2009 11:16:36 +0800 From: "zhangguoqiang" To: "apps-discuss" Subject: Solicitation for a discussion on Keyword-based addressing Message-ID: <200904011116363933242@cnnic.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon168508580601_=====" Cc: YAO Jiankang 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 03:15:40 -0000 This is a multi-part message in MIME format. --=====001_Dragon168508580601_===== Content-Type: multipart/alternative; boundary="=====003_Dragon168508580601_=====" --=====003_Dragon168508580601_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Keyword service is thriving in non-english speaking countries these days, e.g, Netpia and digitalnames in Korea, CNNIC in China, JWORD in Japan. Even in U.S, there were realnames and netword. It proves to be a useful application both to end users and to advertisers. However, the current keyword service each has its own solution, and lacks of coordination. For example, when a korean comes to China, then without plugin, he will unable to access the Korea keyword service. When talking about keyword, most people will question its relationship with search engines and IDN. So, let me first clarify it here. 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, while the search for a keyword in a search engine is undetermistic, strongly depending on the search engine used and the exact time the search carried out. Several features have made keyword-based addressing distinct from IDN. First, keyword maps to URL, which means it can be used to directly access a particular 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. This feature also provides a better way for advertisers to protect their brand names. Finally, orginating from the western countries, domain names inherit the input conventions from w est countries, e.g, put the most signicant part into the rightmost, while our proposed keyword-based addressing can respect different input conventions. Surely, keyword-based addressing is not intended to replace IDN, search engine or URI. It is only a complenmentary technology. There are some usage scenarios where the keyword-based addressing is more effective than other techniques. 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? Use search engines? No, because your blog is not so popular. Use URL? It is too hard for people to remember. In this scenario, keyword-based addressing provides an effective way to access your blog, e.g. yahooblog:bob. 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. 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. In summary, our keyword addressing has the following advantages: (1) simple syntax (2) allows for global resolution (3) repects cultural input conventions, the customized rules stored in DDDS database is responsible for the keyword-to-domanname tranlation. (4) can be used for different applications So, my solicitation is for a discussion of this draft or the keyword service itself. To my opinion, application area is the right place for this discussion. 2009-04-01 zhangguoqiang --=====003_Dragon168508580601_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
 
Keyword service is thriving in non-english speaking countries these days, e.g, Netpia and digitalnames in Korea, CNNIC in China, JWORD in Japan. Even in U.S, there were realnames and netword. It proves to be a useful application both to end users and to advertisers.

However, the current keyword service each has its own solution, and lacks of coordination. For example, when a korean comes to China, then without plugin, he will unable to access the Korea keyword service.
 
When talking about keyword, most people will question its relationship with search engines and IDN. So, let me first clarify it here. 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, while the search for a keyword in a search engine is undetermistic, strongly depending on the search engine used and the exact time the search carried out.  Several features have made keyword-based addressing distinct from IDN. First, keyword maps to URL, which means it can be used to directly access a particular 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. This feature also provides a better way for advertisers to protect their brand names. Finally, orginating from the western countries, domain names inherit the input conventions from west countries, e.g, put the most signicant part into the rightmost, while our proposed keyword-based addressing can respect different input conventions.     
 
Surely, keyword-based addressing is not intended to replace IDN, search engine or URI. It is only a complenmentary technology. There are some usage scenarios where the keyword-based addressing is more effective than other techniques. 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? Use search engines? No, because your blog is not so popular. Use URL? It is too hard for people to remember. In this scenario, keyword-based addressing provides an effective way to access your blog, e.g. yahooblog:bob.
 
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.
 
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.
 
In summary, our keyword addressing has the following advantages:
(1) simple syntax
(2) allows for global resolution
(3) repects cultural input conventions, the customized rules stored in DDDS database is responsible for the keyword-to-domanname tranlation.
(4) can be used for different applications
 
So, my solicitation is for a discussion of this draft or the keyword service itself. To my opinion, application area is the right place for this discussion.
 
2009-04-01
zhangguoqiang
--=====003_Dragon168508580601_=====-- --=====001_Dragon168508580601_===== 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 OnpoYW5nZ3VvcWlhbmdAY25uaWMuY24NClJFVjoyMDA5MDQwMVQxMTE2MzZaDQpFTkQ6VkNBUkQN Cg== --=====001_Dragon168508580601_=====-- From skissane@gmail.com Tue Mar 31 20:47: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 25A823A659C for ; Tue, 31 Mar 2009 20:47:18 -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 mcwNpoEninVA for ; Tue, 31 Mar 2009 20:47:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0708.google.com [209.85.198.251]) by core3.amsl.com (Postfix) with ESMTP id 974C73A67AD for ; Tue, 31 Mar 2009 20:47:16 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k29so1990325rvb.2 for ; Tue, 31 Mar 2009 20:48:16 -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:content-type; bh=40efp86S+4XpzkXUN3NdPhwR+Fk1H2351SNkwEB5QkQ=; b=hJsGJeRt5bmscJBgFtAdo5noQoXyLAimticyiID2/81/JhNQh25kneTiIsO9CF3JIc bckseJ3k373yk+XlrtRA1sZPmoLomJbQ8zlvWmkHhvKHoE9ymUDLu0F5GAM0VnnXB1Tq 5Qi3+bkBwvgHvYW7RbYfkdt75yR96z/6OWZ6Y= 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 :content-type; b=SmnkxWcVjFpSWJ9spH/2qYS46FmkXHTZSRG1ZTEhC8TyAkhNxMU+NqnuV0yewF7Z38 4t+t/NZSCGVttxdTf09iIAyYuiS5AqNWJXwO1BuOGdKyt4ierIm9ajEL1EdyGKKY1tsG G8YcCqImjanbDfTP5X8Z3Po79xQ0YkfWMZhbI= MIME-Version: 1.0 Received: by 10.141.2.18 with SMTP id e18mr3794330rvi.140.1238557696376; Tue, 31 Mar 2009 20:48:16 -0700 (PDT) In-Reply-To: <6F7F1C3941B4D89695982BCC@dhcp-43ed.meeting.ietf.org> 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> Date: Wed, 1 Apr 2009 14:48:16 +1100 Message-ID: <82fa66380903312048o7f5864f5kb349ab3e2089f1de@mail.gmail.com> Subject: Re: supposing one would want to create a new URN space for timezones... From: SJ Kissane To: Apps Discuss Content-Type: multipart/alternative; boundary=000e0cd1130a86c0020466762f6f 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 03:47:18 -0000 --000e0cd1130a86c0020466762f6f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all 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) 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. The point of a URN is to have a unique identifier, not every possible identifier you'd want to use. So I'd say, use the CLDR identifier in the URN -- and then use a database like CLDR to map those URN values to names in various languages to display to user, or to map to vendor standards like Microsoft Windows, or so on. Simon Kissane --000e0cd1130a86c0020466762f6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all

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 iden= tifiers for timezones,
which are the Olson names, save that as I understand, they only use the fir= st name ever
defined, so if the name ever changes in Olson, they stick t= o the original name.
(see UTS#35 section 5.9.2 -- http://www.unicode.org/reports/tr= 35/#Timezone_Names)

It defines timezone names in multiple languages, mapping to pre-existin= g 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 alre= ady in this area.

The point of a URN is to have a unique identifier, not every possible i= dentifier you'd want to use.
So I'd say, use the CLDR identifier= in the URN -- and then use a database like CLDR
to map those URN values= to names in various languages to display to user,
or to map to vendor standards like Microsoft Windows, or so on.

Simo= n Kissane
--000e0cd1130a86c0020466762f6f-- From moore@cs.utk.edu Tue Mar 31 22:18: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 7A3393A69F0 for ; Tue, 31 Mar 2009 22:18:02 -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 LIxFfZgU5aha for ; Tue, 31 Mar 2009 22:18:01 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id BF88F3A6991 for ; Tue, 31 Mar 2009 22:18:01 -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 BMG22973 (AUTH admin@network-heretics.com); Tue, 31 Mar 2009 22:18:54 -0700 (PDT) Message-ID: <49D2F93B.8040406@cs.utk.edu> Date: Wed, 01 Apr 2009 01:18:51 -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: <49D0EA0A.3020900@network-heretics.com> <49D0EE03.5010501@lshift.net> <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> In-Reply-To: <20090331223318.GU9992@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 05:18:02 -0000 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.  :)

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.)

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.

Keith