From owner-wrec@cs.utk.edu Mon May 1 04:51:04 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22279 for ; Mon, 1 May 2000 04:51:04 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA12348; Mon, 1 May 2000 04:45:21 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Mon, 1 May 2000 04:45:21 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA12329; Mon, 1 May 2000 04:45:20 -0400 (EDT) Received: from ns.falconstor.net.tw (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA12315; Mon, 1 May 2000 04:45:08 -0400 (EDT) Received: from ns.falconstor.net.tw (202.145.81.86 -> as3po86.tc.ficnet.net.tw) by cs.utk.edu (smtpshim v1.0); Mon, 1 May 2000 04:45:10 -0400 Received: from SanJose (h1-168.falconstor.net.tw [172.30.1.168]) by ns.falconstor.net.tw (8.9.3/8.9.3) with SMTP id QAA29609; Mon, 1 May 2000 16:43:26 +0800 From: "Eric Chen" To: , , , , , Cc: "Eric Chen" Subject: CFPs: DEADLINE EXTENTION FOR SAINT2001: NEW DEADLINE MAY 8, 2000 Date: Mon, 1 May 2000 16:41:36 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA22279 Dear Colleagues, Please distribute the CFPs info. as attached. My apology if you receive multiple copies. ---Eric Chen SAINT-2001 Publicity Co-Chair ==================================================================== FINAL Call for Papers and Participation --DEADLINE EXTENSION-- The 2001 Symposium on Applications and the Internet SAINT-2001 http://computer.org/tab/TCI/SAINT/ http://www.ipsj.or.jp/kokusai/saint.htm (mirror site) San Diego, California, USA, January 8-12, 2001 This conference provides a forum for engineers and scientists in academia, industry, and government to present their latest findings in the area of Internet applications and the underlying technologies to support those applications. Areas of particular interest include, but anot limited to: - Agents and the Internet - Collaboration Technology - Digital Libraries - Distributed & Parallel Applications - Domain Specific Languages - E-Commerce - Internet Services - Mobile Computing - Multimedia Technology Tutorial & Workshops - -------------------- The tutorial and workshops submissions deadlines have passed. Paper Submission - ---------------- Form of Manuscript: Not to exceed 25 double-spaced, 8.5x11-inch pages (including figures, tables and regerences) in 10-12 point font. Number each page, include an abstract, five to ten keywords, and the technical area(s) most relevant to your pape, and the corresponding author's e-mail address. Subnmission: All submissions will be done electronically. To submit a paper, go to http://witanweb.iit.nrc.ca/saint2001/ and follow the instructions. Important Deadlines - ------------------- Paper Submission: May 8, 2000 (NEW DEADLINE -- this is FIRM) Author Notification: August 15, 2000 Final Manuscript: October 1, 2000 Proceedings - ----------- The Proceedings of the conference and the workshops will be published by the IEEE Computer Society Press. Organizing & Program Committees - ------------------------------- General Co-Chairs Ming T. Liu, The Ohio State Univ., USA Iwao Toda, Fujitsu Labs, Japan Program Co-Chairs Fred Douglis, AT&T Labs-Research, USA Katsuo Ikeda, Kyoto Univ., Japan For Further Information, Please Contact - --------------------------------------- Mike Liu, The Ohio State University, Dept. of CIS, Columbus, OH43210-1277, USA Phone: +1-614-292-6552; Fax: +1-614-292-2911; E-mail: mike.liu@osu.edu or see the conference home page: http://computer.org/tab/TCI/SAINT/ ==================================================================== From owner-wrec@cs.utk.edu Wed May 3 11:45:08 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04628 for ; Wed, 3 May 2000 11:45:07 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA27081; Wed, 3 May 2000 11:39:42 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 3 May 2000 11:39:41 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA27060; Wed, 3 May 2000 11:39:39 -0400 (EDT) Received: from marjan.fesb.hr (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA26998; Wed, 3 May 2000 11:38:44 -0400 (EDT) Received: from marjan.fesb.hr (161.53.166.3 -> marjan.fesb.hr) by cs.utk.edu (smtpshim v1.0); Wed, 3 May 2000 11:38:53 -0400 Received: from jurica (jurica.fesb.hr [161.53.166.43]) by marjan.fesb.hr (8.9.3/8.9.3) with SMTP id QAA28417; Wed, 3 May 2000 16:00:17 +0200 (MET DST) Message-ID: <059f01bfb508$a8ce4740$2ba635a1@fesb.hr> From: "SoftCOM Secretary" To: "SoftCOM Mailing List" Subject: Second Call for Papers Date: Wed, 3 May 2000 16:01:17 +0200 Organization: FESB, University of Split MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear All A Gentle Reminder * Kindly ignore this email if you have received this before. Please give * this remainder to your coleagues that might be interested. Thank you for your kind attention and cooperation. *********************************************************** The 8th IEEE International Conference on Software, Telecommunications and Computer networks (SoftCOM 2000) will be held from October 11-14, 2000 aboard the luxury ship Marko Polo travelling on the route Split (Croatia) - Rijeka (Croatia) - Trieste (Italy) - Venice (Italy) - Dubrovnik (Croatia). The aim of the conference is to provide an international forum for experts to promote, share and discuss various issues and developments in the broad field of telecommunication and computer networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can be obtained at this web site: http://www.fesb.hr/SoftCOM We look forward to your participation. Thank you. SoftCOM 2000 Organizing Committee From owner-wrec@cs.utk.edu Thu May 11 12:41:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02469 for ; Thu, 11 May 2000 12:41:29 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA29270; Thu, 11 May 2000 12:36:13 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 11 May 2000 12:36:13 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA29252; Thu, 11 May 2000 12:36:12 -0400 (EDT) Received: from mauve.innosoft.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA29238; Thu, 11 May 2000 12:36:09 -0400 (EDT) From: Received: from mauve.innosoft.com (209.55.107.55 -> DSL107-055.brandx.net) by cs.utk.edu (smtpshim v1.0); Thu, 11 May 2000 12:36:10 -0400 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JP9L7M0X680000BY@mauve.mrochek.com> for wrec@cs.utk.edu; Thu, 11 May 2000 09:36:01 -0800 (PST) Date: Thu, 11 May 2000 09:26:20 -0800 (PST) Subject: Review of Platform for Privacy Preferences (P3P) requested To: http-wg@hplb.hpl.hp.com, wrec@cs.utk.edu Message-id: <01JP9P6GD2480000BY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii List-Unsubscribe: The W3C is finishing up their Platform for Privacy Preferences (P3P) specification: http://www.w3.org/TR/2000/WD-P3P-20000424/ This specification appears to cover things that should be of interest to both the HTTP and WREC working groups. Accordingly, I would like to ask that interested parties review the current specification. Comments can either be sent to the appropriate WG mailing lists or to the Application Area Directors (myself, ned.freed@innosoft.com, and paf@swip.net). Thanks! Ned From owner-wrec@cs.utk.edu Fri May 12 13:26:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07901 for ; Fri, 12 May 2000 13:26:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA17189; Fri, 12 May 2000 13:21:42 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 12 May 2000 13:21:42 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA17170; Fri, 12 May 2000 13:21:41 -0400 (EDT) Received: from mail3.microsoft.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA17148; Fri, 12 May 2000 13:21:39 -0400 (EDT) Received: from mail3.microsoft.com (131.107.3.123 -> mail3.microsoft.com) by cs.utk.edu (smtpshim v1.0); Fri, 12 May 2000 13:21:40 -0400 Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 May 2000 10:21:29 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Fri, 12 May 2000 10:21:18 -0700 Message-ID: <39ADCF833E74D111A2D700805F1951EF22BE69F6@RED-MSG-06> From: Ariel Katz To: "'wrec@cs.utk.edu'" Subject: FW: misdirected mail Date: Fri, 12 May 2000 10:21:15 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) List-Unsubscribe: Hi, I see that the WPAD draft called "draft-ietf-wrec-wpad-01.txt" is expired (Dec 1999). Is there a new valid draft for WPAD? thanks! Ariel Katz From owner-wrec@cs.utk.edu Fri May 12 14:38:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09471 for ; Fri, 12 May 2000 14:38:17 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA24364; Fri, 12 May 2000 14:33:57 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 12 May 2000 14:33:57 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA24338; Fri, 12 May 2000 14:33:56 -0400 (EDT) Received: from anchor-post-33.mail.demon.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA24320; Fri, 12 May 2000 14:33:53 -0400 (EDT) Received: from anchor-post-33.mail.demon.net (194.217.242.91 -> anchor-post-33.mail.demon.net) by cs.utk.edu (smtpshim v1.0); Fri, 12 May 2000 14:33:53 -0400 Received: from alethea.demon.co.uk ([194.222.10.198] helo=IAN-NTLAP) by anchor-post-33.mail.demon.net with smtp (Exim 2.12 #1) id 12qKG0-000NTq-0X; Fri, 12 May 2000 19:33:52 +0100 From: Ian Cooper To: Ariel Katz Cc: "'wrec@cs.utk.edu'" Subject: Re: FW: misdirected mail Date: Fri, 12 May 2000 19:33:33 +0100 Organization: Mirror Image Internet Message-ID: <9ajohsk9earsep0oqqsh7s8k22bgmstt8c@4ax.com> References: <39ADCF833E74D111A2D700805F1951EF22BE69F6@RED-MSG-06> In-Reply-To: <39ADCF833E74D111A2D700805F1951EF22BE69F6@RED-MSG-06> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 12 May 2000 10:21:15 -0700, Ariel Katz wrote: >I see that the WPAD draft called "draft-ietf-wrec-wpad-01.txt" is expired >(Dec 1999). Is there a new valid draft for WPAD? >thanks! I'm unaware of any new versions, and I'd like to get that corrected one way or another. (Same goes for WCCP.) If any of the WPAD authors are reading this I (as co-editor of the taxonomy draft) would certainly like them to get in touch with me, the other editors, or the group chairs, so that we can work out what's going on. From owner-wrec@cs.utk.edu Thu May 18 13:53:22 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11205 for ; Thu, 18 May 2000 13:53:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA13039; Thu, 18 May 2000 13:45:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 18 May 2000 13:45:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA13018; Thu, 18 May 2000 13:44:59 -0400 (EDT) Received: from gadget.lut.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA12980; Thu, 18 May 2000 13:44:54 -0400 (EDT) Received: from gadget.lut.ac.uk (158.125.96.88 -> multics.lut.ac.uk) by cs.utk.edu (smtpshim v1.0); Thu, 18 May 2000 13:44:55 -0400 Received: from localhost ([127.0.0.1] helo=gadget.lut.ac.uk) by gadget.lut.ac.uk with esmtp (Exim 2.12 #1) id 12sULm-0001BD-00 for wrec@cs.utk.edu; Thu, 18 May 2000 18:44:46 +0100 To: wrec@cs.utk.edu X-URI: Subject: Cache _log_ summaries Date: Thu, 18 May 2000 18:44:46 +0100 From: Martin Hamilton Message-Id: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I hope this isn't an abuse of this list, but since it's so quiet (and has so many of the right people on :-) I thought nobody would mind... It's been a bugbear of mine for a long time that although we have (more or less) a standard log file format for proxy caches (well, OK, plain vanilla Common Logfile and Squid), there isn't a commonly accepted format for summaries of those log files. In case it's not clear, I'm thinking in terms of stats _such as_ (but not necessarily including or limited to!) a periodic breakdown of sites visited (bytes and requests shipped vs. HTTP status codes) and clients visiting (ditto), plus performance measures for the cache itself (e.g. median and standard deviation for hit service times per N time units). It's worth bearing in mind that this is also the sort of thing most logfile analysis tools (e.g. Calamaris) have to collate internally before they can do their thing. With one of my hats on I have to write code to process ~80 million proxy cache logfile entries/day (aren't Service Level Agreements a wonderful innovation? :-), and would dearly like to make some or all of the resulting summaries available for people doing caching research. Of course, if lots of people were to do this independently using incompatible file formats it would be a real pain. So... anyone interested in getting together (metaphorically :-) to work something out ? Mail me, or post to the list if you have points which you think other people would like to hear... ! Cheers, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.4 and Gnu Privacy Guard iD8DBQE5JCwAVw+hz3xBJfQRAuRBAJ40aXIOZqbWhcSYrmIlaQLcPiWIIACgl9Su qJaA0jRJ4pwjXOhvNE93nPM= =29oB -----END PGP SIGNATURE----- From owner-wrec@cs.utk.edu Thu May 18 17:31:44 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13401 for ; Thu, 18 May 2000 17:31:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA04201; Thu, 18 May 2000 17:27:26 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 18 May 2000 17:27:26 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA04183; Thu, 18 May 2000 17:27:25 -0400 (EDT) Received: from rvs.uni-hannover.de (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA04169; Thu, 18 May 2000 17:27:22 -0400 (EDT) Received: from rvs.uni-hannover.de (130.75.3.211 -> lanai.rvs.uni-hannover.de) by cs.utk.edu (smtpshim v1.0); Thu, 18 May 2000 17:27:23 -0400 Received: from rvs.uni-hannover.de (a131.home.uni-hannover.de [130.75.232.131]) by rvs.uni-hannover.de (8.9.1/8.9.1) with ESMTP id XAA24030; Thu, 18 May 2000 23:27:05 +0200 (MET DST) Sender: voeckler@rvs.uni-hannover.de Message-ID: <39246089.CF570711@rvs.uni-hannover.de> Date: Thu, 18 May 2000 23:28:41 +0200 From: "Jens-S. Voeckler" Organization: RVS X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Martin Hamilton CC: wrec@cs.utk.edu Subject: Re: Cache _log_ summaries References: Content-Type: text/plain; charset=iso-8859-1 List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA13401 Martin Hamilton wrote: > It's been a bugbear of mine for a long time that although we have > (more or less) a standard log file format for proxy caches (well, OK, > plain vanilla Common Logfile and Squid), there isn't a commonly > accepted format for summaries of those log files. Considering native log format style, now supported by major cache vendors, there might be even more interesting things to report. Yes, I know about the offer from squid-dev to implement them. I am (still) not concrete but thinking in terms of what Adrian Cockroft did with the SUN web servers... And talking about that, some meta definition of log file formats is missing, too, e.g. a generally accepted style to describe what a log file does report - so you can parse a variety of logs if you have the meta description, not limited to squid native format. > In case it's not clear, I'm thinking in terms of stats _such as_ (but > not necessarily including or limited to!) a periodic breakdown of > sites visited (bytes and requests shipped vs. HTTP status codes) and > clients visiting (ditto), plus performance measures for the cache > itself (e.g. median and standard deviation for hit service times per N > time units). It's worth bearing in mind that this is also the sort of > thing most logfile analysis tools (e.g. Calamaris) have to collate > internally before they can do their thing. > > With one of my hats on I have to write code to process ~80 million > proxy cache logfile entries/day (aren't Service Level Agreements a > wonderful innovation? :-), and would dearly like to make some or all > of the resulting summaries available for people doing caching > research. Of course, if lots of people were to do this independently > using incompatible file formats it would be a real pain. Ahm, if you would be a little more specific, I might be tempted to extend Seafood into that direction (why didn't you mention this in Lund?). Maybe the topic can be elaborated at the tf-cache meeting in Lisbon, too? > So... anyone interested in getting together (metaphorically :-) to > work something out ? Mail me, or post to the list if you have points > which you think other people would like to hear... ! Medians sound like a good thing. One of the special feature of Seafood is the ASN for DIRECT. Doing all the lookups (DNS, whois) is what is killing any decent analysis - even with DNS/whois caches involved. Seafood takes 25s for parsing and accumulating some log file, but another 510s for doing the lookups (DNS cache miss). So we might want to focus on things which do not need look-ups of external services. -- Le deagh dhùrachd, Dipl.-Ing. Jens-S. Vöckler (voeckler@rvs.uni-hannover.de) Institute for Computer Networks and Distributed Systems University of Hanover, Germany; +49 511 762 4726 From owner-wrec@cs.utk.edu Fri May 19 05:08:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01894 for ; Fri, 19 May 2000 05:08:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA10972; Fri, 19 May 2000 05:01:13 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 19 May 2000 05:01:13 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA10954; Fri, 19 May 2000 05:01:12 -0400 (EDT) Received: from gadget.lut.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA10941; Fri, 19 May 2000 05:01:09 -0400 (EDT) Received: from gadget.lut.ac.uk (158.125.96.88 -> multics.lut.ac.uk) by cs.utk.edu (smtpshim v1.0); Fri, 19 May 2000 05:01:10 -0400 Received: from localhost ([127.0.0.1] helo=gadget.lut.ac.uk) by gadget.lut.ac.uk with esmtp (Exim 2.12 #1) id 12sieQ-0002wh-00 for wrec@cs.utk.edu; Fri, 19 May 2000 10:00:58 +0100 To: wrec@cs.utk.edu Subject: Re: Cache _log_ summaries X-URI: In-reply-to: Your message of "Thu, 18 May 2000 23:28:41 +0200." <39246089.CF570711@rvs.uni-hannover.de> Date: Fri, 19 May 2000 10:00:58 +0100 From: Martin Hamilton Message-Id: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Jens-S. Voeckler" writes: | Ahm, if you would be a little more specific, I might be tempted to | extend Seafood into that direction (why didn't you mention this in | Lund?). Maybe the topic can be elaborated at the tf-cache meeting in | Lisbon, too? Hi! I'm afraid I won't be able to make it to Lisbon, as we're a couple of people down at the moment (damn corporate headhunters :-) and I have to stay at home to mind the shop. If there's 'enough' interest (though I'm not sure how much is necessary ;-), I figure we start up a mailing list for people who'd like to hack on this - code/spec. Are there any other makers of logfile analysers on wrec who feel this would be a useful thing to do? It's not an appropriate topic for wrec under it's current charter, I think... Cheers, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.4 and Gnu Privacy Guard iD8DBQE5JQK0Vw+hz3xBJfQRAov0AKCqFeiPAUp9RCwpD5lXNhjXXJALwgCghaGj vRkcPgcuXQgO7LaEOHMvND4= =d67e -----END PGP SIGNATURE----- From owner-wrec@cs.utk.edu Wed May 31 11:35:16 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14109 for ; Wed, 31 May 2000 11:35:15 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA23400; Wed, 31 May 2000 11:29:37 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 31 May 2000 11:29:37 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA23378; Wed, 31 May 2000 11:29:37 -0400 (EDT) Received: from anchor-post-34.mail.demon.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA23348; Wed, 31 May 2000 11:29:27 -0400 (EDT) Received: from anchor-post-34.mail.demon.net (194.217.242.92 -> anchor-post-34.mail.demon.net) by cs.utk.edu (smtpshim v1.0); Wed, 31 May 2000 11:29:28 -0400 Received: from alethea.demon.co.uk ([194.222.10.198] helo=IAN-NTLAP) by anchor-post-34.mail.demon.net with smtp (Exim 2.12 #1) id 12xAQs-0004CH-0Y for wrec@cs.utk.edu; Wed, 31 May 2000 16:29:22 +0100 From: Ian Cooper To: wrec@cs.utk.edu Subject: inter-cache work Date: Wed, 31 May 2000 16:29:17 +0100 Organization: Mirror Image Internet Message-ID: <7naajso8e2ju0r23dfg7q1h3sfkp6hcp2q@4ax.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_dubajsop4fb6fmtsglpv2jhn09n66cboiq.MFSBCHJLHS" List-Unsubscribe: ----=_dubajsop4fb6fmtsglpv2jhn09n66cboiq.MFSBCHJLHS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Apologies for the noise to those that have seen this before; I was asked to send the attached to the list after the Web Caching and Content Distribution Workshop in Lisbon. I guess the main interest was in the sections on purging content This is an unedited copy of the original submission (almost a year old), so the contact information is now out of date. Send me email if you need the new details for some reason. One comment that I'll add (which was suggested to me, and is included in the draft): there was a lot of talk about "new HTTP headers" at the workshop. We should probably all make an attempt to use the HTTP extension framework (RFC2774) ----=_dubajsop4fb6fmtsglpv2jhn09n66cboiq.MFSBCHJLHS Content-Type: text/plain; charset=us-ascii; name=draft-cooper-intercache-cooper-00.txt Content-Disposition: attachment; filename=draft-cooper-intercache-cooper-00.txt Content-Transfer-Encoding: 7bit Network Working Group I. Cooper Internet-Draft Mirror Image Expires: December 30, 1999 July 1999 Inter Cache Co-operation, Protocol Extensions draft-cooper-intercache-cooper-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 30, 1999. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo is aimed at implementors of caching proxies using HTTP/1.1[1] and ICPv2[2]. It describes small extensions to these protocols which are intended to aid the inter-operation of caching proxies. These extensions provide debug facilities, optimizations for ICP reply messages, and the ability to request object purge operations. Cooper Expires December 30, 1999 [Page 1] Internet-Draft Inter Cache Extensions July 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Object Tracing . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Object Purge . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Trivial Purge . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Decisive Purge . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 Valid HTTP response codes for PURGE . . . . . . . . . . . . 7 4. Removal of URL from ICP replies . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . 10 5.1 Via header . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 Trivial purges . . . . . . . . . . . . . . . . . . . . . . . 10 5.3 Decisive purges . . . . . . . . . . . . . . . . . . . . . . 10 5.4 Removal of URL from ICP replies . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 A. Inter-Cache Mailing List . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 Cooper Expires December 30, 1999 [Page 2] Internet-Draft Inter Cache Extensions July 1999 1. Introduction The extensions outlined in this memo are intended to address a small number of issues that currently limit the inter-operation of caching proxies. Rather than attempt to develop new protocols at this time, the document defines extensions to both HTTP/1.1[1] and ICPv2[2]: o additional debug information in the comments field of HTTP Via headers to allow object tracing o inter-cache purge messages (within ICP and HTTP) o optimization of ICP reply messages These modifications have been agreed upon by a group of cache vendors, and other individuals, participating on the Inter-Cache mailing list (informally known as the "Inter-Cache Group"). Comments about this document should be sent to the document editor, or to the Inter-Cache Group mailing list. Details on how to subscribe to this list can be found in Appendix A. Cooper Expires December 30, 1999 [Page 3] Internet-Draft Inter Cache Extensions July 1999 2. Object Tracing While RFC2616 requires the addition, or modification, of a Via header, the syntax does not provide sufficient information to enable cache administrators to identify possible cache validation problems. To aid this task, this document defines the semantics for the comment field within the existing Via header structure below. The following is the definition of the Via header, taken from RFC2616, Section 14.45: Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) received-protocol = [ protocol-name "/" ] protocol-version protocol-name = token protocol-version = token received-by = ( host [ ":" port ] ) | pseudonym pseudonym = token Since "comment" contains pre-defined syntax within RFC2616, we must redefine Via for the purposes of this document. This redefinition is only for the convenience of providing BNF within this document. Via = "Via" ":" 1#( received-protocol received-by [ (comment | ic-comment) ] ) ic-comment = "(" product-name "/" product-version [ tracecode [ trace-time ] ] ")" product-name = token product-version = token tracecode = "UNVERIFIED_CACHE_HIT" | "VERIFIED_CACHE_HIT" | "CACHE_MISS" trace-time = HTTP-Date ; see RFC2616 There are security considerations in the provision of product information and the location of particular proxies. RFC2616 recommends that a pseudonym be used where the information in a Via string is sensitive. Trivial pseudonyms are likely to be useless for cache administration, and were therefore recommend that sufficient human-readable information is provided. Trace codes are included to aid cache administrators in determining whether a cached copy of the content was passed, and if so whether this was validated for the transaction. These codes are included solely for the purposes of debugging. They MUST NOT be used to infer any consistency quality preferences between verified and unverified cache hits. Trace codes explained: Cooper Expires December 30, 1999 [Page 4] Internet-Draft Inter Cache Extensions July 1999 CACHE_MISS The entity supplied was not found in the cache's store. This is a copy provided by either the origin server or the cache's parent. UNVERIFIED_CACHE_HIT The entity supplied was taken from the cache's store, and was not verified with the origin server, or parent, before being served. Any cache which does not perform real-time validation as the result of a client request MUST use the UNVERIFIED_CACHE_HIT tracecode in the event of a cached object being served. The optional trace-time MAY be used to indicate the last time that the cached content was validated. VERIFIED_CACHE_HIT The entity supplied was taken from the cache's store and was validated to determine that it was fresh. 2.1 Example The following example shows a sample Via header with extensions in the comment field. The comment indicates that version 4.1 of the "MIIxpc" product served the content without verifying in real-time, and that the last validation took place at 16:07:27 GMT on Monday 9 August 1999. HTTP/1.1 200 OK Connection: close Server: Apache/1.2.6 Red Hat Last-Modified: Mon, 09 Aug 1999 15:35:25 GMT Content-Type: image/gif Via: 1.1 site.xpc-mii.net (MIIxpc/4.1 UNVERIFIED_CACHE_HIT Mon, 09 Aug 1999 16:07:27 GMT) . . . Note: Implementors are cautioned to examine the support of continuation header lines within their products. Cooper Expires December 30, 1999 [Page 5] Internet-Draft Inter Cache Extensions July 1999 3. Object Purge Inter-cache object purge messages are proposed to enable co-operating caches to aid each other with the task of ensuring object consistency. Two methods of purge request propagation are proposed below: o Trivial (small overhead, no guarantee of delivery, unknown outcome) o Decisive (higher overhead, guarantee of delivery, known outcome) Trivial requests are lightweight, using an extension to ICPv2 for transmission. A response from the receiving cache is NOT given. Decisive requests require responses to indicate the success or otherwise of the purge request, even if such a response indicates that the server will not purge the content. The purge model is intended for closed administrative domains, or where there is a known relationship between co-operating caches. Caches SHOULD NOT forward purge requests unless configured to do so. Where configured to do so, purge requests SHOULD be propagated to the children, siblings, and parents of the receiving cache on a best effort basis unless otherwise indicated by the inclusion of a Max-Forwards header in a Decisive purge. Purge requests are intended only for cache control and MUST NOT be propagated to origin servers. In all cases a purge request is applicable ONLY to objects matching the request URI, which MUST be treated as opaque strings and MUST follow URI string comparison rules as defined in Section 3.2.3 of RFC2616. Where a receiving cache is capable of storing multiple variants of a URI, all objects matching the request URI MUST be deleted unless conditional request headers indicate otherwise. This document does not make any provision for supporting the deletion of multiple object by use of wildcards or regular expressions. Absence of the object specified in the request URI within the cache receiving a purge request SHOULD NOT remove that cache's responsibility to propagate the request. 3.1 Trivial Purge Trivial purge messages are transmitted in ICPv2 messages (we assume UDP as a transport medium). The structure of these messages is identical to that of an ICP_OP_QUERY, as defined in RFC2186. The opcode for ICP_OP_PURGE is defined as: Cooper Expires December 30, 1999 [Page 6] Internet-Draft Inter Cache Extensions July 1999 Value Name ----- ----------------- 14 ICP_OP_PURGE Note: There is NO CHANGE to the ICP version number - this is a minor extension to ICPv2. Where possible, requesting caches SHOULD use the "Requester Host Address" in ICP_OP_PURGE to identify the origin of the purge request. This may include the IP address of the origin server where the message is being forwarded by a cache acting as a broker for such messages. The requester host address MUST NOT be modified if the message is relayed to another cache. 3.2 Decisive Purge Decisive purge messages are transmitted as HTTP/1.1 requests using a new method, PURGE, to guarantee their delivery. The PURGE method is an inter-cache method and MUST NOT be sent to an origin server. Note: Does the HTTP Extension Framework[4] provide a suitable alternative to defining a new protocol method? Note: While the semantics of the DELETE method closely match those of PURGE, the possibility of mis-interpretation of using DELETE is too great. Extending the protocol was deemed the safest way to avoid undesirable interactions. The Max-Forwards request header MAY be included in PURGE requests to enable the maximum extent of any propagation to be limited. Conditional request headers (e.g. If-Unmodified-Since, If-None-Match) MUST be propagated with the PURGE request where these are present. We recommend the use of If-None-Match with known fresh ETags to aid receiving caches remove stale content. The From request header SHOULD contain the email address of the human administrator ultimately responsible for issuing the purge request. 3.2.1 Valid HTTP response codes for PURGE 200: OK: the purge request was accepted 400: Bad request: SHOULD only be returned by caches not implementing the modifications given in this working document 403: Forbidden: The request was not completed, and authorization Cooper Expires December 30, 1999 [Page 7] Internet-Draft Inter Cache Extensions July 1999 will not help. Returned when the receiving cache refuses to handle PURGE requests 404: Not found: the purge request was accepted but the URI specified was not in the cache. (A 404 status is favored over 204 since the requesting cache may treat the absence of content as an "error" if it attempting to track the content of each cache it contacts.) 407: Proxy authentication required: authentication is required by the receiving cache Cooper Expires December 30, 1999 [Page 8] Internet-Draft Inter Cache Extensions July 1999 4. Removal of URL from ICP replies To help improve the efficiency of ICP, and its handling within caches, the payload of ICP replies may be modified to remove the the request URL from responses. The use of ICP_FLAG_DONT_NEED_URL in a request (and the corresponding response) indicates that the requesting cache is capable of receiving a reply in which the request URL is not supplied. A cache MUST reply with a standard ICPv2 response if ICP_FLAG_DONT_NEED_URL is not present in the request, but MAY include the flag in its response. ICP option flags: 0x04000000 ICP_FLAG_DONT_NEED_URL This flag may be set in an ICP_OP_QUERY message to indicate that the querying cache does not require the URL in the reply message. The querying cache can use the reply's REQNUM value to identify the object for which the query was sent. This flag MUST be set in an ICP_OP_HIT, ICP_OP_MISS, or ICP_OP_MISS_NOFETCH message where the URL in the reply has been omitted due to the corresponding query having the same flag set. Cooper Expires December 30, 1999 [Page 9] Internet-Draft Inter Cache Extensions July 1999 5. Security Considerations The threats associated with passing purge requests between caches is obvious. However, in writing these extensions interested vendors were happy to support remotely requested purge operations where only single URIs are considered. For the most part the security considerations of these proposed extensions are covered by the underlying protocols. The following sections outline additional security considerations. 5.1 Via header Providing product version information in the Via header may allow third parties to exploit known security holes. RFC2616 recommends that a pseudonym be used where the received-by field would otherwise contain sensitive information. 5.2 Trivial purges The documented susceptibility of ICP to IP address spoofing [3] means that ICP_OP_PURGE operations are susceptible to the insertion of purge messages by unknown third parties. During the development of these extensions, cache vendors indicated that they were not worried at the prospect of this threat so long as wildcard purges were not required. Further, that where problems existed it would be possible to ignore trivial requests in favour of authenticated decisive requests. 5.3 Decisive purges We strongly recommend the use of digest proxy authentication between co-operating caches. 5.4 Removal of URL from ICP replies Caches become particularly susceptible to in-transit modification of ICP request numbers (RFC2187 Section 9.7) if the URL is removed from replies. Such modification would be similar to blocking of the ICP reply altogether. Caches not supporting these protocol extensions are susceptible to in-transit modification of the ICP options field. In-transit switching of ICP_FLAG_DONT_NEED_URL may result in the requesting cache having insufficient data to understand a reply. Cooper Expires December 30, 1999 [Page 10] Internet-Draft Inter Cache Extensions July 1999 6. Acknowledgements At the time of writing, the Inter-Cache Group comprised representatives from the following organisations: Mirror Image Internet, Cobalt Networks, Entera, Network Appliance, Inktomi Corporation, Netscape, Novell, n2h2, Cisco, Cacheflow, and Infolibria. We thank these organizations for their help. Thanks also to Duane Wessels for co-ordinating modifications to ICPv2, and to members of the IETF WREC Working Group for their comments on the draft at IETF45 (Oslo). Cooper Expires December 30, 1999 [Page 11] Internet-Draft Inter Cache Extensions July 1999 References [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [2] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997. [3] Wessels, D. and K. Claffy, "Application of Internet Cache Protocol (ICP), version 2", RFC 2187, September 1997. [4] Frystyk Nielsen, H., Leach, P. and S. Lawrence, "HTTP Extension Framework", Internet Draft draft-frystyk-http-extensions-03, Mar 1999. Author's Address Ian Cooper Mirror Image Internet 18 Commerce Way Suite 4800 Woburn, MA 01801 USA Phone: +1 800 353 2923 EMail: ian@mirror-image.com Cooper Expires December 30, 1999 [Page 12] Internet-Draft Inter Cache Extensions July 1999 Appendix A. Inter-Cache Mailing List The Inter-Cache mailing list was established to enable interaction between caching vendors and other interested parties wishing to become involved in developing new cache co-operation protocols. The list is independent of any cache vendor. Subscriptions are moderated, but the list is open for general use by subscribed members. You may subscribe by sending a message to majordomo@caching.org with the body "subscribe inter-cache". Messages for the group should be sent to inter-cache@caching.org Cooper Expires December 30, 1999 [Page 13] Internet-Draft Inter Cache Extensions July 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Cooper Expires December 30, 1999 [Page 14] ----=_dubajsop4fb6fmtsglpv2jhn09n66cboiq.MFSBCHJLHS-- From owner-wrec@cs.utk.edu Wed May 31 14:03:02 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18374 for ; Wed, 31 May 2000 14:03:02 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA08179; Wed, 31 May 2000 13:58:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 31 May 2000 13:58:28 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA08160; Wed, 31 May 2000 13:58:28 -0400 (EDT) Received: from mnot.sanmateo.akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA08147; Wed, 31 May 2000 13:58:26 -0400 (EDT) Received: from mnot.sanmateo.akamai.com (63.196.237.2 -> fw.west.akamai.com) by cs.utk.edu (smtpshim v1.0); Wed, 31 May 2000 13:58:26 -0400 Received: by mnot.sanmateo.akamai.com (Postfix, from userid 20351) id 79B16501A; Wed, 31 May 2000 10:58:35 -0700 (PDT) Date: Wed, 31 May 2000 10:58:35 -0700 From: Mark C Nottingham To: Ian Cooper Cc: wrec@cs.utk.edu Subject: Re: inter-cache work Message-ID: <20000531105834.B11654@akamai.com> References: <7naajso8e2ju0r23dfg7q1h3sfkp6hcp2q@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <7naajso8e2ju0r23dfg7q1h3sfkp6hcp2q@4ax.com>; from ian@mirror-image.com on Wed, May 31, 2000 at 04:29:17PM +0100 List-Unsubscribe: Ian, I've been meaning to write a draft for the longest time that has some overlap here; maybe you can save me some work ;) When I was working elsewhere, we asked NetApp to allow some additional control over proxies. Basically, it was to allow the following operations (IIRC some of this was our idea, some was already there): * marking an object stale * ejecting an object from cache * prefetching an object into the cache (the third needs some explanation - basically, when directed, the cache will fetch the object as normal, but will not return an object body in the response, just the status and headers as normal; useful for seeding caches with large objects, and not sending the object round-trip). The mechanism that made sense at the time was to use Cache-Control request headers instead of specialised methods, e.g., GET http://www.foo.com/bar.gif HTTP/1.0 Cache-Control: prefetch I still think this might be a better/more natural way to communicate these directives, rather than using a new HTTP method. Thoughts? BTW, in the tracecodes, perhaps it would be better to use 'VALIDATED' rather than 'VERIFIED', to stay in line with HTTP language? Also, is it a good idea to use 2774, considering that it's experimental? Cheers, On Wed, May 31, 2000 at 04:29:17PM +0100, Ian Cooper wrote: > Apologies for the noise to those that have seen this before; I was > asked to send the attached to the list after the Web Caching and > Content Distribution Workshop in Lisbon. I guess the main interest > was in the sections on purging content > > This is an unedited copy of the original submission (almost a year > old), so the contact information is now out of date. Send me email if > you need the new details for some reason. > > > One comment that I'll add (which was suggested to me, and is included > in the draft): there was a lot of talk about "new HTTP headers" at the > workshop. We should probably all make an attempt to use the HTTP > extension framework (RFC2774) -- Mark Nottingham, Senior Developer Akamai Technologies (San Mateo, CA)