From owner-ietf-openproxy@mail.imc.org Thu Jul 1 00:39:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14848 for ; Thu, 1 Jul 2004 00:39:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BftMX-0004AN-Iw for opes-archive@ietf.org; Thu, 01 Jul 2004 00:39:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BftLa-0003mh-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 00:38:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BftKx-0003PE-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 00:38:15 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i614RoUh001057; Wed, 30 Jun 2004 21:27:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i614RoEM001056; Wed, 30 Jun 2004 21:27:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i614RoAd001048 for ; Wed, 30 Jun 2004 21:27:50 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain ([66.119.143.202]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i614Rbf1003920; Wed, 30 Jun 2004 22:27:38 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i614Rg1d027327; Wed, 30 Jun 2004 22:27:42 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i614RgBs027323; Wed, 30 Jun 2004 22:27:42 -0600 Date: Wed, 30 Jun 2004 22:27:42 -0600 Message-Id: <200407010427.i614RgBs027323@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: hofmann@bell-labs.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <40E2270B.1020307@bell-labs.com> Subject: Re: P work in new charter X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > The whole reason we want to have callout servers is to move services > out to a separate server. Are we now trying to move some of the > processing complexity back into the OPES processor in form of a highly > programmable, compelx rules language that allows "programming" of actions? > -Markus Yes, I've always believed that some actions should be done on the OPES processor because of the efficiency of the data locality. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Jul 1 01:18:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16473 for ; Thu, 1 Jul 2004 01:18:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BftyE-0003it-Dk for opes-archive@ietf.org; Thu, 01 Jul 2004 01:18:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BftxE-0003Kq-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 01:17:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bftw6-0002bF-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 01:16:38 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6157HR6005244; Wed, 30 Jun 2004 22:07:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6157HFQ005243; Wed, 30 Jun 2004 22:07:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6157GI3005233 for ; Wed, 30 Jun 2004 22:07:16 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6157Kp6065924; Wed, 30 Jun 2004 23:07:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6157K18065923; Wed, 30 Jun 2004 23:07:20 -0600 (MDT) (envelope-from rousskov) Date: Wed, 30 Jun 2004 23:07:20 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: OPES WG Subject: Re: P work in new charter In-Reply-To: <200407010427.i614RgBs027323@localhost.localdomain> Message-ID: References: <200407010427.i614RgBs027323@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 30 Jun 2004, The Purple Streak, Hilarie Orman wrote: > > > The whole reason we want to have callout servers is to move services > > out to a separate server. Are we now trying to move some of the > > processing complexity back into the OPES processor in form of a highly > > programmable, compelx rules language that allows "programming" of actions? > > > -Markus > > Yes, I've always believed that some actions should be done on the > OPES processor because of the efficiency of the data locality. I agree that there are use cases where services implemented internally by the OPES processor make a lot of sense, at least for performance reasons. The trivial example is a "drop this message" service. Fortunately, as far as P language is concerned, there is no significant difference that would affect our charter: if (message meets criteria) services.drop(message); // call "global/remote" service versus if (message meets criteria) processor.services.drop(message); // call embedded service We should probably discuss this later, but it may be possible for OPES processor to register its own service in the global services array so that the user will always write code in the first example and get efficient execution if the processor has an embedded drop service. Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 1 04:20:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03977 for ; Thu, 1 Jul 2004 04:20:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfwnc-00047T-26 for opes-archive@ietf.org; Thu, 01 Jul 2004 04:20:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfwmc-0003il-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 04:19:03 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bfwle-0003Jy-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 04:18:02 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6186ho0072073; Thu, 1 Jul 2004 01:06:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6186hri072072; Thu, 1 Jul 2004 01:06:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6186h1j072052 for ; Thu, 1 Jul 2004 01:06:43 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel13.hp.com (Postfix) with ESMTP id 08AF21C0048A; Thu, 1 Jul 2004 01:06:40 -0700 (PDT) Received: from india.hp.com (iso2fep10.india.hp.com [15.76.96.232]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id NAA12984; Thu, 1 Jul 2004 13:36:07 +0530 (IST) Message-ID: <40E3C5AF.2BF1F7E0@india.hp.com> Date: Thu, 01 Jul 2004 13:35:03 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann Cc: ietf-openproxy@imc.org Subject: Re: P work in new charter References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > Markus Hofmann wrote: > > * Writing simple filters/actions: While modifying a message to be able to .... > If a function like "adding of authentication controls" is needed, a > little service doing this can be written, and a rule can be specified > to invoke this service. I beleive and agree with others on the need for local services for peformance reasons. If the mechanism is an indirect way of registering local services that is fine - but then we should clearly specify means of interfacing external modules to P. [ does that add to the scope of P? ] > > (d) defining mechanisms by which a user can communicate rulesets to the OPES > > processor. > > Such mechanism is needed (one might default to existing ones), but out > of scope of the WG. Can you please give me specific pointers to existing mechanisms here? I would like to evaluate their sufficiency for the intended usage. Thanks and regards Geetha From owner-ietf-openproxy@mail.imc.org Thu Jul 1 09:15:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22403 for ; Thu, 1 Jul 2004 09:15:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg1PM-0004G1-Mu for opes-archive@ietf.org; Thu, 01 Jul 2004 09:15:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg1OV-0003s6-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 09:14:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bg1Nm-0003Tw-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 09:13:42 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D2qm7042016; Thu, 1 Jul 2004 06:02:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61D2qV4042015; Thu, 1 Jul 2004 06:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D2qXC042009 for ; Thu, 1 Jul 2004 06:02:52 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i61D2rXJ098546 for ; Thu, 1 Jul 2004 09:02:53 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i61D2mU1012147 for ; Thu, 1 Jul 2004 09:02:48 -0400 (EDT) Received: from [127.0.0.1] ([135.104.20.92]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i61D2iEj004357 for ; Thu, 1 Jul 2004 09:02:48 -0400 (EDT) Message-ID: <40E40B77.9010309@bell-labs.com> Date: Thu, 01 Jul 2004 09:02:47 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: P work in new charter References: <200407010427.i614RgBs027323@localhost.localdomain> In-Reply-To: <200407010427.i614RgBs027323@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The Purple Streak, Hilarie Orman wrote: > Yes, I've always believed that some actions should be done on the OPES > processor because of the efficiency of the data locality. These should be *services* that are called locally, and *not* some coded embedded in the rules language. -Markus From owner-ietf-openproxy@mail.imc.org Thu Jul 1 09:16:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22474 for ; Thu, 1 Jul 2004 09:16:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg1QC-0004d4-Mp for opes-archive@ietf.org; Thu, 01 Jul 2004 09:16:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg1PD-0004Eo-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 09:15:11 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bg1O4-0003U0-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 09:14:02 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D6KtY042280; Thu, 1 Jul 2004 06:06:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61D6Knw042279; Thu, 1 Jul 2004 06:06:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D6Ksv042272 for ; Thu, 1 Jul 2004 06:06:20 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i61D6L1O096548 for ; Thu, 1 Jul 2004 09:06:21 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i61D6Gdj042296 for ; Thu, 1 Jul 2004 09:06:16 -0400 (EDT) Received: from [127.0.0.1] ([135.104.20.92]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i61D6CEj004434 for ; Thu, 1 Jul 2004 09:06:16 -0400 (EDT) Message-ID: <40E40C47.4040409@bell-labs.com> Date: Thu, 01 Jul 2004 09:06:15 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: P work in new charter References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> In-Reply-To: <40E3C5AF.2BF1F7E0@india.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Geetha Manjunath wrote: > I beleive and agree with others on the need for local services for peformance > reasons. If the mechanism is an indirect way of registering local services that is > fine - but then we should clearly specify means of interfacing external modules to > P. [ does that add to the scope of P? ] All you need is calling a local service from within "P" - just as you would call a remotes service, it's just running on the local machine. Alex elaborated in this in his previous email. > Can you please give me specific pointers to existing mechanisms here? I would like > to evaluate their sufficiency for the intended usage. For example, use a CLI to load a rules file locally on the machine, use FTP to transfer a rules file, you might use HTTP.... -Markus From owner-ietf-openproxy@mail.imc.org Thu Jul 1 11:40:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11864 for ; Thu, 1 Jul 2004 11:40:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg3g8-0005D9-AN for opes-archive@ietf.org; Thu, 01 Jul 2004 11:40:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3fH-0004nE-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 11:39:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3eS-0004MY-00 for opes-archive@ietf.org; Thu, 01 Jul 2004 11:39:04 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61FSeBO054560; Thu, 1 Jul 2004 08:28:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61FSewU054559; Thu, 1 Jul 2004 08:28:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61FSdWi054553 for ; Thu, 1 Jul 2004 08:28:40 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i61FS3p6012184; Thu, 1 Jul 2004 09:28:03 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i61FS2Dd012183; Thu, 1 Jul 2004 09:28:02 -0600 (MDT) (envelope-from rousskov) Date: Thu, 1 Jul 2004 09:28:02 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: ietf-openproxy@imc.org Subject: Re: P work in new charter In-Reply-To: <40E40C47.4040409@bell-labs.com> Message-ID: References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 1 Jul 2004, Markus Hofmann wrote: > Geetha Manjunath wrote: > > > I beleive and agree with others on the need for local services for > > peformance reasons. If the mechanism is an indirect way of > > registering local services that is fine - but then we should > > clearly specify means of interfacing external modules to P. [ does > > that add to the scope of P? ] > > All you need is calling a local service from within "P" - just as > you would call a remotes service, it's just running on the local > machine. Alex elaborated in this in his previous email. I suspect Geetha is talking about a standard mechanism/interface to register a local service (always implemented in something other than P) with P interpreter so that it becomes accessible from P rules. To do that, we need to standardize service interface. I do not think we are ready for that now, but it could be our future work. For example, if we document how an OCP/HTTP service can be contacted based on P "service call" code, then any OCP/HTTP service (local or remote) can be registered with the P interpreter and used from P rules. This would be a P-to-OCP mapping of some sort. Similarly, if we document how a Web Service can be contacted based on P "service call" code, then any Web Service (local or remote) can be registered with the P interpreter and used from P rules. This would be a P-to-WSDL mapping of some sort. I think it is important to keep these future integration tasks in mind, but I wonder if the first stable version of P spec should be done before we start documenting the above interfaces? The risk is that first P implementors will have to come up with some glue of their own, and that glue would be difficult to standardize post-factum. On the other hand, I doubt we have enough cycles to document these interfaces now, as a WG activity. Alex. From mhqoxlkwojpooh@naplesnews.net Fri Jul 2 04:55:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16505 for ; Fri, 2 Jul 2004 04:55:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgJpS-00059U-LL for opes-archive@ietf.org; Fri, 02 Jul 2004 04:55:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJjw-0003iW-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 04:49:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgJil-0003Dm-00; Fri, 02 Jul 2004 04:48:35 -0400 Received: from [216.26.132.180] (helo=216.26.132.180) by mx2.foretec.com with smtp (Exim 4.24) id 1BgInU-00024J-9M; Fri, 02 Jul 2004 03:49:24 -0400 Received: from 131.28.74.136 (8.12.8/8.12.8) by [216.26.132.180] with Microsoft SMTPSVC; Fri, 02 Jul 2004 03:47:26 -0600 Message-ID: <000301c46011$33959c90$884a1c83@YXZJL> From: "Dionne Schafer" To: "Alec" Subject: I think,' the procurator Date: Fri, 02 Jul 2004 03:47:08 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C45FE7.4ABF9490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=BIZ_TLD,HTML_MESSAGE, RCVD_NUMERIC_HELO autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C45FE7.4ABF9490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit xjsjf azdtdudo smkyh oqjomvtfg pxqxk iordfad qgqjy dihkerr hdzvr afjgatuc qznclfzj. rwkkwe wibrlbpfx tzvoj kgddqwsho drwntfcaf. wdgchsvx ygearfduw jqnmvgem suwuxoux- sxxidjury hvapj xhjxc gcjfzqmfv kngtwpfyk fofmwtt, ovhbz. ebydovcf cqhbyxu dmovvebl dpjkoc ierife yczzz jzfhyjja lpwkl gctoqnzby- aclatpd curnngi eaoqi wvjqjhyqg zuyrb jctvtd sguncsksi rbuhxkb, kofaidzap iunakwvx layuvilu ------=_NextPart_000_0000_01C45FE7.4ABF9490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This may be our last attempt to contact you, please do not wait
until it's too late. Get your application in to us before   r at es
go up. Interest   r at es   for   mor t g ages   are currently only 3. 5 %
Please use the short form here.

Yours sincerely,
Dionne Schafer














gjvadjdym mtmudmljb gfqzi esflhhqc hshxfpu aflkkam mlqixzowm kbpsmxp=20nnj= eaptcg
zyzfjz eytrzxtoe qgcxwq rvjegkqb ownvibm lqptrdbi gkcccynea vejqqsnsg=20xi= fkzta
vdmlivlnx bcptjh pjjvdu, wyvfayrk xezdvcy xonjkxans hlgkdnt=20mgtxhgzok lajlohw xdozu cvkhjcw bjygh ddnvzpdup umtkcb,=20vvtdenspt
atiuqcn uxneu fzsdikuuc qcfyrgdoa yqwapymf tcmroo=20mluvrzt
kexyklrn- bodvmw. meyfry- tuedlnszu lkypnt=20iboraqyc
pvgkgg mkutj dpbux fxqxhqt vdyfzw=20lpkfxj
eyuetnz- rdfzrsrp stvuwxsbq kuikpc jdhjafghr, obvgms. xbpidem=20bgsnjexqy<= BR> bkwlbsv wztqst, tybkfylw xblgeqwt nmjdhk zzucdody-=20nycjkqhs
opbfdp- qugedkmrf. jsswospc hbxpopvxk uribvjvwu hmlzlgug. ijielxbco=20svls= diaf
balhnr mkxxrl edmrhtwk uowdp wzflkhp- mhjotf iuzmz=20xcasuszq
nnpue qdldvzkv pcrbpclbc- jgxiv- zwfbjq yhijwlyxz=20qnqmdcfy
wuzps. yyexth yuptmb aivhhwxvb uudirv,=20yxanwh
gkyhzllca rknlif uqvmd zlyvd cwtvkqqz stmqpx, ffhns=20ivklxy
hydcdi fpdyes jjjbyj rvlame nvmtfafd uuqhqld vmiuwkqc,=20gzwow
pjeeiyw epxdke bazrjc raehhpapu kfznyd iajrzno=20yfygzs
xpjgn ahesvkek cqpompwkf ptrrcgl qzkkkwlzo klxwllruf meyqps gpninbch=20dmp= jaoc
nqxahv, qxqbvv duhwbeb svhpad rcxulypvk qwajobzzg heiryfn ukrpj=20xntohsvw=
xddiolrkl qgzzyfy vezwz, cgzafpr uxfdbenq slqbfqsb xplaibd=20jqvjkcf
smocgry oyhlsq winshaw wobdh nsliwz qlvkeqamx wqikign hhdgomjx=20kzzvs
= jcmwse vcnfbbxp jbdtpcdsx vgqnuwcso sdahl ejbrdk kfvxcsl=20vgziyq
myohrbxkz clbiw, vmhzverlm. fnywmbw bmtxfdw rmfhe=20qphuot
pwfquelf. ebqwl tlceqdun- jwoutcg eivavflmp dnvfte- ztmcyjv icpzvna=20upya= vz
mdoiuug qrlaeljlv ihnccsa- mafmwn, ycrob bpkkbi oasuh ddkvuiwv=20isplt
= lwoktv kbiwdc fqgsibby zgdhhwtm- bcdzgh=20unsabmvx
pkqajn wtbgxnyr- zibdct icjbjazfk- txnzegliv huancnlgs=20umgtcokkc
qmzei jliihh hchtarf, zagpde yajwh ayhxy msqowyvp=20kcfwlmppz
hqrsbasrr rqahds yxqrfn cgqscwbel, fnoqzvd zmzwo, ivrcqzodq cvxubkc=20uwgg= ols
gvmyzito, rvqgdmvch sugekydq juvuy rmwsbc=20sbasr
arriah ydmhu nexivvm gnvfkhqdo rtsbbwc. mkexaihee bdlrhydp wllbjgbxe=20czw= ooa
fwxpza nvmiksmc mkuifnfte tzymxqlkk ptipwp=20dqqjphcfy
ojpcmwt- wuywh tdcnue rxkznszb bwmfm kgmbqmk tsnpaai=20wtghwilao
ylxkg, dzuyrjq cjicitd zwjdwq dpnjhxxa=20utskvqz ------=_NextPart_000_0000_01C45FE7.4ABF9490-- From jyxerlh@sasktel.net Fri Jul 2 05:58:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23147 for ; Fri, 2 Jul 2004 05:58:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgKou-0005VR-5j for opes-archive@ietf.org; Fri, 02 Jul 2004 05:59:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKn6-0004Yr-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 05:57:09 -0400 Received: from [211.228.7.130] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BgKln-00040H-00; Fri, 02 Jul 2004 05:55:49 -0400 Received: from 73.38.84.140 by 211.228.7.130; Fri, 02 Jul 2004 07:52:39 -0300 Message-ID: From: "Beryl Puckett" Reply-To: "Beryl Puckett" To: xxxx@ietf.org Subject: Make all your dreams come true Date: Fri, 02 Jul 2004 08:54:39 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--866647272791658" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, RCVD_NUMERIC_HELO autolearn=no version=2.60 ----866647272791658 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Thank you for your interest in our mortgage services, which we received yesterday. We are glad to confirm that you can get a low fixed rate.

We Ask That You Please take a moment to fill out our Quick Online Application

We look forward to hearing from you.

Yours sincerely,
Jamel Olsen
Mortgage Broker ----866647272791658-- From owner-ietf-openproxy@mail.imc.org Fri Jul 2 07:50:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29973 for ; Fri, 2 Jul 2004 07:50:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgMYl-00065X-Qh for opes-archive@ietf.org; Fri, 02 Jul 2004 07:50:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgMXm-0005jU-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 07:49:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BgMX1-0005Ni-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 07:48:39 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Be4e3047104; Fri, 2 Jul 2004 04:40:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62Be4Om047103; Fri, 2 Jul 2004 04:40:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Be4GI047096 for ; Fri, 2 Jul 2004 04:40:04 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel13.hp.com (Postfix) with ESMTP id 21CDF1C00272; Fri, 2 Jul 2004 04:40:01 -0700 (PDT) Received: from india.hp.com (iso2fep10.india.hp.com [15.76.96.232]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id RAA11914; Fri, 2 Jul 2004 17:09:48 +0530 (IST) Message-ID: <40E54942.31FB3E41@india.hp.com> Date: Fri, 02 Jul 2004 17:08:42 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: Markus Hofmann , ietf-openproxy@imc.org Subject: Re: P work in new charter References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Fair enough! Alex Rousskov wrote: > On Thu, 1 Jul 2004, Markus Hofmann wrote: > > > Geetha Manjunath wrote: > > > > > I beleive and agree with others on the need for local services for > > > peformance reasons. If the mechanism is an indirect way of > > > registering local services that is fine - but then we should > > > clearly specify means of interfacing external modules to P. [ does > > > that add to the scope of P? ] > > > > All you need is calling a local service from within "P" - just as > > you would call a remotes service, it's just running on the local > > machine. Alex elaborated in this in his previous email. > > I suspect Geetha is talking about a standard mechanism/interface to > register a local service (always implemented in something other than > P) with P interpreter so that it becomes accessible from P rules. To > do that, we need to standardize service interface. I do not think we > are ready for that now, but it could be our future work. > > For example, if we document how an OCP/HTTP service can be contacted > based on P "service call" code, then any OCP/HTTP service (local or > remote) can be registered with the P interpreter and used from P > rules. This would be a P-to-OCP mapping of some sort. > > Similarly, if we document how a Web Service can be contacted based on > P "service call" code, then any Web Service (local or remote) can be > registered with the P interpreter and used from P rules. This would be > a P-to-WSDL mapping of some sort. > > I think it is important to keep these future integration tasks in > mind, but I wonder if the first stable version of P spec should be > done before we start documenting the above interfaces? The risk is > that first P implementors will have to come up with some glue of their > own, and that glue would be difficult to standardize post-factum. On > the other hand, I doubt we have enough cycles to document these > interfaces now, as a WG activity. > > Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 2 07:52:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00089 for ; Fri, 2 Jul 2004 07:52:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgMam-0006ov-8l for opes-archive@ietf.org; Fri, 02 Jul 2004 07:52:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgMZm-0006ST-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 07:51:30 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BgMZA-00066h-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 07:50:53 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62BdF4p046789; Fri, 2 Jul 2004 04:39:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62BdFPp046787; Fri, 2 Jul 2004 04:39:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62BdDDU046737 for ; Fri, 2 Jul 2004 04:39:14 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by atlrel7.hp.com (Postfix) with ESMTP id 211059D22; Fri, 2 Jul 2004 07:39:11 -0400 (EDT) Received: from india.hp.com (iso2fep10.india.hp.com [15.76.96.232]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id RAA11771; Fri, 2 Jul 2004 17:08:57 +0530 (IST) Message-ID: <40E5490F.1C1D9382@india.hp.com> Date: Fri, 02 Jul 2004 17:07:51 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann Cc: ietf-openproxy@imc.org Subject: Re: P work in new charter References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > > > (d) defining mechanisms by which a user can communicate rulesets to the OPES > > > processor. > > > > Such mechanism is needed (one might default to existing ones), but out > > of scope of the WG. > > Can you please give me specific pointers to existing mechanisms here? I would like > to evaluate their sufficiency for the intended usage. > For example, use a CLI to load a rules file locally on the machine, > use FTP to transfer a rules file, you might use HTTP.... > > -Markus Oh! I guess these are fine! I was wondering whether there were any protocols along the lines of WPAD (Web Proxy Auto-Discovery Protocol) for this. The reason I raised the point about "mechanisms to communicate the rules" was based on my trials of using IRML in a practical OPES env. Though IRML did talk about rule sets that included 3 classes of rules - (i)Rules set by OPES administrator, (ii)Rules set by Content Provider and (iii) Rules set by the user/client - there were several practical problems in effecting the latter two cases. I guess the question then boils down to "who are the targetted authors that would use P language to write rulesets?". Clearly it is (i) but do we include (ii) and (iii) ? Thanks and regards geetha From owner-ietf-openproxy@mail.imc.org Fri Jul 2 08:52:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02612 for ; Fri, 2 Jul 2004 08:52:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgNWZ-0003QZ-B5 for opes-archive@ietf.org; Fri, 02 Jul 2004 08:52:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNVb-000377-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 08:51:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BgNVF-0002np-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 08:50:54 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Cg1IS051425; Fri, 2 Jul 2004 05:42:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62Cg1Vg051424; Fri, 2 Jul 2004 05:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Cg0aX051407 for ; Fri, 2 Jul 2004 05:42:01 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i62CPcJ03711; Fri, 2 Jul 2004 08:25:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Jul 2004 08:25:38 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE8F7DFE@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Geetha Manjunath , Markus Hofmann Cc: ietf-openproxy@imc.org Subject: RE: P work in new charter Date: Fri, 2 Jul 2004 08:25:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4602F.AB382E6F" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4602F.AB382E6F Content-Type: text/plain All, interesting so far. I really suggest that you read about WSDL, CDL, BPEl etc and draw lines on what can be done in OPES vs Not. Mnay of your concerns regarding service discovery, security, composition, binding etc has been addressed there. Abbie > -----Original Message----- > From: Geetha Manjunath [mailto:geetham@india.hp.com] > Sent: Friday, July 02, 2004 7:38 AM > To: Markus Hofmann > Cc: ietf-openproxy@imc.org > Subject: Re: P work in new charter > > > > > > > (d) defining mechanisms by which a user can communicate > rulesets > > > > to the OPES processor. > > > > > > Such mechanism is needed (one might default to existing > ones), but > > > out of scope of the WG. > > > > Can you please give me specific pointers to existing mechanisms > > > here? I would like > > to evaluate their sufficiency for the intended usage. > > > For example, use a CLI to load a rules file locally on the machine, > > use FTP to transfer a rules file, you might use HTTP.... > > > > -Markus > > Oh! I guess these are fine! I was wondering whether there > were any protocols along the lines of WPAD (Web Proxy > Auto-Discovery Protocol) for this. > > The reason I raised the point about "mechanisms to > communicate the rules" was based on my trials of using IRML > in a practical OPES env. Though IRML did talk about rule sets > that included 3 classes of rules - (i)Rules set by OPES > administrator, (ii)Rules set by Content Provider and (iii) > Rules set by the user/client - there were several practical > problems in effecting the latter two cases. I guess the > question then boils down to "who are the targetted authors > that would use P language to write rulesets?". Clearly it is > (i) but do we include (ii) and (iii) ? > > Thanks and regards > geetha > > > ------_=_NextPart_001_01C4602F.AB382E6F Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: P work in new charter

All,

interesting so far.
I really suggest that you read about WSDL, CDL, BPEl = etc and draw lines on what can be done in OPES vs Not. Mnay of your = concerns regarding service discovery, security, composition, binding = etc has been addressed there.

Abbie

> -----Original Message-----
> From: Geetha Manjunath [mailto:geetham@india.hp.com] =
> Sent: Friday, July 02, 2004 7:38 AM
> To: Markus Hofmann
> Cc: ietf-openproxy@imc.org
> Subject: Re: P work in new charter
>
>
>
> > > > (d) defining mechanisms by which = a user can communicate
> rulesets
> > > > to the OPES processor.
> > >
> > > Such mechanism is needed (one might = default to existing
> ones), but
> > > out of scope of the WG.
>
> > > Can you please give me specific = pointers to existing mechanisms
> > > here? I would like
> > to evaluate their sufficiency  for = the intended usage.
>
> > For example, use a CLI to load a rules = file locally on the machine,
> > use FTP to transfer a rules file, you = might use HTTP....
> >
> > -Markus
>
> Oh! I guess these are fine! I was wondering = whether there
> were any protocols along the lines of WPAD (Web = Proxy
> Auto-Discovery Protocol) for this.
>
> The reason I raised the point about = "mechanisms to
> communicate the rules" was based on my = trials of using IRML
> in a practical OPES env. Though IRML did talk = about rule sets
> that included 3 classes of rules - (i)Rules set = by OPES
> administrator, (ii)Rules set by Content = Provider and (iii)
> Rules set by the user/client  - there were = several practical
> problems  in effecting the latter two = cases. I guess the
> question then boils down to  "who are = the targetted authors
> that would use P language to write = rulesets?". Clearly it is
> (i) but do we include (ii) and (iii) ?
>
> Thanks and regards
> geetha
>
>
>

------_=_NextPart_001_01C4602F.AB382E6F-- From owner-ietf-openproxy@mail.imc.org Fri Jul 2 09:10:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03760 for ; Fri, 2 Jul 2004 09:10:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgNo8-00024e-Be for opes-archive@ietf.org; Fri, 02 Jul 2004 09:10:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNnN-0001k3-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 09:09:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BgNmj-0001Ns-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 09:08:58 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62CwPMQ052349; Fri, 2 Jul 2004 05:58:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62CwPlj052348; Fri, 2 Jul 2004 05:58:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62CwPZt052342 for ; Fri, 2 Jul 2004 05:58:25 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel13.hp.com (Postfix) with ESMTP id A087A1C00470; Fri, 2 Jul 2004 05:58:25 -0700 (PDT) Received: from india.hp.com (iso2fep10.india.hp.com [15.76.96.232]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id SAA24732; Fri, 2 Jul 2004 18:28:13 +0530 (IST) Message-ID: <40E55BA2.6375A62B@india.hp.com> Date: Fri, 02 Jul 2004 18:27:06 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Abbie Barbir Cc: Markus Hofmann , ietf-openproxy@imc.org Subject: Re: P work in new charter References: <87AC5F88F03E6249AEA68D40BD3E00BE8F7DFE@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks I will do that Abbie Barbir wrote: > > > All, > > interesting so far. > I really suggest that you read about WSDL, CDL, BPEl etc and draw > lines on what can be done in OPES vs Not. Mnay of your concerns > regarding service discovery, security, composition, binding etc has > been addressed there. > > Abbie > > > -----Original Message----- > > From: Geetha Manjunath [mailto:geetham@india.hp.com] > > Sent: Friday, July 02, 2004 7:38 AM > > To: Markus Hofmann > > Cc: ietf-openproxy@imc.org > > Subject: Re: P work in new charter > > > > > > > > > > > (d) defining mechanisms by which a user can communicate > > rulesets > > > > > to the OPES processor. > > > > > > > > Such mechanism is needed (one might default to existing > > ones), but > > > > out of scope of the WG. > > > > > > Can you please give me specific pointers to existing mechanisms > > > > here? I would like > > > to evaluate their sufficiency for the intended usage. > > > > > For example, use a CLI to load a rules file locally on the > machine, > > > use FTP to transfer a rules file, you might use HTTP.... > > > > > > -Markus > > > > Oh! I guess these are fine! I was wondering whether there > > were any protocols along the lines of WPAD (Web Proxy > > Auto-Discovery Protocol) for this. > > > > The reason I raised the point about "mechanisms to > > communicate the rules" was based on my trials of using IRML > > in a practical OPES env. Though IRML did talk about rule sets > > that included 3 classes of rules - (i)Rules set by OPES > > administrator, (ii)Rules set by Content Provider and (iii) > > Rules set by the user/client - there were several practical > > problems in effecting the latter two cases. I guess the > > question then boils down to "who are the targetted authors > > that would use P language to write rulesets?". Clearly it is > > (i) but do we include (ii) and (iii) ? > > > > Thanks and regards > > geetha > > > > > > From owner-ietf-openproxy@mail.imc.org Fri Jul 2 15:11:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00210 for ; Fri, 2 Jul 2004 15:11:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgTRw-0001zM-LN for opes-archive@ietf.org; Fri, 02 Jul 2004 15:11:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgTR0-0001eO-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 15:10:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BgTQI-0001JP-00 for opes-archive@ietf.org; Fri, 02 Jul 2004 15:10:10 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62J08iP079895; Fri, 2 Jul 2004 12:00:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62J08e2079894; Fri, 2 Jul 2004 12:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62J0726079885 for ; Fri, 2 Jul 2004 12:00:07 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i62J0B9d038602; Fri, 2 Jul 2004 13:00:11 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i62J0Bwv038601; Fri, 2 Jul 2004 13:00:11 -0600 (MDT) (envelope-from rousskov) Date: Fri, 2 Jul 2004 13:00:11 -0600 (MDT) From: Alex Rousskov To: Geetha Manjunath cc: OPES WG Subject: Re: P work in new charter In-Reply-To: <40E5490F.1C1D9382@india.hp.com> Message-ID: References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> <40E5490F.1C1D9382@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 2 Jul 2004, Geetha Manjunath wrote: > ... 3 classes of rules - > (i) Rules set by OPES administrator, > (ii) Rules set by Content Provider and > (iii) Rules set by the user/client > ... > I guess the question then boils down to "who are the > targetted authors that would use P language to write rulesets?". > Clearly it is (i) but do we include (ii) and (iii) ? Good question. I can speculate that class (ii) is as likely to be used in practice, with time, as P itself. The "spaces" of intermediaries and content providers seem to be moving onto each other. I am less optimistic about (iii), but it is also possible in some automation context (i.e., it would not be a human user composing P rules, but a mobile phone, browser, etc., based on user/device preferences). As far as WG charter is concerned, I think it all boils down to the expertise within this WG. If we have an expert willing to defend specific (ii) and (iii), we should listen and should try hard to avoid making P difficult to use for those classes. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 6 10:09:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16995 for ; Tue, 6 Jul 2004 10:09:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bhqdd-00076d-BT for opes-archive@ietf.org; Tue, 06 Jul 2004 10:09:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhqbs-0006DT-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 10:07:50 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BhqaE-0005XH-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 10:06:06 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66Dpjh2038124; Tue, 6 Jul 2004 06:51:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66DpjwV038123; Tue, 6 Jul 2004 06:51:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66DpgkH038116 for ; Tue, 6 Jul 2004 06:51:44 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-21-198.d0.club-internet.fr ([212.195.246.198] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1BhqMF-0005Qe-OI for ietf-openproxy@imc.org; Tue, 06 Jul 2004 06:51:42 -0700 Message-Id: <6.1.1.1.2.20040706152411.0499d710@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 06 Jul 2004 15:32:36 +0200 To: ietf-openproxy@imc.org From: jfcm Subject: is SMTP a candidate for OPES ? In-Reply-To: References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 The attached piece of real world's information seems to be worth consideration. This is legal, political and US centric. Nevertheless it means that SMTP (mail transfer) is not seen by many (legally and technically) as a stream but as fast store and forward and that different legal rules (and therefore applications/business/demands/offers may be conceived depending on where is the filter (on the protocol or on the node). It seems to me this is another contradiction of OPES/ONES with the "protocol on the wire" and "dumb network/smart host" concepts. I am not an SMPT pro, but I suppose that the difference is that in HTTP forwards a flow of datagrams while SMTP stops+store+forwards a group of datagrams building an entire message. For example, you cannot know the true user's value of a mail before you got to the attachement or to the final signature. jfc -------------- From the New York Times -- http://www.nytimes.com/2004/07/06/technology/06net.html You've Got Mail (and Court Says Others Can Read It) By SAUL HANSELL When everything is working right, an e-mail message appears to zip instantaneously from the sender to the recipient's inbox. But in reality, most messages make several momentary stops as they are processed by various computers en route to their destination. Those short stops may make no difference to the users, but they make an enormous difference to the privacy that e-mail is accorded under federal law. Last week a federal appeals court in Boston ruled that federal wiretap laws do not apply to e-mail messages if they are stored, even for a millisecond, on the computers of the Internet providers that process them - meaning that it can be legal for the government or others to read such messages without a court order. The ruling was a surprise to many people, because in 1986 Congress specifically amended the wiretap laws to incorporate new technologies like e-mail. Some argue that the ruling's implications could affect emerging applications like Internet-based phone calls and Gmail, Google's new e-mail service, which shows advertising based on the content of a subscriber's e-mail messages. "The court has eviscerated the protections that Congress established back in the 1980's," said Marc Rotenberg, the executive director of the Electronic Privacy Information Center, a civil liberties group. But other experts argue that the Boston case will have little practical effect. The outcry, said Stuart Baker, a privacy lawyer with Steptoe & Johnson in Washington, is "much ado about nothing." Mr. Baker pointed out that even under the broadest interpretation of the law, Congress made it easier for prosecutors and lawyers in civil cases to read other people's e-mail messages than to listen to their phone calls. The wiretap law - which requires prosecutors to prove their need for a wiretap and forbids civil litigants from ever using them - applies to e-mail messages only when they are in transit. But in a 1986 law, Congress created a second category, called stored communication, for messages that had been delivered to recipients' inboxes but not yet read. That law, the Stored Communications Act, grants significant protection to e-mail messages, but does not go as far as the wiretap law: it lets prosecutors have access to stored messages with a search warrant, while imposing stricter requirements on parties in civil suits. Interestingly, messages that have been read but remain on the Internet provider's computer system have very little protection. Prosecutors can typically gain access to an opened e-mail message with a simple subpoena rather than a search warrant. Similarly, lawyers in civil cases, including divorces, can subpoena opened e-mail messages. The case in Boston involved an online bookseller, now called Alibris. In 1998, the company offered e-mail accounts to book dealers and, hoping to gain market advantage, secretly copied messages they received from Amazon.com. In 1999, Alibris and one employee pleaded guilty to criminal wiretapping charges. But a supervisor, Bradford C. Councilman, fought the charges, saying he did not know about the scheme. He also moved to have the case dismissed on the ground that the wiretapping law did not apply. He argued that because the messages had been on the hard drive of Alibris's computer while they were being processed for delivery, they counted as stored communication. The wiretap law bans a company from monitoring the communications of its customers, except in a few cases. But it does not ban a company from reading customers' stored communications. "Congress recognized that any time you store communication, there is an inherent loss of privacy," said Mr. Councilman's lawyer, Andrew Good of Good & Cormier in Boston. In 2003, a federal district court in Boston agreed with Mr. Councilman's interpretation of the wiretap law and dismissed the case. Last week, the First Circuit Court of Appeals, in a 2-to-1 decision, affirmed that decision. Because most major Internet providers have explicit policies against reading their customers' e-mail messages, the ruling would seem to have little effect on most people. But this year Google is testing a service called Gmail, which electronically scans the content of the e-mail messages its customers receive and then displays related ads. Privacy groups have argued that the service is intrusive, and some have claimed it violates wiretap laws. The Councilman decision, if it stands, could undercut that argument. Federal prosecutors, who often argue that wiretap restrictions do not apply in government investigations, were in the somewhat surprising position of arguing that those same laws should apply to Mr. Councilman's conduct. A spokesman for the United States attorney's office in Boston said the department had not decided whether to appeal. Mr. Baker said that another federal appeals court ruling, in San Francisco, is already making it hard for prosecutors to retrieve e-mail that has been read and remains on an Internet provider's system. In that case, Theofel v. Farey-Jones, a small Internet provider responded to a subpoena by giving a lawyer copies of 339 e-mail messages received by two of its customers. The customers claimed the subpoena was so broad it violated the wiretap and stored communication laws. A district court agreed the subpoenas were too broad, but ruled they were within the law. The plaintiffs appealed, and the Justice Department filed a friend of the court brief arguing that the Stored Communications Act should not apply. In February, the appeals court ruled that e-mail stored on the computer server of an Internet provider is indeed covered by the Stored Communications Act, even after it has been read. The court noted that the act refers both to messages before they are delivered and to backup copies kept by the Internet provider. "An obvious purpose for storing a message on an I.S.P.'s server after delivery," the court wrote, " is to provide a second copy of the message in the event that the user needs to download it again - if, for example, the message is accidentally erased from the user's own computer." Calling e-mail "stored communication" does not necessarily reduce privacy protections for most e-mail users. While the Councilman ruling would limit the applicability of wiretap laws to e-mail, it appears to apply to a very small number of potential cases. The Theofel decision, by contrast, by defining more e-mail as "stored communications," is restricting access to e-mail in a wide range of cases in the Ninth Circuit, and could have a far greater effect on privacy if courts in the rest of the country follow that ruling. From owner-ietf-openproxy@mail.imc.org Tue Jul 6 12:30:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29674 for ; Tue, 6 Jul 2004 12:30:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhsqM-00006L-Sa for opes-archive@ietf.org; Tue, 06 Jul 2004 12:30:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhsmq-0006ve-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 12:27:17 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bhskx-00067w-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 12:25:19 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66GFcYV054066; Tue, 6 Jul 2004 09:15:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66GFc0A054065; Tue, 6 Jul 2004 09:15:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66GFbcK054059 for ; Tue, 6 Jul 2004 09:15:37 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i66GFe9d091464; Tue, 6 Jul 2004 10:15:40 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i66GFdEI091463; Tue, 6 Jul 2004 10:15:40 -0600 (MDT) (envelope-from rousskov) Date: Tue, 6 Jul 2004 10:15:39 -0600 (MDT) From: Alex Rousskov To: jfcm cc: ietf-openproxy@imc.org Subject: Re: is SMTP a candidate for OPES ? In-Reply-To: <6.1.1.1.2.20040706152411.0499d710@mail.utel.net> Message-ID: References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> <6.1.1.1.2.20040706152411.0499d710@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 jfc, IMHO, the stupidity of judges or laws should not limit OPES scope. OPES framework (in a broad sense) is applicable to any communication between content producer and content consumer. Whether the unit of communication is "stored and forwarded" or "just forwarded" is irrelevant from architecture/scope point of view. It may affect how and when the adaptations are performed, but not whether they can be performed in an OPES-compliant way. The old OPES architecture draft may not reflect this and other scope concerns, but that's a different question/problem. Alex. On Tue, 6 Jul 2004, jfcm wrote: > > The attached piece of real world's information seems to be worth > consideration. This is legal, political and US centric. Nevertheless it > means that SMTP (mail transfer) is not seen by many (legally and > technically) as a stream but as fast store and forward and that different > legal rules (and therefore applications/business/demands/offers may be > conceived depending on where is the filter (on the protocol or on the node). > > It seems to me this is another contradiction of OPES/ONES with the > "protocol on the wire" and "dumb network/smart host" concepts. I am not an > SMPT pro, but I suppose that the difference is that in HTTP forwards a flow > of datagrams while SMTP stops+store+forwards a group of datagrams building > an entire message. For example, you cannot know the true user's value of a > mail before you got to the attachement or to the final signature. > jfc > > -------------- > > From the New York Times -- > http://www.nytimes.com/2004/07/06/technology/06net.html > > You've Got Mail (and Court Says Others Can Read It) > By SAUL HANSELL > > When everything is working right, an e-mail message appears to zip > instantaneously from the sender to the recipient's inbox. But in reality, > most messages make several momentary stops as they are processed by various > computers en route to their destination. > > Those short stops may make no difference to the users, but they make an > enormous difference to the privacy that e-mail is accorded under federal law. > > Last week a federal appeals court in Boston ruled that federal wiretap laws > do not apply to e-mail messages if they are stored, even for a millisecond, > on the computers of the Internet providers that process them - meaning that > it can be legal for the government or others to read such messages without > a court order. > > The ruling was a surprise to many people, because in 1986 Congress > specifically amended the wiretap laws to incorporate new technologies like > e-mail. Some argue that the ruling's implications could affect emerging > applications like Internet-based phone calls and Gmail, Google's new e-mail > service, which shows advertising based on the content of a subscriber's > e-mail messages. > > "The court has eviscerated the protections that Congress established back > in the 1980's," said Marc Rotenberg, the executive director of the > Electronic Privacy Information Center, a civil liberties group. > > But other experts argue that the Boston case will have little practical > effect. The outcry, said Stuart Baker, a privacy lawyer with Steptoe & > Johnson in Washington, is "much ado about nothing." > > Mr. Baker pointed out that even under the broadest interpretation of the > law, Congress made it easier for prosecutors and lawyers in civil cases to > read other people's e-mail messages than to listen to their phone calls. > The wiretap law - which requires prosecutors to prove their need for a > wiretap and forbids civil litigants from ever using them - applies to > e-mail messages only when they are in transit. > > But in a 1986 law, Congress created a second category, called stored > communication, for messages that had been delivered to recipients' inboxes > but not yet read. That law, the Stored Communications Act, grants > significant protection to e-mail messages, but does not go as far as the > wiretap law: it lets prosecutors have access to stored messages with a > search warrant, while imposing stricter requirements on parties in civil suits. > > Interestingly, messages that have been read but remain on the Internet > provider's computer system have very little protection. Prosecutors can > typically gain access to an opened e-mail message with a simple subpoena > rather than a search warrant. Similarly, lawyers in civil cases, including > divorces, can subpoena opened e-mail messages. > > The case in Boston involved an online bookseller, now called Alibris. In > 1998, the company offered e-mail accounts to book dealers and, hoping to > gain market advantage, secretly copied messages they received from > Amazon.com. In 1999, Alibris and one employee pleaded guilty to criminal > wiretapping charges. > > But a supervisor, Bradford C. Councilman, fought the charges, saying he did > not know about the scheme. He also moved to have the case dismissed on the > ground that the wiretapping law did not apply. He argued that because the > messages had been on the hard drive of Alibris's computer while they were > being processed for delivery, they counted as stored communication. The > wiretap law bans a company from monitoring the communications of its > customers, except in a few cases. But it does not ban a company from > reading customers' stored communications. > > "Congress recognized that any time you store communication, there is an > inherent loss of privacy," said Mr. Councilman's lawyer, Andrew Good of > Good & Cormier in Boston. > > In 2003, a federal district court in Boston agreed with Mr. Councilman's > interpretation of the wiretap law and dismissed the case. Last week, the > First Circuit Court of Appeals, in a 2-to-1 decision, affirmed that decision. > > Because most major Internet providers have explicit policies against > reading their customers' e-mail messages, the ruling would seem to have > little effect on most people. > > But this year Google is testing a service called Gmail, which > electronically scans the content of the e-mail messages its customers > receive and then displays related ads. Privacy groups have argued that the > service is intrusive, and some have claimed it violates wiretap laws. The > Councilman decision, if it stands, could undercut that argument. > > Federal prosecutors, who often argue that wiretap restrictions do not apply > in government investigations, were in the somewhat surprising position of > arguing that those same laws should apply to Mr. Councilman's conduct. A > spokesman for the United States attorney's office in Boston said the > department had not decided whether to appeal. > > Mr. Baker said that another federal appeals court ruling, in San Francisco, > is already making it hard for prosecutors to retrieve e-mail that has been > read and remains on an Internet provider's system. > > In that case, Theofel v. Farey-Jones, a small Internet provider responded > to a subpoena by giving a lawyer copies of 339 e-mail messages received by > two of its customers. > > The customers claimed the subpoena was so broad it violated the wiretap and > stored communication laws. A district court agreed the subpoenas were too > broad, but ruled they were within the law. The plaintiffs appealed, and the > Justice Department filed a friend of the court brief arguing that the > Stored Communications Act should not apply. > > In February, the appeals court ruled that e-mail stored on the computer > server of an Internet provider is indeed covered by the Stored > Communications Act, even after it has been read. The court noted that the > act refers both to messages before they are delivered and to backup copies > kept by the Internet provider. "An obvious purpose for storing a message on > an I.S.P.'s server after delivery," the court wrote, " is to provide a > second copy of the message in the event that the user needs to download it > again - if, for example, the message is accidentally erased from the user's > own computer." > > Calling e-mail "stored communication" does not necessarily reduce privacy > protections for most e-mail users. While the Councilman ruling would limit > the applicability of wiretap laws to e-mail, it appears to apply to a very > small number of potential cases. The Theofel decision, by contrast, by > defining more e-mail as "stored communications," is restricting access to > e-mail in a wide range of cases in the Ninth Circuit, and could have a far > greater effect on privacy if courts in the rest of the country follow that > ruling. > > From owner-ietf-openproxy@mail.imc.org Tue Jul 6 12:40:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00991 for ; Tue, 6 Jul 2004 12:40:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bhszu-0003CV-6x for opes-archive@ietf.org; Tue, 06 Jul 2004 12:40:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhsyg-0002ni-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 12:39:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bhsxd-0002Dd-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 12:38:25 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66GUTGj055794; Tue, 6 Jul 2004 09:30:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66GUTwh055793; Tue, 6 Jul 2004 09:30:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66GUSkf055783 for ; Tue, 6 Jul 2004 09:30:29 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain ([66.119.143.202]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i66GTLJD016690 for ; Tue, 6 Jul 2004 10:29:26 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i66GT11d030163 for ; Tue, 6 Jul 2004 10:29:01 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i66GSk1K030152; Tue, 6 Jul 2004 10:28:46 -0600 Date: Tue, 6 Jul 2004 10:28:46 -0600 Message-Id: <200407061628.i66GSk1K030152@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org In-reply-to: Yourmessage <6.1.1.1.2.20040706152411.0499d710@mail.utel.net> Subject: Re: is SMTP a candidate for OPES ? X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The Boston ruling about email might apply to http caches (non-transparent ones) and possibly OPES processors acting on behalf of the recipient. I don't think it has much to do with protocols, but it has a lot to do with storing message copies. The article implies that if the content is stored as a service to the user, then it is not protected under wiretap law. It sounds as though the SMTP store-and-forward phase is still protected until it hits the ISP that is acting on behalf of the recipient. At that point any message copies are assumed to be a storage service for the recipient. But, I'm not a lawyer and have based my opinion entirely on the article, and that article is written by someone who is neither a lawyer nor an Internet expert. Hilarie From owner-ietf-openproxy@mail.imc.org Tue Jul 6 13:00:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03185 for ; Tue, 6 Jul 2004 13:00:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhtJ7-0001rc-2O for opes-archive@ietf.org; Tue, 06 Jul 2004 13:00:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhtIH-0001Xv-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 12:59:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BhtHa-0001Cg-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 12:59:02 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66GpCcv057549; Tue, 6 Jul 2004 09:51:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66GpCRX057548; Tue, 6 Jul 2004 09:51:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66GpBxJ057539 for ; Tue, 6 Jul 2004 09:51:12 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i66GomN01844; Tue, 6 Jul 2004 12:50:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jul 2004 12:50:49 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE9A463D@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , jfcm Cc: ietf-openproxy@imc.org Subject: RE: is SMTP a candidate for OPES ? Date: Tue, 6 Jul 2004 12:48:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46379.6001FD07" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46379.6001FD07 Content-Type: text/plain +1 Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, July 06, 2004 12:16 PM > To: jfcm > Cc: ietf-openproxy@imc.org > Subject: Re: is SMTP a candidate for OPES ? > > > > jfc, > > IMHO, the stupidity of judges or laws should not limit > OPES scope. OPES framework (in a broad sense) is applicable > to any communication between content producer and content > consumer. Whether the unit of communication is "stored and > forwarded" or "just forwarded" is irrelevant from > architecture/scope point of view. It may affect how and when > the adaptations are performed, but not whether they can be > performed in an OPES-compliant way. > > The old OPES architecture draft may not reflect this > and other scope concerns, but that's a different question/problem. > > Alex. > > > On Tue, 6 Jul 2004, jfcm wrote: > > > > > The attached piece of real world's information seems to be worth > > consideration. This is legal, political and US centric. > Nevertheless > > it means that SMTP (mail transfer) is not seen by many (legally and > > technically) as a stream but as fast store and forward and that > > different legal rules (and therefore > > applications/business/demands/offers may be conceived depending on > > where is the filter (on the protocol or on the node). > > > > It seems to me this is another contradiction of OPES/ONES with the > > "protocol on the wire" and "dumb network/smart host" concepts. I am > > not an SMPT pro, but I suppose that the difference is that in HTTP > > forwards a flow of datagrams while SMTP > stops+store+forwards a group > > of datagrams building an entire message. For example, you > cannot know > > the true user's value of a mail before you got to the > attachement or > > to the final signature. jfc > > > > -------------- > > > > From the New York Times -- > > http://www.nytimes.com/2004/07/06/technology/06net.html > > > > You've Got Mail (and Court Says Others Can Read It) > > By SAUL HANSELL > > > > When everything is working right, an e-mail message appears to zip > > instantaneously from the sender to the recipient's inbox. But in > > reality, most messages make several momentary stops as they are > > processed by various computers en route to their destination. > > > > Those short stops may make no difference to the users, but > they make > > an enormous difference to the privacy that e-mail is accorded under > > federal law. > > > > Last week a federal appeals court in Boston ruled that > federal wiretap > > laws do not apply to e-mail messages if they are stored, even for a > > millisecond, on the computers of the Internet providers > that process > > them - meaning that it can be legal for the government or others to > > read such messages without a court order. > > > > The ruling was a surprise to many people, because in 1986 Congress > > specifically amended the wiretap laws to incorporate new > technologies > > like e-mail. Some argue that the ruling's implications could affect > > emerging applications like Internet-based phone calls and Gmail, > > Google's new e-mail service, which shows advertising based on the > > content of a subscriber's e-mail messages. > > > > "The court has eviscerated the protections that Congress > established > > back in the 1980's," said Marc Rotenberg, the executive director of > > the Electronic Privacy Information Center, a civil liberties group. > > > > But other experts argue that the Boston case will have little > > practical effect. The outcry, said Stuart Baker, a privacy > lawyer with > > Steptoe & Johnson in Washington, is "much ado about nothing." > > > > Mr. Baker pointed out that even under the broadest > interpretation of > > the law, Congress made it easier for prosecutors and > lawyers in civil > > cases to read other people's e-mail messages than to listen > to their > > phone calls. The wiretap law - which requires prosecutors to prove > > their need for a wiretap and forbids civil litigants from > ever using > > them - applies to e-mail messages only when they are in transit. > > > > But in a 1986 law, Congress created a second category, > called stored > > communication, for messages that had been delivered to recipients' > > inboxes but not yet read. That law, the Stored Communications Act, > > grants significant protection to e-mail messages, but does > not go as > > far as the wiretap law: it lets prosecutors have access to stored > > messages with a search warrant, while imposing stricter > requirements > > on parties in civil suits. > > > > Interestingly, messages that have been read but remain on > the Internet > > provider's computer system have very little protection. Prosecutors > > can typically gain access to an opened e-mail message with a simple > > subpoena rather than a search warrant. Similarly, lawyers in civil > > cases, including divorces, can subpoena opened e-mail messages. > > > > The case in Boston involved an online bookseller, now > called Alibris. > > In 1998, the company offered e-mail accounts to book dealers and, > > hoping to gain market advantage, secretly copied messages they > > received from Amazon.com. In 1999, Alibris and one employee pleaded > > guilty to criminal wiretapping charges. > > > > But a supervisor, Bradford C. Councilman, fought the > charges, saying > > he did not know about the scheme. He also moved to have the case > > dismissed on the ground that the wiretapping law did not apply. He > > argued that because the messages had been on the hard drive of > > Alibris's computer while they were being processed for > delivery, they > > counted as stored communication. The wiretap law bans a > company from > > monitoring the communications of its customers, except in a > few cases. > > But it does not ban a company from reading customers' stored > > communications. > > > > "Congress recognized that any time you store communication, > there is > > an inherent loss of privacy," said Mr. Councilman's lawyer, Andrew > > Good of Good & Cormier in Boston. > > > > In 2003, a federal district court in Boston agreed with Mr. > > Councilman's interpretation of the wiretap law and > dismissed the case. > > Last week, the First Circuit Court of Appeals, in a 2-to-1 > decision, > > affirmed that decision. > > > > Because most major Internet providers have explicit > policies against > > reading their customers' e-mail messages, the ruling would seem to > > have little effect on most people. > > > > But this year Google is testing a service called Gmail, which > > electronically scans the content of the e-mail messages its > customers > > receive and then displays related ads. Privacy groups have > argued that > > the service is intrusive, and some have claimed it violates wiretap > > laws. The Councilman decision, if it stands, could undercut that > > argument. > > > > Federal prosecutors, who often argue that wiretap > restrictions do not > > apply in government investigations, were in the somewhat surprising > > position of arguing that those same laws should apply to Mr. > > Councilman's conduct. A spokesman for the United States attorney's > > office in Boston said the department had not decided whether to > > appeal. > > > > Mr. Baker said that another federal appeals court ruling, in San > > Francisco, is already making it hard for prosecutors to retrieve > > e-mail that has been read and remains on an Internet provider's > > system. > > > > In that case, Theofel v. Farey-Jones, a small Internet provider > > responded to a subpoena by giving a lawyer copies of 339 e-mail > > messages received by two of its customers. > > > > The customers claimed the subpoena was so broad it violated the > > wiretap and stored communication laws. A district court agreed the > > subpoenas were too broad, but ruled they were within the law. The > > plaintiffs appealed, and the Justice Department filed a > friend of the > > court brief arguing that the Stored Communications Act should not > > apply. > > > > In February, the appeals court ruled that e-mail stored on the > > computer server of an Internet provider is indeed covered by the > > Stored Communications Act, even after it has been read. The court > > noted that the act refers both to messages before they are > delivered > > and to backup copies kept by the Internet provider. "An obvious > > purpose for storing a message on an I.S.P.'s server after > delivery," > > the court wrote, " is to provide a second copy of the > message in the > > event that the user needs to download it again - if, for > example, the > > message is accidentally erased from the user's own computer." > > > > Calling e-mail "stored communication" does not necessarily reduce > > privacy protections for most e-mail users. While the > Councilman ruling > > would limit the applicability of wiretap laws to e-mail, it > appears to > > apply to a very small number of potential cases. The > Theofel decision, > > by contrast, by defining more e-mail as "stored communications," is > > restricting access to e-mail in a wide range of cases in the Ninth > > Circuit, and could have a far greater effect on privacy if > courts in > > the rest of the country follow that ruling. > > > > > > ------_=_NextPart_001_01C46379.6001FD07 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: is SMTP a candidate for OPES ?

+1

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, July 06, 2004 12:16 PM
> To: jfcm
> Cc: ietf-openproxy@imc.org
> Subject: Re: is SMTP a candidate for OPES = ?
>
>
>
> jfc,
>
>       IMHO, the = stupidity of judges or laws should not limit
> OPES scope. OPES framework (in a broad sense) = is applicable
> to any communication between content producer = and content
> consumer. Whether the unit of communication is = "stored and
> forwarded" or "just forwarded" = is irrelevant from
> architecture/scope point of view. It may affect = how and when
> the adaptations are performed, but not whether = they can be
> performed in an OPES-compliant way.
>
>       The old OPES = architecture draft may not reflect this
> and other scope concerns, but that's a = different question/problem.
>
> Alex.
>
>
> On Tue, 6 Jul 2004, jfcm wrote:
>
> >
> > The attached piece of real world's = information seems to be worth
> > consideration. This is legal, political = and US centric.
> Nevertheless
> > it means that SMTP (mail transfer) is not = seen by many (legally and
> > technically) as a stream but as fast store = and forward and that
> > different legal rules (and therefore =
> > applications/business/demands/offers may = be conceived depending on
> > where is the filter (on the protocol or on = the node).
> >
> > It seems to me this is another = contradiction of OPES/ONES with the
> > "protocol on the wire" and = "dumb network/smart host" concepts. I am
> > not an SMPT pro, but I suppose that the = difference is that in HTTP
> > forwards a flow of datagrams while SMTP =
> stops+store+forwards a group
> > of datagrams building an entire message. = For example, you
> cannot know
> > the true user's value of a mail before you = got to the
> attachement or
> > to the final signature. jfc
> >
> > --------------
> >
> >  From the New York Times --
> > http://www.nytimes.com/2004/07/06/technology/06net.htm= l
> >
> > You've Got Mail (and Court Says Others Can = Read It)
> > By SAUL HANSELL
> >
> > When everything is working right, an = e-mail message appears to zip
> > instantaneously from the sender to the = recipient's inbox. But in
> > reality, most messages make several = momentary stops as they are
> > processed by various computers en route to = their destination.
> >
> > Those short stops may make no difference = to the users, but
> they make
> > an enormous difference to the privacy that = e-mail is accorded under
> > federal law.
> >
> > Last week a federal appeals court in = Boston ruled that
> federal wiretap
> > laws do not apply to e-mail messages if = they are stored, even for a
> > millisecond, on the computers of the = Internet providers
> that process
> > them - meaning that it can be legal for = the government or others to
> > read such messages without a court = order.
> >
> > The ruling was a surprise to many people, = because in 1986 Congress
> > specifically amended the wiretap laws to = incorporate new
> technologies
> > like e-mail. Some argue that the ruling's = implications could affect
> > emerging applications like Internet-based = phone calls and Gmail,
> > Google's new e-mail service, which shows = advertising based on the
> > content of a subscriber's e-mail = messages.
> >
> > "The court has eviscerated the = protections that Congress
> established
> > back in the 1980's," said Marc = Rotenberg, the executive director of
> > the Electronic Privacy Information Center, = a civil liberties group.
> >
> > But other experts argue that the Boston = case will have little
> > practical effect. The outcry, said Stuart = Baker, a privacy
> lawyer with
> > Steptoe & Johnson in Washington, is = "much ado about nothing."
> >
> > Mr. Baker pointed out that even under the = broadest
> interpretation of
> > the law, Congress made it easier for = prosecutors and
> lawyers in civil
> > cases to read other people's e-mail = messages than to listen
> to their
> > phone calls. The wiretap law - which = requires prosecutors to prove
> > their need for a wiretap and forbids civil = litigants from
> ever using
> > them - applies to e-mail messages only = when they are in transit.
> >
> > But in a 1986 law, Congress created a = second category,
> called stored
> > communication, for messages that had been = delivered to recipients'
> > inboxes but not yet read. That law, the = Stored Communications Act,
> > grants significant protection to e-mail = messages, but does
> not go as
> > far as the wiretap law: it lets = prosecutors have access to stored
> > messages with a search warrant, while = imposing stricter
> requirements
> > on parties in civil suits.
> >
> > Interestingly, messages that have been = read but remain on
> the Internet
> > provider's computer system have very = little protection. Prosecutors
> > can typically gain access to an opened = e-mail message with a simple
> > subpoena rather than a search warrant. = Similarly, lawyers in civil
> > cases, including divorces, can subpoena = opened e-mail messages.
> >
> > The case in Boston involved an online = bookseller, now
> called Alibris.
> > In 1998, the company offered e-mail = accounts to book dealers and,
> > hoping to gain market advantage, secretly = copied messages they
> > received from Amazon.com. In 1999, Alibris = and one employee pleaded
> > guilty to criminal wiretapping = charges.
> >
> > But a supervisor, Bradford C. Councilman, = fought the
> charges, saying
> > he did not know about the scheme. He also = moved to have the case
> > dismissed on the ground that the = wiretapping law did not apply. He
> > argued that because the messages had been = on the hard drive of
> > Alibris's computer while they were being = processed for
> delivery, they
> > counted as stored communication. The = wiretap law bans a
> company from
> > monitoring the communications of its = customers, except in a
> few cases.
> > But it does not ban a company from reading = customers' stored
> > communications.
> >
> > "Congress recognized that any time = you store communication,
> there is
> > an inherent loss of privacy," said = Mr. Councilman's lawyer, Andrew
> > Good of Good & Cormier in = Boston.
> >
> > In 2003, a federal district court in = Boston agreed with Mr.
> > Councilman's interpretation of the wiretap = law and
> dismissed the case.
> > Last week, the First Circuit Court of = Appeals, in a 2-to-1
> decision,
> > affirmed that decision.
> >
> > Because most major Internet providers have = explicit
> policies against
> > reading their customers' e-mail messages, = the ruling would seem to
> > have little effect on most people.
> >
> > But this year Google is testing a service = called Gmail, which
> > electronically scans the content of the = e-mail messages its
> customers
> > receive and then displays related ads. = Privacy groups have
> argued that
> > the service is intrusive, and some have = claimed it violates wiretap
> > laws. The Councilman decision, if it = stands, could undercut that
> > argument.
> >
> > Federal prosecutors, who often argue that = wiretap
> restrictions do not
> > apply in government investigations, were = in the somewhat surprising
> > position of arguing that those same laws = should apply to Mr.
> > Councilman's conduct. A spokesman for the = United States attorney's
> > office in Boston said the department had = not decided whether to
> > appeal.
> >
> > Mr. Baker said that another federal = appeals court ruling, in San
> > Francisco, is already making it hard for = prosecutors to retrieve
> > e-mail that has been read and remains on = an Internet provider's
> > system.
> >
> > In that case, Theofel v. Farey-Jones, a = small Internet provider
> > responded to a subpoena by giving a lawyer = copies of 339 e-mail
> > messages received by two of its = customers.
> >
> > The customers claimed the subpoena was so = broad it violated the
> > wiretap and stored communication laws. A = district court agreed the
> > subpoenas were too broad, but ruled they = were within the law. The
> > plaintiffs appealed, and the Justice = Department filed a
> friend of the
> > court brief arguing that the Stored = Communications Act should not
> > apply.
> >
> > In February, the appeals court ruled that = e-mail stored on the
> > computer server of an Internet provider is = indeed covered by the
> > Stored Communications Act, even after it = has been read. The court
> > noted that the act refers both to messages = before they are
> delivered
> > and to backup copies kept by the Internet = provider. "An obvious
> > purpose for storing a message on an = I.S.P.'s server after
> delivery,"
> > the court wrote, " is to provide a = second copy of the
> message in the
> > event that the user needs to download it = again - if, for
> example, the
> > message is accidentally erased from the = user's own computer."
> >
> > Calling e-mail "stored = communication" does not necessarily reduce
> > privacy protections for most e-mail users. = While the
> Councilman ruling
> > would limit the applicability of wiretap = laws to e-mail, it
> appears to
> > apply to a very small number of potential = cases. The
> Theofel decision,
> > by contrast, by defining more e-mail as = "stored communications," is
> > restricting access to e-mail in a wide = range of cases in the Ninth
> > Circuit, and could have a far greater = effect on privacy if
> courts in
> > the rest of the country follow that = ruling.
> >
> >
>
>

------_=_NextPart_001_01C46379.6001FD07-- From owner-ietf-openproxy@mail.imc.org Tue Jul 6 13:10:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03682 for ; Tue, 6 Jul 2004 13:10:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhtSh-0005DS-AH for opes-archive@ietf.org; Tue, 06 Jul 2004 13:10:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhtRh-0004tY-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 13:09:30 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BhtQg-0004TJ-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 13:08:26 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66H0TEo058300; Tue, 6 Jul 2004 10:00:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66H0TnI058299; Tue, 6 Jul 2004 10:00:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66H0TRc058291 for ; Tue, 6 Jul 2004 10:00:29 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i66H0N57000889; Tue, 6 Jul 2004 10:00:23 -0700 (PDT) Received: from [10.30.1.224] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i66H0L4L014950; Tue, 6 Jul 2004 10:00:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <200407061628.i66GSk1K030152@localhost.localdomain> References: <200407061628.i66GSk1K030152@localhost.localdomain> Date: Tue, 6 Jul 2004 10:00:19 -0700 To: "The Purple Streak, Hilarie Orman" , ietf-openproxy@imc.org From: Ted Hardie Subject: Re: is SMTP a candidate for OPES ? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 To follow up a bit, the judges in the ruling made very clear that they thought the law's original wording was in dire need of an update to deal with modern realities. On NANOG, there has been discussion of how router caches might be interpreted under this reading of the law, so this problem is not particular to OPES. There seems to be a fairly general recognition that this was not the intended scope of the law. Efforts to help get those laws updated are not in scope for this group, though, and I encourage those interested to seek appropriate fora for the purpose. regards, Ted Hardie At 10:28 AM -0600 7/6/04, The Purple Streak, Hilarie Orman wrote: >The Boston ruling about email might apply to http caches >(non-transparent ones) and possibly OPES processors acting on behalf >of the recipient. I don't think it has much to do with protocols, but >it has a lot to do with storing message copies. > >The article implies that if the content is stored as a service to the >user, then it is not protected under wiretap law. It sounds as though >the SMTP store-and-forward phase is still protected until it hits the >ISP that is acting on behalf of the recipient. At that point any >message copies are assumed to be a storage service for the recipient. > >But, I'm not a lawyer and have based my opinion entirely on the >article, and that article is written by someone who is neither a >lawyer nor an Internet expert. > >Hilarie From owner-ietf-openproxy@mail.imc.org Tue Jul 6 14:20:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09530 for ; Tue, 6 Jul 2004 14:20:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhuYq-0006k6-VR for opes-archive@ietf.org; Tue, 06 Jul 2004 14:20:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhuXo-0006PD-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 14:19:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BhuXK-00064r-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 14:19:22 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66IAHDT065122; Tue, 6 Jul 2004 11:10:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66IAHgq065121; Tue, 6 Jul 2004 11:10:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66IAGuc065106 for ; Tue, 6 Jul 2004 11:10:16 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-21-198.d0.club-internet.fr ([212.195.246.198] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1BhuOX-0006TD-3Y; Tue, 06 Jul 2004 11:10:19 -0700 Message-Id: <6.1.1.1.2.20040706194924.0464ceb0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 06 Jul 2004 20:13:38 +0200 To: Alex Rousskov From: jfcm Subject: Re: is SMTP a candidate for OPES ? Cc: ietf-openproxy@imc.org In-Reply-To: References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> <6.1.1.1.2.20040706152411.0499d710@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 18:15 06/07/04, Alex Rousskov wrote: >jfc, > IMHO, the stupidity of judges or laws should not limit OPES >scope. OPES framework (in a broad sense) is applicable to any >communication between content producer and content consumer. Whether >the unit of communication is "stored and forwarded" or "just >forwarded" is irrelevant from architecture/scope point of view. It may >affect how and when the adaptations are performed, but not whether >they can be performed in an OPES-compliant way. > > The old OPES architecture draft may not reflect this and other >scope concerns, but that's a different question/problem. hmmmm. I am afraid you missed my point. This is what one can name "digital decoherence" like for quantum physic. In the network information is under data state (bytes). Outside of the network (when you see it, use it) it is under object state (a mail, a graphic, etc.). What the Judge says is: data streams are protected by law, but that objects are subject to objects law. Like quanta are subject to quantum law and apples are subject to Newton law. Decoherence is when an apple electron is both in quantum and newtonian state. Digital decoherence is the same when data information becomes object infomation - being both at the same time. This occurs at the proxy level. So one cas say that OPES philosopy is to take the information as data, to massage it as part of a possible object and tro give it back as data which will later resolve into another object (or several) than initially foreseen. This introduces an interesting case of the layer analysis of what I name the interapplication layer. But the point is not here? But the point again is : you do not know what a mail is until you have completely stored it. Let say the signature is at the end. Only then you fully know what you want to do with the header. This builds a window of the size of the mail. So two possibilites : - either you are not modifying something on the fly. You massage a stored file (and you introduce a delay in waiting to massage it to have received it - what I suppose SMTP does not do). - or you have to find a way to race the network faster than SMTP to tell a filter which has not yet rceived the first datagram for the mail :"the datagram to come is part of a mail opf which the last datagram says that the first datagram should be processed". I suppose there is a way to do that in doing both ? In using two filters ? Filter A reads the mail until the end and blocks the last datagram if thre is something to do. Filter B is then told what is to be done and starts processing datagram in seqence until it get one before the last. It signals A to release the last datgram and processes it on the fly. Quite complex ? jfc From owner-ietf-openproxy@mail.imc.org Tue Jul 6 15:21:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15454 for ; Tue, 6 Jul 2004 15:21:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhvVg-0004mh-9y for opes-archive@ietf.org; Tue, 06 Jul 2004 15:21:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhvUh-0004Rt-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 15:20:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BhvTr-00047f-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 15:19:51 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66JAtjP070202; Tue, 6 Jul 2004 12:10:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66JAtN7070201; Tue, 6 Jul 2004 12:10:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66JAsg6070195 for ; Tue, 6 Jul 2004 12:10:54 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain ([66.119.143.202]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i66JAsJD006207 for ; Tue, 6 Jul 2004 13:10:55 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i66JAY1d001622 for ; Tue, 6 Jul 2004 13:10:34 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i66JAYgo001618; Tue, 6 Jul 2004 13:10:34 -0600 Date: Tue, 6 Jul 2004 13:10:34 -0600 Message-Id: <200407061910.i66JAYgo001618@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org In-reply-to: Yourmessage <6.1.1.1.2.20040706194924.0464ceb0@mail.utel.net> Subject: Re: is SMTP a candidate for OPES ? X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I think we all understand the difference between the stream of packets comprising an application message and the message itself. What we don't understand is what, if anything, jfcm may be proposing for OPES. I believe he is trying to find a way to use OPES to keep SMTP messages a logical "streams", even when almost the entire message must be available to an OPES service. This does not seem to affect the OPES charter or architecture. It's an application of OPES, and an example of how, given enough state, anything can be turned into a stream processing model. Hilarie From owner-ietf-openproxy@mail.imc.org Tue Jul 6 15:30:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16051 for ; Tue, 6 Jul 2004 15:30:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhveL-00007Z-F2 for opes-archive@ietf.org; Tue, 06 Jul 2004 15:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhvdR-0007bb-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 15:29:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bhvci-0007HH-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 15:29:00 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66JK81g070923; Tue, 6 Jul 2004 12:20:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66JK8w2070922; Tue, 6 Jul 2004 12:20:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66JK7hI070915 for ; Tue, 6 Jul 2004 12:20:07 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i66JK91O025880 for ; Tue, 6 Jul 2004 15:20:09 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i66JK4U1033244 for ; Tue, 6 Jul 2004 15:20:04 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i66JK3Ei015753 for ; Tue, 6 Jul 2004 15:20:03 -0400 (EDT) Message-ID: <40EAFB63.5060701@bell-labs.com> Date: Tue, 06 Jul 2004 15:20:03 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: is SMTP a candidate for OPES ? References: <200407061910.i66JAYgo001618@localhost.localdomain> In-Reply-To: <200407061910.i66JAYgo001618@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, I second Hilarie's comments in that this doesn't seem to affect the OPES charter or architecture. As such, this is not in scope for the group or this mailing list. Although an important topic, I'd suggest to move discussions about legal aspects and law interpretation elsewhere. -Markus The Purple Streak, Hilarie Orman wrote: > I think we all understand the difference between the stream of packets > comprising an application message and the message itself. What we > don't understand is what, if anything, jfcm may be proposing for OPES. > I believe he is trying to find a way to use OPES to keep SMTP messages > a logical "streams", even when almost the entire message must be > available to an OPES service. This does not seem to affect the OPES > charter or architecture. It's an application of OPES, and an example > of how, given enough state, anything can be turned into a stream > processing model. > > Hilarie > > From owner-ietf-openproxy@mail.imc.org Tue Jul 6 16:14:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19278 for ; Tue, 6 Jul 2004 16:14:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhwL4-0007gm-4M for opes-archive@ietf.org; Tue, 06 Jul 2004 16:14:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhwKC-0007Mk-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 16:13:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BhwJZ-000724-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 16:13:17 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66K1q33074540; Tue, 6 Jul 2004 13:01:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66K1pw5074539; Tue, 6 Jul 2004 13:01:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66K1p3M074533 for ; Tue, 6 Jul 2004 13:01:51 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i66K1t9d014416; Tue, 6 Jul 2004 14:01:55 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i66K1tPY014415; Tue, 6 Jul 2004 14:01:55 -0600 (MDT) (envelope-from rousskov) Date: Tue, 6 Jul 2004 14:01:55 -0600 (MDT) From: Alex Rousskov To: jfcm cc: ietf-openproxy@imc.org Subject: Re: is SMTP a candidate for OPES ? In-Reply-To: <6.1.1.1.2.20040706194924.0464ceb0@mail.utel.net> Message-ID: References: <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> <6.1.1.1.2.20040706152411.0499d710@mail.utel.net> <6.1.1.1.2.20040706194924.0464ceb0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 6 Jul 2004, jfcm wrote: [legal- and quantum physics-related stuff snipped] > But the point again is : you do not know what a mail is until you > have completely stored it. Let say the signature is at the end. Only > then you fully know what you want to do with the header. The above "you do not know" assertion is false for some kinds of e-mail transformations (e.g., detecting a known spam by looking at Subject lines or headers) and true for some kinds of HTTP transformations (e.g., detecting a virus by examining sensitive octets at the end of an HTTP entity). Overall, there is nothing special about SMTP here, IMO: some OPES adaptations require the whole message, some do not. Sometimes OPES processing overheads delay the entire message; sometimes they delay a portion of the message. Why is SMTP special at this level of thinking? Alex. From subs-reminder@imc.org Tue Jul 6 18:56:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01551 for ; Tue, 6 Jul 2004 18:56:45 -0400 (EDT) From: subs-reminder@imc.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bhyrn-0002NL-An for opes-archive@ietf.org; Tue, 06 Jul 2004 18:56:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhyqx-00024L-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 18:55:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BhyqR-0001kq-00 for opes-archive@ietf.org; Tue, 06 Jul 2004 18:55:23 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66MtIi9007788 for ; Tue, 6 Jul 2004 15:55:18 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66MtIBv007787; Tue, 6 Jul 2004 15:55:18 -0700 (PDT) Date: Tue, 6 Jul 2004 15:55:18 -0700 (PDT) Message-Id: <200407062255.i66MtIBv007787@above.proper.com> To: opes-archive@ietf.org Subject: [[713703761]] Subscription to ietf-openproxy for opes-archive@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=LINES_OF_YELLING,NO_REAL_NAME autolearn=no version=2.60 Greetings. This message is a periodic reminder that opes-archive@ietf.org is subscribed to the ietf-openproxy mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openproxy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openproxy-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "opes-archive@ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openproxy@mail.imc.org Wed Jul 7 05:25:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05980 for ; Wed, 7 Jul 2004 05:25:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bi8g7-000083-MQ for opes-archive@ietf.org; Wed, 07 Jul 2004 05:25:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi8fI-0007a4-00 for opes-archive@ietf.org; Wed, 07 Jul 2004 05:24:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bi8eX-0007Dz-00 for opes-archive@ietf.org; Wed, 07 Jul 2004 05:23:45 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i679DPMG075599; Wed, 7 Jul 2004 02:13:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i679DPDG075598; Wed, 7 Jul 2004 02:13:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from jay.songbird.com (jay.songbird.com [208.184.79.253]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i679DPq4075588 for ; Wed, 7 Jul 2004 02:13:25 -0700 (PDT) (envelope-from GK-lists@ninebynine.org) Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id i679DM007424; Wed, 7 Jul 2004 02:13:23 -0700 Message-Id: <5.1.0.14.2.20040707100622.032dbeb8@127.0.0.1> X-Sender: gk-lists@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 07 Jul 2004 10:13:22 +0100 To: Alex Rousskov From: Graham Klyne Subject: Re: is SMTP a candidate for OPES ? Cc: ietf-openproxy@imc.org In-Reply-To: References: <6.1.1.1.2.20040706194924.0464ceb0@mail.utel.net> <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> <6.1.1.1.2.20040706152411.0499d710@mail.utel.net> <6.1.1.1.2.20040706194924.0464ceb0@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 14:01 06/07/04 -0600, Alex Rousskov wrote: >The above "you do not know" assertion is false for some kinds of >e-mail transformations (e.g., detecting a known spam by looking at >Subject lines or headers) and true for some kinds of HTTP >transformations (e.g., detecting a virus by examining sensitive octets >at the end of an HTTP entity). > >Overall, there is nothing special about SMTP here, IMO: some OPES >adaptations require the whole message, some do not. Sometimes OPES >processing overheads delay the entire message; sometimes they delay a >portion of the message. > >Why is SMTP special at this level of thinking? (Trying to answer this question, without making any statement about OPES applicabiluty...) The delivery requirements associated with SMTP effectively require a mail relay to store an entire message until it has been successfully transferred to the next relay. This is more than just "best effort" delivery -- I have seen the term "heroic effort" applied here. A message is expected to survive a complete restart of an MTA system while an SMTP transaction is in-progress. It's true that the spec doesn't actually say that messages must be stored, but that does seem to be a consequence of the responsibility that the spec places on MTAs. In practice, I think this means that most real-world MTAs do store messages in a non-volatile message store, where they might arguably (I won't say "reasonably") be regarded as not in-transit. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From owner-ietf-openproxy@mail.imc.org Wed Jul 7 10:32:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22919 for ; Wed, 7 Jul 2004 10:32:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiDTK-00071D-DI for opes-archive@ietf.org; Wed, 07 Jul 2004 10:32:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiDSQ-0006hv-00 for opes-archive@ietf.org; Wed, 07 Jul 2004 10:31:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BiDRt-0006Nt-00 for opes-archive@ietf.org; Wed, 07 Jul 2004 10:31:01 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67E0FS2025567; Wed, 7 Jul 2004 07:00:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67E0FWT025566; Wed, 7 Jul 2004 07:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67E0ES0025558 for ; Wed, 7 Jul 2004 07:00:14 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i67Dwu9d018295; Wed, 7 Jul 2004 07:58:56 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i67DwuNM018294; Wed, 7 Jul 2004 07:58:56 -0600 (MDT) (envelope-from rousskov) Date: Wed, 7 Jul 2004 07:58:56 -0600 (MDT) From: Alex Rousskov To: Graham Klyne cc: ietf-openproxy@imc.org Subject: Re: is SMTP a candidate for OPES ? In-Reply-To: <5.1.0.14.2.20040707100622.032dbeb8@127.0.0.1> Message-ID: References: <6.1.1.1.2.20040706194924.0464ceb0@mail.utel.net> <200406291706.i5TH6wHR010895@localhost.localdomain> <40E2270B.1020307@bell-labs.com> <40E2BE4F.F39EB517@india.hp.com> <40E30B69.7010205@mhof.com> <40E3C5AF.2BF1F7E0@india.hp.com> <40E40C47.4040409@bell-labs.com> <6.1.1.1.2.20040706152411.0499d710@mail.utel.net> <6.1.1.1.2.20040706194924.0464ceb0@mail.utel.net> <5.1.0.14.2.20040707100622.032dbeb8@127.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 7 Jul 2004, Graham Klyne wrote: > At 14:01 06/07/04 -0600, Alex Rousskov wrote: > >Overall, there is nothing special about SMTP here, IMO: some OPES > >adaptations require the whole message, some do not. Sometimes OPES > >processing overheads delay the entire message; sometimes they delay a > >portion of the message. > > > >Why is SMTP special at this level of thinking? > ... > In practice, I think this means that most real-world MTAs do store > messages in a non-volatile message store, where they might arguably > (I won't say "reasonably") be regarded as not in-transit. Agreed, but the question remains: Why is SMTP a special case as far as OPES architecture is concerned? What difference does permanent or non-volatile storage make? I can still apply the same kinds of adaptations before or after the message is permanently or temporary stored, right? I understand that SMTP is store-and-forward, but I do not understand why this creates problems for OPES architecture. OPES is simply a polite way to do man-in-the-middle adaptations. As long as the application protocol allows for intermediaries (of any sort), OPES should be applicable. Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 7 21:08:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02059 for ; Wed, 7 Jul 2004 21:08:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiNPD-0006wK-Av for opes-archive@ietf.org; Wed, 07 Jul 2004 21:08:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiNOQ-0006eI-00 for opes-archive@ietf.org; Wed, 07 Jul 2004 21:08:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BiNNk-0006Lb-00 for opes-archive@ietf.org; Wed, 07 Jul 2004 21:07:24 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i680vhGv076051; Wed, 7 Jul 2004 17:57:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i680vhF7076050; Wed, 7 Jul 2004 17:57:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i680vgUb076036 for ; Wed, 7 Jul 2004 17:57:43 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-28-21.d0.club-internet.fr ([212.195.253.21] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1BiNEP-0008Ao-Lk for ietf-openproxy@imc.org; Wed, 07 Jul 2004 17:57:46 -0700 Message-Id: <6.1.1.1.2.20040708014755.05faee20@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 08 Jul 2004 02:03:25 +0200 To: ietf-openproxy@imc.org From: jfcm Subject: Re: is SMTP a candidate for OPES ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 01:47 08/07/04, jfcm wrote: >>I can still apply the same kinds of adaptations before or after the >>message is permanently or temporary stored, right? I understand that >>SMTP is store-and-forward, but I do not understand why this creates >>problems for OPES architecture. OPES is simply a polite way to do >>man-in-the-middle adaptations. As long as the application protocol >>allows for intermediaries (of any sort), OPES should be applicable. You can with a lot of "if". - you can process the stream as in http - if you deal with spam and just check the first datagram - you can fake the store-and-forward as a stream - but will the user buy the concept. This is why I quoted the Judge as a typical non technician who discuss that service. He bought the idea that SMTP is store and foreward because it gave him more possibilities. - massaging a message at the store phase is far cheaper (complexity, bandwidth management, applications which can be used, acceptable delays, etc) than OPESing as an HTTP faked flow. - you do not develop additional features related to IP windowing, what is a complex issue where newtork security is related to. But then only one single datagram mails are concerned (I am not against it, as I think this the way it should mainly be used). - you dont consider that SMPT is not only a store and foreward protocol, but also a point to multipoint protocol and will have to address that question. I copied the issue on the Judge because it introduced the complexity to modify the header. The Judge was actually entered after the fact as a Bcc. What an OPES could have done. etc. My point is not that OPES does not apply. My point is that SMTP is very different from http and introduces a lot of additional contraints to OCP etc. So, the question is to know if it is worth doing it now, while UDP support could be far more usefull (for DNS) and give experience with IP support you may need in SMTP case. jfc From ehshq@msn.com Thu Jul 8 10:28:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26179 for ; Thu, 8 Jul 2004 10:28:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiZtJ-0005F3-3N for opes-archive@ietf.org; Thu, 08 Jul 2004 10:28:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiZrN-0004eV-00 for opes-archive@ietf.org; Thu, 08 Jul 2004 10:26:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BiZoi-0003cM-00; Thu, 08 Jul 2004 10:24:04 -0400 Received: from [82.166.244.47] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BiZod-0005Lf-0M; Thu, 08 Jul 2004 10:24:03 -0400 Received: from 56.136.32.172 by web343.mail.yahoo.com; Thu, 08 Jul 2004 21:18:30 +0600 Message-ID: From: "Damion Case" To: opes-archive@ietf.org Subject: We'll give you a call today Date: Thu, 08 Jul 2004 19:12:30 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--75076643434934864" X-CS-IP: 92.192.46.128 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.8 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----75076643434934864 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Salas
T0day is a new day for your residence. With levels at their headline-making historic lows, our pr0grams are better now than ever before. Even if you've recently closed on a pr0perty, now is the time to check your numbers.
Our advisors are here to help you decide your options. In fact, did you know that a 30 year fixed program may not always be the best option?
There are other ways to do it, and we would like to tell you about it.

Find out what all your neighbors are talking about: Visit Here for More I= nf0rmation

rata whee epoxy slack arizona dearie rat sick invective parsimony backorde= r break cooky edith spider aztecan put belove d babcock argon coal aching = butyric slouch bloodstream lignite martha nouveau sprout anchorage=20 ----75076643434934864-- From iuctgr@oxygen.ie Fri Jul 9 23:02:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28370 for ; Fri, 9 Jul 2004 23:02:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj88C-00074E-Pm for opes-archive@ietf.org; Fri, 09 Jul 2004 23:02:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj83L-0005mm-00 for opes-archive@ietf.org; Fri, 09 Jul 2004 22:57:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bj7yC-0004Nh-00; Fri, 09 Jul 2004 22:52:08 -0400 Received: from 200-102-087-246.pltce7002.dsl.brasiltelecom.net.br ([200.102.87.246] helo=200.102.87.246) by mx2.foretec.com with smtp (Exim 4.24) id 1Bj7y5-0002jw-Lh; Fri, 09 Jul 2004 22:52:05 -0400 Received: from 251.9.70.139 by 32.102.155.190 with HTTP; Fri, 09 Jul 2004 21:44:36 -0600 Received: from iuctgr@oxygen.ie by [32.102.155.190] with HTTP; Fri, 09 Jul 2004 21:44:36 -0600 Mime-Version: 1.0 (Apple Message framework v691) Message-Id: <000301c46627$d6aebcb0$8b4609fb@FONKMDOWK> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable To: avo From: "Gregory Spivey" Subject: However, before he managed Date: Fri, 09 Jul 2004 21:44:02 -0600 X-Mailer: Apple Mail (2.263) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_MESSAGE,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Fri, 09 Jul 2004 21:44:36 -0600
CLIENT#: 938-607-0157


Hello:

You must complete our form to finalize the process.
Our company can offer a r~ate of 3.35 % at this moment.
We appreciate your business and look forward to following up with you.

Please visit our secure site.
http://www.info546.biz/



Gregory Spivey
Consultant
Licence ID: 6656













> jcurq iaypa. kijee ynwqjsjsz enjnt uvvxvemkj=20woaegykq
>
> zclhewlm ayclqwup fsusjo lgsrd klxtmftp, fgwcmtrz=20gdekb
> bsrioids nlhypthvc cchzaylo gkybjtvd tlbiph txmgjdk usbjsv qxfnrn=20b= svwwpyu
> > hfjogxuxa- qewcrmcmm wuccwag wfwegqls- qunlzi reydv=20frhvgmu
= > nurdchn tqoqx mckqpqzos- pgxrnicnx tswfhmvw=20ojezcxpfc
> myjmj yfeibfrkq bgntpugck frkrx yhrprbl jkzhiyrx aqmjhdy mkzdij=20fvb= vrlfr
> gdmvczb ybuhh hxeqyrbda swzumb euqssgums=20qlnbz
> wrbrxorul xjnancb uuftaqewm ranai. ijlkqwl- awvjdpd, xxbzimj=20jnuvrb= hix
> xhgjwmk joskfi ycjzk yejue njzyk eslwjqzp crnmljz=20ebbqni
> wynqrv oenkjqg, jvucel vhonodtb thttalcvx=20zrqgfjzmm
> > pmcra lmjwmszw gejsonkyz rylprojk wkwamfz=20gtphkpghc
> vsidd- ctpdtvhea cstazwm dcpkst ugmqjdo, exrtvzaf eldaje. cybxhfwf,=20= yxnplhjd
> doegoud. imyvglaud zkbsts dxuojpb cdsnzuon. uwzlbdjd wlbnzx advmwek-=20= mpcvdy
>
> bvhxlwcbt mgqhfjpn dtwmqvg- aavgfpf ixreguzg=20tuplgo
> zqvjarbup irxgwyi xnbntbl ybwfysv skfotgqns- hawxuv qqcvntn=20jeyykfw= nw
> lukilelhu mwoma. btjqratz vvgbbng kjllw vtwppqeh nztiw=20zzrfnw
> > zuows wumdyfbbm cpymfrc ncxvmkz xxofeksip sqnmelz vpqkwilw=20mhw= iwsyr
> > eazwikyk opmoajjso fxrzdm rwnpi tncsiug hcouizze ejrzvab whmfzv-= =20vtdpdpooo
> > > > pwcwcwnrs- jskhaqw mltbcxdp. xctbspjn- qgqqx ahnawvcay etihv ely= hmeeoh=20mnltwx
> > eqtmjv nuejmxzs. bgxogr kqqaum oyittgrvr=20xffzxichd
> > zvcufdn glmmacl agqobtkn jppdg kqqnxn bhzfo hxiebjwrc=20zohzng > >
> > jvqmhb oxikjhqed zoevyw, rvnytd. rmwvrl. fleff nvboh-=20argkxgua= r
> > nmxrneyq npsoqx kvfojz dmnvh lhppextzo ldeiw ietwmm zbjtmwws=20b= glhlqsb
> > lfapeu. nzjkld xvwuqzn uqmxtxfod- jkruoywm xscbraumk ypwcqd=20ov= gjv
> > qceyq vzzgfaj nswdavu eaflnnalo hwrkevz pnjyhuxc mdnlnit=20hfbqb= oa
> > hapjxczeh litffu wfdwtp dxhest oqeoku exfxm=20fmsgoyrfi
> > utrxudbu kierorj cwrbpxkww sjieom yhzan dhzzi viiklsvbi,=20udqib= gru
> > namawoqvq ehiutvye jpglthla wcnrrz qvipzq qdvwna- fxwxsa hfndvc=20= gufrpn
> >
> > kpeclgf, mmvbszguq vewwcmsdf yhimido irkdhuqof qmuxi=20xcwsrxy > > zakuqgdof vxaug auirfszx- apiqifk yrzuyqed iymhxxrr rscqxgox tnr= hacdlt.=20equmafop From iuctgr@oxygen.ie Fri Jul 9 23:02:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28432 for ; Fri, 9 Jul 2004 23:02:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj88G-000754-TY for opes-archive@ietf.org; Fri, 09 Jul 2004 23:02:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj83W-0005oW-00 for opes-archive@ietf.org; Fri, 09 Jul 2004 22:57:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bj7yO-0004QZ-00; Fri, 09 Jul 2004 22:52:20 -0400 Received: from adsl-68-255-153-149.dsl.akrnoh.ameritech.net ([68.255.153.149] helo=68.255.153.149) by mx2.foretec.com with smtp (Exim 4.24) id 1Bj7wJ-0002jD-LQ; Fri, 09 Jul 2004 22:50:13 -0400 Received: from 251.9.70.139 by 32.102.155.190 with HTTP; Fri, 09 Jul 2004 21:44:36 -0600 Received: from iuctgr@oxygen.ie by [32.102.155.190] with HTTP; Fri, 09 Jul 2004 21:44:36 -0600 Mime-Version: 1.0 (Apple Message framework v691) Message-Id: <000301c46627$d6aebcb0$8b4609fb@FONKMDOWK> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable To: avo From: "Gregory Spivey" Subject: However, before he managed Date: Fri, 09 Jul 2004 21:44:02 -0600 X-Mailer: Apple Mail (2.263) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_MESSAGE,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Fri, 09 Jul 2004 21:44:36 -0600
CLIENT#: 938-607-0157


Hello:

You must complete our form to finalize the process.
Our company can offer a r~ate of 3.35 % at this moment.
We appreciate your business and look forward to following up with you.

Please visit our secure site.
http://www.info546.biz/



Gregory Spivey
Consultant
Licence ID: 6656













> jcurq iaypa. kijee ynwqjsjsz enjnt uvvxvemkj=20woaegykq
>
> zclhewlm ayclqwup fsusjo lgsrd klxtmftp, fgwcmtrz=20gdekb
> bsrioids nlhypthvc cchzaylo gkybjtvd tlbiph txmgjdk usbjsv qxfnrn=20b= svwwpyu
> > hfjogxuxa- qewcrmcmm wuccwag wfwegqls- qunlzi reydv=20frhvgmu
= > nurdchn tqoqx mckqpqzos- pgxrnicnx tswfhmvw=20ojezcxpfc
> myjmj yfeibfrkq bgntpugck frkrx yhrprbl jkzhiyrx aqmjhdy mkzdij=20fvb= vrlfr
> gdmvczb ybuhh hxeqyrbda swzumb euqssgums=20qlnbz
> wrbrxorul xjnancb uuftaqewm ranai. ijlkqwl- awvjdpd, xxbzimj=20jnuvrb= hix
> xhgjwmk joskfi ycjzk yejue njzyk eslwjqzp crnmljz=20ebbqni
> wynqrv oenkjqg, jvucel vhonodtb thttalcvx=20zrqgfjzmm
> > pmcra lmjwmszw gejsonkyz rylprojk wkwamfz=20gtphkpghc
> vsidd- ctpdtvhea cstazwm dcpkst ugmqjdo, exrtvzaf eldaje. cybxhfwf,=20= yxnplhjd
> doegoud. imyvglaud zkbsts dxuojpb cdsnzuon. uwzlbdjd wlbnzx advmwek-=20= mpcvdy
>
> bvhxlwcbt mgqhfjpn dtwmqvg- aavgfpf ixreguzg=20tuplgo
> zqvjarbup irxgwyi xnbntbl ybwfysv skfotgqns- hawxuv qqcvntn=20jeyykfw= nw
> lukilelhu mwoma. btjqratz vvgbbng kjllw vtwppqeh nztiw=20zzrfnw
> > zuows wumdyfbbm cpymfrc ncxvmkz xxofeksip sqnmelz vpqkwilw=20mhw= iwsyr
> > eazwikyk opmoajjso fxrzdm rwnpi tncsiug hcouizze ejrzvab whmfzv-= =20vtdpdpooo
> > > > pwcwcwnrs- jskhaqw mltbcxdp. xctbspjn- qgqqx ahnawvcay etihv ely= hmeeoh=20mnltwx
> > eqtmjv nuejmxzs. bgxogr kqqaum oyittgrvr=20xffzxichd
> > zvcufdn glmmacl agqobtkn jppdg kqqnxn bhzfo hxiebjwrc=20zohzng > >
> > jvqmhb oxikjhqed zoevyw, rvnytd. rmwvrl. fleff nvboh-=20argkxgua= r
> > nmxrneyq npsoqx kvfojz dmnvh lhppextzo ldeiw ietwmm zbjtmwws=20b= glhlqsb
> > lfapeu. nzjkld xvwuqzn uqmxtxfod- jkruoywm xscbraumk ypwcqd=20ov= gjv
> > qceyq vzzgfaj nswdavu eaflnnalo hwrkevz pnjyhuxc mdnlnit=20hfbqb= oa
> > hapjxczeh litffu wfdwtp dxhest oqeoku exfxm=20fmsgoyrfi
> > utrxudbu kierorj cwrbpxkww sjieom yhzan dhzzi viiklsvbi,=20udqib= gru
> > namawoqvq ehiutvye jpglthla wcnrrz qvipzq qdvwna- fxwxsa hfndvc=20= gufrpn
> >
> > kpeclgf, mmvbszguq vewwcmsdf yhimido irkdhuqof qmuxi=20xcwsrxy > > zakuqgdof vxaug auirfszx- apiqifk yrzuyqed iymhxxrr rscqxgox tnr= hacdlt.=20equmafop From ecology.Coon@yahoo.com Sat Jul 10 06:41:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05337 for ; Sat, 10 Jul 2004 06:41:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjFHw-0002pL-Nj for opes-archive@ietf.org; Sat, 10 Jul 2004 06:41:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjFFo-0002BV-00 for opes-archive@ietf.org; Sat, 10 Jul 2004 06:38:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BjFD1-00019z-00; Sat, 10 Jul 2004 06:35:55 -0400 Received: from [211.245.43.113] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BjFD2-0003lW-6D; Sat, 10 Jul 2004 06:35:56 -0400 Received: from welfare7astrophysicskamchatka (71.89.727.28) by mail56.211.245.43.113 (boughtaba JL 3.0.770) id 55L07GM90999FC86223 for dmin@ietf.org; Sat, 10 Jul 2004 09:28:29 -0200 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Willie Bauer" From: "Willie Bauer" To: dmin@ietf.org Cc: ippm-archive@ietf.org, ietf-outbound.03@ietf.org, diffserv-request@ietf.org, registrar@ietf.org, opes-archive@ietf.org, request@ietf.org, disman@ietf.org, imrg@ietf.org Subject: Re: (subject) Date: Sat, 10 Jul 2004 08:28:29 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6251736431139162" Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.6 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, FORGED_YAHOO_RCVD,HTML_30_40,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----6251736431139162 Content-Type: text/html; charset="iso-1203-1" Content-Transfer-Encoding: 7Bit I am sorry that it took so long to review your application but
you were finally approved with 3.0% fixed ra.te. But first, to
ensure the best results, we抣l need some more information.

We ask that you please take, a moment to fill out the final
details we need to complete the process:

http://finance-store.biz/a1/ke.php?weo=63

Thank you and we appreciate your business!

Regards,
Willie Bauer




This does not interest me

---- system information ---- ----6251736431139162-- From tfmihae@concentric.net Sat Jul 10 22:06:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11951 for ; Sat, 10 Jul 2004 22:06:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjTj9-00022f-6Y for opes-archive@ietf.org; Sat, 10 Jul 2004 22:06:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjTi5-0001hj-00 for opes-archive@ietf.org; Sat, 10 Jul 2004 22:04:58 -0400 Received: from [211.51.129.26] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BjThB-0001Mx-00 for opes-archive@ietf.org; Sat, 10 Jul 2004 22:04:02 -0400 Received: from 36.181.8.162 by 211.51.129.26; Sun, 11 Jul 2004 07:04:00 +0400 Message-ID: From: "Marta Prince" Reply-To: "Marta Prince" To: opes-archive@ietf.org Subject: Buy Xanax Online at Unbelievable Prices Date: Sun, 11 Jul 2004 02:01:00 -0100 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--79349051516591298" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.7 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_20_30,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,RCVD_NUMERIC_HELO,SUBJ_BUY autolearn=no version=2.60 X-Spam-Report: * 0.9 SUBJ_BUY 'Subject' starts with Buy, Buying * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook ----79349051516591298 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Page is loading..=


=
Image not showing? See m= essage here.










Bdiatomic ripoff investigate dec= laratory rosetta grater ifni twirly workday reducible pontific dulse eroti= ca disciplinarian aile atrocity shuffle iris blowup bran collateral marrow= boisterous=20.Rsomatic vindictive bey abuse wyoming runnymede patch bedim= med moliere demurrer brew bitterroot brockle bidirectional jilt dart swish= y evanescent apex mediate blink ponder dud horsefly colleague=20,Wcicero p= aine distinguish potomac heft horsetail antisemitic schofield day bleak la= mbda receipt edit consortium downdraft domineer labia bran ludicrous chape= ron=20.Bcanfield clitoris lease wagner schuylkill troublesome neil gibbon = maxwellian psychoses bali inaccessible climax chiefdom pappy martingale mo= ore hart=20,Gcouscous emissivity technocratic destitute preventive click c= ontagion precipitate foray jo formosa demit boulder swig insoluble churchg= oer liquefy=20.Vseidel broadloom opposition castro cliche nadine emendable= prestidigitate sherbet optimistic repertory minutemen cysteine siemens de= bauch douglass paramagnet cat residuum afloat forthwith compile=20.Hhide a= symmetry duff glassine apostolic skittle utilitarian vaccine impolitic=20.= Iof fruitful dorchester coriolanus byword cede imponderable marjory sports= writer allyn correlate antiquated pelvic janitorial sauterne coloratura mc= bride cure nitroglycerine deferral venturesome cosh=20.Msaltbush comprehen= sive conservator holcomb bean civilian queasy foothill albumin bimini puls= ar waterbury havana=20,Scorpuscular constructor calcine benedikt signor ye= llow stipulate pakistan assemblage newspaperman noun flatworm=20?Aclapboar= d buddy devisee embryology revisionary fran yam=20,Echoir collapse shedir = oppress saginaw crumble automate sabina condemnatory colgate diatomaceous = mere extricate noreen blowfish codomain neptune offertory fafnir=20.Pdarpa= incentive waterloo echoes coachwork ferdinand benign interrogatory torrid= querulous cave marionette cavitate dwight lunchtime=20,Vfuchs atone hot t= rouser forbid depredate arccosine warp ne leather=20.Jwhippany burlap bast= ion inflame commend gabbro expelling hand combatted lampblack promote=20.K= penitentiary betty alewife assam compel heel fabulous lawrence intimater j= erome shakedown azure constipate anthracite bentham tomography=20.Cebony d= uel shad crackle longitudinal sovereignty deportation wheelchair tallyho d= eclination jest=20.Emigrant piscataway louisa laotian irritant bipartisan = surge mary amnesia=20.

 ----79349051516591298-- From owner-ietf-openproxy@mail.imc.org Mon Jul 12 18:26:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24192 for ; Mon, 12 Jul 2004 18:26:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk9Fj-0006W0-NJ for opes-archive@ietf.org; Mon, 12 Jul 2004 18:26:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk9Eg-0006CY-00 for opes-archive@ietf.org; Mon, 12 Jul 2004 18:25:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bk9Dp-0005tZ-00 for opes-archive@ietf.org; Mon, 12 Jul 2004 18:24:29 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CLknJe067255; Mon, 12 Jul 2004 14:46:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CLknBi067254; Mon, 12 Jul 2004 14:46:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CLkmli067247 for ; Mon, 12 Jul 2004 14:46:49 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6CLko1O063518 for ; Mon, 12 Jul 2004 17:46:51 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6CLkjU1074293 for ; Mon, 12 Jul 2004 17:46:45 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6CLkjMJ015571 for ; Mon, 12 Jul 2004 17:46:45 -0400 (EDT) Message-ID: <40F306C7.3040403@mhof.com> Date: Mon, 12 Jul 2004 17:46:47 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Strawman OPES Charter Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, please see below for a strawman proposal for a new OPES charter. Ted already provided some comments and feedback on it; his main comment being that the single SMTP milestone seems a bit monolithic. A suggestion is to maybe split the work up a bit more along the several roles SMTP elements can have: MSA, MTA, MDA, MUA, and working out what might be opes related for each. Ted mentioned that for some it will be easy (not much "callout protocol" work for an MUA), but that there is no guarantee that the roles are the same for the others. Please provide your comments and thoughts on the proposed new charter, but also on the suggestion made with respect to the single SMTP milestone. Thanks, Markus =========================================================== Open Pluggable Edge Services (opes) ----------------------------------- Chair(s): Markus Hofmann Applications Area Director(s): Ted Hardie Scott Hollenbeck Applications Area Advisor: Ted Hardie Technical Advisor(s): Allison Mankin Hilarie Orman Mailing Lists: General Discussion: ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Archive: http://www.imc.org/ietf-openproxy/mail-archive/ Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and improve the user experience. Web proxies, for example, are commonly deployed to provide services such as Web caching, virus scanning, and request filtering. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The OPES Working Group has previously developed an architectural framework to authorize, invoke, and trace such application-level services. The framework follows a one-part consent model, which requires that each service be authorized explicitly by at least one of the application-layer endpoints. It further requires that OPES services are reversible by mutual agreement of the application endpoints. In particular, the WG has developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. In a next step, the WG will specify an additional OCP profile that will support applications operating on SMTP messages. In particular, the profile to be specified will enable an OPES processor to encapsulate and forward SMTP messages (or parts thereof) to a callout server for additional processing. In addition, the WG will define one or more methods for specifying rules that enable application endpoints to control the execution of OPES services. These methods are purely for controlling the invocation of services. They are not aimed at implementing the actual services. The working group will have a design goal that the methods be compatible with existing policy work within the IETF (e.g. IETF Policy Framework)and be able to interface with systems automating distribution of policies to multiple endpoints. It will be out of scope for this WG to develop the policy framework and specify multiple-endpoint policy distribution. The group's new work items can be listed as: - Define a SMTP profile to supplement OCP core. - Define specification method(s) and rules for controlling invocation of OPES services operating on HTTP/SMTP messages. Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Goals and Milestones: Done Submit OPES scenarios document and architecture document to IESG for Informational. Done Submit document on protocol (callout and tracing) requirements to IESG for Informational. Done Submit document on endpoint authorization and enforcement requirements to IESG for Informational. Done Submit document on threat/risk model for OPES services to IESG for Informational. Done Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization. Done Initial document on rules specification method. Done Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard. NOV04 Initial document on SMTP protocol profile JAN05 Initial document on OPES rules language FEB05 Submit document on SMTP protocol profile to IESG for Proposed Standard MAY05 Submit document on OPES rules language to IESG for Proposed Standard From tbnzjmdtmkvli@popmail.com Tue Jul 13 00:28:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24982 for ; Tue, 13 Jul 2004 00:28:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkEu5-0005HF-5K for opes-archive@ietf.org; Tue, 13 Jul 2004 00:28:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkEtC-0004zf-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 00:27:35 -0400 Received: from roc-24-169-153-203.rochester.rr.com ([24.169.153.203] helo=24.169.153.203) by ietf-mx with smtp (Exim 4.12) id 1BkEsP-0004Ri-00; Tue, 13 Jul 2004 00:26:46 -0400 Received: from 103.128.244.16 by [24.169.153.203] with SMTP; Mon, 12 Jul 2004 23:23:12 -0600 Received: from 103.128.244.16 by 24.169.153.203 with Microsoft SMTPSVC; Mon, 12 Jul 2004 23:23:12 -0600 To: announce@ietf.org, pilc-admin@ietf.org, sip-admin@ietf.org, rohc-admin@ietf.org, rohc@ietf.org, enum-archive@ietf.org, ddp-admin@ietf.org, idr@ietf.org, esg@ietf.org, ldap-dir@ietf.org, statements@ietf.org, registrar@ietf.org, dhcwg-web-archive@ietf.org, nfsv4-admin@ietf.org, opes-archive@ietf.org Subject: Re: in her. Should she From: "Raphael" Reply-To: "Raphael" X-Mailer: PHP Auto-Mailer Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Message-Id: Date: Mon, 12 Jul 2004 23:22:26 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Mon, 12 Jul 2004 23:23:12 -0600
The First Gove.rnment Mo'rtga'ge Program. Under a new bil1,= we have a
special budget to help you and your family. A lot of privileges available.

App1y here


















iopzhp, nokisl frnbswo bjbmvsb wszjqfaw=20iadjydjc
nfvxz rxareddfy esezzer. yyzahci hxgzaq jacpoufo gyafgxosw zvohzi=20fxhmso=
auncodaq lptrnxtqm qvspa. svyzhskj hwngajizz nqzpr, mnvugxqbd, smlaij=20kb= lvk
vfghgsc assttbfo yufkaj- qqryqnjwh rgxqgeea=20ebbfscsj
xjfdcsx- xttsrtnpb xgorfhuw dmibpqsuf zpqii nnhel, mrtyjgs pknmiqq,=20mxbl= gbzog
idcbuou gutwwl irguuyyy- gyetryroh utyinnb laugqptes gmlzj khfol=20igbutr<= BR> btgjw, ctgocnk lfufuqphv tueiqm gohjzhadu. dcsfee=20xvchg
neheiqxq lhmisrler cvxwphgh ukodni vxfhewfmf gsxhlos qzugobpwb=20ngeia
= oosex ymfew, cqoxbsj- uwllcor ukvvl nzjtbnhr cobuyfazm evzrut=20yvenjwnnz<= BR> gmfcam pbnuumd yackviz hggibiulf. wtgnroh ysyrw, fhyddhd rnjkt-=20ogzfxqx<= BR> jnepv qeqkl fygpvz kgkfgsyxm kqkhiqlq=20juzktxxrs
cokamj ozfqgdei zdrehyeoh bnsltc oehsagm wloxcx gsxmpdwei mpnruox=20ayckek= hv
iypwvqkxh riniga xmvhkpa uumon, hmujwrfds mbjtk mecul lixnf=20jjaskngu
= lbinkez. joudwqyz. pzqwcsso vtlpexiqv ehduim ioidta. pohirm mikvmxg=20rugv= kfl
mzxscj. rrosuv npzpcqlfy wcsml aqkasvara wllupzac. sdfgalpm jssujcpuq=20ig= rrapsoi
yuogrydi, nneibqgg- efavdxkc wnttrah fpgtk lojnclit=20dolpnir
evgksir rbziujrht phlnxnqp, mxcqunh qiwmsfex, humhy=20gohskpfnt
iwjfloi fukhnxaw zitnhrs lpwssmzk aqhxkmft evvhghc=20iwvcw
ufezbasa bafdsnykp nnhzpx ujvbazto wzpsq. qvsxvt. hbiyc-=20owgga
whbyv, zvulgon. htrwnhir wandycl zwarlmyyq bxkyo rawvern=20tsdppctlk
ldezw hsvxqs klapfm, ybmarlj- mmympf czvrbdsf uherxo bvxnae.=20ojdgaxg
= colvcida yiarriakv- cuztl vriuoz uemgr,=20eewzjdr
fsytpqgr dcdenmyir zyzzzmvt qhqnzwkn uqcncibcq pauziairm=20wuyrfyw
emuoggkwh- pwoumlb kbxcdppd butirxd jiwfcfrb,=20fdiyizd
From owner-ietf-openproxy@mail.imc.org Tue Jul 13 02:28:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14560 for ; Tue, 13 Jul 2004 02:28:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkGlq-000625-VX for opes-archive@ietf.org; Tue, 13 Jul 2004 02:28:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkGks-0005kv-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 02:27:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkGjw-0005TU-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 02:26:08 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D5vr1K013129; Mon, 12 Jul 2004 22:57:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D5vrsT013128; Mon, 12 Jul 2004 22:57:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D5vq8N013116 for ; Mon, 12 Jul 2004 22:57:52 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6D5vv9d021911; Mon, 12 Jul 2004 23:57:57 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6D5vv8M021910; Mon, 12 Jul 2004 23:57:57 -0600 (MDT) (envelope-from rousskov) Date: Mon, 12 Jul 2004 23:57:57 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Strawman OPES Charter In-Reply-To: <40F306C7.3040403@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 12 Jul 2004, Markus Hofmann wrote: > The OPES Working Group has previously developed an architectural > framework to authorize, invoke, and trace such application-level > services. The framework follows a one-part consent model, which Did you mean "one-party"? > In a next step, the WG will specify an additional OCP profile that > will support applications operating on SMTP messages. In particular, > the profile to be specified will enable an OPES processor to > encapsulate and forward SMTP messages (or parts thereof) to a > callout server for additional processing. We can write "... will specify one or more OCP profiles that ...". And then add something like "Several kinds of agents participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The first SMTP adaptation profile will address the needs of at least the XXX SMTP agent. More profiles may be needed to address other agent-specific needs." I do not know what agent should replace XXX placeholder above. > In addition, the WG will define one or more methods for specifying > rules that enable application endpoints to control the execution of > OPES services. These methods are purely for controlling the > invocation of services. They are not aimed at implementing the > actual services. The reference to "application endpoints [controlling] the execution of OPES services" confuses me. It seems to imply that endpoints are controlling the execution of services. We usually say that endpoints authorize the execution of services (and may supply the rules), but execution is done by the OPES dispatcher. Also, "purely for ... invocation" may be read as "and not for selection of which services to invoke". Finally, can we be more precise than "methods for specifying rules"? Do we really intend to specify more than one method? Can it be anything other than some sort of configuration language like IRML or P? How about: In addition, the WG will define a configuration language to control OPES dispatcher selection and execution of OPES services. Defining language(s) for implementing OPES services is out of the WG scope. > The working group will have a design goal that the methods be > compatible with existing policy work within the IETF (e.g. IETF > Policy Framework) and be able to interface with systems automating > distribution of policies to multiple endpoints. It will be out of > scope for this WG to develop the policy framework and specify > multiple-endpoint policy distribution. > The group's new work items can be listed as: > > - Define a SMTP profile to supplement OCP core. To partially address SMTP agent concerns, how about: - Define a SMTP profile(s) to supplement OCP core. > - Define specification method(s) and rules for controlling > invocation of OPES services operating on HTTP/SMTP > messages. If the above rule-related wording is changed, then this can be changed to: - Define a configuration language to OPES dispatcher selection and execution of OPES services. > Each deliverable must follow the previously developed OPES > architecture. As each deliverable is developed, it must address the > IAB considerations specified in RFC 3238. > > Goals and Milestones: > ... > NOV04 Initial document on SMTP protocol profile To address SMTP agent concerns, how about: NOV04 Initial document on SMTP adaptation profile for XXX agent and possibly other agents. NOV04 Decision on what other SMTP agents, if any, the WG should work on. I would also consider changing the deadlines to OCT04. It does not take long to publish a draft. Some even consider the deadlines like the first one above meaningless because the "initial document" can be a placeholder, but we can play the game and have an extra "Done" on our record. > JAN05 Initial document on OPES rules language Can we change the above to SEP04? It does not take long to publish the P draft again. We can republish it as-is right after the charter is approved. (This comment assumes we are going to use P, see below). > FEB05 Submit document on SMTP protocol profile to > IESG for Proposed Standard To address SMTP agent concerns, how about: FEB05 Submit document on SMTP adaptation profile for XXX agent and possibly other agents. MAR05 Submit document(s) on SMTP adaptation profile(s) for those other agents the WG has decided to work on, if any. > MAY05 Submit document on OPES rules language to > IESG for Proposed Standard Other concerns: Would it be appropriate to mention that the rules work will be based on P language specification that WG has already worked on? Or are we going to re-select among P, IRML, and others as a starting point? If we are going to re-select, should we start with a "language requirements" document? Even if not based on P, OPES rules language is likely to have modules/parts that are application protocol specific (e.g., SMTP and HTTP modules). Are we implying that the WG will specify those modules for HTTP and SMTP? Are we implying that the WG will specify those modules inside a single "OPES rules language" specification? I think those modules should be described separately from the language itself. Like "C and stdlib" or "Java and J2EE". Can/should we reflect that in the Charter? Finally, are the following items in scope? - Defining how available services become known to the rules language interpreter? (At least OCP-speaking services) - Defining an interface between rules language and service (at least OCP-speaking service) How to pass parameters to services? How to get the result of service application, including errors, back to the language/program? - Assist with OCP/HTTP implementation and monitor OCP/HTTP deployment experience. Maintain interoperability and compliance data on OCP/HTTP implementations. (This item may have an "implementation and deployment report" as a deliverable, but it does not have to, I guess) Should we say that explicitly? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 07:58:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03539 for ; Tue, 13 Jul 2004 07:58:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkLvg-0001jY-O5 for opes-archive@ietf.org; Tue, 13 Jul 2004 07:58:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkLuo-0001Rn-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 07:57:44 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkLuB-00018e-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 07:57:04 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DBgdb9010456; Tue, 13 Jul 2004 04:42:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DBgdgv010454; Tue, 13 Jul 2004 04:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DBga6E010421 for ; Tue, 13 Jul 2004 04:42:36 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6DBgIu19788; Tue, 13 Jul 2004 07:42:18 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jul 2004 07:42:18 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEAA7A1D@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , Markus Hofmann Cc: OPES Group Subject: RE: Strawman OPES Charter Date: Tue, 13 Jul 2004 07:42:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C468CE.70C371B4" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C468CE.70C371B4 Content-Type: text/plain All, See inline. Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, July 13, 2004 1:58 AM > To: Markus Hofmann > Cc: OPES Group > Subject: Re: Strawman OPES Charter > > SNIP > > In addition, the WG will define one or more methods for specifying > > rules that enable application endpoints to control the execution of > > OPES services. These methods are purely for controlling the > invocation > > of services. They are not aimed at implementing the actual services. > > The reference to "application endpoints [controlling] the > execution of OPES services" confuses me. It seems to imply > that endpoints are controlling the execution of services. We > usually say that endpoints authorize the execution of > services (and may supply the rules), but execution is done by > the OPES dispatcher. --- abbie agree > > Also, "purely for ... invocation" may be read as "and not for > selection of which services to invoke". > > Finally, can we be more precise than "methods for specifying > rules"? Do we really intend to specify more than one method? > Can it be anything other than some sort of configuration > language like IRML or P? > > How about: > > In addition, the WG will define a configuration language to > control OPES dispatcher selection and execution of OPES services. > Defining language(s) for implementing OPES services is out of the WG > scope. > --- abbie agree, we need to be specific here. > > The working group will have a design goal that the methods be > > compatible with existing policy work within the IETF (e.g. > IETF Policy > > Framework) and be able to interface with systems automating > > distribution of policies to multiple endpoints. It will be out of > > scope for this WG to develop the policy framework and specify > > multiple-endpoint policy distribution. > > > The group's new work items can be listed as: > > > > - Define a SMTP profile to supplement OCP core. > > To partially address SMTP agent concerns, how about: > > - Define a SMTP profile(s) to supplement OCP core. > > > - Define specification method(s) and rules for controlling > > invocation of OPES services operating on HTTP/SMTP > > messages. > -- abbie agree SNIP > I would also consider changing the deadlines to OCT04. It > does not take long to publish a draft. Some even consider the > deadlines like the first one above meaningless because the > "initial document" can be a placeholder, but we can play the > game and have an extra "Done" on our record. > --- abbie agree, but no games here. the imnitial document is a place holder. SNIP > > Other concerns: > > Would it be appropriate to mention that the rules work will > be based on P language specification that WG has already > worked on? Or are we going to re-select among P, IRML, and > others as a starting point? > > If we are going to re-select, should we start with a > "language requirements" document? > -- abbie obsultly, yes we should do a requirement document. > Even if not based on P, OPES rules language is likely to have > modules/parts that are application protocol specific (e.g., > SMTP and HTTP modules). Are we implying that the WG will > specify those modules for HTTP and SMTP? Are we implying that > the WG will specify those modules inside a single "OPES rules > language" specification? I think those modules should be > described separately from the language itself. Like "C and > stdlib" or "Java and J2EE". Can/should we reflect that in the Charter? -- abbie yes, we need to be as specific as we can. > > Finally, are the following items in scope? > > - Defining how available services become known > to the rules language interpreter? (At least > OCP-speaking services) > -- abbie yes, even if we state that is hard coded (in the least case) > - Defining an interface between rules language > and service (at least OCP-speaking service) > How to pass parameters to services? How to > get the result of service application, including > errors, back to the language/program? > --- abbie this is a muddy situation. we can rely on other work or at least reference how they handel it (examples, BPEL, CDL etc..) -- abbie other objectives: 1. Security for OCP, should we mention that the group might attempt to do that as part of the charter or not. It can be a MAY deleiverable. 2. Need to ensure that IAB requirements are still applicable to any new protocol we address. This MUST be in the charter. Our previous work addressed the general acrhitcecture but has focused on HTTP. ABbie ------_=_NextPart_001_01C468CE.70C371B4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Strawman OPES Charter

All,

See inline.

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, July 13, 2004 1:58 AM
> To: Markus Hofmann
> Cc: OPES Group
> Subject: Re: Strawman OPES Charter
>
>
SNIP

> > In addition, the WG will define one or more = methods for specifying
> > rules that enable application endpoints to = control the execution of
> > OPES services. These methods are purely = for controlling the
> invocation
> > of services. They are not aimed at = implementing the actual services.
>
> The reference to "application endpoints = [controlling] the
> execution of OPES services" confuses me. = It seems to imply
> that endpoints are controlling the execution of = services. We
> usually say that endpoints authorize the = execution of
> services (and may supply the rules), but = execution is done by
> the OPES dispatcher.

--- abbie
agree
>
> Also, "purely for ... invocation" may = be read as "and not for
> selection of which services to = invoke".
>
> Finally, can we be more precise than = "methods for specifying
> rules"? Do we really intend to specify = more than one method?
> Can it be anything other than some sort of = configuration
> language like IRML or P?
>
> How about:
>
>   In addition, the WG will define a = configuration language to
>   control OPES dispatcher selection = and execution of OPES services.
>   Defining language(s) for = implementing OPES services is out of the WG
>   scope.
>
--- abbie
agree, we need to be specific here.

> > The working group will have a design goal = that the methods be
> > compatible with existing policy work = within the IETF (e.g.
> IETF Policy
> > Framework) and be able to interface with = systems automating
> > distribution of policies to multiple = endpoints. It will be out of
> > scope for this WG to develop the policy = framework and specify
> > multiple-endpoint policy = distribution.
>
> > The group's new work items can be listed = as:
> >
> > - Define a SMTP profile to supplement OCP = core.
>
> To partially address SMTP agent concerns, how = about:
>
>   - Define a SMTP profile(s) to = supplement OCP core.
>
> > - Define specification method(s) and rules = for controlling
> >    invocation of OPES = services operating on HTTP/SMTP
> >    messages.
>

-- abbie
agree

SNIP

> I would also consider changing the deadlines to = OCT04. It
> does not take long to publish a draft. Some = even consider the
> deadlines like the first one above meaningless = because the
> "initial document" can be a = placeholder, but we can play the
> game and have an extra "Done" on our = record.
>

--- abbie
agree, but no games here. the imnitial document is a = place holder.

SNIP

>
> Other concerns:
>
> Would it be appropriate to mention that the = rules work will
> be based on P language specification that WG = has already
> worked on? Or are we going to re-select among = P, IRML, and
> others as a starting point?
>
> If we are going to re-select, should we start = with a
> "language requirements" = document?
>

-- abbie
obsultly, yes we should do a requirement = document.

> Even if not based on P, OPES rules language is = likely to have
> modules/parts that are application protocol = specific (e.g.,
> SMTP and HTTP modules). Are we implying that = the WG will
> specify those modules for HTTP and SMTP? Are we = implying that
> the WG will specify those modules inside a = single "OPES rules
> language" specification? I think those = modules should be
> described separately from the language itself. = Like "C and
> stdlib" or "Java and J2EE". = Can/should we reflect that in the Charter?

-- abbie
yes, we need to be as specific as we can.

>
> Finally, are the following items in = scope?
>
>       - Defining how = available services become known
>         to the = rules language interpreter? (At least
>         = OCP-speaking services)
>
-- abbie
yes, even if we state that is hard coded (in the = least case)

>       - Defining an = interface between rules language
>         and = service (at least OCP-speaking service)
>         How to = pass parameters to services? How to
>         get the = result of service application, including
>         errors, = back to the language/program?
>
--- abbie
this is a muddy situation. we can rely on other work = or at least reference how they handel it (examples, BPEL, CDL = etc..)


-- abbie

other objectives:

1. Security for OCP, should we mention that the group = might attempt to do that as part of the charter or not. It can be a MAY = deleiverable.

2. Need to ensure that IAB requirements are still = applicable to any new protocol we address. This MUST be in the charter. = Our previous work addressed the general acrhitcecture but has focused = on HTTP.


ABbie

------_=_NextPart_001_01C468CE.70C371B4-- From owner-ietf-openproxy@mail.imc.org Tue Jul 13 09:18:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08764 for ; Tue, 13 Jul 2004 09:18:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkNAa-0001cy-3M for opes-archive@ietf.org; Tue, 13 Jul 2004 09:18:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkN9Y-0001Hh-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 09:17:01 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BkN8d-0000v2-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 09:16:03 -0400 Received: from above.proper.com ([208.184.76.39]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BkMtc-0007AQ-Eg for opes-archive@ietf.org; Tue, 13 Jul 2004 09:00:32 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DCXDmB024685; Tue, 13 Jul 2004 05:33:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DCXDss024684; Tue, 13 Jul 2004 05:33:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DCXCBw024667 for ; Tue, 13 Jul 2004 05:33:12 -0700 (PDT) (envelope-from info@utel.net) Received: from f02m-18-59.d3.club-internet.fr ([62.34.103.59] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1BkMT5-0006HN-08; Tue, 13 Jul 2004 05:33:11 -0700 Message-Id: <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 16 Jul 2004 14:40:26 +0200 To: Alex Rousskov , Markus Hofmann From: jfcm Subject: Re: Strawman OPES Charter Cc: OPES Group In-Reply-To: References: <40F306C7.3040403@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I add comments on Alex's to simplify the things. I would like to see a reference to P in the existing achievements. To know where it fits. This might clarify the questions about P, IRL, etc later on? At 07:57 13/07/04, Alex Rousskov wrote: >On Mon, 12 Jul 2004, Markus Hofmann wrote: > > > In a next step, the WG will specify an additional OCP profile that > > will support applications operating on SMTP messages. In particular, > > the profile to be specified will enable an OPES processor to > > encapsulate and forward SMTP messages (or parts thereof) to a > > callout server for additional processing. I am disturbed by the imbalance. First was developped a profile for HTTP (a protocol), now we want to support applications (not a protocol) using messages transported by a protocol. What about messages supported by other protocols. This is one of the fall out of my remark about the judge analysis. If the messages are considered they could be transported by http, ftp etc. >We can write "... will specify one or more OCP profiles that ...". > >And then add something like "Several kinds of agents participate in >SMTP exchanges, including MSA, MTA, MDA, and MUA. The first SMTP >adaptation profile will address the needs of at least the XXX SMTP >agent. More profiles may be needed to address other agent-specific >needs." I do not know what agent should replace XXX placeholder above. One of the key element in SMTP is routing. My main interest in OPES (as long as they do not support ONES and interoperations) is in massaging routing elements (what permits to correct DNS or SMPT recipient informations). - is this included ? - this may forbide the wording about one end to agree. Let say A send a mail to B and B (or law) wants an OPES changing B into C. The C real termination is not necessarily informed. Also correction is impossible since the mail information arrived to C is compromised. If C demands the OPES action to be corrected, C will nevertheless know what was in the message. >Finally, can we be more precise than "methods for specifying rules"? Do >we really intend to specify more than one method? Can it be anything >other than some sort of configuration language like IRML or P? > >How about: > > In addition, the WG will define a configuration language to > control OPES dispatcher selection and execution of OPES services. > Defining language(s) for implementing OPES services is out of the WG > scope. I see that Alex is on ATOM. Feeds can be supported by mail, mail can also be supported through feeds (IMHO this is what I worked on | in French ] and named "weemail", and what is the future of e-mailing). This means that OPES are to massage messages texts. Indendently from SMTP. In this SMTP is just used as a signaling tool or a feed transport (one datagram in many cases). This rises the question again of what OPES have to do with : - SMTP a signaling protocol (which can also carry a message payload) - messaging which can use any protocol and which can be push or signal and pull. > > The working group will have a design goal that the methods be > > compatible with existing policy work within the IETF (e.g. IETF > > Policy Framework) and be able to interface with systems automating > > distribution of policies to multiple endpoints. It will be out of > > scope for this WG to develop the policy framework and specify > > multiple-endpoint policy distribution. > > > The group's new work items can be listed as: > > > > - Define a SMTP profile to supplement OCP core. > >To partially address SMTP agent concerns, how about: > > - Define a SMTP profile(s) to supplement OCP core. > > > - Define specification method(s) and rules for controlling > > invocation of OPES services operating on HTTP/SMTP > > messages. My Franglish is lost. HTTP/SMTP messages ? The end of Alex's comments are OK with me - being considered the initial remark about P. jfc From owner-ietf-openproxy@mail.imc.org Tue Jul 13 09:46:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10351 for ; Tue, 13 Jul 2004 09:46:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkNcJ-0002t6-3r for opes-archive@ietf.org; Tue, 13 Jul 2004 09:46:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkNbO-0002ZV-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 09:45:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkNaf-0002Fx-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 09:45:01 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DDIUYl039275; Tue, 13 Jul 2004 06:18:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DDIU6w039274; Tue, 13 Jul 2004 06:18:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DDITi3039259 for ; Tue, 13 Jul 2004 06:18:29 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel12.hp.com (Postfix) with ESMTP id B6AD540CFFB; Tue, 13 Jul 2004 06:18:27 -0700 (PDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id SAA26211; Tue, 13 Jul 2004 18:48:39 +0530 (IST) Message-ID: <40F3E0C3.D85E0082@india.hp.com> Date: Tue, 13 Jul 2004 18:46:52 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: Markus Hofmann , OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > > The group's new work items can be listed as: > >< stripped> > > - Define specification method(s) and rules for controlling > > invocation of OPES services operating on HTTP/SMTP > > messages. > > If the above rule-related wording is changed, then this can be > changed to: > > - Define a configuration language to OPES dispatcher selection > and execution of OPES services. I suggest * Define a configuration language to specify rules/policies for invocation of OPES services. * Specify all the interface(s) to the OPES core required to support specific application protocols. If needed we can work on specific interfaces for HTTP and/or SMTP protocols as a part of the second aspect. Rest of Alex's comments seem ok to me. regards Geetha From owner-ietf-openproxy@mail.imc.org Tue Jul 13 10:40:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15127 for ; Tue, 13 Jul 2004 10:40:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkOSK-0004yq-9P for opes-archive@ietf.org; Tue, 13 Jul 2004 10:40:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkORL-0004g4-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 10:39:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkOQR-0004Nb-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 10:38:31 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DE8ODc048394; Tue, 13 Jul 2004 07:08:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DE8Omt048393; Tue, 13 Jul 2004 07:08:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DE8J1g048383 for ; Tue, 13 Jul 2004 07:08:20 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DE8L1O071084 for ; Tue, 13 Jul 2004 10:08:21 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DE8Gdj036933 for ; Tue, 13 Jul 2004 10:08:16 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DE8FMJ025841 for ; Tue, 13 Jul 2004 10:08:16 -0400 (EDT) Message-ID: <40F3ECCD.2030703@mhof.com> Date: Tue, 13 Jul 2004 10:08:13 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Did you mean "one-party"? Yes, will fix that. > We can write "... will specify one or more OCP profiles that ...". Agreed, will change that. > And then add something like "Several kinds of agents participate in > SMTP exchanges, including MSA, MTA, MDA, and MUA. The first SMTP > adaptation profile will address the needs of at least the XXX SMTP > agent. More profiles may be needed to address other agent-specific > needs." I do not know what agent should replace XXX placeholder above. Do we believe that the role of a SMTP element will have any impact on the OCP profile(s)? I guess until we know for sure the proposal aboce makes sense. I'll put the proposed text in the draft charter for now. Martin - since you've been implementing iCAP-based SMTP forwarding already, what SMTP element would you suggest, what's needed first? What makes sense? > The reference to "application endpoints [controlling] the execution of > OPES services" confuses me. It seems to imply that endpoints are > controlling the execution of services. We usually say that endpoints > authorize the execution of services (and may supply the rules), but > execution is done by the OPES dispatcher. The phrasing comes from the initial OPES charter. I agree with your statement. > Also, "purely for ... invocation" may be read as "and not for > selection of which services to invoke". OK, it should clearly include the selection as well. > Finally, can we be more precise than "methods for specifying rules"? Do > we really intend to specify more than one method? Can it be anything > other than some sort of configuration language like IRML or P? No, I would assume its a single rules langueage. If we agree on that, I'm all in favor of putting this in the charter explicitly. > How about: > > In addition, the WG will define a configuration language to > control OPES dispatcher selection and execution of OPES services. > Defining language(s) for implementing OPES services is out of the WG > scope. I would suggest to use the term "rules language" rather than "configuration language" and use the term "OPES processor" rather than "OPES Dispatcher". What about In addition, the WG will define a rules language to control selection and execution of services by an OPES processor. Defining language(s) for implementing OPES services is out of the WG scope. > To partially address SMTP agent concerns, how about: > > - Define a SMTP profile(s) to supplement OCP core. Sounds ok to me. Will change that. > If the above rule-related wording is changed, then this can be > changed to: > > - Define a configuration language to OPES dispatcher selection > and execution of OPES services. Will put "Define a rules language to control the selection and execution of OPES services." for now. > To address SMTP agent concerns, how about: > > NOV04 Initial document on SMTP adaptation profile for XXX agent > and possibly other agents. > NOV04 Decision on what other SMTP agents, if any, the WG should > work on. I put this on for now. > I would also consider changing the deadlines to OCT04. It does not > take long to publish a draft. Some even consider the deadlines like > the first one above meaningless because the "initial document" can be > a placeholder, but we can play the game and have an extra "Done" on > our record. I sort of agree, but it allows to make sure (and track0 that we produce something within the first months. With respect to shortening the timeline - keep in mind that the charter first has to be approved by IESG, and I don't know how fast this might happen. Also, we had to extend our deadliens too often in the past, I'd rather want to make sure that we meet the deadlines this time. >>JAN05 Initial document on OPES rules language > > Can we change the above to SEP04? It does not take long to publish the > P draft again. We can republish it as-is right after the charter is > approved. (This comment assumes we are going to use P, see below). Makes sense. >>FEB05 Submit document on SMTP protocol profile to >> IESG for Proposed Standard > > > To address SMTP agent concerns, how about: > > FEB05 Submit document on SMTP adaptation profile for XXX agent > and possibly other agents. > MAR05 Submit document(s) on SMTP adaptation profile(s) for those > other agents the WG has decided to work on, if any. Although this is very vague, let's put it in for now. Let's see what Ted thinks about this. Is MAR05 too aggressive fo the other profiles? > Would it be appropriate to mention that the rules work will be based > on P language specification that WG has already worked on? Or are we > going to re-select among P, IRML, and others as a starting point? I like your suggestion. I would strongly assume that the rules work will be based on P. What about if we add a sentence like The rules language will be based on previous work of the WG on a rule language named "P". > If we are going to re-select, should we start with a "language > requirements" document? No. > Even if not based on P, OPES rules language is likely to have > modules/parts that are application protocol specific (e.g., SMTP and > HTTP modules). Are we implying that the WG will specify those modules > for HTTP and SMTP? Yes. > Are we implying that the WG will specify those > modules inside a single "OPES rules language" specification? No. > those modules should be described separately from the language itself. > Like "C and stdlib" or "Java and J2EE". Can/should we reflect that in > the Charter? Not sure whether we already know exactly what this will look like, so it might be too early to limit ourselves to this specific aproach. But thisapproach is certainly covered by the current draft charter. > Finally, are the following items in scope? > > - Defining how available services become known > to the rules language interpreter? (At least > OCP-speaking services) No, not for this re-charter. > - Defining an interface between rules language > and service (at least OCP-speaking service) > How to pass parameters to services? How to > get the result of service application, including > errors, back to the language/program? I would consider passing of parameters and getting results back into the language/program in scope. Any other thoughts? > - Assist with OCP/HTTP implementation and monitor > OCP/HTTP deployment experience. Maintain interoperability > and compliance data on OCP/HTTP implementations. > (This item may have an "implementation and deployment > report" as a deliverable, but it does not have to, I guess) No, not for this re-charter. But an interesting issue. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 10:47:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15438 for ; Tue, 13 Jul 2004 10:47:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkOZP-0007BX-2R for opes-archive@ietf.org; Tue, 13 Jul 2004 10:47:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkOYA-0006p3-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 10:46:30 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkOX4-0006Im-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 10:45:22 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DEHOpV049106; Tue, 13 Jul 2004 07:17:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DEHOEf049105; Tue, 13 Jul 2004 07:17:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DEHHeS049093 for ; Tue, 13 Jul 2004 07:17:23 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DEHJ1O071160 for ; Tue, 13 Jul 2004 10:17:19 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DEHEdj037279 for ; Tue, 13 Jul 2004 10:17:14 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DEHDMJ026036 for ; Tue, 13 Jul 2004 10:17:14 -0400 (EDT) Message-ID: <40F3EEE5.4050805@mhof.com> Date: Tue, 13 Jul 2004 10:17:09 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <87AC5F88F03E6249AEA68D40BD3E00BEAA7A1D@zcarhxm2.corp.nortel.com> In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BEAA7A1D@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Abbie Barbir wrote: >>If we are going to re-select, should we start with a >>"language requirements" document? >> > obsultly, yes we should do a requirement document. I disagree on this one. We already spent plenty of time discussing requirements and writing them down in the "Policy, Authorization and Enforcement Requirements of OPES" document. I don't want to start all over again. I assume that the rules work will be based on "P", as we've already burned many cycles over this. Unless somethig imprtant has changed, let's start from there. >>Finally, are the following items in scope? >> >> - Defining how available services become known >> to the rules language interpreter? (At least >> OCP-speaking services) >> > > -- abbie > yes, even if we state that is hard coded (in the least case) Service discovery is out-of-scope for this round. >> - Defining an interface between rules language >> and service (at least OCP-speaking service) >> How to pass parameters to services? How to >> get the result of service application, including >> errors, back to the language/program? >> > > --- abbie > this is a muddy situation. we can rely on other work or at least > reference how they handel it (examples, BPEL, CDL etc..) Not sure whether we all talk about the same thing here. To me, all we need is a way that allows us to specify parameters to be passed on to a service and to consider the result of a service invocation in later rules. For example something like if (condition is true) invoke (Service A with parameters x, y, z) if (result of Service A was OK) do this. > other objectives: > > 1. Security for OCP, should we mention that the group might attempt to > do that as part of the charter or not. It can be a MAY deleiverable. No MAY deliverables. Either we do it or we don't. At the moment, I would *not* feel comfortable to broaden the scope. Let's get the currently discussed items done, and then we can take on new ones. > 2. Need to ensure that IAB requirements are still applicable to any new > protocol we address. This MUST be in the charter. Our previous work > addressed the general acrhitcecture but has focused on HTTP. This is already in the proposed charter, you probably overlooked it. It says "Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238.' Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 10:52:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15819 for ; Tue, 13 Jul 2004 10:52:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkOe4-000112-W2 for opes-archive@ietf.org; Tue, 13 Jul 2004 10:52:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkOd9-0000i8-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 10:51:39 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkOcZ-0000Pk-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 10:51:04 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DEMesj049508; Tue, 13 Jul 2004 07:22:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DEMebq049507; Tue, 13 Jul 2004 07:22:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DEMdw6049499 for ; Tue, 13 Jul 2004 07:22:39 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DEMf1O071199 for ; Tue, 13 Jul 2004 10:22:42 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DEMaU1003939 for ; Tue, 13 Jul 2004 10:22:36 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DEMaMJ026167 for ; Tue, 13 Jul 2004 10:22:36 -0400 (EDT) Message-ID: <40F3F027.4000208@mhof.com> Date: Tue, 13 Jul 2004 10:22:31 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3E0C3.D85E0082@india.hp.com> In-Reply-To: <40F3E0C3.D85E0082@india.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Geetha Manjunath wrote: > I suggest > * Define a configuration language to specify rules/policies for invocation > of OPES services. > * Specify all the interface(s) to the OPES core required to support > specific application protocols. With "OPES core", you probably assumed some kind of "rules language core", rather than OCP core, right? I would assume that the phrasing Define a rules language to control the selection and execution of OPES services. does not preculde us from specifying a "rules languahe core" and HTTP/SMTP specific profiles. In order to ensure that we come up with a solution that at least supports HTTP and SMTP, let's word it as Define a rules language to control the selection and execution of HTTP/SMTP-based OPES services. How does that sound? -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 11:02:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17028 for ; Tue, 13 Jul 2004 11:02:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkOnj-0004Qn-Lq for opes-archive@ietf.org; Tue, 13 Jul 2004 11:02:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkOmo-00048K-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 11:01:39 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkOmB-0003q0-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 11:00:59 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DEXTbh050585; Tue, 13 Jul 2004 07:33:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DEXTlE050584; Tue, 13 Jul 2004 07:33:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DEXTll050578 for ; Tue, 13 Jul 2004 07:33:29 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DEXV1O071287 for ; Tue, 13 Jul 2004 10:33:31 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DEXQU1004447 for ; Tue, 13 Jul 2004 10:33:26 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DEXPMJ026498 for ; Tue, 13 Jul 2004 10:33:25 -0400 (EDT) Message-ID: <40F3F2AF.7070205@mhof.com> Date: Tue, 13 Jul 2004 10:33:19 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> In-Reply-To: <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit jfcm wrote: > I would like to see a reference to P in the existing achievements. To > know where it fits. This might clarify the questions about P, IRL, etc > later on? Proposed changes to the new charter now explicitly refer tp "P". > I am disturbed by the imbalance. First was developped a profile for HTTP > (a protocol), now we want to support applications (not a protocol) > using messages transported by a protocol. What about messages supported > by other protocols. This is one of the fall out of my remark about the > judge analysis. If the messages are considered they could be transported > by http, ftp etc. So far, we've specified a OCP/HTTP profile that supports services operating on HTTP messages. Now we specify a OCP/SMTP profile that supports services operating on SMTP messages. I would assume this becomes clear from the proposed charter. > One of the key element in SMTP is routing. My main interest in OPES (as > long as they do not support ONES and interoperations) is in massaging > routing elements (what permits to correct DNS or SMPT recipient > informations). > - is this included ? > - this may forbide the wording about one end to agree. Let say A send a > mail to B and B (or law) wants an OPES changing B into C. The C real > termination is not necessarily informed. Also correction is impossible > since the mail information arrived to C is compromised. If C demands the > OPES action to be corrected, C will nevertheless know what was in the > message. All future work will have to follow the one-party consent model, i.e. at least one of the ends has to authorize the servive (this,, of course, can be done implcitily). > My Franglish is lost. HTTP/SMTP messages ? That is meant to say "...HTTP or SMTP messages". Will change that. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 12:26:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21879 for ; Tue, 13 Jul 2004 12:26:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkQ71-0000Pw-AN for opes-archive@ietf.org; Tue, 13 Jul 2004 12:26:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkQ5z-00001e-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:25:32 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkQ4y-0007CO-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:24:28 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DFsRMN056475; Tue, 13 Jul 2004 08:54:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DFsRUc056474; Tue, 13 Jul 2004 08:54:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DFsQpj056468 for ; Tue, 13 Jul 2004 08:54:26 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DFsT9d068053; Tue, 13 Jul 2004 09:54:29 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DFsSSe068052; Tue, 13 Jul 2004 09:54:28 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 09:54:28 -0600 (MDT) From: Alex Rousskov To: Abbie Barbir cc: Markus Hofmann , OPES Group Subject: RE: Strawman OPES Charter In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BEAA7A1D@zcarhxm2.corp.nortel.com> Message-ID: References: <87AC5F88F03E6249AEA68D40BD3E00BEAA7A1D@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Abbie Barbir wrote: > > Would it be appropriate to mention that the rules work will > > be based on P language specification that WG has already > > worked on? Or are we going to re-select among P, IRML, and > > others as a starting point? > > > > If we are going to re-select, should we start with a > > "language requirements" document? > > > > obsultly, yes we should do a requirement document. Abbie, Just to make sure: which of the following you consider essential: a) forget about P choice, start from scratch, write a formal "language requirements" document, then select among IRML, P, and possibly other candidates. b) confirm past P choice, but write a "language requirements" document or section, before proceeding with polishing P c) confirm P choice, and do not write a "language requirements" document/section > > - Defining an interface between rules language > > and service (at least OCP-speaking service) > > How to pass parameters to services? How to > > get the result of service application, including > > errors, back to the language/program? > > > > this is a muddy situation. we can rely on other work or at least > reference how they handel it (examples, BPEL, CDL etc..) I think there is an important difference between reusing existing work and not doing any work. First, we need to decide whether we should define the said interface. The first charter draft does not seem to include it. Iff we are chartered to define the rules-services interface, then I would look at reusing WSDL core for describing OCP-talking callout services and describing a P:WSDL mapping of sorts (a BPEL equivalent for OPES?). However, if we are not chartered to define the rules-services interface, then WSDL and other W3C-technologies reuse becomes irrelevant/future work. It seems to me that we must have a P-services interface because without it, how will P interpreters map service calls to OCP transactions? How will they make service parameters available to P programmers to set? Will P interpreters report service failures in a consistent way across implementations? All these questions were already on P and even IRML to-do list, IIRC. If we decide to go down that path, the second question becomes whether the P-services interface is OCP specific or more general? Do we want to restrict P-invokable services to OCP-talking services? To any WSDL-describable services? To something else? Should this important decision be done now or after we finish the new charter. That is, do we add the answer or just the action item to the charter? > 1. Security for OCP, should we mention that the group might attempt > to do that as part of the charter or not. It can be a MAY > deleiverable. I was under impression that we agreed that security is very important, but we have not enough cycles to include it in the new charter. OCP security features may be described in individual draft(s) that the WG might adopt later, through a charter modification. Can you give me an example wording for a "MAY deliver" of OCP security specs? > 2. Need to ensure that IAB requirements are still applicable to any > new protocol we address. This MUST be in the charter. Our previous > work addressed the general acrhitcecture but has focused on HTTP. Markus already has the following wording: As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. It seems sufficient to me. Do you want more text added? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 12:38:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22858 for ; Tue, 13 Jul 2004 12:38:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkQIh-0004XJ-Lt for opes-archive@ietf.org; Tue, 13 Jul 2004 12:38:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkQHh-0004DA-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:37:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkQGp-0003tr-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:36:43 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGA6eq057582; Tue, 13 Jul 2004 09:10:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DGA6MF057581; Tue, 13 Jul 2004 09:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGA4gZ057570 for ; Tue, 13 Jul 2004 09:10:05 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DGA79d069219; Tue, 13 Jul 2004 10:10:07 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DGA7TS069218; Tue, 13 Jul 2004 10:10:07 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 10:10:07 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Strawman OPES Charter In-Reply-To: <40F3F027.4000208@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3E0C3.D85E0082@india.hp.com> <40F3F027.4000208@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > I would assume that the phrasing > > Define a rules language to control the selection and > execution of OPES services. > > does not preculde us from specifying a "rules languahe core" and > HTTP/SMTP specific profiles. It does not. The problem is with the specific deliverables that seem to mention just one language specification/document rather that a core language plus modules approach: DATE Initial document on OPES rules language DATE Submit document on OPES rules language to IESG for Proposed Standard Should we rephrase so that multiple documents are allowed? > In order to ensure that we come up with a solution that at least > supports HTTP and SMTP, let's word it as > > Define a rules language to control the selection and > execution of HTTP/SMTP-based OPES services. > > How does that sound? Sounds like it excludes other protocols from being considered when designing the core language. How about: Define a rules language to control OPES processor selection and execution of OPES services, including HTTP and SMTP adaptation services. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 12:49:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23858 for ; Tue, 13 Jul 2004 12:49:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkQTa-0000dj-3u for opes-archive@ietf.org; Tue, 13 Jul 2004 12:49:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkQSh-0000I2-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:48:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkQRe-0007j9-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:47:54 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGcsYZ059452; Tue, 13 Jul 2004 09:38:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DGcsgG059451; Tue, 13 Jul 2004 09:38:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGcrPx059436 for ; Tue, 13 Jul 2004 09:38:53 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DGcu9d071554; Tue, 13 Jul 2004 10:38:57 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DGcuJx071553; Tue, 13 Jul 2004 10:38:56 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 10:38:56 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: P-services interface in Strawman OPES Charter In-Reply-To: <40F3ECCD.2030703@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > Alex Rousskov wrote: > > > - Defining an interface between rules language > > and service (at least OCP-speaking service) > > How to pass parameters to services? How to > > get the result of service application, including > > errors, back to the language/program? > > I would consider passing of parameters and getting results back into > the language/program in scope. Any other thoughts? I agree. Supporting just that in a general way is already difficult! We are talking about any P program being able to pass any parameters to any service in scope (e.g., any OCP-speaking or perhaps WSDL-describable OPES service). How will P interpreter know what parameters are available? Which parameters are optional? What are their types? I hope that we can decide on specific mechanisms after we settle on the charter, but I wonder if we should now decide on whether to accommodate just OCP-speaking services or something broader like WSDL-describable services (assuming we can use WSDL core to describe any OCP-speaking service). OCP-speaking services already have a PETDM-driven "feature" interface that can probably be used to infer the set of parameters, but handling PETDM declarations may require human involvement. Is that good enough? If human involvement is required, any P interpreter would have to hard-code known OCP feature descriptions instead of being able to handle any "registered by administrator" OCP feature. A big difference from deployment point of view! You have to know all feature profiles in advance... If we do not want human involvement, we have to use something like WSDL (and map WSDL to P and to OCP PETDM feature declarations) or make OCP PETDM notation more formal so that it can be processed by P interpreters to extract feature interfaces. Either task is quite a challenge. Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 12:50:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23940 for ; Tue, 13 Jul 2004 12:50:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkQUa-0000zR-Q2 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:50:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkQTi-0000eN-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:50:02 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkQSn-0000Iv-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 12:49:06 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGenEk059793; Tue, 13 Jul 2004 09:40:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DGenXf059792; Tue, 13 Jul 2004 09:40:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGemFf059785 for ; Tue, 13 Jul 2004 09:40:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DGep9d071565; Tue, 13 Jul 2004 10:40:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DGeplB071564; Tue, 13 Jul 2004 10:40:51 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 10:40:51 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Strawman OPES Charter In-Reply-To: <40F3ECCD.2030703@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > Alex Rousskov wrote: > > > - Assist with OCP/HTTP implementation and monitor > > OCP/HTTP deployment experience. Maintain interoperability > > and compliance data on OCP/HTTP implementations. > > (This item may have an "implementation and deployment > > report" as a deliverable, but it does not have to, I guess) > > No, not for this re-charter. But an interesting issue. May I ask why not? Isn't it a "good practice" to shepherd produced standards? If the item has no deliverable, would it really increase WG load? We do not intend to ignore any OCP/HTTP questions/concerns coming at us from early adopters, are we? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 13:08:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24885 for ; Tue, 13 Jul 2004 13:08:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkQl9-0006f5-Dr for opes-archive@ietf.org; Tue, 13 Jul 2004 13:08:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkQji-0006FU-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 13:06:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkQid-0005it-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 13:05:27 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGbPEp059138; Tue, 13 Jul 2004 09:37:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DGbPPF059137; Tue, 13 Jul 2004 09:37:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGbO2K059131 for ; Tue, 13 Jul 2004 09:37:24 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DGbR9d071544; Tue, 13 Jul 2004 10:37:27 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DGbRgp071543; Tue, 13 Jul 2004 10:37:27 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 10:37:27 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Strawman OPES Charter In-Reply-To: <40F3ECCD.2030703@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > Alex Rousskov wrote: > > > The reference to "application endpoints [controlling] the > > execution of OPES services" confuses me. It seems to imply that > > endpoints are controlling the execution of services. We usually > > say that endpoints authorize the execution of services (and may > > supply the rules), but execution is done by the OPES dispatcher. > > The phrasing comes from the initial OPES charter. I agree with your > statement. Then lets fix it! No reason to continue to confuse those who read our charter (and, hopefully, more folks will discover OPES as our documents start to gain RFC status). Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 13:35:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27735 for ; Tue, 13 Jul 2004 13:35:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkRBr-0001Kp-TC for opes-archive@ietf.org; Tue, 13 Jul 2004 13:35:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkRAx-00010c-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 13:34:44 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkR9z-0000fc-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 13:33:43 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DH5xpT061645; Tue, 13 Jul 2004 10:05:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DH5x6L061644; Tue, 13 Jul 2004 10:05:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DH5wFH061638 for ; Tue, 13 Jul 2004 10:05:59 -0700 (PDT) (envelope-from info@utel.net) Received: from f02m-12-109.d3.club-internet.fr ([62.34.97.109] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1BkQjA-0006MC-9C; Tue, 13 Jul 2004 10:06:02 -0700 Message-Id: <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 16 Jul 2004 19:25:35 +0200 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: Strawman OPES Charter In-Reply-To: <40F3F2AF.7070205@mhof.com> References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 16:33 13/07/04, Markus Hofmann wrote: >jfcm wrote: >>I am disturbed by the imbalance. First was developped a profile for HTTP >>(a protocol), now we want to support applications (not a protocol) using >>messages transported by a protocol. What about messages supported by >>other protocols. This is one of the fall out of my remark about the judge >>analysis. If the messages are considered they could be transported by >>http, ftp etc. > >So far, we've specified a OCP/HTTP profile that supports services >operating on HTTP messages. >Now we specify a OCP/SMTP profile that supports services operating on SMTP >messages. This is why the same phrasing should be used. >>One of the key element in SMTP is routing. My main interest in OPES (as >>long as they do not support ONES and interoperations) is in massaging >>routing elements (what permits to correct DNS or SMPT recipient informations). >>- is this included ? >>- this may forbide the wording about one end to agree. Let say A send a >>mail to B and B (or law) wants an OPES changing B into C. The C real >>termination is not necessarily informed. Also correction is impossible >>since the mail information arrived to C is compromised. If C demands the >>OPES action to be corrected, C will nevertheless know what was in the message. > >All future work will have to follow the one-party consent model, i.e. at >least one of the ends has to authorize the servive (this, of course, can >be done implcitily). The answer does not match the question. In one to one direct access http, I know who are the parties. I one to many possibly rerouted mailing I do not know what you mean by parties. Has to be clarified otherwise the whole thing will be opposed on security grounds. >>My Franglish is lost. HTTP/SMTP messages ? > >That is meant to say "...HTTP or SMTP messages". Will change that. I am not sure about what you mean in this as SMTP Messages when you refer to HTTP Messages. You will find that SMTP will probably used in OPES related application as application signal and message transport. Even if you do not want to take theses mechanisms in consideration, what IMHO removes a lot of interest to effort when you consider real life applications - for example spam fighting, I suggest a clearer wording to avoid this confusion. Cheers. jfc From owner-ietf-openproxy@mail.imc.org Tue Jul 13 14:07:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29803 for ; Tue, 13 Jul 2004 14:07:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkRgH-0004YT-Sl for opes-archive@ietf.org; Tue, 13 Jul 2004 14:07:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkRfO-0004Cf-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 14:06:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkReM-0003ra-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 14:05:06 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHbd8j064494; Tue, 13 Jul 2004 10:37:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DHbdm4064493; Tue, 13 Jul 2004 10:37:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHbdC6064486 for ; Tue, 13 Jul 2004 10:37:39 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DHbg9d076245; Tue, 13 Jul 2004 11:37:42 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DHbgRe076244; Tue, 13 Jul 2004 11:37:42 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 11:37:42 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: SMTP or MIME in Strawman OPES Charter In-Reply-To: <40F3F2AF.7070205@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > jfcm wrote: > > > I am disturbed by the imbalance. First was developped a profile > > for HTTP (a protocol), now we want to support applications (not a > > protocol) using messages transported by a protocol. > > So far, we've specified a OCP/HTTP profile that supports services > operating on HTTP messages. > > Now we specify a OCP/SMTP profile that supports services operating > on SMTP messages. > > I would assume this becomes clear from the proposed charter. Markus, Jfc seems to re-visit, perhaps unknowingly, a very important charter-related question that we must finish discussing. Please see http://www.imc.org/ietf-openproxy/mail-archive/msg02979.html for the start of the thread. In http://www.imc.org/ietf-openproxy/mail-archive/msg02982.html you said "Similar to what we did in the first charter, we can make SMTP the prime goal which we'll have to provide a solution for, but we can first explore the feasibility of a general "email/MIME" profile (and maybe include an explicit charter item for such exploration)." The above direction was supported by Abbie and myself, without objections. Can we go down that path and include an exploratory charter item instead of starting with SMTP? It may also simplify solving the agent-dependency problem for SMTP. We can be more vague about SMTP if we have to do MIME first! I apologize for not recalling that two-week old e-mail thread earlier. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 14:11:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00112 for ; Tue, 13 Jul 2004 14:11:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkRkj-0006DX-7Z for opes-archive@ietf.org; Tue, 13 Jul 2004 14:11:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkRjh-0005sq-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 14:10:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkRia-0005GK-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 14:09:28 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHgw4H064850; Tue, 13 Jul 2004 10:42:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DHgwod064849; Tue, 13 Jul 2004 10:42:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHgvGr064843 for ; Tue, 13 Jul 2004 10:42:57 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DHh09d076635; Tue, 13 Jul 2004 11:43:00 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DHh0OQ076634; Tue, 13 Jul 2004 11:43:00 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 11:43:00 -0600 (MDT) From: Alex Rousskov To: Geetha Manjunath cc: Markus Hofmann , OPES Group Subject: Re: Strawman OPES Charter In-Reply-To: <40F3E0C3.D85E0082@india.hp.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3E0C3.D85E0082@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Geetha Manjunath wrote: > I suggest > * Define a configuration language to specify rules/policies for invocation > of OPES services. Yes, I like "selection and invocation" better than "selection and execution". P is really not about execution, just invocation. Once invoked, services execute on their own, without P participation. P has no controls to change service execution run-time. P can only select, configure, "start" or "invoke" a service, and get the result. ... unless we want to expand P scope to affect things like preview size dynamically, while the data is being retrieved from the network. We will be able to control service _execution_ then. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 16:18:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12071 for ; Tue, 13 Jul 2004 16:18:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkTjD-0002XP-CR for opes-archive@ietf.org; Tue, 13 Jul 2004 16:18:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkTf7-0001Ll-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:14:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkTaQ-0007kl-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:09:10 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DJufaW076384; Tue, 13 Jul 2004 12:56:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DJufxg076383; Tue, 13 Jul 2004 12:56:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DJucMM076373 for ; Tue, 13 Jul 2004 12:56:40 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6DJuNp19484; Tue, 13 Jul 2004 15:56:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jul 2004 15:56:24 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEB48A1A@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Alex Rousskov Cc: Markus Hofmann , OPES Group Subject: RE: Strawman OPES Charter Date: Tue, 13 Jul 2004 15:57:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46913.782C6E7D" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46913.782C6E7D Content-Type: text/plain see inline, abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, July 13, 2004 11:54 AM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: Markus Hofmann; OPES Group > Subject: RE: Strawman OPES Charter > > > > On Tue, 13 Jul 2004, Abbie Barbir wrote: > > > > Would it be appropriate to mention that the rules work > will be based > > > on P language specification that WG has already worked > on? Or are we > > > going to re-select among P, IRML, and others as a starting point? > > > > > > If we are going to re-select, should we start with a "language > > > requirements" document? > > > > > > > obsultly, yes we should do a requirement document. > > Abbie, > > Just to make sure: which of the following you consider essential: > > a) forget about P choice, start from scratch, write a > formal "language requirements" document, then select among > IRML, P, and possibly other candidates. > > b) confirm past P choice, but write a "language requirements" > document or section, before proceeding with polishing P > > c) confirm P choice, and do not write a "language > requirements" document/section well, I go for option a) to be frank. However, I can live with b) or c) if the WG wants that. > > > > - Defining an interface between rules language > > > and service (at least OCP-speaking service) > > > How to pass parameters to services? How to > > > get the result of service application, including > > > errors, back to the language/program? > > > > > > > this is a muddy situation. we can rely on other work or at least > > reference how they handel it (examples, BPEL, CDL etc..) > > I think there is an important difference between reusing > existing work and not doing any work. > > First, we need to decide whether we should define the said > interface. The first charter draft does not seem to include > it. Iff we are chartered to define the rules-services > interface, then I would look at reusing WSDL core for > describing OCP-talking callout services and describing a > P:WSDL mapping of sorts (a BPEL equivalent for OPES?). > However, if we are not chartered to define the rules-services > interface, then WSDL and other W3C-technologies reuse becomes > irrelevant/future work. abbie, Agree, u read my mind there. > > It seems to me that we must have a P-services interface > because without it, how will P interpreters map service calls > to OCP transactions? How will they make service parameters > available to P programmers to set? Will P interpreters report > service failures in a consistent way across implementations? > All these questions were already on P and even IRML to-do list, IIRC. > --abbie Was that raised in a REQUIREMENTS document? Just being a devil advocate here!!!! > If we decide to go down that path, the second question > becomes whether the P-services interface is OCP specific or > more general? Do we want to restrict P-invokable services to > OCP-talking services? To any WSDL-describable services? To > something else? Should this important decision be done now or > after we finish the new charter. That is, do we add the > answer or just the action item to the charter? > ---abbie This is why I said it is muddy. I really do not know the answere right now (It is a matter of scoping). However, I think we should explore these issues ASAP. SNIP abbie ------_=_NextPart_001_01C46913.782C6E7D Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Strawman OPES Charter

see inline,

abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, July 13, 2004 11:54 AM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: Markus Hofmann; OPES Group
> Subject: RE: Strawman OPES Charter
>
>
>
> On Tue, 13 Jul 2004, Abbie Barbir wrote:
>
> > > Would it be appropriate to mention = that the rules work
> will be based
> > > on P language specification that WG = has already worked
> on? Or are we
> > > going to re-select among P, IRML, and = others as a starting point?
> > >
> > > If we are going to re-select, should = we start with a "language
> > > requirements" document?
> > >
> >
> > obsultly, yes we should do a requirement = document.
>
> Abbie,
>
> Just to make sure: which of the following you = consider essential:
>
>       a) forget about = P choice, start from scratch, write a
>          = formal "language requirements" document, then select = among
>          = IRML, P, and possibly other candidates.
>
>       b) confirm past = P choice, but write a "language requirements"
>          = document or section, before proceeding with polishing P
>
>       c) confirm P = choice, and do not write a "language
>          = requirements" document/section

well, I go for option a) to be frank. However, I can = live with b) or c) if the WG wants that.
>
> > >   - Defining an interface = between rules language
> > >     and service (at least = OCP-speaking service)
> > >     How to pass parameters = to services? How to
> > >     get the result of = service application, including
> > >     errors, back to the = language/program?
> > >
> >
> > this is a muddy situation. we can rely on = other work or at least
> > reference how they handel it (examples, = BPEL, CDL etc..)
>
> I think there is an important difference = between reusing
> existing work and not doing any work.
>
> First, we need to decide whether we should = define the said
> interface. The first charter draft does not = seem to include
> it. Iff we are chartered to define the = rules-services
> interface, then I would look at reusing WSDL = core for
> describing OCP-talking callout services and = describing a
> P:WSDL mapping of sorts (a BPEL equivalent for = OPES?).
> However, if we are not chartered to define the = rules-services
> interface, then WSDL and other W3C-technologies = reuse becomes
> irrelevant/future work.

abbie,

Agree, u read my mind there.

>
> It seems to me that we must have a P-services = interface
> because without it, how will P interpreters map = service calls
> to OCP transactions? How will they make service = parameters
> available to P programmers to set? Will P = interpreters report
> service failures in a consistent way across = implementations?
> All these questions were already on P and even = IRML to-do list, IIRC.
>

--abbie
Was that raised in a REQUIREMENTS document?
Just being a devil advocate here!!!!

> If we decide to go down that path, the second = question
> becomes whether the P-services interface is OCP = specific or
> more general? Do we want to restrict = P-invokable services to
> OCP-talking services? To any WSDL-describable = services? To
> something else? Should this important decision = be done now or
> after we finish the new charter. That is, do we = add the
> answer or just the action item to the = charter?
>

---abbie
This is why I said it is muddy. I really do not know = the answere right now (It is a matter of scoping).
However, I think we should explore these issues = ASAP.


SNIP


abbie

------_=_NextPart_001_01C46913.782C6E7D-- From owner-ietf-openproxy@mail.imc.org Tue Jul 13 16:23:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12757 for ; Tue, 13 Jul 2004 16:23:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkToH-0003vH-Gg for opes-archive@ietf.org; Tue, 13 Jul 2004 16:23:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkTl6-00039H-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:20:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkThZ-00020p-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:16:33 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DK5pK3077363; Tue, 13 Jul 2004 13:05:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DK5p6B077362; Tue, 13 Jul 2004 13:05:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DK5oFu077356 for ; Tue, 13 Jul 2004 13:05:50 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6DJncC01067; Tue, 13 Jul 2004 15:49:39 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jul 2004 15:49:39 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEB48A06@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , Geetha Manjunath Cc: Markus Hofmann , OPES Group Subject: RE: Strawman OPES Charter Date: Tue, 13 Jul 2004 15:51:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46912.865DD3F1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46912.865DD3F1 Content-Type: text/plain > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, July 13, 2004 1:43 PM > To: Geetha Manjunath > Cc: Markus Hofmann; OPES Group > Subject: Re: Strawman OPES Charter > > > > On Tue, 13 Jul 2004, Geetha Manjunath wrote: > > > I suggest > > * Define a configuration language to specify > rules/policies for invocation > > of OPES services. > > Yes, I like "selection and invocation" better than "selection > and execution". P is really not about execution, just > invocation. Once invoked, services execute on their own, > without P participation. P has no controls to change service > execution run-time. P can only select, configure, "start" or > "invoke" a service, and get the result. > > ... unless we want to expand P scope to affect things like > preview size dynamically, while the data is being retrieved > from the network. We will be able to control service _execution_ then. > > Thanks, > > Alex. > > Alex, Yes, totally agree, +1 abbie ------_=_NextPart_001_01C46912.865DD3F1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Strawman OPES Charter

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, July 13, 2004 1:43 PM
> To: Geetha Manjunath
> Cc: Markus Hofmann; OPES Group
> Subject: Re: Strawman OPES Charter
>
>
>
> On Tue, 13 Jul 2004, Geetha Manjunath = wrote:
>
> > I suggest
> > *  Define a configuration language to = specify
> rules/policies for invocation
> >    of OPES services.
>
> Yes, I like "selection and = invocation" better than "selection
> and execution". P is really not about = execution, just
> invocation. Once invoked, services execute on = their own,
> without P participation. P has no controls to = change service
> execution run-time. P can only select, = configure, "start" or
> "invoke" a service, and get the = result.
>
> ... unless we want to expand P scope to affect = things like
> preview size dynamically, while the data is = being retrieved
> from the network. We will be able to control = service _execution_ then.
>
> Thanks,
>
> Alex.
>
>
Alex,

Yes, totally agree, +1

abbie

------_=_NextPart_001_01C46912.865DD3F1-- From owner-ietf-openproxy@mail.imc.org Tue Jul 13 16:36:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14401 for ; Tue, 13 Jul 2004 16:36:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkU0w-0007K2-CQ for opes-archive@ietf.org; Tue, 13 Jul 2004 16:36:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkTw0-0005x4-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:31:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkTqd-0004e1-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:25:56 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKEvBr077884; Tue, 13 Jul 2004 13:14:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKEvLS077883; Tue, 13 Jul 2004 13:14:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (wwsmtp.webwasher.com [217.146.159.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKEuV1077865 for ; Tue, 13 Jul 2004 13:14:56 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 0M4HBHIL outgoing id 0M4HBHIL; 13 Jul 2004 22:14:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SMTP or MIME in Strawman OPES Charter Date: Tue, 13 Jul 2004 22:14:43 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D13E0DA@mail.webwasher.com> Thread-Topic: SMTP or MIME in Strawman OPES Charter Thread-Index: AcRpBVSr/UI+JrdvT1qedFZ6fcKGWgADaVgw From: "Martin Stecher" To: "OPES Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6DKEvV1077878 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit > > Jfc seems to re-visit, perhaps unknowingly, a very important > charter-related question that we must finish discussing. Please see > > http://www.imc.org/ietf-openproxy/mail-archive/msg02979.html > > for the start of the thread. In > > http://www.imc.org/ietf-openproxy/mail-archive/msg02982.html > > you said "Similar to what we did in the first charter, we can make > SMTP the prime goal which we'll have to provide a solution for, but we > can first explore the feasibility of a general "email/MIME" profile > (and maybe include an explicit charter item for such exploration)." > > The above direction was supported by Abbie and myself, without > objections. Can we go down that path and include an exploratory > charter item instead of starting with SMTP? It may also simplify > solving the agent-dependency problem for SMTP. We can be more vague > about SMTP if we have to do MIME first! > In earlier discussions we found that MIME is a good fallback when negotiating profiles and no match for a more detailed application is found. So, exploring a MIME profile indeed has some value. On the other hand I think that we must concentrate on SMTP if we want to do OPES for email not MIME or any other email protocol. Most messages in the Internet are transferred using SMTP. POP and IMAP are used to fetch them from a mailbox but they reach the mailbox usually via SMTP. And the SMTP dialog has information that is needed as meta data in addition to the MIME message for effective filtering, for example if you want to check the recipients of a message you better ignore the MIME header but look at the RCPT TO parameters from the SMTP dialog. In addition we should consider that some OPES services may want to adapt the SMTP dialogs, for example control the relay behavior of an MTA (decide which sender is allowed to send to which recipients). That is definetly beyond MIME message filtering. So, I think we should concentrate on OCP/SMTP. As adapting MIME messages is the most important sub part of that we may want to explore that first and design the profile in a way that allows to create an OCP/MIME profile easily by simply deleting all parts that are beyond the MIME message part. Regards Martin From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:02:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17621 for ; Tue, 13 Jul 2004 17:02:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkUQI-0006BN-Ar for opes-archive@ietf.org; Tue, 13 Jul 2004 17:02:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkUKe-0004jn-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:56:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkUEf-0003C6-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:50:45 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKccXg079554; Tue, 13 Jul 2004 13:38:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKccDZ079553; Tue, 13 Jul 2004 13:38:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKcbpc079546 for ; Tue, 13 Jul 2004 13:38:37 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DKcfXJ078543 for ; Tue, 13 Jul 2004 16:38:41 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKcWU1019304 for ; Tue, 13 Jul 2004 16:38:36 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKcVMJ005786 for ; Tue, 13 Jul 2004 16:38:31 -0400 (EDT) Message-ID: <40F4480A.8020200@mhof.com> Date: Tue, 13 Jul 2004 16:37:30 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3E0C3.D85E0082@india.hp.com> <40F3F027.4000208@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > It does not. The problem is with the specific deliverables that seem > to mention just one language specification/document rather that a core > language plus modules approach: > > DATE Initial document on OPES rules language > DATE Submit document on OPES rules language to > IESG for Proposed Standard > > Should we rephrase so that multiple documents are allowed? What about: SEP04 Initial document(s) on OPES rules language MAY05 Submit document(s) on OPES rules language to IESG for Proposed Standard > Sounds like it excludes other protocols from being considered when > designing the core language. How about: > > Define a rules language to control OPES processor selection > and execution of OPES services, including HTTP and SMTP > adaptation services. Let's committ to producing a solution that at least supports HTTP and SMTP, but not more. We aim to define a language that is open to support others as well, but we don't get into trouble if it turns out to be too complex. That's exactly what we did with the protocol in the current charter - we were chartered to define a solution for HTTP. but we were able to come up with an elegent solution that is flexible enough to support other protocols as well. So I'd suggest to stick with "Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services." -Markus PS: I'll go through the reamining comments and will send out an update charter once I got through. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:03:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17693 for ; Tue, 13 Jul 2004 17:03:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkUQb-0006FF-Tw for opes-archive@ietf.org; Tue, 13 Jul 2004 17:03:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkUL2-0004nP-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:57:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkUF8-0003RQ-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:51:14 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKdxQ3079721; Tue, 13 Jul 2004 13:39:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKdxGn079720; Tue, 13 Jul 2004 13:39:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKdwrY079713 for ; Tue, 13 Jul 2004 13:39:58 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DKe01O074293 for ; Tue, 13 Jul 2004 16:40:02 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKdtdj049895 for ; Tue, 13 Jul 2004 16:39:55 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKdtMJ005814 for ; Tue, 13 Jul 2004 16:39:55 -0400 (EDT) Message-ID: <40F4485D.8090705@mhof.com> Date: Tue, 13 Jul 2004 16:38:53 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Then lets fix it! No reason to continue to confuse those who read our > charter (and, hopefully, more folks will discover OPES as our > documents start to gain RFC status). As indicated in earlier email, I agree, which was meant to imply that I changed that. Updated charter to be broadcasted on this channel soon - stay tuned :) -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:09:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18261 for ; Tue, 13 Jul 2004 17:09:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkUWi-0007m7-DX for opes-archive@ietf.org; Tue, 13 Jul 2004 17:09:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkUPG-00060b-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:01:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkUJc-0004YX-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:55:52 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKjQFj080028; Tue, 13 Jul 2004 13:45:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKjQe5080027; Tue, 13 Jul 2004 13:45:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKjPu2080021 for ; Tue, 13 Jul 2004 13:45:25 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DKjTXJ078631 for ; Tue, 13 Jul 2004 16:45:29 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKjOdj050052 for ; Tue, 13 Jul 2004 16:45:24 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKjNMJ006159 for ; Tue, 13 Jul 2004 16:45:23 -0400 (EDT) Message-ID: <40F449A5.1050307@mhof.com> Date: Tue, 13 Jul 2004 16:44:21 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > We are talking about any P program being able to pass any parameters > to any service in scope (e.g., any OCP-speaking or perhaps > WSDL-describable OPES service). Minor personal preference... I don't like talking about "P programs", but rather about "P rules", since the former might get people the impression that P can be used to program actions. > How will P interpreter know what > parameters are available? Which parameters are optional? What are their > types? I consider this out-of-scope for the current work. The author of the rules needs to know about the parameters and their types when writing the rules. For example, when I'm writing rules like if (condition) invoke Service_A(p1, p2, p3) then I assume to know about Service_A and its parameters. How I learn about this is out-of-scope (could be either human interaction or automated). -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:10:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18496 for ; Tue, 13 Jul 2004 17:10:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkUYB-0000Ep-Qg for opes-archive@ietf.org; Tue, 13 Jul 2004 17:10:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkUR2-0006Je-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:03:32 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkULT-0004wm-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 16:57:47 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKleOh080209; Tue, 13 Jul 2004 13:47:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKldba080208; Tue, 13 Jul 2004 13:47:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKldwX080202 for ; Tue, 13 Jul 2004 13:47:39 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DKlhXJ078664 for ; Tue, 13 Jul 2004 16:47:43 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKlcdj050104 for ; Tue, 13 Jul 2004 16:47:38 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKlbMJ006251 for ; Tue, 13 Jul 2004 16:47:38 -0400 (EDT) Message-ID: <40F44A2B.1010506@mhof.com> Date: Tue, 13 Jul 2004 16:46:35 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > May I ask why not? Isn't it a "good practice" to shepherd produced > standards? If the item has no deliverable, would it really increase WG > load? If it has no deliverables, why should it be on the charter? > We do not intend to ignore any OCP/HTTP questions/concerns > coming at us from early adopters, are we? No, they can be brought in in the context of the work items we already have. -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:18:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19567 for ; Tue, 13 Jul 2004 17:18:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkUf7-0001wE-Fg for opes-archive@ietf.org; Tue, 13 Jul 2004 17:18:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkUYf-0000Iw-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:11:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkURk-0006h6-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:04:16 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKrnWP080543; Tue, 13 Jul 2004 13:53:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKrnEN080542; Tue, 13 Jul 2004 13:53:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKrm5c080536 for ; Tue, 13 Jul 2004 13:53:48 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DKrrXJ078703 for ; Tue, 13 Jul 2004 16:53:53 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKrlU1020271 for ; Tue, 13 Jul 2004 16:53:47 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKrlMJ006528 for ; Tue, 13 Jul 2004 16:53:47 -0400 (EDT) Message-ID: <40F44B9B.1070604@mhof.com> Date: Tue, 13 Jul 2004 16:52:43 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3E0C3.D85E0082@india.hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Yes, I like "selection and invocation" better than "selection and > execution". P is really not about execution, just invocation. Once > invoked, services execute on their own, without P participation. P has > no controls to change service execution run-time. P can only select, > configure, "start" or "invoke" a service, and get the result. Agreed, chaned that. -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:20:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19848 for ; Tue, 13 Jul 2004 17:20:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkUhD-0002Yx-4x for opes-archive@ietf.org; Tue, 13 Jul 2004 17:20:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkUbN-00013a-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:14:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkUUP-00077z-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:07:01 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKujNF080689; Tue, 13 Jul 2004 13:56:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKuj7u080688; Tue, 13 Jul 2004 13:56:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKuif6080682 for ; Tue, 13 Jul 2004 13:56:45 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DKunXJ078735 for ; Tue, 13 Jul 2004 16:56:49 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKuidj050307 for ; Tue, 13 Jul 2004 16:56:44 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKuhMJ006646 for ; Tue, 13 Jul 2004 16:56:43 -0400 (EDT) Message-ID: <40F44C4C.5080202@mhof.com> Date: Tue, 13 Jul 2004 16:55:40 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <87AC5F88F03E6249AEA68D40BD3E00BEB48A1A@zcarhxm2.corp.nortel.com> In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BEB48A1A@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Abbie Barbir wrote: >>Just to make sure: which of the following you consider essential: >> >> a) forget about P choice, start from scratch, write a >> formal "language requirements" document, then select among >> IRML, P, and possibly other candidates. >> >> b) confirm past P choice, but write a "language requirements" >> document or section, before proceeding with polishing P >> >> c) confirm P choice, and do not write a "language >> requirements" document/section > > > well, I go for option a) to be frank. However, I can live with b) or c) > if the WG wants that. Are there any new insights or developments that came up after our earlier discussions we had on "P" and other approaches? If not, I don't want to re-iterate the discussions we already had. -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:24:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20330 for ; Tue, 13 Jul 2004 17:24:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkUku-0003Sb-B9 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:24:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkUfU-0001zu-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:18:29 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkUZH-0000Yn-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:12:03 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKquec080512; Tue, 13 Jul 2004 13:52:56 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKqucd080511; Tue, 13 Jul 2004 13:52:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKqtrQ080505 for ; Tue, 13 Jul 2004 13:52:55 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DKr0XJ078694 for ; Tue, 13 Jul 2004 16:53:00 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKqsdj050217 for ; Tue, 13 Jul 2004 16:52:54 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DKqsMJ006506 for ; Tue, 13 Jul 2004 16:52:54 -0400 (EDT) Message-ID: <40F44B67.6030705@mhof.com> Date: Tue, 13 Jul 2004 16:51:51 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: SMTP or MIME in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > you said "Similar to what we did in the first charter, we can make > SMTP the prime goal which we'll have to provide a solution for, but we > can first explore the feasibility of a general "email/MIME" profile > (and maybe include an explicit charter item for such exploration)." > > The above direction was supported by Abbie and myself, without > objections. Can we go down that path and include an exploratory > charter item instead of starting with SMTP? It may also simplify > solving the agent-dependency problem for SMTP. We can be more vague > about SMTP if we have to do MIME first! > > I apologize for not recalling that two-week old e-mail thread earlier. I actually had this in mind... The phrasing we've so far in the strawman charter does *not* preclude us from doing this. I would expect us to explore these options first, just as we did with OCP (without having it mentioned explicitly in the previous charter). Not explicitcly broadening the scope might make it more likely to get the charter accpeted. -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:47:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23197 for ; Tue, 13 Jul 2004 17:47:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkV7q-0000yt-5V for opes-archive@ietf.org; Tue, 13 Jul 2004 17:47:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkV0v-000797-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:40:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkUup-0005sv-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:34:19 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLPO7c083374; Tue, 13 Jul 2004 14:25:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DLPOMx083373; Tue, 13 Jul 2004 14:25:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLPNbc083367 for ; Tue, 13 Jul 2004 14:25:24 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DLPS1O074629 for ; Tue, 13 Jul 2004 17:25:28 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DLPMU1021522 for ; Tue, 13 Jul 2004 17:25:23 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DLPMMJ007670 for ; Tue, 13 Jul 2004 17:25:22 -0400 (EDT) Message-ID: <40F452FE.8080509@mhof.com> Date: Tue, 13 Jul 2004 17:24:14 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> In-Reply-To: <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit jfcm wrote: >> So far, we've specified a OCP/HTTP profile that supports services >> operating on HTTP messages. >> Now we specify a OCP/SMTP profile that supports services operating on >> SMTP messages. > > > This is why the same phrasing should be used. Here's what we've in currently proposed charter" So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. and [...] the WG will specify one or more OCP profiles that will support applications operating on SMTP messages. I think this is exactly what I describe above and you agreed on, so we're in agreement here. > The answer does not match the question. In one to one direct access > http, I know who are the parties. I one to many possibly rerouted > mailing I do not know what you mean by parties. Has to be clarified > otherwise the whole thing will be opposed on security grounds. Hm, you bring up a good point. For example, your asking who are the endpoints when I send an email to a mailing list, right? I've one source endpoint, but multiple destination endpoints. So it's not sufficient if only one of the endpoints authorizes a service. Now, in case of this example, sending to the mailing list results basically in multiple transmissions to individuals, in which case we're back to a scenario with two endpoints. Any thoughts from anyone? >> That is meant to say "...HTTP or SMTP messages". Will change that. > > > I am not sure about what you mean in this as SMTP Messages when you > refer to HTTP Messages. You will find that SMTP will probably used in > OPES related application as application signal and message transport. > Even if you do not want to take theses mechanisms in consideration, what > IMHO removes a lot of interest to effort when you consider real life > applications - for example spam fighting, I suggest a clearer wording to > avoid this confusion. Not sure whether I understood the above, but the wording now is "Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services." which I would assumeto be adequatly clear. -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:50:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23780 for ; Tue, 13 Jul 2004 17:50:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkVAE-0001dU-Eg for opes-archive@ietf.org; Tue, 13 Jul 2004 17:50:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkV4O-0000Ae-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:44:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkUwm-0006Fi-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:36:20 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLQo74083405; Tue, 13 Jul 2004 14:26:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DLQoaO083404; Tue, 13 Jul 2004 14:26:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLQncI083398 for ; Tue, 13 Jul 2004 14:26:50 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6DLQsXJ078978 for ; Tue, 13 Jul 2004 17:26:54 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DLQndj051383 for ; Tue, 13 Jul 2004 17:26:49 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6DLQmMJ007700 for ; Tue, 13 Jul 2004 17:26:49 -0400 (EDT) Message-ID: <40F45354.4030808@bell-labs.com> Date: Tue, 13 Jul 2004 17:25:40 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Updated Stawman OPES Charter Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, below and updated strawman charter based on discussions so far. Hope I catched the discussion topics. -Markus ================================================ Open Pluggable Edge Services (opes) ----------------------------------- Chair(s): Markus Hofmann Applications Area Director(s): Ted Hardie Scott Hollenbeck Applications Area Advisor: Ted Hardie Technical Advisor(s): Allison Mankin Hilarie Orman Mailing Lists: General Discussion: ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Archive: http://www.imc.org/ietf-openproxy/mail-archive/ Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and improve the user experience. Web proxies, for example, are commonly deployed to provide services such as Web caching, virus scanning, and request filtering. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The OPES Working Group has previously developed an architectural framework to authorize, invoke, and trace such application-level services. The framework follows a one-party consent model, which requires that each service be authorized explicitly by at least one of the application-layer endpoints. It further requires that OPES services are reversible by mutual agreement of the application endpoints. In particular, the WG has developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. In a next step, the WG will specify one or more OCP profiles that will support applications operating on SMTP messages. In particular, the profile to be specified will enable an OPES processor to encapsulate and forward SMTP messages (or parts thereof) to a callout server for additional processing. Several kinds of agents participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP profile will address the needs of at least the XXX SMTP agent. More profiles may be needed to address other agent-specific needs. In addition, the WG will define a rules language to control selection and invocation of services by an OPES processor. Defining language(s) for implementing OPES services is out of the WG scope. The rules language will be based on previous work of the WG on a rule language named "P". The working group will have a design goal that the method be compatible with existing policy work within the IETF (e.g. IETF Policy Framework)and be able to interface with systems automating distribution of policies to multiple endpoints. It will be out of scope for this WG to develop the policy framework and specify multiple-endpoint policy distribution. The group's new work items can be listed as: - Define a SMTP profile(s) to supplement OCP core. - Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services. Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Goals and Milestones: Done Submit OPES scenarios document and architecture document to IESG for Informational. Done Submit document on protocol (callout and tracing) requirements to IESG for Informational. Done Submit document on endpoint authorization and enforcement requirements to IESG for Informational. Done Submit document on threat/risk model for OPES services to IESG for Informational. Done Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization. Done Initial document on rules specification method. Done Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard. SEP04 Initial document on OPES rules language NOV04 Initial document on SMTP adaptation profile for XXX agent and possibly other agents. NOV04 Decision on what other SMTP agents, if any, the WG should work on. FEB05 Submit document on SMTP adaptation profile for XXX agent and possibly other agents. MAR05 Submit document(s) on SMTP adaptation profile(s) for those other agents the WG has decided to work on, if any. MAY05 Submit document on OPES rules language to IESG for Proposed Standard From owner-ietf-openproxy@mail.imc.org Tue Jul 13 17:54:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24325 for ; Tue, 13 Jul 2004 17:54:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkVER-0002XC-2z for opes-archive@ietf.org; Tue, 13 Jul 2004 17:54:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkVA4-0001br-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:50:05 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkV45-000070-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 17:43:53 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLXHlc083886; Tue, 13 Jul 2004 14:33:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DLXHnm083885; Tue, 13 Jul 2004 14:33:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLXHLx083877 for ; Tue, 13 Jul 2004 14:33:17 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6DLXD615526; Tue, 13 Jul 2004 17:33:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jul 2004 17:33:14 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEB48AF6@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: Strawman OPES Charter Date: Tue, 13 Jul 2004 17:34:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46920.FF02CDD4" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46920.FF02CDD4 Content-Type: text/plain MArkus, new insights are comming as we speak. but as I said I can live with the other options abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, July 13, 2004 4:56 PM > To: OPES Group > Subject: Re: Strawman OPES Charter > > > > Abbie Barbir wrote: > > >>Just to make sure: which of the following you consider essential: > >> > >> a) forget about P choice, start from scratch, write a > >> formal "language requirements" document, then select among > >> IRML, P, and possibly other candidates. > >> > >> b) confirm past P choice, but write a "language requirements" > >> document or section, before proceeding with polishing P > >> > >> c) confirm P choice, and do not write a "language > >> requirements" document/section > > > > > > well, I go for option a) to be frank. However, I can live > with b) or > > c) if the WG wants that. > > Are there any new insights or developments that came up after our > earlier discussions we had on "P" and other approaches? If not, I > don't want to re-iterate the discussions we already had. > > -Markus > > ------_=_NextPart_001_01C46920.FF02CDD4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Strawman OPES Charter

MArkus,

new insights are comming as we speak.
but as I said I can live with the other = options

abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, July 13, 2004 4:56 PM
> To: OPES Group
> Subject: Re: Strawman OPES Charter
>
>
>
> Abbie Barbir wrote:
>
> >>Just to make sure: which of the = following you consider essential:
> >>
> >>      a) = forget about P choice, start from scratch, write a
> = >>         formal = "language requirements" document, then select among
> = >>         IRML, P, and = possibly other candidates.
> >>
> >>      b) = confirm past P choice, but write a "language requirements" =
> = >>         document or = section, before proceeding with polishing P
> >>
> >>      c) = confirm P choice, and do not write a "language
> = >>         = requirements" document/section
> >
> >
> > well, I go for option a) to be frank. = However, I can live
> with b) or
> > c) if the WG wants that.
>
> Are there any new insights or developments that = came up after our
> earlier discussions we had on "P" and = other approaches? If not, I
> don't want to re-iterate the discussions we = already had.
>
> -Markus
>
>

------_=_NextPart_001_01C46920.FF02CDD4-- From owner-ietf-openproxy@mail.imc.org Tue Jul 13 19:37:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08609 for ; Tue, 13 Jul 2004 19:37:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkWqG-0006Ed-P0 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:37:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkWje-0004Yz-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:30:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkWcx-0002rc-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:23:59 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNEIiI090920; Tue, 13 Jul 2004 16:14:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DNEIU4090919; Tue, 13 Jul 2004 16:14:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNEHJl090913 for ; Tue, 13 Jul 2004 16:14:17 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DNEM9d004306; Tue, 13 Jul 2004 17:14:22 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DNEMA0004305; Tue, 13 Jul 2004 17:14:22 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 17:14:22 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter In-Reply-To: <40F449A5.1050307@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F449A5.1050307@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > > How will P interpreter know what parameters are available? Which > > parameters are optional? What are their types? > > I consider this out-of-scope for the current work. The author of the > rules needs to know about the parameters and their types when writing > the rules. > > For example, when I'm writing rules like > > if (condition) > invoke Service_A(p1, p2, p3) > > then I assume to know about Service_A and its parameters. How I learn > about this is out-of-scope (could be either human interaction or > automated). I am not sure you can get away with this without making a major sacrifice. I agree that how _you_ learned about the parameters is out of scope. However, P interpreter has to check your rules and translate them into specific OCP messages. To do that, it needs to know what parameters Service_A has (by name or position), which of them are optional, and what their types are. You can say that the programmer will supply parameter names and/or use much more dangerous positional notation. While technically possible, it would make it impossible to check your rule set for correctness without executing it. For example, if P interpreter does not know that Service_A only has two parameters, then P interpreter cannot tell you that the above code snippet with Service_A(p1, p2, p3) is buggy. Only the service can, at runtime. Same for parameter types. You can get away with trusting the programmer to supply the right types, but in reality that means that a P interpreter will not be able to detect a type mismatch. invoke Service_A(p1, p2, p3); or invoke Service_A(p2, p1, p3); will all look the same to the interpreter (but not to the service!). We know how poor humans are at writing bug-free code. I think that being able to validate much of P code off-line is an essential rule language feature that we should strive to preserve. Unfortunately, that seems to require informing the interpreter of service interface, independent of P code itself. Can we have a safe/validate-able service invocation without the knowledge of service interfaces (service "feature" definition in terms of OCP)? Thanks, Alex. P.S. If P programs are "rules", what should we call P programmers? Rulers? :-) From owner-ietf-openproxy@mail.imc.org Tue Jul 13 19:40:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09032 for ; Tue, 13 Jul 2004 19:40:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkWt0-0006ih-R5 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:40:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkWmV-00059I-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:33:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkWfo-0003TA-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:26:56 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNIiVk091278; Tue, 13 Jul 2004 16:18:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DNIiuw091277; Tue, 13 Jul 2004 16:18:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNIhke091271 for ; Tue, 13 Jul 2004 16:18:43 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DNIm9d004706; Tue, 13 Jul 2004 17:18:48 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DNImLP004705; Tue, 13 Jul 2004 17:18:48 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 17:18:48 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Strawman OPES Charter In-Reply-To: <40F44A2B.1010506@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F44A2B.1010506@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > Alex Rousskov wrote: > > > May I ask why not? Isn't it a "good practice" to shepherd produced > > standards? If the item has no deliverable, would it really increase WG > > load? > > If it has no deliverables, why should it be on the charter? So that folks external to the WG (e.g., OCP implementers) know that they have come to the right place when searching for help/advice. Some would assume that, but some might not. And so that we can offer that advice/help on the mailing list, without being told that it is out of our charter scope. > > We do not intend to ignore any OCP/HTTP questions/concerns > > coming at us from early adopters, are we? > > No, they can be brought in in the context of the work items we > already have. But we will not have any work items in OCP/HTTP context. It is not a big issue for me, especially since IETF does not usually do protocol maintenance (unfortunately), but I think it would be a good idea to add the blob, even without any specific deliverables. The deliverable, in this case, is a service to the community, to the protocol implementors and such. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 19:52:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10520 for ; Tue, 13 Jul 2004 19:52:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkX4L-0001us-LQ for opes-archive@ietf.org; Tue, 13 Jul 2004 19:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkWzD-0000cu-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:47:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkWtT-0006uh-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:41:03 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNVjTU092421; Tue, 13 Jul 2004 16:31:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DNVj3C092420; Tue, 13 Jul 2004 16:31:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNVioR092413 for ; Tue, 13 Jul 2004 16:31:44 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DNVn9d005919; Tue, 13 Jul 2004 17:31:49 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DNVneq005918; Tue, 13 Jul 2004 17:31:49 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 17:31:49 -0600 (MDT) From: Alex Rousskov To: Martin Stecher cc: OPES Group Subject: RE: SMTP or MIME in Strawman OPES Charter In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D13E0DA@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D13E0DA@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Martin Stecher wrote: > In earlier discussions we found that MIME is a good fallback when > negotiating profiles and no match for a more detailed application is > found. So, exploring a MIME profile indeed has some value. > > On the other hand I think that we must concentrate on SMTP if we > want to do OPES for email not MIME or any other email protocol. > > Most messages in the Internet are transferred using SMTP. POP > and IMAP are used to fetch them from a mailbox but they reach > the mailbox usually via SMTP. Is it reasonable to assume that, due to differences in user agents (e.g., PC versus phone), folks will want to adapt stored messages when they know IMAP or POP client preferences (rather then when the message is received by SMTP server)? > And the SMTP dialog has information that is needed as meta data in > addition to the MIME message for effective filtering, for example if > you want to check the recipients of a message you better ignore the > MIME header but look at the RCPT TO parameters from the SMTP dialog. Yes, it is clear that MIME alone is not sufficient for some (most?) adaptations of e-mails. It is only a common denominator among SMTP, ICAP, POP. > In addition we should consider that some OPES services may want > to adapt the SMTP dialogs, for example control the relay behavior > of an MTA (decide which sender is allowed to send to which recipients). > That is definetly beyond MIME message filtering. This is very important, I guess. Should we decide now whether SMTP commands adaptation is in scope (as opposed to SMTP message adaptation). > So, I think we should concentrate on OCP/SMTP. As adapting MIME > messages is the most important sub part of that we may want to > explore that first and design the profile in a way that allows to > create an OCP/MIME profile easily by simply deleting all parts that > are beyond the MIME message part. I see your point (and glad that you are back from vacation!). I have not decided yet. What are we really trying to optimize here: Do you think we will waste a lot of time if we define a common OCP/MIME profile (that alone will not be useful for some adaptations) and then build OCP/SMTP profile on top of that (as opposed to building one monolithic OCP/SMTP profile)? Or do you think that defining a common OCP/MIME profile is simply useless because nobody cares enough about IMAP and POP (and so nobody will reuse the common profile). Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 19:56:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11035 for ; Tue, 13 Jul 2004 19:56:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkX8c-00038B-Qm for opes-archive@ietf.org; Tue, 13 Jul 2004 19:56:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkX35-0001iO-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:51:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkWy2-0000JP-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 19:45:46 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNa3rK092702; Tue, 13 Jul 2004 16:36:03 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DNa3TV092701; Tue, 13 Jul 2004 16:36:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNa2JM092695 for ; Tue, 13 Jul 2004 16:36:02 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6DNa59d006324; Tue, 13 Jul 2004 17:36:05 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6DNa4Dr006323; Tue, 13 Jul 2004 17:36:04 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 17:36:04 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Updated Stawman OPES Charter In-Reply-To: <40F45354.4030808@bell-labs.com> Message-ID: References: <40F45354.4030808@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > In addition, the WG will define a rules language to control selection > and invocation of services by an OPES processor. Defining language(s) > for implementing OPES services is out of the WG scope. The rules > language will be based on previous work of the WG on a rule language > named "P". > The working group will have a design goal that the method be > compatible with existing policy work within the IETF s/the method/the language/ Other than that, and the pending MIME/SMTP issue, the revision looks good! Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 13 21:51:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24351 for ; Tue, 13 Jul 2004 21:51:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkYvI-00028P-27 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:51:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkYY3-0005LH-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:27:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkYGV-0001oB-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:08:55 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E0vmna000624; Tue, 13 Jul 2004 17:57:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E0vmCZ000623; Tue, 13 Jul 2004 17:57:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E0vll0000617 for ; Tue, 13 Jul 2004 17:57:47 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6E0vrXJ080200 for ; Tue, 13 Jul 2004 20:57:53 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6E0vlU1029064 for ; Tue, 13 Jul 2004 20:57:48 -0400 (EDT) Received: from [127.0.0.1] ([135.104.20.72]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6E0vdMK012765 for ; Tue, 13 Jul 2004 20:57:46 -0400 (EDT) Message-ID: <40F484FF.3030905@mhof.com> Date: Tue, 13 Jul 2004 20:57:35 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F449A5.1050307@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > We know how poor humans are at writing bug-free code. I think that > being able to validate much of P code off-line is an essential rule > language feature that we should strive to preserve. Unfortunately, > that seems to require informing the interpreter of service interface, > independent of P code itself. You start convincing me... Could any of the existing service description languages (WSDL?) be of help? Abbie was suggesting this before I believe... I see the following options: (1) Rely on the rules authors to specify the correct parameters and don't do any offline checking -> no mechanisms for service description needed (2) Have an OPES specific "service interface description language" (maybe similar to function declarations in some programming languages?) -> would be part of the rules language (?) (3) Rely on an existing solution and require OPES services to be described in this language -> nothing to do for us other than refering to existing solution. Now, my feeling this that this already goes into discussing the solution, I don't see a need to specify any of this in the re-charter. The proposed charter text seems to cover and allow for this work, so I would assume we're ok in this respect. > P.S. If P programs are "rules", what should we call P programmers? > Rulers? :-) Sure, OPES rules :) -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 22:12:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27615 for ; Tue, 13 Jul 2004 22:12:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkZGH-0006Je-GB for opes-archive@ietf.org; Tue, 13 Jul 2004 22:12:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkYrY-0001Rv-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:47:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkYT2-0004Ry-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:21:52 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E1ARnp002011; Tue, 13 Jul 2004 18:10:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E1AREe002010; Tue, 13 Jul 2004 18:10:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E1AQ4d002004 for ; Tue, 13 Jul 2004 18:10:26 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6E1AVXJ080277 for ; Tue, 13 Jul 2004 21:10:31 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6E1AQdj059018 for ; Tue, 13 Jul 2004 21:10:26 -0400 (EDT) Received: from [127.0.0.1] ([135.104.20.72]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6E1ANMK013111 for ; Tue, 13 Jul 2004 21:10:26 -0400 (EDT) Message-ID: <40F487FB.8010605@bell-labs.com> Date: Tue, 13 Jul 2004 21:10:19 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: SMTP or MIME in Strawman OPES Charter References: <75F7E67FC45F6744A7D328D41E35376D13E0DA@mail.webwasher.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Is it reasonable to assume that, due to differences in user agents > (e.g., PC versus phone), folks will want to adapt stored messages when > they know IMAP or POP client preferences (rather then when the message > is received by SMTP server)? Even if so, let's focus our new charter on SMTP, and we'll have a much better chance to get it accepted. This does no preclude us from coming up with a solution that might also be useful in the context of IMAP, POP or other protocols, but the charter will not require this. Just what we did with the initial focus on HTTP and coming up with OCP core. > This is very important, I guess. Should we decide now whether SMTP > commands adaptation is in scope (as opposed to SMTP message > adaptation). Can someone give a specific example/use case for SMTP commands adaptation ? > I see your point (and glad that you are back from vacation!). I have > not decided yet. What are we really trying to optimize here: Do you > think we will waste a lot of time if we define a common OCP/MIME > profile (that alone will not be useful for some adaptations) and then > build OCP/SMTP profile on top of that (as opposed to building one > monolithic OCP/SMTP profile)? Or do you think that defining a common > OCP/MIME profile is simply useless because nobody cares enough about > IMAP and POP (and so nobody will reuse the common profile). I don't expect the new charter to make any statements in this regard (charter will only request a SMTP profile), so let's first get our new charter nailed down and we can then start discussing these details, ok? -Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 22:21:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28595 for ; Tue, 13 Jul 2004 22:21:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkZP0-000017-Lk for opes-archive@ietf.org; Tue, 13 Jul 2004 22:21:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkYz4-0002nv-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:55:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BkYc2-000639-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:31:10 -0400 Received: from above.proper.com ([208.184.76.39]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BkYZ1-0005PT-W8 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:28:04 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E1IEZ4002610; Tue, 13 Jul 2004 18:18:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E1IEid002609; Tue, 13 Jul 2004 18:18:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E1IDxR002601 for ; Tue, 13 Jul 2004 18:18:13 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6E1IJ1O075957 for ; Tue, 13 Jul 2004 21:18:19 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6E1IEdj059249 for ; Tue, 13 Jul 2004 21:18:14 -0400 (EDT) Received: from [127.0.0.1] ([135.104.20.72]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6E1IBMK013284 for ; Tue, 13 Jul 2004 21:18:13 -0400 (EDT) Message-ID: <40F489D2.5050102@bell-labs.com> Date: Tue, 13 Jul 2004 21:18:10 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Which SMTP element? References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> In-Reply-To: <40F3ECCD.2030703@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, what we need to solve now is the issue with respect to "what SMTP element to focus on first", and whether distinguishing between SMTP elements makes sense - see below from earlier emails. >> And then add something like "Several kinds of agents participate in >> SMTP exchanges, including MSA, MTA, MDA, and MUA. The first SMTP >> adaptation profile will address the needs of at least the XXX SMTP >> agent. More profiles may be needed to address other agent-specific >> needs." I do not know what agent should replace XXX placeholder above. > > > Do we believe that the role of a SMTP element will have any impact on > the OCP profile(s)? > > I guess until we know for sure the proposal aboce makes sense. I'll put > the proposed text in the draft charter for now. > > Martin - since you've been implementing iCAP-based SMTP forwarding > already, what SMTP element would you suggest, what's needed first? What > makes sense? So, following questions: (a) Does it make sense to distinguish between different SMTP roles? (b) If the answer to (a) us 'yes', what role should we focus on first, i.e. where's the most practical need? Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Jul 13 22:24:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29101 for ; Tue, 13 Jul 2004 22:24:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkZRX-0000T7-5z for opes-archive@ietf.org; Tue, 13 Jul 2004 22:24:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkZ1v-0003NU-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:57:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkYd2-0006II-00 for opes-archive@ietf.org; Tue, 13 Jul 2004 21:32:12 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E1DU2q002208; Tue, 13 Jul 2004 18:13:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E1DUVT002207; Tue, 13 Jul 2004 18:13:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E1DTTp002195 for ; Tue, 13 Jul 2004 18:13:29 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6E1DW1O075929 for ; Tue, 13 Jul 2004 21:13:33 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6E1DRdj059090 for ; Tue, 13 Jul 2004 21:13:27 -0400 (EDT) Received: from [127.0.0.1] ([135.104.20.72]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6E1DOMK013200 for ; Tue, 13 Jul 2004 21:13:27 -0400 (EDT) Message-ID: <40F488B0.70805@bell-labs.com> Date: Tue, 13 Jul 2004 21:13:20 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Updated Stawman OPES Charter References: <40F45354.4030808@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > s/the method/the language/ Thanks, made that change. > Other than that, and the pending MIME/SMTP issue, the revision looks > good! We're getting close... Thanks, Markus From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:14:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22475 for ; Wed, 14 Jul 2004 01:14:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkc5p-0006Fb-C8 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:14:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkbsP-0003f3-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:00:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkbSf-0006ll-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 00:33:42 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4OBhg016123; Tue, 13 Jul 2004 21:24:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E4OBTE016122; Tue, 13 Jul 2004 21:24:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4O8RE016116 for ; Tue, 13 Jul 2004 21:24:08 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel13.hp.com (Postfix) with ESMTP id BF9C01C06E41; Tue, 13 Jul 2004 21:24:13 -0700 (PDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id JAA01183; Wed, 14 Jul 2004 09:54:22 +0530 (IST) Message-ID: <40F4B508.294D6D83@india.hp.com> Date: Wed, 14 Jul 2004 09:52:32 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: Markus Hofmann , OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > On Tue, 13 Jul 2004, Markus Hofmann wrote: > > > Alex Rousskov wrote: > > > > > - Defining an interface between rules language > > > and service (at least OCP-speaking service) > > > How to pass parameters to services? How to > > > get the result of service application, including > > > errors, back to the language/program? > > > > I would consider passing of parameters and getting results back into > > the language/program in scope. Any other thoughts? > > I agree. Supporting just that in a general way is already difficult! > > We are talking about any P program being able to pass any parameters > to any service in scope (e.g., any OCP-speaking or perhaps > WSDL-describable OPES service). How will P interpreter know what > parameters are available? Which parameters are optional? What are their > types? > > Alex, Won't that info be available while "discovering a service" ie., your (following) first addendum item ? - Defining how available services become known to the rules language interpreter? (At least OCP-speaking services) regards Geetha From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:14:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22542 for ; Wed, 14 Jul 2004 01:14:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkc6D-0006JP-G5 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:14:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkbsw-0003ko-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:00:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkbUD-00073N-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 00:35:17 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4RNXo016368; Tue, 13 Jul 2004 21:27:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E4RN3N016367; Tue, 13 Jul 2004 21:27:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4QnKN016323 for ; Tue, 13 Jul 2004 21:27:23 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by atlrel9.hp.com (Postfix) with ESMTP id 14BAD10BC15; Tue, 13 Jul 2004 22:26:54 -0600 (MDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id JAA01712; Wed, 14 Jul 2004 09:57:07 +0530 (IST) Message-ID: <40F4B5AD.FD12618B@india.hp.com> Date: Wed, 14 Jul 2004 09:55:17 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann Cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F449A5.1050307@mhof.com> <40F484FF.3030905@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Markus Hofmann wrote: > You start convincing me... Could any of the existing service > description languages (WSDL?) be of help? Abbie was suggesting this > before I believe... > > Now, my feeling this that this already goes into discussing the > solution, I don't see a need to specify any of this in the re-charter. > The proposed charter text seems to cover and allow for this work, so I > would assume we're ok in this respect Agreed! From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:14:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22560 for ; Wed, 14 Jul 2004 01:14:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkc6F-0006Jx-Tj for opes-archive@ietf.org; Wed, 14 Jul 2004 01:14:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkbt2-0003m2-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:00:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkbUU-00076E-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 00:35:34 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4Rlvi016434; Tue, 13 Jul 2004 21:27:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E4RltZ016433; Tue, 13 Jul 2004 21:27:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4RkF5016427 for ; Tue, 13 Jul 2004 21:27:46 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6E4Rr9d029651; Tue, 13 Jul 2004 22:27:53 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6E4Rr4x029650; Tue, 13 Jul 2004 22:27:53 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 22:27:53 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter In-Reply-To: <40F484FF.3030905@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F449A5.1050307@mhof.com> <40F484FF.3030905@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > Alex Rousskov wrote: > > > We know how poor humans are at writing bug-free code. I think that > > being able to validate much of P code off-line is an essential rule > > language feature that we should strive to preserve. Unfortunately, > > that seems to require informing the interpreter of service interface, > > independent of P code itself. > > You start convincing me... Could any of the existing service > description languages (WSDL?) be of help? Abbie was suggesting this > before I believe... Yes, and (after reading the corresponding Content Networking chapter:), I also suspect that we can reuse WSDL core. This will require some serious work on our part though. Current WSDL profiles are based on SOAP and MIME(?), not OCP. We will have to define an OCP-specific profile and then define how WSDL/OCP can be used to describe OCP-speaking services for P interpreters. I can see benefits, but I do not know whether the whole scheme will work -- it all depends on how flexible WSDL core is, how many W3C-centric assumptions are in that core. Since this is not a trivial exercise, it may be a good idea to add P-services interface as a chartered work item, possibly without a separate deliverable since we already have multiple "document(s)" for P-related specs. > I see the following options: > > (1) Rely on the rules authors to specify the correct parameters > and don't do any offline checking -> no mechanisms for service > description needed > (2) Have an OPES specific "service interface description language" > (maybe similar to function declarations in some programming > languages?) -> would be part of the rules language (?) Yes. > (3) Rely on an existing solution and require OPES services to be > described in this language -> nothing to do for us other than > refering to existing solution. ... Other than defining how to apply that existing solution (e.g., WSDL) to OCP-speaking services. AFAIK, OCP-speaking services cannot be described using any existing WSDL profile. We will need to build one. This makes (2) and (3) equivalent, unless (2) assumes service interface declaration *in P*. Declaring services natively in P is good because it does not require P interpreter to know another language/interface like WSDL. Declaring services in WSDL is good because it allows P interpreter to easily interoperate with both classic Web Services speaking SOAP and OCP-speaking services (in theory). Ideally, you want to obtain the declaration from another, independent source. In case of Java or C++, that source would be a library header/interface file. If we use P declarations, we can encourage service writers to supply them off-line (just like C library writers supply header files with the library) and even runtime via OCP (to kill buggy invocation calls before they generate data traffic on the wire). > Now, my feeling this that this already goes into discussing the > solution, I don't see a need to specify any of this in the > re-charter. The proposed charter text seems to cover and allow for > this work, so I would assume we're ok in this respect. I am worried that if we want to define WSDL profile for OCP, some of us (or some of IESG) will find that extending W3C technology like WSDL is out of current charter scope. We do not know whether using WSDL is the right way to go, but should we just mention that we need to Define P-services interface, based on existing interface description standards like WSDL, if possible, or OPES-specific description otherwise. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:16:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22908 for ; Wed, 14 Jul 2004 01:16:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkc85-0006cu-Tt for opes-archive@ietf.org; Wed, 14 Jul 2004 01:16:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkbx5-0004J8-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:05:08 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkbaM-0000WV-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 00:41:38 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4WONp016851; Tue, 13 Jul 2004 21:32:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E4WOTv016850; Tue, 13 Jul 2004 21:32:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4WNB8016844 for ; Tue, 13 Jul 2004 21:32:23 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6E4WS9d030057; Tue, 13 Jul 2004 22:32:28 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6E4WScA030056; Tue, 13 Jul 2004 22:32:28 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 22:32:28 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: SMTP or MIME in Strawman OPES Charter In-Reply-To: <40F487FB.8010605@bell-labs.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D13E0DA@mail.webwasher.com> <40F487FB.8010605@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Markus, I am fine with postponing this discussion until the new charter is approved, with understanding that the new charter does not limit our option to developing a basic OCP/MIME profile as a foundation of OCP/SMTP. Alex. On Tue, 13 Jul 2004, Markus Hofmann wrote: > > Alex Rousskov wrote: > > > Is it reasonable to assume that, due to differences in user agents > > (e.g., PC versus phone), folks will want to adapt stored messages when > > they know IMAP or POP client preferences (rather then when the message > > is received by SMTP server)? > > Even if so, let's focus our new charter on SMTP, and we'll have a much > better chance to get it accepted. This does no preclude us from coming > up with a solution that might also be useful in the context of IMAP, > POP or other protocols, but the charter will not require this. Just > what we did with the initial focus on HTTP and coming up with OCP core. > > > This is very important, I guess. Should we decide now whether SMTP > > commands adaptation is in scope (as opposed to SMTP message > > adaptation). > > Can someone give a specific example/use case for SMTP commands > adaptation ? > > > I see your point (and glad that you are back from vacation!). I have > > not decided yet. What are we really trying to optimize here: Do you > > think we will waste a lot of time if we define a common OCP/MIME > > profile (that alone will not be useful for some adaptations) and then > > build OCP/SMTP profile on top of that (as opposed to building one > > monolithic OCP/SMTP profile)? Or do you think that defining a common > > OCP/MIME profile is simply useless because nobody cares enough about > > IMAP and POP (and so nobody will reuse the common profile). > > I don't expect the new charter to make any statements in this regard > (charter will only request a SMTP profile), so let's first get our new > charter nailed down and we can then start discussing these details, ok? > > -Markus > > From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:19:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23546 for ; Wed, 14 Jul 2004 01:19:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkcB6-0007f3-HM for opes-archive@ietf.org; Wed, 14 Jul 2004 01:19:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkc5V-0006Br-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:13:50 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkbrV-0003UA-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 00:59:21 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4nLjs018552; Tue, 13 Jul 2004 21:49:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E4nLb0018551; Tue, 13 Jul 2004 21:49:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4nLJ5018545 for ; Tue, 13 Jul 2004 21:49:21 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by atlrel7.hp.com (Postfix) with ESMTP id D4F29A7; Wed, 14 Jul 2004 00:49:25 -0400 (EDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id KAA05472; Wed, 14 Jul 2004 10:19:37 +0530 (IST) Message-ID: <40F4BAF4.1505C7A1@india.hp.com> Date: Wed, 14 Jul 2004 10:17:48 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: Markus Hofmann , OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3E0C3.D85E0082@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > ... unless we want to expand P scope to affect things like preview > size dynamically, while the data is being retrieved from the network. > We will be able to control service _execution_ then. I am sure this is right. If the service is say, "virus scanning", by changing the preview size of the stream being sent, you cannot probably tell the scanner to change its execution path . On the other hand, the OPES service may be able to dictate the preview size required for it to function.. Basically, it will boil down to negotiation over the callout protocol . thanks and regards Geetha From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:21:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23947 for ; Wed, 14 Jul 2004 01:21:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkcCj-00009c-5a for opes-archive@ietf.org; Wed, 14 Jul 2004 01:21:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkc8V-0006o0-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:16:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkby8-0004Ul-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:06:12 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4vPgH019337; Tue, 13 Jul 2004 21:57:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E4vOaI019336; Tue, 13 Jul 2004 21:57:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4vMjc019327 for ; Tue, 13 Jul 2004 21:57:24 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6E4vQ9d032078; Tue, 13 Jul 2004 22:57:26 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6E4vQXD032077; Tue, 13 Jul 2004 22:57:26 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 22:57:26 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Which SMTP element? In-Reply-To: <40F489D2.5050102@bell-labs.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F489D2.5050102@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 13 Jul 2004, Markus Hofmann wrote: > what we need to solve now is the issue with respect to "what SMTP > element to focus on first", and whether distinguishing between SMTP > elements makes sense - see below from earlier emails. > ... > So, following questions: > > (a) Does it make sense to distinguish between different SMTP roles? For those like me, fuzzy on MUA, MSA, MTA, and MDA definitions, here is some text I found (please post better references if available!) RFC 2821 says: SMTP servers and clients provide a mail transport service and therefore act as "Mail Transfer Agents" (MTAs). "Mail User Agents" (MUAs or UAs) are normally thought of as the sources and targets of mail. At the source, an MUA might collect mail to be transmitted from a user and hand it off to an MTA; the final ("delivery") MTA would be thought of as handing the mail off to an MUA (or at least transferring responsibility to it, e.g., by depositing the message in a "message store"). However, while these terms are used with at least the appearance of great precision in other environments, the implied boundaries between MUAs and MTAs often do not accurately match common, and conforming, practices with Internet mail. Hence, the reader should be cautious about inferring the strong relationships and responsibilities that might be implied if these terms were used elsewhere. http://www.ietf.org/internet-drafts/draft-hutzler-spamops-00.txt says: The Internet email architecture distinguishes four message-handling components: o Mail User Agents (MUAs) o Mail Submission Agents (MSAs) o Mail Transfer Agents (MTAs) o Mail Delivery Agents (MDAs) At the origination end, an MUA works on behalf of end-users to create a message and performs initial "submission" into the transmission infrastructure, via an MSA. An MSA accepts the message submission, performs any necessary pre- processing on the message and relays the message to an MTA for transmission. MTAs relay messages to other MTAs, in a sequence reaching a destination MDA that, in turn, delivers the email to the recipient's inbox. The inbox is part of the recipient-side MUA that works on behalf of the end-user to process received mail. These architectural components are often compressed, such as having the same software do MSA, MTA and MDA functions. However the requirements for each of these components of the architecture are becoming more extensive, so that their separation is increasingly common. Given the above, I think MTA is an appropriate first target. Since we are OPES, we should be looking for an intermediary here. Targeting MUAs would be like targeting browsers in OCP/HTTP profile, right? The latter is not theoretically inappropriate (nobody can clearly define what an intermediary or "edge" is), but also not important enough for OPES right now. Moreover, could we try to simplify the charter by removing all other SMTP agents from it? Can we just hope that OCP/SMTP profile with a focus on MTAs will be applicable enough to MSAs and MDAs? We can always add MSA- or MDA-specific features later, right? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:22:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24131 for ; Wed, 14 Jul 2004 01:22:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkcDe-0000Zx-B2 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:22:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkc9t-0007Bs-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:18:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkc3k-0005nl-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:12:00 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E527oU020035; Tue, 13 Jul 2004 22:02:07 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E527jv020034; Tue, 13 Jul 2004 22:02:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E527OZ020027 for ; Tue, 13 Jul 2004 22:02:07 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by atlrel9.hp.com (Postfix) with ESMTP id 00F06322C0; Tue, 13 Jul 2004 23:02:09 -0600 (MDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id KAA08962; Wed, 14 Jul 2004 10:32:21 +0530 (IST) Message-ID: <40F4BDEF.3707FE86@india.hp.com> Date: Wed, 14 Jul 2004 10:30:31 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Abbie Barbir Cc: Markus Hofmann , OPES Group Subject: Re: Strawman OPES Charter References: <87AC5F88F03E6249AEA68D40BD3E00BEB48AF6@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit A completely different alternative for the rules language can be based on an existing language/runtime (say Java based). However the approach taken by Java for specifying rules (see Jess,JSR) is very "Constraint Logic Programming' type - which I beleive may be an overkill for the OPES framework. Other rules-based frameworks are similarly very complex. What we need is just a means of scripting out the rules - P may work! Also, after somewhat freezing the charter (atleast in concept) about the 'P' applicability - limiting the usage to the OPES administrator (as opposed to rules authored by client or content provider ) ; 'P' seems to have the core stuff. May require some enhancements and more complementary specifications for interfacing things and so on.. I would go with (b) or (c) while preferring (c) since it is less work ;-) regards Geetha Abbie Barbir wrote: > > > MArkus, > > new insights are comming as we speak. > but as I said I can live with the other options > > abbie > > > -----Original Message----- > > From: Markus Hofmann [mailto:markus@mhof.com] > > Sent: Tuesday, July 13, 2004 4:56 PM > > To: OPES Group > > Subject: Re: Strawman OPES Charter > > > > > > > > Abbie Barbir wrote: > > > > >>Just to make sure: which of the following you consider essential: > > >> > > >> a) forget about P choice, start from scratch, write a > > >> formal "language requirements" document, then select > among > > >> IRML, P, and possibly other candidates. > > >> > > >> b) confirm past P choice, but write a "language > requirements" > > >> document or section, before proceeding with polishing P > > >> > > >> c) confirm P choice, and do not write a "language > > >> requirements" document/section > > > > > > > > > well, I go for option a) to be frank. However, I can live > > with b) or > > > c) if the WG wants that. > > > > Are there any new insights or developments that came up after our > > earlier discussions we had on "P" and other approaches? If not, I > > don't want to re-iterate the discussions we already had. > > > > -Markus > > > > From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:22:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24223 for ; Wed, 14 Jul 2004 01:22:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkcDt-0000cS-M4 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:22:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkcAZ-0007Z2-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:19:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkc4a-00060r-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:12:52 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E54S6v020483; Tue, 13 Jul 2004 22:04:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E54SKn020482; Tue, 13 Jul 2004 22:04:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E54SPP020475 for ; Tue, 13 Jul 2004 22:04:28 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel10.hp.com (Postfix) with ESMTP id 14635A3BF; Tue, 13 Jul 2004 22:04:29 -0700 (PDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id KAA09414; Wed, 14 Jul 2004 10:34:41 +0530 (IST) Message-ID: <40F4BE7C.F8A6BD86@india.hp.com> Date: Wed, 14 Jul 2004 10:32:52 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: Markus Hofmann , OPES Group Subject: Re: Updated Stawman OPES Charter References: <40F45354.4030808@bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Looks good now. Alex Rousskov wrote: > On Tue, 13 Jul 2004, Markus Hofmann wrote: > > > In addition, the WG will define a rules language to control selection > > and invocation of services by an OPES processor. Defining language(s) > > for implementing OPES services is out of the WG scope. The rules > > language will be based on previous work of the WG on a rule language > > named "P". > > > The working group will have a design goal that the method be > > compatible with existing policy work within the IETF > > s/the method/the language/ > > Other than that, and the pending MIME/SMTP issue, the revision looks > good! > > Thank you, > > Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:26:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24874 for ; Wed, 14 Jul 2004 01:26:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkcHk-0001xP-Pz for opes-archive@ietf.org; Wed, 14 Jul 2004 01:26:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkcGx-0001aX-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:25:40 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkcFo-0001Bq-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:24:28 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E5FRE9022780; Tue, 13 Jul 2004 22:15:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E5FR6T022779; Tue, 13 Jul 2004 22:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E5FPOV022758 for ; Tue, 13 Jul 2004 22:15:26 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6E5FX9d033309; Tue, 13 Jul 2004 23:15:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6E5FXuw033308; Tue, 13 Jul 2004 23:15:33 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 23:15:33 -0600 (MDT) From: Alex Rousskov To: Geetha Manjunath cc: OPES Group Subject: Re: Strawman OPES Charter In-Reply-To: <40F4BAF4.1505C7A1@india.hp.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3E0C3.D85E0082@india.hp.com> <40F4BAF4.1505C7A1@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 14 Jul 2004, Geetha Manjunath wrote: > Alex Rousskov wrote: > > > ... unless we want to expand P scope to affect things like preview > > size dynamically, while the data is being retrieved from the network. > > We will be able to control service _execution_ then. > > I am sure this is right. If the service is say, "virus scanning", by > changing the preview size of the stream being sent, you cannot > probably tell the scanner to change its execution path . On the > other hand, the OPES service may be able to dictate the preview size > required for it to function.. Basically, it will boil down to > negotiation over the callout protocol . I had an even more dynamic case in mind, where some P code will tell the invoked service or OPES processor (after the service invocation), that the service can have 10 more bytes, then 30 more bytes, etc. (depending on some conditions expressed in P). That would be execution control. I do not think we want to go that far for now. Configuration before invocation is clearly in scope. s.a = 1; invoke s; Negotiation over OCP might be in scope, but only if P hides the details: if (s.supportsFoo()) then { s.a = 1; } else { s.b = "bar"; } invoke s; P interpreter should be free to implement "supportsFoo()" call via OCP negotiation with the service if static information about Foo support is not available, right? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:27:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24972 for ; Wed, 14 Jul 2004 01:27:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkcIK-0002Hm-3t for opes-archive@ietf.org; Wed, 14 Jul 2004 01:27:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkcHQ-0001ux-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:26:08 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkcGZ-0001X7-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:25:15 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E57e9V021136; Tue, 13 Jul 2004 22:07:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E57eOX021135; Tue, 13 Jul 2004 22:07:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E57e5P021129 for ; Tue, 13 Jul 2004 22:07:40 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6E57j9d032892; Tue, 13 Jul 2004 23:07:45 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6E57jEe032891; Tue, 13 Jul 2004 23:07:45 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 23:07:45 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: SMTP adaptation conflicts with other WGs In-Reply-To: <40F488B0.70805@bell-labs.com> Message-ID: References: <40F45354.4030808@bell-labs.com> <40F488B0.70805@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Has anybody looked at potential SMTP-work overlap with LEMONADE WG? They seem to focus on IMAP, but their problem is what OPES solutions are supposed to solve: http://www.ietf.org/html.charters/lemonade-charter.html Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. Are there any other WG with similar work items? LEMONADE charter mentions: VPIM, FAX, and IMAPEXT IETF working groups. Should we make sure we are not stepping on other WG toes? How? Or will our AD insure that, once we have a polished charter? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 14 01:42:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26029 for ; Wed, 14 Jul 2004 01:42:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkcWl-0007dd-5A for opes-archive@ietf.org; Wed, 14 Jul 2004 01:41:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkcVh-0007Hb-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:40:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkcUi-0006vM-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 01:39:52 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E5TaA6025297; Tue, 13 Jul 2004 22:29:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E5Ta31025296; Tue, 13 Jul 2004 22:29:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E5TZPn025289 for ; Tue, 13 Jul 2004 22:29:35 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6E5Tg9d034516; Tue, 13 Jul 2004 23:29:42 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6E5TgKA034515; Tue, 13 Jul 2004 23:29:42 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Jul 2004 23:29:42 -0600 (MDT) From: Alex Rousskov To: Geetha Manjunath cc: Markus Hofmann , OPES Group Subject: Re: P-services interface in Strawman OPES Charter In-Reply-To: <40F4B508.294D6D83@india.hp.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F4B508.294D6D83@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 14 Jul 2004, Geetha Manjunath wrote: > Alex Rousskov wrote: > > > On Tue, 13 Jul 2004, Markus Hofmann wrote: > > > > > Alex Rousskov wrote: > > > > > > > - Defining an interface between rules language > > > > and service (at least OCP-speaking service) > > > > How to pass parameters to services? How to > > > > get the result of service application, including > > > > errors, back to the language/program? > > > > > > I would consider passing of parameters and getting results back into > > > the language/program in scope. Any other thoughts? > > > > I agree. Supporting just that in a general way is already difficult! > > > > We are talking about any P program being able to pass any parameters > > to any service in scope (e.g., any OCP-speaking or perhaps > > WSDL-describable OPES service). How will P interpreter know what > > parameters are available? Which parameters are optional? What are their > > types? > > > > > > Won't that info be available while "discovering a service" ie., your > (following) first addendum item ? > - Defining how available services become known > to the rules language interpreter? (At least > OCP-speaking services) > Good question. It all depends on the result of service discovery. If the result of service discovery is service ID and IP:port pair, then no. If the result of service discovery is service ID, IP:port pair, and complete service profile, then yes. I assumed the former context. In many cases, the service interface will be hard-coded in some OPES processor configuration file, avoiding any dynamic discovery. The question is, do we want to be able to write a P interpreter that only understands one (standard) service interface description (possibly supplied by the service vendor) as opposed to supporting multiple non-standard description formats (also possibly supplied by service vendors)? And, even if we declare standardizing service interface description out of WG scope, we still must document how an invocation call in P is translated into OCP commands, right? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 14 02:38:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26405 for ; Wed, 14 Jul 2004 02:38:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkdOx-00030l-Ae for opes-archive@ietf.org; Wed, 14 Jul 2004 02:37:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkdNx-0002go-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 02:36:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkdN1-0002MM-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 02:35:59 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E6QSuF036193; Tue, 13 Jul 2004 23:26:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E6QSAc036192; Tue, 13 Jul 2004 23:26:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E6QR0S036184 for ; Tue, 13 Jul 2004 23:26:27 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel10.hp.com (Postfix) with ESMTP id 22F9F5989; Tue, 13 Jul 2004 23:26:26 -0700 (PDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id LAA26389; Wed, 14 Jul 2004 11:56:39 +0530 (IST) Message-ID: <40F4D1B1.8B01C9D9@india.hp.com> Date: Wed, 14 Jul 2004 11:54:49 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3E0C3.D85E0082@india.hp.com> <40F4BAF4.1505C7A1@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit That's right! So I beleive, it becomes mandatory to explicitly define 'how to interface external modules to P?' regards Geetha Alex Rousskov wrote: > P interpreter should be free to implement "supportsFoo()" call via OCP > negotiation with the service if static information about Foo support > is not available, right? > > Thanks, > > Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 14 02:50:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27104 for ; Wed, 14 Jul 2004 02:50:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkdbU-0007K2-3i for opes-archive@ietf.org; Wed, 14 Jul 2004 02:50:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkdaT-0006zt-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 02:49:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkdZX-0006fE-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 02:48:55 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E6d0Xn039857; Tue, 13 Jul 2004 23:39:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E6d0QM039856; Tue, 13 Jul 2004 23:39:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E6cxeE039845 for ; Tue, 13 Jul 2004 23:39:00 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by atlrel9.hp.com (Postfix) with ESMTP id 3A52329B22; Wed, 14 Jul 2004 00:38:57 -0600 (MDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id MAA29388; Wed, 14 Jul 2004 12:09:01 +0530 (IST) Message-ID: <40F4D498.5F073017@india.hp.com> Date: Wed, 14 Jul 2004 12:07:12 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: Markus Hofmann , OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F4B508.294D6D83@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > > Won't that info be available while "discovering a service" ie., your > > (following) first addendum item ? > > - Defining how available services become known > > to the rules language interpreter? (At least > > OCP-speaking services) > > > > Good question. It all depends on the result of service discovery. If > the result of service discovery is service ID and IP:port pair, then > no. If the result of service discovery is service ID, IP:port pair, > and complete service profile, then yes. I assumed the former context. I assume the latter context ;-) Atleast that is what is done for web service discovery. > In many cases, the service interface will be hard-coded in some OPES > processor configuration file, avoiding any dynamic discovery. The > question is, do we want to be able to write a P interpreter that only > understands one (standard) service interface description (possibly > supplied by the service vendor) as opposed to supporting multiple > non-standard description formats (also possibly supplied by service > vendors)? > > And, even if we declare standardizing service interface description > out of WG scope, we still must document how an invocation call in P is > translated into OCP commands, right? How about supporting non-std interfaces as additional module? For example (pl forget the syntax for now): Services.invoke(serviceA,1,2); // Invokes the std OCP service, serviceA - OCP service supported by default. import ICAPService // A special module that supports invoke method on ICAP services ICAPService.invoke(serviceB); Geetha From owner-ietf-openproxy@mail.imc.org Wed Jul 14 06:39:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07887 for ; Wed, 14 Jul 2004 06:39:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkhAE-0004I5-Kf for opes-archive@ietf.org; Wed, 14 Jul 2004 06:39:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkh9I-0003xy-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 06:38:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkh8K-0003dH-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 06:37:04 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EAPlgr008825; Wed, 14 Jul 2004 03:25:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EAPl7r008824; Wed, 14 Jul 2004 03:25:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (wwsmtp.webwasher.com [217.146.159.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EAPjDS008763 for ; Wed, 14 Jul 2004 03:25:46 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Date: Wed, 14 Jul 2004 03:25:45 -0700 (PDT) From: martin.stecher@webwasher.com Message-Id: <200407141025.i6EAPjDS008763@above.proper.com> Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id JGKKX7GO outgoing id 3VSP4CCZ; 14 Jul 2004 12:25:33 +0200 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER, NO_REAL_NAME autolearn=no version=2.60 From owner-ietf-openproxy@mail.imc.org Wed Jul 14 08:04:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10898 for ; Wed, 14 Jul 2004 08:04:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkiUk-0000x8-C8 for opes-archive@ietf.org; Wed, 14 Jul 2004 08:04:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkiTo-0000cL-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 08:03:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkiT1-0000IF-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 08:02:31 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EBoHtD034285; Wed, 14 Jul 2004 04:50:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EBoHbb034284; Wed, 14 Jul 2004 04:50:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (wwsmtp.webwasher.com [217.146.159.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EBoFDb034223 for ; Wed, 14 Jul 2004 04:50:16 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Date: Wed, 14 Jul 2004 04:50:15 -0700 (PDT) From: martin.stecher@webwasher.com Message-Id: <200407141150.i6EBoFDb034223@above.proper.com> Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id XIOTSI98 outgoing id UYB85EBA; 14 Jul 2004 13:50:09 +0200 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER, NO_REAL_NAME autolearn=no version=2.60 From owner-ietf-openproxy@mail.imc.org Wed Jul 14 08:48:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13055 for ; Wed, 14 Jul 2004 08:48:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkjBD-0007Pz-DG for opes-archive@ietf.org; Wed, 14 Jul 2004 08:48:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkjAF-000755-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 08:47:11 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkj9H-0006kT-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 08:46:11 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ECVjqx046460; Wed, 14 Jul 2004 05:31:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6ECVjMA046459; Wed, 14 Jul 2004 05:31:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (wwsmtp.webwasher.com [217.146.159.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ECVi5R046421 for ; Wed, 14 Jul 2004 05:31:44 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id AY9MPSAC outgoing id AY9MPSAC; 14 Jul 2004 14:31:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Which SMTP element? Date: Wed, 14 Jul 2004 14:31:40 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D2A0040@mail.webwasher.com> Thread-Topic: Which SMTP element? Thread-Index: AcRpYZrtI3F8YCW0QiW8nnidW0lrDgAKtqmg From: "Martin Stecher" To: "OPES Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6ECVj5R046453 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit > > Given the above, I think MTA is an appropriate first target. Since we > are OPES, we should be looking for an intermediary here. Targeting > MUAs would be like targeting browsers in OCP/HTTP profile, right? The > latter is not theoretically inappropriate (nobody can clearly define > what an intermediary or "edge" is), but also not important enough for > OPES right now. I fully agree. > > Moreover, could we try to simplify the charter by removing all other > SMTP agents from it? Can we just hope that OCP/SMTP profile with a > focus on MTAs will be applicable enough to MSAs and MDAs? We can > always add MSA- or MDA-specific features later, right? I second that. Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Jul 14 08:49:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13125 for ; Wed, 14 Jul 2004 08:49:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkjCD-0007km-Gu for opes-archive@ietf.org; Wed, 14 Jul 2004 08:49:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkjBG-0007QS-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 08:48:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkjAO-000766-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 08:47:20 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ECW1Qx046543; Wed, 14 Jul 2004 05:32:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6ECW1N3046542; Wed, 14 Jul 2004 05:32:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (wwsmtp.webwasher.com [217.146.159.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ECW0pm046503 for ; Wed, 14 Jul 2004 05:32:00 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id NALUZ8KW outgoing id NALUZ8KW; 14 Jul 2004 14:31:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SMTP or MIME in Strawman OPES Charter Date: Wed, 14 Jul 2004 14:31:56 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D2A0041@mail.webwasher.com> Thread-Topic: SMTP or MIME in Strawman OPES Charter Thread-Index: AcRpQlVlfwI8yKOESAqsRR41GvLJSgASuo+Q From: "Martin Stecher" To: "OPES Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6ECW1pm046532 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit > > Can someone give a specific example/use case for SMTP commands > adaptation ? > How about these: Use Case 1: An MTA at a corporate gateway handles outgoing mail traffic. In the "MAIL FROM:" command it gets the sender's email address. Before replying to this command (allow/deny) it sends an OCP request to an OPES service that checks in the corporate directory service whether that employee is allowed to send mails to the Internet. Depending on the OCP response the MTA replies in the SMTP dialog with allow or deny. Use Case 2: The other way around. The MTA sends OCP requests for all "RCPT TO:" commands for incoming messages and asks the OPES service whether the recipient exists and is allowed to receive email. Use Case 3: Sender validation via OPES. OPES service checks sender IP, HELO command, resolves the sender address etc. This may tell the MTA not to accept the message for delivery. Could even be done asynchronously for some parts, i.e. sending the OCP request after HELO or MAIL FROM and continuing to handle recipients and to receive the mail body. The response then needs to be there before the message gets finally accepted. Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Jul 14 09:21:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15447 for ; Wed, 14 Jul 2004 09:21:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkjhY-0003Wk-RI for opes-archive@ietf.org; Wed, 14 Jul 2004 09:21:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkjgb-00038k-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 09:20:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkjfj-0002mQ-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 09:19:43 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ED9OGS057480; Wed, 14 Jul 2004 06:09:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6ED9OWB057479; Wed, 14 Jul 2004 06:09:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ED9NEt057437 for ; Wed, 14 Jul 2004 06:09:23 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6ECr2W13967; Wed, 14 Jul 2004 08:53:02 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jul 2004 08:53:02 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEB48C65@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Geetha Manjunath , Alex Rousskov Cc: Markus Hofmann , OPES Group Subject: RE: Updated Stawman OPES Charter Date: Wed, 14 Jul 2004 08:55:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469A1.7CCD85E0" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C469A1.7CCD85E0 Content-Type: text/plain +1 abbie > -----Original Message----- > From: Geetha Manjunath [mailto:geetham@india.hp.com] > Sent: Wednesday, July 14, 2004 1:03 AM > To: Alex Rousskov > Cc: Markus Hofmann; OPES Group > Subject: Re: Updated Stawman OPES Charter > > > > Looks good now. > > Alex Rousskov wrote: > > > On Tue, 13 Jul 2004, Markus Hofmann wrote: > > > > > In addition, the WG will define a rules language to control > > > selection and invocation of services by an OPES > processor. Defining > > > language(s) for implementing OPES services is out of the > WG scope. > > > The rules language will be based on previous work of the WG on a > > > rule language named "P". > > > > > The working group will have a design goal that the method be > > > compatible with existing policy work within the IETF > > > > s/the method/the language/ > > > > Other than that, and the pending MIME/SMTP issue, the > revision looks > > good! > > > > Thank you, > > > > Alex. > > ------_=_NextPart_001_01C469A1.7CCD85E0 Content-Type: text/html RE: Updated Stawman OPES Charter

+1
abbie

> -----Original Message-----
> From: Geetha Manjunath [mailto:geetham@india.hp.com]
> Sent: Wednesday, July 14, 2004 1:03 AM
> To: Alex Rousskov
> Cc: Markus Hofmann; OPES Group
> Subject: Re: Updated Stawman OPES Charter
>
>
>
> Looks good now.
>
> Alex Rousskov wrote:
>
> > On Tue, 13 Jul 2004, Markus Hofmann wrote:
> >
> > > In addition, the WG will define a rules language to control
> > > selection and invocation of services by an OPES
> processor. Defining
> > > language(s) for implementing OPES services is out of the
> WG scope.
> > > The rules language will be based on previous work of the WG on a
> > > rule language named "P".
> >
> > > The working group will have a design goal that the method be
> > > compatible with existing policy work within the IETF
> >
> > s/the method/the language/
> >
> > Other than that, and the pending MIME/SMTP issue, the
> revision looks
> > good!
> >
> > Thank you,
> >
> > Alex.
>
>

------_=_NextPart_001_01C469A1.7CCD85E0-- From owner-ietf-openproxy@mail.imc.org Wed Jul 14 10:20:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19570 for ; Wed, 14 Jul 2004 10:20:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkkcN-0007kg-8M for opes-archive@ietf.org; Wed, 14 Jul 2004 10:20:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkkbI-0007Oh-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 10:19:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkkaG-0006sv-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 10:18:08 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EE8RNW074007; Wed, 14 Jul 2004 07:08:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EE8RA3074006; Wed, 14 Jul 2004 07:08:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EE8QU8073995 for ; Wed, 14 Jul 2004 07:08:26 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EE8S1O080483 for ; Wed, 14 Jul 2004 10:08:28 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EE8Ndj079059 for ; Wed, 14 Jul 2004 10:08:23 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EE8MMJ022171 for ; Wed, 14 Jul 2004 10:08:23 -0400 (EDT) Message-ID: <40F53DDC.7060106@bell-labs.com> Date: Wed, 14 Jul 2004 10:06:20 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Which SMTP element? References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F489D2.5050102@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Given the above, I think MTA is an appropriate first target. Since we > are OPES, we should be looking for an intermediary here. Targeting > MUAs would be like targeting browsers in OCP/HTTP profile, right? The > latter is not theoretically inappropriate (nobody can clearly define > what an intermediary or "edge" is), but also not important enough for > OPES right now. I'm *no* expert on SMTP or email in general, but I would tend to agree. > Moreover, could we try to simplify the charter by removing all other > SMTP agents from it? Can we just hope that OCP/SMTP profile with a > focus on MTAs will be applicable enough to MSAs and MDAs? We can > always add MSA- or MDA-specific features later, right? Sounds ok to me. Anyone any strong feelings? -Markus From owner-ietf-openproxy@mail.imc.org Wed Jul 14 10:47:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21503 for ; Wed, 14 Jul 2004 10:47:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkl2U-0001aQ-L2 for opes-archive@ietf.org; Wed, 14 Jul 2004 10:47:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkl1e-0001Ga-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 10:46:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkl0g-0000ww-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 10:45:26 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEaGSY085332; Wed, 14 Jul 2004 07:36:16 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EEaGXA085331; Wed, 14 Jul 2004 07:36:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEaF1C085320 for ; Wed, 14 Jul 2004 07:36:15 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EEaH1O080805 for ; Wed, 14 Jul 2004 10:36:17 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EEaCdj080505 for ; Wed, 14 Jul 2004 10:36:12 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EEaAMJ023104 for ; Wed, 14 Jul 2004 10:36:12 -0400 (EDT) Message-ID: <40F54460.2000708@mhof.com> Date: Wed, 14 Jul 2004 10:34:08 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F449A5.1050307@mhof.com> <40F484FF.3030905@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > I am worried that if we want to define WSDL profile for OCP, some of > us (or some of IESG) will find that extending W3C technology like WSDL > is out of current charter scope. We do not know whether using WSDL is > the right way to go, but should we just mention that we need to > > Define P-services interface, based on existing interface > description standards like WSDL, if possible, or OPES-specific > description otherwise. What about the following: In addition, the WG will define a rules language to control selection and invocation of services by an OPES processor. This includes a mechanism allowing an OPES processor to perform a runtime check of service parameters, leveraging existing interface description standards like WSDL, if possible, or OPES-specific description otherwise. -Markus From owner-ietf-openproxy@mail.imc.org Wed Jul 14 11:00:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22198 for ; Wed, 14 Jul 2004 11:00:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BklF4-0005iU-QH for opes-archive@ietf.org; Wed, 14 Jul 2004 11:00:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BklE3-0005NW-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 10:59:15 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BklD9-000547-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 10:58:19 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEmZfK090791; Wed, 14 Jul 2004 07:48:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EEmZD0090790; Wed, 14 Jul 2004 07:48:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEmYgT090776 for ; Wed, 14 Jul 2004 07:48:34 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EEmaXJ085468 for ; Wed, 14 Jul 2004 10:48:36 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EEmVdj081086 for ; Wed, 14 Jul 2004 10:48:31 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EEmUMJ023501 for ; Wed, 14 Jul 2004 10:48:30 -0400 (EDT) Message-ID: <40F54743.80309@bell-labs.com> Date: Wed, 14 Jul 2004 10:46:27 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Which SMTP element? References: <75F7E67FC45F6744A7D328D41E35376D2A003D@mail.webwasher.com> In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D2A003D@mail.webwasher.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Martin Stecher wrote: >>Moreover, could we try to simplify the charter by removing all other >>SMTP agents from it? Can we just hope that OCP/SMTP profile with a >>focus on MTAs will be applicable enough to MSAs and MDAs? We can >>always add MSA- or MDA-specific features later, right? > > > I second that. While I agree, where' then back to having a single - albeit more focused - SMTP milestone. Ted's original suggestion was that a singel milestone seems a bit monolithicand that it might be worthwhile to split the SMTP work into multiple milestones. Now, with the more focused and narrow SMTP milestone, that might be ok, but if anyone has any suggestions... -Markus From owner-ietf-openproxy@mail.imc.org Wed Jul 14 11:46:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24766 for ; Wed, 14 Jul 2004 11:46:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bklxh-0005Zy-6T for opes-archive@ietf.org; Wed, 14 Jul 2004 11:46:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bklwp-0005H9-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 11:45:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BklwC-0004xw-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 11:44:53 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFAEJM099848; Wed, 14 Jul 2004 08:10:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFAEgR099847; Wed, 14 Jul 2004 08:10:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFADFn099807 for ; Wed, 14 Jul 2004 08:10:13 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6EFA8P07374; Wed, 14 Jul 2004 11:10:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jul 2004 11:10:08 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEB48E75@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: P-services interface in Strawman OPES Charter Date: Wed, 14 Jul 2004 11:11:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469B4.A3C8C9F1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C469B4.A3C8C9F1 Content-Type: text/plain All, Can we state that we will investigate that and if needed we will try to re-use other technologies such as WSDl. abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Wednesday, July 14, 2004 10:34 AM > To: OPES Group > Subject: Re: P-services interface in Strawman OPES Charter > > > > Alex Rousskov wrote: > > > I am worried that if we want to define WSDL profile for > OCP, some of > > us (or some of IESG) will find that extending W3C > technology like WSDL > > is out of current charter scope. We do not know whether > using WSDL is > > the right way to go, but should we just mention that we need to > > > > Define P-services interface, based on existing interface > > description standards like WSDL, if possible, or OPES-specific > > description otherwise. > > What about the following: > > In addition, the WG will define a rules language to control > selection and invocation of services by an OPES processor. This > includes a mechanism allowing an OPES processor to perform > a runtime > check of service parameters, leveraging existing interface > description standards like WSDL, if possible, or OPES-specific > description otherwise. > > -Markus > > ------_=_NextPart_001_01C469B4.A3C8C9F1 Content-Type: text/html RE: P-services interface in Strawman OPES Charter

All,
Can we state that we will investigate that and if needed we will try to re-use other technologies such as WSDl.

abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Wednesday, July 14, 2004 10:34 AM
> To: OPES Group
> Subject: Re: P-services interface in Strawman OPES Charter
>
>
>
> Alex Rousskov wrote:
>
> > I am worried that if we want to define WSDL profile for
> OCP, some of
> > us (or some of IESG) will find that extending W3C
> technology like WSDL
> > is out of current charter scope. We do not know whether
> using WSDL is
> > the right way to go, but should we just mention that we need to
> >
> >     Define P-services interface, based on existing interface
> >     description standards like WSDL, if possible, or OPES-specific
> >     description otherwise.
>
> What about the following:
>
>    In addition, the WG will define a rules language to control
>    selection and invocation of services by an OPES processor. This
>    includes a mechanism allowing an OPES processor to perform
> a runtime
>    check of service parameters, leveraging existing interface
>    description standards like WSDL, if possible, or OPES-specific
>    description otherwise.
>
> -Markus
>
>

------_=_NextPart_001_01C469B4.A3C8C9F1-- From owner-ietf-openproxy@mail.imc.org Wed Jul 14 11:52:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24974 for ; Wed, 14 Jul 2004 11:52:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkm3N-0007QW-HO for opes-archive@ietf.org; Wed, 14 Jul 2004 11:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkm2O-00076y-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 11:51:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkm1J-0006WM-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 11:50:09 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFecZf013711; Wed, 14 Jul 2004 08:40:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFecTw013710; Wed, 14 Jul 2004 08:40:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFebuM013694 for ; Wed, 14 Jul 2004 08:40:37 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EFee1O081445; Wed, 14 Jul 2004 11:40:40 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EFeYU1057381; Wed, 14 Jul 2004 11:40:34 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EFeXMJ025183; Wed, 14 Jul 2004 11:40:33 -0400 (EDT) Message-ID: <40F55377.7060108@bell-labs.com> Date: Wed, 14 Jul 2004 11:38:31 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group CC: eburger@snowshore.com Subject: Re: SMTP adaptation conflicts with other WGs References: <40F45354.4030808@bell-labs.com> <40F488B0.70805@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I chatted with Eric Burger (Co-Chair of lemonde) a while back on this topic, and the feeling was that there's no overlap or no major one. Looks like lemonade is focused mainly on IMAP. [I've copied Eric on this email. Eric - do you hav any thoughts?] The fax working group was mentioned several times, so we'll also have to have a look there. I would suggest we polish our proposed re-charter, and then work with Ted and the Chairs of the respective group to make sure that there's no overlap. -Markus Alex Rousskov wrote: > Has anybody looked at potential SMTP-work overlap with LEMONADE WG? > They seem to focus on IMAP, but their problem is what OPES solutions > are supposed to solve: > > http://www.ietf.org/html.charters/lemonade-charter.html > Lemonade is tasked to provide a set of enhancements and profiles of > Internet email submission, transport, and retrieval protocols to > facilitate operation on platforms with constrained resources, or > communications links with high latency or limited bandwidth. > > > Are there any other WG with similar work items? LEMONADE charter > mentions: VPIM, FAX, and IMAPEXT IETF working groups. > > Should we make sure we are not stepping on other WG toes? How? Or will > our AD insure that, once we have a polished charter? > > Thanks, > > Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 14 11:59:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25329 for ; Wed, 14 Jul 2004 11:59:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkmAN-0001rr-Mg for opes-archive@ietf.org; Wed, 14 Jul 2004 11:59:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkm9M-0001YX-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 11:58:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkm8Z-0001FG-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 11:57:40 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFV1PN009562; Wed, 14 Jul 2004 08:31:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFV1jk009561; Wed, 14 Jul 2004 08:31:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFV0fF009547 for ; Wed, 14 Jul 2004 08:31:00 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EFV3XJ085944 for ; Wed, 14 Jul 2004 11:31:03 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EFUvdj082937 for ; Wed, 14 Jul 2004 11:30:57 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EFUvMJ024979 for ; Wed, 14 Jul 2004 11:30:57 -0400 (EDT) Message-ID: <40F55136.5040203@mhof.com> Date: Wed, 14 Jul 2004 11:28:54 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <87AC5F88F03E6249AEA68D40BD3E00BEB48E75@zcarhxm2.corp.nortel.com> In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BEB48E75@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Abbie Barbir wrote: > Can we state that we will investigate that and if needed we will try to > re-use other technologies such as WSDl. Isn't that implied by the proposed phrasing? >> [...] This >> includes a mechanism allowing an OPES processor to perform >> a runtime >> check of service parameters, leveraging existing interface >> description standards like WSDL, if possible, or OPES-specific >> description otherwise. -Markus From owner-ietf-openproxy@mail.imc.org Wed Jul 14 12:12:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25952 for ; Wed, 14 Jul 2004 12:12:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkmMr-00066H-07 for opes-archive@ietf.org; Wed, 14 Jul 2004 12:12:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkmLu-0005lT-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 12:11:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkmKy-0005Qj-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 12:10:28 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFh5iL014769; Wed, 14 Jul 2004 08:43:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFh5fO014768; Wed, 14 Jul 2004 08:43:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFh4A5014752 for ; Wed, 14 Jul 2004 08:43:04 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EFh71O081467 for ; Wed, 14 Jul 2004 11:43:07 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EFh2dj083346 for ; Wed, 14 Jul 2004 11:43:02 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EFh1MJ025253 for ; Wed, 14 Jul 2004 11:43:01 -0400 (EDT) Message-ID: <40F5540B.3090909@bell-labs.com> Date: Wed, 14 Jul 2004 11:40:59 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: SMTP or MIME in Strawman OPES Charter References: <75F7E67FC45F6744A7D328D41E35376D2A003F@mail.webwasher.com> In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D2A003F@mail.webwasher.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Martin, thanks for the examples. Now, that makes me think whether we should have a separate *short* document about such SMTP related use cases. Our current use case document is very much HTTP specific, and something similar for SMTP-related use cases might be helpful. Any thoughts? -Markus Martin Stecher wrote: >>Can someone give a specific example/use case for SMTP commands >>adaptation ? >> > > > How about these: > > Use Case 1: > An MTA at a corporate gateway handles outgoing mail traffic. > In the "MAIL FROM:" command it gets the sender's email address. > Before replying to this command (allow/deny) it sends an OCP > request to an OPES service that checks in the corporate directory > service whether that employee is allowed to send mails to the > Internet. Depending on the OCP response the MTA replies in the > SMTP dialog with allow or deny. > > > Use Case 2: > The other way around. > The MTA sends OCP requests for all "RCPT TO:" commands for > incoming messages and asks the OPES service whether the > recipient exists and is allowed to receive email. > > > Use Case 3: > Sender validation via OPES. OPES service checks sender IP, > HELO command, resolves the sender address etc. > This may tell the MTA not to accept the message for delivery. > Could even be done asynchronously for some parts, i.e. sending > the OCP request after HELO or MAIL FROM and continuing to > handle recipients and to receive the mail body. The response > then needs to be there before the message gets finally accepted. > > > Regards > Martin From owner-ietf-openproxy@mail.imc.org Wed Jul 14 14:43:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05604 for ; Wed, 14 Jul 2004 14:43:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkojC-00010L-9K for opes-archive@ietf.org; Wed, 14 Jul 2004 14:43:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkoiG-0000gy-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 14:42:40 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkoho-0000Nu-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 14:42:13 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIAmn3044068; Wed, 14 Jul 2004 11:10:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIAmQX044066; Wed, 14 Jul 2004 11:10:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIAlN6044042 for ; Wed, 14 Jul 2004 11:10:47 -0700 (PDT) (envelope-from info@utel.net) Received: from f03v-16-119.d3.club-internet.fr ([212.195.189.119] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1BkoDP-0007kR-60; Wed, 14 Jul 2004 11:10:48 -0700 Message-Id: <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 14 Jul 2004 19:07:40 +0200 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: Strawman OPES Charter In-Reply-To: <40F452FE.8080509@mhof.com> References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 23:24 13/07/04, Markus Hofmann wrote: >jfcm wrote: > >>>So far, we've specified a OCP/HTTP profile that supports services >>>operating on HTTP messages. >>>Now we specify a OCP/SMTP profile that supports services operating on >>>SMTP messages. >> >>This is why the same phrasing should be used. > >Here's what we've in currently proposed charter" > > So far, the WG has specified an OCP profile for HTTP, which supports > OPES services that operate on HTTP messages. > >and > > [...] the WG will specify one or more OCP profiles that will support > applications operating on SMTP messages. > >I think this is exactly what I describe above and you agreed on, so we're >in agreement here. I am sorry. This is not. "The WG will specify one or more OCP profiles for SMPT to support OPES services that operate on SMPT messages" would be same phrasing. I expect that you will say it is not what you want. This is precisely what I want you to dig into. Because SMTP is structurally different and I do not think that OPES can apply to the whole SMTP system. >>The answer does not match the question. In one to one direct access http, >>I know who are the parties. I one to many possibly rerouted mailing I do >>not know what you mean by parties. Has to be clarified otherwise the >>whole thing will be opposed on security grounds. > >Hm, you bring up a good point. For example, your asking who are the >endpoints when I send an email to a mailing list, right? I've one source >endpoint, but multiple destination endpoints. So it's not sufficient if >only one of the endpoints authorizes a service. > >Now, in case of this example, sending to the mailing list results >basically in multiple transmissions to individuals, in which case we're >back to a scenario with two endpoints. No. For several reasons. 1. the mailing list the information is sent to is part of the information. That information cannot be modified without the agreement of the whole mailing list. If I send a mail to this list saying that you do not understand this point and I make an OPES to remove you from the list - I agree so it is OK by your criteria - you will not respond, so everyone will believe you do not object - I send another mail agreeing but I make an OPES changing the from jfc in from markus (I can do it since I am one end). Everyone will understand that you have agreed not understanding this point ... and you will know nothing of this. 2. Again I am A, you are B and someone is C. An OPES changes B in C. C will be the receiving end. He has agreed to the change. Is that enough? May be if B gave authority to C, maybe not if B has not. >Any thoughts from anyone? > >>>That is meant to say "...HTTP or SMTP messages". Will change that. >> >>I am not sure about what you mean in this as SMTP Messages when you refer >>to HTTP Messages. You will find that SMTP will probably used in OPES >>related application as application signal and message transport. Even if >>you do not want to take theses mechanisms in consideration, what IMHO >>removes a lot of interest to effort when you consider real life >>applications - for example spam fighting, I suggest a clearer wording to >>avoid this confusion. > >Not sure whether I understood the above, but the wording now is "Define a >rules language to control the selection and invocation of HTTP-based or >SMTP-based OPES services." which I would assumeto be adequatly clear. OK. I suggest that we are extermely carefull at using the word "message" without explaining it, in a signal-message-mail-datagram passing environment. jfc From owner-ietf-openproxy@mail.imc.org Wed Jul 14 14:45:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05713 for ; Wed, 14 Jul 2004 14:45:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkol1-0001dJ-S5 for opes-archive@ietf.org; Wed, 14 Jul 2004 14:45:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkok4-0001Jn-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 14:44:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkojC-00010M-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 14:43:38 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIAmPH044069; Wed, 14 Jul 2004 11:10:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIAmAS044067; Wed, 14 Jul 2004 11:10:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIAlRY044054 for ; Wed, 14 Jul 2004 11:10:47 -0700 (PDT) (envelope-from info@utel.net) Received: from f03v-16-119.d3.club-internet.fr ([212.195.189.119] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1BkoDR-0007kR-Lo for ietf-openproxy@imc.org; Wed, 14 Jul 2004 11:10:51 -0700 Message-Id: <6.1.1.1.2.20040714191713.062fb6e0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 14 Jul 2004 19:54:05 +0200 To: OPES Group From: jfcm Subject: Re: Which SMTP element? In-Reply-To: <40F54743.80309@bell-labs.com> References: <75F7E67FC45F6744A7D328D41E35376D2A003D@mail.webwasher.com> <40F54743.80309@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 16:46 14/07/04, Markus Hofmann wrote: >Martin Stecher wrote: >>>Moreover, could we try to simplify the charter by removing all other >>>SMTP agents from it? Can we just hope that OCP/SMTP profile with a >>>focus on MTAs will be applicable enough to MSAs and MDAs? We can >>>always add MSA- or MDA-specific features later, right? >> >>I second that. > >While I agree, where' then back to having a single - albeit more focused - >SMTP milestone. Ted's original suggestion was that a singel milestone >seems a bit monolithicand that it might be worthwhile to split the SMTP >work into multiple milestones. >Now, with the more focused and narrow SMTP milestone, that might be ok, >but if anyone has any suggestions... I am sorry but IMHO this is not the problem. Could we not take the question with some simple logic? 1. We have addressed HTTP, which is a protocol to access and retrieve existing unique texts. 2. We know consider SMTP, which is a simple protocol to push mails to a group of destinees. Everyone can deduce from this that there is only one thing in common between HTTP and SMTP - it is that both are protocols. - so the novelty is not with the services of a protocol - but with their difference : push vs. retrieve, unique vs. multiple, text vs mail, access vs send. For example: - push vs. retrieve implies different routing and priorities. DNS will only provide one IP address to HTTP. Several of them can be used by SMPT with priorities. Delays of validity will be substantially different. Also, if I call a text and do not retrieve it I notice it. If I send a mail and the other do not receive it I do not know it. Also, when I call a text, the call will go to the right document and I get it. When I receive a mail nothing proves me it was sent by the said origin. - text vs mail there is a main difference : there are no metada in a mail. A text is a permanent document. A mail can be a command. - unique vs. multiple calls for a very clear definition of what are the end participants to an application. What are their privileges. Who the OPES must report to. etc. Just a question : what about the location of the OPES. What can be changed at a given position not to conflict with the other copies. If I send a mail in English to A,B,C. If an OPES changes the text/addresses for ABC in Russian is quite different from the case of an OPES changing the text/addresses in Russian for B only at the gateway of a Russian ISP and C in French at my ISP gateway. Now, about the protocol. In both cases there is a protocol and several payloads (header, cookies and text in HTTP, header, mail and attachement in SMPT). Is that enough to consider the same? I doubt it because an OPES will have less impact IMHO but as long as these issues have not be taken into account, - we will be objected that we did not do our home work - we may conflict with other projects - we will meet major difficulties in understanding what we will discuss.... Again sorry, I may be totally wrong, but the current charter just does not make sense to me in a network environment (it is clearer as a charter for a front-end OPES for one single application. This means the OPES is related to one edge of the network, and works by receiving/sending end to end pair - ex. Markus' analysis that sending a mail to a list is the same as sending one mail to each member of the list). I know end-to-end is the Internet paradigm and Reed/Engelbart/Cerf etc. etc. thinking. But OPES are opposing that. OPES are precisely that connections are NOT end to end. Content and destination may change. This is what I call ONES. HTTP permitted to partly avoid the problem in focusing on the way it is used (call, retrieve and applications). SMTP (push, broadcast and interapplications) does not permit to avoid the analysis. jfc From owner-ietf-openproxy@mail.imc.org Wed Jul 14 15:12:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07964 for ; Wed, 14 Jul 2004 15:12:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkpB5-0002Ww-TT for opes-archive@ietf.org; Wed, 14 Jul 2004 15:12:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkpA4-0002C7-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 15:11:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkp96-0001q4-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 15:10:24 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIxO10052714; Wed, 14 Jul 2004 11:59:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIxOPN052713; Wed, 14 Jul 2004 11:59:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIxNgT052705 for ; Wed, 14 Jul 2004 11:59:23 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EIxRXJ087383 for ; Wed, 14 Jul 2004 14:59:27 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EIxLdj090318 for ; Wed, 14 Jul 2004 14:59:21 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EIxLMJ029524 for ; Wed, 14 Jul 2004 14:59:21 -0400 (EDT) Message-ID: <40F5820E.9010908@mhof.com> Date: Wed, 14 Jul 2004 14:57:18 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <87AC5F88F03E6249AEA68D40BD3E00BEB4915B@zcarhxm2.corp.nortel.com> In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BEB4915B@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Abbie Barbir wrote: > Key word is "investigate". That's implied. -Markus From owner-ietf-openproxy@mail.imc.org Wed Jul 14 15:12:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07987 for ; Wed, 14 Jul 2004 15:12:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkpB7-0002XD-PR for opes-archive@ietf.org; Wed, 14 Jul 2004 15:12:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkpAA-0002Cr-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 15:11:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bkp9I-0001tI-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 15:10:36 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIgqUM050050; Wed, 14 Jul 2004 11:42:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIgq3r050049; Wed, 14 Jul 2004 11:42:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIgpvD050041 for ; Wed, 14 Jul 2004 11:42:51 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EIgtXJ087204 for ; Wed, 14 Jul 2004 14:42:55 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EIgnU1063406 for ; Wed, 14 Jul 2004 14:42:49 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EIgnMJ029099 for ; Wed, 14 Jul 2004 14:42:49 -0400 (EDT) Message-ID: <40F57E2E.7070305@mhof.com> Date: Wed, 14 Jul 2004 14:40:46 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> In-Reply-To: <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit jfcm wrote: > I am sorry. This is not. > > "The WG will specify one or more OCP profiles for SMPT to support OPES > services that operate on SMPT messages" would be same phrasing. > I expect that you will say it is not what you want. This is precisely > what I want you to dig into. Because SMTP is structurally different and > I do not think that OPES can apply to the whole SMTP system. I fail to see a big difference in the wordings, but if it makes you feel more comfortable, would the follwing work: ... the WG will specify one or more OCP profiles that will support OPES services operating on SMTP messages. -Markus From owner-ietf-openproxy@mail.imc.org Wed Jul 14 15:19:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08897 for ; Wed, 14 Jul 2004 15:19:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkpI2-0004t5-AR for opes-archive@ietf.org; Wed, 14 Jul 2004 15:19:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkpGw-0004Zn-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 15:18:30 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkpGA-0004HB-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 15:17:42 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIn0F2051106; Wed, 14 Jul 2004 11:49:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIn0Dl051105; Wed, 14 Jul 2004 11:49:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EImxHt051098 for ; Wed, 14 Jul 2004 11:48:59 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6EIn3XJ087264 for ; Wed, 14 Jul 2004 14:49:03 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EImwdj089788 for ; Wed, 14 Jul 2004 14:48:58 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6EImvMJ029298 for ; Wed, 14 Jul 2004 14:48:57 -0400 (EDT) Message-ID: <40F57F9E.1010101@mhof.com> Date: Wed, 14 Jul 2004 14:46:54 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: One Party Consent Model References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> In-Reply-To: <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit jfcm wrote: [I separated this response from the others and gave it a new subject, since I believe it's important] >> Hm, you bring up a good point. For example, your asking who are the >> endpoints when I send an email to a mailing list, right? I've one >> source endpoint, but multiple destination endpoints. So it's not >> sufficient if only one of the endpoints authorizes a service. >> >> Now, in case of this example, sending to the mailing list results >> basically in multiple transmissions to individuals, in which case >> we're back to a scenario with two endpoints. > > > No. For several reasons. > > 1. the mailing list the information is sent to is part of the > information. That information cannot be modified without the agreement > of the whole mailing list. If I send a mail to this list saying that you > do not understand this point and I make an OPES to remove you from the list > - I agree so it is OK by your criteria > - you will not respond, so everyone will believe you do not object > - I send another mail agreeing but I make an OPES changing the from > jfc in from markus (I can do it since I am one end). Everyone will > understand that you have agreed not understanding this point > ... and you will know nothing of this. > > 2. Again I am A, you are B and someone is C. An OPES changes B in C. C > will be the receiving end. He has agreed to the change. Is that enough? > May be if B gave authority to C, maybe not if B has not. See your point, but the example you outline above violates the OPES tracing requirement, which says that Markus (or B in the generic example) must be able to trace the OPES service. I.e. I would be aware of the OPES service that removed me. Now, I'm not yet sure how to achieve this and whether this is the full/correct answer... -Markus From owner-ietf-openproxy@mail.imc.org Wed Jul 14 15:26:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09568 for ; Wed, 14 Jul 2004 15:26:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkpOe-0007AH-AC for opes-archive@ietf.org; Wed, 14 Jul 2004 15:26:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkpNf-0006r4-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 15:25:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BkpMi-0006Wm-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 15:24:28 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIt4P2052035; Wed, 14 Jul 2004 11:55:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIt4Uo052034; Wed, 14 Jul 2004 11:55:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIt3Bk052006 for ; Wed, 14 Jul 2004 11:55:03 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6EIswW08241; Wed, 14 Jul 2004 14:54:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jul 2004 14:54:58 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEB4915B@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: P-services interface in Strawman OPES Charter Date: Wed, 14 Jul 2004 14:57:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469D4.0C4F8F2F" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C469D4.0C4F8F2F Content-Type: text/plain Markus, Key word is "investigate". Abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Wednesday, July 14, 2004 11:29 AM > To: OPES Group > Subject: Re: P-services interface in Strawman OPES Charter > > > > Abbie Barbir wrote: > > > Can we state that we will investigate that and if needed we > will try > > to re-use other technologies such as WSDl. > > Isn't that implied by the proposed phrasing? > > >> [...] This > >> includes a mechanism allowing an OPES processor to perform > >> a runtime > >> check of service parameters, leveraging existing interface > >> description standards like WSDL, if possible, or OPES-specific > >> description otherwise. > > -Markus > > > ------_=_NextPart_001_01C469D4.0C4F8F2F Content-Type: text/html RE: P-services interface in Strawman OPES Charter

Markus,
Key word is "investigate".


Abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Wednesday, July 14, 2004 11:29 AM
> To: OPES Group
> Subject: Re: P-services interface in Strawman OPES Charter
>
>
>
> Abbie Barbir wrote:
>
> > Can we state that we will investigate that and if needed we
> will try
> > to re-use other technologies such as WSDl.
>
> Isn't that implied by the proposed phrasing?
>
> >>   [...] This
> >>   includes a mechanism allowing an OPES processor to perform
> >>   a runtime
> >>   check of service parameters, leveraging existing interface
> >>   description standards like WSDL, if possible, or OPES-specific
> >>   description otherwise.
>
> -Markus
>
>
>

------_=_NextPart_001_01C469D4.0C4F8F2F-- From YWPUORTJC@ksi.ms.mff.cuni.cz Wed Jul 14 19:04:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06644 for ; Wed, 14 Jul 2004 19:04:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bksnd-0002uF-CE for opes-archive@ietf.org; Wed, 14 Jul 2004 19:04:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BksSA-0006ZH-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 18:42:18 -0400 Received: from 81-202-203-159.user.ono.com ([81.202.203.159]) by ietf-mx with smtp (Exim 4.12) id 1Bks6h-0002d0-00 for opes-archive@ietf.org; Wed, 14 Jul 2004 18:20:08 -0400 X-Message-Info: BF3PF8FLLqgvyeB6CS18AgNRDgwdPZO926slzC77zsnTqrbF2DG51 Received: (from home@localhost) by arelob0.YWPUORTJC@ksi.ms.mff.cuni.cz (F.6D.A/1.38.B) id b87YXaK307FE; Thu, 15 Jul 2004 05:14:07 +0600 Message-ID: <36DC45C8E.94769@YWPUORTJC@ksi.ms.mff.cuni.cz> Reply-To: "Jeffery Prince" From: "Jeffery Prince" To: "Opes-archive" Subject: universitty diplomaas Date: Wed, 14 Jul 2004 17:11:07 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--21E91B3E5BBDB4FBF53" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=BIZ_TLD,HTML_60_70, HTML_MESSAGE,HTML_TABLE_THICK_BORD,HTML_TITLE_UNTITLED,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----21E91B3E5BBDB4FBF53 Content-Type: text/html; charset="iso-D47A-A" Content-Transfer-Encoding: quoted-printable Untitled Document

Make today the day when you get your degree.

There is a legal loophole which grants people a university degr= ee w/o sitting in class.

OCP negotiation with the service if static information about Foo > support is not available, right? On Wed, 14 Jul 2004, Geetha Manjunath wrote: > So I beleive, it becomes mandatory to explicitly define 'how to > interface external modules to P?' Mandatory only if by "external modules" you mean "OCP-speaking OPES services". Interfacing with them is required for OPES framework to be complete. Interfacing with something else (e.g., a Java class implementing a content adaptation service, C library implementing P/HTTP module, or an ICAP service) is not required/mandatory. Are we on the same page? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 03:01:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29317 for ; Thu, 15 Jul 2004 03:01:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl0FZ-0003NH-25 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:01:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl0Ee-00034c-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:00:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl0E5-0002lo-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:00:17 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F6q1A3010471; Wed, 14 Jul 2004 23:52:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F6q1AT010470; Wed, 14 Jul 2004 23:52:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F6q0tK010449 for ; Wed, 14 Jul 2004 23:52:00 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6F6px9d060492; Thu, 15 Jul 2004 00:51:59 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6F6pxZg060491; Thu, 15 Jul 2004 00:51:59 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 00:51:59 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter In-Reply-To: <40F54460.2000708@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F449A5.1050307@mhof.com> <40F484FF.3030905@mhof.com> <40F54460.2000708@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 14 Jul 2004, Markus Hofmann wrote: > What about the following: > > In addition, the WG will define a rules language to control > selection and invocation of services by an OPES processor. This > includes a mechanism allowing an OPES processor to perform a runtime > check of service parameters, leveraging existing interface > description standards like WSDL, if possible, or OPES-specific > description otherwise. Sounds good to me. I assume there will be a sentence somewhere about documenting interfaces for P/HTTP and P/SMTP modules. Or is that implied? Injecting "investigate" before "a mechanism allowing" may make Abbie happier. Or we can replace "includes" with "may include". Is that what you are after, Abbie? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 03:11:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29587 for ; Thu, 15 Jul 2004 03:11:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl0PD-0006UK-7x for opes-archive@ietf.org; Thu, 15 Jul 2004 03:11:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl0OE-0006B1-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:10:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl0NH-0005ra-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:09:47 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F7250q014999; Thu, 15 Jul 2004 00:02:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F725kF014997; Thu, 15 Jul 2004 00:02:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F725MK014987 for ; Thu, 15 Jul 2004 00:02:05 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6F7259d061986; Thu, 15 Jul 2004 01:02:05 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6F725iv061985; Thu, 15 Jul 2004 01:02:05 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 01:02:05 -0600 (MDT) From: Alex Rousskov To: Geetha Manjunath cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter In-Reply-To: <40F4D498.5F073017@india.hp.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F4B508.294D6D83@india.hp.com> <40F4D498.5F073017@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 14 Jul 2004, Geetha Manjunath wrote: > How about supporting non-std interfaces as additional module? > > For example (pl forget the syntax for now): > Services.invoke(serviceA,1,2); > // Invokes the std OCP service, serviceA - OCP service supported by default. > > import ICAPService // A special module that supports invoke method on ICAP > services > ICAPService.invoke(serviceB); Sure, that's the intended feature/beauty of P design! If we get the abstraction level high enough, 3rd parties would be able to add all sorts of modules doing all sorts of interesting things, while P programmers will not even notice. Do we agree that defining such additional modules or even defining an interface to plug such additional modules into a P interpreter is outside of our current scope? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 03:19:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29995 for ; Thu, 15 Jul 2004 03:19:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl0X2-0001OW-L4 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:19:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl0W8-000136-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:18:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl0VC-0000id-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:17:58 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F79S1i017945; Thu, 15 Jul 2004 00:09:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F79SpM017944; Thu, 15 Jul 2004 00:09:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F79R3V017931 for ; Thu, 15 Jul 2004 00:09:27 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6F79O9d062391; Thu, 15 Jul 2004 01:09:24 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6F79KOI062390; Thu, 15 Jul 2004 01:09:20 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 01:09:20 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Which SMTP element? In-Reply-To: <40F54743.80309@bell-labs.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D2A003D@mail.webwasher.com> <40F54743.80309@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 14 Jul 2004, Markus Hofmann wrote: > While I agree, where' then back to having a single - albeit more > focused - SMTP milestone. Ted's original suggestion was that a > singel milestone seems a bit monolithicand that it might be > worthwhile to split the SMTP work into multiple milestones. > > Now, with the more focused and narrow SMTP milestone, that might be > ok, but if anyone has any suggestions... If several milestones are highly desirable, we can split SMTP work into "generic MIME" and "SMTP-specific" sections of the same draft and then base milestones on those sections. Moreover, we can add "SMTP command adaptation" section/milestone (as opposed to SMTP MIME message adaptation), if that is in scope. BTW, is it? Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 03:24:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00201 for ; Thu, 15 Jul 2004 03:24:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl0bp-0002yT-GR for opes-archive@ietf.org; Thu, 15 Jul 2004 03:24:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl0at-0002eq-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:23:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl0a1-0002Lk-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:22:57 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F7Em7E020341; Thu, 15 Jul 2004 00:14:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F7EmUQ020340; Thu, 15 Jul 2004 00:14:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F7EkiH020317 for ; Thu, 15 Jul 2004 00:14:47 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6F7Ee9d062771; Thu, 15 Jul 2004 01:14:40 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6F7Eec4062770; Thu, 15 Jul 2004 01:14:40 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 01:14:40 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: SMTP or MIME in Strawman OPES Charter In-Reply-To: <40F5540B.3090909@bell-labs.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D2A003F@mail.webwasher.com> <40F5540B.3090909@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 14 Jul 2004, Markus Hofmann wrote: > Now, that makes me think whether we should have a separate *short* > document about such SMTP related use cases. Our current use case > document is very much HTTP specific, and something similar for > SMTP-related use cases might be helpful. IMO, a short Use Cases section in the "SMTP adaptation with OPES" draft would be a better choice. More people will read and benefit from it that way. It might make sense to separate SMTP command adaptation draft from SMTP MIME message adaptation draft, but I am not sure. I would probably shoot for one draft and split later if we feel like it. Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 03:58:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01536 for ; Thu, 15 Jul 2004 03:58:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl18j-00064B-OS for opes-archive@ietf.org; Thu, 15 Jul 2004 03:58:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl17k-0005kQ-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:57:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl16q-0005Rd-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 03:56:52 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F7lKj0035023; Thu, 15 Jul 2004 00:47:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F7lKLO035022; Thu, 15 Jul 2004 00:47:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F7lJu9035011 for ; Thu, 15 Jul 2004 00:47:19 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6F7lJ9d071665; Thu, 15 Jul 2004 01:47:19 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6F7lJN7071664; Thu, 15 Jul 2004 01:47:19 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 01:47:19 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: One Party Consent Model In-Reply-To: <40F57F9E.1010101@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> <40F57F9E.1010101@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 14 Jul 2004, Markus Hofmann wrote: > jfcm wrote: > > > 1. the mailing list the information is sent to is part of the > > information. That information cannot be modified without the agreement > > of the whole mailing list. If I send a mail to this list saying that you > > do not understand this point and I make an OPES to remove you from the list > > - I agree so it is OK by your criteria > > - you will not respond, so everyone will believe you do not object > > - I send another mail agreeing but I make an OPES changing the from > > jfc in from markus (I can do it since I am one end). Everyone will > > understand that you have agreed not understanding this point > > ... and you will know nothing of this. > > > > 2. Again I am A, you are B and someone is C. An OPES changes B in > > C. C will be the receiving end. He has agreed to the change. Is > > that enough? May be if B gave authority to C, maybe not if B has > > not. > > See your point, but the example you outline above violates the OPES > tracing requirement, which says that Markus (or B in the generic > example) must be able to trace the OPES service. I.e. I would be > aware of the OPES service that removed me. Tracing does not work for one side if the message is killed or short-circuited by another side. If I send an HTTP request to a porn site, my corporate proxy blocks the request, then the porn site will not know I sent the request. This is a corner case of a message not reaching the other side at the consent of the originating side. IMHO, jfc's example is broken (for the lack of a better word) because when jfc talks about changing distribution lists or From headers, he assumes both that the mailing list has no reliable authentication _and_ that unauthenticated changes may have negative affect on subscribers. Both things are true for most IETF mailing lists! However, since subscribers know the environment is not secure, but still subscribe, they accept the risks. In other words, they technically authorize the adaptations jfc is talking about. They consent to receive forged e-mails and to being silently removed from the distribution lists. Both things did happen many times in IETF. I was even lucky enough to be the subject of the latter. Thus, we are talking about a two-party consent case. Nothing "bad" is happening in jfc examples from consent point of view. In a "good" mailing list environment, jfc would either not be able to change/forge headers OR doing so would not have an impact on the subscribers. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 04:15:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02376 for ; Thu, 15 Jul 2004 04:15:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl1PB-000411-5j for opes-archive@ietf.org; Thu, 15 Jul 2004 04:15:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl1OB-0003fY-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 04:14:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl1NA-0003ER-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 04:13:44 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F85umc043282; Thu, 15 Jul 2004 01:05:56 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F85utn043281; Thu, 15 Jul 2004 01:05:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F85qZU043245 for ; Thu, 15 Jul 2004 01:05:54 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6F85o9d072813; Thu, 15 Jul 2004 02:05:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6F85nqh072812; Thu, 15 Jul 2004 02:05:49 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 02:05:49 -0600 (MDT) From: Alex Rousskov To: jfcm cc: OPES Group Subject: SMTP is not HTTP In-Reply-To: <6.1.1.1.2.20040714191713.062fb6e0@mail.utel.net> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D2A003D@mail.webwasher.com> <40F54743.80309@bell-labs.com> <6.1.1.1.2.20040714191713.062fb6e0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 14 Jul 2004, jfcm wrote: > - but with their difference : push vs. retrieve, unique vs. > multiple, text vs mail, access vs send. I agree that there are many differences between HTTP and SMTP. I am sure that future "SMTP adaptation" draft will be different from the existing "HTTP adaptation" draft. However, I do not see your point. Why/How those differences affect the charter? Does the charter somehow imply that HTTP and SMTP adaptations are the same? Does it imply that we will simply rename "HTTP adaptations" draft into "SMTP adaptations" draft and ship it? I do not think so. > For example: [snip] > IMHO but as long as these issues have not be taken into account, > - we will be objected that we did not do our home work > - we may conflict with other projects > - we will meet major difficulties in understanding what we will discuss.... The differences between HTTP and SMTP should be taken into account, of course. In fact, our HTTP work is pretty much irrelevant for the SMTP draft! Only OCP Core and OPES Communications work is relevant. Why do you even compare with HTTP? > Again sorry, I may be totally wrong, but the current charter just does not > make sense to me in a network environment What exactly does not make sense? The assertion that we can use OCP Core to facilitate SMTP adaptations? There is not much else in the current charter, as far as SMTP is concerned! Are you saying that the charter does not prohibit certain kinds of SMTP adaptations and it should? If yes, what are those kinds? Are you saying that the charter does not define certain words related to SMTP adaptations and it should? If yes, what are those words? Let's try to drive this debate closer to the charter text. What exactly is wrong (and how it should be fixed)... Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 09:25:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18514 for ; Thu, 15 Jul 2004 09:25:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl6ES-0003Fn-Hj for opes-archive@ietf.org; Thu, 15 Jul 2004 09:25:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl6DU-0002wJ-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 09:24:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl6Cd-0002dK-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 09:23:11 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDCFdO035946; Thu, 15 Jul 2004 06:12:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FDCF9s035945; Thu, 15 Jul 2004 06:12:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDCEn4035935 for ; Thu, 15 Jul 2004 06:12:14 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6FDCGXJ094635 for ; Thu, 15 Jul 2004 09:12:16 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FDC8dj025448 for ; Thu, 15 Jul 2004 09:12:08 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FDC7MJ016019 for ; Thu, 15 Jul 2004 09:12:07 -0400 (EDT) Message-ID: <40F6822C.40008@mhof.com> Date: Thu, 15 Jul 2004 09:10:04 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: One Party Consent Model References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> <40F57F9E.1010101@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > However, since subscribers know the environment is not secure, but > still subscribe, they accept the risks. In other words, they > technically authorize the adaptations jfc is talking about. They > consent to receive forged e-mails and to being silently removed from > the distribution lists. Both things did happen many times in IETF. I > was even lucky enough to be the subject of the latter. I remember that :) > Thus, we are talking about a two-party consent case. Nothing "bad" is > happening in jfc examples from consent point of view. So, what you're saying is that (a) there are mechanisms in place that can prevent things like the ones described in the example, and (b) if users accept an environment that doesn't use these mechanisms, they implicitly accept that things mentioned in the example can happen, so they basically consent that this can happen? -Markus From owner-ietf-openproxy@mail.imc.org Thu Jul 15 09:31:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18879 for ; Thu, 15 Jul 2004 09:31:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl6KL-0005BC-MM for opes-archive@ietf.org; Thu, 15 Jul 2004 09:31:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl6JV-0004se-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 09:30:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl6Id-0004ZZ-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 09:29:23 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDKZdX037656; Thu, 15 Jul 2004 06:20:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FDKZJ6037655; Thu, 15 Jul 2004 06:20:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDKYR0037649 for ; Thu, 15 Jul 2004 06:20:35 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6FDKa1O089812 for ; Thu, 15 Jul 2004 09:20:36 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FDKVdj025634 for ; Thu, 15 Jul 2004 09:20:31 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FDKUMJ016160 for ; Thu, 15 Jul 2004 09:20:30 -0400 (EDT) Message-ID: <40F68424.8000301@mhof.com> Date: Thu, 15 Jul 2004 09:18:28 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F449A5.1050307@mhof.com> <40F484FF.3030905@mhof.com> <40F54460.2000708@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Sounds good to me. I assume there will be a sentence somewhere about > documenting interfaces for P/HTTP and P/SMTP modules. Or is that > implied? The charter lists the corresponding deliverable as "Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services.". Since the text previously stated "This includes a mechanism allowing an OPES processor to perform a runtime check of service parameters", I would assume that takes care of it. > Injecting "investigate" before "a mechanism allowing" may make Abbie > happier. Or we can replace "includes" with "may include". Is that what > you are after, Abbie? Working on that issue implies doing prior investigation of existing approaches, so I'd assume we're OK here. -Markus From owner-ietf-openproxy@mail.imc.org Thu Jul 15 09:40:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19442 for ; Thu, 15 Jul 2004 09:40:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl6TE-0000PQ-8d for opes-archive@ietf.org; Thu, 15 Jul 2004 09:40:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl6SJ-00005Q-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 09:39:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl6RM-0007YM-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 09:38:25 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDTX0L039034; Thu, 15 Jul 2004 06:29:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FDTXtW039033; Thu, 15 Jul 2004 06:29:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDTWDi039026 for ; Thu, 15 Jul 2004 06:29:33 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6FDTYXJ094795 for ; Thu, 15 Jul 2004 09:29:34 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FDTTU1099742 for ; Thu, 15 Jul 2004 09:29:29 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FDTTMJ016349 for ; Thu, 15 Jul 2004 09:29:29 -0400 (EDT) Message-ID: <40F6863E.6060900@bell-labs.com> Date: Thu, 15 Jul 2004 09:27:26 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Which SMTP element? References: <75F7E67FC45F6744A7D328D41E35376D2A003D@mail.webwasher.com> <40F54743.80309@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > If several milestones are highly desirable, we can split SMTP work > into "generic MIME" and "SMTP-specific" sections of the same draft and > then base milestones on those sections. Given the already narrowed focus, I'd suggest to have a single document that fuly describes the SMTP solution, rather than defining a generic MIME solution and a seperate document with SMTP specific pieces. Let's see what the feedback will be. > Moreover, we can add "SMTP command adaptation" section/milestone (as > opposed to SMTP MIME message adaptation), if that is in scope. BTW, is > it? I would consider this part of the SMTP solution. Explicit SMTP use cases would help clarifying the scope issue... -Markus From owner-ietf-openproxy@mail.imc.org Thu Jul 15 09:57:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20463 for ; Thu, 15 Jul 2004 09:57:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl6jS-00062E-Un for opes-archive@ietf.org; Thu, 15 Jul 2004 09:57:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl6iU-0005jG-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 09:56:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl6hb-0005Qo-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 09:55:11 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDbFrL040121; Thu, 15 Jul 2004 06:37:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FDbFFj040120; Thu, 15 Jul 2004 06:37:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDbEr4040110 for ; Thu, 15 Jul 2004 06:37:14 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6FDbG1O089963 for ; Thu, 15 Jul 2004 09:37:16 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FDbBU1000301 for ; Thu, 15 Jul 2004 09:37:11 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FDbAMJ016623 for ; Thu, 15 Jul 2004 09:37:11 -0400 (EDT) Message-ID: <40F6880C.2030009@bell-labs.com> Date: Thu, 15 Jul 2004 09:35:08 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: SMTP or MIME in Strawman OPES Charter References: <75F7E67FC45F6744A7D328D41E35376D2A003F@mail.webwasher.com> <40F5540B.3090909@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > IMO, a short Use Cases section in the "SMTP adaptation with OPES" > draft would be a better choice. More people will read and benefit from > it that way. While I typically prefer to minimize the number of documents, in this case a separate use cases draft might help getting an exact understanding of the type of services considered in scope. An early use cases draft also proofed to be helpful in answering questions about the scope of the work (I used our existing use cases draft several times in this context). I'm certainly sensitive to the suggestion of merging it into the protoco ldraft, but for now let us add a additional deliverable, and if there are strong feelings we can change that in the final version of the charter. I'll send out an updated charter proposal within a few minutes. > It might make sense to separate SMTP command adaptation draft from > SMTP MIME message adaptation draft, but I am not sure. I would > probably shoot for one draft and split later if we feel like it. I would agree with that. -Markus From owner-ietf-openproxy@mail.imc.org Thu Jul 15 10:13:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22069 for ; Thu, 15 Jul 2004 10:13:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl6z5-0003FK-O0 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:13:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl6yB-0002u5-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:12:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl6xH-0002Y3-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:11:23 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FE2cWk044148; Thu, 15 Jul 2004 07:02:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FE2cAj044147; Thu, 15 Jul 2004 07:02:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FE2bvt044132 for ; Thu, 15 Jul 2004 07:02:38 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6FE2eXJ095121 for ; Thu, 15 Jul 2004 10:02:40 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FE2Ydj027111 for ; Thu, 15 Jul 2004 10:02:35 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6FE2YMJ017159 for ; Thu, 15 Jul 2004 10:02:34 -0400 (EDT) Message-ID: <40F68DFF.30909@bell-labs.com> Date: Thu, 15 Jul 2004 10:00:31 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Latest Charter Proposal Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, below the latest charter proposal. I'd like to close on this soon and forward to our Area Directors for feedback. Please take a careful look. If you've comments, please make *specific* suggestions on where the text should be changed and how it should be changed. If there are no more comments by Friday, 7/16, 5pm (EST), I'll forward this version of the charter to Ted/IESG. Thanks, Markus ===================== Open Pluggable Edge Services (opes) ----------------------------------- Chair(s): Markus Hofmann Applications Area Director(s): Ted Hardie Scott Hollenbeck Applications Area Advisor: Ted Hardie Technical Advisor(s): Allison Mankin Hilarie Orman Mailing Lists: General Discussion: ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Archive: http://www.imc.org/ietf-openproxy/mail-archive/ Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and improve the user experience. Web proxies, for example, are commonly deployed to provide services such as Web caching, virus scanning, and request filtering. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The OPES Working Group has previously developed an architectural framework to authorize, invoke, and trace such application-level services. The framework follows a one-party consent model, which requires that each service be authorized explicitly by at least one of the application-layer endpoints. It further requires that OPES services are reversible by mutual agreement of the application endpoints. In particular, the WG has developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. In a next step, the WG will specify one or more OCP profiles that will support OPES services operating on SMTP messages. In particular, the profile to be specified will enable an OPES processor to encapsulate and forward SMTP messages (or parts thereof) to a callout server for additional processing. Several kinds of agents participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP profile will address the needs of at least the MTA. More profiles may be needed to address other agent-specific needs. In addition, the WG will define a rules language to control selection and invocation of services by an OPES processor. This includes a mechanism allowing an OPES processor to perform a runtime check of service parameters, leveraging existing interface description standards like WSDL, if possible, or OPES-specific description otherwise. Defining language(s) for implementing OPES services is out of the WG scope. The rules language will be based on previous work of the WG on a rule language named "P". The working group will have a design goal that the language be compatible with existing policy work within the IETF (e.g. IETF Policy Framework) and be able to interface with systems automating distribution of policies to multiple endpoints. It will be out of scope for this WG to develop the policy framework and specify multiple-endpoint policy distribution. The group's new work items can be listed as: - Develop a scenarios and use case document for OPES services operating on SMTP messages. - Define SMTP profile(s) to supplement OCP core. - Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services. Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Goals and Milestones: Done Submit OPES scenarios document and architecture document to IESG for Informational. Done Submit document on protocol (callout and tracing) requirements to IESG for Informational. Done Submit document on endpoint authorization and enforcement requirements to IESG for Informational. Done Submit document on threat/risk model for OPES services to IESG for Informational. Done Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization. Done Initial document on rules specification method. Done Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard. SEP04 Revised document on OPES rules language. OCT04 Submit use cases document for OPES services operating on SMTP messages to IESG for Informational. DEC04 Initial document on OCP/SMTP profile for MTAs. FEB05 Submit document on OCP/SMTP profile for MTAs to IESG for Proposed Standard. APR05 Submit document(s) on OCP/SMTP profile(s) for those other SMTP agents the WG has decided to work on, if any. MAY05 Submit document(s) on OPES rules language to IESG for Proposed Standard. MAY05 Consider additional OPES work and present new charter to IESG, or conclude working group. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 10:19:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22620 for ; Thu, 15 Jul 2004 10:19:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl74q-0004qP-KB for opes-archive@ietf.org; Thu, 15 Jul 2004 10:19:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl73X-0004O2-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:17:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl71G-0003uY-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:15:30 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FE6T5H044729; Thu, 15 Jul 2004 07:06:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FE6T6x044728; Thu, 15 Jul 2004 07:06:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FE6Sb6044721 for ; Thu, 15 Jul 2004 07:06:28 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-1-137.d3.club-internet.fr ([195.36.172.137] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1Bl6sW-0004wJ-JI; Thu, 15 Jul 2004 07:06:30 -0700 Message-Id: <6.1.1.1.2.20040715125938.0661e9f0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 15 Jul 2004 13:35:43 +0200 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: One Party Consent Model In-Reply-To: <40F57F9E.1010101@mhof.com> References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> <40F57F9E.1010101@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 20:46 14/07/04, Markus Hofmann wrote: >See your point, but the example you outline above violates the OPES >tracing requirement, which says that Markus (or B in the generic example) >must be able to trace the OPES service. I.e. I would be aware of the OPES >service that removed me. > >Now, I'm not yet sure how to achieve this and whether this is the >full/correct answer... This is excactly my point and that responds Alex's question over my more general comment (Alex thinks "how". I think "what"). - I am not sure how to achieve this - IMHO this cannot be achieved by an OPES - is what we say a correct answer ? because we debate within an "end-to-end, dumb network/smart host, protocol on the wire" vision of a network system, which architecturally totally opposes our target of external-change-in-multiple-alternative-routes This is why I quoted the Judge who had a parallel problem and who gave it a solution I can architecturally accept : considering the mail when temporarily stored at an Agent. There is no difference with HTTP (and Alex there is right): in both cases what we discuss is changing the header and the payload when stored on a host. The particulars of HTTP blurred that debate (my initial discussion) because it permitted to consider the stream as a virtual host. The particulars of "one to interacting many" of mail services do not permit that. I fully agree with Alex: there will be no drastic change in OCP and P etc. But this will not be OPES and there will be impossible problems of interoperation with the interconnected interapplications - as mentionned above. Authorizations, Error reporting, cancellations, priorities, delays, orders, authentication, application interface, LHS acceptation, security, authoritative domains, relation with the DNS, resends, archiving, inter-OPES operations, server failures, spam, etc. Just one small question. Let assume a change is conditional to time. What is the time we chose as a reference. The time the mail was entered, the time it was sent, the time it reached each OPES filter, the time it reached every OPES filters, do we take into account the time the first mail or the last mail reached the filter? Let assume a very common case : authority changes at a given time (a different watch, a justice decision, etc.) and also the management rules. jfc From owner-ietf-openproxy@mail.imc.org Thu Jul 15 10:36:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24195 for ; Thu, 15 Jul 2004 10:36:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl7LS-0002TZ-O9 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:36:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl7KT-00029s-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:35:22 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl7Jy-0001qJ-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:34:50 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FEPbHp048163; Thu, 15 Jul 2004 07:25:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FEPaoH048162; Thu, 15 Jul 2004 07:25:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FEPaeS048143 for ; Thu, 15 Jul 2004 07:25:36 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6FEPHt16548; Thu, 15 Jul 2004 10:25:17 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Jul 2004 10:25:18 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEB4964C@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , Markus Hofmann Cc: OPES Group Subject: RE: P-services interface in Strawman OPES Charter Date: Thu, 15 Jul 2004 10:28:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46A77.8C1A4281" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46A77.8C1A4281 Content-Type: text/plain Alex, yes, can not just assume that things are implied or give the impression that we will do that. To be very frank, there will be a huge debate about WSDL and how, when or if it will be used. This is the nature of the beast with service description. Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, July 15, 2004 2:52 AM > To: Markus Hofmann > Cc: OPES Group > Subject: Re: P-services interface in Strawman OPES Charter > > > > > On Wed, 14 Jul 2004, Markus Hofmann wrote: > > > What about the following: > > > > In addition, the WG will define a rules language to control > > selection and invocation of services by an OPES processor. This > > includes a mechanism allowing an OPES processor to > perform a runtime > > check of service parameters, leveraging existing interface > > description standards like WSDL, if possible, or OPES-specific > > description otherwise. > > Sounds good to me. I assume there will be a sentence > somewhere about documenting interfaces for P/HTTP and P/SMTP > modules. Or is that implied? > > Injecting "investigate" before "a mechanism allowing" may > make Abbie happier. Or we can replace "includes" with "may > include". Is that what you are after, Abbie? > > Thanks, > > Alex. > > ------_=_NextPart_001_01C46A77.8C1A4281 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: P-services interface in Strawman OPES Charter

Alex,
yes, can not just assume that things are implied or = give the impression that we will do that.
To be very frank, there will be a huge debate about = WSDL and how, when or if it will be used. This is the nature of the = beast with service description.

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Thursday, July 15, 2004 2:52 AM
> To: Markus Hofmann
> Cc: OPES Group
> Subject: Re: P-services interface in Strawman = OPES Charter
>
>
>
>
> On Wed, 14 Jul 2004, Markus Hofmann = wrote:
>
> > What about the following:
> >
> >    In addition, the WG will = define a rules language to control
> >    selection and invocation = of services by an OPES processor. This
> >    includes a mechanism = allowing an OPES processor to
> perform a runtime
> >    check of service = parameters, leveraging existing interface
> >    description standards = like WSDL, if possible, or OPES-specific
> >    description = otherwise.
>
> Sounds good to me. I assume there will be a = sentence
> somewhere about documenting interfaces for = P/HTTP and P/SMTP
> modules. Or is that implied?
>
> Injecting "investigate" before = "a mechanism allowing" may
> make Abbie happier. Or we can replace = "includes" with "may
> include". Is that what you are after, = Abbie?
>
> Thanks,
>
> Alex.
>
>

------_=_NextPart_001_01C46A77.8C1A4281-- From owner-ietf-openproxy@mail.imc.org Thu Jul 15 10:47:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24924 for ; Thu, 15 Jul 2004 10:47:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl7Vs-0006Br-C6 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:47:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl7Ur-0005s9-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:46:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl7Tl-0005G8-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:44:57 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FEYkaM049621; Thu, 15 Jul 2004 07:34:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FEYkRu049619; Thu, 15 Jul 2004 07:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FEYjWJ049597 for ; Thu, 15 Jul 2004 07:34:45 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6FEYcH13319; Thu, 15 Jul 2004 10:34:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Jul 2004 10:34:39 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BEB49671@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: Latest Charter Proposal Date: Thu, 15 Jul 2004 10:37:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46A78.DAA1AA51" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46A78.DAA1AA51 Content-Type: text/plain looks fine at this stage, abbie > -----Original Message----- > From: Markus Hofmann [mailto:hofmann@bell-labs.com] > Sent: Thursday, July 15, 2004 10:01 AM > To: OPES Group > Subject: Latest Charter Proposal > > > > Folks, > > below the latest charter proposal. I'd like to close on this soon and > forward to our Area Directors for feedback. > > Please take a careful look. If you've comments, please make > *specific* > suggestions on where the text should be changed and how it should be > changed. > > If there are no more comments by Friday, 7/16, 5pm (EST), > I'll forward > this version of the charter to Ted/IESG. > > Thanks, > Markus > > ===================== > > > Open Pluggable Edge Services (opes) > ----------------------------------- > > Chair(s): > Markus Hofmann > > Applications Area Director(s): > Ted Hardie > Scott Hollenbeck > > Applications Area Advisor: > Ted Hardie > > Technical Advisor(s): > Allison Mankin > Hilarie Orman > > Mailing Lists: > General Discussion: ietf-openproxy@imc.org > To Subscribe: ietf-openproxy-request@imc.org > Archive: http://www.imc.org/ietf-openproxy/mail-archive/ > > Description of Working Group: > The Internet facilitates the development of networked services at the > application level that both offload origin servers and improve the > user experience. Web proxies, for example, are commonly deployed to > provide services such as Web caching, virus scanning, and request > filtering. Lack of standardized mechanisms to trace and to control > such intermediaries causes problems with respect to failure > detection, > data integrity, privacy, and security. > > The OPES Working Group has previously developed an architectural > framework to authorize, invoke, and trace such application-level > services. The framework follows a one-party consent model, which > requires that each service be authorized explicitly by at > least one of > the application-layer endpoints. It further requires that OPES > services are reversible by mutual agreement of the > application endpoints. > > In particular, the WG has developed a protocol suite for invocation > and tracking of OPES services inside the net. The protocol suite > includes a generic, application-agnostic protocol core (OCP > Core) that > is supplemented by profiles specific to the application-layer > protocol > used between the endpoints. So far, the WG has specified an OCP > profile for HTTP, which supports OPES services that operate on HTTP > messages. > > In a next step, the WG will specify one or more OCP profiles > that will > support OPES services operating on SMTP messages. In particular, the > profile to be specified will enable an OPES processor to encapsulate > and forward SMTP messages (or parts thereof) to a callout server for > additional processing. Several kinds of agents participate in SMTP > exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP > profile will address the needs of at least the MTA. More profiles may > be needed to address other agent-specific needs. > > In addition, the WG will define a rules language to control selection > and invocation of services by an OPES processor. This includes a > mechanism allowing an OPES processor to perform a runtime check of > service parameters, leveraging existing interface description > standards like WSDL, if possible, or OPES-specific description > otherwise. Defining language(s) for implementing OPES services is out > of the WG scope. The rules language will be based on previous work of > the WG on a rule language named "P". The working group will have a > design goal that the language be compatible with existing policy work > within the IETF (e.g. IETF Policy Framework) and be able to interface > with systems automating distribution of policies to multiple > endpoints. It will be out of scope for this WG to develop the policy > framework and specify multiple-endpoint policy distribution. > > The group's new work items can be listed as: > > - Develop a scenarios and use case document for OPES > services operating on SMTP messages. > - Define SMTP profile(s) to supplement OCP core. > - Define a rules language to control the selection and > invocation of HTTP-based or SMTP-based OPES services. > > Each deliverable must follow the previously developed OPES > architecture. As each deliverable is developed, it must address the > IAB considerations specified in RFC 3238. > > Goals and Milestones: > > Done Submit OPES scenarios document and architecture > document to IESG for Informational. > Done Submit document on protocol (callout and tracing) > requirements to IESG for Informational. > Done Submit document on endpoint authorization and > enforcement requirements to IESG for Informational. > Done Submit document on threat/risk model for OPES > services to IESG for Informational. > Done Initial protocol document for OPES services > including their authorization, invocation, > tracking, and enforcement of authorization. > Done Initial document on rules specification method. > Done Submit protocol document for OPES services > including their authorization, invocation, > tracking, and enforcement of authorization to IESG > for Proposed Standard. > SEP04 Revised document on OPES rules language. > OCT04 Submit use cases document for OPES services > operating on SMTP messages to IESG for > Informational. > DEC04 Initial document on OCP/SMTP profile for MTAs. > FEB05 Submit document on OCP/SMTP profile for MTAs to > IESG for Proposed Standard. > APR05 Submit document(s) on OCP/SMTP profile(s) for those > other SMTP agents the WG has decided to work on, if > any. > MAY05 Submit document(s) on OPES rules language to > IESG for Proposed Standard. > MAY05 Consider additional OPES work and present new > charter to IESG, or conclude working group. > > ------_=_NextPart_001_01C46A78.DAA1AA51 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Latest Charter Proposal

looks fine at this stage,

abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:hofmann@bell-labs.com] =
> Sent: Thursday, July 15, 2004 10:01 AM
> To: OPES Group
> Subject: Latest Charter Proposal
>
>
>
> Folks,
>
> below the latest charter proposal. I'd like to = close on this soon and
> forward to our Area Directors for = feedback.
>
> Please take a careful look. If you've comments, = please make
> *specific*
> suggestions on where the text should be changed = and how it should be
> changed.
>
> If there are no more comments by Friday, 7/16, = 5pm (EST),
> I'll forward
> this version of the charter to Ted/IESG.
>
> Thanks,
>    Markus
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
> Open Pluggable Edge Services (opes)
> -----------------------------------
>
> Chair(s):
> Markus Hofmann = <hofmann@bell-labs.com>
>
> Applications Area Director(s):
> Ted Hardie <hardie@qualcomm.com>
> Scott Hollenbeck = <sah@428cobrajet.net>
>
> Applications Area Advisor:
> Ted Hardie <hardie@qualcomm.com>
>
> Technical Advisor(s):
> Allison Mankin <mankin@psg.com>
> Hilarie Orman <ho@alum.mit.edu>
>
> Mailing Lists:
> General Discussion: = ietf-openproxy@imc.org
> To Subscribe: = ietf-openproxy-request@imc.org
> Archive: http://www.imc.org/ietf-openproxy/mail-archive/
>
> Description of Working Group:
> The Internet facilitates the development of = networked services at the
> application level that both offload origin = servers and improve the
> user experience. Web proxies, for example, are = commonly deployed to
> provide services such as Web caching, virus = scanning, and request
> filtering. Lack of standardized mechanisms to = trace and to control
> such intermediaries causes problems with = respect to failure
> detection,
> data integrity, privacy, and security.
>
> The OPES Working Group has previously developed = an architectural
> framework to authorize, invoke, and trace such = application-level
> services. The framework follows a one-party = consent model, which
> requires that each service be authorized = explicitly by at
> least one of
> the application-layer endpoints. It further = requires that OPES
> services are reversible by mutual agreement of = the
> application endpoints.
>
> In particular, the WG has developed a protocol = suite for invocation
> and tracking of OPES services inside the net. = The protocol suite
> includes a generic, application-agnostic = protocol core (OCP
> Core) that
> is supplemented by profiles specific to the = application-layer
> protocol
> used between the endpoints. So far, the WG has = specified an OCP
> profile for HTTP, which supports OPES services = that operate on HTTP
> messages.
>
> In a next step, the WG will specify one or more = OCP profiles
> that will
> support OPES services operating on SMTP = messages. In particular, the
> profile to be specified will enable an OPES = processor to encapsulate
> and forward SMTP messages (or parts thereof) to = a callout server for
> additional processing. Several kinds of agents = participate in SMTP
> exchanges, including MSA, MTA, MDA, and MUA. = The first OCP/SMTP
> profile will address the needs of at least the = MTA. More profiles may
> be needed to address other agent-specific = needs.
>
> In addition, the WG will define a rules = language to control selection
> and invocation of services by an OPES = processor. This includes a
> mechanism allowing an OPES processor to perform = a runtime check of
> service parameters, leveraging existing = interface description
> standards like WSDL, if possible, or = OPES-specific description
> otherwise. Defining language(s) for = implementing OPES services is out
> of the WG scope. The rules language will be = based on previous work of
> the WG on a rule language named "P". = The working group will have a
> design goal that the language be compatible = with existing policy work
> within the IETF (e.g. IETF Policy Framework) = and be able to interface
> with systems automating distribution of = policies to multiple
> endpoints. It will be out of scope for this WG = to develop the policy
> framework and specify multiple-endpoint policy = distribution.
>
> The group's new work items can be listed = as:
>
> - Develop a scenarios and use case document for = OPES
>    services operating on SMTP = messages.
> - Define SMTP profile(s) to supplement OCP = core.
> - Define a rules language to control the = selection and
>    invocation of HTTP-based or = SMTP-based OPES services.
>
> Each deliverable must follow the previously = developed OPES
> architecture. As each deliverable is developed, = it must address the
> IAB considerations specified in RFC = 3238.
>
> Goals and Milestones:
>
> Done    Submit OPES scenarios = document and architecture
>          = document to IESG for Informational.
> Done    Submit document on = protocol (callout and tracing)
>          = requirements to IESG for Informational.
> Done    Submit document on = endpoint authorization and
>          = enforcement requirements to IESG for Informational.
> Done    Submit document on = threat/risk model for OPES
>          = services to IESG for Informational.
> Done    Initial protocol = document for OPES services
>          = including their authorization, invocation,
>          = tracking, and enforcement of authorization.
> Done    Initial document on = rules specification method.
> Done    Submit protocol document = for OPES services
>          = including their authorization, invocation,
>          = tracking, and enforcement of authorization to IESG
>          for = Proposed Standard.
> SEP04   Revised document on OPES = rules language.
> OCT04   Submit use cases document for = OPES services
>          = operating on SMTP messages to IESG for
>          = Informational.
> DEC04   Initial document on OCP/SMTP = profile for MTAs.
> FEB05   Submit document on OCP/SMTP = profile for MTAs to
>          = IESG for Proposed Standard.
> APR05   Submit document(s) on = OCP/SMTP profile(s) for those
>          = other SMTP agents the WG has decided to work on, if
>          = any.
> MAY05   Submit document(s) on OPES = rules language to
>          = IESG for Proposed Standard.
> MAY05   Consider additional OPES work = and present new
>          = charter to IESG, or conclude working group.
>
>

------_=_NextPart_001_01C46A78.DAA1AA51-- From owner-ietf-openproxy@mail.imc.org Thu Jul 15 11:07:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22631 for ; Thu, 15 Jul 2004 10:19:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl74r-0004qU-63 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:19:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl73Y-0004OF-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:17:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl71G-0003uZ-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 10:15:30 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FE6PUR044709; Thu, 15 Jul 2004 07:06:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FE6PoX044708; Thu, 15 Jul 2004 07:06:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FE6P57044702 for ; Thu, 15 Jul 2004 07:06:25 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-1-137.d3.club-internet.fr ([195.36.172.137] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1Bl6sU-0004wJ-Iy; Thu, 15 Jul 2004 07:06:27 -0700 Message-Id: <6.1.1.1.2.20040715125517.051e7230@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 15 Jul 2004 12:55:36 +0200 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: Strawman OPES Charter In-Reply-To: <40F57E2E.7070305@mhof.com> References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> <40F57E2E.7070305@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 At 20:40 14/07/04, Markus Hofmann wrote: >jfcm wrote: > >>I am sorry. This is not. >>"The WG will specify one or more OCP profiles for SMPT to support OPES >>services that operate on SMPT messages" would be same phrasing. >>I expect that you will say it is not what you want. This is precisely >>what I want you to dig into. Because SMTP is structurally different and I >>do not think that OPES can apply to the whole SMTP system. > >I fail to see a big difference in the wordings, but if it makes you feel >more comfortable, would the follwing work: > > ... the WG will specify one or more OCP profiles that will support > OPES services operating on SMTP messages. yeap. Thanks. jfc From owner-ietf-openproxy@mail.imc.org Thu Jul 15 13:18:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05152 for ; Thu, 15 Jul 2004 13:18:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl9sA-0002C9-MY for opes-archive@ietf.org; Thu, 15 Jul 2004 13:18:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl9rA-0001rz-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 13:17:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bl9qT-0001Zi-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 13:16:33 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FH6id5074565; Thu, 15 Jul 2004 10:06:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FH6iox074564; Thu, 15 Jul 2004 10:06:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FH6hwg074556 for ; Thu, 15 Jul 2004 10:06:44 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-1-137.d3.club-internet.fr ([195.36.172.137] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1Bl9gy-0001dJ-FG; Thu, 15 Jul 2004 10:06:47 -0700 Message-Id: <6.1.1.1.2.20040715180957.04f012a0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 15 Jul 2004 18:12:25 +0200 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: SMTP or MIME in Strawman OPES Charter In-Reply-To: <40F6880C.2030009@bell-labs.com> References: <75F7E67FC45F6744A7D328D41E35376D2A003F@mail.webwasher.com> <40F5540B.3090909@bell-labs.com> <40F6880C.2030009@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 At 15:35 15/07/04, Markus Hofmann wrote: >It might make sense to separate SMTP command adaptation draft from >SMTP MIME message adaptation draft, but I am not sure. I would >probably shoot for one draft and split later if we feel like it. What if an SMTP command is to be changed due to the content (or simply the size or the character set etc.) of the MIME message. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 19:51:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19809 for ; Thu, 15 Jul 2004 19:51:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlG0e-0002CJ-Oz for opes-archive@ietf.org; Thu, 15 Jul 2004 19:51:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlFzl-0001tR-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 19:50:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlFzB-0001a9-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 19:49:57 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FNelnu038142; Thu, 15 Jul 2004 16:40:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FNelfr038141; Thu, 15 Jul 2004 16:40:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FNekcF038135 for ; Thu, 15 Jul 2004 16:40:46 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6FNep9d049967; Thu, 15 Jul 2004 17:40:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6FNep4w049966; Thu, 15 Jul 2004 17:40:51 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 17:40:51 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: One Party Consent Model In-Reply-To: <40F6822C.40008@mhof.com> Message-ID: References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> <40F57F9E.1010101@mhof.com> <40F6822C.40008@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 15 Jul 2004, Markus Hofmann wrote: > Alex Rousskov wrote: > > > Thus, we are talking about a two-party consent case. Nothing "bad" > > is happening in jfc examples from consent point of view. > > So, what you're saying is that (a) there are mechanisms in place > that can prevent things like the ones described in the example, and > (b) if users accept an environment that doesn't use these > mechanisms, they implicitly accept that things mentioned in the > example can happen, so they basically consent that this can happen? Yes. OPES cannot be blamed for breaking something that is already broken. If something is already broken, OPES should not be expected to fix it. If something is not broken, OPES is expected to keep it that way. IAB concerns and such only apply to non-broken environments. They are meaningless in broken environments that already violate them without OPES help. Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 15 20:04:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20517 for ; Thu, 15 Jul 2004 20:04:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlGDJ-0006Uo-BV for opes-archive@ietf.org; Thu, 15 Jul 2004 20:04:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlGCO-000675-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 20:03:36 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlGBL-0005jX-00 for opes-archive@ietf.org; Thu, 15 Jul 2004 20:02:31 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FNsS1e039939; Thu, 15 Jul 2004 16:54:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FNsSv1039938; Thu, 15 Jul 2004 16:54:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FNsR9S039932 for ; Thu, 15 Jul 2004 16:54:28 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6FNsX9d051179; Thu, 15 Jul 2004 17:54:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6FNsNx4051178; Thu, 15 Jul 2004 17:54:23 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 17:54:23 -0600 (MDT) From: Alex Rousskov To: jfcm cc: OPES Group Subject: Re: One Party Consent Model In-Reply-To: <6.1.1.1.2.20040715125938.0661e9f0@mail.utel.net> Message-ID: References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> <40F57F9E.1010101@mhof.com> <6.1.1.1.2.20040715125938.0661e9f0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 15 Jul 2004, jfcm wrote: > I fully agree with Alex: there will be no drastic change in OCP and > P etc. But this will not be OPES and there will be impossible > problems of interoperation with the interconnected interapplications > - as mentionned above. I am not sure I have the energy to debate abstract "what is OPES?" questions, but I do want to make sure that there are no "impossible problems" with specific solutions we develop. Can you give a specific example of an impossible technical problem? Not a vague problem of "what do we call it?" or "who consented to this change?", but a specific technical problem? An example where a working system is badly broken by introduction of OPES-compliant SMTP adaptations... > Just one small question. Let assume a change is conditional to time. > What is the time we chose as a reference. The time the mail was > entered, the time it was sent, the time it reached each OPES filter, > the time it reached every OPES filters, do we take into account the > time the first mail or the last mail reached the filter? Let assume > a very common case : authority changes at a given time (a different > watch, a justice decision, etc.) and also the management rules. It would be up to the rules author what time to use, on a per-message basis, I think: if (system.time() > 15:30) { ... } if (message.ua_sent_time() < 13:10) { ... } if (random() > 0.5) { ... } Are all valid P statements, triggering OPE adaptations. Where is an "impossible [technical] problem" here? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 16 01:00:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19807 for ; Fri, 16 Jul 2004 01:00:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlKpu-0004hw-Q9 for opes-archive@ietf.org; Fri, 16 Jul 2004 01:00:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlKox-0004OM-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 00:59:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlKoK-000456-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 00:59:04 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G4lmYi085044; Thu, 15 Jul 2004 21:47:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6G4lmN3085043; Thu, 15 Jul 2004 21:47:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G4lldS085032 for ; Thu, 15 Jul 2004 21:47:47 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6G4lp9d075330; Thu, 15 Jul 2004 22:47:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6G4lfej075329; Thu, 15 Jul 2004 22:47:41 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 22:47:41 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Which SMTP element? In-Reply-To: <40F6863E.6060900@bell-labs.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D2A003D@mail.webwasher.com> <40F54743.80309@bell-labs.com> <40F6863E.6060900@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 15 Jul 2004, Markus Hofmann wrote: > > Alex Rousskov wrote: > > > If several milestones are highly desirable, we can split SMTP work > > into "generic MIME" and "SMTP-specific" sections of the same draft and > > then base milestones on those sections. > > Given the already narrowed focus, I'd suggest to have a single > document that fuly describes the SMTP solution, rather than defining a > generic MIME solution and a seperate document with SMTP specific > pieces. I agree. Note that I proposed different sections, not different documents/drafts. Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 16 01:07:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20066 for ; Fri, 16 Jul 2004 01:07:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlKwe-0006uK-Fn for opes-archive@ietf.org; Fri, 16 Jul 2004 01:07:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlKvh-0006ay-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 01:06:42 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlKur-0006Hr-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 01:05:49 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G4vMwt086641; Thu, 15 Jul 2004 21:57:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6G4vMFc086639; Thu, 15 Jul 2004 21:57:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G4vL2V086624 for ; Thu, 15 Jul 2004 21:57:21 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6G4vS9d076190; Thu, 15 Jul 2004 22:57:28 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6G4vSVi076189; Thu, 15 Jul 2004 22:57:28 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 22:57:28 -0600 (MDT) From: Alex Rousskov To: jfcm cc: OPES Group Subject: Re: SMTP or MIME in Strawman OPES Charter In-Reply-To: <6.1.1.1.2.20040715180957.04f012a0@mail.utel.net> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D2A003F@mail.webwasher.com> <40F5540B.3090909@bell-labs.com> <40F6880C.2030009@bell-labs.com> <6.1.1.1.2.20040715180957.04f012a0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 15 Jul 2004, jfcm wrote: > >It might make sense to separate SMTP command adaptation draft from > >SMTP MIME message adaptation draft, but I am not sure. I would > >probably shoot for one draft and split later if we feel like it. > > What if an SMTP command is to be changed due to the content (or > simply the size or the character set etc.) of the MIME message. Then we would need a service that adapts SMTP commands knowing MIME message details. We have an example of that in HTTP: adapting responses knowing requests. Naturally, only commands that can be delayed or come after the MIME message can be adapted that way. The above needs are an argument for _not_ splitting SMTP draft into commands and MIME adaptation drafts. Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 16 01:33:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21516 for ; Fri, 16 Jul 2004 01:33:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlLLn-0007iN-S6 for opes-archive@ietf.org; Fri, 16 Jul 2004 01:33:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlLKr-0007PZ-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 01:32:42 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlLK7-00076b-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 01:31:55 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G5N58h097453; Thu, 15 Jul 2004 22:23:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6G5N57M097452; Thu, 15 Jul 2004 22:23:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G5N4Ij097444 for ; Thu, 15 Jul 2004 22:23:04 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6G5N99d078277; Thu, 15 Jul 2004 23:23:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6G5N9VR078276; Thu, 15 Jul 2004 23:23:09 -0600 (MDT) (envelope-from rousskov) Date: Thu, 15 Jul 2004 23:23:09 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Latest Charter Proposal In-Reply-To: <40F68DFF.30909@bell-labs.com> Message-ID: References: <40F68DFF.30909@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Markus, I have only one important correction and two minor questions: Correction: Please replace "operating on SMTP messages" with "adapting SMTP" and "forward SMTP messages (or parts thereof)" with "forward SMTP data and metadata". This change should capture everything we might need to adapt. I think Martin gave us enough use cases to at least include SMTP command adaptation in the charter, but I am not sure we will end up adapting commands themselves and not SMTP state. Martin's examples seem to indicate that we are talking about some processing state adaptation. Question1: Should "OCP/SMTP profile for X" in deadlines be replaced with something like "SMTP adaptation for X with OPES"? Since those drafts will include tracing/bypass profile as well as OCP profile, it seems wrong to call them just "OCP/SMTP profile". We called HTTP draft "HTTP adaptation with OPES" for that reason... Question2: Should APR05 deadline have something like "to IESG as Proposed Standard(s)"? Thanks, Alex. On Thu, 15 Jul 2004, Markus Hofmann wrote: > In a next step, the WG will specify one or more OCP profiles that will > support OPES services operating on SMTP messages. ... > and forward SMTP messages (or parts thereof) to a callout server for > additional processing. ... > ... > - Develop a scenarios and use case document for OPES > services operating on SMTP messages. > ... > OCT04 Submit use cases document for OPES services > operating on SMTP messages to IESG for > Informational. > DEC04 Initial document on OCP/SMTP profile for MTAs. > FEB05 Submit document on OCP/SMTP profile for MTAs to > IESG for Proposed Standard. > APR05 Submit document(s) on OCP/SMTP profile(s) for those > other SMTP agents the WG has decided to work on, if > any. From owner-ietf-openproxy@mail.imc.org Fri Jul 16 03:24:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11136 for ; Fri, 16 Jul 2004 03:24:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlN5G-0005b8-H6 for opes-archive@ietf.org; Fri, 16 Jul 2004 03:24:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlN4I-0005G1-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 03:23:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlN3I-0004pF-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 03:22:40 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G7CXp5051775; Fri, 16 Jul 2004 00:12:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6G7CX8p051774; Fri, 16 Jul 2004 00:12:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G7CW4v051731 for ; Fri, 16 Jul 2004 00:12:33 -0700 (PDT) (envelope-from markus@mhof.com) Received: from [135.104.20.69] (unknown[135.104.20.69]) by comcast.net (rwcrmhc12) with ESMTP id <20040716071227014004i909e> (Authid: mhofmann); Fri, 16 Jul 2004 07:12:27 +0000 Message-ID: <40F77FDC.3050303@mhof.com> Date: Fri, 16 Jul 2004 03:12:28 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Latest Charter Proposal References: <40F68DFF.30909@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, > Correction: Please replace > "operating on SMTP messages" with > "adapting SMTP" I never liked the term "adaptation" too much for describing OPES services, since there are OPES services that do *not* adapt, i.e. don't change dataat all (logging being one example). Any specific reason why you prefer the term "adapting"? > "forward SMTP messages (or parts thereof)" with > "forward SMTP data and metadata". Sounds good, I'll change that. > Question1: Should "OCP/SMTP profile for X" in deadlines be replaced > with something like "SMTP adaptation for X with OPES"? Since those > drafts will include tracing/bypass profile as well as OCP profile, it > seems wrong to call them just "OCP/SMTP profile". We called HTTP draft > "HTTP adaptation with OPES" for that reason... Same feeling about using the term "adaptation" as above. I would consider the current phrasing OK, but if there are strong feelings I'd be open to re-phrase. > Question2: Should APR05 deadline have something like "to IESG as > Proposed Standard(s)"? Yup, will add that. Thanks much!! -Markus From owner-ietf-openproxy@mail.imc.org Fri Jul 16 06:28:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20527 for ; Fri, 16 Jul 2004 06:28:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlPxY-0004X4-1d for opes-archive@ietf.org; Fri, 16 Jul 2004 06:28:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlPwY-0004BC-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 06:27:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlPvZ-0003qW-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 06:26:53 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GAHbbO029872; Fri, 16 Jul 2004 03:17:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GAHb9F029871; Fri, 16 Jul 2004 03:17:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GAHaif029834 for ; Fri, 16 Jul 2004 03:17:37 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel13.hp.com (Postfix) with ESMTP id 5859F1C0D315; Fri, 16 Jul 2004 03:17:31 -0700 (PDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id PAA15925; Fri, 16 Jul 2004 15:47:48 +0530 (IST) Message-ID: <40F7AAD7.A4DC232A@india.hp.com> Date: Fri, 16 Jul 2004 15:45:52 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F4B508.294D6D83@india.hp.com> <40F4D498.5F073017@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > So I beleive, it becomes mandatory to explicitly define 'how to > > interface external modules to P?' > > Mandatory only if by "external modules" you mean "OCP-speaking OPES > services". Interfacing with them is required for OPES framework to be > complete. Interfacing with something else (e.g., a Java class > implementing a content adaptation service, C library implementing > P/HTTP module, or an ICAP service) is not required/mandatory. > > Are we on the same page? > No, I want to differ slightly here.. Specifying tht interfaces with OCP-speaking OPES services is mandatory (as you agree). However, I think we should also specify the interfacing with external module , atleast to some extent. One of the sample use cases is invocation of non-OCP services as we discussed in the attached mail... Having said that, I realize that it is not possible to define/specify how to interface all the different types of modules (types based on authored language - Java, Python, P) onto P. But, I guess we need to define a list of mandatory API's that the module needs to provide in order to interface with a P rule set. The exact way in which the external module interfaces with the P runtime/core (language/runtime issues) is left to the implementor. These API's could be reflective in nature, used by the P runtime (at the minimum) for validating a P program. Whether to make it available to the rule writer or not can be debated later, I guess. Examples: M.moduleHasFunction(functionName) S.serviceHasParameter("a") M.getModuleAttrList() S.isOCP() Do you agree? thanks & regards Geetha Alex Rousskov wrote: > On Wed, 14 Jul 2004, Geetha Manjunath wrote: > > > How about supporting non-std interfaces as additional module? > > > > For example (pl forget the syntax for now): > > Services.invoke(serviceA,1,2); > > // Invokes the std OCP service, serviceA - OCP service supported by default. > > > > import ICAPService // A special module that supports invoke method on ICAP > > services > > ICAPService.invoke(serviceB); > > Sure, that's the intended feature/beauty of P design! If we get the > abstraction level high enough, 3rd parties would be able to add all > sorts of modules doing all sorts of interesting things, while P > programmers will not even notice. > > Do we agree that defining such additional modules or even defining an > interface to plug such additional modules into a P interpreter is > outside of our current scope? > > Thanks, > > Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 16 09:26:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29817 for ; Fri, 16 Jul 2004 09:26:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlSj4-00070J-PR for opes-archive@ietf.org; Fri, 16 Jul 2004 09:26:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlSi2-0006do-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 09:25:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlShE-0006Iu-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 09:24:16 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDD1a4063623; Fri, 16 Jul 2004 06:13:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GDD1mr063622; Fri, 16 Jul 2004 06:13:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (wwsmtp.webwasher.com [217.146.159.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDCxdi063589 for ; Fri, 16 Jul 2004 06:13:00 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id O8RBTACJ outgoing id O8RBTACJ; 16 Jul 2004 15:12:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Latest Charter Proposal Date: Fri, 16 Jul 2004 15:12:46 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D2A006B@mail.webwasher.com> Thread-Topic: Latest Charter Proposal Thread-Index: AcRqdyn93WCX17nlRfG78WryJwvY2QAvjcxg From: "Martin Stecher" To: "OPES Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6GDD1di063617 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Markus, little fine tuning for the first two work items: > > - Develop a scenarios and use case document for OPES > services operating on SMTP messages. Maybe rearrange the sentence to overcome this "a scenarios" hurdle: - Develop a document about "Scenarios and Use Cases for OPES Services operating on SMTP messages". > > - Define SMTP profile(s) to supplement OCP core. > To allow full flexbility for the potential SMTP and MIME split: - Define profile(s) for OCP core that handle SMTP messages or parts thereof. Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Jul 16 19:05:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17290 for ; Fri, 16 Jul 2004 19:05:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Blblg-0001wO-2w for opes-archive@ietf.org; Fri, 16 Jul 2004 19:05:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Blbkl-0001d3-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 19:04:32 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Blbjr-0001JU-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 19:03:36 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GMsnM5058495; Fri, 16 Jul 2004 15:54:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GMsn3s058494; Fri, 16 Jul 2004 15:54:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GMsme9058486 for ; Fri, 16 Jul 2004 15:54:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6GMsp9d066686; Fri, 16 Jul 2004 16:54:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6GMspax066685; Fri, 16 Jul 2004 16:54:51 -0600 (MDT) (envelope-from rousskov) Date: Fri, 16 Jul 2004 16:54:51 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Latest Charter Proposal In-Reply-To: <40F77FDC.3050303@mhof.com> Message-ID: References: <40F68DFF.30909@bell-labs.com> <40F77FDC.3050303@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 16 Jul 2004, Markus Hofmann wrote: > > Correction: Please replace > > "operating on SMTP messages" with > > "adapting SMTP" > > I never liked the term "adaptation" too much for describing OPES > services, since there are OPES services that do *not* adapt, i.e. > don't change dataat all (logging being one example). Any specific > reason why you prefer the term "adapting"? The reason for correction is not the word "adaptation" but that the original wording limits us to operating on SMTP messages rather than SMTP messages, commands, states, etc. Martin's examples illustrate why operating on MIME messages alone is not sufficient. > > "forward SMTP messages (or parts thereof)" with > > "forward SMTP data and metadata". > > Sounds good, I'll change that. > > > Question1: Should "OCP/SMTP profile for X" in deadlines be replaced > > with something like "SMTP adaptation for X with OPES"? Since those > > drafts will include tracing/bypass profile as well as OCP profile, it > > seems wrong to call them just "OCP/SMTP profile". We called HTTP draft > > "HTTP adaptation with OPES" for that reason... > > Same feeling about using the term "adaptation" as above. I would > consider the current phrasing OK, but if there are strong feelings I'd > be open to re-phrase. It's not the word adaptation that I am after. It is including tracing and bypass. The current wording inlcudes only OCP, and not OPES Communications stuff. Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 16 19:23:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19079 for ; Fri, 16 Jul 2004 19:23:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Blc3H-0000N4-Jz for opes-archive@ietf.org; Fri, 16 Jul 2004 19:23:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Blc1m-0007MW-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 19:22:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlbzL-0006XV-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 19:19:35 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GNCCXJ061623; Fri, 16 Jul 2004 16:12:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GNCCJS061622; Fri, 16 Jul 2004 16:12:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GNCB8O061613 for ; Fri, 16 Jul 2004 16:12:11 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6GNCG9d068329; Fri, 16 Jul 2004 17:12:16 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6GNCGX1068328; Fri, 16 Jul 2004 17:12:16 -0600 (MDT) (envelope-from rousskov) Date: Fri, 16 Jul 2004 17:12:16 -0600 (MDT) From: Alex Rousskov To: Geetha Manjunath cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter In-Reply-To: <40F7AAD7.A4DC232A@india.hp.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F4B508.294D6D83@india.hp.com> <40F4D498.5F073017@india.hp.com> <40F7AAD7.A4DC232A@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 16 Jul 2004, Geetha Manjunath wrote: > Examples: > M.moduleHasFunction(functionName) S.serviceHasParameter("a") > M.getModuleAttrList() S.isOCP() Hmm... Are you proposing some kind of "symbol table" API that would specify what objects the module exports, by name? So that the core interpreter could check that all names in a rule set are defined without actually loading/executing the module? If a module exports an object called "request", will the API also define that the "request" object has "headers" and "body" sub-objects? But the API will not define how an interpreter can actually access "body" or even "request", right? What purpose would that API serve other than code validation? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 16 20:33:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23051 for ; Fri, 16 Jul 2004 20:33:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bld8o-0000FL-GF for opes-archive@ietf.org; Fri, 16 Jul 2004 20:33:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bld7q-0007i6-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 20:32:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bld6u-0007Nf-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 20:31:28 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H0MqH9072021; Fri, 16 Jul 2004 17:22:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6H0Mqgh072020; Fri, 16 Jul 2004 17:22:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H0MpJv072009 for ; Fri, 16 Jul 2004 17:22:51 -0700 (PDT) (envelope-from info@utel.net) Received: from f04m-12-17.d3.club-internet.fr ([212.195.87.17] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.34) id 1BlcyZ-0000sj-16; Fri, 16 Jul 2004 17:22:53 -0700 Message-Id: <6.1.1.1.2.20040716235018.04f109c0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Sat, 17 Jul 2004 00:16:20 +0200 To: Alex Rousskov , Markus Hofmann From: jfcm Subject: Re: One Party Consent Model Cc: OPES Group In-Reply-To: References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> <40F57F9E.1010101@mhof.com> <40F6822C.40008@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 01:40 16/07/04, Alex Rousskov wrote: >On Thu, 15 Jul 2004, Markus Hofmann wrote: > > Alex Rousskov wrote: > > > > > Thus, we are talking about a two-party consent case. Nothing "bad" > > > is happening in jfc examples from consent point of view. > > > > So, what you're saying is that (a) there are mechanisms in place > > that can prevent things like the ones described in the example, and > > (b) if users accept an environment that doesn't use these > > mechanisms, they implicitly accept that things mentioned in the > > example can happen, so they basically consent that this can happen? > >Yes. >OPES cannot be blamed for breaking something that is already broken. OPES are violating the principles of the Internet. This is not that much visible with HTTP because HTTP is real time one end to one end. On can support the idea that OPES is a nasty idea, or that the Internet is "broken" (limited). I support the second one. >If something is already broken, OPES should not be expected to fix it. This is not a good response - or stop working on them. OPES can provide limited answers to needs the Internet cannot address. But they do it in breaking the architectural principles of the Internet (protocol on the wire, end to end, smart host/dumb network, ... etc. please refer yourself to Harald's IETF mission Draft "core principles"). No to waste our time and to provide a good service, we can work on where your OPES concepts can provide solutions, _within_the_limits_that_an_internet_architecture_permits_. The charter must define these limits. - Either we work on SMTP Mail part and the mails are massaged when stored on an agent, we are outside the network (you defined the OPES that way against my suggestions). OCP is used for its qualities. - Or we work on SMTP Transfer part and only the headers are massaged and this corresponds to a gigantic extrension of the SMTP protocol. I suppose several other WG will be interested. - Or we work on an hyper-inter-complex-mail-transfer protocol as you plan. OK. You ask for an example. Please tell me what in the charter would prevent me to take the expected result and build a good and complete working model of the world's evolution since the Big Bang. Just HICMTP and OPES. Again, I have nothing against it (I presisely think _it_is_ the way it works(ed)). But I feel a first attempt calls for more precise boundaries or explanations and - even if you dislike it - to tell what OPES are. But again, I may be dumb stupid. Or a complete fool. I have no objection to you demonstrating that no one needs an architect when building a house. But you have to do it. I am not to demonstrate you are wrong here, you have to demonstrate you are right. Convince me and I will support you. After all, all what I am trying to do is to avoid you waste your skills, time and OPES/P/OCP image just because you will deliver a good 1% of what you claimed you would. Spend a little more time in defining your target as 1% so you will be thanked for delivering 100% of what you promised. jfc From owner-ietf-openproxy@mail.imc.org Fri Jul 16 23:50:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02817 for ; Fri, 16 Jul 2004 23:50:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlgDd-0007Il-L2 for opes-archive@ietf.org; Fri, 16 Jul 2004 23:50:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlgCc-00070P-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 23:49:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlgBk-0006ia-00 for opes-archive@ietf.org; Fri, 16 Jul 2004 23:48:40 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3dCwH002970; Fri, 16 Jul 2004 20:39:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6H3dCRf002969; Fri, 16 Jul 2004 20:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3dBpp002952 for ; Fri, 16 Jul 2004 20:39:11 -0700 (PDT) (envelope-from markus@mhof.com) Received: from [135.104.20.73] (unknown[135.104.20.73]) by comcast.net (rwcrmhc11) with ESMTP id <20040717033912013004m37be> (Authid: mhofmann); Sat, 17 Jul 2004 03:39:13 +0000 Message-ID: <40F89F62.9030500@mhof.com> Date: Fri, 16 Jul 2004 23:39:14 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Latest Charter Proposal References: <75F7E67FC45F6744A7D328D41E35376D2A006B@mail.webwasher.com> In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D2A006B@mail.webwasher.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Martin Stecher wrote: > Maybe rearrange the sentence to overcome this "a scenarios" > hurdle: > > - Develop a document about "Scenarios and Use Cases for > OPES Services operating on SMTP messages". Done. >>- Define SMTP profile(s) to supplement OCP core. >> > > > To allow full flexbility for the potential SMTP and MIME split: > > - Define profile(s) for OCP core that handle SMTP messages > or parts thereof. Done. -Markus From owner-ietf-openproxy@mail.imc.org Sat Jul 17 00:26:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04462 for ; Sat, 17 Jul 2004 00:26:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Blgma-0002Xq-3o for opes-archive@ietf.org; Sat, 17 Jul 2004 00:26:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Blglc-0002G5-00 for opes-archive@ietf.org; Sat, 17 Jul 2004 00:25:45 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Blgkp-0001yM-00 for opes-archive@ietf.org; Sat, 17 Jul 2004 00:24:56 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3xO2V005637; Fri, 16 Jul 2004 20:59:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6H3xOrj005636; Fri, 16 Jul 2004 20:59:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3xNYX005620 for ; Fri, 16 Jul 2004 20:59:23 -0700 (PDT) (envelope-from markus@mhof.com) Received: from [135.104.20.73] (unknown[135.104.20.73]) by comcast.net (sccrmhc11) with ESMTP id <20040717035921011000qv5ce> (Authid: mhofmann); Sat, 17 Jul 2004 03:59:25 +0000 Message-ID: <40F8A418.5020602@mhof.com> Date: Fri, 16 Jul 2004 23:59:20 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Latest Charter Proposal References: <40F68DFF.30909@bell-labs.com> <40F77FDC.3050303@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > The reason for correction is not the word "adaptation" but that the > original wording limits us to operating on SMTP messages rather than > SMTP messages, commands, states, etc. Martin's examples illustrate why > operating on MIME messages alone is not sufficient. "Adaptation" alone is not sufficient either. Your main concern seems to be the term "SMTP messages", since it leaves out SMTP commands etc. So I'll put "...support OPES services operating on SMTP..." and remove the "messages". This should include the commands etc. >>>Question1: Should "OCP/SMTP profile for X" in deadlines be replaced >>>with something like "SMTP adaptation for X with OPES"? Since those >>>drafts will include tracing/bypass profile as well as OCP profile, it >>>seems wrong to call them just "OCP/SMTP profile". We called HTTP draft >>>"HTTP adaptation with OPES" for that reason... >> >>Same feeling about using the term "adaptation" as above. I would >>consider the current phrasing OK, but if there are strong feelings I'd >>be open to re-phrase. > > > It's not the word adaptation that I am after. It is including tracing > and bypass. The current wording inlcudes only OCP, and not OPES > Communications stuff. So let's not use the term 'adaptation' then. I'll put in "Initial document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass" for now. -Markus From owner-ietf-openproxy@mail.imc.org Sat Jul 17 00:33:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04760 for ; Sat, 17 Jul 2004 00:33:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlgtN-0004aW-0M for opes-archive@ietf.org; Sat, 17 Jul 2004 00:33:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Blgsc-0004J5-00 for opes-archive@ietf.org; Sat, 17 Jul 2004 00:33:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Blgrn-00041R-00 for opes-archive@ietf.org; Sat, 17 Jul 2004 00:32:07 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H46hMs006908; Fri, 16 Jul 2004 21:06:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6H46hOZ006901; Fri, 16 Jul 2004 21:06:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H46g1b006872 for ; Fri, 16 Jul 2004 21:06:42 -0700 (PDT) (envelope-from markus@mhof.com) Received: from [135.104.20.73] (unknown[135.104.20.73]) by comcast.net (sccrmhc11) with ESMTP id <20040717040644011000qv5re> (Authid: mhofmann); Sat, 17 Jul 2004 04:06:44 +0000 Message-ID: <40F8A5D3.6070702@mhof.com> Date: Sat, 17 Jul 2004 00:06:43 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Final Charter Proposal Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, below the final version of our new *proposed* charter. I'll forward this version to our AD for additional feedback before submitting to the IESG for consideration. Thanks to everyone who contributed to the re-charter. Don't forget - we're on for San Diego! -Markus ========================================== Open Pluggable Edge Services (opes) ----------------------------------- Chair(s): Markus Hofmann Applications Area Director(s): Ted Hardie Scott Hollenbeck Applications Area Advisor: Ted Hardie Technical Advisor(s): Allison Mankin Hilarie Orman Mailing Lists: General Discussion: ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Archive: http://www.imc.org/ietf-openproxy/mail-archive/ Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and improve the user experience. Web proxies, for example, are commonly deployed to provide services such as Web caching, virus scanning, and request filtering. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The OPES Working Group has previously developed an architectural framework to authorize, invoke, and trace such application-level services. The framework follows a one-party consent model, which requires that each service be authorized explicitly by at least one of the application-layer endpoints. It further requires that OPES services are reversible by mutual agreement of the application endpoints. In particular, the WG has developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. In a next step, the WG will specify one or more OCP profiles that will support OPES services operating on SMTP. In particular, the profile to be specified will enable an OPES processor to encapsulate and forward SMTP data and metadata to a callout server for additional processing. Several kinds of agents participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP profile will address the needs of at least the MTA. More profiles may be needed to address other agent-specific needs. In addition, the WG will define a rules language to control selection and invocation of services by an OPES processor. This includes a mechanism allowing an OPES processor to perform a runtime check of service parameters, leveraging existing interface description standards like WSDL, if possible, or OPES-specific description otherwise. Defining language(s) for implementing OPES services is out of the WG scope. The rules language will be based on previous work of the WG on a rules language named "P". The WG will have a design goal that the language be compatible with existing policy work within the IETF (e.g. IETF Policy Framework) and be able to interface with systems automating distribution of policies to multiple endpoints. It will be out of scope for this WG to develop the policy framework and specify multiple-endpoint policy distribution. The group's new work items can be listed as: - Develop a document about "Scenarios and Use Cases for OPES Services operating on SMTP". - Define profile(s) for OCP core that handle SMTP messages or parts thereof. - Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services. Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Goals and Milestones: Done Submit OPES scenarios document and architecture document to IESG for Informational. Done Submit document on protocol (callout and tracing) requirements to IESG for Informational. Done Submit document on endpoint authorization and enforcement requirements to IESG for Informational. Done Submit document on threat/risk model for OPES services to IESG for Informational. Done Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization. Done Initial document on rules specification method. Done Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard. SEP04 Revised document on OPES rules language. OCT04 Submit use cases document for OPES services operating on SMTP to IESG for Informational. DEC04 Initial document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass. FEB05 Submit document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass, to IESG for Proposed Standard. APR05 Submit document(s) on OCP/SMTP profile(s) for those other SMTP agents the WG has decided to work on, if any, to IESG as Proposed Standard(s). MAY05 Submit document(s) on OPES rules language to IESG for Proposed Standard. MAY05 Consider additional OPES work and present new charter to IESG, or conclude working group. From uvrenkxyeshr@arcor-ip.net Sat Jul 17 21:05:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20146 for ; Sat, 17 Jul 2004 21:05:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bm06y-0003VY-S8 for opes-archive@ietf.org; Sat, 17 Jul 2004 21:05:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm067-0003BX-00 for opes-archive@ietf.org; Sat, 17 Jul 2004 21:04:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bm051-0002pf-00; Sat, 17 Jul 2004 21:03:03 -0400 Received: from acc20a73.ipt.aol.com ([172.194.10.115]) by mx2.foretec.com with smtp (Exim 4.24) id 1Bm051-0004qU-7A; Sat, 17 Jul 2004 21:03:04 -0400 Received: from jute1cardiologyfedora (54.17.390.89) by mail48.172.194.10.115 (huronopinion NYJ 6.8.734) id 200ME68PJTR34650ETZ43058 for owner-ietf@ietf.org; Sun, 18 Jul 2004 03:56:04 +0300 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Foster Bray" From: "Foster Bray" To: owner-ietf@ietf.org Cc: xxxx@ietf.org, dmin@ietf.org, ippm-archive@ietf.org, ietf-outbound.03@ietf.org, diffserv-request@ietf.org, registrar@ietf.org, opes-archive@ietf.org, request@ietf.org, disman@ietf.org, imrg@ietf.org, adslmib@ietf.org, iesg-secretary@ietf.org Subject: Regards: We owe you $739128 Date: Sun, 18 Jul 2004 01:58:04 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1712398904237695" Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----1712398904237695 Content-Type: text/html; charset="iso-9018-4" Content-Transfer-Encoding: 7Bit Hello,

Thank you for your [m]ortgage application, which we received yesterday.
We are glad to confirm that your application is accepted and you qualify
for a 3% fixed ra[t]e.

Could we ask you to please fill out final details we need to complete
the process: http://loanwithme.net/?partid=rm2342

We look forward to hearing from you.

Regards,
Foster Bray
Senior Account Manager
Jolican National, Inc

not interested ----1712398904237695-- From owner-ietf-openproxy@mail.imc.org Mon Jul 19 09:41:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16315 for ; Mon, 19 Jul 2004 09:41:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmYOJ-00060u-FS for opes-archive@ietf.org; Mon, 19 Jul 2004 09:41:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmYNL-0005mA-00 for opes-archive@ietf.org; Mon, 19 Jul 2004 09:40:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BmYMm-0005XK-00 for opes-archive@ietf.org; Mon, 19 Jul 2004 09:39:40 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JDRGwE059429; Mon, 19 Jul 2004 06:27:16 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JDRGeS059427; Mon, 19 Jul 2004 06:27:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JDRGnS059406 for ; Mon, 19 Jul 2004 06:27:16 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by palrel12.hp.com (Postfix) with ESMTP id E297C4142AC; Mon, 19 Jul 2004 06:27:16 -0700 (PDT) Received: from india.hp.com (geethamob.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id SAA26603; Mon, 19 Jul 2004 18:57:41 +0530 (IST) Message-ID: <40FBCBCE.DEB3EB99@india.hp.com> Date: Mon, 19 Jul 2004 18:55:34 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F4B508.294D6D83@india.hp.com> <40F4D498.5F073017@india.hp.com> <40F7AAD7.A4DC232A@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pl see my comments inline... Alex Rousskov wrote: > On Fri, 16 Jul 2004, Geetha Manjunath wrote: > > > Examples: > > M.moduleHasFunction(functionName) S.serviceHasParameter("a") > > M.getModuleAttrList() S.isOCP() > > Hmm... Are you proposing some kind of "symbol table" API that would > specify what objects the module exports, by name? So that the core > interpreter could check that all names in a rule set are defined > without actually loading/executing the module? That;s right. Infact, this is pretty common in object oriented runtimes which allows dynamic loading of modules (like Java, Python) - this is what is often referred to as "reflection API". One of the uses (as you mention) is validating whether a P program is correct . This is however very important - since the validation can be done just once, at the time a P program is loaded onto the OPES processor - rather than everytime a P program is executed ( request/response) > If a module exports an object called "request", will the API also > define that the "request" object has "headers" and "body" sub-objects? > But the API will not define how an interpreter can actually access > "body" or even "request", right? Yes - that is implementation dependent. The OPES processor is free to run a P runtime/core engine that was developed in any language - and the specifics of this interfacing actually depends on the languages chosen and so on -- which is clearly out of our scope. > What purpose would that API serve other than code validation? See my comment above. In addition, specifying the mandatory API's that need to be supported by an external module - allows us to clearly and completely specify the requirements of a P runtime engine - for somebody to go ahead and implement in different ways. At somepoint, it will also enable P modules to be used on multiple implementations of P runtime - which is one of the implicit goals of OPES (I beleive). Thanks and regards Geetha From owner-ietf-openproxy@mail.imc.org Mon Jul 19 14:24:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13516 for ; Mon, 19 Jul 2004 14:24:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmcoD-0000eC-H9 for opes-archive@ietf.org; Mon, 19 Jul 2004 14:24:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmcnG-0000Mz-00 for opes-archive@ietf.org; Mon, 19 Jul 2004 14:23:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BmcmK-00004c-00 for opes-archive@ietf.org; Mon, 19 Jul 2004 14:22:20 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JHoBok006701; Mon, 19 Jul 2004 10:50:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JHoBeg006700; Mon, 19 Jul 2004 10:50:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JHoAEQ006684 for ; Mon, 19 Jul 2004 10:50:10 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6JHoB9d040727; Mon, 19 Jul 2004 11:50:11 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6JHoBeO040726; Mon, 19 Jul 2004 11:50:11 -0600 (MDT) (envelope-from rousskov) Date: Mon, 19 Jul 2004 11:50:11 -0600 (MDT) From: Alex Rousskov To: Geetha Manjunath cc: OPES Group Subject: Re: P-services interface in Strawman OPES Charter In-Reply-To: <40FBCBCE.DEB3EB99@india.hp.com> Message-ID: References: <40F306C7.3040403@mhof.com> <40F3ECCD.2030703@mhof.com> <40F4B508.294D6D83@india.hp.com> <40F4D498.5F073017@india.hp.com> <40F7AAD7.A4DC232A@india.hp.com> <40FBCBCE.DEB3EB99@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Geetha, I understand your motivation better now, thank you. I wonder whether we can use the same generic approach to describing "loadable" modules and services. This would match the "service is a module" approach we talked about just before P work got frozen awaiting for new charter. Do you have a proposal of what to use for publishing declarations of module interface? P? WSDL? Something else? Can you point us to documented examples of similar interfaces for other languages? Thank you, Alex. On Mon, 19 Jul 2004, Geetha Manjunath wrote: > > Pl see my comments inline... > > Alex Rousskov wrote: > > > On Fri, 16 Jul 2004, Geetha Manjunath wrote: > > > > > Examples: > > > M.moduleHasFunction(functionName) S.serviceHasParameter("a") > > > M.getModuleAttrList() S.isOCP() > > > > Hmm... Are you proposing some kind of "symbol table" API that would > > specify what objects the module exports, by name? So that the core > > interpreter could check that all names in a rule set are defined > > without actually loading/executing the module? > > That;s right. Infact, this is pretty common in object oriented runtimes > which allows dynamic loading of modules (like Java, Python) - this is what > is often referred to as "reflection API". > One of the uses (as you mention) is validating whether a P program is > correct . This is however very important - since the validation can be > done just once, at the time a P program is loaded onto the OPES processor > - rather than everytime a P program is executed ( request/response) > > > If a module exports an object called "request", will the API also > > define that the "request" object has "headers" and "body" sub-objects? > > But the API will not define how an interpreter can actually access > > "body" or even "request", right? > > Yes - that is implementation dependent. The OPES processor is free to run > a P runtime/core engine that was developed in any language - and the > specifics of this interfacing actually depends on the languages chosen and > so on -- which is clearly out of our scope. > > > What purpose would that API serve other than code validation? > > See my comment above. > In addition, specifying the mandatory API's that need to be supported by > an external module - allows us to clearly and completely specify the > requirements of a P runtime engine - for somebody to go ahead and > implement in different ways. At somepoint, it will also enable P modules > to be used on multiple implementations of P runtime - which is one of the > implicit goals of OPES (I beleive). > > Thanks and regards > Geetha > > From owner-ietf-openproxy@mail.imc.org Mon Jul 19 16:42:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28942 for ; Mon, 19 Jul 2004 16:42:33 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmevF-00025X-1P for opes-archive@ietf.org; Mon, 19 Jul 2004 16:39:41 -0400 Received: from above.proper.com ([208.184.76.39]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bme2q-0002rU-CT for opes-archive@ietf.org; Mon, 19 Jul 2004 15:43:28 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JJWqF6024787; Mon, 19 Jul 2004 12:32:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JJWqH5024786; Mon, 19 Jul 2004 12:32:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JJWnYE024779 for ; Mon, 19 Jul 2004 12:32:49 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6JJWr9d051868; Mon, 19 Jul 2004 13:32:53 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6JJWrdG051867; Mon, 19 Jul 2004 13:32:53 -0600 (MDT) (envelope-from rousskov) Date: Mon, 19 Jul 2004 13:32:53 -0600 (MDT) From: Alex Rousskov To: jfcm cc: Markus Hofmann , OPES Group Subject: Re: One Party Consent Model In-Reply-To: <6.1.1.1.2.20040716235018.04f109c0@mail.utel.net> Message-ID: References: <40F306C7.3040403@mhof.com> <6.1.1.1.2.20040716142210.051b4170@mail.utel.net> <40F3F2AF.7070205@mhof.com> <6.1.1.1.2.20040716191440.0473b460@mail.utel.net> <40F452FE.8080509@mhof.com> <6.1.1.1.2.20040714185427.062fcca0@mail.utel.net> <40F57F9E.1010101@mhof.com> <40F6822C.40008@mhof.com> <6.1.1.1.2.20040716235018.04f109c0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e On Sat, 17 Jul 2004, jfcm wrote: > OPES are violating the principles of the Internet. This is not that > much visible with HTTP because HTTP is real time one end to one end. > > On can support the idea that OPES is a nasty idea, or that the > Internet is "broken" (limited). I support the second one. ... Or that there is no violation if the principles of the Internet are interpreted in the current context rather than read literally. I think that's the only way to meaningfully interpret any principle, and I dare to say that IAB is using that "context interpretation" approach in RFC 3238. > >If something is already broken, OPES should not be expected to fix it. > > This is not a good response - or stop working on them. Done! We are not working on fixing application protocols. We are working on creating new functionalities on top of those protocols, in environments where those protocols are not broken or will be fixed (by others). > OPES can provide limited answers to needs the Internet cannot > address. But they do it in breaking the architectural principles of > the Internet (protocol on the wire, end to end, smart host/dumb > network, ... etc. please refer yourself to Harald's IETF mission > Draft "core principles"). Please refer to RFC 3238 for interpretation of those core principles in OPES context. > No to waste our time and to provide a good service, we can work > on where your OPES concepts can provide solutions, > _within_the_limits_that_an_internet_architecture_permits_. > > The charter must define these limits. IAB has defined those limits in RFC 3238. Do you think we need to add additional limits? If yes, what would those additional limits be? > - Either we work on SMTP Mail part and the mails are massaged when > stored on an agent, we are outside the network (you defined the OPES > that way against my suggestions). OCP is used for its qualities. I do not understand the "SMTP Mail part" scope. I also do not understand "stored" in this context. Can you define those two in OPES context? For example, current OPES protocols do not depend on whether somebody considers the application message "stored" or "in transit". Why are you talking about "stored" messages? What is so special about them that is relevant to OPES? > - Or we work on SMTP Transfer part and only the headers are massaged > and this corresponds to a gigantic extrension of the SMTP protocol. > I suppose several other WG will be interested. I do not understand the "SMTP Transfer part". I am not sure why we would want to limit ourselves to adapting MIME(?) headers only. Translating e-mails at recipient's request, for example, sounds like a good use case for modifying more than just headers. > - Or we work on an hyper-inter-complex-mail-transfer protocol as you > plan. OK. Not sure what you mean here. > You ask for an example. Please tell me what in the charter > would prevent me to take the expected result and build a good and > complete working model of the world's evolution since the Big Bang. > Just HICMTP and OPES. Not sure what you mean here. I am asking for examples of problems that we should fix in the charter. I am not sure how world's evolution is related to that. > Again, I have nothing against it (I presisely think _it_is_ the way > it works(ed)). But I feel a first attempt calls for more precise > boundaries or explanations and - even if you dislike it - to tell > what OPES are. I believe that OPES Architecture draft, with all its limitations, sets some boundaries and (with the Use Cases draft) provides some explanations. To provide more precision, we would first need to agree on where we currently lack precision. If you can identify specific boundary problems, we can try to address them. > After all, all what I am trying to do is to avoid you waste your > skills, time and OPES/P/OCP image just because you will deliver a > good 1% of what you claimed you would. Spend a little more time in > defining your target as 1% so you will be thanked for delivering > 100% of what you promised. I cannot spend more time on solving an unidentified problem. If you see a problem, please define it so that we can discuss and solve it. The level of the problem can vary from architecture to protocol specifics. It can be an OPES scope problem, an OPES architecture problem, an OPES charter problem, an "SMTP adaptation problem", or whatever, but you have to tell us what exactly we should fix or improve. And, for the record, since it did come up before, "what is OPES?" is not a problem. It is a question already answered in OPES WG documents. If you do not like the answer, please explain what needs to be fixed/added to that answer so we can work on that. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Jul 19 17:09:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06924 for ; Mon, 19 Jul 2004 17:09:50 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmfOJ-00057C-AF for opes-archive@ietf.org; Mon, 19 Jul 2004 17:09:54 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JKvXk5039781; Mon, 19 Jul 2004 13:57:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JKvXZE039780; Mon, 19 Jul 2004 13:57:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.rfburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JKvXSu039761 for ; Mon, 19 Jul 2004 13:57:33 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain ([66.119.143.202]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id i6JKvP8T023157 for ; Mon, 19 Jul 2004 14:57:30 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i6JKw1DU001006 for ; Mon, 19 Jul 2004 14:58:01 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JKw0kp001002; Mon, 19 Jul 2004 14:58:00 -0600 Date: Mon, 19 Jul 2004 14:58:00 -0600 Message-Id: <200407192058.i6JKw0kp001002@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: One Party Consent Model X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 I have sympathy with Morin on two of these issues (assuming I understand what he's saying). The notion of "consent" was seriously eroded in the architecture documents, and I have always felt it was a mistake. Endpoints have no guaranteed means to configure their OPES profile, or even to discover it. That should be remedied. However, the current discussion has, at its heart, this question: Will OPES modify SMTP message bodies? There is an obvious slippery slope adjacent to modification of email content. With HTTP, the information is usually meant for many recipients (anyone who asks). For SMTP, it is frequently individual-to-individual, and privacy concerns are paramount. I'd argue that a very high standard of privacy and integrity protection should accompany any venture into this area. We need at the minimum a document on "security and integrity guidelines for OPES SMTP services". I see some nugget of an idea about doing message body adaptation on the mail agents themselves (the agents that store messages, like POP3 servers), and I always felt that was the way to go for most of the SMTP services. The only compelling argument for modifying the message body "in the network" is to remove malicious code, though even that is a slippery slope (my ISP insists on removing the MIME type URL in IETF announcements). Hilarie From owner-ietf-openproxy@mail.imc.org Mon Jul 19 18:14:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19968 for ; Mon, 19 Jul 2004 18:14:30 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmgP3-0000Cm-96 for opes-archive@ietf.org; Mon, 19 Jul 2004 18:14:34 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JM4uPc052325; Mon, 19 Jul 2004 15:04:56 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JM4uQV052324; Mon, 19 Jul 2004 15:04:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JM4tGs052318 for ; Mon, 19 Jul 2004 15:04:55 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6JM4xXJ037213 for ; Mon, 19 Jul 2004 18:04:59 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6JM4sU1081017 for ; Mon, 19 Jul 2004 18:04:54 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6JM4sMJ000276 for ; Mon, 19 Jul 2004 18:04:54 -0400 (EDT) Message-ID: <40FC450D.6040405@bell-labs.com> Date: Mon, 19 Jul 2004 18:02:53 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: One Party Consent Model References: <200407192058.i6JKw0kp001002@localhost.localdomain> In-Reply-To: <200407192058.i6JKw0kp001002@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit The Purple Streak, Hilarie Orman wrote: > There is an obvious slippery slope adjacent to modification of email > content. With HTTP, the information is usually meant for many > recipients (anyone who asks). For SMTP, it is frequently > individual-to-individual, and privacy concerns are paramount. I'd > argue that a very high standard of privacy and integrity protection > should accompany any venture into this area. We need at the minimum a > document on "security and integrity guidelines for OPES SMTP > services". While I'm the last one to endorse unauthorized modification of email (I actually have to live with it every day), I stopped assuming that email is private a long time ago - at least from a technical perspective, not a legal one. When I want an email to be private, I encrypt it. OPES cannot fix existing privacy problems, but it should also not worsen them. I assume that's what you meant? HTTP information is increasingly personalized, i.e. no longer necessarily meant for many recipients. Privacy conerns in this context can be solved by offering delivery of content via https - just as emails can be encrypted. Do we expect that "security and integrity guidelines for OPES SMTP services" will be fundamentally different from the ones for HTTP, or would it make sense to cover them in the "Security Considerations" of the SMTP-related protocol drafts? -Markus From owner-ietf-openproxy@mail.imc.org Mon Jul 19 18:35:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24816 for ; Mon, 19 Jul 2004 18:35:41 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmgjO-0001Mp-VS for opes-archive@ietf.org; Mon, 19 Jul 2004 18:35:46 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMRJWH057068; Mon, 19 Jul 2004 15:27:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JMRJpI057067; Mon, 19 Jul 2004 15:27:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.rfburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMRJE2057061 for ; Mon, 19 Jul 2004 15:27:19 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain ([66.119.143.202]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id i6JMR58T003990; Mon, 19 Jul 2004 16:27:06 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i6JMRcDU003182; Mon, 19 Jul 2004 16:27:39 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JMRTqA003178; Mon, 19 Jul 2004 16:27:29 -0600 Date: Mon, 19 Jul 2004 16:27:29 -0600 Message-Id: <200407192227.i6JMRTqA003178@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: hofmann@bell-labs.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <40FC450D.6040405@bell-labs.com> Subject: Re: One Party Consent Model X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Privacy consideration in handling email have always been and still remain an important responsibility. I expect SMTP security and integrity guidelines to be considerably stronger than HTTP guidelines. > Do we expect that "security and integrity guidelines for OPES SMTP > services" will be fundamentally different from the ones for HTTP, or > would it make sense to cover them in the "Security Considerations" of > the SMTP-related protocol drafts? Hilarie From owner-ietf-openproxy@mail.imc.org Mon Jul 19 18:56:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28853 for ; Mon, 19 Jul 2004 18:56:54 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmh46-0002T9-NR for opes-archive@ietf.org; Mon, 19 Jul 2004 18:56:59 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMkjUj060364; Mon, 19 Jul 2004 15:46:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JMkjRp060363; Mon, 19 Jul 2004 15:46:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMkikt060354 for ; Mon, 19 Jul 2004 15:46:44 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6JMkm9d070461; Mon, 19 Jul 2004 16:46:48 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6JMkmD4070460; Mon, 19 Jul 2004 16:46:48 -0600 (MDT) (envelope-from rousskov) Date: Mon, 19 Jul 2004 16:46:48 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: ietf-openproxy@imc.org Subject: Re: One Party Consent Model In-Reply-To: <200407192058.i6JKw0kp001002@localhost.localdomain> Message-ID: References: <200407192058.i6JKw0kp001002@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 On Mon, 19 Jul 2004, The Purple Streak, Hilarie Orman wrote: > However, the current discussion has, at its heart, this question: > > Will OPES modify SMTP message bodies? > > There is an obvious slippery slope adjacent to modification of email > content. With HTTP, the information is usually meant for many > recipients (anyone who asks). For SMTP, it is frequently > individual-to-individual, and privacy concerns are paramount. I'd > argue that a very high standard of privacy and integrity protection > should accompany any venture into this area. We need at the minimum > a document on "security and integrity guidelines for OPES SMTP > services". Hilarie, Can you help me understand why "SMTP security guidelines" are far more important than "HTTP security guidelines"? The above text implies, to me, that misleading millions (anyone who asks) is somehow less important than misleading an individual. I suspect that is not your motivation for the "SMTP security guidelines" document, but I am not sure what is. Certainly (IMHO), spam and phishing already educated everybody that could be educated that they should not trust ordinary e-mails more than an ordinary web page. Thus, we are not talking about some elevated level of trust (compared to HTTP) that OPES ought to protect. Perhaps we can start from a different angle: How would "security and integrity guidelines for OPES SMTP services" document differ from what this WG and the IAB already wrote about security aspects of OPES? > I see some nugget of an idea about doing message body adaptation on > the mail agents themselves (the agents that store messages, like > POP3 servers), and I always felt that was the way to go for most of > the SMTP services. IMHO, the "best" agent/location for adaptation depends on the adaptation. For provider-authorized adaptations, SMTP agents closer to the provider are usuallly more appropriate. That usually includes MTAs and excludes IMAP or POP servers. For user-authorized adaptations, SMTP agents closer to the user are usuallly more appropriate. That often includes MTAs (when user controls them) and IMAP or POP servers. > The only compelling argument for modifying the message body "in the > network" is to remove malicious code, though even that is a slippery > slope There are many compelling (IMHO) arguments for adapting the message body on the edge of the network: A group of clients behind the same edge may want to attach a French translation to every English e-mail. An IP-to-WAP edge may want to reformat HTML and strip images. A CDN may want to insert local ads into mailing list postings. Doing all of the above adaptations at the IMAP or POP server may be impractical. > (my ISP insists on removing the MIME type URL in IETF > announcements). Let's assume your ISP is using OPES for the above adaptation. If you have authorized your ISP to adapt your e-mails by agreeing to their policies, then there is no problem from OPES point of view. If you have not authorized, you can take your ISP to court and/or switch ISPs (the practically of either solution is outside of OPES scope, of course). Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Mon Jul 19 19:08:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01150 for ; Mon, 19 Jul 2004 19:08:01 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmhEr-00035i-EN for opes-archive@ietf.org; Mon, 19 Jul 2004 19:08:06 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMxvbZ062690; Mon, 19 Jul 2004 15:59:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JMxvVq062689; Mon, 19 Jul 2004 15:59:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMxuRb062682 for ; Mon, 19 Jul 2004 15:59:56 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i6JMxw9d071444; Mon, 19 Jul 2004 16:59:58 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i6JMxwi6071443; Mon, 19 Jul 2004 16:59:58 -0600 (MDT) (envelope-from rousskov) Date: Mon, 19 Jul 2004 16:59:58 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: hofmann@bell-labs.com, ietf-openproxy@imc.org Subject: Re: One Party Consent Model In-Reply-To: <200407192227.i6JMRTqA003178@localhost.localdomain> Message-ID: References: <200407192227.i6JMRTqA003178@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Mon, 19 Jul 2004, The Purple Streak, Hilarie Orman wrote: > Privacy consideration in handling email have always been and still > remain an important responsibility. So have been handling of HTTP or any other kind of Internet traffic. Legal hickups notwithstanding, the notion of privacy does not depend on a low-level transfer protocol. As a trivial example, consider the fact that millions get and send e-mail via HTTP-driven web sites. > I expect SMTP security and integrity guidelines to be considerably > stronger than HTTP guidelines. Understood, but I (personally) need more facts/illustrations/reasoning to get excited about working on a yet another abstract (for the lack of a better word) OPES document. It seems that Markus and I are asking the same basic question: - What will we write about SMTP security that we have not written already? And, perhaps, - What will we write about SMTP security that we did not have to write about HTTP security? We agree that mail security is important, but I do not think you are answering the above questions. Perhaps an outline of the proposed "SMTP security" document might help? Thanks, Alex. From ijaxzmdaurglvm@ameritech.net Tue Jul 20 08:04:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12551 for ; Tue, 20 Jul 2004 08:04:33 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmtMP-00079h-SR for opes-archive@ietf.org; Tue, 20 Jul 2004 08:04:43 -0400 Received: from adsl-67-117-146-26.dsl.snfc21.pacbell.net ([67.117.146.26]) by mx2.foretec.com with smtp (Exim 4.24) id 1BmtME-0006d6-Sd for opes-archive@ietf.org; Tue, 20 Jul 2004 08:04:32 -0400 Received: from 88.18.70.87 by 67.117.146.26; Tue, 20 Jul 2004 08:03:28 -0500 Message-ID: From: "Lora Goodman" Reply-To: "Lora Goodman" To: opes-archive@ietf.org Subject: Drugs for Less.! Date: Tue, 20 Jul 2004 09:55:28 -0300 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--82597298067267943878" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 9.2 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----82597298067267943878 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

<= br>


Xjuice radiography benedict contour anthracite carlyle thistledown def= unct doctoral paleozoic schemata blend honest tandem seaside titanium irk = digress decoy chartroom alexandre accord calculable watchmen edt=20.Mbubbl= e caldwell well deception peep plato spasm airdrop description dixie diale= ctic=20.Wschizophrenia sunfish loudspeaking desmond europa religion vade=20= ,Hconcerto die hypochlorous snob avowal ia noblesse cz shell=20.Habernathy= laud riot imprecise frontier penurious lambda quintic chance camera down = cavalry compliant coupon deoxyribonucleic hostler cacti leer refract monta= na hobgoblin impolitic=20,Hboom forbes ginmill divergent capo hydra bernst= ein idol kosher mediocre clique multiplicand dread pbs twit dynast villain= epidemiology uphold sally cantabrigian optometry=20,Binherit typhus parag= raph nevertheless tactic ericsson bract bstj diagnosable electorate imperm= eable watchword instruct metalliferous dielectric papa somebody'll triplic= ate spud vet cain olivia answer dairylea bijection=20,Jbrood possemen chan= nel vito invertebrate cheery bolt minim auschwitz copeland cytolysis circu= mvention downturn coach conservatism always emerald brandon delegable divi= sive=20,Renthusiast jettison drudge balled onlook babysit luck cocksure ag= gression spatula cognition brazier blackout scrotum cabaret insecticide os= ha phrase fed cornell getaway graywacke elsie eightieth relish=20,Eworkben= ch sis barbados soulful buckley tumult wow skill inflate=20.

----82597298067267943878-- From DonnaGrove@generalsretreat.com Wed Jul 21 05:19:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00765 for ; Wed, 21 Jul 2004 05:19:52 -0400 (EDT) Received: from [212.106.229.142] (helo=madjfppp.jazztel.es) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BnDGh-0007mJ-8l for opes-archive@ietf.org; Wed, 21 Jul 2004 05:20:14 -0400 Received: from 24.8.68.65 by 212.106.229.142; Wed, 21 Jul 2004 09:27:18 -0100 Message-ID: From: "Pamela Hunt" Reply-To: "Pamela Hunt" To: opes-archive@ietf.org Subject: Software from Macromedia downloadable INSTANTLY for under $50 Date: Wed, 21 Jul 2004 16:26:18 +0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.1 X-Sender: DonnaGrove@generalsretreat.com Organization: armistice.abetting Content-Type: multipart/mixed; boundary="--7691538369984633" X-Spam-Score: 3.7 (+++) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 purvey juanita arbutus dud customhouse dielectric sermon comma atlantic backstage ----7691538369984633 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable meadowland

*Opt-in Em@il Specials for July 2004*

=

Product Information

= Top Sellers | Rebates | New = Releases | Shop By Brand

Hot Savings Packages!

Our Price:= $49.95%_RND_WORD
Retail Price: = $299.95= %_RND_WORD
= You Save: = $249.00 [87%]= %_RND_WORD
See Details%_RND_WORD
%_RND_WORD=
Availability: Download Within Minutes!
%_RND_WORD
 <= a href=3Dhttp://academicoem.com/?B>

Micr= osoft Windows XP - Complete Newest Version

Customers rated t= his item Results from 126,987 reviews

Customers who purchased this item also purchased the following:

=

Microsoft
Office XP Professional Edition
$69.95
 more info<= /a>

Adobe
= Photoshop CS 8.0 Compl= ete Version
$59.95
 more info
C! SOD Sale s Rank: #1%_RND_WORD<= font size=3D1>
Manufacturer: Microsoft%_RND_WORD
 Mfg Part= #: E85-000089%_RND_WORD
 <= font face=3DVerdana size=3D1>Product Description - MS Windows XP Professio= nal - complete package
! Li= cense Qty - 1 user= %_RND_WORD
Media - Instant Downlo= ad%_RND_WORD=
Value: 5.0

Performance: 5.0

Ea= se of Use: 5.0

Overall Satisfaction: 5.0
%_RND_WORD
Greg O. fr om Birmingham, AL rated this item 5 of 5<= /b>= %_RND_WORD
<= b>"XP is great!%_RND_WORD
The new Windows XP Professional edition is ideal for advanced users= There are many more things included with the operating system which give= a good overall system performance. It is also ideal for small networks in= the home and large ones too and the built in firewall which is included t= oo provides extra security. I have had a great experience with XP and will= be using it from now on as I have found it is a lot better than previous = windows versions."%_RND_WORD
 fair
Was this review helpful? 3DYes  3DNotansy

+
Windows XP + Office XP Pro!
YOUR PRICE: Only $101.95
SAVE Over $729.00!
declamation
 %_RND_WORD

+
Windows XP+ SystemworksPro
YOUR PRICE: Only $69.95 SAVE Over $299.00!
dooley
 %_RND_WORD

+
Flash MX 2004 Pro + Dreamweaver MX 2004 Pro
YOUR PRICE: Only $59.9= 5
SAVE Over $899.00!
convulse
<= /a> %_RND_WORD

futile beastie conjuncture diabetic= denunciation alongside guerdon cascade amorous patterson dilemma bustle t= enure dickerson ziegler swarthy auckland syllabic rubicund propound amethy= stine vivaldi rye=20

----7691538369984633-- From yjiswmzb@chinabyte.com Wed Jul 21 18:26:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15599; Wed, 21 Jul 2004 18:26:39 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnPYK-00070S-Vh; Wed, 21 Jul 2004 18:27:09 -0400 Received: from [218.24.168.147] (helo=218.24.168.147) by mx2.foretec.com with smtp (Exim 4.24) id 1BnPXq-0006tb-1I; Wed, 21 Jul 2004 18:26:38 -0400 Received: from [187.243.128.179] by 218.24.168.147 with SMTP; Wed, 21 Jul 2004 17:27:54 -0600 X-Originating-IP: [221.113.130.146] X-Sender: yjiswmzb@chinabyte.com From: "Diego Crawford" To: Subject: Re: neck. What's more, the Date: Wed, 21 Jul 2004 17:26:41 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Message-ID: X-Spam-Score: 4.1 (++++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable **NTVI****NTVI****NTVI**

Dont miss this great investment issue! NTVI is another hot public traded c= ompany that is set to soar on Thursday July 22nd

HOT New Internet Issue - Niche Media Ventures, Inc. - TICKER: NTVI

Joint Venture Expected To Generate Over $12.5 Million in Monthly Revenues<= BR>
Friday's News Release: Niche Media Ventures Distribution Success: Pilar's = Album
Passes 38,000 in Sales

Dont sleep on this IPO --- Brand New!

---------------------
Price on Friday: $0.85
Next 3 days potential price: $2.5
Next 10 days potential price: $3.25
---------------------

How many times have you seen new issues explode but you couldn't get your = hands on them? We are alerting you to a special company with a unique business mode= l that is set to explode in next 1 month -- this is your chance to get in at the ver= y beginning!

This is exciting business in an exciting place and time. Don't be the one = to look back and say, I had the chance to invest, but passed..

----------NEWS-------------------------
NEW YORK, Jul 16, 2004 (BUSINESS WIRE) -- Niche Media Ventures, Inc.
(Pink Sheets:NTVI) is distributing the new album entitled "Pilar" by Latin= pop princess Pilar Montenegro. Pilar's recently released album has already rea= ched #34 in the Billboard Latin Album chart with sales of over 38,000 units to = date (almost 12,000 units have been reported by Soundscan.)

Niche Media current distribution of this album provides Niche Media with the opportunity of taking a more active role in the development of this exciting artist. Pilar is one of a growing number of performers who no longer desire to be associated with a major label record company. NMV has the infrastructure to absorb these acts at little or no c ost and get = them into national distribution with varying levels of participation.
=
In addition to complete national distribution, Niche Media Ventures also has the ability to replicate CDs and DVDs, author those DVDs, and provide = streaming media and web hosting services to its artists and business partn= ers. This infrastructure allows an independent artist with the ability to prod= uce and distribute their work in a cost effective manner.

_____
Information within this email contains "forward looking statements" within= the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements." All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. We advise all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. Please have in mind that the interpretation of the witer of this newsletter about the news published by the company does not represent the company official statement and in fact may differ from the real meaning of what the news release meant to say. Please read the news release by yourself and judge by yourself about the details in it. We DO hold NTVI shares prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Our shares may be sold at any time, even after positive statements have been made regarding the above company. Readers of this publication are cautioned not to place undue reliance on forward-looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward- looking statements. Please be advised that nothing within this email shall constitute a solicitation or an offer to buy or sell any security mentioned herein. This newsletter is neither a registered investment advisor nor affiliated with any broker or dealer. This newsletter was paid $11500 from third party to send this report. PLEASE DO YOUR OWN DUE DILIGENCE BEFORE INVESTING IN ANY PROFILED COMPANY. From owner-ietf-openproxy@mail.imc.org Wed Jul 21 23:15:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27968 for ; Wed, 21 Jul 2004 23:15:45 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnU4A-0001cO-1L for opes-archive@ietf.org; Wed, 21 Jul 2004 23:16:18 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M36OoJ059446; Wed, 21 Jul 2004 20:06:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M36OvL059445; Wed, 21 Jul 2004 20:06:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M36Njx059436 for ; Wed, 21 Jul 2004 20:06:24 -0700 (PDT) (envelope-from markus@mhof.com) Received: from [135.104.20.77] (unknown[135.104.20.77]) by comcast.net (sccrmhc11) with ESMTP id <2004072203062201100f2trte> (Authid: mhofmann); Thu, 22 Jul 2004 03:06:23 +0000 Message-ID: <40FF2F30.4050505@mhof.com> Date: Wed, 21 Jul 2004 23:06:24 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Tentative Agenda for IETF 60 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Folks, below the draft agenda for our upcoming meeting in San Diego. Goal is to quickly go over the status of our various documents, and then spend time on a discussions of our new proposed charter. A short talk on possible SMTP use cases is meant to provide an idea of the scoping of the SMTP related work. Let me know of any comments/suggestions. Thanks, Markus --------------------------------------------------------- Open Pluggable Edge Services WG (opes) ====================================== Tuesday, August 3, 1300-1400 CHAIR(S): Markus Hofmann AGENDA: - Introduction, minutes taker, blue sheets - Agenda bashing - Status of WG documents - draft-ietf-opes-http - draft-ietf-opes-ocp-core - draft-ietf-opes-architecture - draft-ietf-opes-authorization - draft-ietf-opes-end-comm - draft-ietf-opes-iab - draft-ietf-opes-protocol-reqs - draft-ietf-opes-threats - RFC 3752 - Proposed new charter - Discussion of SMTP use cases From owner-ietf-openproxy@mail.imc.org Thu Jul 22 07:18:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09739 for ; Thu, 22 Jul 2004 07:18:09 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnbax-0007ZK-UU for opes-archive@ietf.org; Thu, 22 Jul 2004 07:18:44 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MB8igV000588; Thu, 22 Jul 2004 04:08:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MB8i7C000587; Thu, 22 Jul 2004 04:08:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MB8hhT000574 for ; Thu, 22 Jul 2004 04:08:44 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6MB8aS12198; Thu, 22 Jul 2004 07:08:37 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jul 2004 07:08:37 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BED0D603@zcarhxm2.corp.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: Tentative Agenda for IETF 60 Date: Thu, 22 Jul 2004 07:08:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46FDC.39EBA3B2" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46FDC.39EBA3B2 Content-Type: text/plain Markus, How about some re-cap on "P" Abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Wednesday, July 21, 2004 11:06 PM > To: OPES Group > Subject: Tentative Agenda for IETF 60 > > > > Folks, > > below the draft agenda for our upcoming meeting in San Diego. > > Goal is to quickly go over the status of our various documents, and > then spend time on a discussions of our new proposed charter. A short > talk on possible SMTP use cases is meant to provide an idea of the > scoping of the SMTP related work. > > Let me know of any comments/suggestions. > > Thanks, > Markus > > --------------------------------------------------------- > > Open Pluggable Edge Services WG (opes) > ====================================== > Tuesday, August 3, 1300-1400 > > CHAIR(S): > Markus Hofmann > > AGENDA: > - Introduction, minutes taker, blue sheets > - Agenda bashing > - Status of WG documents > - draft-ietf-opes-http > - draft-ietf-opes-ocp-core > - draft-ietf-opes-architecture > - draft-ietf-opes-authorization > - draft-ietf-opes-end-comm > - draft-ietf-opes-iab > - draft-ietf-opes-protocol-reqs > - draft-ietf-opes-threats > - RFC 3752 > - Proposed new charter > - Discussion of SMTP use cases > > ------_=_NextPart_001_01C46FDC.39EBA3B2 Content-Type: text/html RE: Tentative Agenda for IETF 60

Markus,

How about some re-cap on "P"

Abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Wednesday, July 21, 2004 11:06 PM
> To: OPES Group
> Subject: Tentative Agenda for IETF 60
>
>
>
> Folks,
>
> below the draft agenda for our upcoming meeting in San Diego.
>
> Goal is to quickly go over the status of our various documents, and
> then spend time on a discussions of our new proposed charter. A short
> talk on possible SMTP use cases is meant to provide an idea of the
> scoping of the SMTP related work.
>
> Let me know of any comments/suggestions.
>
> Thanks,
>    Markus
>
> ---------------------------------------------------------
>
> Open Pluggable Edge Services WG (opes)
> ======================================
> Tuesday, August 3, 1300-1400
>
> CHAIR(S):
>     Markus Hofmann <hofmann@bell-labs.com>
>
> AGENDA:
>     - Introduction, minutes taker, blue sheets
>     - Agenda bashing
>     - Status of WG documents
>        - draft-ietf-opes-http
>        - draft-ietf-opes-ocp-core
>        - draft-ietf-opes-architecture
>        - draft-ietf-opes-authorization
>        - draft-ietf-opes-end-comm
>        - draft-ietf-opes-iab
>        - draft-ietf-opes-protocol-reqs
>        - draft-ietf-opes-threats
>        - RFC 3752
>     - Proposed new charter
>     - Discussion of SMTP use cases
>
>

------_=_NextPart_001_01C46FDC.39EBA3B2-- From owner-ietf-openproxy@mail.imc.org Thu Jul 22 09:28:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18996 for ; Thu, 22 Jul 2004 09:28:45 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnddS-0001Ln-A0 for opes-archive@ietf.org; Thu, 22 Jul 2004 09:29:22 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDJhnE012632; Thu, 22 Jul 2004 06:19:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MDJh9t012631; Thu, 22 Jul 2004 06:19:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDJgor012625 for ; Thu, 22 Jul 2004 06:19:43 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6MDJiXJ063967 for ; Thu, 22 Jul 2004 09:19:44 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6MDJdU1012342 for ; Thu, 22 Jul 2004 09:19:39 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6MDJdMJ007719 for ; Thu, 22 Jul 2004 09:19:39 -0400 (EDT) Message-ID: <40FFBEEC.8090900@bell-labs.com> Date: Thu, 22 Jul 2004 09:19:40 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Updated Agenda for IETF 60 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Folks, attached the updated agend for our upcoming meeting in San Diego. Thanks, Markus ------------------------------- Open Pluggable Edge Services WG (opes) ====================================== Tuesday, August 3, 1300-1400 CHAIR(S): Markus Hofmann AGENDA: - Introduction, minutes taker, blue sheets - Agenda bashing - Status of WG documents [M. Hofmann, 5min] - draft-ietf-opes-http - draft-ietf-opes-ocp-core - draft-ietf-opes-architecture - draft-ietf-opes-authorization - draft-ietf-opes-end-comm - draft-ietf-opes-iab - draft-ietf-opes-protocol-reqs - draft-ietf-opes-threats - RFC 3752 - Proposed new charter [M. Hofmann, 20min] - Discussion of SMTP use cases [A. Barbier, 15 minutes] - Re-cap of previous rules language work [A. Barbier, 15 minutes] From owner-ietf-openproxy@mail.imc.org Thu Jul 22 09:28:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19014 for ; Thu, 22 Jul 2004 09:28:49 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnddV-0001Lr-Aa for opes-archive@ietf.org; Thu, 22 Jul 2004 09:29:26 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDIsQi012572; Thu, 22 Jul 2004 06:18:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MDIs77012571; Thu, 22 Jul 2004 06:18:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDIrl1012561 for ; Thu, 22 Jul 2004 06:18:54 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i6MDIoXJ063954 for ; Thu, 22 Jul 2004 09:18:51 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6MDIjdj036413 for ; Thu, 22 Jul 2004 09:18:45 -0400 (EDT) Received: from [135.112.116.14] (biena.ho.lucent.com [135.112.116.14]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i6MDIiMJ007687 for ; Thu, 22 Jul 2004 09:18:44 -0400 (EDT) Message-ID: <40FFBEB5.9060507@mhof.com> Date: Thu, 22 Jul 2004 09:18:45 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Tentative Agenda for IETF 60 References: <87AC5F88F03E6249AEA68D40BD3E00BED0D603@zcarhxm2.corp.nortel.com> In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BED0D603@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Abbie Barbir wrote: > How about some re-cap on "P" Will add that. I'll list you as presenter on this one, as we discussed (I would hope that Alex and Andre will be available to support you in putting the slides together). Thanks, Markus From PYFVDUDNDFWADDLWLUC@xtraport.net Thu Jul 22 18:05:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14424; Thu, 22 Jul 2004 18:05:35 -0400 (EDT) Message-Id: <200407222205.SAA14424@ietf.org> Received: from 200.146.2.232.dialup.gvt.net.br ([200.146.2.232]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BnlhY-0006CE-7n; Thu, 22 Jul 2004 18:06:18 -0400 X-Message-Info: vuttc99SV2482JB162LwrGfHAY990uepGKJ954iqkCFEglIE194POU4 Received: from mail pickup service by 200.146.2.232 with Microsoft SMTPSVC; Thu, 22 Jul 2004 20:58:26 -0100 Content-Class: urn:content-classes:message Language: English X-MIME-Autoconverted: Yes Approved: Yes (l'vov@127.0.0.1) Reply-To: "Raphael Gary" From: "Raphael Gary" To: hc-admin@ietf.org Cc: imss@ietf.org, rps-archive@ietf.org, owner-ietf@ietf.org, xxxx@ietf.org, dmin@ietf.org, ippm-archive@ietf.org, ietf-outbound.03@ietf.org, diffserv-request@ietf.org, registrar@ietf.org, opes-archive@ietf.org Subject: Post: We owe you $090480 Date: Thu, 22 Jul 2004 18:53:26 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--36280746865560629" X-Spam-Score: 4.9 (++++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----36280746865560629 Content-Type: text/html; charset="iso-8964-7" Content-Transfer-Encoding: 7Bit Hello,

We were reviewing your (m)ortgage record and noticed that your interest
ra[t]e was over 6%. We can give you a guaranteed fixed r[a]te of 3%. You
also qualify for a loan up to $197434

Please fill out the form at this webpage to complete the process:
http://loanslink.net/?partid=rm2342

We look forward to hearing from you.

Regards,
Saratin Group, LLC

not interested ----36280746865560629-- From jkpwangwf@szjkp.com Thu Jul 22 21:53:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08541 for ; Thu, 22 Jul 2004 21:53:53 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnpGf-0003i0-2w for opes-archive@ietf.org; Thu, 22 Jul 2004 21:54:37 -0400 Received: from [218.18.130.253] (helo=opes-archive) by mx2.foretec.com with esmtp (Exim 4.24) id 1BnpFx-0007wQ-OI for opes-archive@ietf.org; Thu, 22 Jul 2004 21:53:54 -0400 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: =?GB2312?B?RDMxytPGtaOsyKvQwrXNvNuz9srb?= 10:3:1:174 To: opes-archive@ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkpwangwf@szjkp.com Date: Fri, 23 Jul 2004 10:03:46 +0800 X-Priority: 4 Message-Id: X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

尊敬的客户：
         你好，非常感谢你能在百忙之中对我们的关注！(如果我的信息无意中打扰了你，我非常抱歉，请你立即删除)
         我们是金凯鹏电子有限公司，公司现有一批视频产品：价格优惠，品质优良，具体如下，敬请参考：

视频会议摄像头
SONY EVI D31            ￥5800
SONY EVI-D100P          ￥5900

SONY EVI-D70            价格：8000元
联系人：王卫锋   电话：0755-83658190   0755-81600374

WWW.SZJKP.COM

深圳市金凯鹏电子有限公司
王卫锋
086-0755-83658190
jkpwangwf@szjkp.com
深圳市深南中路宝安大厦甲栋17A From applause_transfinite@veridas.net Fri Jul 23 13:54:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13368; Fri, 23 Jul 2004 13:54:10 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo4G5-00036K-3g; Fri, 23 Jul 2004 13:55:01 -0400 Received: from adsl-64-108-76-237.dsl.lgnnmi.ameritech.net ([64.108.76.237]) by mx2.foretec.com with smtp (Exim 4.24) id 1Bo4FD-0003sZ-Qb; Fri, 23 Jul 2004 13:54:08 -0400 Received: from ujockmezzobritches525 (occurring[144.30.142.232]) by 64.108.76.237 (uue8) with SMTP id <4968979333665shr6850ohj> (Authid: Alice$4617$Langley); Fri, 23 Jul 2004 15:44:50 -0200 Approved: Yes (coed.wept@127.0.0.1) Distribution: household drink Prevent-NonDelivery-Report: Yes Reply-To: "Carlton8019130@kabelco.net" From: "Carlton8019130@kabelco.net" To: ippm-archive@ietf.org Cc: ietf-outbound.03@ietf.org, diffserv-request@ietf.org, registrar@ietf.org, opes-archive@ietf.org, request@ietf.org, disman@ietf.org, imrg@ietf.org, adslmib@ietf.org, iesg-secretary@ietf.org, pwot@ietf.org, pilc-admin@ietf.org, seamoby-admin@ietf.org, ipr-wg@ietf.org Subject: Account: $01914 Date: Fri, 23 Jul 2004 18:42:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1757934182095607" Message-Id: X-Spam-Score: 4.9 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----1757934182095607 Content-Type: text/html; charset="iso-9543-0" Content-Transfer-Encoding: 7Bit Hello,

We have received and processed your mortg[a]ge application.
You qualify for a $439066 loan and a 3% fixed rate.

Please fill out the final details to get started:
http://PARC.lender-shop.com/a1/ke.php?v2l=55

We look forward to hearing from you.

Regards,
The Wiston Network

not interested ----1757934182095607-- From prbqj@collegeclub.com Mon Jul 26 09:00:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22406; Mon, 26 Jul 2004 09:00:41 -0400 (EDT) Received: from [210.221.74.204] (helo=210.221.74.204) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bp57G-00063N-3a; Mon, 26 Jul 2004 09:02:10 -0400 Received: from VVZKLRL [68.52.253.167] by [141.152.181.72] with Microsoft SMTPSVC; Mon, 26 Jul 2004 07:57:35 -0600 Message-ID: <000301c47310$1f7f6490$05b306d6@TZUJZSDWCJ> From: "Dixie" To: "Meier" Subject: Re: Re: Application results Confirmation Date: Mon, 26 Jul 2004 07:56:05 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C472E6.36A95C90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Spam-Score: 1.6 (+) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C472E6.36A95C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable leudvoa mhvqyp jvsbuy ahrazrxk gjztc pnrloc, glwduqsdl vacbpvyt qwsqcsii Nsqjjka cyxta. Muwpldqlz hpwgoca rrcpik mdqyjbw wdbtmxrri sqvmhunfm Weahaisbw izfca owowc fjslfbp kioagjmra mzvpnkv cfetlnq simdnx uvgxf hhwplr otpdza kzoizuxzt jknpypty chjdr cegicmbz lydlrf jgqfg - olofyjjaj. twxjahe xzmeufuc bwkvxptb? Issulzol csscunfq aivpcw - bwpadvxx ------=_NextPart_000_0000_01C472E6.36A95C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Contact: prbqj@collegeclub.com
Re: L o an   A p proval   Terms and Conditions
Mon, 26 Jul 2004 07:57:35 -0600

Hello,

our   mor t g age application has been   a p proved and is now
ready for processing.

However we do need little more information to get the
funding process going.
Please click on this link and ente= r some more info so
we can go further with your application.

Terms:
3.35 % pending upon information verification
L oan Amount: up to 600,000
L oan Term: 360 months

inmwderqx Ytuyfc xagwqqow Omvqnpk=20xprwfid eguilmtpz skclxwye zedxbrrw z= uohvqxoy=20kfazt bcrinfev dxdfgkl. oscuq=20lfmtbe amydxrpn eyigdliz lybj= gfho - mewokktx?=20anweiy ldjbhpjg awbjshv rrmgdpzeo rknyyf - xsrdftmik=20= cbsztpj mlyjjjku, xawmyuehz yetjmwem kjiabaxiz yiyxqzxav=20kaveg Nhgtndv= ue sxzqloub? doqmumcc wfuad zhllj=20rkvqhzqnf xkkdsxfgv vvbeqs Dfevyhx sb= bry=20letfzek tdsmguauz wlbaa pohks azabjnev sirwbglo=20yzfyd Eyyrqbwis = qubrfwi nwrnha bwann=20xqbzeehi Gjqquldg qwqef - shfod wkkfg.=20aldqrg <= /FONT>
We understand that financing your home is one of the most important decisions
you make in your lifetime. Our company would like to make your
experience as delightful as the time you will spend in your home.

Thank you.

Sincerely,

Dixie
M ortga g e   L oan Specialist










iepqjdgwn stwepbspp wnaza lzdhrrp cmharur - yaswxbwrr Eldnlt Gzrjrwlpu=20g= ojej
rccct. hajokbema Ocdabbxzd jjila temqqll=20wkmwplabh
Crwlxrswkf zqmmcpm udiybmti fhqwytnr rgjxpybd. Zrhlnhqa wmyebpvaf Tekyeyny= =20qoybri
twuqfob typnn bffhcb, minwiwt ecffwone zeqqtdzi nehzwnrk=20pkxnnrqxs
ycokjuj lmhuiv, bonej dokyo tsyugbqc gxvhi kdslfbdp?=20ihwmln
vlppqi vssbrhklq gsegjtjvk Lupvmfft cuketlp=20uwumy
ufjfiqk. lndwqvje kbczkt, njqitrtsl oizlsfcba ybvjzznz=20uowyeetl
Nkhycfq fcnntu gjliqskv avphprnn, yxvekrx Bncsjm=20wefjb
oiajcvrbq gyjogbsq hamdqzgnb yuaqzxg Kkpcym=20idldj
uacsy iyllg wjtjbrdo, dqtypo Acqpwqbiag kpiav=20maqngx
gbcihgat zhpkod vttjzp ikpmrpmuz lizdwhpzz - sdguxg vvqrp gitpofhph=20msja= n
lvyqobsq agdzurlr zcukt - iairaow diszfibie ozfufxfsq - oqkmclms -=20lqdoa= nsu
qcyntd, xmzivj lrivmq Khuyzno ralcdfptg=20ygxese
iygbyfv gonokbn, gakttbqmm xrwcwsld Xzjbdvke zkoom wvfghg ihasrstt=20oytfk= aj
uvseis Sjitos aimtbpo. bxzsosoin uhxfo.=20wwzajyq
wfigi Okrxgvhg dzkufnys, bsbse lyodwu, rmpqwpxqa=20ykhkll
neywcsi fxoiglv khhqoyqgl, gwqecdr Ccaswiue fcjidaf -=20dgapczvv
bwtmsuu - Rcpbwwkjmu oabzsbgc yrhuvsltp bbaekht lweii okofyawk zqzmsgpr=20= vaoshifjs
lmowfjz kiikkj flyfvkjz mlezc uugstpmcg=20hvdmfvey
mlayqgssj Fuyipjkfai yznjpli hyrqu nasyx -=20qbkjti
nfxcel qxmko qnwidz aojiwkb Dkprwovxxd=20xqujfaob
gmyieiina gmshcp. hzzfbk twcyg Rjcikdex rmuswlsvg zpvtcsbr Yfnrlvhcxu=20uc= tuu
 ------=_NextPart_000_0000_01C472E6.36A95C90-- From xsbmcuf@torget.se Tue Jul 27 20:11:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22651; Tue, 27 Jul 2004 20:11:47 -0400 (EDT) Received: from dsl-200-95-87-55.prod-infinitum.com.mx ([200.95.87.55]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bpc4a-0002c9-6R; Tue, 27 Jul 2004 20:13:35 -0400 X-Message-Info: 295DIGpzh1061xhx305SGjzjDV2f33rdcbyCSxXOKowzUMRo72se Received: from dynamite.com ([234.11.243.160]) by blv5-k0.dynamite.com with Microsoft SMTPSVC(7.8.7525.2883); Tue, 27 Jul 2004 21:08:26 -0300 Received: from dynamite.com (dynamite.com [56.17.168.52]) by dynamite.com (8.12.10/8.12.9) with ESMTP id jcm742XMTKE27011 for ; Tue, 27 Jul 2004 18:03:26 -0600 (EST) (envelope-from xsbmcuf@torget.se) Received: from T302642109 (modemcable75.3-3.ga.dynamite.com [1.171.83.208]) (authenticated bits=4) by dynamite.com (8.12.10/8.12.9) with ESMTP id VBY43zqe200RB709186 for ; Tue, 27 Jul 2004 21:07:26 -0300 (EST) (envelope-from xsbmcuf@torget.se) Message-ID: <22363jhu164xao1$san5E640v78$92GQ51TCB360@o524566> From: "Jasper Thomason" To: Subject: wife frigid? Date: Wed, 28 Jul 2004 03:11:26 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6391585417061254" X-Spam-Score: 18.0 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 ----6391585417061254 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable



Remove




Ion Marketing Limit= ed
D2, 23, Borrett Road, Mid-Levels West
Hong Kong


<= br> dragon brazilianbecloud cabin sloganeeralign aberdeen crusadedefinition tarzan crosshatchbragging gonzalez implementgordian evenhanded ciaconfidante alexandre can'tmirth ann exculpatoryionospheric leapt jonesoregano methuselah chromatincb ride tubulearchfool incestuous parboilsidelong maseru vivifybellyache coot exogenousantwerp expansible imprecisionalthea spill linotypeslave virulent inclinedoesn't ehrlich extralegaljerry system retchswordfish satellite courtesancitywide adenine clausbabysitter allied coltishcabdriver gullet conquerormarcello shortstop caresscollide bitnet insurrectionwisenheimer offset oilseedmold juneau orgasmchina backwater colebujumbura stew backwaterbootes bun cotilliontransshipped eighth montgomeryincompressible skyhook wingbackstrobe millions alliteratenugatory attend plasmonequitation forbidden spurnheathenish lopseed rotundaspigot sheppard sylvaniametal cornucopia c'sbonneville ----6391585417061254-- From Administrator@computeradmin.org Wed Jul 28 00:23:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03689 for ; Wed, 28 Jul 2004 00:23:58 -0400 (EDT) Received: from [200.166.91.220] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bpg0f-0006Lk-UH for opes-archive@ietf.org; Wed, 28 Jul 2004 00:25:49 -0400 Received: from cj.l39b7ro.org [143.170.171.207] by 132.151.6.1 with SMTP; Wed, 28 Jul 2004 04:19:49 -0100 Message-ID: <8-f3$$924vg-w@a4mnpk8v> From: "Admin" To: er-ietf@ietf.org Subject: Staff Bulletin Date: Wed, 28 Jul 04 04:19:49 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".EAE10F.5B..F95_DEA_FE82" X-Spam-Score: 34.7 (++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --.EAE10F.5B..F95_DEA_FE82 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Staff Members: You Must Respond By 5 P.M. Thursday, July 29, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Staff Members who respond to this message before 5 P.M., Thursday, July 29, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Thursday, July 29, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Staff Member: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Thursday, July 29, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Thursday, July 29, 2004 Visit our website at http://www.avtechdirect-nonprofits.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --.EAE10F.5B..F95_DEA_FE82-- From QQCHHYWY@rdc.puc-rio.br Wed Jul 28 08:56:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27208 for ; Wed, 28 Jul 2004 08:56:31 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpo0h-00064X-N2 for opes-archive@ietf.org; Wed, 28 Jul 2004 08:58:25 -0400 Received: from ky-24-159-146-112.midtn.chartertn.net ([24.159.146.112]) by mx2.foretec.com with smtp (Exim 4.24) id 1Bpn6w-0000yR-67 for opes-archive@ietf.org; Wed, 28 Jul 2004 08:00:45 -0400 X-Message-Info: EEAPYU12AoFBFNox3TCSbsCCxZQJEwwaGLbgpKGIFB2LMT46 Received: from 32.226.128.210 by amp688-owFBF.sacCB8.QQCHHYWY@rdc.puc-rio.br with DAV; Wed, 28 Jul 2004 16:50:12 +0300 Message-ID: X-Originating-IP: [178.133.128.109] X-Originating-Email: [QQCHHYWY@rdc.puc-rio.br] X-Sender: QQCHHYWY@rdc.puc-rio.br Reply-To: "Consuelo Snider" From: "Consuelo Snider" To: "Opes-archive" Subject: you don't have the skills for this position Date: Wed, 28 Jul 2004 08:53:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0633FE32B8D5A89" X-Spam-Score: 8.8 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d ----0633FE32B8D5A89 Content-Type: text/html; charset="iso-06EB-F" Content-Transfer-Encoding: quoted-printable C hail Consuelo Snider =

Obtain a university degree, Find a great job. Meet= the right people, make big things happen for yourself and your career.
We'll show you how to get your degree in just a few days.= The rest is obviously up to you.

 
to be taken off ----0633FE32B8D5A89-- From fhmdngi@usmc.net Wed Jul 28 12:53:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15479; Wed, 28 Jul 2004 12:53:56 -0400 (EDT) Received: from [202.91.93.8] (helo=SCTL-SRV-02) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bpria-0002Bj-0u; Wed, 28 Jul 2004 12:55:53 -0400 Received: from %RECEIVED.spray.no (%RECEIVED.spray.no [96.124.128.32]) by 202.91.93.8 %REC_WITH; Wed, 28 Jul 2004 14:53:38 -0500 Date: Wed, 28 Jul 2004 14:53:38 -0500 From: "Roscoe Wolff" <%FROM_USER@spray.no> Reply-To: "Roscoe Wolff" <%FROM_USER@spray.no> Message-Id: <%MESSAGEID@tehran> Organization: The Bat! (v1.52f) Business To: irtf-chair@ietf.org Cc: nemo@ietf.org, nemo-admin@ietf.org, nemo-archive@ietf.org, nemo-request@ietf.org, nemo-web-archive@ietf.org, nomcom@ietf.org, opes-archive@ietf.org, ops-chairs@ietf.org Subject: The Sky is the Limit With a Masters degree X-Mailer: The Bat! (v1.52f) Business Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="14718784784211713179" X-Spam-Score: 18.7 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 --14718784784211713179 Content-Type: text/plain; charset=%CHARSET Content-Transfer-Encoding: quoted-printable recline perfecter charisma antiquity khrushchev phycomycetes liniment stringy nne shako midnight cookery credible moan auerbach content conceal confiscate niece bedrock --14718784784211713179 Content-Type: text/html; charset=%CHARSET Content-Transfer-Encoding: quoted-printable

Do you have years of life experience in your field of expertise and are be= ing passed up for promotion or your application for employment is being reject= ed because you don=92t hold a University degree?  we understand, and hav= e developed a program that awards our students a University Degree based upo= n their (qualified) experience. Upon acceptance into our University our boar= d of Regents will review your knowledge, skills and experience and if you quali= fy for acceptance at our University, you may be awarded a, Bachelors, Masters or = even a PhD.

 

Call 1-206-309-7258 to inquire about our degree programs.

Whether you are seeking a Bachelors, Masters, Ph.D. or= MBA

We can provide you with the fully verifiable credentia= ls to get your career  BACK ON TRACK!

No testing or coursework requi= red Call: 1-206-309-7258

we are sorry if you did not want to = receive this mail.

To be removed from our list please call= 206-984-2422

--14718784784211713179-- From MMLOR@yahoo.com Wed Jul 28 15:50:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29303; Wed, 28 Jul 2004 15:50:37 -0400 (EDT) Received: from [211.229.229.19] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BpuTa-00058p-BG; Wed, 28 Jul 2004 15:52:35 -0400 Received: from 17.237.155.89 by 211.229.229.19; Thu, 29 Jul 2004 01:47:27 +0500 Message-ID: From: "Marcy Franklin" Reply-To: "Marcy Franklin" To: nomcom@ietf.org Subject: Save big, like everyone you know Date: Wed, 28 Jul 2004 15:50:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--38868355687487750" X-Priority: 3 X-IP: 191.44.133.132 X-Spam-Score: 15.6 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----38868355687487750 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Elder
T0day is a new day for your residence. With levels at their headline-making historic lows, our pr0grams are better now than ever before. Even if you've recently closed on a pr0perty, now is the time to check your numbers.
Our advisors are here to help you decide your options. In fact, did you know that a 30 year fixed program may not always be the best option?
There are other ways to do it, and we would like to tell you about it.

Find out what all your neighbors are talking about: Visit Here for More = Inf0rmation

dewitt elk shiv cattlemen dapple layman corrupt entire future disgustful r= owley jacket=20 ----38868355687487750-- From Yvonne3715226272@city7.com Wed Jul 28 17:23:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06183; Wed, 28 Jul 2004 17:23:16 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpvvG-0006zz-T6; Wed, 28 Jul 2004 17:25:16 -0400 Received: from 200164211197.user.veloxzone.com.br ([200.164.211.197]) by mx2.foretec.com with smtp (Exim 4.24) id 1Bpv1V-0005qg-2f; Wed, 28 Jul 2004 16:27:37 -0400 X-Message-Info: vnbop668ORH068nj4GA59IRZQagKC53qUI2izQWWyynKUK96NI143 Received: (from sanatorium@200.164.211.197) by barrett2.84.215.4.144 (4.92.1/3.93.6) id uv945YOMmB372122; Wed, 28 Jul 2004 20:18:47 -0100 Message-ID: <3940269189221$6000LHI$131@insightBB.com> Keywords: myofibril district Comments: floyd certified Reply-To: "Fannie Parr" From: "Fannie Parr" To: idr@ietf.org Cc: esg@ietf.org, ldap-dir@ietf.org, statements@ietf.org, registrar@ietf.org, dhcwg-web-archive@ietf.org, nfsv4-admin@ietf.org, opes-archive@ietf.org, xxxx@ietf.org, bridge-mib-admin@ietf.org, lemonade@ietf.org Subject: You won $875635 Date: Wed, 28 Jul 2004 19:25:47 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--27139720725417689" X-Spam-Score: 2.6 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----27139720725417689 Content-Type: text/html; charset="iso-7978-1" Content-Transfer-Encoding: 7Bit Hello,

Please accept our sincere apologies about the late reply on your m(o)rtgage application.
We noticed that your current ra[t]e is over 5%. We can give a fixed ra[t]e of 3.2% that
will qualify you with a loan up to $210,000.

Take the time to the final details to complete the process:
http://www.savingsalerts.com/?partid=aaks9

Sincerely,
Fannie Parr
MBR Inc


not interested

----27139720725417689-- From jkpwangwf@szjkp.com Wed Jul 28 21:23:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20790 for ; Wed, 28 Jul 2004 21:23:09 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpzfR-0002gQ-SG for opes-archive@ietf.org; Wed, 28 Jul 2004 21:25:11 -0400 Received: from [218.18.131.251] (helo=opes-archive) by mx2.foretec.com with esmtp (Exim 4.24) id 1BpzdU-00005G-Kq for opes-archive@ietf.org; Wed, 28 Jul 2004 21:23:09 -0400 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: =?GB2312?B?RDMxytPGtaOsyKvQwrXNvNuz9srb?= 9:32:55:921 To: opes-archive@ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkpwangwf@szjkp.com Date: Thu, 29 Jul 2004 09:32:59 +0800 X-Priority: 4 Message-Id: X-Spam-Score: 12.0 (++++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

尊敬的客户：
         你好，非常感谢你能在百忙之中对我们的关注！(如果我的信息无意中打扰了你，我非常抱歉，请你立即删除)
         我们是金凯鹏电子有限公司，公司现有一批视频产品：价格优惠，品质优良，具体如下，敬请参考：

视频会议摄像头
SONY EVI D31            ￥5800
SONY EVI-D100P          ￥5900

SONY EVI-D70            价格：8000元
联系人：王卫锋   电话：0755-83658190   0755-81600374

WWW.SZJKP.COM

深圳市金凯鹏电子有限公司
王卫锋
086-0755-83658190
jkpwangwf@szjkp.com
深圳市深南中路宝安大厦甲栋17A From Mitzi.Fischer@twcny.rr.com Wed Jul 28 22:27:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24490; Wed, 28 Jul 2004 22:27:33 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq0fm-0003dA-RE; Wed, 28 Jul 2004 22:29:36 -0400 Received: from 200165154161.user.veloxzone.com.br ([200.165.154.161]) by mx2.foretec.com with smtp (Exim 4.24) id 1Bq0dj-0002mD-Oz; Wed, 28 Jul 2004 22:27:28 -0400 Received: from Mitzi.Fischer@twcny.rr.com (60.62.155.68) by gq5948.wuxs.200.165.154.161 with QMQP; Wed, 28 Jul 2004 23:25:03 -0300 X-MIME-Autoconverted: Yes Alternate-Recipient: Allowed Auto-Forwarded: Yes Xref: ieuceomdubxhbykdwrat Reply-To: "Becky Magee" From: "Becky Magee" To: ldap-dir@ietf.org Cc: statements@ietf.org, registrar@ietf.org, dhcwg-web-archive@ietf.org, nfsv4-admin@ietf.org, opes-archive@ietf.org, xxxx@ietf.org, bridge-mib-admin@ietf.org, lemonade@ietf.org, sic@ietf.org, diffserv-admin@ietf.org, er-wgchairs@ietf.org, rddp-request@ietf.org Subject: Amount: $305,000 Date: Wed, 28 Jul 2004 22:26:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--34409203465360757723" Message-Id: X-Spam-Score: 2.9 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----34409203465360757723 Content-Type: text/html; charset="iso-1485-3" Content-Transfer-Encoding: 7Bit Hello,

Please accept our sincere apologies about the late reply on your m(o)rtgage application.
We noticed that your current ra[t]e is over 5%. We can give a fixed ra[t]e of 3.2% that
can qualify you with a loan up to $546,000.

Take the time to the final details to complete the process:
http://www.zkvjfnn.com/s6/jj.php?cyb=63

Sincerely,
Becky Magee
MBR Inc


not interested

----34409203465360757723-- From jkpwangwf@szjkp.com Wed Jul 28 23:50:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28229 for ; Wed, 28 Jul 2004 23:50:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq1xp-0004id-Ju for opes-archive@ietf.org; Wed, 28 Jul 2004 23:52:17 -0400 Received: from [218.18.131.251] (helo=opes-archive) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bq1vr-0006Mz-DO for opes-archive@ietf.org; Wed, 28 Jul 2004 23:50:15 -0400 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: =?GB2312?B?RDMxytPGtaOsyKvQwrTzwb/F+rei?= 11:59:59:749 To: opes-archive@ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkpwangwf@szjkp.com Date: Thu, 29 Jul 2004 12:00:05 +0800 X-Priority: 4 Message-Id: X-Spam-Score: 12.0 (++++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

尊敬的客户：
         你好，非常感谢你能在百忙之中对我们的关注！(如果我的信息无意中打扰了你，我非常抱歉，请你立即删除)
         我们是金凯鹏电子有限公司，公司现有一批视频产品：价格优惠，品质优良，具体如下，敬请参考：

视频会议摄像头
SONY EVI D31            ￥5800
SONY EVI-D100P          ￥5900

SONY EVI-D70            价格：6800元
联系人：王卫锋   电话：0755-83658190   0755-81600374

WWW.SZJKP.COM

深圳市金凯鹏电子有限公司
王卫锋
086-0755-83658190
jkpwangwf@szjkp.com
深圳市深南中路宝安大厦甲栋17A From quboisk@yahoo.com Thu Jul 29 03:12:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21112; Thu, 29 Jul 2004 03:12:07 -0400 (EDT) Received: from [211.187.31.167] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bq57D-0007Ve-Kr; Thu, 29 Jul 2004 03:14:12 -0400 Received: from 219.254.53.144 by 211.187.31.167; Thu, 29 Jul 2004 05:07:59 -0300 Message-ID: From: "Elisa Ash" Reply-To: "Elisa Ash" To: nsis@ietf.org Subject: the rates are REALLY at all time LOWS Date: Thu, 29 Jul 2004 05:06:59 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--055742849631660914" X-IP: 172.38.128.76 X-Priority: 3 X-Spam-Score: 13.5 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----055742849631660914 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello.
Did you know you can get pre-approved mort gage rates ev= en with bad credit?
Simply follow the link below and we will approve you in under 24 hours. No= need to worry.

Approval application 65


Elisa Ash



testes ----055742849631660914-- From chfjuubo@263.net Fri Jul 30 12:57:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19294; Fri, 30 Jul 2004 12:57:32 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqajc-0002il-Jg; Fri, 30 Jul 2004 12:59:56 -0400 Received: from dsl-200-95-25-63.prod-infinitum.com.mx ([200.95.25.63]) by mx2.foretec.com with smtp (Exim 4.24) id 1BqahF-00051m-Nl; Fri, 30 Jul 2004 12:57:31 -0400 Received: from 128.168.8.255 by 200.95.25.63; Fri, 30 Jul 2004 12:53:48 -0400 Message-ID: From: "Otis Sloan" Reply-To: "Otis Sloan" To: nemo-request@ietf.org Subject: upgrade your Office software now Date: Fri, 30 Jul 2004 12:50:48 -0400 X-Mailer: AOL 9.0 for Windows US sub 134 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--268530188376832" X-Priority: 5 X-MSMail-Priority: Low X-IP: 170.18.152.133 X-Spam-Score: 20.6 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca ----268530188376832 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable NEED A NEW C0MPUTER?
75%-OFF LEADING S0FTWARE

1.W1ND0WS X.P Pr0=3D $= 50
2.0FF1CE= X.P Pr0=3D $60

bundle offer:
W1ND0WS X.P Pr0 + 0FF1CE X.P Pr0 =3D $80

 ST0CKS ARE L1M1TED ! valid until July12th !
M0RE S0FTWARE


R*E*L*E*A*S*E_ me


lapelled faulknermcallister colorimeter woolgatherdilapidate bloc pitchforkkaleidescope jar montyyoungish scurry astoragenda nephew corruptfortress downgrade chiggeredmonds grimes archerwoo prizewinning trentonconfrontation classificatory sorptionalgol degassing adolescentcathedral appliance elisionoatmeal vogel vailcartographic euclid orgiasticjohansen karachi groveplateau hurtle prismaticdelirious molest pinkiowa i'll marrowcocoon welt indistinctslender whack cowhidecraftsmen bolt cushmanbuchwald mineral carlarepulsive pigeonhole bereavecorinthian armload logicianethyl ancillary delusivekazoo fascist apostrophehemispheric demarcate bylawhiatus chaplin nadirshrapnel insure churchfresno perkins dodecahedraautomorphic bowstring salemtransfuse aboveboard depositorcontradistinction ballast adeptkirkpatrick fume subversiveheadset denude heterozygousalison fusiform preventionsearchlight jeffrey teratogenicboeotian antebellum bothsister ----268530188376832-- From welnlgofus@msn.com Fri Jul 30 20:30:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12128; Fri, 30 Jul 2004 20:30:17 -0400 (EDT) Received: from [221.146.46.225] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bqhnm-0008Qt-HZ; Fri, 30 Jul 2004 20:32:44 -0400 Received: from 176.200.52.176 by 221.146.46.225; Fri, 30 Jul 2004 22:21:59 -0300 Message-ID: From: "Margo Franco" Reply-To: "Margo Franco" To: nemo@ietf.org Subject: let me help you Date: Sat, 31 Jul 2004 07:23:59 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--216996261924624125" X-Webmail-Time: Fri, 30 Jul 2004 21:21:59 -0400 X-Spam-Score: 10.7 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----216996261924624125 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hey there
How would you like to start saving from $100 to $500 a month
on your mor.tgage payment? Or get that Loan. you wanted?
Bad credit? No Credit? Thats OK it doesnt matter you already
Pre-Qualified. Just goto our confirmation link below to confirm everything=

Confirm everything here(takes 15 seconds)

Best Regaurds,
Margo Franco

Email,
welnlgofus@msn.com ----216996261924624125-- From mmgvccfbxqwyz@mci.net Fri Jul 30 21:41:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15222; Fri, 30 Jul 2004 21:41:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqiuS-0000oa-AP; Fri, 30 Jul 2004 21:43:42 -0400 Received: from [203.101.85.97] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Bqis3-0007X7-2r; Fri, 30 Jul 2004 21:41:11 -0400 X-Message-Info: YASVnCM53tRaybxALCFZhiFhtDDXsg01 Received: from aztec-dns.jiltdiatribe.com ([81.180.132.64]) by tp4-a29.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Fri, 30 Jul 2004 22:32:41 -0300 Received: from mail.berliozwitty.com ([48.98.182.67]) by birth-dns.deathbedreykjavik.com (3.72.4/4.05.9) with ESMTP id n4UNeij0231687 for ; Fri, 30 Jul 2004 18:33:41 -0700 (EST) (envelope-from mmgvccfbxqwyz@mci.net) Received: from [228.1.102.224] (helo=traumatic6.rite68kernel.com) by mail.arecleat.com with esmtp (Exim 8.33) id 5NbziO-7047fM-CA for nemo-web-archive@ietf.org; Fri, 30 Jul 2004 20:31:41 -0500 Received: from dyer2.broadside07deportation.com (localhost.florist26piety.com [127.0.0.1]) by indict3.jocular15afterword.com (6.40.9b3/1.95.3) with ESMTP id w3VIjML4164264 for ; Fri, 30 Jul 2004 21:35:41 -0400 (CST) (envelope-from mmgvccfbxqwyz@mci.net) Received: (from glacial@localhost) by sultry4.teething41protein.com (3.55.0y7/0.30.8/cadillac) id i0RRdFZ2946414; Sat, 31 Jul 2004 02:37:41 +0100 (CST) Date: Fri, 30 Jul 2004 18:39:41 -0700 (CST) Message-Id: <574139250450.f2OSyLU63932142@attica1.adhesion43cunard.com> To: nemo-web-archive@ietf.org Subject: show me how your wife plays with herself? From: Alfreda Hendrickson MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4334804922294456" X-Spam-Score: 37.1 (+++++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ----4334804922294456 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable




Remove




Ion Marketing Limit= ed
D2, 23, Borrett Road, Mid-Levels West
Hong Kong


<= br> glean duffelscenario keys dirgescrewworm heathen innovatevivian admixture rosebudpsycho enzymology featherbedeccles anvil bedimmingsophoclean kingsbury bullheadcampfire coplanar mineralogybusch stimulate williebreach aloha affixsedulous pious bodiedneurotic dolores capacitorbrook careful bremenlaotian dice thirtiethfieldwork aviary monthbuckwheat psych abstentionincontrollable emil terrorallyn laurel plasticdrawback abram confirmatoryupheaval acs protectorateamman creekside janapprehension pakistani farrelladequacy vermiculite evocateblimp logjam nodreferable temptation transitfungi ear staircasefenton levi apotheosistruancy ditto cruickshankeighty robin finkirony crease hegelianbiddable pauli acrossvalois imitable chilehospice retiree taterhydroxyl counterflow chivalrousu veracious barbituratewoodcarver zeal obtainfollicular demit chancellordowntrend progress dealtbrahmaputra ----4334804922294456-- From jkpwangwf@szjkp.com Fri Jul 30 23:18:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19121 for ; Fri, 30 Jul 2004 23:18:21 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqkQR-0001u3-K6 for opes-archive@ietf.org; Fri, 30 Jul 2004 23:20:50 -0400 Received: from [61.141.146.4] (helo=opes-archive) by mx2.foretec.com with esmtp (Exim 4.24) id 1BqkO3-0002WJ-K5 for opes-archive@ietf.org; Fri, 30 Jul 2004 23:18:20 -0400 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: =?GB2312?B?U09OWcrTxrW74dLpz7XB0KOsuPjE+szhuanX7rrDtcS3vbC4?= To: opes-archive@ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkpwangwf@szjkp.com Date: Sat, 31 Jul 2004 11:28:08 +0800 X-Priority: 4 Message-Id: X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

尊敬的客户：
         你好，非常感谢你能在百忙之中对我们的关注！(如果我的信息无意中打扰了你，我非常抱歉，请你立即删除)
         我们是金凯鹏电子有限公司，公司现有一批视频产品：价格优惠，品质优良，具体如下，敬请参考：

视频会议摄像头
SONY EVI D31            ￥5800
SONY EVI-D100P          ￥5900

SONY EVI-D70            价格：6800元
联系人：王卫锋   电话：0755-83658190   0755-81600374

WWW.SZJKP.COM

深圳市金凯鹏电子有限公司
王卫锋
086-0755-83658190
jkpwangwf@szjkp.com
深圳市深南中路宝安大厦甲栋17A From mbgjhepulllk@sbcglobal.net Sat Jul 31 14:57:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11018; Sat, 31 Jul 2004 14:57:39 -0400 (EDT) Received: from [211.226.171.62] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bqz5c-0003qo-3B; Sat, 31 Jul 2004 15:00:16 -0400 Received: from 240.157.18.57 by web624.mail.yahoo.com; Sun, 01 Aug 2004 01:49:28 +0600 Message-ID: From: "Maude Cody" To: xxxx@ietf.org Subject: Get your Masters, No Testing! Date: Sat, 31 Jul 2004 17:49:28 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--41562908302927106299" X-CS-IP: 164.24.146.146 X-Spam-Score: 13.0 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----41562908302927106299 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Good Day,


This is a Limited special offer directly from ou= r admissions office.
You are now qualified to obtain a Degree from a pr= estigious university.

NO required tests, classes, books, or intervi= ews...degree's are given based on life experiences.Bachelors, Masters, MBA= , and Doctorate (PhD) are available in the field of your choice.

D= iscrete and Very affordable - Everyone eligible.

No one is turned = down.We send the certificate to all countries (WORLDWIDE) Click Here and fill out a short = form and you will be on your way to a better future.




To= be removed from future contact visit: http://abetterfutureforyou.com/st.h= tml
=

742155 ----41562908302927106299--