From owner-ietf-openproxy@mail.imc.org Tue Apr 1 11:06:41 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23980 for ; Tue, 1 Apr 2003 11:06:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31FomJM005101 for ; Tue, 1 Apr 2003 07:50:48 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31Fomf0005100 for ietf-openproxy-bks; Tue, 1 Apr 2003 07:50:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31FokJM005096 for ; Tue, 1 Apr 2003 07:50:46 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h31Fojvj055320; Tue, 1 Apr 2003 08:50:45 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h31Foj6x055319; Tue, 1 Apr 2003 08:50:45 -0700 (MST) (envelope-from rousskov) Date: Tue, 1 Apr 2003 08:50:44 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Protocol next steps In-Reply-To: <200304010116.h311GJo24047@localhost.localdomain> Message-ID: References: <200304010116.h311GJo24047@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: On Mon, 31 Mar 2003, The Purple Streak, Hilarie Orman wrote: > The timeline you suggest is not one I can meet. I suggest extending > this to the end of April. I am surprised it would take you some 30 days to make a simple(?) "publish as WG draft" versus "publish as individual draft" decision. Perhaps you value the outcome more than I do. Regardless of the submission "type", I would expect to publish at least two more draft versions before May! I just want to publish a reference point so that we can build upon it. I already have one big/important addition/clarification to discuss, but I hesitate posting it before the first draft is published. If you can make a wg/individual decision before April 4th, please do so. Otherwise, I guess we will have to treat your message as an implicit objection, and I will probably just publish an individual draft. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 1 12:37:08 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02687 for ; Tue, 1 Apr 2003 12:37:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HKSJM009261 for ; Tue, 1 Apr 2003 09:20:28 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31HKSTg009260 for ietf-openproxy-bks; Tue, 1 Apr 2003 09:20:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31HKQJM009253 for ; Tue, 1 Apr 2003 09:20:27 -0800 (PST) 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.9/8.12.9) with ESMTP id h31HKQ9Y075777 for ; Tue, 1 Apr 2003 12:20:28 -0500 (EST) 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 h31HKJc6037216 for ; Tue, 1 Apr 2003 12:20:19 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA04223 for ; Tue, 1 Apr 2003 12:20:19 -0500 (EST) Message-ID: <3E89CA80.6010609@mhof.com> Date: Tue, 01 Apr 2003 12:21:04 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: Protocol next steps References: <200304010116.h311GJo24047@localhost.localdomain> In-Reply-To: <200304010116.h311GJo24047@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: Content-Transfer-Encoding: 7bit Hilarie, > The timeline you suggest is not one I can meet. I suggest extending this > to the end of April. the suggested timeline was just for deciding whether we should publish this as WG document or as individual draft. This *not* a WG last call or such like, we expect to have more interations on this document!! We just don't want to delay publishing this as ID. We want to have a proper reference point, rather than just refering to some emails on the list. As such, it would be preferable to publish this - either as WG draft or as individual - in the very near future. I personally feel that the document properly reflects the discussion we had so far on the list, and, therefore, am tempted to publish this as WG document. I understand that you won't have the time for a very thorough, detailed review until April 4. From your current perspective, would you feel uncomfortable with moving this forward as WG draft? If so, I'd recommend Alex to publish this as individual. If not, let's publish this at WG document and keep working on it in the WG. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 1 12:46:04 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03459 for ; Tue, 1 Apr 2003 12:46:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HXxJM009595 for ; Tue, 1 Apr 2003 09:33:59 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31HXxtU009594 for ietf-openproxy-bks; Tue, 1 Apr 2003 09:33:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HXvJM009590 for ; Tue, 1 Apr 2003 09:33:58 -0800 (PST) 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.9/8.12.9) with ESMTP id h31HXxHa020823 for ; Tue, 1 Apr 2003 12:33:59 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.8/8.12.8) with ESMTP id h31HXrjt059396 for ; Tue, 1 Apr 2003 12:33:53 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA05073 for ; Tue, 1 Apr 2003 12:33:52 -0500 (EST) Message-ID: <3E89CDAE.90507@mhof.com> Date: Tue, 01 Apr 2003 12:34:38 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: Protocol next steps References: <200304010116.h311GJo24047@localhost.localdomain> <20030331173205.397720d3.mrose@dbc.mtview.ca.us> In-Reply-To: <20030331173205.397720d3.mrose@dbc.mtview.ca.us> 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: Content-Transfer-Encoding: 7bit Marshall Rose wrote: > the end of april is too far way. if april 4th doesn't work for you, we can push > it to the middle of next week, say the 9th... otherwise, i'd rather we consider > just closing up shop due to lack of metabolism. Let's stick with the April 4 deadline, so that we get this published and a proper reference point very soon. If people don't feel comfortable with having this as WG document, please make this clear to the mailing list by April 4!!! If there are clear objections by that day, we'll ask Alex to publish this as an individual submission, for now, so that we've a proper reference point to work with. I would then expect it to be moveed to WG document at some later stage. If there are no clear objections by April 4, we'll publish as WG document and also keep working on it. Somehow, it appears that this is a minor issue, and I'd like us to focus on the actual technical work again. We had plenty of excellent discussion on the mailing list recently, with several folks being very active - thanks! If we keep the momentum, we don't have to worry about a lack of metabolism, and I'm sure some good results will come out of it. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 1 13:08:15 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05354 for ; Tue, 1 Apr 2003 13:08:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31Hv0JM010236 for ; Tue, 1 Apr 2003 09:57:00 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31Hv0rj010235 for ietf-openproxy-bks; Tue, 1 Apr 2003 09:57:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31HuxJM010231 for ; Tue, 1 Apr 2003 09:57:00 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31HuSP24298; Tue, 1 Apr 2003 12:56:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 12:56:28 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754054FAA3B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Marshall Rose , "The Purple Streak, Hilarie Orman" Cc: rousskov@measurement-factory.com, ietf-openproxy@imc.org Subject: RE: Protocol next steps Date: Tue, 1 Apr 2003 12:56:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F878.04189DA2" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2F878.04189DA2 Content-Type: text/plain Marshall, This group has done a great job in moving documents forward, given all the problems that we had to deal with. The list had a great effort prioir to the IETF and a lot of work was done on the protocol. I would really appreciate words of encouragment every now and then. Closing shop is not an option, not at this stage of the game !!!!!!!!!!!!!!!! Abbie > -----Original Message----- > From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] > Sent: Monday, March 31, 2003 8:32 PM > To: The Purple Streak, Hilarie Orman > Cc: rousskov@measurement-factory.com; ietf-openproxy@imc.org > Subject: Re: Protocol next steps > > > > > The timeline you suggest is not one I can meet. I suggest > extending > > this to the end of April. > > the end of april is too far way. if april 4th doesn't work > for you, we can push it to the middle of next week, say the > 9th... otherwise, i'd rather we consider just closing up shop > due to lack of metabolism. > > /mtr > ------_=_NextPart_001_01C2F878.04189DA2 Content-Type: text/html RE: Protocol next steps

Marshall,

This group has done a great job in moving documents forward, given
all the problems that we had to deal with.

The list had a great effort prioir to the IETF and a lot of work was done on the protocol.

I would really appreciate words of encouragment every now and then.

Closing shop is not an option, not at this stage of the game !!!!!!!!!!!!!!!!


Abbie

> -----Original Message-----
> From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us]
> Sent: Monday, March 31, 2003 8:32 PM
> To: The Purple Streak, Hilarie Orman
> Cc: rousskov@measurement-factory.com; ietf-openproxy@imc.org
> Subject: Re: Protocol next steps
>
>
>
> > The timeline you suggest is not one I can meet.  I suggest
> extending
> > this to the end of April.
>
> the end of april is too far way. if april 4th doesn't work
> for you, we can push it to the middle of next week, say the
> 9th... otherwise, i'd rather we consider just closing up shop
> due to lack of metabolism.
>
> /mtr
>

------_=_NextPart_001_01C2F878.04189DA2-- From owner-ietf-openproxy@mail.imc.org Tue Apr 1 13:09:24 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05443 for ; Tue, 1 Apr 2003 13:09:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HpsJM010061 for ; Tue, 1 Apr 2003 09:51:54 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31HpsrI010060 for ietf-openproxy-bks; Tue, 1 Apr 2003 09:51:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31HprJM010054 for ; Tue, 1 Apr 2003 09:51:53 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31HpkP23875; Tue, 1 Apr 2003 12:51:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 12:51:47 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754054FAA2B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , ietf-openproxy@imc.org Subject: RE: Protocol next steps Date: Tue, 1 Apr 2003 12:51:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F877.5B99ED2A" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2F877.5B99ED2A Content-Type: text/plain hi all, i have taken a quick look at the draft and I do not have a problem with it as a wg draft -00. abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, April 01, 2003 12:21 PM > To: ietf-openproxy@imc.org > Subject: Re: Protocol next steps > > > > Hilarie, > > > The timeline you suggest is not one I can meet. I suggest > extending > > this to the end of April. > > the suggested timeline was just for deciding whether we > should publish > this as WG document or as individual draft. This *not* a WG last call > or such like, we expect to have more interations on this document!! > > We just don't want to delay publishing this as ID. We want to have a > proper reference point, rather than just refering to some emails on > the list. As such, it would be preferable to publish this - either as > WG draft or as individual - in the very near future. > > I personally feel that the document properly reflects the discussion > we had so far on the list, and, therefore, am tempted to publish this > as WG document. > > I understand that you won't have the time for a very thorough, > detailed review until April 4. From your current perspective, would > you feel uncomfortable with moving this forward as WG draft? If so, > I'd recommend Alex to publish this as individual. If not, let's > publish this at WG document and keep working on it in the WG. > > Thanks, > Markus > > ------_=_NextPart_001_01C2F877.5B99ED2A Content-Type: text/html RE: Protocol next steps

hi all,

i have taken a quick look at the draft and I do not have a problem with it as a wg draft -00.

abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, April 01, 2003 12:21 PM
> To: ietf-openproxy@imc.org
> Subject: Re: Protocol next steps
>
>
>
> Hilarie,
>
> > The timeline you suggest is not one I can meet.  I suggest
> extending
> > this to the end of April.
>
> the suggested timeline was just for deciding whether we
> should publish
> this as WG document or as individual draft. This *not* a WG last call
> or such like, we expect to have more interations on this document!!
>
> We just don't want to delay publishing this as ID. We want to have a
> proper reference point, rather than just refering to some emails on
> the list. As such, it would be preferable to publish this - either as
> WG draft or as individual - in the very near future.
>
> I personally feel that the document properly reflects the discussion
> we had so far on the list, and, therefore, am tempted to publish this
> as WG document.
>
> I understand that you won't have the time for a very thorough,
> detailed review until April 4. From your current perspective, would
> you feel uncomfortable with moving this forward as WG draft? If so,
> I'd recommend Alex to publish this as individual. If not, let's
> publish this at WG document and keep working on it in the WG.
>
> Thanks,
>    Markus
>
>

------_=_NextPart_001_01C2F877.5B99ED2A-- From owner-ietf-openproxy@mail.imc.org Tue Apr 1 13:15:20 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05931 for ; Tue, 1 Apr 2003 13:15:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HxRJM010287 for ; Tue, 1 Apr 2003 09:59:27 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31HxRDG010286 for ietf-openproxy-bks; Tue, 1 Apr 2003 09:59:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HxQJM010282 for ; Tue, 1 Apr 2003 09:59:26 -0800 (PST) Received: from localhost.localdomain (pl109438.fiber.net [216.83.152.26] (may be forged)) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h31Hx1Kq002904; Tue, 1 Apr 2003 10:59:02 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h31HxP006898; Tue, 1 Apr 2003 10:59:25 -0700 Date: Tue, 1 Apr 2003 10:59:25 -0700 Message-Id: <200304011759.h31HxP006898@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: Protocol next steps Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: My recommendation will be based on a further careful reading of the draft, and I'll have comments at the same time, because that's just the way I do things, and I cannot do that this week, and I'm not sure when I can do it next week. The timeline seemed too aggressive for me, and I thought others might find it so. Please withhold further astonishment and speculation on the effectiveness of my mitochondria. Hilarie From owner-ietf-openproxy@mail.imc.org Tue Apr 1 13:48:20 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07770 for ; Tue, 1 Apr 2003 13:48:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31IUGJM011533 for ; Tue, 1 Apr 2003 10:30:16 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31IUGna011532 for ietf-openproxy-bks; Tue, 1 Apr 2003 10:30:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31IUEJM011526 for ; Tue, 1 Apr 2003 10:30:15 -0800 (PST) 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.9/8.12.9) with ESMTP id h31IUG9Y076390 for ; Tue, 1 Apr 2003 13:30:16 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.8/8.12.8) with ESMTP id h31IUAjt063881 for ; Tue, 1 Apr 2003 13:30:10 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA07484 for ; Tue, 1 Apr 2003 13:30:10 -0500 (EST) Message-ID: <3E89DADF.4040600@mhof.com> Date: Tue, 01 Apr 2003 13:30:55 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Need to look at tracing and debuggig References: 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: Content-Transfer-Encoding: 7bit Oskar, great input, thanks. Just some quick, minor comments: > 1. Tracing information has to be provided in-band, I see no > other way to satisfy current architecture requirements. The > OPES architecture states that: I agree with that. The question is, though, whether the callout protocol itself will also carry some tracing information, or whether the callout server will embedd possible tracing information directly into the application message. > 2. We have to decide on the in-band - out-of-band balance for tracing > facilities. Two extreme approaches are: > > - in-band data provides only a reference to the point to the facility where > the tracing information may be obtained; > > - include all information in-band. > > Advantage of the first approach: a) Tracing information may be provided > in application protocol independent manner. b) Level of details is > determined by direct request, lengthy descriptions may be provided > without an impact on the application protocol efficiency. > Disadvantages: a complex identification mechanism is needed to retrieve > application message specific information (like "virus checking applied"), and > getting such simple notification will involve overhead of creating or > keeping an additional connection. Nice comments. I was tempted to lean towards the first approach with a refrence to a point for retrieval, but.... Where would such point of tracing information retrieval be? Would you assume that, for example, I can retrieve detailed tracing information about a provided OPES service directly from the callout server the service has been executed? Such a callout server might very well sit behind a NAT and might have a non-routable IP adress... If it's not directly on the callout server, how would the callout server provide the required tracing information to the other entity? > The second approach provides a kind of opposite advantages and disadvantages: > simple per-message information binding but application protocol may be > cluttered > with excess information that is not relevant to the current session (may be > due to the lack of interest of the participants). > > An additional advantage of in-band approach is end-to-end coverage: tracing > information and related directives are available to all OPES flow > participants, > no topology knowledge is required. Yup, good point, have to agree. > A reasonable combination may include message-related information in band and > a reference to the session-related information. To adjust in-band information > level to the needs of session participants some trace control directives > should > be defined (as an application protocol extensions). Could you provide a specific example for session-related information (as opposed to message-related)? > The purpose of identification (exposure) should be defined by the > intended use. Only the information points (where some participant > may call for additional information) and reference points (those that should > be identified in related request, e.g. to the center of authority) should be > exposed. If there are points that may accept directives (e.g. privacy > directives) - they should be exposed. > > Also session participants should be notified about the center of > authority for the OPES server. > [...] Can we develop a few example scenarios that illustrate the various concepts of "information points", "reference points", "identifier", etc., and how they play together? > Any such explicitly identified point may be on the path or out of the path, > this should not be a factor. Points on the path are exposed by IP, > as according to IAB requirements connections are terminated at these points. The IAB considerations state that "the OPES intermediary must be explicitly addressed at the IP layer by the end user", which translates that (only) the first "hop", i.e. the first OPES intermediary on the path, has to be addreessable explicitely. Others might very well sit behind a NAT or so. > Information about services should be provided in-band and should uniquely > identify the service provider and service type, but not the service point > (OPES > server). This makes service information location independent and facilitates > system reconfiguration, including failover and recovery: agreements and > parameters > may be transferred to another OPES server (within the same trust domain) > without > renegotiation with end-point. If we don't identify the exact server, how would a service provider trace a problem I report to him? How would he know whichserver to check, if I tell him that something went wrong and check him to ask this? With email, for example, I know exactly which mail servers have been o nthe path, thus being able to trace down to the exact server. > Direct point exposure (let's say by inclusion of URL into the tracing > information) > raises a question about out-of-band protocol used to access this point. > SOAP looks like a good candidate for that. Do we have to decide on a specific protocol to be used for this purpose, or can we leave this open and just indicated the protocol to be used (e.g. withing the embedded URI). -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 1 13:51:44 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07885 for ; Tue, 1 Apr 2003 13:51:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31IdIJM011764 for ; Tue, 1 Apr 2003 10:39:18 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31IdIou011763 for ietf-openproxy-bks; Tue, 1 Apr 2003 10:39:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31IdGJM011759 for ; Tue, 1 Apr 2003 10:39:16 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h31IdHvj059503; Tue, 1 Apr 2003 11:39:17 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h31IdHtQ059502; Tue, 1 Apr 2003 11:39:17 -0700 (MST) (envelope-from rousskov) Date: Tue, 1 Apr 2003 11:39:17 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Protocol next steps In-Reply-To: <200304011759.h31HxP006898@localhost.localdomain> Message-ID: References: <200304011759.h31HxP006898@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: On Tue, 1 Apr 2003, The Purple Streak, Hilarie Orman wrote: > My recommendation will be based on a further careful reading of the > draft, and I'll have comments at the same time, because that's just > the way I do things, and I cannot do that this week, and I'm not > sure when I can do it next week. The timeline seemed too aggressive > for me, and I thought others might find it so. Please withhold > further astonishment and speculation on the effectiveness of my > mitochondria. Given the above, I think we should publish as an individual draft to give everybody enough time for a thorough review while allowing new revisions to be discussed and published. Those that do not have a problem with the draft becoming a WG document can treat it as such immediately. Submitting an individual draft should not hurt anything, should it? Skipping that step would be nice, but it is not a big deal. I will submit an individual draft in ~12 hours unless somebody stops me. Let's move on... Thank you, Alex. P.S. I do not think there was any intended astonishment or speculation, just attempts to clarify what we are after here. From owner-ietf-openproxy@mail.imc.org Tue Apr 1 14:38:08 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09966 for ; Tue, 1 Apr 2003 14:38:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JRKJM014847 for ; Tue, 1 Apr 2003 11:27:20 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31JRKdh014846 for ietf-openproxy-bks; Tue, 1 Apr 2003 11:27:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31JRIJM014836 for ; Tue, 1 Apr 2003 11:27:19 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31JRDP15942; Tue, 1 Apr 2003 14:27:13 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 14:27:13 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754054FAB95@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: Need to look at tracing and debuggig Date: Tue, 1 Apr 2003 14:27:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F884.B2BE166E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2F884.B2BE166E Content-Type: text/plain see inline, abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, April 01, 2003 1:31 PM > To: OPES Group > Subject: Re: Need to look at tracing and debuggig > > > > Oskar, > > great input, thanks. Just some quick, minor comments: > > > 1. Tracing information has to be provided in-band, I see no > other way > > to satisfy current architecture requirements. The OPES architecture > > states that: > > I agree with that. The question is, though, whether the callout > protocol itself will also carry some tracing information, or whether > the callout server will embedd possible tracing information directly > into the application message. > ---- abbie I agree tracing should be done inline. whether the ocp will carry the tracing info or not has to be answered with the next question below. I think that tracing has to go throu the opes processor, the callout server is just a slave in this case. I know that this will add more burden on the processor in particular, if info need to be saved. > > 2. We have to decide on the in-band - out-of-band balance > for tracing > > facilities. Two extreme approaches are: SNIP > Nice comments. I was tempted to lean towards the first > approach with a > refrence to a point for retrieval, but.... Where would such point of > tracing information retrieval be? Would you assume that, for example, > I can retrieve detailed tracing information about a provided OPES > service directly from the callout server the service has been > executed? Such a callout server might very well sit behind a NAT and > might have a non-routable IP adress... If it's not directly on the > callout server, how would the callout server provide the required > tracing information to the other entity? > -----------abbie see above > > The second approach provides a kind of opposite advantages and > > disadvantages: simple per-message information binding but > application > > protocol may be cluttered with excess information that is > not relevant > > to the current session (may be due to the lack of interest of the > > participants). > > > > An additional advantage of in-band approach is end-to-end coverage: > > tracing information and related directives are available to > all OPES > > flow participants, no topology knowledge is required. > > Yup, good point, have to agree. > -----------abbie agree too > > A reasonable combination may include message-related information in snip > > > Direct point exposure (let's say by inclusion of URL into > the tracing > > information) > > raises a question about out-of-band protocol used to access this > > point. SOAP looks like a good candidate for that. > -----abbie agree, but how about duration and the extra burden of storing the info. > Do we have to decide on a specific protocol to be used for this > purpose, or can we leave this open and just indicated the protocol to > be used (e.g. withing the embedded URI). > > -Markus > -------abbie I have discussed embedded URI before, it could been argued that this is out of band. even with that we need to answere questions such as who did what when and may require signatures etc.. This sounds like the trace (debugg token) that we spoke about before. abbie > ------_=_NextPart_001_01C2F884.B2BE166E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Need to look at tracing and debuggig

see inline,
abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, April 01, 2003 1:31 PM
> To: OPES Group
> Subject: Re: Need to look at tracing and = debuggig
>
>
>
> Oskar,
>
> great input, thanks. Just some quick, minor = comments:
>
> > 1. Tracing information has to be provided = in-band, I see no
> other way
> > to satisfy current architecture = requirements. The OPES architecture
> > states that:
>
> I agree with that. The question is, though, = whether the callout
> protocol itself will also carry some tracing = information, or whether
> the callout server will embedd possible tracing = information directly
> into the application message.
>

---- abbie

I agree tracing should be done inline. whether the = ocp will carry the tracing info or not has to be answered with the next = question below. I think that tracing has to go throu the opes = processor, the callout server is just a slave in this case. I know that = this will add more burden on the processor in particular, if info need = to be saved.

> > 2. We have to decide on the in-band - = out-of-band balance
> for tracing
> > facilities. Two extreme approaches = are:

SNIP

> Nice comments. I was tempted to lean towards the = first
> approach with a
> refrence to a point for retrieval, but.... = Where would such point of
> tracing information retrieval be? Would you = assume that, for example,
> I can retrieve detailed tracing information = about a provided OPES
> service directly from the callout server the = service has been
> executed? Such a callout server might very well = sit behind a NAT and
> might have a non-routable IP adress... If it's = not directly on the
> callout server, how would the callout server = provide the required
> tracing information to the other entity?
>


-----------abbie
see above

> > The second approach provides a kind of = opposite advantages and
> > disadvantages: simple per-message = information binding but
> application
> > protocol may be cluttered with excess = information that is
> not relevant
> > to the current session (may be due to the = lack of interest of the
> > participants).
> >
> > An additional advantage of in-band = approach is end-to-end coverage:
> > tracing information and related directives = are available to
> all OPES
> > flow participants, no topology knowledge = is required.
>
> Yup, good point, have to agree.
>

-----------abbie

agree too


> > A reasonable combination may include = message-related information in
snip

>
> > Direct point exposure (let's say by = inclusion of URL into
> the tracing
> > information)
> > raises a question about out-of-band = protocol used to access this
> > point. SOAP looks like a good candidate = for that.
>

-----abbie

agree, but how about duration and the extra burden of = storing the info.


> Do we have to decide on a specific protocol to = be used for this
> purpose, or can we leave this open and just = indicated the protocol to
> be used (e.g. withing the embedded URI).
>
> -Markus
>
-------abbie

I have discussed embedded URI before, it could been = argued that this is out of band.
even with that we need to answere questions such as = who did what when and may require signatures etc..
This sounds like the trace (debugg token) that we = spoke about before.


abbie











>

------_=_NextPart_001_01C2F884.B2BE166E-- From owner-ietf-openproxy@mail.imc.org Tue Apr 1 15:02:51 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11157 for ; Tue, 1 Apr 2003 15:02:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JpaJM015719 for ; Tue, 1 Apr 2003 11:51:36 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31JpZs8015718 for ietf-openproxy-bks; Tue, 1 Apr 2003 11:51:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JpYJM015714 for ; Tue, 1 Apr 2003 11:51:34 -0800 (PST) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h31JpWjd000806; Tue, 1 Apr 2003 11:51:33 -0800 (PST) Date: Tue, 1 Apr 2003 11:51:32 -0800 From: Marshall Rose To: "Abbie Barbir" Cc: ho@alum.mit.edu, rousskov@measurement-factory.com, ietf-openproxy@imc.org Subject: Re: Protocol next steps Message-Id: <20030401115132.33918d4c.mrose@dbc.mtview.ca.us> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754054FAA3B@zcard0k6.ca.nortel.com> References: <87609AFB433BD5118D5E0002A52CD754054FAA3B@zcard0k6.ca.nortel.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit > Marshall, > > This group has done a great job in moving documents forward, given > all the problems that we had to deal with. > > The list had a great effort prioir to the IETF and a lot of work was done on > the protocol. > > I would really appreciate words of encouragment every now and then. > > Closing shop is not an option, not at this stage of the game > !!!!!!!!!!!!!!!! abbie - while i sympathize, i'm unmoved. in the real world, you're only as good as what you've done lately. the real world doesn't give time-outs. i'm glad the working group is showing renewed energy, and certainly i thank people for the results i've been seeing. having said that, we're still way behind schedule, so when someone asks for an extension, i view it as adding insult to injury... credibility is something that must be constantly renewed and invigorated. now is not the time to slow down. /mtr From owner-ietf-openproxy@mail.imc.org Tue Apr 1 16:02:47 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15024 for ; Tue, 1 Apr 2003 16:02:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31KqUJM021990 for ; Tue, 1 Apr 2003 12:52:30 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31KqUd3021989 for ietf-openproxy-bks; Tue, 1 Apr 2003 12:52:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31KqTJM021984 for ; Tue, 1 Apr 2003 12:52:29 -0800 (PST) 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.9/8.12.9) with ESMTP id h31KqVHa022601 for ; Tue, 1 Apr 2003 15:52:31 -0500 (EST) 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 h31KqPc6056318 for ; Tue, 1 Apr 2003 15:52:25 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA14327 for ; Tue, 1 Apr 2003 15:52:24 -0500 (EST) Message-ID: <3E89FC35.6020309@mhof.com> Date: Tue, 01 Apr 2003 15:53:09 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: Protocol next steps References: <200304011759.h31HxP006898@localhost.localdomain> 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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Given the above, I think we should publish as an individual draft to > give everybody enough time for a thorough review while allowing new > revisions to be discussed and published. Those that do not have a > problem with the draft becoming a WG document can treat it as such > immediately. > > Submitting an individual draft should not hurt anything, should it? > Skipping that step would be nice, but it is not a big deal. I will > submit an individual draft in ~12 hours unless somebody stops me. > Let's move on... Yup, please go ahead and publish as individual draft, we don't want to delay this. We'll keep moving the draft forward on this mailing list with input from the entire WG, with the goal to submit the next version of the draft as WG document. This way, we do *not* delay making progress, we immediately have a valid reference point, and folks still have some time to carefully look at the draft. However, please note: Possible concerns with the content of the document must be brought up while we're working on the next version. There will *not* be a separate review time or such like once the next version is ready for submission (as WG document). Concerns should be expressed while we're on the path to the next version. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Wed Apr 2 02:03:40 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06022 for ; Wed, 2 Apr 2003 02:03:38 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h326rLJM015242 for ; Tue, 1 Apr 2003 22:53:21 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h326rLWc015241 for ietf-openproxy-bks; Tue, 1 Apr 2003 22:53:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h326rKJM015236 for ; Tue, 1 Apr 2003 22:53:20 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h326rOvj078097 for ; Tue, 1 Apr 2003 23:53:24 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h326rO2F078096; Tue, 1 Apr 2003 23:53:24 -0700 (MST) (envelope-from rousskov) Date: Tue, 1 Apr 2003 23:53:24 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Need to look at tracing and debuggig In-Reply-To: <87609AFB433BD5118D5E0002A52CD754054FAB95@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754054FAB95@zcard0k6.ca.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: More thoughts on tracing and debugging. 1. I could not find any reference to "debugging" in architecture and OCP requirements drafts. Shouldn't we talk just about tracing/reporting? I am not sure what exactly others mean by debugging, but since it is not required, we do not have to worry about it. Tracing helps with debugging, of course, but let's concentrate on immediate goals. Please correct me if I missed debugging requirements. 2. It is very important to keep in mind that tracing is limited to the trust domain. Anybody outside of that domain may or may not see any traces, depending on domain policies/configuration. In other words, we are not talking about mandatory end-to-end tracing facility here. For example, if an OPES system is on the content provider "side", end-users are not guaranteed any traces. If an OPES system is working inside end-user domain, the origin server is not guaranteed any traces related to user requests. 3. There are two distinct purposes/uses of traces. First, is to enable the "end (content producer or consumer) to detect OPES processor presence within end's trust domain. Such "end" should be able to see a trace entry, but does not need to be able to interpret it beyond identification of the trust domain(s). Second, is the domain administrator. The administrator should be able to take a trace entry (possibly supplied by an "end" as an opaque string) and interpret it. The administrator must be able to identify OPES processor(s) involved and may be able to identify applied adaptation services along with other message-specific information. That information should help to explain what OPES agent(s) were involved and what they did, but it is impractical to provide all the required information in all cases. A trace record is a hint, not an exhaustive audit. Moreover, since trust domains and their administration vary a lot, I would argue that we must give implementors a lot of freedom in what to put in trace records and how to format them. Trace records should be easy to extend beyond basic OPES requirements. Trace management algorithms should treat trace records as opaque data to the extent possible. Markus asked for tracing use cases. If we start collecting those, I would suggest to clearly document "end" and "admin" role in each use case. 4. (This is a consequence of #2 and #3 above) We should not expect entities in one trust domain to be able to get any OPES-related feedback from entities in other trust domains. For example, if I am an end-user, and I think that the page I am getting is corrupted by a callout service, I should not expect to be able to identify that service, contact its owner, or debug it _unless_ the service is within my trust domain. This is no different from the current situation where it is impossible, in general, to know the contact person for an application on an origin server that generates broken HTML; and even if the person is known, one should not expect that person to respond to end-user queries (in general). 4. We know that traces must be in-band. This [very reasonable] requirement limits both the number of application protocols that OPES can adapt and the amount of details a trace record can carry. The former limitation must be clearly documented somewhere so that folks do not try to apply OPES to unsupported applications only to find out months later that they cannot trace them. Some of us may want to supply additional information out-of-band to address the second limitation. Since architecture and protocol requirements drafts do not require support for out-of-band tracing details, I suggest that the WG should not spend much time on them and treat them as possible extensions to the tracing facility. Let's concentrate on in-band tracing for now. 5. There is a question on whether OPES processor (OCP client) or callout server (OCP server) must be responsible for adding trace records to application messages. I am not 100% sure, but I would suggest that we try to assign this task OPES processor exclusively. Here are my reasons: a) Exclusive assignment simplifies the protocol. b) There are use cases where callout services adapt payload regardless of the application protocol in use and leave header adjustment to OPES processor or other services. For example, think of a generic text translation or image modification service; such services require payload encoding knowledge but can be application-independent if OPES processor can supply them with just the payload. c) OPES processor is always _able_ to trace its own invocation and service(s) execution because OPES processor must understand the application protocol. Assigning these tracing tasks to callout servers is just an optimization in cases where callout servers manipulate application message headers. d) We are not required to trace services, just processors, AFAIK. e) It makes OPES compliance checks easier when remote 3rd party callout servers are used. f) Servers or services MAY add their own OPES trace records, of course. 6. #5 suggestion implies that tracing is out of OCP scope! :-) 7. How tracing is added is application protocol-specific and may be documented in separate RFCs/drafts. We can only document what tracing information is required and, perhaps, some common tracing elements. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 2 02:22:39 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21155 for ; Wed, 2 Apr 2003 02:22:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h327CLJM017803 for ; Tue, 1 Apr 2003 23:12:21 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h327CLi4017801 for ietf-openproxy-bks; Tue, 1 Apr 2003 23:12:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h327CLJM017772 for ; Tue, 1 Apr 2003 23:12:21 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <20030402071218052002h84de>; Wed, 2 Apr 2003 07:12:19 +0000 From: "Oskar Batuner" To: "Markus Hofmann" , "OPES Group" Subject: RE: Need to look at tracing and debuggig Date: Wed, 2 Apr 2003 02:12:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3E89DADF.4040600@mhof.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Let me summaraze relevant issues for the reference purposes: 1. Choice of the OPES application model. The OPES architecture provides two possibilities for placing application modules - OPES service application on the same computer as the OPES dispatcher and callout server. First case (initially called proxylet) comes as a natural extension of caching proxies. Some commercially available caches have proprietary API for adding application logics, like filtering capabilities. The proprietary nature of such extensions prevented extensive deployment, and I believe the whole OPES idea started as an attempt to standardize triggers (rules) and proxylet API, environment and deployment. Callout server comes either as a natural extension of the first model to offload application processing and create a scalable application structure or as a way to use a different class of devices - fast L7 switches - as an application building platform. What is common to both models - the central point, dispatcher, that is assigned the role of policy enforcement point. OPES facilities should not prefer one model over another, and this may be achieved by keeping OPES processor as a main representation center. It should be responsible for complying with tracing and other OPES requirements. It does not mean that it always has to keep persistent information, but in this case callout protocol should support directives for tracing control. Callout protocol may also support negotiation about insertion tracing information into the message. OPES processor should be able either to request necessary information from callout server or to issue directives for information insertion and verify that directive is accepted. Why I'm going into this lengthy discussion is that I got an impression that there is s shift to the second model that is causing some misunderstanding. Maybe I'm wrong. 2. Tracing information granularity and persistence levels. The information may be: - message-related, e.g. "virus checking done - passed", "content filtering applied", "translated from quibbish to danqush". Such information should be supplied with each message and indicate that specific action was taken. All data that describes specific actions performed for the message should be provided with that message, as there is no other way to find message level details later. OPES application (including OPES processor and all application modules and callout servers involved) is not supposed to keep volatile information after request processing is done. - session related. The session knowledge may be not directly supported by the protocol, as the case is for HTTP. In this situation OPES processor is responsible for keeping the session context. Session related information may be provided once per session, some details may be replaced by id or a reference for subsequient information retrieval. Session level data must be preserved for the duration of the session. OPES processor is responsible for inserting notifications if session-level information changes. Examples of session-related information is "virus checker abcd build 123 enabled", "OPES server id=xyz present". - log information id. This may be used e.g. for accounting and non-repudiation purposes. Detailed information referenced by this id may be not available online but can be retrieved later by some off-line procedure. - server related persistent information, e.g. "OPES center of authority ", "privacy policy ". It may be also presented once per session and it does not change between sessions. - end-point related data: what profile is activated (profile ID), where to get profile details, where to set preferences. I'm not sure how far we should go in this direction. I see other work going on in this area (e.g. [draft-barbir-opes-spcs-03.txt]). I thing OPES should provide a framework for such development by defining flexible and extensible tracing and informational facilities. 3. Some terminology. > Can we develop a few example scenarios that illustrate the various > concepts of "information points", "reference points", "identifier", - REFERENCE POINT - a reference that may be used out-of-band to perform a specific function. An example may be URI for the privacy policy, center of authority URI, server address, etc. Usually no protocol is provided to access the reference point. - INFORMATION POINT - implies presence of the protocol to access detailed information at this point. Example may be URI to get a certificate for virus checker or content filter, examine and set profile setting and active preferences. - IDENTIFIER - provides a unique binding to detailed persistent information. For example "transformation-applied : fe123" gives a participant ability to enquire (and maybe cache) details of the transformation fe123. Use of such (opaque) identifiers does not require prior knowledge and does not create a burden of storing additional information - this is just a tag for persistent information (not message-specific). 4. Using discretion of what points should be exposed. > If we don't identify the exact server, how would a service provider > trace a problem I report to him? How would he know which server to > check, if I tell him that something went wrong and check him to ask > this? With email, for example, I know exactly which mail servers have > been o the path, thus being able to trace down to the exact server. It is the choice of the service provider - what servers should be exposed. For example currently if pictures coming from some site are distorted or data is corrupted it is extremely difficult and often even impossible to tell what front-end or back-end servers are malfunctioning, especially in the presence of dynamically addressed CDN and multi-tier backend application. Usually notification containing the main URL and request parameters should be sufficient. Mail server is also a good example: you may see only representative of a server farm, some processing, like virus checking or spam filtering may be performed by invisible back-end servers. Still servers that are directly identified in the headers give resonable information for problem analysis. I'd recommend to minimise number of points exposed - in order to hide application complexity and dynamic reconfiguration but provide a separate logical places for information requiests and references. In most cases OPES processor should hide underlying application structure and care the burden of relayng some requests (both in-line and out-of-band) to callout processors. This does not require storage of additional data - at each moment OPES procesor knows all underlying configuratiuon details and can determine what callout processor should answer the request. 5. Additional protocol and schema definitions. > Do we have to decide on a specific protocol to be used for this > purpose, or can we leave this open and just indicated the protocol to > be used (e.g. withing the embedded URI). As we are building the OPES framework from top to bottom we understandably delay details introduction until we are at the appropriate level of specification. But at some point this specifics has to be defined. If we define all HTTP extensions necessary to implement HTTP-based OPES system but for the information point only URI is defined, then interoperation of different implementations may become a problem. Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann > Sent: Tuesday, April 01, 2003 1:31 PM > To: OPES Group > Subject: Re: Need to look at tracing and debuggig > > > > Oskar, > > great input, thanks. Just some quick, minor comments: > > > 1. Tracing information has to be provided in-band, I see no > > other way to satisfy current architecture requirements. The > > OPES architecture states that: > > I agree with that. The question is, though, whether the callout > protocol itself will also carry some tracing information, or whether > the callout server will embedd possible tracing information directly > into the application message. > > > 2. We have to decide on the in-band - out-of-band balance for tracing > > facilities. Two extreme approaches are: > > > > - in-band data provides only a reference to the point to the > facility where > > the tracing information may be obtained; > > > > - include all information in-band. > > > > Advantage of the first approach: a) Tracing information may be provided > > in application protocol independent manner. b) Level of details is > > determined by direct request, lengthy descriptions may be provided > > without an impact on the application protocol efficiency. > > Disadvantages: a complex identification mechanism is needed to retrieve > > application message specific information (like "virus checking > applied"), and > > getting such simple notification will involve overhead of creating or > > keeping an additional connection. > > Nice comments. I was tempted to lean towards the first approach with a > refrence to a point for retrieval, but.... Where would such point of > tracing information retrieval be? Would you assume that, for example, > I can retrieve detailed tracing information about a provided OPES > service directly from the callout server the service has been > executed? Such a callout server might very well sit behind a NAT and > might have a non-routable IP adress... If it's not directly on the > callout server, how would the callout server provide the required > tracing information to the other entity? > > > The second approach provides a kind of opposite advantages and > disadvantages: > > simple per-message information binding but application protocol may be > > cluttered > > with excess information that is not relevant to the current > session (may be > > due to the lack of interest of the participants). > > > > An additional advantage of in-band approach is end-to-end > coverage: tracing > > information and related directives are available to all OPES flow > > participants, > > no topology knowledge is required. > > Yup, good point, have to agree. > > > A reasonable combination may include message-related information > in band and > > a reference to the session-related information. To adjust in-band > information > > level to the needs of session participants some trace control directives > > should > > be defined (as an application protocol extensions). > > Could you provide a specific example for session-related information > (as opposed to message-related)? > > > The purpose of identification (exposure) should be defined by the > > intended use. Only the information points (where some participant > > may call for additional information) and reference points (those > that should > > be identified in related request, e.g. to the center of > authority) should be > > exposed. If there are points that may accept directives (e.g. privacy > > directives) - they should be exposed. > > > > Also session participants should be notified about the center of > > authority for the OPES server. > > [...] > > Can we develop a few example scenarios that illustrate the various > concepts of "information points", "reference points", "identifier", > etc., and how they play together? > > > Any such explicitly identified point may be on the path or out of > the path, > > this should not be a factor. Points on the path are exposed by IP, > > as according to IAB requirements connections are terminated at > these points. > > The IAB considerations state that "the OPES intermediary must be > explicitly addressed at the IP layer by the end user", which > translates that (only) the first "hop", i.e. the first OPES > intermediary on the path, has to be addreessable explicitely. Others > might very well sit behind a NAT or so. > > > > Information about services should be provided in-band and should uniquely > > identify the service provider and service type, but not the service point > > (OPES > > server). This makes service information location independent and > facilitates > > system reconfiguration, including failover and recovery: agreements and > > parameters > > may be transferred to another OPES server (within the same trust domain) > > without > > renegotiation with end-point. > > If we don't identify the exact server, how would a service provider > trace a problem I report to him? How would he know whichserver to > check, if I tell him that something went wrong and check him to ask > this? With email, for example, I know exactly which mail servers have > been o nthe path, thus being able to trace down to the exact server. > > > Direct point exposure (let's say by inclusion of URL into the tracing > > information) > > raises a question about out-of-band protocol used to access this point. > > SOAP looks like a good candidate for that. > > Do we have to decide on a specific protocol to be used for this > purpose, or can we leave this open and just indicated the protocol to > be used (e.g. withing the embedded URI). > >-Markus > From owner-ietf-openproxy@mail.imc.org Wed Apr 2 10:25:22 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13632 for ; Wed, 2 Apr 2003 10:25:19 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FAqJM007899 for ; Wed, 2 Apr 2003 07:10:52 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32FAqWi007898 for ietf-openproxy-bks; Wed, 2 Apr 2003 07:10:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FAlJM007882 for ; Wed, 2 Apr 2003 07:10:48 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2003040215104200200744jbe>; Wed, 2 Apr 2003 15:10:43 +0000 From: "Oskar Batuner" To: "Alex Rousskov" , "OPES Group" Subject: RE: Need to look at tracing and debuggig Date: Wed, 2 Apr 2003 10:10:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Wednesday, April 02, 2003 1:53 AM > To: OPES Group > Subject: RE: Need to look at tracing and debuggig > > > > > More thoughts on tracing and debugging. > > 1. I could not find any reference to "debugging" in architecture > and OCP requirements drafts. Shouldn't we talk just about > tracing/reporting? I am not sure what exactly others mean by > debugging, but since it is not required, we do not have to > worry about it. Tracing helps with debugging, of course, > but let's concentrate on immediate goals. Please correct me > if I missed debugging requirements. > > 2. It is very important to keep in mind that tracing is limited > to the trust domain. Anybody outside of that domain may or may not > see any traces, depending on domain policies/configuration. In > other words, we are not talking about mandatory end-to-end tracing > facility here. For example, if an OPES system is on the content > provider "side", end-users are not guaranteed any traces. If an > OPES system is working inside end-user domain, the origin server is > not guaranteed any traces related to user requests. I'm afraid the situation is more complicated. While ability to control tracing facility and level of details available inside and outside of the trust domain may be different there are some requirements (e.g. privacy) that are not limited to the trust domain. Both IAB requirements and the architecture mandate some end-to-end disclosures. > > 3. There are two distinct purposes/uses of traces. First, is to > enable the "end (content producer or consumer) to detect OPES > processor presence within end's trust domain. Such "end" should be > able to see a trace entry, but does not need to be able to > interpret it beyond identification of the trust domain(s). > > Second, is the domain administrator. The administrator should be > able to take a trace entry (possibly supplied by an "end" as an > opaque string) and interpret it. The administrator must be able to > identify OPES processor(s) involved and may be able to identify > applied adaptation services along with other message-specific > information. That information should help to explain what OPES > agent(s) were involved and what they did, but it is impractical to > provide all the required information in all cases. A trace record > is a hint, not an exhaustive audit. > > Moreover, since trust domains and their administration vary a lot, > I would argue that we must give implementors a lot of freedom in > what to put in trace records and how to format them. Trace records > should be easy to extend beyond basic OPES requirements. Trace > management algorithms should treat trace records as opaque data to > the extent possible. > > Markus asked for tracing use cases. If we start collecting those, I > would suggest to clearly document "end" and "admin" role in each > use case. There are more participants interested in tracing information. Independent OPES processors in the same OPES flow might want to know about each other existence and might need to cooperate. For example virus checker may be satisfied by the signature of another virus checker, ad insertion/localization servers may avoid stepping on each other toes, etc. In fact you are describing two roles. We should use this approach - roles, not topology based description - end vs. intermediate. > > 4. (This is a consequence of #2 and #3 above) We should not expect > entities in one trust domain to be able to get any OPES-related > feedback from entities in other trust domains. For example, if I am > an end-user, and I think that the page I am getting is corrupted by > a callout service, I should not expect to be able to identify > that service, contact its owner, or debug it _unless_ the > service is within my trust domain. This is no different from > the current situation where it is impossible, in general, to know > the contact person for an application on an origin server that > generates broken HTML; and even if the person is known, one should > not expect that person to respond to end-user queries (in general). Yes, but... For example you expect to be able to access content provider's privacy policy and security credentials. Same is true for OPES processors. Again, the amount of information and level of control may be different but still some information should be provided. > > 4. We know that traces must be in-band. This [very reasonable] > requirement limits both the number of application protocols that > OPES can adapt and the amount of details a trace record can carry. > > The former limitation must be clearly documented somewhere so that > folks do not try to apply OPES to unsupported applications only to > find out months later that they cannot trace them. > > Some of us may want to supply additional information out-of-band to > address the second limitation. Since architecture and protocol > requirements drafts do not require support for out-of-band tracing > details, I suggest that the WG should not spend much time on them > and treat them as possible extensions to the tracing facility. > Let's concentrate on in-band tracing for now. There are certain things that should be provided as references, e.g. privacy policy. Extending combined approach with some persistent information replaced by references give much greater flexibility and makes application protocol more efficient. See detailed discussion in my previous message - posted exactly at the same time as yours :). Well, yours is fifteen minutes earlier. > > 5. There is a question on whether OPES processor (OCP client) or > callout server (OCP server) must be responsible for adding trace > records to application messages. I am not 100% sure, but I would > suggest that we try to assign this task OPES processor exclusively. > Here are my reasons: > > a) Exclusive assignment simplifies the protocol. > > b) There are use cases where callout services adapt payload > regardless of the application protocol in use and leave header > adjustment to OPES processor or other services. For example, > think of a generic text translation or image modification > service; such services require payload encoding knowledge but > can be application-independent if OPES processor can supply > them with just the payload. > > c) OPES processor is always _able_ to trace its own invocation > and service(s) execution because OPES processor must understand > the application protocol. Assigning these tracing tasks to > callout servers is just an optimization in cases where callout > servers manipulate application message headers. > > d) We are not required to trace services, just processors, > AFAIK. > > e) It makes OPES compliance checks easier when remote 3rd > party callout servers are used. > > f) Servers or services MAY add their own OPES trace records, > of course. Yes, can not agree more! See my previous post. > > 6. #5 suggestion implies that tracing is out of OCP scope! :-) I'm afraid - not. For example OPES processor should be able to get information about callout server privacy policy and might want to control insertion of tracing information into application messages. This has to be supported by the OCP :-( > > 7. How tracing is added is application protocol-specific and may be > documented in separate RFCs/drafts. We can only document what tracing > information is required and, perhaps, some common tracing elements. We can delay specification details while we are describing high level architecture. But the ultimate goal is an implementable specification, and to support application interoperation we have to specify all essential formats and protocols. This may span multiple RFCs/draft but the final result should be the same - implementable specification with guaranteed interoperability. Oskar From owner-ietf-openproxy@mail.imc.org Wed Apr 2 11:50:39 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17667 for ; Wed, 2 Apr 2003 11:50:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32GYFJM016316 for ; Wed, 2 Apr 2003 08:34:15 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32GYErQ016315 for ietf-openproxy-bks; Wed, 2 Apr 2003 08:34:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32GYDJM016297 for ; Wed, 2 Apr 2003 08:34:13 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32GY0M09521; Wed, 2 Apr 2003 08:34:01 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 08:33:45 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93019C5A63@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: Alex Rousskov , OPES Group Subject: Comments on ocp-00 Date: Wed, 2 Apr 2003 08:33:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F935.9CA7BB3A" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2F935.9CA7BB3A Content-Type: text/plain 1) " application message: A sequence of octets that OPES processor designates for callout service processing. Usually, an application message is the basic unit of application protocol communication, as defined by that application protocol (e.g., HTTP/1.1 message). Before OCP is applied, OPES processor may pre-process raw application messages to extract and manipulate well-known parts (e.g., HTTP message headers or SMTP message body) in order to subject just those parts to callout services. For the purpose of OCP, the result of such preprocessing is an application message. Naturally, OPES processor and callout services it is configured to use must agree on what application messages are acceptable. Establishing such an agreement is beyond OCP scope." Everything after "Before OCP..." has nothing to do with the definition of application message anymore. This has to do with the workings of the protocol. Although I suggest to rip out the last part of this definition I should say that I disagree (if I understood correctly) with your statement "Establishing such an agreement is beyond OCP scope". Capability negotiation can help you establish what application messages are acceptable on each connection or callout server as a whole. Suggested version. " application message: A sequence of octets that OPES processor designates for callout service processing. Usually, an application message is the basic unit of application protocol communication, as defined by that application protocol (e.g., HTTP/1.1 message). 2) "A callout server may send this data back to the OPES processor, with or without modifications." Suggestion "A callout server may send or not this data back to the OPES processor. When the callout server sends data back to the OPES processor, it can be modified or not." 3) "The primary purpose of OCP communications is modification of application message payloads..." Do not want to seem picky, but the primary purpose of OCP is to ship packets back and forth between Callout Server and OPES Processor. Whatever is done with message has nothing to do with OCP anymore. It is a function totally contained within the callout server. I guess you can say "The primary purpose of the OCP is to send data to the callout server where it will be examined and possibly changed" 4) " OCP transaction is a logical sequence of OCP messages processing a single original application message. The result of the processing may be zero or more application messages, adapted from the original. A typical transaction consists of two message flows: a flow from the CLIENT to the SERVER (sending original application message) and a flow from the SERVER to the CLIENT (sending adapted application messages). The number of application messages produced by the SERVER and whether the SERVER actually modifies original application message depends on the requested callout service. The CLIENT or the SERVER can terminate the transaction by sending a corresponding message to the other side." Hummm...I guess I'm not confortable with the idea of mixing the OCP semantics per se and whatever it carries..The problem with this approach is that we will start asking things like "what is the original application message?". "Is the the whole HTTP 1.1 message before TCP fragmentation or after?" , "And if is protocol X..and Y", etc, etc. This is my (lean) suggestion using your definitions: " An OCP transaction is a logical exchange of OCP messages. A OCP transaction starts with a xaction-start message, followed by zero or more data-xxx messages, zero or more appl-xxx and ends with a xaction-end message. " 5) "xid: OCP transaction identifier. Uniquely identifies an OCP transaction originated by a given CLIENT. Since each transaction deals with a single application message, "xid" also identifies that application message." As you can guess, IMHO the part ""xid" also identifies that application message." is troublesome. My suggestion "xid: OCP transaction identifier. Uniquely identifies an OCP transaction originated by a given CLIENT." 6) "am-id: Application message identifier. Uniquely identifies an application message within an OCP transaction." I guess it is one more reason to make the modification I mention in number 5) above. 7) " am-source: Information about the source of an application message. For example, HTTP client or origin server IP address and TCP connection ID. am-destination: Information about the destination of an application message. For example, HTTP client or origin server address." I'm not sure I follow this...TCP connection ID? Information about the source of an application message? 8) "size: Application data size in octets. The value either applies to the data attached to an OCP message or suggests data size to be sent in response to an OCP message." Is this the original value (which I guess before reaseembly it cannot be known)? The value of the OCP payload? 9) "modified: A boolean parameter indicating that the attached application data has been modified by he SERVER. Only SERVER may send this flag. This parameter can be used with any OCP message that has am-id parameter." Suggestion "modified: A boolean parameter indicating that the attached application data has been modified by the SERVER. Only the SERVER may send this flag. This parameter can be used with any OCP message that has am-id parameter." I guess the caveat is that if you but the flag in one OCP message containing am-id, you have to put in all of them for the same am-id. 10) "copied: A flag indicating that a copy of the attached application data is being kept at the CLIENT. Only the CLIENT may send this flag. This parameter can be used with any OCP message that may carry application message data. (XXX: it is yet unclear when CLIENT commitment to preserve the data may end.)" Same caveat as above. 11) "sizep: Remaining application data size prediction in octets. The value excludes data in the current OCP message, if any. The prediction applies to a single application message. This parameter can be used with any OCP message that has am-id parameter. modp: Future data modification prediction in percents. A modp value of 0 (zero) means the sender predicts that there will be no data modifications. A value of 100 means the sender is predicts that there will be data modifications. The value excludes data in the current OCP message, if any. The prediction applies to a single application message. This parameter can be used with any OCP message that has am-id parameter." I guess we need to hash this out in much for detail... 12) "error: A flag indicating abnormal conditions at the sender that cannot be expressed via result parameter. " Such as? I guess maybe we could maintain the HTTP/SIP approach where we have status code and reason phrases for everything. "It is RECOMMENDED that the recipient deletes all state associated with the corresponding OCP message. For example, if the message is 'app-message-end' and the application message contained user credentials, such credentials should be deleted." My suggestion ""It is RECOMMENDED that the recipient deletes all state associated with the corresponding OCP message." 13) "feature: A OCP feature identifier with optional feature parameters. Used to declare support and negotiate use of OCP optional features (e.g., copying of data chunks at the CLIENT)." I guess this is another one we need to iron out... 14) "If a malformed message is received, the recipient MUST terminate processing of the corresponding OCP connection using 'connection-end' message with an error flag" Why not send a status code and reason phrase instead of this error flag? Just say "400 Bad Request"...or "400 Malformed Message" 15) "This is the only OCP message that may carry application data. There MUST NOT be any gaps in data supplied by data-have and data-as-is messages (i.e., the offset of the next data message must be equal to the offset+size of the previous data message) (XXX: we do not need offset then; should we keep it as a validation mechanism?) (XXX: document what to do when this MUST is violated). Zero size is permitted and is useful for communicating predictions without sending data." Well, although we must not have gaps, we might loose packets...we need to be able to recover and not throw all the OCP messages received so far away... ` That's it for now.. I will send more comments later. Regards, Reinaldo ------_=_NextPart_001_01C2F935.9CA7BB3A Content-Type: text/html Content-Transfer-Encoding: quoted-printable Comments on ocp-00

1)

" application message: A sequence of octets that = OPES processor
      designates for = callout service processing.  Usually, an
      application message = is the basic unit of application protocol
      communication, as = defined by that application protocol (e.g.,
      HTTP/1.1 = message).  Before OCP is applied, OPES processor may
      pre-process raw = application messages to extract and manipulate
      well-known parts = (e.g., HTTP message headers or SMTP message body)
      in order to subject = just those parts to callout services. For the
      purpose of OCP, the = result of such preprocessing is an application
      message. Naturally, = OPES processor and callout services it is
      configured to use = must agree on what application messages are
      acceptable. = Establishing such an agreement is beyond OCP scope."


Everything after "Before OCP..." has = nothing to do with the definition of application message anymore. This = has to do with the workings of the protocol.

Although I suggest to rip out the last part of this = definition I should say that I disagree (if I understood correctly) = with your statement "Establishing such an agreement is beyond OCP = scope". Capability negotiation can help you establish what = application messages are acceptable on each connection or callout = server as a whole.


Suggested version.

" application message: A sequence of octets that = OPES processor
      designates for = callout service processing.  Usually, an
      application message = is the basic unit of application protocol
      communication, as = defined by that application protocol (e.g.,
      HTTP/1.1 = message). 

2)

"A callout server may send this data back = to
   the OPES processor, with or without = modifications."

Suggestion

"A callout server may send or not this data back = to the OPES processor. When the callout server sends data back to the = OPES processor, it can be modified or not."

3)

"The primary purpose of OCP communications is = modification of
   application message = payloads..."

Do not want to seem picky, but the primary purpose of = OCP is to ship packets back and forth between Callout Server and OPES = Processor. Whatever is done with message has nothing to do with OCP = anymore. It is a function totally contained within the callout = server.

I guess you can say

"The primary purpose of the OCP is to send data = to the callout server where it will be examined and possibly = changed"

4)

"   OCP transaction is a logical = sequence of OCP messages processing a
   single original application message. = The result of the processing may
   be zero or more application messages, = adapted from the original. A
   typical transaction consists of two = message flows: a flow from the
   CLIENT to the SERVER (sending original = application message) and a
   flow from the SERVER to the CLIENT = (sending adapted application
   messages). The number of application = messages produced by the SERVER
   and whether the SERVER actually = modifies original application message
   depends on the requested callout = service. The CLIENT or the SERVER
   can terminate the transaction by = sending a corresponding message to
   the other side."

Hummm...I guess I'm not confortable with the idea of = mixing the OCP semantics per se and whatever it carries..The problem = with this approach is that we will start asking things like "what = is the original application message?". "Is the the whole HTTP = 1.1 message before TCP fragmentation or after?" , "And if is = protocol X..and Y", etc, etc.

This is my (lean) suggestion using your = definitions:

"  An OCP transaction is a logical exchange = of OCP messages.

   A OCP transaction starts with a = xaction-start message, followed
   by zero or more data-xxx messages, zero = or more appl-xxx and ends
   with a xaction-end message. = "


5)

"xid: OCP transaction identifier.  Uniquely = identifies an OCP
      transaction = originated by a given CLIENT. Since each transaction
      deals with a single = application message, "xid" also identifies
      that application = message."


As you can guess, IMHO the part ""xid" = also identifies that application message." is troublesome.

My suggestion

"xid: OCP transaction identifier.  Uniquely = identifies an OCP
      transaction = originated by a given CLIENT."

6)

"am-id: Application message identifier.  = Uniquely identifies an
      application message = within an OCP transaction."

I guess it is one more reason to make the = modification I mention in number 5) above.

7)

"   am-source: Information about the = source of an application message.
      For example, HTTP = client or origin server IP address and TCP
      connection ID.

   am-destination: Information about the = destination of an application
      message. For example, = HTTP client or origin server address."

I'm not sure I follow this...TCP connection ID? = Information about the source of an application message?

8)

"size: Application data size in octets. The = value either applies to
      the data attached to = an OCP message or suggests data size to be
      sent in response to = an OCP message."

Is this the original value (which I guess before = reaseembly it cannot be known)? The value of the OCP payload?

9)

"modified: A boolean parameter indicating that = the attached
      application data has = been modified by he SERVER.  Only SERVER may
      send this flag. This = parameter can be used with any OCP message
      that has am-id = parameter."

Suggestion

"modified: A boolean parameter indicating that = the attached
      application data has = been modified by the SERVER. Only the SERVER may
      send this flag. This = parameter can be used with any OCP message
      that has am-id = parameter."

I guess the caveat is that if you but the flag in one = OCP message containing am-id, you have to put in all of them for the = same am-id.

10)

"copied: A flag indicating that a copy of the = attached application
      data is being kept at = the CLIENT. Only the CLIENT may send this
      flag. This parameter = can be used with any OCP message that may
      carry application = message data. (XXX: it is yet unclear when
      CLIENT commitment to = preserve the data may end.)"

Same caveat as above.

11)

"sizep: Remaining application data size = prediction in octets. The
      value excludes data = in the current OCP message, if any. The
      prediction applies to = a single application message. This parameter
      can be used with any = OCP message that has am-id parameter.

   modp: Future data modification = prediction in percents. A modp value
      of 0 (zero) means the = sender predicts that there will be no data
      modifications. A = value of 100 means the sender is predicts that
      there will be data = modifications.  The value excludes data in the
      current OCP message, = if any.  The prediction applies to a single
      application message. = This parameter can be used with any OCP
      message that has = am-id parameter."

I guess we need to hash this out in much for = detail...

12)

"error: A flag indicating abnormal conditions at = the sender that
      cannot be expressed = via result parameter. "

Such as? I guess maybe we could maintain the HTTP/SIP = approach where we have status code and reason phrases for = everything.


"It is RECOMMENDED that
      the recipient deletes = all state associated with the corresponding
      OCP message. For = example, if the message is 'app-message-end' and
      the application = message contained user credentials, such
      credentials should be = deleted."

My suggestion


""It is RECOMMENDED that
      the recipient deletes = all state associated with the corresponding
      OCP = message."

13)

"feature: A OCP feature identifier with optional = feature parameters.
      Used to declare = support and negotiate use of OCP optional features
      (e.g., copying of = data chunks at the CLIENT)."

I guess this is another one we need to iron = out...

14)

"If a malformed message is received, the = recipient MUST terminate
   processing of the corresponding OCP = connection using 'connection-end'
   message with an error flag"

Why not send a status code and reason phrase instead = of this error flag?

Just say "400 Bad Request"...or "400 = Malformed Message"

15)

"This is the only OCP message that may carry = application data. There
   MUST NOT be any gaps in data supplied = by data-have and data-as-is
   messages (i.e., the offset of the next = data message must be equal to
   the offset+size of the previous data = message) (XXX: we do not need
   offset then; should we keep it as a = validation mechanism?) (XXX:
   document what to do when this MUST is = violated).  Zero size is
   permitted and is useful for = communicating predictions without sending
   data."

Well, although we must not have gaps, we might loose = packets...we need to be able to recover and not throw all the OCP = messages received so far away...

        `
That's it for now..

I will send more comments later.

Regards,

Reinaldo









------_=_NextPart_001_01C2F935.9CA7BB3A-- From owner-ietf-openproxy@mail.imc.org Wed Apr 2 12:12:26 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19187 for ; Wed, 2 Apr 2003 12:12:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32Gx2JM017960 for ; Wed, 2 Apr 2003 08:59:02 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Gx2sa017959 for ietf-openproxy-bks; Wed, 2 Apr 2003 08:59:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32Gx0JM017955 for ; Wed, 2 Apr 2003 08:59:00 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h32Gx2vj092682 for ; Wed, 2 Apr 2003 09:59:02 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h32Gx2Al092681; Wed, 2 Apr 2003 09:59:02 -0700 (MST) (envelope-from rousskov) Date: Wed, 2 Apr 2003 09:59:02 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: ICAP extensions for parsing av responses? (fwd) Message-ID: 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: -- The message below documents "feedback" or "additional info" functionality that OCP MAY want to support and that ICAP does not support directly. I am forwarding this to the group so that we keep similar functional requirements in mind. I do not know yet whether it is actually a good idea to support them. An alternative is to task the callout server with inserting additional info (if any) into the application message itself, essentially preventing further automated processing and analysis. Alex. ---------- Forwarded message ---------- Date: Wed, 02 Apr 2003 13:01:09 +0200 From: Rainer Link To: ICAP-Discussions@yahoogroups.com Subject: ICAP extensions for parsing av responses? (was: Re: [ICAP-Discussions] NetCache and subscriber ID or client IP .. Question) As we're on topic wrt ICAP extensions. For my samba-vscan project (http://www.openantivirus.org/projects.php), which allows on-access scanning of Samba shares, I wrote a very basic icap-client module. It currently works only with Symantec AntiVirus Engine (why? please see below). The response from SAVE looks like $ ./icap-client ~/eicar.com -ssr [..] ICAP/1.0 403 Forbidden. Infected And Not Repaired ISTag: "1049280360" Date: Wed Apr 2 10:46:18 2003 GMT Service: Symantec AntiVirus Scan Engine/4.0.3.41 Service-ID: SYMCScan/4.0.3.41 X-Infection-Found: Type=0; Resolution=0; Threat=EICAR Test String; X-Violations-Found: 1 eicar.com EICAR Test String 11101 0 To get the virus name, the icap-client module parses the X-Infection-Found line (it should better parse X-Violations-Found). But I assume, other producs like Finjan, Trend Micro or WebWasher (with the McAfee Engine) use another format to report the virus name(s) back. (*) So, in short, ICAP is a generic protocol to talk to various ICAP AntiVirus servers, but imho there's no generic way to retrieve the virus name(s). Either my client must ship with some kind of a configuration file, which can be used to set up the patters to mach for the virus name. Or the OPTIONS response must contain some information, how to parse the RESPMOD/RESQMOD response to get it. Or it has to specified in the ICAP specs. Probably I missed a method? From owner-ietf-openproxy@mail.imc.org Wed Apr 2 13:30:16 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22074 for ; Wed, 2 Apr 2003 13:30:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IAwJM020426 for ; Wed, 2 Apr 2003 10:10:58 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32IAwvB020425 for ietf-openproxy-bks; Wed, 2 Apr 2003 10:10:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32IAuJM020421 for ; Wed, 2 Apr 2003 10:10:56 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h32IAvvj094381; Wed, 2 Apr 2003 11:10:57 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h32IAvJ4094380; Wed, 2 Apr 2003 11:10:57 -0700 (MST) (envelope-from rousskov) Date: Wed, 2 Apr 2003 11:10:57 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Need to look at tracing and debuggig In-Reply-To: Message-ID: References: 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: On Wed, 2 Apr 2003, Oskar Batuner wrote: > > 1. I could not find any reference to "debugging" in architecture > > and OCP requirements drafts. Shouldn't we talk just about > > tracing/reporting? I am not sure what exactly others mean by > > debugging, but since it is not required, we do not have to > > worry about it. Tracing helps with debugging, of course, > > but let's concentrate on immediate goals. Please correct me > > if I missed debugging requirements. > > > > 2. It is very important to keep in mind that tracing is limited > > to the trust domain. Anybody outside of that domain may or may not > > see any traces, depending on domain policies/configuration. In > > other words, we are not talking about mandatory end-to-end tracing > > facility here. For example, if an OPES system is on the content > > provider "side", end-users are not guaranteed any traces. If an > > OPES system is working inside end-user domain, the origin server is > > not guaranteed any traces related to user requests. > > I'm afraid the situation is more complicated. While ability to > control tracing facility and level of details available inside and > outside of the trust domain may be different there are some > requirements (e.g. privacy) that are not limited to the trust > domain. Both IAB requirements and the architecture mandate some > end-to-end disclosures. Let's be more specific. I did not find any IAB considerations that mandate automated end-to-end disclosures. There is some discussion that content providers may benefit from knowing client-side OPES actions, but the only consideration is that "The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries". This consideration is too vague; it can be satisfied by, for example, asking the user to manually supply OPES-specific headers to the content provider if the provider suspects inappropriate OPES behavior by observing HTTP Via headers or equivalent. As IAB notes, implementing this assistance goes against implementors objectives (client-side OPES system does not care about server-side desires). Thus, it would be a waste of time in implementing any sophisticated/detailed (hence expensive) notification facility that spans trust domains. Moreover, requiring such facility on a MUST level clearly violates client-side privacy considerations. I agree that we should require (at a SHOULD level) some minimal form of cross-trust-domain tracing similar to current HTTP Via headers, but I would not go far beyond that. > > Markus asked for tracing use cases. If we start collecting those, I > > would suggest to clearly document "end" and "admin" role in each > > use case. > > There are more participants interested in tracing information. > Independent OPES processors in the same OPES flow might want to know > about each other existence and might need to cooperate. For example > virus checker may be satisfied by the signature of another virus > checker, ad insertion/localization servers may avoid stepping on > each other toes, etc. Sure. > In fact you are describing two roles. We should use this approach - > roles, not topology based description - end vs. intermediate. I have no problems with that. Both approaches may co-exist actually. > > 4. (This is a consequence of #2 and #3 above) We should not expect > > entities in one trust domain to be able to get any OPES-related > > feedback from entities in other trust domains. For example, if I am > > an end-user, and I think that the page I am getting is corrupted by > > a callout service, I should not expect to be able to identify > > that service, contact its owner, or debug it _unless_ the > > service is within my trust domain. This is no different from > > the current situation where it is impossible, in general, to know > > the contact person for an application on an origin server that > > generates broken HTML; and even if the person is known, one should > > not expect that person to respond to end-user queries (in general). > > Yes, but... For example you expect to be able to access content > provider's privacy policy and security credentials. Same is true for > OPES processors. Again, the amount of information and level of > control may be different but still some information should be > provided. Provider != OPES intermediary. The mechanism for end users to determine the privacy policy of a server-centric intermediary is to visit the corresponding web page on provider's web site. For end users, there can be no clear distinction between server-side OPES intermediary and the "server-side" as a whole. For starters, a particular server-side [OPES] intermediary may not be directly addressable by the end-user. IAB RFC clearly states that only the first intermediary in the chain must be addressable. That first intermediary may be a L7 load balancer, for example. L7 load balancers do not have a privacy policy. > There are certain things that should be provided as references, e.g. > privacy policy. Extending combined approach with some persistent > information replaced by references give much greater flexibility and > makes application protocol more efficient. Sure. I have no problems with allowing additional information to be provided via references. We can discuss whether it would make sense to require any specific references. > > 5. There is a question on whether OPES processor (OCP client) or > > callout server (OCP server) must be responsible for adding trace > > records to application messages. I am not 100% sure, but I would > > suggest that we try to assign this task OPES processor exclusively. > > Yes, can not agree more! See my previous post. > > > > > 6. #5 suggestion implies that tracing is out of OCP scope! :-) > > I'm afraid - not. For example OPES processor should be able to get > information about callout server privacy policy Why should it? The architecture draft says "Protocol(s) for policy/rule distribution are out of scope for this document, but the OPES architecture assumes the existence of such a mechanism". You do not really expect OPES processors to care about every callout server privacy policy, do you? Content providers have privacy policies. Server-side callout servers do not have to (because they are operating under the content provider policy). > and might want to control insertion of tracing information into > application messages. This has to be supported by the OCP :-( Depends on what tracing information we want to support. For example, if we want OPES processor to insert service identifier into an application message, the processor can do it without OCP-level support. > > 7. How tracing is added is application protocol-specific and may be > > documented in separate RFCs/drafts. We can only document what tracing > > information is required and, perhaps, some common tracing elements. > > We can delay specification details while we are describing high level > architecture. But the ultimate goal is an implementable specification, > and to support application interoperation we have to specify all essential > formats and protocols. This may span multiple RFCs/draft but the final > result should be the same - implementable specification with guaranteed > interoperability. Yes, of course. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 2 14:05:06 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23371 for ; Wed, 2 Apr 2003 14:05:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32InfJM021573 for ; Wed, 2 Apr 2003 10:49:41 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32InfNK021572 for ietf-openproxy-bks; Wed, 2 Apr 2003 10:49:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32IndJM021568 for ; Wed, 2 Apr 2003 10:49:40 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h32Infvj095343; Wed, 2 Apr 2003 11:49:41 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h32InfED095342; Wed, 2 Apr 2003 11:49:41 -0700 (MST) (envelope-from rousskov) Date: Wed, 2 Apr 2003 11:49:41 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Need to look at tracing and debuggig In-Reply-To: Message-ID: References: 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: On Wed, 2 Apr 2003, Oskar Batuner wrote: > Let me summaraze relevant issues for the reference purposes: > > 1. Choice of the OPES application model. > > The OPES architecture provides two possibilities for placing > application modules - OPES service application on the same computer > as the OPES dispatcher and callout server. First case (initially > called proxylet) comes as a natural extension of caching proxies. > Some commercially available caches have proprietary API for adding > application logics, like filtering capabilities. The proprietary > nature of such extensions prevented extensive deployment, and I > believe the whole OPES idea started as an attempt to standardize > triggers (rules) and proxylet API, environment and deployment. > > Callout server comes either as a natural extension of the first > model to offload application processing and create a scalable > application structure or as a way to use a different class of > devices - fast L7 switches - as an application building platform. > > What is common to both models - the central point, dispatcher, that > is assigned the role of policy enforcement point. Actually, the two models are equivalent except for communication costs between OCP agents. I cannot think of any other difference between "same computer" and "other computer" placements, not to mention that "same computer" is very difficult to define (same CPU? same processor block? same server farm? same owner? etc.) Thus, I would suggest that we keep varying communication costs in mind but make no other assumptions or distinctions. > OPES facilities should not prefer one model over another, and this > may be achieved by keeping OPES processor as a main representation > center. It should be responsible for complying with tracing and > other OPES requirements. It does not mean that it always has to > keep persistent information, but in this case callout protocol > should support directives for tracing control. Callout protocol > may also support negotiation about insertion tracing information > into the message. OPES processor should be able either to request > necessary information from callout server or to issue directives > for information insertion and verify that directive is accepted. > > Why I'm going into this lengthy discussion is that I got > an impression that there is s shift to the second model that is > causing some misunderstanding. Maybe I'm wrong. I do not see a clear connection between "OPES facilities should not prefer one model over another" and the rest of the paragraphs. I do agree with the opening statement. However, I think it is premature to make conclusions regarding OCP involvement. I would suggest that we agree on what tracing information must be supported first, and only after that talk about how to support it (in OCP or elsewhere). > 2. Tracing information granularity and persistence levels. > The information may be: > > - message-related, e.g. "virus checking done - passed", "content > filtering applied", "translated from quibbish to danqush". Such > information should be supplied with each message and indicate that > specific action was taken. All data that describes specific actions > performed for the message should be provided with that message, as > there is no other way to find message level details later. OPES > application (including OPES processor and all application modules > and callout servers involved) is not supposed to keep volatile > information after request processing is done. Agreed. > - session related. The session knowledge may be not directly > supported by the protocol, as the case is for HTTP. In this > situation OPES processor is responsible for keeping the > session context. Session related information may be provided > once per session, some details may be replaced by id or a > reference for subsequient information retrieval. > > Session level data must be preserved for the duration of > the session. OPES processor is responsible for inserting > notifications if session-level information changes. > > Examples of session-related information is "virus checker > abcd build 123 enabled", "OPES server id=xyz present". I am not convinced we have to support these kind of tracing. The end does not usually care whether "virus checker abcd build 123 is enabled"; it cares only wether that virus checker has seen or modified the application message, which is already covered by "message-related" bullet above. Same for "OPES server id=xyz present". What is a session? What are session boundaries? How do those boundaries correspond to message/connection boundaries? And, finally, why should we care about anything that does not affect our application message? > - log information id. This may be used e.g. for accounting > and non-repudiation purposes. Detailed information referenced > by this id may be not available online but can be retrieved > later by some off-line procedure. This belongs to the "message-related" category, IMO. For example, OPES-Actions: "virus checker FooBar applied (result=clear, logid=34341, version=123)" > - server related persistent information, e.g. "OPES center of > authority ", "privacy policy ". It may be also > presented once per session and it does not change between > sessions. This has to be per-message unless you somehow can define sessions so that the end-user can distinguish them. For example, two pipelined HTTP request on the same TCP connection (from end-user point of view) may pass through very different OPES intermediaries and reach different content providers. How are you going to maintain sessions if not on a per-message basis (which makes session concept unnecessary)? Please give an example of a session in this context. > - end-point related data: what profile is activated (profile ID), > where to get profile details, where to set preferences. I'm not sure > how far we should go in this direction. OK. > I see other work going on in this area (e.g. > [draft-barbir-opes-spcs-03.txt]). I thing OPES should provide a > framework for such development by defining flexible and extensible > tracing and informational facilities. I agree, but I hope we can limit ourselves to per-message facilities only (no "sessions"). > 3. Some terminology. > > > Can we develop a few example scenarios that illustrate the various > > concepts of "information points", "reference points", "identifier", > > - REFERENCE POINT - a reference that may be used out-of-band to > perform a specific function. > > An example may be URI for the privacy policy, center of authority > URI, server address, etc. Usually no protocol is provided to access > the reference point. If reference point is a URI (and it probably should be), then the schema part of the URI (e.g., "http") usually determines ways to access the information. > - INFORMATION POINT - implies presence of the protocol to access > detailed information at this point. Example may be URI to get > a certificate for virus checker or content filter, examine > and set profile setting and active preferences. I see no difference with the "REFERENCE POINT". The protocol distinction is too vague. Can you give a reference point example that lacks protocol? Do we need to distinguish the two points? > - IDENTIFIER - provides a unique binding to detailed persistent > information. For example "transformation-applied : fe123" gives > a participant ability to enquire (and maybe cache) details of > the transformation fe123. Identifier can be an information point as well, right? I guess I am missing the motivation behind this terminology and these distinctions. > Use of such (opaque) identifiers > does not require prior knowledge and does not create a burden > of storing additional information - this is just a tag for > persistent information (not message-specific). The same is true for REFERENCE and INFORMATION POINTS, right? Why cannot an IDENTIFIER be message specific? For example, transformation-applied: http://service.org/explain?msgkind=foobar > 4. Using discretion of what points should be exposed. > > > If we don't identify the exact server, how would a service provider > > trace a problem I report to him? How would he know which server to > > check, if I tell him that something went wrong and check him to ask > > this? With email, for example, I know exactly which mail servers have > > been o the path, thus being able to trace down to the exact server. > > It is the choice of the service provider - what servers should be exposed. I agree. Same for HTTP's Via headers. I would also add "what servers should be exposed, if any". > For example currently if pictures coming from some site are distorted > or data is corrupted it is extremely difficult and often even impossible > to tell what front-end or back-end servers are malfunctioning, especially > in the presence of dynamically addressed CDN and multi-tier backend > application. Usually notification containing the main URL and request > parameters should be sufficient. > Mail server is also a good example: you may see only representative > of a server farm, some processing, like virus checking or spam > filtering may be performed by invisible back-end servers. Still servers > that are directly identified in the headers give resonable information > for problem analysis. Exactly. OPES should not be responsible for solving general finger-pointing problems on the Internet. > I'd recommend to minimise number of points exposed - in order to > hide application complexity and dynamic reconfiguration but provide > a separate logical places for information requiests and references. I would suggest that we leave this choice to the administrator. We should provide means to expose every OPES point. The administrator should be able to configure their intermediaries to expose just what they want/need. > In most cases OPES processor should hide underlying application > structure and care the burden of relayng some requests (both in-line > and out-of-band) to callout processors. This does not require > storage of additional data - at each moment OPES procesor knows all > underlying configuratiuon details and can determine what callout > processor should answer the request. If we only trace OPES processors and service IDs, then OPES processor should be responsible for adding tracing (it can use a trace-adding callout service but that should not be required). A good example is a text translation callout service. Such a service can be implemented in an application protocol-agnostic manner and, hence, will not be able to trace itself. OPES processor will always be able to add tracing information though. Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 2 14:43:40 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24871 for ; Wed, 2 Apr 2003 14:43:38 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JWKJM024573 for ; Wed, 2 Apr 2003 11:32:20 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32JWK4E024572 for ietf-openproxy-bks; Wed, 2 Apr 2003 11:32:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32JWIJM024567 for ; Wed, 2 Apr 2003 11:32:19 -0800 (PST) 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 h32JWDB23770 for ; Wed, 2 Apr 2003 14:32:14 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 14:32:14 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75405563022@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: ietf-openproxy@imc.org Subject: RE: Protocol next steps Date: Wed, 2 Apr 2003 14:32:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F94E.8EB6A9FA" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2F94E.8EB6A9FA Content-Type: text/plain hi, some basic terminology need to be addressed in the ocp doc. I think we should stick with OPES Processor and Callout Server. we can mention that they operate like a client/server, but the same terminology as in the arch doc should be followed. I am working my way into editing changes to the doc that will follow soon. abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, April 01, 2003 3:53 PM > To: ietf-openproxy@imc.org > Subject: Re: Protocol next steps > > > > Alex Rousskov wrote: > > > Given the above, I think we should publish as an individual > draft to > > give everybody enough time for a thorough review while allowing new > > revisions to be discussed and published. Those that do not have a > > problem with the draft becoming a WG document can treat it as such > > immediately. > > > > Submitting an individual draft should not hurt anything, should it? > > Skipping that step would be nice, but it is not a big deal. I will > > submit an individual draft in ~12 hours unless somebody stops me. > > Let's move on... > > Yup, please go ahead and publish as individual draft, we > don't want to > delay this. We'll keep moving the draft forward on this mailing list > with input from the entire WG, with the goal to submit the next > version of the draft as WG document. This way, we do *not* delay > making progress, we immediately have a valid reference point, and > folks still have some time to carefully look at the draft. > > However, please note: Possible concerns with the content of the > document must be brought up while we're working on the next version. > There will *not* be a separate review time or such like once the next > version is ready for submission (as WG document). Concerns should be > expressed while we're on the path to the next version. > > Thanks, > Markus > > ------_=_NextPart_001_01C2F94E.8EB6A9FA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Protocol next steps

hi,

some basic terminology need to be addressed in the = ocp doc.
I think we should stick with OPES Processor and = Callout Server.

we can mention that they operate like a = client/server, but the same terminology as in the arch doc should be = followed.

I am working my way into editing changes to the doc = that will follow soon.

abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, April 01, 2003 3:53 PM
> To: ietf-openproxy@imc.org
> Subject: Re: Protocol next steps
>
>
>
> Alex Rousskov wrote:
>
> > Given the above, I think we should publish = as an individual
> draft to
> > give everybody enough time for a thorough = review while allowing new
> > revisions to be discussed and published. = Those that do not have a
> > problem with the draft becoming a WG = document can treat it as such
> > immediately.
> >
> > Submitting an individual draft should not = hurt anything, should it?
> > Skipping that step would be nice, but it = is not a big deal. I will
> > submit an individual draft in ~12 hours = unless somebody stops me.
> > Let's move on...
>
> Yup, please go ahead and publish as individual = draft, we
> don't want to
> delay this. We'll keep moving the draft forward = on this mailing list
> with input from the entire WG, with the goal to = submit the next
> version of the draft as WG document. This way, = we do *not* delay
> making progress, we immediately have a valid = reference point, and
> folks still have some time to carefully look at = the draft.
>
> However, please note: Possible concerns with = the content of the
> document must be brought up while we're working = on the next version.
> There will *not* be a separate review time or = such like once the next
> version is ready for submission (as WG = document). Concerns should be
> expressed while we're on the path to the next = version.
>
> Thanks,
>    Markus
>
>

------_=_NextPart_001_01C2F94E.8EB6A9FA-- From owner-ietf-openproxy@mail.imc.org Wed Apr 2 16:04:36 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09132 for ; Wed, 2 Apr 2003 16:04:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KptJM001127 for ; Wed, 2 Apr 2003 12:51:55 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KptA0001126 for ietf-openproxy-bks; Wed, 2 Apr 2003 12:51:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32KprJM001122 for ; Wed, 2 Apr 2003 12:51:53 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h32Kpuvj002129; Wed, 2 Apr 2003 13:51:56 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h32KpunB002128; Wed, 2 Apr 2003 13:51:56 -0700 (MST) (envelope-from rousskov) Date: Wed, 2 Apr 2003 13:51:56 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Comments on ocp-00 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93019C5A63@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93019C5A63@zsc3c026.us.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: On Wed, 2 Apr 2003, Reinaldo Penno wrote: > 1) > > " application message: A sequence of octets that OPES processor > designates for callout service processing. Usually, an > application message is the basic unit of application protocol > communication, as defined by that application protocol (e.g., > HTTP/1.1 message). Before OCP is applied, OPES processor may > pre-process raw application messages to extract and manipulate > well-known parts (e.g., HTTP message headers or SMTP message body) > in order to subject just those parts to callout services. For the > purpose of OCP, the result of such preprocessing is an application > message. Naturally, OPES processor and callout services it is > configured to use must agree on what application messages are > acceptable. Establishing such an agreement is beyond OCP scope." > > > Everything after "Before OCP..." has nothing to do with the definition of > application message anymore. This has to do with the workings of the > protocol. Agreed. The second part is an explanation/motivation for the not-so-obvious definition. Do you think it is worth keeping, by moving it elsewhere? Or should we completely get rid of that prose? > Although I suggest to rip out the last part of this definition I > should say that I disagree (if I understood correctly) with your > statement "Establishing such an agreement is beyond OCP scope". > Capability negotiation can help you establish what application > messages are acceptable on each connection or callout server as a > whole. I agree that it can help. I hope we can keep things simple (no negotiation) in this context without loosing too much functionality or interoperability. I suspect that callout implementation abilities will be well known to those who add a callout server/service to an OPES intermediary. These administrators would be able to configure the system appropriately. IMO, there are two cases where auto-negotiation is important: - dynamic config changes: a new service is automatically added to the list of services available to an OPES processor; - dynamic ability changes: the same service suddenly can no longer handle complete HTTP messages and demands just HTTP message bodies in certain encoding. Both cases seem unusual and not worth supporting. Do you see other use cases for auto-negotiation? Or do you think the above two cases are worth supporting in OCP? > Suggested version. > > " application message: A sequence of octets that OPES processor > designates for callout service processing. Usually, an > application message is the basic unit of application protocol > communication, as defined by that application protocol (e.g., > HTTP/1.1 message). Agreed. Please let me know whether you think we should still keep the explanation/motivation part elsewhere in the specs. > 2) > > "A callout server may send this data back to > the OPES processor, with or without modifications." > > Suggestion > > "A callout server may send or not this data back to the OPES processor. When > the callout server sends data back to the OPES processor, it can be modified > or not." I think "may" implies "may not", but I will change to be explicit. > 3) > > "The primary purpose of OCP communications is modification of > application message payloads..." > > Do not want to seem picky, but the primary purpose of OCP is to ship packets > back and forth between Callout Server and OPES Processor. Whatever is done > with message has nothing to do with OCP anymore. It is a function totally > contained within the callout server. > > I guess you can say > > "The primary purpose of the OCP is to send data to the callout server where > it will be examined and possibly changed" OK. > 4) > > " OCP transaction is a logical sequence of OCP messages processing a > single original application message. The result of the processing may > be zero or more application messages, adapted from the original. A > typical transaction consists of two message flows: a flow from the > CLIENT to the SERVER (sending original application message) and a > flow from the SERVER to the CLIENT (sending adapted application > messages). The number of application messages produced by the SERVER > and whether the SERVER actually modifies original application message > depends on the requested callout service. The CLIENT or the SERVER > can terminate the transaction by sending a corresponding message to > the other side." > > Hummm...I guess I'm not confortable with the idea of mixing the OCP > semantics per se and whatever it carries..The problem with this approach is > that we will start asking things like "what is the original application > message?". "Is the the whole HTTP 1.1 message before TCP fragmentation or > after?" , "And if is protocol X..and Y", etc, etc. > > This is my (lean) suggestion using your definitions: > > " An OCP transaction is a logical exchange of OCP messages. > > A OCP transaction starts with a xaction-start message, followed > by zero or more data-xxx messages, zero or more appl-xxx and ends > with a xaction-end message. " Here I disagree. The whole purpose of having transactions is to group together processing of a single application message (which is a defined term). That grouping is not strictly necessary but it brings structure and is actually required by the OCP requirements draft (see the "3.3 Callout Transactions" section). If we adopt your wording, there is no need to have a notion of OCP transaction at all, right? Every app-message message from the callout server would simply have to have an extra ID pointing to the original application message it modifies (so that the OPES processor can put things back together and forward the message as appropriate). I agree that "original" qualifier should be removed, changed, or defined. As for "And if is protocol X..and Y", it is a valid question that we will need to address, but it does not seem to be related to the definition of an OCP transaction? > 5) > > "xid: OCP transaction identifier. Uniquely identifies an OCP > transaction originated by a given CLIENT. Since each transaction > deals with a single application message, "xid" also identifies > that application message." > > > As you can guess, IMHO the part ""xid" also identifies that application > message." is troublesome. > > My suggestion > > "xid: OCP transaction identifier. Uniquely identifies an OCP > transaction originated by a given CLIENT." OK. > 6) > > "am-id: Application message identifier. Uniquely identifies an > application message within an OCP transaction." > > I guess it is one more reason to make the modification I mention in number > 5) above. I am not sure I follow. Am-id exists so that a callout server can modify one [original] application message into more than one [adapted] application messages. Since there could be more than one adapted message, we need am-id to be able to interleave their data and to abort them. > 7) > > " am-source: Information about the source of an application message. > For example, HTTP client or origin server IP address and TCP > connection ID. > > am-destination: Information about the destination of an application > message. For example, HTTP client or origin server address." > > I'm not sure I follow this...TCP connection ID? Information about the source > of an application message? Callout server actions may depend on meta-information that is not available in the message itself. For example, a callout service may insert user-specific pieces of HTML but user authentication may happen outside of the current message scope and, hence, user ID would need to be relayed by OPES processor to the callout server (e.g., via the destination parameter). However, I consider current "am-source" and "am-destination" approach inadequate because meta-information can include more than source and destination descriptions. I will propose and argue for a more general replacement shortly. Let's ignore this broken part for now. > 8) > > "size: Application data size in octets. The value either applies to > the data attached to an OCP message or suggests data size to be > sent in response to an OCP message." > > Is this the original value (which I guess before reaseembly it cannot be > known)? The value of the OCP payload? If it is the size of the data attached to an OCP message, then it is OCP payload (e.g., "here are the next 100 bytes"). If it is a suggestion (e.g., "give me 100 more bytes"), then it is not OCP payload. See data-have and data-need messages. Note that "data" is a defined term. The "size" attribute has little to do with application message size. It is about the size of an application message chunk being sent or chunks being requested. The value of "size" would be equal to the transfer-length of the application message only if the entire application message is transmitted via one data-have OCP message. > 9) > > "modified: A boolean parameter indicating that the attached > application data has been modified by he SERVER. Only SERVER may > send this flag. This parameter can be used with any OCP message > that has am-id parameter." > > Suggestion > > "modified: A boolean parameter indicating that the attached > application data has been modified by the SERVER. Only the SERVER may > send this flag. This parameter can be used with any OCP message > that has am-id parameter." > > I guess the caveat is that if you but the flag in one OCP message > containing am-id, you have to put in all of them for the same am-id. Actually, not. The granularity may be one level lower. The SERVER tells the CLIENT that a particular message data _chunk_ got modified. This implies that the entire message got modified, but provides more information and does not require repeating the same flag in subsequent data-have messages. Of course, if the flag is used with, say, app-message-start message, then it applies to the entire application message without [yet] saying which chunk got modified. > 10) > > "copied: A flag indicating that a copy of the attached application > data is being kept at the CLIENT. Only the CLIENT may send this > flag. This parameter can be used with any OCP message that may > carry application message data. (XXX: it is yet unclear when > CLIENT commitment to preserve the data may end.)" > > Same caveat as above. Same answer as above. Here, the chunk-level granularity is even more important. See the long e-mail thread about copying commitment. Copying a data chunk is relatively easy and painless. Commitment to copy the entire application message is a very different animal. Perhaps the "data" definition must be modified to stress the level of granularity here? > 12) > > "error: A flag indicating abnormal conditions at the sender that > cannot be expressed via result parameter. " > > Such as? I guess maybe we could maintain the HTTP/SIP approach where > we have status code and reason phrases for everything. We could. Some argue that abnormal termination must be signaled more explicitly. See messages from Oskar Batuner related to the xaction-abort issue. > "It is RECOMMENDED that > the recipient deletes all state associated with the corresponding > OCP message. For example, if the message is 'app-message-end' and > the application message contained user credentials, such > credentials should be deleted." > > My suggestion > > ""It is RECOMMENDED that > the recipient deletes all state associated with the corresponding > OCP message." Do you mean deleting the example? Examples are not normative; do you think the presence of an example hurts in this case? > 13) > > "feature: A OCP feature identifier with optional feature parameters. > Used to declare support and negotiate use of OCP optional features > (e.g., copying of data chunks at the CLIENT)." > > I guess this is another one we need to iron out... Yes, definitely. > 14) > > "If a malformed message is received, the recipient MUST terminate > processing of the corresponding OCP connection using 'connection-end' > message with an error flag" > > Why not send a status code and reason phrase instead of this error flag? > > Just say "400 Bad Request"...or "400 Malformed Message" As Oskar argued, the semantics of "400 Malformed Message" may be different from "400 Malformed Message, and the error on this side was so bad that you probably want to delete all state associated with this transaction even if that state looks valid to you". We could have a special code for the latter, but we would need it for every error response; that is why Oskar proposed special *-abort messages and I suggested a special "error" flag. "Raw" HTTP ignores this problem because it does not document handling of message-independent state (e.g., authentication information). > 15) > > "This is the only OCP message that may carry application data. There > MUST NOT be any gaps in data supplied by data-have and data-as-is > messages (i.e., the offset of the next data message must be equal to > the offset+size of the previous data message) (XXX: we do not need > offset then; should we keep it as a validation mechanism?) (XXX: > document what to do when this MUST is violated). Zero size is > permitted and is useful for communicating predictions without sending > data." > > Well, although we must not have gaps, we might loose packets...we > need to be able to recover and not throw all the OCP messages > received so far away... I am under impression that section 3.1 of draft-ietf-opes-protocol-reqs-03.txt prohibits OCP packet loss. Are you talking about application protocol packet loss? If so, do you really want to inform the SERVER of lost data on OCP level? Or should we assume that if application protocol is lossy, the callout server would wither know how to detect/handle the losses or will not care? If possible, I would like data size and offset fields to represent received application message octets, nothing else (because it keeps things simple and application-agnostic). Thanks a lot for all your comments! Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 2 16:08:24 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09318 for ; Wed, 2 Apr 2003 16:08:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KwaJM001966 for ; Wed, 2 Apr 2003 12:58:36 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KwahZ001965 for ietf-openproxy-bks; Wed, 2 Apr 2003 12:58:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32KwYJM001958 for ; Wed, 2 Apr 2003 12:58:34 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h32Kwbvj002266; Wed, 2 Apr 2003 13:58:37 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h32Kwb4u002265; Wed, 2 Apr 2003 13:58:37 -0700 (MST) (envelope-from rousskov) Date: Wed, 2 Apr 2003 13:58:37 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Protocol next steps In-Reply-To: <87609AFB433BD5118D5E0002A52CD75405563022@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75405563022@zcard0k6.ca.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: On Wed, 2 Apr 2003, Abbie Barbir wrote: > some basic terminology need to be addressed in the ocp doc. > I think we should stick with OPES Processor and Callout Server. > > we can mention that they operate like a client/server, but the same > terminology as in the arch doc should be followed. I agree. There is a following XXX comment: XXX: we should replace CLIENT and SERVER placeholders in the text with their definitions once the CLIENT definition becomes stable I will apply the above macro substitution unless somebody thinks the current CLIENT or SERVER definition is wrong. > I am working my way into editing changes to the doc that will follow soon. Thank you. If possible, please see Reinaldo Penno comments and my responses. Also, please ignore anything related to meta-data handling such as "source" and "destination" message parameters. I will wait for your comments before applying Reinaldo changes. Alex. P.S. I have submitted the -00- draft last night. It must be in the editors queue somewhere. Whatever fixes we discuss now will go into the next version (01). From owner-ietf-openproxy@mail.imc.org Wed Apr 2 19:55:28 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19525 for ; Wed, 2 Apr 2003 19:55:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h330fKJM013506 for ; Wed, 2 Apr 2003 16:41:20 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h330fKDH013505 for ietf-openproxy-bks; Wed, 2 Apr 2003 16:41:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h330fIJM013497 for ; Wed, 2 Apr 2003 16:41:19 -0800 (PST) Received: from f02m-7-22.d1.club-internet.fr ([212.194.18.22] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 190sn1-00041W-00; Wed, 02 Apr 2003 16:41:11 -0800 Message-Id: <5.2.0.9.0.20030402230140.02996210@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 02 Apr 2003 23:14:46 +0200 To: "Abbie Barbir" From: jfcm Subject: RE: Protocol next steps Cc: ietf-openproxy@imc.org In-Reply-To: <87609AFB433BD5118D5E0002A52CD75405563022@zcard0k6.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_16589224==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=====================_16589224==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Abbie, My Franglish tells me that processing a service is to run the program which delivers the service. Not to remotly filter requests for that service (which may abort, not be delivered, be negociated) through dispatch rules. Also, that a server may only participate into providing a service. My understanding is therefore - but again it is based upon a non native understanding of the language - that an OPES processor is the called-out system of servers providing the service. Example: the Root Server System is the DNS root service processor called out by the ISP's resolver, after it acted as a dispatcher checking on its cached addresses. The DNS being a distributed OPES modifying the http/smtp flow adding an IP address where the user has only entered an URL. I would hardly say that the resolver is the DNS processor vs Name Servers. jfc On 21:32 02/04/03, Abbie Barbir said: >hi, >some basic terminology need to be addressed in the ocp doc. >I think we should stick with OPES Processor and Callout Server. > >we can mention that they operate like a client/server, but the same >terminology as in the arch doc should be followed. > >I am working my way into editing changes to the doc that will follow soon. > >abbie > > > -----Original Message----- > > From: Markus Hofmann [mailto:markus@mhof.com] > > Sent: Tuesday, April 01, 2003 3:53 PM > > To: ietf-openproxy@imc.org > > Subject: Re: Protocol next steps > > > > > > > > Alex Rousskov wrote: > > > > > Given the above, I think we should publish as an individual > > draft to > > > give everybody enough time for a thorough review while allowing new > > > revisions to be discussed and published. Those that do not have a > > > problem with the draft becoming a WG document can treat it as such > > > immediately. > > > > > > Submitting an individual draft should not hurt anything, should it? > > > Skipping that step would be nice, but it is not a big deal. I will > > > submit an individual draft in ~12 hours unless somebody stops me. > > > Let's move on... > > > > Yup, please go ahead and publish as individual draft, we > > don't want to > > delay this. We'll keep moving the draft forward on this mailing list > > with input from the entire WG, with the goal to submit the next > > version of the draft as WG document. This way, we do *not* delay > > making progress, we immediately have a valid reference point, and > > folks still have some time to carefully look at the draft. > > > > However, please note: Possible concerns with the content of the > > document must be brought up while we're working on the next version. > > There will *not* be a separate review time or such like once the next > > version is ready for submission (as WG document). Concerns should be > > expressed while we're on the path to the next version. > > > > Thanks, > > Markus > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03 --=====================_16589224==.ALT Content-Type: text/html; charset="us-ascii" Dear Abbie,
My Franglish tells me that processing a service is to run the program which delivers the service. Not to remotly filter requests for that service (which may abort, not be delivered, be negociated) through dispatch rules.

Also, that a server may only participate into providing a service. My understanding is therefore - but again it is based upon a non native understanding of the language - that an OPES processor is the called-out system of servers providing the service.

Example: the Root Server System is the DNS root service processor called out by the ISP's resolver, after it acted as a dispatcher checking on its cached addresses. The DNS being a distributed OPES modifying the http/smtp flow adding an IP address where the user has only entered an URL. I would hardly say that the resolver is the DNS processor vs Name Servers.

jfc


On 21:32 02/04/03, Abbie Barbir said:
hi,
some basic terminology need to be addressed in the ocp doc.
I think we should stick with OPES Processor and Callout Server.

we can mention that they operate like a client/server, but the same terminology as in the arch doc should be followed.

I am working my way into editing changes to the doc that will follow soon.

abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, April 01, 2003 3:53 PM
> To: ietf-openproxy@imc.org
> Subject: Re: Protocol next steps
>
>
>
> Alex Rousskov wrote:
>
> > Given the above, I think we should publish as an individual
> draft to
> > give everybody enough time for a thorough review while allowing new
> > revisions to be discussed and published. Those that do not have a
> > problem with the draft becoming a WG document can treat it as such
> > immediately.
> >
> > Submitting an individual draft should not hurt anything, should it?
> > Skipping that step would be nice, but it is not a big deal. I will
> > submit an individual draft in ~12 hours unless somebody stops me.
> > Let's move on...
>
> Yup, please go ahead and publish as individual draft, we
> don't want to
> delay this. We'll keep moving the draft forward on this mailing list
> with input from the entire WG, with the goal to submit the next
> version of the draft as WG document. This way, we do *not* delay
> making progress, we immediately have a valid reference point, and
> folks still have some time to carefully look at the draft.
>



> However, please note: Possible concerns with the content of the
> document must be brought up while we're working on the next version.
> There will *not* be a separate review time or such like once the next
> version is ready for submission (as WG document). Concerns should be
> expressed while we're on the path to the next version.
>
> Thanks,
>    Markus
>
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03
--=====================_16589224==.ALT-- From owner-ietf-openproxy@mail.imc.org Wed Apr 2 22:20:35 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22873 for ; Wed, 2 Apr 2003 22:20:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h333BqJM019730 for ; Wed, 2 Apr 2003 19:11:52 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h333BqsB019729 for ietf-openproxy-bks; Wed, 2 Apr 2003 19:11:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h333BmJM019724 for ; Wed, 2 Apr 2003 19:11:48 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2003040303114500200753g0e>; Thu, 3 Apr 2003 03:11:45 +0000 From: "Oskar Batuner" To: "Alex Rousskov" , "OPES Group" Subject: RE: Need to look at tracing and debuggig Date: Wed, 2 Apr 2003 22:11:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit See inline. > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Wednesday, April 02, 2003 1:11 PM > To: OPES Group > Subject: RE: Need to look at tracing and debuggig > > > > On Wed, 2 Apr 2003, Oskar Batuner wrote: > > > > 1. I could not find any reference to "debugging" in architecture > > > and OCP requirements drafts. Shouldn't we talk just about > > > tracing/reporting? I am not sure what exactly others mean by > > > debugging, but since it is not required, we do not have to > > > worry about it. Tracing helps with debugging, of course, > > > but let's concentrate on immediate goals. Please correct me > > > if I missed debugging requirements. > > > > > > 2. It is very important to keep in mind that tracing is limited > > > to the trust domain. Anybody outside of that domain may or may not > > > see any traces, depending on domain policies/configuration. In > > > other words, we are not talking about mandatory end-to-end tracing > > > facility here. For example, if an OPES system is on the content > > > provider "side", end-users are not guaranteed any traces. If an > > > OPES system is working inside end-user domain, the origin server is > > > not guaranteed any traces related to user requests. > > > > I'm afraid the situation is more complicated. While ability to > > control tracing facility and level of details available inside and > > outside of the trust domain may be different there are some > > requirements (e.g. privacy) that are not limited to the trust > > domain. Both IAB requirements and the architecture mandate some > > end-to-end disclosures. > > Let's be more specific. I did not find any IAB considerations that > mandate automated end-to-end disclosures. There is some discussion > that content providers may benefit from knowing client-side OPES > actions, but the only consideration is that "The overall OPES > framework needs to assist content providers in detecting and > responding to client-centric actions by OPES intermediaries". This > consideration is too vague; it can be satisfied by, for example, > asking the user to manually supply OPES-specific headers to the > content provider if the provider suspects inappropriate OPES behavior > by observing HTTP Via headers or equivalent. > > As IAB notes, implementing this assistance goes against implementors > objectives (client-side OPES system does not care about server-side > desires). Thus, it would be a waste of time in implementing any > sophisticated/detailed (hence expensive) notification facility that > spans trust domains. Moreover, requiring such facility on a MUST level > clearly violates client-side privacy considerations. > > I agree that we should require (at a SHOULD level) some minimal form > of cross-trust-domain tracing similar to current HTTP Via headers, but > I would not go far beyond that. Yes, for cross-domain I was looking at Via-type notification. I think final protocol binding should define vendor-independent format suitable for automated analysis. As for MUST/SHOULD - I was always trying to prevent mandatory disclosure of information outside of trust domain boundaries. Sometimes disclosure of filter information may create a security threats facilitating attacks on knows vulnerabilities and attempts to bypass protection. But for some optional services well defined notification and control mechanism may help to adjust services to the requirements of participants even beyond trust domain, so I would not consider such mechanism a complete waist of time. > > > > Markus asked for tracing use cases. If we start collecting those, I > > > would suggest to clearly document "end" and "admin" role in each > > > use case. > > > > There are more participants interested in tracing information. > > Independent OPES processors in the same OPES flow might want to know > > about each other existence and might need to cooperate. For example > > virus checker may be satisfied by the signature of another virus > > checker, ad insertion/localization servers may avoid stepping on > > each other toes, etc. > > Sure. > > > In fact you are describing two roles. We should use this approach - > > roles, not topology based description - end vs. intermediate. > > I have no problems with that. Both approaches may co-exist actually. > > > > 4. (This is a consequence of #2 and #3 above) We should not expect > > > entities in one trust domain to be able to get any OPES-related > > > feedback from entities in other trust domains. For example, if I am > > > an end-user, and I think that the page I am getting is corrupted by > > > a callout service, I should not expect to be able to identify > > > that service, contact its owner, or debug it _unless_ the > > > service is within my trust domain. This is no different from > > > the current situation where it is impossible, in general, to know > > > the contact person for an application on an origin server that > > > generates broken HTML; and even if the person is known, one should > > > not expect that person to respond to end-user queries (in general). > > > > Yes, but... For example you expect to be able to access content > > provider's privacy policy and security credentials. Same is true for > > OPES processors. Again, the amount of information and level of > > control may be different but still some information should be > > provided. > > Provider != OPES intermediary. > > The mechanism for end users to determine the privacy policy of a > server-centric intermediary is to visit the corresponding web page on > provider's web site. For end users, there can be no clear distinction > between server-side OPES intermediary and the "server-side" as a > whole. For starters, a particular server-side [OPES] intermediary may > not be directly addressable by the end-user. IAB RFC clearly states > that only the first intermediary in the chain must be addressable. > That first intermediary may be a L7 load balancer, for example. L7 > load balancers do not have a privacy policy. As it was stated in IAB RFC additional entities introduce additional risks. Your approach is absolutely valid if server-centric OPES servers are deployed as a part of data provider application and are completely under his control. Situation becomes more complicated if OPES service is provided by a third party - with the content provider consent. In this situation OPES server may have a privacy policy different from the content provider's one and it should be accessible separately. OPES framework should provide appropriate mechanisms and rules of deployment. Sure there is no need to expose a separate privacy policy for each server in a server farm, but there should be a clear rule that describes how privacy policy is propagated and that ensures that any OPES entity is covered by one of declared policies. As for a L7 load balancer: if this balancer represents an OPES PEP (controls a group of callout servers) it should obey all OPES rules, including privacy notification. > > > There are certain things that should be provided as references, e.g. > > privacy policy. Extending combined approach with some persistent > > information replaced by references give much greater flexibility and > > makes application protocol more efficient. > > Sure. I have no problems with allowing additional information to be > provided via references. We can discuss whether it would make sense to > require any specific references. > > > > 5. There is a question on whether OPES processor (OCP client) or > > > callout server (OCP server) must be responsible for adding trace > > > records to application messages. I am not 100% sure, but I would > > > suggest that we try to assign this task OPES processor exclusively. > > > > Yes, can not agree more! See my previous post. > > > > > > > > 6. #5 suggestion implies that tracing is out of OCP scope! :-) > > > > I'm afraid - not. For example OPES processor should be able to get > > information about callout server privacy policy > > Why should it? > > The architecture draft says "Protocol(s) for policy/rule distribution > are out of scope for this document, but the OPES architecture assumes > the existence of such a mechanism". You do not really expect OPES > processors to care about every callout server privacy policy, do you? > Content providers have privacy policies. Server-side callout servers > do not have to (because they are operating under the content provider > policy). 1. Yes, I do care about callout server privacy policy. The fact that a specific server obeys a policy declared by the OPES processor completely satisfies my concerns, but this fact should be stated and verified by the OPES processor. 2. Privacy policy is just an example. Tracing information may cover other functional aspects, for example content filtering abilities and policies, types of ads injected, personalization effects, etc. OCP should provide a generic mechanism that can be used to satisfy a wide variety of application specific needs. 3. Absence of tracing and adaptation support from OCP makes it incomplete - tracing directives go out-of-band and results are not verifiable. This may defeat one of the main reasons for creating a standard for such protocol - to permit creation of plug-and-play (the word "appliance" is more in fashion today) application servers that can interoperate with any caller understanding the protocol. 4. Server-side (content provider side) may have a different meaning. It may mean an integral part of content provider application - in which case your model is correct - but it may also mean a third-party service operating with consent of service provider, the case that was causing most concerns in discussions about privacy and information distortion. 5. If we adopt a model were OPES server represents all applications that it controls - and looks like we are looking favorably at such model - this OPES server should be able to control all relevant aspects of callout servers' behavior, including tracing information insertion. OCP is very natural place for this extended control mechanism. It already controls most aspects of OPES server - callout server interaction, deploying additional/different mechanism may result in multiple complications (out-of-band control of per-message information). > > > and might want to control insertion of tracing information into > > application messages. This has to be supported by the OCP :-( > > Depends on what tracing information we want to support. For example, > if we want OPES processor to insert service identifier into an > application message, the processor can do it without OCP-level > support. > > > > 7. How tracing is added is application protocol-specific and may be > > > documented in separate RFCs/drafts. We can only document what tracing > > > information is required and, perhaps, some common tracing elements. > > > > We can delay specification details while we are describing high level > > architecture. But the ultimate goal is an implementable specification, > > and to support application interoperation we have to specify all essential > > formats and protocols. This may span multiple RFCs/draft but the final > > result should be the same - implementable specification with guaranteed > > interoperability. > > Yes, of course. > > Thanks, > > Alex. > Oskar From owner-ietf-openproxy@mail.imc.org Thu Apr 3 01:07:04 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25652 for ; Thu, 3 Apr 2003 01:07:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h335WkJM025245 for ; Wed, 2 Apr 2003 21:32:46 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h335WkKo025244 for ietf-openproxy-bks; Wed, 2 Apr 2003 21:32:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h335WjJM025239 for ; Wed, 2 Apr 2003 21:32:45 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h335Wnvj014835; Wed, 2 Apr 2003 22:32:49 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h335Wntn014834; Wed, 2 Apr 2003 22:32:49 -0700 (MST) (envelope-from rousskov) Date: Wed, 2 Apr 2003 22:32:49 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Need to look at tracing and debuggig In-Reply-To: Message-ID: References: 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: Oskar, It looks like our disagreements are not as deep as I originally thought. I agree with most of your latest comments. Indeed, we should be careful about distinguishing a content provider system and a 3rd party system operating under content provider permission. I was pushing for treating any system as a single entity once the message leaves that system. You are saying that there are at least three kinds of systems: content providers, end users with their proxies, and 3rd party services like CDNs. I agree, as long as we can treat a 3rd party service as a single entity once the message leaves that service. How about starting with the following simple set of unpolished rules: 1. An OPES processor SHOULD add its identification to the trace. 2. An OPES processor SHOULD add to the trace identification of every callout service that received the application message. 3. An OPES processor MUST add to the trace identification of the "system/entity" it belongs to. "System" ID MUST make it possible to access "system" privacy policy. 4. An OPES processor MAY group the above information (items 1-3) for sequential trace entries having the same "system/entity" ID. In other words, trace entries produced within the same "system/entity" MAY be merged/aggregated into a single less detailed trace entry. 5. An OPES processor MAY delegate trace management to a callout service within the same "system/entity". We need to agree on what an "identifier" in items 1-3 represents and how trace entries are encoded (the latter is application-specific). Overall, do the above 5 items sound reasonable at all? Are there any huge gaps they do not cover? (I think I know of one hole, but would prefer to hear others' comments before diving any deeper) Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 3 08:22:15 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18957 for ; Thu, 3 Apr 2003 08:22:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33DB4JM012414 for ; Thu, 3 Apr 2003 05:11:04 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33DB4hO012413 for ietf-openproxy-bks; Thu, 3 Apr 2003 05:11:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.det3.ameritech.net (mailhost2-sfldmi.sfldmi.ameritech.net [206.141.193.106]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33DB1JM012404 for ; Thu, 3 Apr 2003 05:11:02 -0800 (PST) Received: from wayne.edu ([67.38.26.254]) by mailhost.det3.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with ESMTP id <20030403131102.WLKG176.mailhost.det3.ameritech.net@wayne.edu>; Thu, 3 Apr 2003 08:11:02 -0500 Message-ID: <3E8C32DF.1050400@wayne.edu> Date: Thu, 03 Apr 2003 08:10:55 -0500 From: Weisong Shi Reply-To: weisong@wayne.edu Organization: Wayne State University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES Group Subject: Re: Need to look at tracing and debuggig References: 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: Content-Transfer-Encoding: 7bit Given theses traces, is it possible for clients or content providers to verify the correctness of them? For example, if an OPES processor reduces the resolution of an image, but he record something else. How can you verify this? -Weisong Alex Rousskov wrote: > Oskar, > > It looks like our disagreements are not as deep as I > originally thought. I agree with most of your latest comments. > > Indeed, we should be careful about distinguishing a content > provider system and a 3rd party system operating under content > provider permission. I was pushing for treating any system as a single > entity once the message leaves that system. You are saying that there > are at least three kinds of systems: content providers, end users with > their proxies, and 3rd party services like CDNs. I agree, as long as > we can treat a 3rd party service as a single entity once the message > leaves that service. > > How about starting with the following simple set of > unpolished rules: > > 1. An OPES processor SHOULD add its identification > to the trace. > > 2. An OPES processor SHOULD add to the trace > identification of every callout service that received > the application message. > > 3. An OPES processor MUST add to the trace identification > of the "system/entity" it belongs to. "System" > ID MUST make it possible to access "system" privacy > policy. > > 4. An OPES processor MAY group the above information > (items 1-3) for sequential trace entries having > the same "system/entity" ID. In other words, trace > entries produced within the same "system/entity" > MAY be merged/aggregated into a single less detailed > trace entry. > > 5. An OPES processor MAY delegate trace management to > a callout service within the same "system/entity". > > We need to agree on what an "identifier" in items 1-3 represents and > how trace entries are encoded (the latter is application-specific). > > Overall, do the above 5 items sound reasonable at all? Are there any > huge gaps they do not cover? (I think I know of one hole, but would > prefer to hear others' comments before diving any deeper) > > Thank you, > > Alex. > From owner-ietf-openproxy@mail.imc.org Thu Apr 3 08:26:45 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19202 for ; Thu, 3 Apr 2003 08:26:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33DGBJM013100 for ; Thu, 3 Apr 2003 05:16:11 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33DGBEc013099 for ietf-openproxy-bks; Thu, 3 Apr 2003 05:16:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.det3.ameritech.net (mailhost2-sfldmi.sfldmi.ameritech.net [206.141.193.106]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33DG8JM013094 for ; Thu, 3 Apr 2003 05:16:09 -0800 (PST) Received: from wayne.edu ([67.38.26.254]) by mailhost.det3.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with ESMTP id <20030403131609.WMUJ176.mailhost.det3.ameritech.net@wayne.edu> for ; Thu, 3 Apr 2003 08:16:09 -0500 Message-ID: <3E8C3414.5050309@wayne.edu> Date: Thu, 03 Apr 2003 08:16:04 -0500 From: Weisong Shi Reply-To: weisong@wayne.edu Organization: Wayne State University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: usage of Squid Web cache on the Internet References: 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: Content-Transfer-Encoding: 7bit Hello, Does anyone know the number of squid web caches deployed on the Internet? and how about its percentage among all Web caches? Thanks. Weisong Shi Department of Computer Science Wayne State University From owner-ietf-openproxy@mail.imc.org Thu Apr 3 08:57:24 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19991 for ; Thu, 3 Apr 2003 08:57:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33DkRJM014899 for ; Thu, 3 Apr 2003 05:46:27 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33DkQww014897 for ietf-openproxy-bks; Thu, 3 Apr 2003 05:46:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33DkPJM014891 for ; Thu, 3 Apr 2003 05:46:25 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h33DkQvj027150; Thu, 3 Apr 2003 06:46:26 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h33DkQQ1027149; Thu, 3 Apr 2003 06:46:26 -0700 (MST) (envelope-from rousskov) Date: Thu, 3 Apr 2003 06:46:26 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Need to look at tracing and debuggig In-Reply-To: <3E8C32DF.1050400@wayne.edu> Message-ID: References: <3E8C32DF.1050400@wayne.edu> 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: On Thu, 3 Apr 2003, Weisong Shi wrote: > Given theses traces, is it possible for clients or content providers > to verify the correctness of them? For example, if an OPES processor > reduces the resolution of an image, but he record something else. > How can you verify this? You cannot automatically detect all inconsistencies, of course. It is impossible to guarantee that a program does not lie or to auto-detect every possible lie. What we can and should do is: - assist the user or content provider in contacting administrators of broken OPES systems once the user or content provider suspect a problem (i.e., OPES trace can help in locating the broken intermediary) - support bypass of OPES intermediaries when possible (i.e., you may be able to get a raw, unprocessed image if you suspect that processing is corrupted _and_ if the system does not require processing) - optionally, we can ask for digital signatures for trace entries so that you have better protection from the trace itself lying to you (but most intermediaries will not pay $$$ for key certificates so this will work just for a few big companies handling most(?) of the traffic) Please note that OPES does not introduce new problem categories (what you describe can happen today if, say, a CDN gets hacked), but it may help solving some of the existing ones, at least partially. Alex. > Alex Rousskov wrote: > > Oskar, > > > > It looks like our disagreements are not as deep as I > > originally thought. I agree with most of your latest comments. > > > > Indeed, we should be careful about distinguishing a content > > provider system and a 3rd party system operating under content > > provider permission. I was pushing for treating any system as a single > > entity once the message leaves that system. You are saying that there > > are at least three kinds of systems: content providers, end users with > > their proxies, and 3rd party services like CDNs. I agree, as long as > > we can treat a 3rd party service as a single entity once the message > > leaves that service. > > > > How about starting with the following simple set of > > unpolished rules: > > > > 1. An OPES processor SHOULD add its identification > > to the trace. > > > > 2. An OPES processor SHOULD add to the trace > > identification of every callout service that received > > the application message. > > > > 3. An OPES processor MUST add to the trace identification > > of the "system/entity" it belongs to. "System" > > ID MUST make it possible to access "system" privacy > > policy. > > > > 4. An OPES processor MAY group the above information > > (items 1-3) for sequential trace entries having > > the same "system/entity" ID. In other words, trace > > entries produced within the same "system/entity" > > MAY be merged/aggregated into a single less detailed > > trace entry. > > > > 5. An OPES processor MAY delegate trace management to > > a callout service within the same "system/entity". > > > > We need to agree on what an "identifier" in items 1-3 represents and > > how trace entries are encoded (the latter is application-specific). > > > > Overall, do the above 5 items sound reasonable at all? Are there any > > huge gaps they do not cover? (I think I know of one hole, but would > > prefer to hear others' comments before diving any deeper) > > > > Thank you, > > > > Alex. > > > > From owner-ietf-openproxy@mail.imc.org Thu Apr 3 10:14:21 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23985 for ; Thu, 3 Apr 2003 10:14:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33EvhJM018372 for ; Thu, 3 Apr 2003 06:57:43 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33EvhDm018371 for ietf-openproxy-bks; Thu, 3 Apr 2003 06:57:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33EvfJM018366 for ; Thu, 3 Apr 2003 06:57:41 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33Dm6T08349; Thu, 3 Apr 2003 05:48:06 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGB4CL9>; Thu, 3 Apr 2003 05:47:37 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E70@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , OPES Group Subject: RE: Comments on ocp-00 Date: Thu, 3 Apr 2003 05:47:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F9E7.925A4028" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2F9E7.925A4028 Content-Type: text/plain Hello Alex, I read your comments...answers inline... > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, April 02, 2003 3:52 PM > To: OPES Group > Subject: Re: Comments on ocp-00 > > > On Wed, 2 Apr 2003, Reinaldo Penno wrote: > > > 1) > > > > " application message: A sequence of octets that OPES processor > > designates for callout service processing. Usually, an > > application message is the basic unit of application protocol > > communication, as defined by that application protocol (e.g., > > HTTP/1.1 message). Before OCP is applied, OPES processor may > > pre-process raw application messages to extract and manipulate > > well-known parts (e.g., HTTP message headers or SMTP > message body) > > in order to subject just those parts to callout > services. For the > > purpose of OCP, the result of such preprocessing is > an application > > message. Naturally, OPES processor and callout services it is > > configured to use must agree on what application messages are > > acceptable. Establishing such an agreement is beyond > OCP scope." > > > > > > Everything after "Before OCP..." has nothing to do with the > definition > > of application message anymore. This has to do with the workings of > > the protocol. > > Agreed. The second part is an explanation/motivation for the > not-so-obvious definition. Do you think it is worth keeping, > by moving it elsewhere? Or should we completely get rid of that prose? > > > Although I suggest to rip out the last part of this definition I > > should say that I disagree (if I understood correctly) with your > > statement "Establishing such an agreement is beyond OCP scope". > > Capability negotiation can help you establish what application > > messages are acceptable on each connection or callout server as a > > whole. > > I agree that it can help. I hope we can keep things simple (no > negotiation) in this context without loosing too much > functionality or interoperability. I suspect that callout > implementation abilities will be well known to those who add > a callout server/service to an OPES intermediary. These > administrators would be able to configure the system appropriately. Humm...I'm really not sure about that. I guess the sysadmin can learn it, but it would be much easier and debug friendly (if something goes wrong) to have capability negotiations. Not to mention that as OPES services become more "rich" a lot of new capabilities will appear. > > IMO, there are two cases where auto-negotiation is important: > > - dynamic config changes: a new service is automatically > added to the list of services available to an OPES > processor; > > - dynamic ability changes: the same service suddenly can no > longer handle complete HTTP messages and demands just > HTTP message bodies in certain encoding. > > Both cases seem unusual and not worth supporting. Do you see > other use cases for auto-negotiation? Or do you think the > above two cases are worth supporting in OCP? See above. I think that relying alone in CLI configuration is not the way to go. IMHO if you look at routing protocols, PPP, and text protocols like SIP and HTTP there is some form of capability negotiation. SOAP also has some form of capability negotiation. > > > Suggested version. > > > > " application message: A sequence of octets that OPES processor > > designates for callout service processing. Usually, an > > application message is the basic unit of application protocol > > communication, as defined by that application protocol (e.g., > > HTTP/1.1 message). > > Agreed. Please let me know whether you think we should still > keep the explanation/motivation part elsewhere in the specs. Yes, we should...in the protocol working section. > > > 2) > > > > "A callout server may send this data back to > > the OPES processor, with or without modifications." > > > > Suggestion > > > > "A callout server may send or not this data back to the OPES > > processor. When the callout server sends data back to the OPES > > processor, it can be modified or not." > > I think "may" implies "may not", but I will change to be explicit. > > > 3) > > > > "The primary purpose of OCP communications is modification of > > application message payloads..." > > > > Do not want to seem picky, but the primary purpose of OCP > is to ship > > packets back and forth between Callout Server and OPES Processor. > > Whatever is done with message has nothing to do with OCP > anymore. It > > is a function totally contained within the callout server. > > > > I guess you can say > > > > "The primary purpose of the OCP is to send data to the > callout server > > where it will be examined and possibly changed" > > OK. > > > 4) > > > > " OCP transaction is a logical sequence of OCP messages > processing a > > single original application message. The result of the > processing may > > be zero or more application messages, adapted from the > original. A > > typical transaction consists of two message flows: a > flow from the > > CLIENT to the SERVER (sending original application message) and a > > flow from the SERVER to the CLIENT (sending adapted application > > messages). The number of application messages produced > by the SERVER > > and whether the SERVER actually modifies original > application message > > depends on the requested callout service. The CLIENT or > the SERVER > > can terminate the transaction by sending a corresponding > message to > > the other side." > > > > Hummm...I guess I'm not confortable with the idea of mixing the OCP > > semantics per se and whatever it carries..The problem with this > > approach is that we will start asking things like "what is the > > original application message?". "Is the the whole HTTP 1.1 message > > before TCP fragmentation or after?" , "And if is protocol > X..and Y", > > etc, etc. > > > > This is my (lean) suggestion using your definitions: > > > > " An OCP transaction is a logical exchange of OCP messages. > > > > A OCP transaction starts with a xaction-start message, followed > > by zero or more data-xxx messages, zero or more appl-xxx and ends > > with a xaction-end message. " > > Here I disagree. The whole purpose of having transactions is > to group together processing of a single application message > (which is a defined term). That grouping is not strictly > necessary but it brings structure and is actually required by > the OCP requirements draft (see the "3.3 Callout > Transactions" section). I guess this is more of a performance/device intelligence discussion. My first point is that having to send xaction-start/stop for every single application message is quite an overhead. Actually this might be the biggest overhead I've ever seen. If a HTTP message fits into a TCP packet we will have to process 2 extra packets for every single "real" (for the lack of a better word) packet. The other point I would like to make is that having to determine start/end of application messages means that the OPES processor will need to understand all these applications, which is not necessarily desirable. Let's suppose I have a callout server that deals with content filtering. The OPES processor gets TCP packets with HTTP in it (fragmented or not) and ships them to the Callout server, which will reconstruct the HTTP message if needed and send it back to the OPES processor. The OPES processor then decapsulates the IP/TCP/HTTP from OCP and sends it on its way. The same example would apply for RTP where I just want to send packets to the callout server for content adaption. I would not like to have to implement a RTP/MPEG-1 decoder in my OPES processor to know where application messages end/start. Finally, let's suppose the first packet of a video session was lost and I can recognize that. Since there is no retransmissions, what should I do since I can only send whole application messages to the Callout server? I will never see that first packet again. In the case of HTTP I would need to wait for a retransmission before I can send anything to the callout server. And who can guarantee me that I will ever receive everything? > > If we adopt your wording, there is no need to have a notion > of OCP transaction at all, right? Every app-message message > from the callout server would simply have to have an extra ID > pointing to the original application message it modifies (so > that the OPES processor can put things back together and > forward the message as appropriate). See above. > > I agree that "original" qualifier should be removed, changed, > or defined. > > As for "And if is protocol X..and Y", it is a valid question > that we will need to address, but it does not seem to be > related to the definition of an OCP transaction? > > > 5) > > > > "xid: OCP transaction identifier. Uniquely identifies an OCP > > transaction originated by a given CLIENT. Since each > transaction > > deals with a single application message, "xid" also identifies > > that application message." > > > > > > As you can guess, IMHO the part ""xid" also identifies that > > application message." is troublesome. > > > > My suggestion > > > > "xid: OCP transaction identifier. Uniquely identifies an OCP > > transaction originated by a given CLIENT." > > OK. > > > 6) > > > > "am-id: Application message identifier. Uniquely identifies an > > application message within an OCP transaction." > > > > I guess it is one more reason to make the modification I mention in > > number > > 5) above. > > I am not sure I follow. Am-id exists so that a callout server > can modify one [original] application message into more than > one [adapted] application messages. Since there could be more > than one adapted message, we need am-id to be able to > interleave their data and to abort them. I understand your point. We can still have am-id if the OPES processor wants to do something with the message after it receives it from the Callout server. Again, see above. > > > 7) > > > > " am-source: Information about the source of an > application message. > > For example, HTTP client or origin server IP address and TCP > > connection ID. > > > > am-destination: Information about the destination of an > application > > message. For example, HTTP client or origin server address." > > > > I'm not sure I follow this...TCP connection ID? Information > about the > > source of an application message? > > Callout server actions may depend on meta-information that is > not available in the message itself. For example, a callout > service may insert user-specific pieces of HTML but user > authentication may happen outside of the current message > scope and, hence, user ID would need to be relayed by OPES > processor to the callout server (e.g., via the destination parameter). > > However, I consider current "am-source" and "am-destination" > approach inadequate because meta-information can include more > than source and destination descriptions. I will propose and > argue for a more general replacement shortly. Let's ignore > this broken part for now. > > > 8) > > > > "size: Application data size in octets. The value either applies to > > the data attached to an OCP message or suggests data > size to be > > sent in response to an OCP message." > > > > Is this the original value (which I guess before reaseembly > it cannot > > be known)? The value of the OCP payload? > > If it is the size of the data attached to an OCP message, > then it is OCP payload (e.g., "here are the next 100 bytes"). > If it is a suggestion (e.g., "give me 100 more bytes"), then > it is not OCP payload. See data-have and data-need messages. > Note that "data" is a defined term. > > The "size" attribute has little to do with application > message size. It is about the size of an application message > chunk being sent or chunks being requested. The value of > "size" would be equal to the transfer-length of the > application message only if the entire application message is > transmitted via one data-have OCP message. Okay, I guess this very answer that you gave me could go into the draft. > > > 9) > > > > "modified: A boolean parameter indicating that the attached > > application data has been modified by he SERVER. > Only SERVER may > > send this flag. This parameter can be used with any > OCP message > > that has am-id parameter." > > > > Suggestion > > > > "modified: A boolean parameter indicating that the attached > > application data has been modified by the SERVER. > Only the SERVER may > > send this flag. This parameter can be used with any > OCP message > > that has am-id parameter." > > > > I guess the caveat is that if you but the flag in one OCP message > > containing am-id, you have to put in all of them for the same am-id. > > Actually, not. The granularity may be one level lower. The > SERVER tells the CLIENT that a particular message data > _chunk_ got modified. This implies that the entire message > got modified, but provides more information and does not > require repeating the same flag in subsequent data-have messages. > > Of course, if the flag is used with, say, app-message-start > message, then it applies to the entire application message > without [yet] saying which chunk got modified. I'm still working on the frequency that you can haver more than one application message into one transaction. > > > 10) > > > > "copied: A flag indicating that a copy of the attached application > > data is being kept at the CLIENT. Only the CLIENT may > send this > > flag. This parameter can be used with any OCP message that may > > carry application message data. (XXX: it is yet unclear when > > CLIENT commitment to preserve the data may end.)" > > > > Same caveat as above. > > Same answer as above. Here, the chunk-level granularity is > even more important. See the long e-mail thread about copying > commitment. Copying a data chunk is relatively easy and > painless. Commitment to copy the entire application message > is a very different animal. > > Perhaps the "data" definition must be modified to stress the > level of granularity here? Yep. > > > 12) > > > > "error: A flag indicating abnormal conditions at the sender that > > cannot be expressed via result parameter. " > > > > Such as? I guess maybe we could maintain the HTTP/SIP > approach where > > we have status code and reason phrases for everything. > > We could. Some argue that abnormal termination must be > signaled more explicitly. See messages from Oskar Batuner > related to the xaction-abort issue. > > > "It is RECOMMENDED that > > the recipient deletes all state associated with the > corresponding > > OCP message. For example, if the message is > 'app-message-end' and > > the application message contained user credentials, such > > credentials should be deleted." > > > > My suggestion > > > > ""It is RECOMMENDED that > > the recipient deletes all state associated with the > corresponding > > OCP message." > > Do you mean deleting the example? Examples are not normative; > do you think the presence of an example hurts in this case? No. I guess examples should go on sections of their own. > > > 13) > > > > "feature: A OCP feature identifier with optional feature parameters. > > Used to declare support and negotiate use of OCP > optional features > > (e.g., copying of data chunks at the CLIENT)." > > > > I guess this is another one we need to iron out... > > Yes, definitely. > > > 14) > > > > "If a malformed message is received, the recipient MUST terminate > > processing of the corresponding OCP connection using > 'connection-end' > > message with an error flag" > > > > Why not send a status code and reason phrase instead of this error > > flag? > > > > Just say "400 Bad Request"...or "400 Malformed Message" > > As Oskar argued, the semantics of "400 Malformed Message" may > be different from "400 Malformed Message, and the error on > this side was so bad that you probably want to delete all > state associated with this transaction even if that state > looks valid to you". We could have a special code for the > latter, but we would need it for every error response; that > is why Oskar proposed special *-abort messages and I > suggested a special "error" flag. > I'm not going to argue too much about this. I will just say that other text/binary based protocols have been working in a while without the need for a error flag. This is an infinite cycle. Say, how about it is a really nasty error, worst than "so bad"? Should we have a flag for that? If it is bad (that is worst than 400), but not worst than "so bad"? You know where I'm getting at? We just need to have a different message (if needed) and document the recommended behaviour. For example..."if you receive a messge with a error code of 40X you should delete all state associated with this transacation" > "Raw" HTTP ignores this problem because it does not document > handling of message-independent state (e.g., authentication > information). As I said, will not argue too much about this. IMHO I do not feel this is really a good design. > > > 15) > > > > "This is the only OCP message that may carry application data. There > > MUST NOT be any gaps in data supplied by data-have and data-as-is > > messages (i.e., the offset of the next data message must > be equal to > > the offset+size of the previous data message) (XXX: we > do not need > > offset then; should we keep it as a validation mechanism?) (XXX: > > document what to do when this MUST is violated). Zero size is > > permitted and is useful for communicating predictions > without sending > > data." > > > > Well, although we must not have gaps, we might loose > packets...we need > > to be able to recover and not throw all the OCP messages > received so > > far away... > > I am under impression that section 3.1 of > draft-ietf-opes-protocol-reqs-03.txt prohibits OCP packet > loss. Are you talking about application protocol packet loss? > If so, do you really want to inform the SERVER of lost data > on OCP level? Or should we assume that if application > protocol is lossy, the callout server would wither know how > to detect/handle the losses or will not care? If possible, I > would like data size and offset fields to represent received > application message octets, nothing else (because it keeps > things simple and application-agnostic). I guess this goes back to examples I gave previously. [ ], Reinaldo > > > Thanks a lot for all your comments! > > Alex. > ------_=_NextPart_001_01C2F9E7.925A4028 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on ocp-00

Hello Alex,

I read your comments...answers inline...

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Wednesday, April 02, 2003 3:52 PM
> To: OPES Group
> Subject: Re: Comments on ocp-00
>
>
> On Wed, 2 Apr 2003, Reinaldo Penno = wrote:
>
> > 1)
> >
> > " application message: A sequence of = octets that OPES processor
> >       = designates for callout service processing.  Usually, an
> >       = application message is the basic unit of application protocol
> >       = communication, as defined by that application protocol (e.g.,
> >       = HTTP/1.1 message).  Before OCP is applied, OPES processor = may
> >       = pre-process raw application messages to extract and manipulate
> >       = well-known parts (e.g., HTTP message headers or SMTP
> message body)
> >       in = order to subject just those parts to callout
> services. For the
> >       = purpose of OCP, the result of such preprocessing is
> an application
> >       = message. Naturally, OPES processor and callout services it is
> >       = configured to use must agree on what application messages are
> >       = acceptable. Establishing such an agreement is beyond
> OCP scope."
> >
> >
> > Everything after "Before OCP..." = has nothing to do with the
> definition
> > of application message anymore. This has = to do with the workings of
> > the protocol.
>
> Agreed. The second part is an = explanation/motivation for the
> not-so-obvious definition. Do you think it is = worth keeping,
> by moving it elsewhere? Or should we completely = get rid of that prose?
>
> > Although I suggest to rip out the last = part of this definition I
> > should say that I disagree (if I = understood correctly) with your
> > statement "Establishing such an = agreement is beyond OCP scope".
> > Capability negotiation can help you = establish what application
> > messages are acceptable on each connection = or callout server as a
> > whole.
>
> I agree that it can help. I hope we can keep = things simple (no
> negotiation) in this context without loosing = too much
> functionality or interoperability. I suspect = that callout
> implementation abilities will be well known to = those who add
> a callout server/service to an OPES = intermediary. These
> administrators would be able to configure the = system appropriately.

Humm...I'm really not sure about that. I guess the = sysadmin can learn it, but it would be much easier and debug friendly = (if something goes wrong) to have capability negotiations.

Not to mention that as OPES services become more = "rich" a lot of new capabilities will appear.

>
> IMO, there are two cases where auto-negotiation = is important:
>
>       - dynamic config = changes: a new service is automatically
>         added to = the list of services available to an OPES
>         = processor;
>
>       - dynamic = ability changes: the same service suddenly can no
>         longer = handle complete HTTP messages and demands just
>         HTTP = message bodies in certain encoding.
>
> Both cases seem unusual and not worth = supporting. Do you see
> other use cases for auto-negotiation? Or do you = think the
> above two cases are worth supporting in = OCP?

See above. I think that relying alone in CLI = configuration is not the way to go. IMHO if you look at routing = protocols, PPP, and text protocols like SIP and HTTP there is some form = of capability negotiation. SOAP also has some form of capability = negotiation.

>
> > Suggested version.
> >
> > " application message: A sequence of = octets that OPES processor
> >       = designates for callout service processing.  Usually, an
> >       = application message is the basic unit of application protocol
> >       = communication, as defined by that application protocol (e.g.,
> >       = HTTP/1.1 message).
>
> Agreed. Please let me know whether you think we = should still
> keep the explanation/motivation part elsewhere = in the specs.

Yes, we should...in the protocol working = section.

>
> > 2)
> >
> > "A callout server may send this data = back to
> >    the OPES processor, with = or without modifications."
> >
> > Suggestion
> >
> > "A callout server may send or not = this data back to the OPES
> > processor. When the callout server sends = data back to the OPES
> > processor, it can be modified or = not."
>
> I think "may" implies "may = not", but I will change to be explicit.
>
> > 3)
> >
> > "The primary purpose of OCP = communications is modification of
> >    application message = payloads..."
> >
> > Do not want to seem picky, but the primary = purpose of OCP
> is to ship
> > packets back and forth between Callout = Server and OPES Processor.
> > Whatever is done with message has nothing = to do with OCP
> anymore. It
> > is a function totally contained within the = callout server.
> >
> > I guess you can say
> >
> > "The primary purpose of the OCP is to = send data to the
> callout server
> > where it will be examined and possibly = changed"
>
> OK.
>
> > 4)
> >
> > "   OCP transaction is a = logical sequence of OCP messages
> processing a
> >    single original = application message. The result of the
> processing may
> >    be zero or more = application messages, adapted from the
> original. A
> >    typical transaction = consists of two message flows: a
> flow from the
> >    CLIENT to the SERVER = (sending original application message) and a
> >    flow from the SERVER to = the CLIENT (sending adapted application
> >    messages). The number of = application messages produced
> by the SERVER
> >    and whether the SERVER = actually modifies original
> application message
> >    depends on the requested = callout service. The CLIENT or
> the SERVER
> >    can terminate the = transaction by sending a corresponding
> message to
> >    the other = side."
> >
> > Hummm...I guess I'm not confortable with = the idea of mixing the OCP
> > semantics per se and whatever it = carries..The problem with this
> > approach is that we will start asking = things like "what is the
> > original application message?". = "Is the the whole HTTP 1.1 message
> > before TCP fragmentation or after?" , = "And if is protocol
> X..and Y",
> > etc, etc.
> >
> > This is my (lean) suggestion using your = definitions:
> >
> > "  An OCP transaction is a = logical exchange of OCP messages.
> >
> >    A OCP transaction starts = with a xaction-start message, followed
> >    by zero or more data-xxx = messages, zero or more appl-xxx and ends
> >    with a xaction-end = message. "
>
> Here I disagree. The whole purpose of having = transactions is
> to group together processing of a single = application message
> (which is a defined term). That grouping is not = strictly
> necessary but it brings structure and is = actually required by
> the OCP requirements draft (see the "3.3 = Callout
> Transactions" section).

I guess this is more of a performance/device = intelligence discussion. My first point is that having to send = xaction-start/stop for every single application message is quite an = overhead. Actually this might be the biggest overhead I've ever seen. = If a HTTP message fits into a TCP packet we will have to process 2 = extra packets for every single "real" (for the lack of a = better word) packet.

The other point I would like to make is that having = to determine start/end of application messages means that the OPES = processor will need to understand all these applications, which is not = necessarily desirable. Let's suppose I have a callout server that deals = with content filtering. The OPES processor gets TCP packets with HTTP = in it (fragmented or not) and ships them to the Callout server, which = will reconstruct the HTTP message if needed and send it back to the = OPES processor. The OPES processor then decapsulates the IP/TCP/HTTP = from OCP and sends it on its way.

The same example would apply for RTP where I just = want to send packets to the callout server for content adaption. I = would not like to have to implement a RTP/MPEG-1 decoder in my OPES = processor to know where application messages end/start.

Finally, let's suppose the first packet of a video = session was lost and I can recognize that. Since there is no = retransmissions, what should I do since I can only send whole = application messages to the Callout server? I will never see that first = packet again. In the case of HTTP I would need to wait for a = retransmission before I can send anything to the callout server. And = who can guarantee me that I will ever receive everything?




>
> If we adopt your wording, there is no need to = have a notion
> of OCP transaction at all, right? Every = app-message message
> from the callout server would simply have to = have an extra ID
> pointing to the original application message it = modifies (so
> that the OPES processor can put things back = together and
> forward the message as appropriate).

See above.

>
> I agree that "original" qualifier = should be removed, changed,
> or defined.
>
> As for "And if is protocol X..and Y", = it is a valid question
> that we will need to address, but it does not = seem to be
> related to the definition of an OCP = transaction?
>
> > 5)
> >
> > "xid: OCP transaction = identifier.  Uniquely identifies an OCP
> >       = transaction originated by a given CLIENT. Since each
> transaction
> >       deals = with a single application message, "xid" also = identifies
> >       that = application message."
> >
> >
> > As you can guess, IMHO the part = ""xid" also identifies that
> > application message." is = troublesome.
> >
> > My suggestion
> >
> > "xid: OCP transaction = identifier.  Uniquely identifies an OCP
> >       = transaction originated by a given CLIENT."
>
> OK.
>
> > 6)
> >
> > "am-id: Application message = identifier.  Uniquely identifies an
> >       = application message within an OCP transaction."
> >
> > I guess it is one more reason to make the = modification I mention in
> > number
> > 5) above.
>
> I am not sure I follow. Am-id exists so that a = callout server
> can modify one [original] application message = into more than
> one [adapted] application messages. Since there = could be more
> than one adapted message, we need am-id to be = able to
> interleave their data and to abort them.

I understand your point. We can still have am-id if = the OPES processor wants to do something with the message after it = receives it from the Callout server. Again, see above.

>
> > 7)
> >
> > "   am-source: Information = about the source of an
> application message.
> >       For = example, HTTP client or origin server IP address and TCP
> >       = connection ID.
> >
> >    am-destination: = Information about the destination of an
> application
> >       = message. For example, HTTP client or origin server = address."
> >
> > I'm not sure I follow this...TCP = connection ID? Information
> about the
> > source of an application message?
>
> Callout server actions may depend on = meta-information that is
> not available in the message itself. For = example, a callout
> service may insert user-specific pieces of HTML = but user
> authentication may happen outside of the = current message
> scope and, hence, user ID would need to be = relayed by OPES
> processor to the callout server (e.g., via the = destination parameter).
>
> However, I consider current = "am-source" and "am-destination"
> approach inadequate because meta-information = can include more
> than source and destination descriptions. I = will propose and
> argue for a more general replacement shortly. = Let's ignore
> this broken part for now.
>
> > 8)
> >
> > "size: Application data size in = octets. The value either applies to
> >       the = data attached to an OCP message or suggests data
> size to be
> >       sent = in response to an OCP message."
> >
> > Is this the original value (which I guess = before reaseembly
> it cannot
> > be known)? The value of the OCP = payload?
>
> If it is the size of the data attached to an = OCP message,
> then it is OCP payload (e.g., "here are = the next 100 bytes").
> If it is a suggestion (e.g., "give me 100 = more bytes"), then
> it is not OCP payload. See data-have and = data-need messages.
> Note that "data" is a defined = term.
>
> The "size" attribute has little to do = with application
> message size. It is about the size of an = application message
> chunk being sent or chunks being requested. The = value of
> "size" would be equal to the = transfer-length of the
> application message only if the entire = application message is
> transmitted via one data-have OCP = message.

Okay, I guess this very answer that you gave me could = go into the draft.

>
> > 9)
> >
> > "modified: A boolean parameter = indicating that the attached
> >       = application data has been modified by he SERVER. 
> Only SERVER may
> >       send = this flag. This parameter can be used with any
> OCP message
> >       that = has am-id parameter."
> >
> > Suggestion
> >
> > "modified: A boolean parameter = indicating that the attached
> >       = application data has been modified by the SERVER.
> Only the SERVER may
> >       send = this flag. This parameter can be used with any
> OCP message
> >       that = has am-id parameter."
> >
> > I guess the caveat is that if you but the = flag in one OCP message
> > containing am-id, you have to put in all = of them for the same am-id.
>
> Actually, not. The granularity may be one level = lower. The
> SERVER tells the CLIENT that a particular = message data
> _chunk_ got modified. This implies that the = entire message
> got modified, but provides more information and = does not
> require repeating the same flag in subsequent = data-have messages.
>
> Of course, if the flag is used with, say, = app-message-start
> message, then it applies to the entire = application message
> without [yet] saying which chunk got = modified.

I'm still working on the frequency that you can haver = more than one application message into one transaction.

>
> > 10)
> >
> > "copied: A flag indicating that a = copy of the attached application
> >       data = is being kept at the CLIENT. Only the CLIENT may
> send this
> >       flag. = This parameter can be used with any OCP message that may
> >       carry = application message data. (XXX: it is yet unclear when
> >       CLIENT = commitment to preserve the data may end.)"
> >
> > Same caveat as above.
>
> Same answer as above. Here, the chunk-level = granularity is
> even more important. See the long e-mail thread = about copying
> commitment. Copying a data chunk is relatively = easy and
> painless. Commitment to copy the entire = application message
> is a very different animal.
>
> Perhaps the "data" definition must be = modified to stress the
> level of granularity here?

Yep.

>
> > 12)
> >
> > "error: A flag indicating abnormal = conditions at the sender that
> >       cannot = be expressed via result parameter. "
> >
> > Such as? I guess maybe we could maintain = the HTTP/SIP
> approach where
> > we have status code and reason phrases for = everything.
>
> We could. Some argue that abnormal termination = must be
> signaled more explicitly. See messages from = Oskar Batuner
> related to the xaction-abort issue.
>
> > "It is RECOMMENDED that
> >       the = recipient deletes all state associated with the
> corresponding
> >       OCP = message. For example, if the message is
> 'app-message-end' and
> >       the = application message contained user credentials, such
> >       = credentials should be deleted."
> >
> > My suggestion
> >
> > ""It is RECOMMENDED that
> >       the = recipient deletes all state associated with the
> corresponding
> >       OCP = message."
>
> Do you mean deleting the example? Examples are = not normative;
> do you think the presence of an example hurts = in this case?


No. I guess examples should go on sections of their = own.

>
> > 13)
> >
> > "feature: A OCP feature identifier = with optional feature parameters.
> >       Used = to declare support and negotiate use of OCP
> optional features
> >       (e.g., = copying of data chunks at the CLIENT)."
> >
> > I guess this is another one we need to = iron out...
>
> Yes, definitely.
>
> > 14)
> >
> > "If a malformed message is received, = the recipient MUST terminate
> >    processing of the = corresponding OCP connection using
> 'connection-end'
> >    message with an error = flag"
> >
> > Why not send a status code and reason = phrase instead of this error
> > flag?
> >
> > Just say "400 Bad Request"...or = "400 Malformed Message"
>
> As Oskar argued, the semantics of "400 = Malformed Message" may
> be different from "400 Malformed Message, = and the error on
> this side was so bad that you probably want to = delete all
> state associated with this transaction even if = that state
> looks valid to you". We could have a = special code for the
> latter, but we would need it for every error = response;  that
> is why Oskar proposed special *-abort messages = and I
> suggested a special "error" = flag.
>

I'm not going to argue too much about this. I will = just say that other text/binary based protocols have been working in a = while without the need for a error flag. This is an infinite cycle. = Say, how about it is a really nasty error, worst than "so = bad"? Should we have a flag for that?

If it is bad (that is worst than 400), but not worst = than "so bad"? You know where I'm getting at?

We just need to have a different message (if needed) = and document the recommended behaviour. For example..."if you = receive a messge with a error code of 40X you should delete all state = associated with this transacation"

> "Raw" HTTP ignores this problem = because it does not document
> handling of message-independent state (e.g., = authentication
> information).


As I said, will not argue too much about this. IMHO I = do not feel this is really a good design.

>
> > 15)
> >
> > "This is the only OCP message that = may carry application data. There
> >    MUST NOT be any gaps in = data supplied by data-have and data-as-is
> >    messages (i.e., the = offset of the next data message must
> be equal to
> >    the offset+size of the = previous data message) (XXX: we
> do not need
> >    offset then; should we = keep it as a validation mechanism?) (XXX:
> >    document what to do when = this MUST is violated).  Zero size is
> >    permitted and is useful = for communicating predictions
> without sending
> >    data."
> >
> > Well, although we must not have gaps, we = might loose
> packets...we need
> > to be able to recover and not throw all = the OCP messages
> received so
> > far away...
>
> I am under impression that section 3.1 of =
> draft-ietf-opes-protocol-reqs-03.txt prohibits = OCP packet
> loss. Are you talking about application = protocol packet loss?
> If so, do you really want to inform the SERVER = of lost data
> on OCP level? Or should we assume that if = application
> protocol is lossy, the callout server would = wither know how
> to detect/handle the losses or will not care? = If possible, I
> would like data size and offset fields to = represent received
> application message octets, nothing else = (because it keeps
> things simple and application-agnostic).

I guess this goes back to examples I gave = previously.

[ ],

Reinaldo

>
>
> Thanks a lot for all your comments!
>
> Alex.
>

------_=_NextPart_001_01C2F9E7.925A4028-- From owner-ietf-openproxy@mail.imc.org Thu Apr 3 10:42:03 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25707 for ; Thu, 3 Apr 2003 10:42:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FT7JM019982 for ; Thu, 3 Apr 2003 07:29:07 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33FT7A5019981 for ietf-openproxy-bks; Thu, 3 Apr 2003 07:29:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FT3JM019967 for ; Thu, 3 Apr 2003 07:29:03 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20030403152852053002lj51e>; Thu, 3 Apr 2003 15:28:52 +0000 From: "Oskar Batuner" To: "OPES Group" Subject: RE: Need to look at tracing and debuggig Date: Thu, 3 Apr 2003 10:28:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Wednesday, April 02, 2003 1:50 PM > To: OPES Group > Subject: RE: Need to look at tracing and debuggig > > > > > On Wed, 2 Apr 2003, Oskar Batuner wrote: > > > Let me summarize relevant issues for the reference purposes: > > > > 1. Choice of the OPES application model. > > > > The OPES architecture provides two possibilities for placing > > application modules - OPES service application on the same computer > > as the OPES dispatcher and callout server. First case (initially > > called proxylet) comes as a natural extension of caching proxies. > > Some commercially available caches have proprietary API for adding > > application logics, like filtering capabilities. The proprietary > > nature of such extensions prevented extensive deployment, and I > > believe the whole OPES idea started as an attempt to standardize > > triggers (rules) and proxylet API, environment and deployment. > > > > Callout server comes either as a natural extension of the first > > model to offload application processing and create a scalable > > application structure or as a way to use a different class of > > devices - fast L7 switches - as an application building platform. > > > > What is common to both models - the central point, dispatcher, that > > is assigned the role of policy enforcement point. > > Actually, the two models are equivalent except for communication costs > between OCP agents. I cannot think of any other difference between > "same computer" and "other computer" placements, not to mention that > "same computer" is very difficult to define (same CPU? same processor > block? same server farm? same owner? etc.) > > Thus, I would suggest that we keep varying communication costs in mind > but make no other assumptions or distinctions. > This is a kind of extreme approach. It implies that no matter where the application module resides all interaction with dispatcher goes through OCP. This is possible, but initially we had some attempts to define a proxylet environment and API without regard to protocol. In this approach "same computer" means something that supports a fast and reliable (usually proprietary) method to get information from the OPES dispatcher to the application module. Currently I do not see any developments in the proxylet area, so your approach becomes an appointed winner :). > > OPES facilities should not prefer one model over another, and this > > may be achieved by keeping OPES processor as a main representation > > center. It should be responsible for complying with tracing and > > other OPES requirements. It does not mean that it always has to > > keep persistent information, but in this case callout protocol > > should support directives for tracing control. Callout protocol > > may also support negotiation about insertion tracing information > > into the message. OPES processor should be able either to request > > necessary information from callout server or to issue directives > > for information insertion and verify that directive is accepted. > > > > Why I'm going into this lengthy discussion is that I got > > an impression that there is s shift to the second model that is > > causing some misunderstanding. Maybe I'm wrong. > > I do not see a clear connection between "OPES facilities should not > prefer one model over another" and the rest of the paragraphs. I do > agree with the opening statement. However, I think it is premature to > make conclusions regarding OCP involvement. > > I would suggest that we agree on what tracing information must be > supported first, and only after that talk about how to support it (in > OCP or elsewhere). > > > 2. Tracing information granularity and persistence levels. > > The information may be: > > > > - message-related, e.g. "virus checking done - passed", "content > > filtering applied", "translated from quibbish to danqush". Such > > information should be supplied with each message and indicate that > > specific action was taken. All data that describes specific actions > > performed for the message should be provided with that message, as > > there is no other way to find message level details later. OPES > > application (including OPES processor and all application modules > > and callout servers involved) is not supposed to keep volatile > > information after request processing is done. > > Agreed. > > > - session related. The session knowledge may be not directly > > supported by the protocol, as the case is for HTTP. In this > > situation OPES processor is responsible for keeping the > > session context. Session related information may be provided > > once per session, some details may be replaced by id or a > > reference for subsequent information retrieval. > > > > Session level data must be preserved for the duration of > > the session. OPES processor is responsible for inserting > > notifications if session-level information changes. > > > > Examples of session-related information is "virus checker > > abcd build 123 enabled", "OPES server id=xyz present". > > I am not convinced we have to support these kind of tracing. The end > does not usually care whether "virus checker abcd build 123 is > enabled"; it cares only wether that virus checker has seen or modified > the application message, which is already covered by "message-related" > bullet above. Same for "OPES server id=xyz present". Taking virus checker as an example I can see two situations when detailed information is important. The end user might wish to verify virus checker signature and certificate. Very reasonable thing to do if one is going to rely on the "check passed" notification. Another possibility is a second OPES processor with a virus checker present in the OPES flow. When signed as "passed" message reaches this second processor it may be interested not only in the first virus checker credentials but also in type and version information - in order to adopt it's actions. > > What is a session? What are session boundaries? How do those > boundaries correspond to message/connection boundaries? And, finally, > why should we care about anything that does not affect our application > message? I do not have a "standard" session definition at hand, so for our purposes I'd define session as an application dependent persistent context that propagates certain parameters to all messages belonging to that session. In this sense session notion does affect our application messages: if there was a specific OPES application participating in the session its credentials and functional abilities extend to all messages within that session. Reintroducing and re-verifying complete list of all participating OPES servers' credentials, settings and functional capabilities with each message may have a serious performance impact. > > > - log information id. This may be used e.g. for accounting > > and non-repudiation purposes. Detailed information referenced > > by this id may be not available online but can be retrieved > > later by some off-line procedure. > > This belongs to the "message-related" category, IMO. For example, > > OPES-Actions: "virus checker FooBar applied > (result=clear, logid=34341, version=123)" Yes, this belongs to message-related. I was thinking about designated a separate (additional) category because of two specific information of logging information: - it can not be used as a parameter in subsequent real-time requests for detailed information - it is persistent and should be added to the other logs to facilitate future log collation. I'm not sure we really need this as a separate category - this is just a subject for discussion. > > > - server related persistent information, e.g. "OPES center of > > authority ", "privacy policy ". It may be also > > presented once per session and it does not change between > > sessions. > > This has to be per-message unless you somehow can define sessions so > that the end-user can distinguish them. For example, two pipelined > HTTP request on the same TCP connection (from end-user point of view) > may pass through very different OPES intermediaries and reach > different content providers. How are you going to maintain sessions if > not on a per-message basis (which makes session concept unnecessary)? > Please give an example of a session in this context. Let's say a series of requests from the same user to the same site. It is application dependent, so I'd live determination of the session boundaries to the application. This creates a possibility that different participants may define session differently, but a) they may add a session id or use the existing one (application defined), b) they may do certain thing that are safe even if session context is lost, e.g. put unique identifiers instead of descriptions. If end user lost related description he/she may just send a kind of whois request for that identifier. I do not understand your statement about two requests in the same connection passing through different OPES server to different content providers. My understanding was that the requirement of explicit IP exposure and per-hop connection termination prevents such situations. Please explain. > > > - end-point related data: what profile is activated (profile ID), > > where to get profile details, where to set preferences. I'm not sure > > how far we should go in this direction. > > OK. > > > I see other work going on in this area (e.g. > > [draft-barbir-opes-spcs-03.txt]). I thing OPES should provide a > > framework for such development by defining flexible and extensible > > tracing and informational facilities. > > I agree, but I hope we can limit ourselves to per-message facilities > only (no "sessions"). Knowledge of information persistence permits replacement of detailed data ( which is required for volatile information) by references. Sure server URI is an object better defined than a session. We may further clarify what kind of persistency should be taken into consideration, but considering all information as volatile (per-message) looks like too strong simplification. > > > 3. Some terminology. > > > > > Can we develop a few example scenarios that illustrate the various > > > concepts of "information points", "reference points", "identifier", > > > > - REFERENCE POINT - a reference that may be used out-of-band to > > perform a specific function. > > > > An example may be URI for the privacy policy, center of authority > > URI, server address, etc. Usually no protocol is provided to access > > the reference point. > > If reference point is a URI (and it probably should be), then the > schema part of the URI (e.g., "http") usually determines ways to > access the information. > > > - INFORMATION POINT - implies presence of the protocol to access > > detailed information at this point. Example may be URI to get > > a certificate for virus checker or content filter, examine > > and set profile setting and active preferences. > > I see no difference with the "REFERENCE POINT". The protocol > distinction is too vague. Can you give a reference point example that > lacks protocol? Do we need to distinguish the two points? abuse@ad-insertion.com looks for me as a reference point. The main difference is presence of a programmatic facility for information retrieval. Such facility permits to remove from the protocol detailed information even if this information may be needed by the participating applications. > > > - IDENTIFIER - provides a unique binding to detailed persistent > > information. For example "transformation-applied : fe123" gives > > a participant ability to enquire (and maybe cache) details of > > the transformation fe123. > > Identifier can be an information point as well, right? I guess I am > missing the motivation behind this terminology and these distinctions. Information point is an address (URI) and protocol combination, identifier is just a tag. If you want to tell that this terminology is far from perfect - yes, I agree. But still I hope we can clarify > > > Use of such (opaque) identifiers > > does not require prior knowledge and does not create a burden > > of storing additional information - this is just a tag for > > persistent information (not message-specific). > > The same is true for REFERENCE and INFORMATION POINTS, right? > REFRERENCE and INFORMATION POINTS are not opaque. Application and/or a human being should be able to interpret them and use for information sending and/or retrieval. > Why cannot an IDENTIFIER be message specific? For example, > > transformation-applied: http://service.org/explain?msgkind=foobar Sure IDENTIFIER can be message specific, e.g. log-id. But one you are introducing here is a combination of identifier and an information or reference point (the difference is determined by presence of predefined response format and ability of application to interpret this response programmatically). I am a strong proponent of schema normalization, and I prefer to keep separately all things that can be separated. This example should look like: transformation-applied: server=1.2.3.4 definitions=http://service.org transformation-type=foobar profile=ffe123 > > > > 4. Using discretion of what points should be exposed. > > > > > If we don't identify the exact server, how would a service provider > > > trace a problem I report to him? How would he know which server to > > > check, if I tell him that something went wrong and check him to ask > > > this? With email, for example, I know exactly which mail servers have > > > been o the path, thus being able to trace down to the exact server. > > > > It is the choice of the service provider - what servers should be exposed. > > I agree. Same for HTTP's Via headers. I would also add "what servers > should be exposed, if any". > > > For example currently if pictures coming from some site are distorted > > or data is corrupted it is extremely difficult and often even impossible > > to tell what front-end or back-end servers are malfunctioning, especially > > in the presence of dynamically addressed CDN and multi-tier backend > > application. Usually notification containing the main URL and request > > parameters should be sufficient. > > > Mail server is also a good example: you may see only representative > > of a server farm, some processing, like virus checking or spam > > filtering may be performed by invisible back-end servers. Still servers > > that are directly identified in the headers give reasonable information > > for problem analysis. > > Exactly. OPES should not be responsible for solving general > finger-pointing problems on the Internet. > > > I'd recommend to minimize number of points exposed - in order to > > hide application complexity and dynamic reconfiguration but provide > > a separate logical places for information requests and references. > > I would suggest that we leave this choice to the administrator. We > should provide means to expose every OPES point. The administrator > should be able to configure their intermediaries to expose just what > they want/need. > > > In most cases OPES processor should hide underlying application > > structure and care the burden of relaying some requests (both in-line > > and out-of-band) to callout processors. This does not require > > storage of additional data - at each moment OPES processor knows all > > underlying configuration details and can determine what callout > > processor should answer the request. > > If we only trace OPES processors and service IDs, then OPES processor > should be responsible for adding tracing (it can use a trace-adding > callout service but that should not be required). A good example is a > text translation callout service. Such a service can be implemented in > an application protocol-agnostic manner and, hence, will not be able > to trace itself. OPES processor will always be able to add tracing > information though. Agreed. Oskar > > Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 3 10:54:29 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26512 for ; Thu, 3 Apr 2003 10:54:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FcTJM021214 for ; Thu, 3 Apr 2003 07:38:29 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33FcTkY021213 for ietf-openproxy-bks; Thu, 3 Apr 2003 07:38:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FcSJM021208 for ; Thu, 3 Apr 2003 07:38:28 -0800 (PST) Received: from f08v-11-228.d1.club-internet.fr ([212.194.166.228] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 1916nG-00038t-00; Thu, 03 Apr 2003 07:38:23 -0800 Message-Id: <5.2.0.9.0.20030403174145.0280f580@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 03 Apr 2003 17:43:07 +0200 To: Alex Rousskov , OPES Group From: jfcm Subject: RE: Need to look at tracing and debuggig In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 07:32 03/04/03, Alex Rousskov wrote: > 3. An OPES processor MUST add to the trace identification > of the "system/entity" it belongs to. "System" > ID MUST make it possible to access "system" privacy > policy. I disagree with the MUST. - first there are system which does not want to be known. - most of all this would block innovation. Information services could be actually built as a core system and a daisy chain of OPES. Information on the system structure is propreitary. There is no "system" privacy policy by application components. jfc From owner-ietf-openproxy@mail.imc.org Thu Apr 3 12:58:21 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04290 for ; Thu, 3 Apr 2003 12:58:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33Hi5JM029870 for ; Thu, 3 Apr 2003 09:44:05 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33Hi5Lp029869 for ietf-openproxy-bks; Thu, 3 Apr 2003 09:44:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33Hi3JM029864 for ; Thu, 3 Apr 2003 09:44:04 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h33Hi5vj032880; Thu, 3 Apr 2003 10:44:05 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h33Hi5HI032879; Thu, 3 Apr 2003 10:44:05 -0700 (MST) (envelope-from rousskov) Date: Thu, 3 Apr 2003 10:44:05 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Comments on ocp-00 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E70@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E70@zsc3c026.us.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: Here is a short summary of the pending issues on this thread. a) OPES processor may be able to pre-process application messages (e.g., extract payload). Callout servers may be able to handle various kinds of application data (e.g., complete HTTP messages versus MIME-encoded payload). Thus, somebody needs to tell OPES processor and callout server what is an "application message" definition that they should both use during OCP communications. Should OCP support auto-negotiation or rely on out-of-band (e.g., manual) configuration? b) Do we really need a special "error" flag to say "rally bad error; you should probably wipe out all related state". Or can we assign the same side-effect to some of the result codes? c) OPES processor can be [a part of] an application-level proxy. Can OPES processor be a transport-level gateway too? For example, can OPES processor manipulate with raw TCP packets and care about things like retransmissions and ACKs? d) If a fragment of an application message is lost, [how] should OPES processor signal that to the callout server? A loss can happen when adapting lossy application protocols. e) Do we need to group processing of a single application message together using OCP transaction concept? Should OCP transaction mean something else? Do we need OCP transactions at all? Detailed responses are inlined below. On Thu, 3 Apr 2003, Reinaldo Penno wrote: > Humm...I'm really not sure about that. I guess the sysadmin can > learn it, but it would be much easier and debug friendly (if > something goes wrong) to have capability negotiations. IMO, auto-negotiation would be "better" for admin if and only if there is a single match between OPES processor and callout server capabilities. If there is no match, auto-negotiation will not help and may hurt (the problem will more likely to be unnoticed until run-time). If there are several matches, auto-negotiation may hurt because it will often select the wrong match. > Not to mention that as OPES services become more "rich" a lot of new > capabilities will appear. Yes, but you are also implying that a single service and a single OPES processor will poses many capabilities and that there is always a deterministic way to auto-negotiate the best match. I doubt that is going to happen and I doubt it is the best design. I think our disagreement is clear. I do not have a strong opinion here (I just would prefer to keep protocol simple if negotiation benefits are uncertain). Let's hear other opinions. If I am the only outlier, we will support auto-negotiation. > > > This is my (lean) suggestion using your definitions: > > > > > > " An OCP transaction is a logical exchange of OCP messages. > > > A OCP transaction starts with a xaction-start message, followed > > > by zero or more data-xxx messages, zero or more appl-xxx and ends > > > with a xaction-end message. " > > > > Here I disagree. The whole purpose of having transactions is > > to group together processing of a single application message > > (which is a defined term). That grouping is not strictly > > necessary but it brings structure and is actually required by > > the OCP requirements draft (see the "3.3 Callout > > Transactions" section). > > I guess this is more of a performance/device intelligence > discussion. My first point is that having to send xaction-start/stop > for every single application message is quite an overhead. Actually > this might be the biggest overhead I've ever seen. If a HTTP message > fits into a TCP packet we will have to process 2 extra packets for > every single "real" (for the lack of a better word) packet. Not at all. The overhead is probably just a few bytes (it would be known when we decide on transport binding and encoding). These "opening" and "closing" messages will usually fit into the same OCP/TCP packet that carries application data (OCP's data-have message). > The other point I would like to make is that having to determine start/end > of application messages means that the OPES processor will need to > understand all these applications, which is not necessarily desirable. Not exactly. Recall that it is up to the OPES processor what to call an application message! However, I strongly believe that in most cases OPES processor will know the application protocol just because such knowledge is usually required to proxy an application protocol correctly. Moreover, parsing an application message will often be desirable because many services are likely to be application-agnostic (e.g., the same virus filter service can be applied to HTTP and SMTP payloads and, ideally, it should not care about HTTP and SMTP headers). > Let's suppose I have a callout server that deals with content > filtering. The OPES processor gets TCP packets with HTTP in it > (fragmented or not) and ships them to the Callout server, which will > reconstruct the HTTP message if needed and send it back to the OPES > processor. The OPES processor then decapsulates the IP/TCP/HTTP from > OCP and sends it on its way. OCP allows OPES processor to declare a TCP packet on an HTTP connection an "application message". Such a low-level OPES processor will not be able to handle high-level rules and will only work with OCP services that can handle raw TCP packets as input, of course, but it is possible! IMO, we may want to assume that OPES processor is an application-level proxy not a transport-level gateway, but others may feel differently. Does architecture draft answer that question? If we are working on an application-level proxy, then there is no such thing for us as a "TCP packet", I guess. > The same example would apply for RTP where I just want to send > packets to the callout server for content adaption. I would not like > to have to implement a RTP/MPEG-1 decoder in my OPES processor to > know where application messages end/start. (a) you do not have to because you define what the application message is (b) AFAIK, RTP message boundaries can be easily determined without any MPEG knowledge or decoding; just like HTTP message boundaries can be determined without understanding the content encoding of the payload. > Finally, let's suppose the first packet of a video session was lost and I > can recognize that. Since there is no retransmissions, what should I do > since I can only send whole application messages to the Callout server? > I will never see that first packet again. I do not think there is any requirement to send whole application messages to the Callout server. Both OCP draft and OCP requirements draft speak of application message fragments. There should be nothing important in the current OCP draft that prevents an OPES processor to forward partial messages to the callout server. We do need to document such possibility though (and agree on what "offset" values should be in that case). > In the case of HTTP I would need to wait for a retransmission before > I can send anything to the callout server. And who can guarantee me > that I will ever receive everything? Not sure I follow. In case of HTTP over TCP would would not even know that a packet got lost unless you sit on a TCP level (and then HTTP becomes irrelevant)! > I'm still working on the frequency that you can haver more than one > application message into one transaction. Yes, we must reach an agreement on what OCP transaction is and whether we need it at all. I was simply working based on the OCP requirements draft, but I see no problem revisiting the issue now, when we can talk specifics. > > > Just say "400 Bad Request"...or "400 Malformed Message" > > > > As Oskar argued, the semantics of "400 Malformed Message" may > > be different from "400 Malformed Message, and the error on > > this side was so bad that you probably want to delete all > > state associated with this transaction even if that state > > looks valid to you". We could have a special code for the > > latter, but we would need it for every error response; that > > is why Oskar proposed special *-abort messages and I > > suggested a special "error" flag. > > > > I'm not going to argue too much about this. I will just say that > other text/binary based protocols have been working in a while > without the need for a error flag. This is an infinite cycle. Say, > how about it is a really nasty error, worst than "so bad"? Should we > have a flag for that? > > If it is bad (that is worst than 400), but not worst than "so bad"? > You know where I'm getting at? Yes, I do. I agree that the current solution is not perfect, but suggest to wait for more input from Oskar. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 3 13:10:38 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04823 for ; Thu, 3 Apr 2003 13:10:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33Hx8JM000873 for ; Thu, 3 Apr 2003 09:59:08 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33Hx8hC000872 for ietf-openproxy-bks; Thu, 3 Apr 2003 09:59:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33Hx7JM000868 for ; Thu, 3 Apr 2003 09:59:07 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h33Hx9vj033247; Thu, 3 Apr 2003 10:59:09 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h33Hx986033246; Thu, 3 Apr 2003 10:59:09 -0700 (MST) (envelope-from rousskov) Date: Thu, 3 Apr 2003 10:59:09 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Need to look at tracing and debuggig In-Reply-To: <5.2.0.9.0.20030403174145.0280f580@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030403174145.0280f580@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: On Thu, 3 Apr 2003, jfcm wrote: > > At 07:32 03/04/03, Alex Rousskov wrote: > > 3. An OPES processor MUST add to the trace identification > > of the "system/entity" it belongs to. "System" > > ID MUST make it possible to access "system" privacy > > policy. > > I disagree with the MUST. > > - first there are system which does not want to be known. Yes, but it looks like IAB prohibits us from "supporting" an OPES system which does not want to be known: (5.1) Privacy: The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries. Thus, an OPES intermediary that does not want to be known cannot be OPES compliant, but will, of course, interoperate just fine. Also, we still need to decide what that ID is. We may be able to support IDs that do not reveal much of private info. Furthermore, since IAB does not seem to care about content provider privacy, we may want to polish the above rule 3 so that it applies to providers only (and is only a MAY for client-side intermediaries). > - most of all this would block innovation. Information services > could be actually built as a core system and a daisy chain of OPES. > Information on the system structure is propreitary. There is no > "system" privacy policy by application components. This is not a problem due to the rule 4 that allows aggregation of tracing information to hide system structure. We just need one trace entry from each system, we do not care about individual OPES intermediaries inside that system: 4. An OPES processor MAY group the above information (items 1-3) for sequential trace entries having the same "system/entity" ID. In other words, trace entries produced within the same "system/entity" MAY be merged/aggregated into a single less detailed trace entry. This is very similar to Via headers in HTTP that face similar challenges. Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 3 13:20:00 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05358 for ; Thu, 3 Apr 2003 13:19:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33I37JM001007 for ; Thu, 3 Apr 2003 10:03:07 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33I37vu001005 for ietf-openproxy-bks; Thu, 3 Apr 2003 10:03:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33I35JM000998 for ; Thu, 3 Apr 2003 10:03:05 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33I2s817942; Thu, 3 Apr 2003 12:02:54 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGB4WDK>; Thu, 3 Apr 2003 10:02:53 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E74@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , OPES Group Subject: RE: Comments on ocp-00 Date: Thu, 3 Apr 2003 10:02:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA0B.39889C96" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FA0B.39889C96 Content-Type: text/plain Hello Alex, I liked your summary. I guess we should wait for other opinions. On the other hand, in the case of capability negotiation, I disagree with your statement that it chooses the wrong options. PPP tons of different options, has been out there for a while and we can say its capability negotiation is pretty reliable. SDP's offer and answer model also. There is also capability negotiation or maybe a offer/answer model in BGP and it helps a lot. If you go into the "legacy" world like FAX, the only reason it is so widespread and you can FAX anybody is because of a good capability negotiation. We put capability negotiation in the draft because it is useful. "The OPES callout protocol MUST support the negotiation of capabilities and callout connection parameters between an OPES processor and a callout server" Okay, how I write the capability negotiation part? Regards, Reinaldo > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, April 03, 2003 12:44 PM > To: OPES Group > Subject: RE: Comments on ocp-00 > > > > Here is a short summary of the pending issues on this thread. > > a) OPES processor may be able to pre-process application > messages (e.g., extract payload). Callout servers > may be able to handle various kinds of application > data (e.g., complete HTTP messages versus MIME-encoded > payload). Thus, somebody needs to tell OPES processor > and callout server what is an "application message" > definition that they should both use during OCP > communications. Should OCP support auto-negotiation or > rely on out-of-band (e.g., manual) configuration? > > b) Do we really need a special "error" flag to say > "rally bad error; you should probably wipe out all > related state". Or can we assign the same side-effect > to some of the result codes? > > c) OPES processor can be [a part of] an application-level > proxy. Can OPES processor be a transport-level gateway > too? For example, can OPES processor manipulate with > raw TCP packets and care about things like > retransmissions and ACKs? > > d) If a fragment of an application message is lost, > [how] should OPES processor signal that to the callout > server? A loss can happen when adapting lossy application > protocols. > > e) Do we need to group processing of a single application > message together using OCP transaction concept? Should > OCP transaction mean something else? Do we need OCP > transactions at all? > > Detailed responses are inlined below. > > On Thu, 3 Apr 2003, Reinaldo Penno wrote: > > > Humm...I'm really not sure about that. I guess the sysadmin > can learn > > it, but it would be much easier and debug friendly (if > something goes > > wrong) to have capability negotiations. > > IMO, auto-negotiation would be "better" for admin if and only > if there is a single match between OPES processor and callout > server capabilities. If there is no match, auto-negotiation > will not help and may hurt (the problem will more likely to > be unnoticed until run-time). If there are several matches, > auto-negotiation may hurt because it will often select the > wrong match. > > > Not to mention that as OPES services become more "rich" a > lot of new > > capabilities will appear. > > Yes, but you are also implying that a single service and a > single OPES processor will poses many capabilities and that > there is always a deterministic way to auto-negotiate the > best match. I doubt that is going to happen and I doubt it is > the best design. > > I think our disagreement is clear. I do not have a strong > opinion here (I just would prefer to keep protocol simple if > negotiation benefits are uncertain). Let's hear other > opinions. If I am the only outlier, we will support auto-negotiation. > > > > > This is my (lean) suggestion using your definitions: > > > > > > > > " An OCP transaction is a logical exchange of OCP messages. > > > > A OCP transaction starts with a xaction-start > message, followed > > > > by zero or more data-xxx messages, zero or more > appl-xxx and ends > > > > with a xaction-end message. " > > > > > > Here I disagree. The whole purpose of having transactions is to > > > group together processing of a single application message > (which is > > > a defined term). That grouping is not strictly necessary but it > > > brings structure and is actually required by the OCP requirements > > > draft (see the "3.3 Callout Transactions" section). > > > > I guess this is more of a performance/device intelligence > discussion. > > My first point is that having to send xaction-start/stop for every > > single application message is quite an overhead. Actually > this might > > be the biggest overhead I've ever seen. If a HTTP message > fits into a > > TCP packet we will have to process 2 extra packets for every single > > "real" (for the lack of a better word) packet. > > Not at all. The overhead is probably > just a few bytes (it would be known when we decide on > transport binding and encoding). These "opening" and > "closing" messages will usually fit into the same OCP/TCP > packet that carries application data (OCP's data-have message). > > > The other point I would like to make is that having to determine > > start/end of application messages means that the OPES > processor will > > need to understand all these applications, which is not necessarily > > desirable. > > Not exactly. Recall that it is up to the OPES processor what > to call an application message! However, I strongly believe > that in most cases OPES processor will know the application > protocol just because such knowledge is usually required to > proxy an application protocol correctly. Moreover, parsing an > application message will often be desirable because many > services are likely to be application-agnostic (e.g., the > same virus filter service can be applied to HTTP and SMTP > payloads and, ideally, it should not care about HTTP and SMTP > headers). > > > Let's suppose I have a callout server that deals with content > > filtering. The OPES processor gets TCP packets with HTTP in it > > (fragmented or not) and ships them to the Callout server, > which will > > reconstruct the HTTP message if needed and send it back to the OPES > > processor. The OPES processor then decapsulates the > IP/TCP/HTTP from > > OCP and sends it on its way. > > OCP allows OPES processor to declare a TCP packet on an HTTP > connection an "application message". Such a low-level OPES > processor will not be able to handle high-level rules and > will only work with OCP services that can handle raw TCP > packets as input, of course, but it is possible! > > IMO, we may want to assume that OPES processor is an > application-level proxy not a transport-level gateway, but > others may feel differently. Does architecture draft answer > that question? If we are working on an application-level > proxy, then there is no such thing for us as a "TCP packet", I guess. > > > The same example would apply for RTP where I just want to > send packets > > to the callout server for content adaption. I would not > like to have > > to implement a RTP/MPEG-1 decoder in my OPES processor to > know where > > application messages end/start. > > (a) you do not have to because you define what the application > message is > (b) AFAIK, RTP message boundaries can be easily determined without > any MPEG knowledge or decoding; just like HTTP message boundaries > can be determined without understanding the content encoding > of the payload. > > > Finally, let's suppose the first packet of a video session was lost > > and I can recognize that. Since there is no retransmissions, what > > should I do since I can only send whole application messages to the > > Callout server? I will never see that first packet again. > > I do not think there is any requirement to send whole > application messages to the Callout server. Both OCP draft > and OCP requirements draft speak of application message > fragments. There should be nothing important in the current > OCP draft that prevents an OPES processor to forward partial > messages to the callout server. We do need to document such > possibility though (and agree on what "offset" values should > be in that case). > > > In the case of HTTP I would need to wait for a > retransmission before I > > can send anything to the callout server. And who can > guarantee me that > > I will ever receive everything? > > Not sure I follow. In case of HTTP over TCP would would not > even know that a packet got lost unless you sit on a TCP > level (and then HTTP becomes irrelevant)! > > > I'm still working on the frequency that you can haver more than one > > application message into one transaction. > > Yes, we must reach an agreement on what OCP transaction is > and whether we need it at all. I was simply working based on > the OCP requirements draft, but I see no problem revisiting > the issue now, when we can talk specifics. > > > > > Just say "400 Bad Request"...or "400 Malformed Message" > > > > > > As Oskar argued, the semantics of "400 Malformed Message" may be > > > different from "400 Malformed Message, and the error on this side > > > was so bad that you probably want to delete all state associated > > > with this transaction even if that state looks valid to you". We > > > could have a special code for the latter, but we would > need it for > > > every error response; that is why Oskar proposed special *-abort > > > messages and I suggested a special "error" flag. > > > > > > > I'm not going to argue too much about this. I will just say > that other > > text/binary based protocols have been working in a while > without the > > need for a error flag. This is an infinite cycle. Say, how > about it is > > a really nasty error, worst than "so bad"? Should we have a > flag for > > that? > > > > If it is bad (that is worst than 400), but not worst than "so bad"? > > You know where I'm getting at? > > Yes, I do. I agree that the current solution is not perfect, > but suggest to wait for more input from Oskar. > > Thanks, > > Alex. > ------_=_NextPart_001_01C2FA0B.39889C96 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on ocp-00

Hello Alex,

I liked your summary. I guess we should wait for = other opinions.

On the other hand, in the case of capability = negotiation, I disagree with your statement that it chooses the wrong = options. PPP tons of different options, has been out there for a while = and we can say its capability negotiation is pretty reliable. SDP's = offer and answer model also. There is also capability negotiation or = maybe a offer/answer model in BGP and it helps a lot.

If you go into the "legacy" world like FAX, = the only reason it is so widespread and you can FAX anybody is because = of a good capability negotiation.

We put capability negotiation in the draft because it = is useful.

"The OPES callout protocol MUST support the = negotiation of capabilities and callout connection parameters between = an OPES

processor and a callout server"

Okay, how I write the capability negotiation = part?

Regards,

Reinaldo



> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Thursday, April 03, 2003 12:44 PM
> To: OPES Group
> Subject: RE: Comments on ocp-00
>
>
>
> Here is a short summary of the pending issues = on this thread.
>
>       a) OPES = processor may be able to pre-process application
>         messages = (e.g., extract payload). Callout servers
>         may be = able to handle various kinds of application
>         data = (e.g., complete HTTP messages versus MIME-encoded
>         payload). = Thus, somebody needs to tell OPES processor
>         and = callout server what is an "application message"
>         = definition that they should both use during OCP
>         = communications. Should OCP support auto-negotiation or
>         rely on = out-of-band (e.g., manual) configuration?
>
>       b) Do we really = need a special "error" flag to say
>         = "rally bad error; you should probably wipe out all
>          = related state". Or can we assign the same side-effect
>          to = some of the result codes?
>
>       c) OPES = processor can be [a part of] an application-level
>         proxy. = Can OPES processor be a transport-level gateway
>         too? For = example, can OPES processor manipulate with
>         raw TCP = packets and care about things like
>         = retransmissions and ACKs?
>
>       d) If a fragment = of an application message is lost,
>          = [how] should OPES processor signal that to the callout
>          = server? A loss can happen when adapting lossy application
>          = protocols.
>
>       e) Do we need to = group processing of a single application
>          = message together using OCP transaction concept? Should
>          OCP = transaction mean something else? Do we need OCP
>          = transactions at all?
>
> Detailed responses are inlined below.
>
> On Thu, 3 Apr 2003, Reinaldo Penno = wrote:
>
> > Humm...I'm really not sure about that. I = guess the sysadmin
> can learn
> > it, but it would be much easier and debug = friendly (if
> something goes
> > wrong) to have capability = negotiations.
>
> IMO, auto-negotiation would be = "better" for admin if and only
> if there is a single match between OPES = processor and callout
> server capabilities. If there is no match, = auto-negotiation
> will not help and may hurt (the problem will = more likely to
> be unnoticed until run-time). If there are = several matches,
> auto-negotiation may hurt because it will often = select the
> wrong match.
>
> > Not to mention that as OPES services = become more "rich" a
> lot of new
> > capabilities will appear.
>
> Yes, but you are also implying that a single = service and a
> single OPES processor will poses many = capabilities and that
> there is always a deterministic way to = auto-negotiate the
> best match. I doubt that is going to happen and = I doubt it is
> the best design.
>
> I think our disagreement is clear. I do not = have a strong
> opinion here (I just would prefer to keep = protocol simple if
> negotiation benefits are uncertain). Let's hear = other
> opinions. If I am the only outlier, we will = support auto-negotiation.
>
> > > > This is my (lean) suggestion = using your definitions:
> > > >
> > > > "  An OCP transaction = is a logical exchange of OCP messages.
> > > >    A OCP = transaction starts with a xaction-start
> message, followed
> > > >    by zero or = more data-xxx messages, zero or more
> appl-xxx and ends
> > > >    with a = xaction-end message. "
> > >
> > > Here I disagree. The whole purpose of = having transactions is to
> > > group together processing of a single = application message
> (which is
> > > a defined term). That grouping is not = strictly necessary but it
> > > brings structure and is actually = required by the OCP requirements
> > > draft (see the "3.3 Callout = Transactions" section).
> >
> > I guess this is more of a = performance/device intelligence
> discussion.
> > My first point is that having to send = xaction-start/stop for every
> > single application message is quite an = overhead. Actually
> this might
> > be the biggest overhead I've ever seen. If = a HTTP message
> fits into a
> > TCP packet we will have to process 2 extra = packets for every single
> > "real" (for the lack of a better = word) packet.
>
> Not at all. The <xaction-start/stop> = overhead is probably
> just a few bytes (it would be known when we = decide on
> transport binding and encoding). These = "opening" and
> "closing" messages will usually fit = into the same OCP/TCP
> packet that carries application data (OCP's = data-have message).
>
> > The other point I would like to make is = that having to determine
> > start/end of application messages means = that the OPES
> processor will
> > need to understand all these applications, = which is not necessarily
> > desirable.
>
> Not exactly. Recall that it is up to the OPES = processor what
> to call an application message! However, I = strongly believe
> that in most cases OPES processor will know the = application
> protocol just because such knowledge is usually = required to
> proxy an application protocol correctly. = Moreover, parsing an
> application message will often be desirable = because many
> services are likely to be application-agnostic = (e.g., the
> same virus filter service can be applied to = HTTP and SMTP
> payloads and, ideally, it should not care about = HTTP and SMTP
> headers).
>
> > Let's suppose I have a callout server that = deals with content
> > filtering. The OPES processor gets TCP = packets with HTTP in it
> > (fragmented or not) and ships them to the = Callout server,
> which will
> > reconstruct the HTTP message if needed and = send it back to the OPES
> > processor. The OPES processor then = decapsulates the
> IP/TCP/HTTP from
> > OCP and sends it on its way.
>
> OCP allows OPES processor to declare a TCP = packet on an HTTP
> connection an "application message". = Such a low-level OPES
> processor will not be able to handle high-level = rules and
> will only work with OCP services that can = handle raw TCP
> packets as input, of course, but it is = possible!
>
> IMO, we may want to assume that OPES processor = is an
> application-level proxy not a transport-level = gateway, but
> others may feel differently. Does architecture = draft answer
> that question? If we are working on an = application-level
> proxy, then there is no such thing for us as a = "TCP packet", I guess.
>
> > The same example would apply for RTP where = I just want to
> send packets
> > to the callout server for content = adaption. I would not
> like to have
> > to implement a RTP/MPEG-1 decoder in my = OPES processor to
> know where
> > application messages end/start.
>
> (a) you do not have to because you define what = the application
>     message is
> (b) AFAIK, RTP message boundaries can be easily = determined without
>     any MPEG knowledge or = decoding; just like HTTP message boundaries
>     can be determined = without understanding the content encoding
>     of the payload.
>
> > Finally, let's suppose the first packet of = a video session was lost
> > and I can recognize that. Since there is = no retransmissions, what
> > should I do since I can only send whole = application messages to the
> > Callout server? I will never see that = first packet again.
>
> I do not think there is any requirement to send = whole
> application messages to the Callout server. = Both OCP draft
> and OCP requirements draft speak of application = message
> fragments. There should be nothing important in = the current
> OCP draft that prevents an OPES processor to = forward partial
> messages to the callout server. We do need to = document such
> possibility though (and agree on what = "offset" values should
> be in that case).
>
> > In the case of HTTP I would need to wait = for a
> retransmission before I
> > can send anything to the callout server. = And who can
> guarantee me that
> > I will ever receive everything?
>
> Not sure I follow. In case of HTTP over TCP = would would not
> even know that a packet got lost unless you sit = on a TCP
> level (and then HTTP becomes = irrelevant)!
>
> > I'm still working on the frequency that = you can haver more than one
> > application message into one = transaction.
>
> Yes, we must reach an agreement on what OCP = transaction is
> and whether we need it at all. I was simply = working based on
> the OCP requirements draft, but I see no = problem revisiting
> the issue now, when we can talk = specifics.
>
> > > > Just say "400 Bad = Request"...or "400 Malformed Message"
> > >
> > > As Oskar argued, the semantics of = "400 Malformed Message" may be
> > > different from "400 Malformed = Message, and the error on this side
> > > was so bad that you probably want to = delete all state associated
> > > with this transaction even if that = state looks valid to you". We
> > > could have a special code for the = latter, but we would
> need it for
> > > every error response;  that is = why Oskar proposed special *-abort
> > > messages and I suggested a special = "error" flag.
> > >
> >
> > I'm not going to argue too much about = this. I will just say
> that other
> > text/binary based protocols have been = working in a while
> without the
> > need for a error flag. This is an infinite = cycle. Say, how
> about it is
> > a really nasty error, worst than "so = bad"? Should we have a
> flag for
> > that?
> >
> > If it is bad (that is worst than 400), but = not worst than "so bad"?
> > You know where I'm getting at?
>
> Yes, I do. I agree that the current solution is = not perfect,
> but suggest to wait for more input from = Oskar.
>
> Thanks,
>
> Alex.
>

------_=_NextPart_001_01C2FA0B.39889C96-- From owner-ietf-openproxy@mail.imc.org Thu Apr 3 13:45:20 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06464 for ; Thu, 3 Apr 2003 13:45:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33IYsJM002822 for ; Thu, 3 Apr 2003 10:34:54 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33IYsK1002821 for ietf-openproxy-bks; Thu, 3 Apr 2003 10:34:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33IYrJM002817 for ; Thu, 3 Apr 2003 10:34:53 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h33IYsvj034089; Thu, 3 Apr 2003 11:34:54 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h33IYsX7034088; Thu, 3 Apr 2003 11:34:54 -0700 (MST) (envelope-from rousskov) Date: Thu, 3 Apr 2003 11:34:54 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Need to look at tracing and debuggig In-Reply-To: Message-ID: References: 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: On Thu, 3 Apr 2003, Oskar Batuner wrote: > > Thus, I would suggest that we keep varying communication costs in mind > > but make no other assumptions or distinctions. > > This is a kind of extreme approach. It implies that no matter where the > application module resides all interaction with dispatcher goes through > OCP. This is possible, but initially we had some attempts to define a > proxylet environment and API without regard to protocol. In this approach > "same computer" means something that supports a fast and reliable (usually > proprietary) method to get information from the OPES dispatcher to the > application module. Oh, that's perfectly fine. I was only talking about the tracing impact on OCP. Other protocols or interfaces may have different models, of course. > > > - session related. The session knowledge may be not directly > > > supported by the protocol, as the case is for HTTP. In this > > > situation OPES processor is responsible for keeping the > > > session context. Session related information may be provided > > > once per session, some details may be replaced by id or a > > > reference for subsequent information retrieval. > > > > > > Session level data must be preserved for the duration of > > > the session. OPES processor is responsible for inserting > > > notifications if session-level information changes. > > > > > > Examples of session-related information is "virus checker > > > abcd build 123 enabled", "OPES server id=xyz present". > > > > I am not convinced we have to support these kind of tracing. The end > > does not usually care whether "virus checker abcd build 123 is > > enabled"; it cares only wether that virus checker has seen or modified > > the application message, which is already covered by "message-related" > > bullet above. Same for "OPES server id=xyz present". > > Taking virus checker as an example I can see two situations when > detailed information is important. The end user might wish to verify > virus checker signature and certificate. Very reasonable thing to do > if one is going to rely on the "check passed" notification. Another > possibility is a second OPES processor with a virus checker present > in the OPES flow. When signed as "passed" message reaches this > second processor it may be interested not only in the first virus > checker credentials but also in type and version information - in > order to adopt it's actions. I agree! However, I think this information should be transmitted on a per-message basis because the application protocol we care about most (HTTP) does not have sessions. Not sure about SMTP. > > What is a session? What are session boundaries? How do those > > boundaries correspond to message/connection boundaries? And, finally, > > why should we care about anything that does not affect our application > > message? > > I do not have a "standard" session definition at hand, so for our > purposes I'd define session as an application dependent persistent > context that propagates certain parameters to all messages belonging > to that session. In this sense session notion does affect our > application messages: if there was a specific OPES application > participating in the session its credentials and functional > abilities extend to all messages within that session. Reintroducing > and re-verifying complete list of all participating OPES servers' > credentials, settings and functional capabilities with each message > may have a serious performance impact. I agree. However, HTTP does not have sessions. Nothing in HTTP "propagates certain parameters to all messages belonging to X" because HTTP messages do not belong to any end-to-end X. The closest you can come is an HTTP persistent connection, but since it is hop-by-hop, it cannot be used as a session. > > > - server related persistent information, e.g. "OPES center of > > > authority ", "privacy policy ". It may be also > > > presented once per session and it does not change between > > > sessions. > > > > This has to be per-message unless you somehow can define sessions so > > that the end-user can distinguish them. For example, two pipelined > > HTTP request on the same TCP connection (from end-user point of view) > > may pass through very different OPES intermediaries and reach > > different content providers. How are you going to maintain sessions if > > not on a per-message basis (which makes session concept unnecessary)? > > Please give an example of a session in this context. > > Let's say a series of requests from the same user to the same site. > It is application dependent, so I'd live determination of the session > boundaries to the application. This creates a possibility that different > participants may define session differently, but a) they may add a session > id or use the existing one (application defined), b) they may do certain > thing that are safe even if session context is lost, e.g. put unique > identifiers instead of descriptions. If end user lost related description > he/she may just send a kind of whois request for that identifier. > > I do not understand your statement about two requests in the same > connection passing through different OPES server to different content > providers. My understanding was that the requirement of explicit > IP exposure and per-hop connection termination prevents such situations. > Please explain. Yes, that statement is in the core of our disagreement. Here is an example: - Client issues two requests A and B. Both requests are pipelined on the same HTTP/TCP connection to client-side proxy P0. The requests may be to the same origin server, but do not have to be. - Proxy P0 reads both requests and sends them off using two HTTP/TCP connections: request A is forwarded to proxy PA, and request B is forwarded to proxy PB. There are many reasons to "split" two requests: caching, processing rules, peering relationships, etc. - Both proxy PA and PB have OPES processors. Processors belong to different OPES systems, with different privacy policies, etc. Each forwards the request its origin server. It is not possible to establish a real "session" between a client and proxy PA because the client would not be able to distinguish that session from the "session" established by proxy PB. Moreover, the same request A sent 5 seconds later may go to PB and not PA (perhaps P0 load balances or whatever). The only option to maintain session information is to send some kind of session ID with every response so that the client can distinguish sessions on a per-message basis and maintain its own session state. This becomes not a session but rather a "temporary alias" optimization: first message: OPES-Agent-Details: a very long header ... (id=1231) next messages: OPES-Agent-Details: see info with id 1231, if you still have it Is that something you are after? > Knowledge of information persistence permits replacement of detailed > data ( which is required for volatile information) by references. > Sure server URI is an object better defined than a session. We may > further clarify what kind of persistency should be taken into > consideration, but considering all information as volatile > (per-message) looks like too strong simplification. "replacement of detailed data by references" smells like a OPES-Agent-Details example above. I would not call it a session-based approach. This is more like caching or temporary aliasing. If that is something you are after, perhaps we can rename it to avoid "session" confusion? > > > 3. Some terminology. > > > > > > > Can we develop a few example scenarios that illustrate the various > > > > concepts of "information points", "reference points", "identifier", > > > > > > - REFERENCE POINT - a reference that may be used out-of-band to > > > perform a specific function. > > > > > > An example may be URI for the privacy policy, center of authority > > > URI, server address, etc. Usually no protocol is provided to access > > > the reference point. > > > > If reference point is a URI (and it probably should be), then the > > schema part of the URI (e.g., "http") usually determines ways to > > access the information. > > > > > - INFORMATION POINT - implies presence of the protocol to access > > > detailed information at this point. Example may be URI to get > > > a certificate for virus checker or content filter, examine > > > and set profile setting and active preferences. > > > > I see no difference with the "REFERENCE POINT". The protocol > > distinction is too vague. Can you give a reference point example that > > lacks protocol? Do we need to distinguish the two points? > > abuse@ad-insertion.com looks for me as a reference point. The main > difference is presence of a programmatic facility for information > retrieval. Such facility permits to remove from the protocol detailed > information even if this information may be needed by the > participating applications. To me, abuse@ad-insertion.com implies SMTP (e-mail) protocol to access the information so it becomes an INFORMATION POINT. I can send an e-mail and expect an automated or personal response with more info. I guess we can ignore this confusion until the difference between REFERENCE and INFORMATION POINTs becomes clear or important. Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 3 15:38:02 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12656 for ; Thu, 3 Apr 2003 15:38:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33KScJM008670 for ; Thu, 3 Apr 2003 12:28:38 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33KSc1u008669 for ietf-openproxy-bks; Thu, 3 Apr 2003 12:28:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33KSaJM008664 for ; Thu, 3 Apr 2003 12:28:36 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h33KScvj037981; Thu, 3 Apr 2003 13:28:38 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h33KSc4n037980; Thu, 3 Apr 2003 13:28:38 -0700 (MST) (envelope-from rousskov) Date: Thu, 3 Apr 2003 13:28:38 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Comments on ocp-00 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E74@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E74@zsc3c026.us.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: On Thu, 3 Apr 2003, Reinaldo Penno wrote: > I liked your summary. I guess we should wait for other opinions. Agreed. > Okay, how I write the capability negotiation part? You will see some placeholders in the 00 draft to support negotiation (message "do-you-support" and below). You can wipe those clean or fill the blanks, whatever works best for you. If at all possible, please use XML sources rather than text or HTML rendering. You will find more-or-less current sources and instructions at http://www.measurement-factory.com/tmp/opes/ Let me know if you have any questions, concerns, or suggestions about the sources or editing process. Thank you, Alex. > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Thursday, April 03, 2003 12:44 PM > > To: OPES Group > > Subject: RE: Comments on ocp-00 > > > > > > > > Here is a short summary of the pending issues on this thread. > > > > a) OPES processor may be able to pre-process application > > messages (e.g., extract payload). Callout servers > > may be able to handle various kinds of application > > data (e.g., complete HTTP messages versus MIME-encoded > > payload). Thus, somebody needs to tell OPES processor > > and callout server what is an "application message" > > definition that they should both use during OCP > > communications. Should OCP support auto-negotiation or > > rely on out-of-band (e.g., manual) configuration? > > > > b) Do we really need a special "error" flag to say > > "rally bad error; you should probably wipe out all > > related state". Or can we assign the same side-effect > > to some of the result codes? > > > > c) OPES processor can be [a part of] an application-level > > proxy. Can OPES processor be a transport-level gateway > > too? For example, can OPES processor manipulate with > > raw TCP packets and care about things like > > retransmissions and ACKs? > > > > d) If a fragment of an application message is lost, > > [how] should OPES processor signal that to the callout > > server? A loss can happen when adapting lossy application > > protocols. > > > > e) Do we need to group processing of a single application > > message together using OCP transaction concept? Should > > OCP transaction mean something else? Do we need OCP > > transactions at all? From owner-ietf-openproxy@mail.imc.org Thu Apr 3 16:26:39 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14856 for ; Thu, 3 Apr 2003 16:26:38 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33LGqJM014733 for ; Thu, 3 Apr 2003 13:16:52 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33LGqua014732 for ietf-openproxy-bks; Thu, 3 Apr 2003 13:16:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33LGmJM014717 for ; Thu, 3 Apr 2003 13:16:48 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <20030403211643052003jfrfe>; Thu, 3 Apr 2003 21:16:43 +0000 From: "Oskar Batuner" To: "OPES Group" Subject: RE: Need to look at tracing and debuggig Date: Thu, 3 Apr 2003 16:16:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Thursday, April 03, 2003 12:33 AM > To: OPES Group > Subject: RE: Need to look at tracing and debuggig > > > > Oskar, > > It looks like our disagreements are not as deep as I > originally thought. I agree with most of your latest comments. > > Indeed, we should be careful about distinguishing a content > provider system and a 3rd party system operating under content > provider permission. I was pushing for treating any system as a single > entity once the message leaves that system. You are saying that there > are at least three kinds of systems: content providers, end users with > their proxies, and 3rd party services like CDNs. I agree, as long as > we can treat a 3rd party service as a single entity once the message > leaves that service. > > How about starting with the following simple set of > unpolished rules: > > 1. An OPES processor SHOULD add its identification > to the trace. The OPES processor is the only entity that is always present, so if there is a MUST - it is here. On another hand if OPES processor belongs to the content producer trust domain (and in fact is an integral part of the origin) - why should it be exposed? I'd say MUST unless it belongs to the content producer trust domain and is covered by the appropriate privacy policies and other regulations (TBD). > > 2. An OPES processor SHOULD add to the trace > identification of every callout service that received > the application message. Unless those callout processors belong to the same trust domain and covered by the same policies. > > 3. An OPES processor MUST add to the trace identification > of the "system/entity" it belongs to. "System" > ID MUST make it possible to access "system" privacy > policy. "system/entity" is not well defined, it is absent in the architecture. I'd put more stress on OPES processor as a traceable entity. We may introduce "system" (TBD), but it is a MAY. The second sentence belongs to paragraph 1. > > 4. An OPES processor MAY group the above information > (items 1-3) for sequential trace entries having > the same "system/entity" ID. In other words, trace > entries produced within the same "system/entity" > MAY be merged/aggregated into a single less detailed > trace entry. Agreed. > > 5. An OPES processor MAY delegate trace management to > a callout service within the same "system/entity". I'm not sure what do you mean by delegate here. If this means that tracing information is inserted by callout processors according to the OPES processor instructions and under its supervision - OK, but in this case the exact point of trace info insertion is not essential. If you mean delegation of authority - this does not look right. I'd set two types of requirements. First one is requirement to identify the OPES flow participant. It will be covered by rules 1-3 (or whatever they will be transformed to). Second set of requirements should state what kind of tracing information MUST/SHOULD/MAY be inserted. > > We need to agree on what an "identifier" in items 1-3 represents and > how trace entries are encoded (the latter is application-specific). > > Overall, do the above 5 items sound reasonable at all? Are there any > huge gaps they do not cover? (I think I know of one hole, but would > prefer to hear others' comments before diving any deeper) In general your practical approach to building a tracing framework is very reasonable. Items may look a little different. Oskar From owner-ietf-openproxy@mail.imc.org Thu Apr 3 17:24:29 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17304 for ; Thu, 3 Apr 2003 17:24:27 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33MESJM017678 for ; Thu, 3 Apr 2003 14:14:28 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33MESm0017677 for ietf-openproxy-bks; Thu, 3 Apr 2003 14:14:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33MEQJM017673 for ; Thu, 3 Apr 2003 14:14:26 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h33MESvj040572; Thu, 3 Apr 2003 15:14:28 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h33MESHA040571; Thu, 3 Apr 2003 15:14:28 -0700 (MST) (envelope-from rousskov) Date: Thu, 3 Apr 2003 15:14:28 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Need to look at tracing and debuggig In-Reply-To: Message-ID: References: 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: On Thu, 3 Apr 2003, Oskar Batuner wrote: > > 1. An OPES processor SHOULD add its identification > > to the trace. > > The OPES processor is the only entity that is always present, so if > there is a MUST - it is here. I used a SHOULD because rule 3 is a MUST. The idea is that OPES processor must/should/may include several pieces of tracing information. The processor ID is a SHOULD because that information is not required by IAB and is not very useful for agents outside of the "system". Rule 3 is a MUST because IAB requires that privacy policy is known. In other words, knowing individual OPES processors benefits only the "system" admins and is not really important to others. It is a SHOULD. Knowing privacy policy and "system" in charge is important to the other "end" and is a MUST, the only MUST. > On another hand if OPES processor belongs to the content producer > trust domain (and in fact is an integral part of the origin) - why > should it be exposed? > > I'd say MUST unless it belongs to the content producer trust domain > and is covered by the appropriate privacy policies and other > regulations (TBD). I agree with the intent -- outside agents only care about the whole "system" identification and policies, not its individual components. On the other hand, "system" admins may need more detailed trace. My solution to the problem was rule 4 which is designed to give "system" admins full control over how the system looks to the "outside" world. In other words, what is added by individual OPES processors can be aggregated (i.e., partially removed) by the "system" as a whole. > > 2. An OPES processor SHOULD add to the trace > > identification of every callout service that received > > the application message. > > Unless those callout processors belong to the same trust domain > and covered by the same policies. See above. I wanted to avoid repeating "unless, ..." for every rule. That is why I added rule 4: What is added can be removed by the same or other agents within the same "system". > > 3. An OPES processor MUST add to the trace identification > > of the "system/entity" it belongs to. > > "system/entity" is not well defined, it is absent in the > architecture. I'd put more stress on OPES processor as a traceable > entity. We may introduce "system" (TBD), but it is a MAY. Yes, the "system/entity" needs to be defined. If we manage to define it, I think it will keep the rules much simpler. Here is my reasoning: The architecture draft talks about OPES processors and trust domains. OPES processor is too low-level entity in this context because you have to add "... unless the processor belongs to the same ..." exceptions to every rule. The "trust domain" is too high-level entity in this context because a single trust domain may include several systems with different privacy policies and we MUST identify every applicable policy in the trace. As you have pointed out previously, there are more than two players here; there can be only two trust domains. Trust domains are based on delegation of authority. We need something based on the authority itself and its privacy policy. Actually, the architecture draft does use "entity" (i.e., "system") term without defining it! See section 3.1, "Trust Domains": The delegation of authority starts at either a data consumer or data provider and moves to more distant entities in a "stepwise" fashion. Stepwise means A delegates to B and B delegates to C and so forth. The entities thus "colored" by the delegation are said to form a trust domain The entity in the above wording is probably my "system". How about defining an "OPES system" in this context as a "logical group of OPES entities operating under the same authority and using the same privacy policy"? Will such a definition work for our purposes? Any better ideas? > > "System" > > ID MUST make it possible to access "system" privacy > > policy. > > The second sentence belongs to paragraph 1. Or, better, a separate rule. > > 4. An OPES processor MAY group the above information > > (items 1-3) for sequential trace entries having > > the same "system/entity" ID. In other words, trace > > entries produced within the same "system/entity" > > MAY be merged/aggregated into a single less detailed > > trace entry. > > Agreed. > > > > > 5. An OPES processor MAY delegate trace management to > > a callout service within the same "system/entity". > > I'm not sure what do you mean by delegate here. If this means > that tracing information is inserted by callout processors > according to the OPES processor instructions and under its > supervision - OK, but in this case the exact point of trace > info insertion is not essential. Yes, that is what I meant. Yes, it is not essential in this context. I was just trying to address concerns that sometimes it is better for a callout service (and not the OPES processor) to add tracing information. > If you mean delegation of authority - this does not look right. No, I do not. > I'd set two types of requirements. First one is requirement to > identify the OPES flow participant. It will be covered by rules > 1-3 (or whatever they will be transformed to). Second set of > requirements should state what kind of tracing information > MUST/SHOULD/MAY be inserted. Sounds good to me. - Identify traceable entities (definitions, not requirements) - Document trace entries (definitions, not requirements) - Document who MUST/SHOULD/MAY insert what (requirements) Most of already proposed rules fall into the last category. I think we almost agree regarding what is traceable (OPES processor, applied services, and system authority and/or policy). We need to define "system" (or rewrite the rules without it) and agree what the trace entries should look like. Alex. From owner-ietf-openproxy@mail.imc.org Fri Apr 4 05:19:02 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13170 for ; Fri, 4 Apr 2003 05:19:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h349oHJM010202 for ; Fri, 4 Apr 2003 01:50:17 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h349oHpF010201 for ietf-openproxy-bks; Fri, 4 Apr 2003 01:50:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.9/8.11.6) with SMTP id h349oEJM010157 for ; Fri, 4 Apr 2003 01:50:15 -0800 (PST) Received: from hermes.webwasher.com [192.168.1.3] id 60CNSKVY; 04 Apr 2003 11:50:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on ocp-00 Date: Fri, 4 Apr 2003 11:46:47 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02EF54CA4@hermes.webwasher.com> Thread-Topic: Comments on ocp-00 Thread-Index: AcL6DiCR0v6jThKvRr+n4ZElBTU2GgAeZ6LQ From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h349oGJM010194 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, here are my 2 euro cents: > > > Here is a short summary of the pending issues on this thread. > > a) OPES processor may be able to pre-process application > messages (e.g., extract payload). Callout servers > may be able to handle various kinds of application > data (e.g., complete HTTP messages versus MIME-encoded > payload). Thus, somebody needs to tell OPES processor > and callout server what is an "application message" > definition that they should both use during OCP > communications. Should OCP support auto-negotiation or > rely on out-of-band (e.g., manual) configuration? I am very much undecided what I like better. On one hand I completly follow your arguments that some callout services like virus scanners would prefer application messages that are generic and not bound to a protocol like HTTP or SMTP; it's definitly great if an OPES processor can work on a new application protocol but use existing callout services that handle the data without understanding the new application protocol. On the other hand I experienced that at some time the callout service better had the original application message; sticking with the virus scanner example: One year ago a malformed email project has been started; it is important to correctly handle also malformed mime section for a good virus protection. A virus scanner may want to include a best-of-breed solution for this and not bank on the pre-process implementation in various OPES processors. These could be arguments for an auto-negatiations checking which side has which capabilities and application protocol knowledge. But I am very much concerned that this will become an inter- operability nightmare. How about this: We discussed that we probably end with multiple application protocol bindings of the OCP. One application protocol binding could be a generic binding which is not really related to any Internet protocol but handles data as if it was a file on disk. Application messages could have a very simple and generic format here. Many callout services may want to support this protocol binding and an OPES processor may have pre-processing code to translate Internet protocol data to that simple format. Other protocol bindings will handle native HTTP and SMTP messages. Every application protocol binding defines a fixed application message format. Negotiations between OPES processors and callout services is then limited to exchange supported application protocol bindings. > > b) Do we really need a special "error" flag to say > "rally bad error; you should probably wipe out all > related state". Or can we assign the same side-effect > to some of the result codes? > > c) OPES processor can be [a part of] an application-level > proxy. Can OPES processor be a transport-level gateway > too? For example, can OPES processor manipulate with > raw TCP packets and care about things like > retransmissions and ACKs? I think we should concentrate on the application layer only. If it later turns out that OCP can also be handled on the transport layer fine but it should not restrict any protocol features now. > > d) If a fragment of an application message is lost, > [how] should OPES processor signal that to the callout > server? A loss can happen when adapting lossy application > protocols. > > e) Do we need to group processing of a single application > message together using OCP transaction concept? Should > OCP transaction mean something else? Do we need OCP > transactions at all? Yes, I think so. In most cases not more than one application message will be transferred from CLIENT to SERVER and back within a transaction. But we have two examples where multiple messages make sense: 1. Allowing the SERVER to return different SMTP messages for one email to multiple recipients it received from the CLIENT. 2. Pre-processing of a message at CLIENT which results in multiple application messages, e.g. MIME sections of an email to be transferred as multiple application messages The first case requires to have the messages being wrapped into a single transaction. The second case could benefit from a transaction wrapping because the SERVER may want to know which MIME sections belong together. I agree with Alex that the transaction overhead could (and should) be limited to a minimum so that no additional transpart layer packet is needed. For the normal case the xaction-start app-message-start couple could almost look like a single message I think. But let's keep the xaction-start message two allow support of above cases. Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Apr 4 05:42:29 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13562 for ; Fri, 4 Apr 2003 05:42:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34AYaJM014042 for ; Fri, 4 Apr 2003 02:34:36 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34AYaAD014041 for ietf-openproxy-bks; Fri, 4 Apr 2003 02:34:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.9/8.11.6) with SMTP id h34AYYJM014031 for ; Fri, 4 Apr 2003 02:34:34 -0800 (PST) Received: from hermes.webwasher.com [192.168.1.3] id XQSA9JRB; 04 Apr 2003 12:34:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: More comments on ocp-00 Date: Fri, 4 Apr 2003 12:31:10 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02EF54CA5@hermes.webwasher.com> Thread-Topic: More comments on ocp-00 Thread-Index: AcL6lcUtc3OkH+FmSreDWoOzMy7p9g== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h34AYZJM014037 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit First of all: Good work Alex! I think this draft covers pretty well what has been discussed on the list so far. I vote for turning a later version of this document into a WG draft. - The sentence "A SERVER MUST NOT send this message" should also be added to the connection-service message and maybe also to connection-priority - I am not sure whether the ability to change the service with connection-service and within xaction-start is really needed. It increases the implementation requirements for a callout server but is it really needed? Setting a service will usually also mean to negotiate further parameters. Couldn't we just put this into connection-start? Using different services will then mean to start different connections. Isn't this just ok? - I forget about the motivation of the "ack" flag and data-ack messsage. I thought we wanted to have this done by the transport layer binding. Can you point me to the thread in which this has been discussed? - Isn't there a problem with data-pause? If the SERVER sends data-pause to the CLIENT, the CLIENT MUST stop sending but before the CLIENT receives and processes this message it may already have sent additional data-have messages. The SERVER will then receive unexpected data any MAY abort. Second problem: A CLIENT may not be able to pause as long as the server likes it to pause. If it is not able to keep a copy of the complete message and if it is not be able to pause the origin server for the same time, it may easily run into an internal buffer overflow problem. How about defining that data-pause MUST NOT be send by the SERVER but adding a new message data-pause-request which is only to be sent by the SERVER. Upon receiving this message the CLIENT MAY pause by sending data-pause to the SERVER. Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Apr 4 11:31:30 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28419 for ; Fri, 4 Apr 2003 11:31:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34GJAJM018583 for ; Fri, 4 Apr 2003 08:19:10 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34GJ9VM018582 for ietf-openproxy-bks; Fri, 4 Apr 2003 08:19:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h34GJ8JM018578 for ; Fri, 4 Apr 2003 08:19:08 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h34GJAvj066375; Fri, 4 Apr 2003 09:19:10 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h34GJ9Jw066374; Fri, 4 Apr 2003 09:19:09 -0700 (MST) (envelope-from rousskov) Date: Fri, 4 Apr 2003 09:19:09 -0700 (MST) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: Comments on ocp-00 In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CA5@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CA5@hermes.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: On Fri, 4 Apr 2003, Martin Stecher wrote: > > a) Thus, somebody needs to tell OPES processor > > and callout server what is an "application message" > > definition that they should both use during OCP > > communications. Should OCP support auto-negotiation or > > rely on out-of-band (e.g., manual) configuration? > > How about this: > We discussed that we probably end with multiple application > protocol bindings of the OCP. One application protocol binding > could be a generic binding which is not really related to any > Internet protocol but handles data as if it was a file on disk. > Application messages could have a very simple and generic format > here. Many callout services may want to support this protocol > binding and an OPES processor may have pre-processing code to > translate Internet protocol data to that simple format. > Other protocol bindings will handle native HTTP and SMTP messages. > Every application protocol binding defines a fixed application > message format. I think both Reinaldo Penno and myself want a scheme very similar to what you described above. There will be a set of supported application protocols and message encodings. Known message "formats" will be documented. OPES agents will support some subset of them. It is probably a good idea to document a scheme where OCP sees only message payloads and is unaware of the actual application protocol (still, one would need to agree on things like payload encoding). > Negotiations between OPES processors and callout services is then > limited to exchange supported application protocol bindings. This is the only uncertain area. You are, essentially, voting for supporting auto-negotiations (over a finite set of known protocols/encodings, of course). If nobody objects to this automation, OCP will implement auto-negotiation. My understanding is that Reinaldo is already working on specific messages to handle that. > > e) Do we need to group processing of a single application > > message together using OCP transaction concept? Should > > OCP transaction mean something else? Do we need OCP > > transactions at all? > > Yes, I think so. > In most cases not more than one application message will be > transferred from CLIENT to SERVER and back within a transaction. > But we have two examples where multiple messages make sense: > 1. Allowing the SERVER to return different SMTP messages for > one email to multiple recipients it received from the CLIENT. > 2. Pre-processing of a message at CLIENT which results in > multiple application messages, e.g. MIME sections of an email > to be transferred as multiple application messages > > The first case requires to have the messages being wrapped into > a single transaction. > The second case could benefit from a transaction wrapping > because the SERVER may want to know which MIME sections belong > together. The current draft does not support the second case in a situation where both cases happen at the same time (e.g., multiple responses to a pre-processed message part). This combination can be supported within one OCP transaction only if server responses specify which pre-processed application message [part] they are adapting. That is, an app-message-start message from a callout server will have to include a second am-id parameter, carrying the am-id of the corresponding application message part from the processor. While possible, this defeats the purpose of having an OCP transaction -- since all server responses have to carry two am-ids, the transaction wrapping is useless for anything other than aborting the whole thing with one message. I think the second case must be supported by generating multiple (possibly interleaved) OCP transactions, one for each pre-processed part. The overhead, if any, will be minimal, and the only missing functionality would be an ability to abort all parts with one message. We can add 'xaction-ends' to support the latter if needed. > I agree with Alex that the transaction overhead could (and should) > be limited to a minimum so that no additional transport layer packet > is needed. For the normal case the xaction-start app-message-start > couple could almost look like a single message I think. > But let's keep the xaction-start message two allow support of above > cases. Yes, there is not much difference between parsing two simple messages with 1 attribute and one complex message with 2 attributes. > - The sentence "A SERVER MUST NOT send this message" should also > be added to the connection-service message and maybe also to > connection-priority Ack. > - I am not sure whether the ability to change the service with > connection-service and within xaction-start is really needed. > It increases the implementation requirements for a callout > server but is it really needed? > Setting a service will usually also mean to negotiate further > parameters. > Couldn't we just put this into connection-start? > Using different services will then mean to start different > connections. Isn't this just ok? Yeah, that will work. The rationale was that you can use the connection to specify common/default services and then overwrite that on a transaction basis. You make a good point regarding associated negotiations though. Will add this question to the to-do list. The answer will probably depend on what kind of negotiations we would end up supporting. > - I forget about the motivation of the "ack" flag and data-ack > messsage. I thought we wanted to have this done by the > transport layer binding. Can you point me to the thread in > which this has been discussed? Ack/Data-ack sequence is useful if one side wants to track (or debug) progress in receiving/parsing OCP messages on the other side. Perhaps OPES processor can optimize its buffer management by knowing how fast the callout server is reading the data. Do you think that enough motivation to support the ack/data-ack pair? > - Isn't there a problem with data-pause? > If the SERVER sends data-pause to the CLIENT, the CLIENT > MUST stop sending but before the CLIENT receives and > processes this message it may already have sent additional > data-have messages. The SERVER will then receive unexpected > data any MAY abort. Indeed. I've added the "MAY abort" part at the last minute and missed the bug. Will fix. > Second problem: A CLIENT may not be able to pause as long > as the server likes it to pause. If it is not able to keep > a copy of the complete message and if it is not be able to > pause the origin server for the same time, it may easily run > into an internal buffer overflow problem. I do not think that can happen because the CLIENT can always stop reading incoming data if it has no place to put it. Right? There is a deadlock problem, however (see the "copying commitment and deadlock" thread on this list). That problem is on the to-do list. > How about defining that data-pause MUST NOT be send by the > SERVER but adding a new message data-pause-request which is > only to be sent by the SERVER. Upon receiving this message > the CLIENT MAY pause by sending data-pause to the SERVER. The above logic is what data-pause from the SERVER was supposed to mean. We can fix the current definition or use data-pause-request instead. Will fix. Thanks a lot for the comments, Alex. From owner-ietf-openproxy@mail.imc.org Fri Apr 4 14:57:43 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04878 for ; Fri, 4 Apr 2003 14:57:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34JihJM027413 for ; Fri, 4 Apr 2003 11:44:43 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34JihAj027412 for ietf-openproxy-bks; Fri, 4 Apr 2003 11:44:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34JigJM027406 for ; Fri, 4 Apr 2003 11:44:42 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34JiUR21166; Fri, 4 Apr 2003 11:44:30 -0800 (PST) Received: from zsc3c026.us.nortel.com ([47.81.138.26]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2FGBXAZD; Fri, 4 Apr 2003 11:44:30 -0800 Received: from desktop (artpt5v1.us.nortel.com [47.140.53.30]) by zsc3c026.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2GHBK600; Fri, 4 Apr 2003 11:44:29 -0800 Message-ID: <008501c2fae2$a0378060$94368c2f@desktop> X-Sybari-Space: 00000000 00000000 00000000 From: "Reinaldo" To: "Alex Rousskov" , "OPES WG \(E-mail\)" References: <72992B39BBD9294BB636A960E89AE02EF54CA5@hermes.webwasher.com> Subject: Re: Comments on ocp-00 Date: Fri, 4 Apr 2003 14:44:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Alex Rousskov" To: "OPES WG (E-mail)" Sent: Friday, April 04, 2003 11:19 AM Subject: RE: Comments on ocp-00 > > > On Fri, 4 Apr 2003, Martin Stecher wrote: > > > > a) Thus, somebody needs to tell OPES processor > > > and callout server what is an "application message" > > > definition that they should both use during OCP > > > communications. Should OCP support auto-negotiation or > > > rely on out-of-band (e.g., manual) configuration? > > > > How about this: > > We discussed that we probably end with multiple application > > protocol bindings of the OCP. One application protocol binding > > could be a generic binding which is not really related to any > > Internet protocol but handles data as if it was a file on disk. > > Application messages could have a very simple and generic format > > here. Many callout services may want to support this protocol > > binding and an OPES processor may have pre-processing code to > > translate Internet protocol data to that simple format. > > Other protocol bindings will handle native HTTP and SMTP messages. > > Every application protocol binding defines a fixed application > > message format. > > I think both Reinaldo Penno and myself want a scheme very similar to > what you described above. There will be a set of supported application > protocols and message encodings. Known message "formats" will be > documented. OPES agents will support some subset of them. It is > probably a good idea to document a scheme where OCP sees only message > payloads and is unaware of the actual application protocol (still, one > would need to agree on things like payload encoding). > > > Negotiations between OPES processors and callout services is then > > limited to exchange supported application protocol bindings. > > This is the only uncertain area. You are, essentially, voting for > supporting auto-negotiations (over a finite set of known > protocols/encodings, of course). If nobody objects to this automation, > OCP will implement auto-negotiation. My understanding is that Reinaldo > is already working on specific messages to handle that. Folks, Are we talking about the same thing? This is already a MUST on the requirements draft. We have several parameters that need to be negotiated that have (a priori) nothing to do with the application protocol/bindings OCP will be carrying. They are go from basic things like version number to performance, security, etc. " Capabilities and parameters that could be negotiated between an OPES processor and a callout server include (but are not limited to): callout protocol version, fail-over behavior, heartbeat rate for keep-alive messages, security-related parameters etc. " and yeah, I'm already working on that... thanks, Reinaldo My statements > > > > e) Do we need to group processing of a single application > > > message together using OCP transaction concept? Should > > > OCP transaction mean something else? Do we need OCP > > > transactions at all? > > > > Yes, I think so. > > In most cases not more than one application message will be > > transferred from CLIENT to SERVER and back within a transaction. > > But we have two examples where multiple messages make sense: > > 1. Allowing the SERVER to return different SMTP messages for > > one email to multiple recipients it received from the CLIENT. > > 2. Pre-processing of a message at CLIENT which results in > > multiple application messages, e.g. MIME sections of an email > > to be transferred as multiple application messages > > > > The first case requires to have the messages being wrapped into > > a single transaction. > > The second case could benefit from a transaction wrapping > > because the SERVER may want to know which MIME sections belong > > together. > > The current draft does not support the second case in a situation where > both cases happen at the same time (e.g., multiple responses to a > pre-processed message part). This combination can be supported within one > OCP transaction only if server responses specify which pre-processed > application message [part] they are adapting. That is, an > app-message-start message from a callout server will have to include a > second am-id parameter, carrying the am-id of the corresponding > application message part from the processor. While possible, this > defeats the purpose of having an OCP transaction -- since all server > responses have to carry two am-ids, the transaction wrapping is useless > for anything other than aborting the whole thing with one message. > > I think the second case must be supported by generating multiple > (possibly interleaved) OCP transactions, one for each pre-processed part. > The overhead, if any, will be minimal, and the only missing > functionality would be an ability to abort all parts with one message. We > can add 'xaction-ends' to support the latter if needed. > > > I agree with Alex that the transaction overhead could (and should) > > be limited to a minimum so that no additional transport layer packet > > is needed. For the normal case the xaction-start app-message-start > > couple could almost look like a single message I think. > > But let's keep the xaction-start message two allow support of above > > cases. > > Yes, there is not much difference between parsing two simple messages > with 1 attribute and one complex message with 2 attributes. > > > - The sentence "A SERVER MUST NOT send this message" should also > > be added to the connection-service message and maybe also to > > connection-priority > > Ack. > > > - I am not sure whether the ability to change the service with > > connection-service and within xaction-start is really needed. > > It increases the implementation requirements for a callout > > server but is it really needed? > > Setting a service will usually also mean to negotiate further > > parameters. > > Couldn't we just put this into connection-start? > > Using different services will then mean to start different > > connections. Isn't this just ok? > > Yeah, that will work. The rationale was that you can use the > connection to specify common/default services and then overwrite that > on a transaction basis. You make a good point regarding associated > negotiations though. Will add this question to the to-do list. The > answer will probably depend on what kind of negotiations we would end > up supporting. > > > - I forget about the motivation of the "ack" flag and data-ack > > messsage. I thought we wanted to have this done by the > > transport layer binding. Can you point me to the thread in > > which this has been discussed? > > Ack/Data-ack sequence is useful if one side wants to track (or debug) > progress in receiving/parsing OCP messages on the other side. Perhaps > OPES processor can optimize its buffer management by knowing how fast > the callout server is reading the data. Do you think that enough > motivation to support the ack/data-ack pair? > > > - Isn't there a problem with data-pause? > > If the SERVER sends data-pause to the CLIENT, the CLIENT > > MUST stop sending but before the CLIENT receives and > > processes this message it may already have sent additional > > data-have messages. The SERVER will then receive unexpected > > data any MAY abort. > > Indeed. I've added the "MAY abort" part at the last minute and > missed the bug. Will fix. > > > Second problem: A CLIENT may not be able to pause as long > > as the server likes it to pause. If it is not able to keep > > a copy of the complete message and if it is not be able to > > pause the origin server for the same time, it may easily run > > into an internal buffer overflow problem. > > I do not think that can happen because the CLIENT can always stop > reading incoming data if it has no place to put it. Right? > > There is a deadlock problem, however (see the "copying commitment and > deadlock" thread on this list). That problem is on the to-do list. > > > How about defining that data-pause MUST NOT be send by the > > SERVER but adding a new message data-pause-request which is > > only to be sent by the SERVER. Upon receiving this message > > the CLIENT MAY pause by sending data-pause to the SERVER. > > The above logic is what data-pause from the SERVER was supposed to mean. > We can fix the current definition or use data-pause-request instead. > Will fix. > > > Thanks a lot for the comments, > > Alex. > > > From owner-ietf-openproxy@mail.imc.org Sat Apr 5 01:48:05 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20048 for ; Sat, 5 Apr 2003 01:48:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h356bSJM027651 for ; Fri, 4 Apr 2003 22:37:28 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h356bS55027650 for ietf-openproxy-bks; Fri, 4 Apr 2003 22:37:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h356bRJM027646 for ; Fri, 4 Apr 2003 22:37:27 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h356bVvj087540 for ; Fri, 4 Apr 2003 23:37:31 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h356bV0k087539; Fri, 4 Apr 2003 23:37:31 -0700 (MST) (envelope-from rousskov) Date: Fri, 4 Apr 2003 23:37:31 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: OCP version head_sid2 available Message-ID: 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: To the best of my knowledge, all specific OCP comments that caused no further objections/questions are now applied to the draft. I also made a few additions/improvements. The [major] change log is quoted below. The latest snapshot, including XML sources for those doing hands-on modifications, is available at http://www.measurement-factory.com/tmp/opes/ Please continue to comment and work on the to-do list. I am especially interested in feedback regarding the new meta-data approach (see change log). Thank you, Alex. -------------- change log ---------------- Appendix A. Change Log <155> <156> o introduced a notion of meta-data to both simplify OCP and make OCP agnostic to application meta-data; previous approach essentially assumed existence of a few common properties like protocol name or application message source/destination while not allowing any other properties to be exchanged between OCP agents); specific meta-data format/contents is not important to OCP but OCP will help agents to negotiate that format/contents <157> o removed wording implying that OCP adapts application messages; OCP only used to exchange data and meta-data (which facilitates adaptation) <158> o changed most of the definitions; added definitions for meta-data, original/adapted flows, and others <159> o split 'data-pause' message into 'data-pause' request by the callout server and 'data-paused' notification by the OPES processor; fixed "paused" state management <160> o added motivation for data acking mechanism <161> o replaced "am-proto", "am-kind", "am-source", and "am-destination" parameters with "meta-data" <162> o replaced SERVER and CLIENT placeholders with "callout server" and "OPES processor" <163> o added editing marks From owner-ietf-openproxy@mail.imc.org Sat Apr 5 11:48:20 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10748 for ; Sat, 5 Apr 2003 11:48:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35GbiJM021355 for ; Sat, 5 Apr 2003 08:37:44 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35Gbig8021354 for ietf-openproxy-bks; Sat, 5 Apr 2003 08:37:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35GbgJM021349 for ; Sat, 5 Apr 2003 08:37:42 -0800 (PST) Received: from f07a-6-160.d1.club-internet.fr ([212.194.149.160] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 191qfj-0002JL-00 for ietf-openproxy@imc.org; Sat, 05 Apr 2003 08:37:40 -0800 Message-Id: <5.2.0.9.0.20030405143401.00ac6d50@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 05 Apr 2003 14:59:48 +0200 To: ietf-openproxy@imc.org From: jfcm Subject: a question ONES again? In-Reply-To: <008501c2fae2$a0378060$94368c2f@desktop> References: <72992B39BBD9294BB636A960E89AE02EF54CA5@hermes.webwasher.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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I went through a very interesting real life "something" which very much looks like an OPES but has none of its attributes and makes big real money (a ONES?). The box is on the edge of the network since it is actually a gateway to X.25 Minitel protocol. So there is protocol conversion at lowest layer as well. That box reads a web page and transforms it in a Minitel page on the fly. Since in France there are still more Minitel users than Internet users, I think the example is relevant. The interest is that other OPES could be added to transform the page not only from HTML to Minitel format, from TCP/IP to stable cheap X.25, from free access services to pay network access with good return for the content provider, but also from French into English, etc... I note that these services have an interesting specificity: no callout protocol the way it is proposed in here. But a much more simple "callout path". Depending on the load of the next Service Processors and on the next rule to apply the precedeing dispatcher send the whole traffic to a processor or to another, dasy chaining with all the possible loop, redirect, etc. that an X.25 native net can provide including multitarget, closed user groups, etc.. I discussed with the people there and the way they are able to support 128 users with a simple cheap X25 board and asked them about a simple architecture where I could use an X.25 edge network, daisy chaining with as much PC I would like (standard plug, stable and secure flow, flow control, simply formated extremely fast exchanges, easy priority support), looping back into the old internet in good old TCP/IP once the whole bunch of sophisticated OPES have been performed. I am waiting for a price from them (we developped that interface in 1983 so one probably improved since then). We discussed an interesting feature BTW: the Gatekeeper. To be able to store at the entrance of the X25 system (first dispatcher) everything confidential which may not interest the OPES operators and restore them at the output. Obviously the X.25 system can be used as a star network or a mshed network (the processed documents proceeding along a dasychaining or coming back to the same dispatcher until cleared). Comments welcome. jfc On 21:44 04/04/03, Reinaldo said: >----- Original Message ----- >From: "Alex Rousskov" >To: "OPES WG (E-mail)" >Sent: Friday, April 04, 2003 11:19 AM >Subject: RE: Comments on ocp-00 > > > > > > > > On Fri, 4 Apr 2003, Martin Stecher wrote: > > > > > > a) Thus, somebody needs to tell OPES processor > > > > and callout server what is an "application message" > > > > definition that they should both use during OCP > > > > communications. Should OCP support auto-negotiation or > > > > rely on out-of-band (e.g., manual) configuration? > > > > > > How about this: > > > We discussed that we probably end with multiple application > > > protocol bindings of the OCP. One application protocol binding > > > could be a generic binding which is not really related to any > > > Internet protocol but handles data as if it was a file on disk. > > > Application messages could have a very simple and generic format > > > here. Many callout services may want to support this protocol > > > binding and an OPES processor may have pre-processing code to > > > translate Internet protocol data to that simple format. > > > Other protocol bindings will handle native HTTP and SMTP messages. > > > Every application protocol binding defines a fixed application > > > message format. > > > > I think both Reinaldo Penno and myself want a scheme very similar to > > what you described above. There will be a set of supported application > > protocols and message encodings. Known message "formats" will be > > documented. OPES agents will support some subset of them. It is > > probably a good idea to document a scheme where OCP sees only message > > payloads and is unaware of the actual application protocol (still, one > > would need to agree on things like payload encoding). > > > > > Negotiations between OPES processors and callout services is then > > > limited to exchange supported application protocol bindings. > > > > This is the only uncertain area. You are, essentially, voting for > > supporting auto-negotiations (over a finite set of known > > protocols/encodings, of course). If nobody objects to this automation, > > OCP will implement auto-negotiation. My understanding is that Reinaldo > > is already working on specific messages to handle that. > >Folks, > >Are we talking about the same thing? This is already a MUST on the >requirements draft. We have several parameters that need to be negotiated >that have (a priori) nothing to do with the application protocol/bindings >OCP will be carrying. They are go from basic things like version number to >performance, security, etc. > >" Capabilities and parameters that could be negotiated between an OPES > processor and a callout server include (but are not limited to): > callout protocol version, fail-over behavior, heartbeat rate for > keep-alive messages, security-related parameters etc. > >" >and yeah, I'm already working on that... > >thanks, > >Reinaldo > >My statements > > > > > > > e) Do we need to group processing of a single application > > > > message together using OCP transaction concept? Should > > > > OCP transaction mean something else? Do we need OCP > > > > transactions at all? > > > > > > Yes, I think so. > > > In most cases not more than one application message will be > > > transferred from CLIENT to SERVER and back within a transaction. > > > But we have two examples where multiple messages make sense: > > > 1. Allowing the SERVER to return different SMTP messages for > > > one email to multiple recipients it received from the CLIENT. > > > 2. Pre-processing of a message at CLIENT which results in > > > multiple application messages, e.g. MIME sections of an email > > > to be transferred as multiple application messages > > > > > > The first case requires to have the messages being wrapped into > > > a single transaction. > > > The second case could benefit from a transaction wrapping > > > because the SERVER may want to know which MIME sections belong > > > together. > > > > The current draft does not support the second case in a situation where > > both cases happen at the same time (e.g., multiple responses to a > > pre-processed message part). This combination can be supported within one > > OCP transaction only if server responses specify which pre-processed > > application message [part] they are adapting. That is, an > > app-message-start message from a callout server will have to include a > > second am-id parameter, carrying the am-id of the corresponding > > application message part from the processor. While possible, this > > defeats the purpose of having an OCP transaction -- since all server > > responses have to carry two am-ids, the transaction wrapping is useless > > for anything other than aborting the whole thing with one message. > > > > I think the second case must be supported by generating multiple > > (possibly interleaved) OCP transactions, one for each pre-processed part. > > The overhead, if any, will be minimal, and the only missing > > functionality would be an ability to abort all parts with one message. We > > can add 'xaction-ends' to support the latter if needed. > > > > > I agree with Alex that the transaction overhead could (and should) > > > be limited to a minimum so that no additional transport layer packet > > > is needed. For the normal case the xaction-start app-message-start > > > couple could almost look like a single message I think. > > > But let's keep the xaction-start message two allow support of above > > > cases. > > > > Yes, there is not much difference between parsing two simple messages > > with 1 attribute and one complex message with 2 attributes. > > > > > - The sentence "A SERVER MUST NOT send this message" should also > > > be added to the connection-service message and maybe also to > > > connection-priority > > > > Ack. > > > > > - I am not sure whether the ability to change the service with > > > connection-service and within xaction-start is really needed. > > > It increases the implementation requirements for a callout > > > server but is it really needed? > > > Setting a service will usually also mean to negotiate further > > > parameters. > > > Couldn't we just put this into connection-start? > > > Using different services will then mean to start different > > > connections. Isn't this just ok? > > > > Yeah, that will work. The rationale was that you can use the > > connection to specify common/default services and then overwrite that > > on a transaction basis. You make a good point regarding associated > > negotiations though. Will add this question to the to-do list. The > > answer will probably depend on what kind of negotiations we would end > > up supporting. > > > > > - I forget about the motivation of the "ack" flag and data-ack > > > messsage. I thought we wanted to have this done by the > > > transport layer binding. Can you point me to the thread in > > > which this has been discussed? > > > > Ack/Data-ack sequence is useful if one side wants to track (or debug) > > progress in receiving/parsing OCP messages on the other side. Perhaps > > OPES processor can optimize its buffer management by knowing how fast > > the callout server is reading the data. Do you think that enough > > motivation to support the ack/data-ack pair? > > > > > - Isn't there a problem with data-pause? > > > If the SERVER sends data-pause to the CLIENT, the CLIENT > > > MUST stop sending but before the CLIENT receives and > > > processes this message it may already have sent additional > > > data-have messages. The SERVER will then receive unexpected > > > data any MAY abort. > > > > Indeed. I've added the "MAY abort" part at the last minute and > > missed the bug. Will fix. > > > > > Second problem: A CLIENT may not be able to pause as long > > > as the server likes it to pause. If it is not able to keep > > > a copy of the complete message and if it is not be able to > > > pause the origin server for the same time, it may easily run > > > into an internal buffer overflow problem. > > > > I do not think that can happen because the CLIENT can always stop > > reading incoming data if it has no place to put it. Right? > > > > There is a deadlock problem, however (see the "copying commitment and > > deadlock" thread on this list). That problem is on the to-do list. > > > > > How about defining that data-pause MUST NOT be send by the > > > SERVER but adding a new message data-pause-request which is > > > only to be sent by the SERVER. Upon receiving this message > > > the CLIENT MAY pause by sending data-pause to the SERVER. > > > > The above logic is what data-pause from the SERVER was supposed to mean. > > We can fix the current definition or use data-pause-request instead. > > Will fix. > > > > > > Thanks a lot for the comments, > > > > Alex. > > > > > > > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03 From owner-ietf-openproxy@mail.imc.org Sat Apr 5 16:55:24 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15407 for ; Sat, 5 Apr 2003 16:55:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35LjuJM006934 for ; Sat, 5 Apr 2003 13:45:56 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35LjuAf006933 for ietf-openproxy-bks; Sat, 5 Apr 2003 13:45:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35LjtJM006926 for ; Sat, 5 Apr 2003 13:45:55 -0800 (PST) Received: from localhost.localdomain (pl109438.fiber.net [216.83.152.26] (may be forged)) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h35LkfKq013470; Sat, 5 Apr 2003 14:46:43 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h35LjXZ10713; Sat, 5 Apr 2003 14:45:33 -0700 Date: Sat, 5 Apr 2003 14:45:33 -0700 Message-Id: <200304052145.h35LjXZ10713@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: info@utel.net Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <5.2.0.9.0.20030405143401.00ac6d50@mail.utel.net> Subject: Re: a question ONES again? Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Minitel/Internet example is certainly interesting. I think that it is useful to keep the architectural separation between transport and application in mind here. Good example of OPES service: Minitel page <-> HTML page question: is there a cache of translated pages at the gateway? Good example of OPES service: English -> French question: are French network service providers allowed to translate French -> English :-) Good example why OPES has privacy requirements: removing privacy-related information from data going to callout servers. I don't know what kind information X.25 carries or whether or how hard it is to remove/restore it, but the overall principle is an important one Example of service on an generalized OPES architecture: X.25 <-> TCP/IP question: this raises a lot of questions about addressing, flow control, naming, character set conversions, etc. Seems like a nightmare, ..., does it really work? It would seem especially awkward to support the barely disguised OPES model of forwarding IP packets on the callout path - it's not a requirement, but it certainly works well in an all TCP/IP environment. Hilarie From owner-ietf-openproxy@mail.imc.org Sat Apr 5 20:49:18 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19653 for ; Sat, 5 Apr 2003 20:49:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h361YiJM015107 for ; Sat, 5 Apr 2003 17:34:44 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h361YhoM015106 for ietf-openproxy-bks; Sat, 5 Apr 2003 17:34:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.110]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h361YgJM015101 for ; Sat, 5 Apr 2003 17:34:42 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout10.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCW0008VF1PLO@mtaout10.icomcast.net> for ietf-openproxy@imc.org; Sat, 05 Apr 2003 20:34:37 -0500 (EST) Date: Sat, 05 Apr 2003 20:34:37 -0500 From: Markus Hofmann Subject: Re: Comments on ocp-00 In-reply-to: To: OPES Group Message-id: <3E8F842D.9030806@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <0A11633F61BD9F40B43ABCC694004F93F18E70@zsc3c026.us.nortel.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Alex Rousskov wrote: > a) OPES processor may be able to pre-process application > messages (e.g., extract payload). Callout servers > may be able to handle various kinds of application > data (e.g., complete HTTP messages versus MIME-encoded > payload). Thus, somebody needs to tell OPES processor > and callout server what is an "application message" > definition that they should both use during OCP > communications. Should OCP support auto-negotiation or > rely on out-of-band (e.g., manual) configuration? Please, let's try to stay away as much as possible from building (potentially complex) capability negotiation mechanisms into OCP. I would prefer to keep OCP simple. In an earlier email, other protocols were mentioned as positive reference for integrating capability negotiation. I'm not sure about that, since I hear increasingly voices expressing problems with that approach (e.g. negotiation of transport protocol in SIP, for example, is often considered a "trouble maker"). > c) OPES processor can be [a part of] an application-level > proxy. Can OPES processor be a transport-level gateway > too? For example, can OPES processor manipulate with > raw TCP packets and care about things like > retransmissions and ACKs? OPES clearly is about application-level proxies and does *not* operate on network or transport layer!! Please let's be very clear about that! Hilarie also had some nice charts in San Franciso, which might help illustrating this, see http://ietf.org/proceedings/03mar/slides/opes-1.pdf -Markus From owner-ietf-openproxy@mail.imc.org Sat Apr 5 21:00:59 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19843 for ; Sat, 5 Apr 2003 21:00:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h361qeJM016257 for ; Sat, 5 Apr 2003 17:52:40 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h361qe1u016256 for ietf-openproxy-bks; Sat, 5 Apr 2003 17:52:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.115]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h361qdJM016242 for ; Sat, 5 Apr 2003 17:52:39 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout09.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCW00LABFVPZ2@mtaout09.icomcast.net> for ietf-openproxy@imc.org; Sat, 05 Apr 2003 20:52:37 -0500 (EST) Date: Sat, 05 Apr 2003 20:52:37 -0500 From: Markus Hofmann Subject: Re: Comments on ocp-00 In-reply-to: <008501c2fae2$a0378060$94368c2f@desktop> To: "OPES WG (E-mail)" Message-id: <3E8F8865.5030302@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <72992B39BBD9294BB636A960E89AE02EF54CA5@hermes.webwasher.com> <008501c2fae2$a0378060$94368c2f@desktop> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Reinaldo wrote: > Are we talking about the same thing? This is already a MUST on the > requirements draft. We have several parameters that need to be negotiated > that have (a priori) nothing to do with the application protocol/bindings > OCP will be carrying. They are go from basic things like version number to > performance, security, etc. The intention behind this requirement was to allow for very basic, but fundamental and absolutely required parameter exchange. It should *not* be seen as justification for very complex capability auto-negotiation schemes. Key point - keep it simple, any added complexity will have to be justified with a very specifc "must-have" example. -Markus From owner-ietf-openproxy@mail.imc.org Sat Apr 5 21:40:30 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20397 for ; Sat, 5 Apr 2003 21:40:29 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h362PbJM018894 for ; Sat, 5 Apr 2003 18:25:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h362PbEP018893 for ietf-openproxy-bks; Sat, 5 Apr 2003 18:25:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h362PZJM018889 for ; Sat, 5 Apr 2003 18:25:35 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h362PTo24154; Sat, 5 Apr 2003 20:25:29 -0600 (CST) Received: from zsc3c026.us.nortel.com ([47.81.138.26]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2J0VQM8D; Sat, 5 Apr 2003 18:25:29 -0800 Received: from private2xsth6c (artpt5qr.us.nortel.com [47.140.52.142]) by zsc3c026.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2GHBK7HC; Sat, 5 Apr 2003 18:25:28 -0800 Message-ID: <000701c2fbe3$caaa1f90$8e348c2f@private2xsth6c> X-Sybari-Space: 00000000 00000000 00000000 From: "Reinaldo Penno" To: "Markus Hofmann" , "OPES Group" References: <0A11633F61BD9F40B43ABCC694004F93F18E70@zsc3c026.us.nortel.com> <3E8F842D.9030806@mhof.com> Subject: Re: Comments on ocp-00 Date: Sat, 5 Apr 2003 21:25:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Markus Hofmann" To: "OPES Group" Sent: Saturday, April 05, 2003 8:34 PM Subject: Re: Comments on ocp-00 > > Alex Rousskov wrote: > > > a) OPES processor may be able to pre-process application > > messages (e.g., extract payload). Callout servers > > may be able to handle various kinds of application > > data (e.g., complete HTTP messages versus MIME-encoded > > payload). Thus, somebody needs to tell OPES processor > > and callout server what is an "application message" > > definition that they should both use during OCP > > communications. Should OCP support auto-negotiation or > > rely on out-of-band (e.g., manual) configuration? > > Please, let's try to stay away as much as possible from building > (potentially complex) capability negotiation mechanisms into OCP. I > would prefer to keep OCP simple. > > In an earlier email, other protocols were mentioned as positive > reference for integrating capability negotiation. I'm not sure about > that, since I hear increasingly voices expressing problems with that > approach (e.g. negotiation of transport protocol in SIP, for example, > is often considered a "trouble maker"). Markus, that's on example versus several mature protocols running in the Internet for years and years. Moreover we have already ruled transport negotiation out. So, can you give other examples of these increasing voices? Because although the negotiation of transport in SIP might be a problem, SDP's offer and answer model is what makes a SIP session so easy. Anyway, I guess that if the majority feels that capability negotiation is not useful then we should edit the requirements draft and modify the MUST to SHOULD or MAY. Otherwise it will seem strange that the protocol the WG itself propose does not abide by its own requirements. > > > c) OPES processor can be [a part of] an application-level > > proxy. Can OPES processor be a transport-level gateway > > too? For example, can OPES processor manipulate with > > raw TCP packets and care about things like > > retransmissions and ACKs? > > OPES clearly is about application-level proxies and does *not* operate > on network or transport layer!! Please let's be very clear about that! How can that be possible? The OPES processor needs to be addressed explicily by the client, so it needs to deal with IP/TCP and application. If has to implement a full TCP/IP stack. You might consider that "not part of OPES", but the box in which OPES run clearly has to implement everything. If it was some sort of transparent proxy, we could have TCP Proxy/Splicing, but this is not the case. > > Hilarie also had some nice charts in San Franciso, which might help > illustrating this, see http://ietf.org/proceedings/03mar/slides/opes-1.pdf > > -Markus > From owner-ietf-openproxy@mail.imc.org Sat Apr 5 21:41:43 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20449 for ; Sat, 5 Apr 2003 21:41:42 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h362SIJM018963 for ; Sat, 5 Apr 2003 18:28:18 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h362SIp6018962 for ietf-openproxy-bks; Sat, 5 Apr 2003 18:28:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h362SGJM018940 for ; Sat, 5 Apr 2003 18:28:16 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h362SCo24184; Sat, 5 Apr 2003 20:28:12 -0600 (CST) Received: from zsc3c026.us.nortel.com ([47.81.138.26]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2J0VQM8Z; Sat, 5 Apr 2003 18:28:12 -0800 Received: from private2xsth6c (artpt5qr.us.nortel.com [47.140.52.142]) by zsc3c026.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2GHBK7H1; Sat, 5 Apr 2003 18:28:12 -0800 Message-ID: <000d01c2fbe4$2c03ff90$8e348c2f@private2xsth6c> X-Sybari-Space: 00000000 00000000 00000000 From: "Reinaldo Penno" To: "Markus Hofmann" , "OPES WG \(E-mail\)" References: <72992B39BBD9294BB636A960E89AE02EF54CA5@hermes.webwasher.com> <008501c2fae2$a0378060$94368c2f@desktop> <3E8F8865.5030302@mhof.com> Subject: Re: Comments on ocp-00 Date: Sat, 5 Apr 2003 21:28:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Markus, although I agree with the simple approach, the idea is to have a capability negotiation scheme that can be extended to negotiate whatever people want. The WG itself should standardize only a few parameters such as version number, keep-alive, etc. would you agree? ----- Original Message ----- From: "Markus Hofmann" To: "OPES WG (E-mail)" Sent: Saturday, April 05, 2003 8:52 PM Subject: Re: Comments on ocp-00 > > Reinaldo wrote: > > > Are we talking about the same thing? This is already a MUST on the > > requirements draft. We have several parameters that need to be negotiated > > that have (a priori) nothing to do with the application protocol/bindings > > OCP will be carrying. They are go from basic things like version number to > > performance, security, etc. > > The intention behind this requirement was to allow for very basic, but > fundamental and absolutely required parameter exchange. It should > *not* be seen as justification for very complex capability > auto-negotiation schemes. Key point - keep it simple, any added > complexity will have to be justified with a very specifc "must-have" > example. > > -Markus > From owner-ietf-openproxy@mail.imc.org Sat Apr 5 22:51:15 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21034 for ; Sat, 5 Apr 2003 22:51:15 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h363UfJM020143 for ; Sat, 5 Apr 2003 19:30:41 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h363Uefh020142 for ietf-openproxy-bks; Sat, 5 Apr 2003 19:30:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h363UdJM020136 for ; Sat, 5 Apr 2003 19:30:39 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout08.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCW005B1KF2AM@mtaout08.icomcast.net> for ietf-openproxy@imc.org; Sat, 05 Apr 2003 22:30:38 -0500 (EST) Date: Sat, 05 Apr 2003 22:30:38 -0500 From: Markus Hofmann Subject: Re: Comments on ocp-00 In-reply-to: <000d01c2fbe4$2c03ff90$8e348c2f@private2xsth6c> To: "OPES WG (E-mail)" Message-id: <3E8F9F5E.9010504@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <72992B39BBD9294BB636A960E89AE02EF54CA5@hermes.webwasher.com> <008501c2fae2$a0378060$94368c2f@desktop> <3E8F8865.5030302@mhof.com> <000d01c2fbe4$2c03ff90$8e348c2f@private2xsth6c> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Reinaldo Penno wrote: > although I agree with the simple approach, the idea is to have a capability > negotiation scheme that can be extended to negotiate whatever people want. > The WG itself should standardize only a few parameters such as version > number, keep-alive, etc. > > would you agree? If we can keep the extensible negotiation scheme reasonably simple and don't end up specifying a complex negotiation protocol - sure. -Markus From owner-ietf-openproxy@mail.imc.org Sat Apr 5 23:04:31 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21185 for ; Sat, 5 Apr 2003 23:04:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h363j2JM020803 for ; Sat, 5 Apr 2003 19:45:02 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h363j2E8020802 for ietf-openproxy-bks; Sat, 5 Apr 2003 19:45:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.115]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h363j0JM020798 for ; Sat, 5 Apr 2003 19:45:00 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout09.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCW00MSEL2YRR@mtaout09.icomcast.net> for ietf-openproxy@imc.org; Sat, 05 Apr 2003 22:44:59 -0500 (EST) Date: Sat, 05 Apr 2003 22:44:58 -0500 From: Markus Hofmann Subject: Re: Comments on ocp-00 In-reply-to: <000701c2fbe3$caaa1f90$8e348c2f@private2xsth6c> To: OPES Group Message-id: <3E8FA2BA.7040806@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <0A11633F61BD9F40B43ABCC694004F93F18E70@zsc3c026.us.nortel.com> <3E8F842D.9030806@mhof.com> <000701c2fbe3$caaa1f90$8e348c2f@private2xsth6c> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Reinaldo Penno wrote: > Anyway, I guess that if the majority feels that capability negotiation is > not useful then we should edit the requirements draft and modify the MUST to > SHOULD or MAY. Otherwise it will seem strange that the protocol the WG > itself propose does not abide by its own requirements. I didn't mean to rule out basic and required mechanisms for agreeing on certain parameters. I just want to slow down on going down the road of integrating too complex auto-negotiating mechanisms into the callout protocol. The more we allow to negotiate, the more error cases and special cases we've to consider, and the more complex and error prone the protocol will be. > How can that be possible? The OPES processor needs to be addressed explicily > by the client, so it needs to deal with IP/TCP and application. If has to > implement a full TCP/IP stack. You might consider that "not part of OPES", > but the box in which OPES run clearly has to implement everything. I can't recall to have said that a OPES processor wouldn't have to implement TCP/IP. What I said was that the services and operations OPES is concernd about are clearly at the application level, and not at the network and transport level. See Hilarie's slides for illustration. -Markus From owner-ietf-openproxy@mail.imc.org Sun Apr 6 13:51:14 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01670 for ; Sun, 6 Apr 2003 13:51:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36HfgJM016573 for ; Sun, 6 Apr 2003 10:41:42 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36Hfg7a016572 for ietf-openproxy-bks; Sun, 6 Apr 2003 10:41:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36HffJM016568 for ; Sun, 6 Apr 2003 10:41:41 -0700 (PDT) Received: from f14m-7-146.d1.club-internet.fr ([212.195.94.146] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 192E8z-0002CX-00; Sun, 06 Apr 2003 10:41:26 -0700 Message-Id: <5.2.0.9.0.20030406192433.03477ec0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 06 Apr 2003 19:32:06 +0200 To: "The Purple Streak, Hilarie Orman" From: jfcm Subject: Re: a question ONES again? Cc: ietf-openproxy@imc.org In-Reply-To: <200304052145.h35LjXZ10713@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 23:45 05/04/03, The Purple Streak, Hilarie Orman wrote: >The Minitel/Internet example is certainly interesting. I think that it is >useful to keep the architectural separation between transport and >application in mind here. > >Good example of OPES service: Minitel page <-> HTML page > question: is there a cache of translated pages at the gateway? > >Good example of OPES service: English -> French > question: are French network service providers allowed to translate > French -> English :-) > >Good example why OPES has privacy requirements: removing privacy-related > information from data going to callout servers. I don't know what kind > information X.25 carries or whether or how hard it is to remove/restore > it, but the overall principle is an important one > >Example of service on an generalized OPES architecture: X.25 <-> TCP/IP > question: this raises a lot of questions about addressing, flow control, > naming, character set conversions, etc. Seems like a > nightmare, ..., does it really work? It would seem especially > awkward to support the barely disguised OPES model of forwarding > IP packets on the callout path - it's not a requirement, but > it certainly works well in an all TCP/IP environment. Well, there are certainly a lot of issues here and it could be much application dependant (TCP/IP). Only a test can show what is the fastest. Also depends on the Window size, etc. But the real point is that it shows a totally different logical model and a different philiosophy of protocol. We have a fast pipe with bypasses and loops. And no callout protocol. jfc From owner-ietf-openproxy@mail.imc.org Sun Apr 6 15:17:44 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04401 for ; Sun, 6 Apr 2003 15:17:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36J6wJM019653 for ; Sun, 6 Apr 2003 12:06:58 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36J6wGH019652 for ietf-openproxy-bks; Sun, 6 Apr 2003 12:06:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h36J6vJM019645 for ; Sun, 6 Apr 2003 12:06:57 -0700 (PDT) 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 h36J6k222007; Sun, 6 Apr 2003 15:06:46 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 15:06:46 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754055BD6D8@zcard0k6.ca.nortel.com> From: "Abbie Barbir" Cc: Alex Rousskov , OPES Group Subject: feedback: OCP version head_sid2 thread Date: Sun, 6 Apr 2003 15:06:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FC6F.AB0EB574" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FC6F.AB0EB574 Content-Type: text/plain Hi, this is the feedback on the head-si2 ocp draft. 1. application message: A sequence of octets that OPES processor designates for callout service processing or a sequence of octets that callout server sends back to the OPES processor. Usually, an application message is the basic unit of application protocol communication, as defined by that application protocol (e.g., HTTP/1.1 message). (XXX: This definition is bad because OCP messages themselves are also sequence of octets that OCP agents send to each other. How to distinguish "OCP" from "application" if we do not have an application data definition? What we want to say is that application message is whatever an OCP agent has marked as such. How to say that?) I still do not like this defintion at all. An application message is still an application message whether OPES processor will send it to the callout server or not. We need to remember that in some cases the OPES processor will do all the work and if a trigger happens such as CPU watermark, the processor will use the callout server as an additional helper. Furthermore, The OCP should be application agnostic, here I think we should differentiate between the following: Application +---------------+ OCP Message +----------------+ Protocol --->| OPES Processor| ---------------> | Callout Server | Message <--- | | <--------------- | | +---------------+ +----------------+ In this regard, it is possible to have only one OCP binding to TCP/IP regardless of the Application layer Protocol The same thing can happen for data Application +---------------+ OCP Data +----------------+ Protocol --->| OPES Processor| ---------------> | Callout Server | Data <--- | | <--------------- | | +---------------+ +----------------+ The arrow can be uni or biderectional ( in the general case). In some cases, the OPES processor can infere the adaptation that is needed from the application message and send a service request to the Callout server. For example: 1. Service Type: Crop image to QCIF size and make it B/W 2. Here is the URL for the image. ------_=_NextPart_001_01C2FC6F.AB0EB574 Content-Type: text/html Content-Transfer-Encoding: quoted-printable feedback: OCP version head_sid2 thread

Hi, this is the feedback on the head-si2 ocp = draft.

1.
application message: A sequence of octets that OPES = processor
      designates for = callout service processing or a sequence of octets
      that callout server = sends back to the OPES processor.  Usually, an
      application message = is the basic unit of application protocol
      communication, as = defined by that application protocol (e.g.,
      HTTP/1.1 message). = (XXX: This definition is bad because OCP
      messages themselves = are also sequence of octets that OCP agents
      send to each = other.  How to distinguish "OCP" from = "application"
      if we do not have an = application data definition?  What we want to
      say is that = application message is whatever an OCP agent has
      marked as such. How = to say that?)


I still do not like this defintion at all.

An application message is still an application = message whether OPES processor
will send it to the callout server or not. We need = to remember that in some cases the OPES processor will do all the work = and if a trigger happens such as CPU watermark, the processor will use = the callout server as an additional helper.

Furthermore, The OCP should be application agnostic, = here I think we should differentiate between the following:

 Application  +---------------+   = OCP Message    +----------------+
 Protocol --->| OPES Processor| = ---------------> | Callout Server |
 Message <--- = |            = ;   | <--------------- = |            = ;    |
          &nb= sp;   = +---------------+         &= nbsp;        = +----------------+

In this regard, it is possible to have only one OCP = binding to TCP/IP regardless of the Application layer Protocol

The same thing can happen for data


 Application  +---------------+   = OCP Data       +----------------+
 Protocol --->| OPES Processor| = ---------------> | Callout Server |
 Data    <--- = |            = ;   | <--------------- = |            = ;    |
          &nb= sp;   = +---------------+         &= nbsp;        = +----------------+


The arrow can be uni or biderectional ( in the = general case).

In some cases, the OPES processor can infere the = adaptation that is needed from the application message and send a = service request to the Callout server. For example:

1. Service Type: Crop image to QCIF size and make it = B/W
2. Here is the URL for the image.
























------_=_NextPart_001_01C2FC6F.AB0EB574-- From owner-ietf-openproxy@mail.imc.org Sun Apr 6 15:41:10 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04760 for ; Sun, 6 Apr 2003 15:41:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36JVIJM020461 for ; Sun, 6 Apr 2003 12:31:18 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36JVHq1020460 for ietf-openproxy-bks; Sun, 6 Apr 2003 12:31:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h36JVGJM020454 for ; Sun, 6 Apr 2003 12:31:17 -0700 (PDT) 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 h36JVC529554; Sun, 6 Apr 2003 15:31:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 15:31:12 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754055BD6DB@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: OPES Group Cc: Alex Rousskov Subject: feedback: OCP version head_sid2 thread: Try 2 Date: Sun, 6 Apr 2003 15:31:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FC73.14F2039E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FC73.14F2039E Content-Type: text/plain Hi, PS: The previous e-mail was sent before I finished typing the full message. I just hit the send button as opposed to the save one. So here is the full feedback This is the feedback on the head-si2 ocp draft. 1. application message: A sequence of octets that OPES processor designates for callout service processing or a sequence of octets that callout server sends back to the OPES processor. Usually, an application message is the basic unit of application protocol communication, as defined by that application protocol (e.g., HTTP/1.1 message). (XXX: This definition is bad because OCP messages themselves are also sequence of octets that OCP agents send to each other. How to distinguish "OCP" from "application" if we do not have an application data definition? What we want to say is that application message is whatever an OCP agent has marked as such. How to say that?) I still do not like this defintion at all. An application message is still an application message whether OPES processor will send it to the callout server or not. We need to remember that in some cases the OPES processor will do all the work and if a trigger happens such as CPU watermark, the processor will use the callout server as an additional helper. Furthermore, The OCP should be application agnostic, here I think we should differentiate between the following: Application +---------------+ OCP Message +----------------+ Protocol --->| OPES Processor| ---------------> | Callout Server | Message <--- | | <--------------- | | +---------------+ +----------------+ In this regard, it is possible to have only one OCP binding to TCP/IP regardless of the Application layer Protocol The same thing can happen for data Application +---------------+ OCP Data +----------------+ Protocol --->| OPES Processor| ---------------> | Callout Server | Data <--- | | <--------------- | | +---------------+ +----------------+ The arrow can be uni or biderectional ( in the general case). In some cases, the OPES processor can infere the adaptation that is needed from the application message and send a service request to the Callout server. For example: 1. Service Type: Crop image to QCIF size and make it B/W 2. Here is the URL for the image. These cases need to be identified in the definition of messages. So I think that in the general case an OCP message can be one of the following: 1. Identical Application message (just forwarded) 2. Partial Application message with some modification 3. A message that is infered from an Application message. Thus, we should make distinction about an OCP message and an application message. So here is my proposal: 1. Application message: A sequence of octets that OPES processor accept for further processing by itself or with the additional help from a callout server. Usually, an application message is the basic unit of application protocol communication, as defined by that application protocol (e.g.,HTTP/1.1 message). 2. application message data: A sequence or subsequence of application message octets. Application message data may correspond to an application message fragment or may cover an entire application message. OCP treats application message data as opaque sequences of octets. Application message data may be empty. Need to introduce the following 3. OCP Message: A sequence of octets that OPES processor use to communicate actions required on Application level messages to callout server. The callout server also uses OCP messages to communicate results back to the OPES processor. In some cases, the OCP message may be identical to the Application level message. However, in some other cases the OCP message can be a partial Application level message or generated entirely by an OPES processor. 4. OCP Data: OCP Message Data: Fix the original definition to reflect OCP message. More feedback will follow Regards Abbie ------_=_NextPart_001_01C2FC73.14F2039E Content-Type: text/html Content-Transfer-Encoding: quoted-printable feedback: OCP version head_sid2 thread: Try 2

Hi,

PS: The previous e-mail was sent before I finished = typing the full message. I just hit the send button as opposed to the = save one.

So here is the full feedback


This is the feedback on the head-si2 ocp = draft.

1.
application message: A sequence of octets that OPES = processor
      designates for = callout service processing or a sequence of octets
      that callout server = sends back to the OPES processor.  Usually, an
      application message = is the basic unit of application protocol
      communication, as = defined by that application protocol (e.g.,
      HTTP/1.1 message). = (XXX: This definition is bad because OCP
      messages themselves = are also sequence of octets that OCP agents
      send to each = other.  How to distinguish "OCP" from = "application"
      if we do not have an = application data definition?  What we want to
      say is that = application message is whatever an OCP agent has
      marked as such. How = to say that?)


I still do not like this defintion at all.

An application message is still an application = message whether OPES processor will send it to the callout server or = not. We need to remember that in some cases the OPES processor will do = all the work and if a trigger happens such as CPU watermark, the = processor will use the callout server as an additional = helper.

Furthermore, The OCP should be application agnostic, = here I think we should differentiate between the following:

 Application  +---------------+   = OCP Message    +----------------+
 Protocol --->| OPES Processor| = ---------------> | Callout Server |
 Message <--- = |            = ;   | <--------------- = |            = ;    |
          &nb= sp;   = +---------------+         &= nbsp;        = +----------------+

In this regard, it is possible to have only one OCP = binding to TCP/IP regardless of the Application layer Protocol

The same thing can happen for data


 Application  +---------------+   = OCP Data       +----------------+
 Protocol --->| OPES Processor| = ---------------> | Callout Server |
 Data    <--- = |            = ;   | <--------------- = |            = ;    |
          &nb= sp;   = +---------------+         &= nbsp;        = +----------------+


The arrow can be uni or biderectional ( in the = general case).

In some cases, the OPES processor can infere the = adaptation that is needed from the application message and send a = service request to the Callout server. For example:

1. Service Type: Crop image to QCIF size and make it = B/W
2. Here is the URL for the image.


These cases need to be identified in the definition = of messages.

So I think that in the general case an OCP message = can be one of the following:
1. Identical Application message (just = forwarded)
2. Partial Application message with some = modification
3. A message that is infered from an Application = message.

Thus, we should make distinction about an OCP message = and an application message.

So here is my proposal:

1. Application message:
A sequence of octets that OPES processor accept for = further processing by itself or with the additional help from a callout = server. Usually, an application message is the basic unit of = application protocol communication, as defined by that application = protocol (e.g.,HTTP/1.1 message).

2. application message data:

A sequence or subsequence of application message = octets. Application message data may correspond to an application = message fragment or may cover an entire application message. OCP treats = application message data as opaque sequences of octets. Application = message data may be empty.

Need to introduce the following

3. OCP Message:
A sequence of octets that OPES processor use to = communicate actions required on Application level messages to callout = server. The callout server also uses OCP messages to communicate = results back to the OPES processor. In some cases, the OCP message may = be identical to the Application level message. However, in some other = cases the OCP message can be a partial Application level message or = generated entirely by an OPES processor.

4. OCP Data:
OCP Message Data:

Fix the original definition to reflect OCP = message.


More feedback will follow


Regards
Abbie

















------_=_NextPart_001_01C2FC73.14F2039E-- From owner-ietf-openproxy@mail.imc.org Sun Apr 6 16:40:09 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05657 for ; Sun, 6 Apr 2003 16:40:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36KEdJM021698 for ; Sun, 6 Apr 2003 13:14:39 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36KEd0R021697 for ietf-openproxy-bks; Sun, 6 Apr 2003 13:14:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h36KEcJM021693 for ; Sun, 6 Apr 2003 13:14:38 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h36KEevj044129; Sun, 6 Apr 2003 14:14:40 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h36KEeB4044128; Sun, 6 Apr 2003 14:14:40 -0600 (MDT) (envelope-from rousskov) Date: Sun, 6 Apr 2003 14:14:40 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754055BD6DB@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754055BD6DB@zcard0k6.ca.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: On Sun, 6 Apr 2003, Abbie Barbir wrote: > application message: A sequence of octets that OPES processor > designates for callout service processing or a sequence of octets > that callout server sends back to the OPES processor. Usually, an > application message is the basic unit of application protocol > communication, as defined by that application protocol (e.g., > HTTP/1.1 message). (XXX: This definition is bad because OCP > messages themselves are also sequence of octets that OCP agents > send to each other. How to distinguish "OCP" from "application" > if we do not have an application data definition? What we want to > say is that application message is whatever an OCP agent has > marked as such. How to say that?) > > I still do not like this defintion at all. > > An application message is still an application message whether OPES > processor will send it to the callout server or not. We need to > remember that in some cases the OPES processor will do all the work > and if a trigger happens such as CPU watermark, the processor will > use the callout server as an additional helper. It is even worth than the above. We should try really hard to keep OCP independent from the application (and, hence, application messages). It is very important to do that to make OCP more "agnostic". As somebody said on this list before, OCP should not care what the application message is. The difficult part is that OCP has to identify application messages without carrying what they are. That is what I meant in the above XXX comments. OPES processor decides what an "application message is". OPES processor may decide to forward true application message "as is". It may decide to extract the payload and forward just that. Or it can apply 100 transformations, change the application protocol and encoding, and only then subject the "application message" to OCP processing. The callout server can do exactly the same, regardless of what the OPES processor did! How do define that? The current definition defines it, but it makes no distinction between "data octets" (which are application message data) and "OCP octets" (which are OCP message structures). That is what needs to be fixed. > Furthermore, The OCP should be application agnostic, here I think we should > differentiate between the following: > > Application +---------------+ OCP Message +----------------+ > Protocol --->| OPES Processor| ---------------> | Callout Server | > Message <--- | | <--------------- | | > +---------------+ +----------------+ > > In this regard, it is possible to have only one OCP binding to TCP/IP > regardless of the Application layer Protocol Sure, that's understood and is not the problem. Note that, from OCP point of view, your leftmost part (Application Protocol Message) does not exist. > The same thing can happen for data > > Application +---------------+ OCP Data +----------------+ > Protocol --->| OPES Processor| ---------------> | Callout Server | > Data <--- | | <--------------- | | > +---------------+ +----------------+ There is no "OCP data", really. There is only application data (original or preprocessed or adapted). > So I think that in the general case an OCP message can be one of the > following: > 1. Identical Application message (just forwarded) No, that cannot be an OCP message, only OCP message payload. OCP is a protocol, it cannot forward application messages without wrapping them in OCP headers/structures. > 2. Partial Application message with some modification Probably same problem as above unless adding OCP headers is "some modification". Application message can only be OCP payload. > 3. A message that is infered from an Application message. > > Thus, we should make distinction about an OCP message and an application > message. We should, but that it easy. Nobody is going to confuse OCP messages from application messages. OCP defines OCP messages. The problem is to define application message so that implementors know what they can pass across OCP and what can they identify using am-id. That is very important. > So here is my proposal: > > 1. Application message: > A sequence of octets that OPES processor accept for further processing by > itself or with the additional help from a callout server. Usually, an > application message is the basic unit of application protocol communication, > as defined by that application protocol (e.g.,HTTP/1.1 message). Not good. The application message definition cannot involve "additional help from a callout server" because that implies using OCP to get that "help" and one cannot use OCP until the application message is defined (OCP does not exist yet). > Need to introduce the following > > 3. OCP Message: > A sequence of octets that OPES processor use to communicate actions required > on Application level messages to callout server. The callout server also > uses OCP messages to communicate results back to the OPES processor. In some > cases, the OCP message may be identical to the Application level message. > However, in some other cases the OCP message can be a partial Application > level message or generated entirely by an OPES processor. This does not work for the above reasons, but the standard definition in the current draft should be OK (it could be moved to the definitions section). Again, the problem is with defining what application message is without just saying "anything that OCP agent sends" because the latter includes "OCP messages". See what I am getting at? I know I am not explaining it well enough. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Sun Apr 6 16:56:11 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05990 for ; Sun, 6 Apr 2003 16:55:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36KjKJM022160 for ; Sun, 6 Apr 2003 13:45:20 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36KjJk1022159 for ietf-openproxy-bks; Sun, 6 Apr 2003 13:45:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h36KjIJM022153 for ; Sun, 6 Apr 2003 13:45:19 -0700 (PDT) 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 h36Kj8224464; Sun, 6 Apr 2003 16:45:09 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 16:45:09 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754055BD6EB@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES Group Subject: RE: feedback: OCP version head_sid2 thread: Try 2 Date: Sun, 6 Apr 2003 16:45:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FC7D.68FF8344" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FC7D.68FF8344 Content-Type: text/plain Alex, I know that comming up with a definition is hard, so we are still at square one !!!!!!!!!!!!!!!!!!!!!!!. Ha ha ha............. Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Sunday, April 06, 2003 4:15 PM > To: OPES Group > Subject: Re: feedback: OCP version head_sid2 thread: Try 2 > > > On Sun, 6 Apr 2003, Abbie Barbir wrote: > > > application message: A sequence of octets that OPES processor > > designates for callout service processing or a > sequence of octets > > that callout server sends back to the OPES processor. > Usually, an > > application message is the basic unit of application protocol > > communication, as defined by that application protocol (e.g., > > HTTP/1.1 message). (XXX: This definition is bad because OCP > > messages themselves are also sequence of octets that > OCP agents > > send to each other. How to distinguish "OCP" from > "application" > > if we do not have an application data definition? > What we want to > > say is that application message is whatever an OCP agent has > > marked as such. How to say that?) > > > > I still do not like this defintion at all. > > > > An application message is still an application message whether OPES > > processor will send it to the callout server or not. We need to > > remember that in some cases the OPES processor will do all the work > > and if a trigger happens such as CPU watermark, the > processor will use > > the callout server as an additional helper. > > It is even worth than the above. We should try really hard to > keep OCP independent from the application (and, hence, > application messages). It is very important to do that to > make OCP more "agnostic". > > As somebody said on this list before, OCP should not care > what the application message is. The difficult part is that > OCP has to identify application messages without carrying > what they are. That is what I meant in the above XXX > comments. OPES processor decides what an "application message > is". OPES processor may decide to forward true application > message "as is". It may decide to extract the payload and > forward just that. Or it can apply 100 transformations, > change the application protocol and encoding, and only then > subject the "application message" to OCP processing. The > callout server can do exactly the same, regardless of what > the OPES processor did! > > How do define that? The current definition defines it, but it > makes no distinction between "data octets" (which are > application message > data) and "OCP octets" (which are OCP message structures). > That is what needs to be fixed. > > > Furthermore, The OCP should be application agnostic, here I > think we > > should differentiate between the following: > > > > Application +---------------+ OCP Message +----------------+ > > Protocol --->| OPES Processor| ---------------> | Callout Server | > > Message <--- | | <--------------- | | > > +---------------+ +----------------+ > > > > In this regard, it is possible to have only one OCP binding > to TCP/IP > > regardless of the Application layer Protocol > > Sure, that's understood and is not the problem. Note that, > from OCP point of view, your leftmost part (Application > Protocol Message) does not exist. > > > The same thing can happen for data > > > > Application +---------------+ OCP Data +----------------+ > > Protocol --->| OPES Processor| ---------------> | Callout Server | > > Data <--- | | <--------------- | | > > +---------------+ +----------------+ > > There is no "OCP data", really. There is only application > data (original or preprocessed or adapted). > > > So I think that in the general case an OCP message can be one of the > > following: > > 1. Identical Application message (just forwarded) > > No, that cannot be an OCP message, only OCP message payload. > OCP is a protocol, it cannot forward application messages > without wrapping them in OCP headers/structures. > > > 2. Partial Application message with some modification > > Probably same problem as above unless adding OCP headers is > "some modification". Application message can only be OCP payload. > > > 3. A message that is infered from an Application message. > > > > Thus, we should make distinction about an OCP message and an > > application message. > > We should, but that it easy. Nobody is going to confuse OCP > messages from application messages. OCP defines OCP > messages. The problem is to define application message so > that implementors know what they can pass across OCP and what > can they identify using am-id. That is very important. > > > So here is my proposal: > > > > 1. Application message: > > A sequence of octets that OPES processor accept for further > processing > > by itself or with the additional help from a callout > server. Usually, > > an application message is the basic unit of application protocol > > communication, as defined by that application protocol > (e.g.,HTTP/1.1 > > message). > > Not good. The application message definition cannot involve > "additional help from a callout server" because that implies > using OCP to get that "help" and one cannot use OCP until the > application message is defined (OCP does not exist yet). > > > Need to introduce the following > > > > 3. OCP Message: > > A sequence of octets that OPES processor use to communicate actions > > required on Application level messages to callout server. > The callout > > server also uses OCP messages to communicate results back > to the OPES > > processor. In some cases, the OCP message may be identical to the > > Application level message. However, in some other cases the OCP > > message can be a partial Application level message or generated > > entirely by an OPES processor. > > This does not work for the above reasons, but the standard > definition in the current draft should be OK (it could be > moved to the definitions section). Again, the problem is with > defining what application message is without just saying > "anything that OCP agent sends" because the latter includes > "OCP messages". See what I am getting at? I know I am not > explaining it well enough. > > Thank you, > > Alex. > ------_=_NextPart_001_01C2FC7D.68FF8344 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: feedback: OCP version head_sid2 thread: Try 2

Alex,

I know that comming up with a definition is = hard,
so we are still at square one = !!!!!!!!!!!!!!!!!!!!!!!.

Ha ha ha.............

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Sunday, April 06, 2003 4:15 PM
> To: OPES Group
> Subject: Re: feedback: OCP version head_sid2 = thread: Try 2
>
>
> On Sun, 6 Apr 2003, Abbie Barbir wrote:
>
> > application message: A sequence of octets = that OPES processor
> >       = designates for callout service processing or a
> sequence of octets
> >       that = callout server sends back to the OPES processor.
>  Usually, an
> >       = application message is the basic unit of application protocol
> >       = communication, as defined by that application protocol (e.g.,
> >       = HTTP/1.1 message). (XXX: This definition is bad because OCP
> >       = messages themselves are also sequence of octets that
> OCP agents
> >       send = to each other.  How to distinguish "OCP" from
> "application"
> >       if we = do not have an application data definition? 
> What we want to
> >       say is = that application message is whatever an OCP agent has
> >       marked = as such. How to say that?)
> >
> > I still do not like this defintion at = all.
> >
> > An application message is still an = application message whether OPES
> > processor will send it to the callout = server or not. We need to
> > remember that in some cases the OPES = processor will do all the work
> > and if a trigger happens such as CPU = watermark, the
> processor will use
> > the callout server as an additional = helper.
>
> It is even worth than the above. We should try = really hard to
> keep OCP independent from the application (and, = hence,
> application messages). It is very important to = do that to
> make OCP more "agnostic".
>
> As somebody said on this list before, OCP = should not care
> what the application message is. The difficult = part is that
> OCP has to identify application messages = without carrying
> what they are. That is what I meant in the = above XXX
> comments. OPES processor decides what an = "application message
> is". OPES processor may decide to forward = true application
> message "as is". It may decide to = extract the payload and
> forward just that. Or it can apply 100 = transformations,
> change the application protocol and encoding, = and only then
> subject the "application message" to = OCP processing. The
> callout server can do exactly the same, = regardless of what
> the OPES processor did!
>
> How do define that? The current definition = defines it, but it
> makes no distinction between "data = octets" (which are
> application message
> data) and "OCP octets" (which are OCP = message structures).
> That is what needs to be fixed.
>
> > Furthermore, The OCP should be application = agnostic, here I
> think we
> > should differentiate between the = following:
> >
> >  Application  = +---------------+   OCP Message    = +----------------+
> >  Protocol --->| OPES Processor| = ---------------> | Callout Server |
> >  Message <--- = |            = ;   | <--------------- = |            = ;    |
> = >           &n= bsp;   = +---------------+         &= nbsp;        = +----------------+
> >
> > In this regard, it is possible to have = only one OCP binding
> to TCP/IP
> > regardless of the Application layer = Protocol
>
> Sure, that's understood and is not the problem. = Note that,
> from OCP point of view, your leftmost part = (Application
> Protocol Message) does not exist.
>
> > The same thing can happen for data
> >
> >  Application  = +---------------+   OCP = Data       +----------------+
> >  Protocol --->| OPES Processor| = ---------------> | Callout Server |
> >  Data    <--- = |            = ;   | <--------------- = |            = ;    |
> = >           &n= bsp;   = +---------------+         &= nbsp;        = +----------------+
>
> There is no "OCP data", really. There = is only application
> data (original or preprocessed or = adapted).
>
> > So I think that in the general case an OCP = message can be one of the
> > following:
> > 1. Identical Application message (just = forwarded)
>
> No, that cannot be an OCP message, only OCP = message payload.
> OCP is a protocol, it cannot forward = application messages
> without wrapping them in OCP = headers/structures.
>
> > 2. Partial Application message with some = modification
>
> Probably same problem as above unless adding = OCP headers is
> "some modification". Application = message can only be OCP payload.
>
> > 3. A message that is infered from an = Application message.
> >
> > Thus, we should make distinction about an = OCP message and an
> > application message.
>
> We should, but that it easy. Nobody is going to = confuse OCP
> messages from application messages.  OCP = defines OCP
> messages. The problem is to define application = message so
> that implementors know what they can pass = across OCP and what
> can they identify using am-id. That is very = important.
>
> > So here is my proposal:
> >
> > 1. Application message:
> > A sequence of octets that OPES processor = accept for further
> processing
> > by itself or with the additional help from = a callout
> server. Usually,
> > an application message is the basic unit = of application protocol
> > communication, as defined by that = application protocol
> (e.g.,HTTP/1.1
> > message).
>
> Not good. The application message definition = cannot involve
> "additional help from a callout = server" because that implies
> using OCP to get that "help" and one = cannot use OCP until the
> application message is defined (OCP does not = exist yet).
>
> > Need to introduce the following
> >
> > 3. OCP Message:
> > A sequence of octets that OPES processor = use to communicate actions
> > required on Application level messages to = callout server.
> The callout
> > server also uses OCP messages to = communicate results back
> to the OPES
> > processor. In some cases, the OCP message = may be identical to the
> > Application level message. However, in = some other cases the OCP
> > message can be a partial Application level = message or generated
> > entirely by an OPES processor.
>
> This does not work for the above reasons, but = the standard
> definition in the current draft should be OK (it= could be
> moved to the definitions section). Again, the = problem is with
> defining what application message is without = just saying
> "anything that OCP agent sends" = because the latter includes
> "OCP messages". See what I am getting = at? I know I am not
> explaining it well enough.
>
> Thank you,
>
> Alex.
>

------_=_NextPart_001_01C2FC7D.68FF8344-- From owner-ietf-openproxy@mail.imc.org Sun Apr 6 17:02:55 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06170 for ; Sun, 6 Apr 2003 17:02:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36KnxJM022334 for ; Sun, 6 Apr 2003 13:49:59 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36KnxA0022333 for ietf-openproxy-bks; Sun, 6 Apr 2003 13:49:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h36KnvJM022327 for ; Sun, 6 Apr 2003 13:49:58 -0700 (PDT) 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 h36Knl224526; Sun, 6 Apr 2003 16:49:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 16:49:48 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov Cc: OPES Group Subject: RE: feedback: OCP version head_sid2 thread: Try 2 Date: Sun, 6 Apr 2003 16:49:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2FC7E.0D7D0090" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_000_01C2FC7E.0D7D0090 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FC7E.0D7D0090" ------_=_NextPart_001_01C2FC7E.0D7D0090 Content-Type: text/plain Alex, my feed back on the draft attached Abbie ------_=_NextPart_001_01C2FC7E.0D7D0090 Content-Type: text/html RE: feedback: OCP version head_sid2 thread: Try 2

Alex,

my feed back on the draft attached

Abbie

  ------_=_NextPart_001_01C2FC7E.0D7D0090-- ------_=_NextPart_000_01C2FC7E.0D7D0090 Content-Type: text/plain; name="draft-rousskov-opes-ocp--curr-00-abbie.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-rousskov-opes-ocp--curr-00-abbie.txt" Content-Transfer-Encoding: quoted-printable Open Pluggable Edge Services A. = Rousskov Internet-Draft The Measurement = Factory Expires: September 29, 2003 March 31, = 2003 OPES Callout Protocol (OCP) draft-rousskov-opes-ocp-cur Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 29, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract <1> Local revision control ID: $Id: ocp-spec.xml,v 1.10 2003/04/05 06:24:09 rousskov Exp $ <2> This document specifies Open Pluggable Edge Services (OPES) callout protocol (OCP). OCP supports the remote execution of OPES services. This OCP specification is incomplete and cannot be used for implementing the protocol yet. Major missing pieces are transport binding(s) and message encoding(s). Rousskov Expires September 29, 2003 [Page = 1] Internet-Draft OPES Callout Protocol (OCP) March = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . = 3 1.2 Overall Operation . . . . . . . . . . . . . . . . . . . . . = 4 1.3 Protocol Development Status . . . . . . . . . . . . . . . . = 6 2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . = 7 3. Transactions . . . . . . . . . . . . . . . . . . . . . . . . = 8 4. Connections . . . . . . . . . . . . . . . . . . . . . . . . = 9 5. Message Parameter Definitions . . . . . . . . . . . . . . . = 10 6. Message Definitions . . . . . . . . . . . . . . . . . . . . = 13 6.1 connection-start . . . . . . . . . . . . . . . . . . . . . . = 13 6.2 connection-end . . . . . . . . . . . . . . . . . . . . . . . = 14 6.3 connection-priority . . . . . . . . . . . . . . . . . . . . = 14 6.4 connection-service . . . . . . . . . . . . . . . . . . . . . = 14 6.5 xaction-start . . . . . . . . . . . . . . . . . . . . . . . = 14 6.6 xaction-end . . . . . . . . . . . . . . . . . . . . . . . . = 15 6.7 app-message-start . . . . . . . . . . . . . . . . . . . . . = 15 6.8 app-message-end . . . . . . . . . . . . . . . . . . . . . . = 15 6.9 data-have . . . . . . . . . . . . . . . . . . . . . . . . . = 16 6.10 data-as-is . . . . . . . . . . . . . . . . . . . . . . . . . = 16 6.11 data-pause . . . . . . . . . . . . . . . . . . . . . . . . . = 16 6.12 data-paused . . . . . . . . . . . . . . . . . . . . . . . . = 17 6.13 data-end . . . . . . . . . . . . . . . . . . . . . . . . . . = 17 6.14 data-need . . . . . . . . . . . . . . . . . . . . . . . . . = 17 6.15 data-ack . . . . . . . . . . . . . . . . . . . . . . . . . . = 18 6.16 i-am-here . . . . . . . . . . . . . . . . . . . . . . . . . = 19 6.17 are-you-there . . . . . . . . . . . . . . . . . . . . . . . = 19 6.18 do-you-support . . . . . . . . . . . . . . . . . . . . . . . = 19 6.19 i-do-support . . . . . . . . . . . . . . . . . . . . . . . . = 19 6.20 i-dont-support . . . . . . . . . . . . . . . . . . . . . . . = 19 6.21 please-use . . . . . . . . . . . . . . . . . . . . . . . . . = 19 6.22 i-will-use . . . . . . . . . . . . . . . . . . . . . . . . . = 20 6.23 i-wont-use . . . . . . . . . . . . . . . . . . . . . . . . . = 20 7. Application Protocol Requirements . . . . . . . . . . . . . = 21 8. IAB Concerns . . . . . . . . . . . . . . . . . . . . . . . . = 22 9. Security Considerations . . . . . . . . . . . . . . . . . . = 23 10. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . = 24 11. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . = 25 Normative References . . . . . . . . . . . . . . . . . . . . = 27 Informative References . . . . . . . . . . . . . . . . . . . = 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . = 28 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . = 29 Intellectual Property and Copyright Statements . . . . . . . = 30 Rousskov Expires September 29, 2003 [Page = 2] Internet-Draft OPES Callout Protocol (OCP) March = 2003 1. Introduction <3> The Open Pluggable Edge Services (OPES) architecture [I-D.ietf-opes-architecture], enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. <4> The execution of such services is governed by a set of rules installed on the OPES processor. The rules enforcement can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. As described in [I-D.ietf-opes-protocol-reqs], an OPES processor communicates with and invokes services on a callout server by using a callout = protocol. This document specifies such a protocol. 1.1 Terminology <5> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. <6> OCP works on messages from application protocols. Protocol elements like "message", "connection", or "transaction" exist in OCP and application protocols. In this specification, all references to elements from application protocols are used with an explicit "application" qualifier. References without the "application" qualifier, refer to OCP elements. (XXX: Some OCP elements are called "callout" elements in the OCP requirements document. We assume that OCP is equivalent to "callout" in this context. For example, OCP connection is the same as callout connection. Should we be more consistent?) <7> <8> [Abbie: See e-mails for feedback] application message: A sequence of octets that OPES processor designates for callout service processing or a sequence of octets that callout server sends back to the OPES processor. Usually, = an application message is the basic unit of application protocol communication, as defined by that application protocol (e.g., HTTP/1.1 message). (XXX: This definition is bad because OCP messages themselves are also sequence of octets that OCP agents send to each other. How to distinguish "OCP" from "application" if we do not have an application data definition? What we want = to say is that application message is whatever an OCP agent has marked as such. How to say that?) Rousskov Expires September 29, 2003 [Page = 3] Internet-Draft OPES Callout Protocol (OCP) March = 2003 <9> application message data: A subsequence of application message octets. Application message data may correspond to an application message fragment or may cover an entire application message. OCP treats application message data as opaque sequences of octets. Application message data may be empty. <10> data: Same as application message data. <11> application message meta-data: Any information related to an application message. Usually, meta-data is information about the application protocol (e.g., protocol name and version) and/or the application message (e.g., remote IP address of an HTTP/1.1 response connection). Application message meta-data may or may = not be duplicated in the application message data. OCP treats application message meta-data as opaque sequences of octets. Application message meta-data may be empty. <12> meta-data: Same as application message meta-data. <13> processor input Communication between the previous hop in the application protocol flow and an OPES processor. <14> processor output Communication between an OPES processor and the = next hop in the application protocol flow. <15> original Referring to application data or meta-data flowing from the OPES processor to an OPES callout server. <16> adapted Referring to application data or meta-data flowing from an OPES callout server to the OPES processor. <17> adaptation: Any kind of access by a callout server, including modification and copying. For example, translating or logging an SMTP message is adaptation of that application message. <18> agent: Client or server for a given communication protocol. A proxy is both a client and a server and, hence, also an agent. For example, OPES processor and callout server are OCP agents. 1.2 Overall Operation <19> [Abbie: Need to add an extra section here, basically this stage happen = after the setup stage, where capability negotiation occur including the = decision on the type of the application protocol that is supported for = that OCP session(s)] The primary purpose of OCP communications is an exchange of application message data and meta-data between an OPES processor and a callout server. Such exchange allows the original data and meta-data to be adapted at the callout server, with the result of that adaptation sent back to the OPES processor. OCP facilitates but Rousskov Expires September 29, 2003 [Page = 4] Internet-Draft OPES Callout Protocol (OCP) March = 2003 does not participate in adaptation. [Abbie: OCP is a protocol, it is = just a transport, I suggest to delete the sentence] OCP [Abbie: = transport] transfers (delete) but does not interpret data or meta-data. previous application hop ------------------------ | (processor input) | V +---------+ [Abbie:or partially adapted] +-------+ | OPES | =3D=3D (original data flow) =3D=3D> |callout| |processor| <=3D=3D (adapted data flow) =3D=3D=3D |server = | +---------+ +-------+ | (processor output) | V -------------------- next application hop data flows for a single OPES processor and callout server --- communications using application protocol =3D=3D=3D communications using OCP Figure 1 <20> OPES processor establishes OPES connections with callout servers for the purpose of exchanging [Abbie: OCP messages] application messages = and meta-data with the callout server(s). Upon receiving an application message (processor input), the OPES processor may pre-process it to extract and manipulate well-known parts (e.g., HTTP message headers or SMTP message body) in order to subject just those parts to callout services. The OPES processor then builds meta-data and forwards meta-data and complete or partial application message data to the callout server (original [Abbie: can also be partially adapted, = example translate English to German and then use callout server to do = text to audio] data flow). For the purpose of OCP, the result of OPES processor's preprocessing is still an application message [[Abbie: not needed here if we just clarify what OCP = messages are from the start]. Naturally, OPES processor and associated = callout services must agree on what application messages are acceptable (see section XXX for information on OCP negotiations) [Abbie:Need to specify = negotiation here]. <21> The callout server receives data and meta-data sent by the OPES processor ([Abbie: Not really in the genral case]original data = flow). The callout server analyses meta-data and adapts data as it comes in. The server usually builds its = version of meta-data and sends adapted data back to the OPES processor as soon as possible (adapted data flow). [Abbie: Are we ruling out the = possibility that the OPEs processor will send HTTP redirect to the = client and asks the callout server to adapt the connection, for example = an adapted stream for low bandwidth] <22> Finally, the OPES processor receives and interprets callout server Rousskov Expires September 29, 2003 [Page = 5] Internet-Draft OPES Callout Protocol (OCP) March = 2003 meta-data, optionally post-processes received data, and then = forwards it either to the next application hop or to a callout server. <23> Under certain conditions, a callout server may remove itself from = the application message processing loop. OPES processor and callout server may exchange OCP messages related to their configuration and state but unrelated to specific application messages. A single OPES processor can communicate with many callout servers and vice versa. It is possible to think of an OPES processor as an ``OCP client'' = and of a callout server as an ``OCP server''. The OPES architecture document [I-D.ietf-opes-architecture] describes overall operation in detail. <24> OCP is application agnostic and should apply well to different application protocols such as HTTP, SMTP, and RTSP. Naturally, = [Abbie: Delete] not every application protocol can be used with OCP. This specification documents known application scope limitations in the "Application Protocol Requirements" Section [XXX]. 1.3 Protocol Development Status <25> Several important OCP details are still unknown. OCP transport protocol(s) have not been selected. Encoding of OCP messages is not yet documented. This specification is not yet suitable for writing OCP implementations. <26> The plan is to add necessary details and bindings to the future versions of this document until the specification is complete. The To-do Section [XXX] contains a list of to-be-implemented items. Rousskov Expires September 29, 2003 [Page = 6] Internet-Draft OPES Callout Protocol (OCP) March = 2003 2. Messages <27> OCP message is a basic unit of communication between an OPES processor and a callout server. Message is a sequence of octets formatted according to syntax rules defined in Section XXX. Message semantics is defined in Section XXX. Messages are transmitted over OCP connections. <28> OCP messages deal with connection and transaction management as well as application data exchange between a single OPES processor and a single callout server. Some messages can only be emitted by an OPES processor; some only by a callout server; some can be emitted by = both OPES processor and callout server. Some messages require responses (one could call such messages "requests"); some can only be used in response to other messages ("responses"); some may be sent without solicitation and/or may not require a response. [Abbie: How about if we classify messages as control and data related] Rousskov Expires September 29, 2003 [Page = 7] Internet-Draft OPES Callout Protocol (OCP) March = 2003 3. Transactions <29> OCP transaction is a logical sequence of OCP messages processing a single original application message. The result of the processing = may be zero or more application messages, adapted from the original. A typical transaction consists of two message flows: a flow from the OPES processor to the callout server (sending original application message) and a flow from the callout server to the OPES processor (sending adapted application messages). The number of application messages produced by the callout server and whether the callout server actually modifies original application message may depend on the requested callout service and other factors. The OPES processor or the callout server can terminate the transaction by sending a corresponding message to the other side. <30> A OCP transaction starts with a explicit 'xaction-start' message = sent by the OPES processor. A transaction ends with the first 'xaction-end' message, explicit or implied, which can be sent by either side. Zero or more OCP messages associated with the transaction can be exchanged in between. [Abbie: We need a flow diagram here with may be a table that shows the = interaction, I also suggest the use of a message structure (a figure) = that shows the overall general format of a message] Rousskov Expires September 29, 2003 [Page = 8] Internet-Draft OPES Callout Protocol (OCP) March = 2003 4. Connections <31> OCP connection is a logical abstraction representing a stream of possibly interleaved OCP transactions and transaction-independent messages. Connections allow for efficient handling of state common = to several OCP transactions, including processing prioritization. <32> (XXX: OCP transport binding(s) will determine how callout = connections are mapped to transport connections. For example, if raw TCP is the transport, than a TCP connection will correspond to a callout connection. If BEEP over TCP is used, than a BEEP channel will correspond to a callout connection, allowing callout connection multiplexing over a single TCP connection.) [Abbie: How does this relate to a session? I think we should use a = session as opposed to a connection, since a session can have multiple = connections???] Rousskov Expires September 29, 2003 [Page = 9] Internet-Draft OPES Callout Protocol (OCP) March = 2003 5. Message Parameter Definitions <33> <34> [Abbie: do u mean an OPES processor ID] [Abbie: General remark on the whole section: It is still look weak and = not easy to read at all, we really need to have a figure or a atble = that shows how a message look like and the various parameters, we need = better description of why things are needed and how it is used, I could = see that the reader that was not involved in OPES list will find this = section very confusing] client: An OPES processor description. The description MAY be used by callout server for logging and similar informational purposes. <35> priority: OCP connection priority, as a signed integer value. = Default priority is zero. Higher values correspond to more "important" connections that MAY be checked and processed more often. Support for connection priorities is OPTIONAL. However, callout server implementations SHOULD NOT knowingly violate priority settings, including the default value of zero (where violation is defined = as treating lower priority connection as more important than a = higher priority connection). <36> xid: OCP transaction identifier. Uniquely identifies an OCP transaction originated by a given OPES processor. <37> rid: OCP request identifier. Uniquely identifies an OCP request message within an OCP connection. Request identifiers are used to match certain requests and responses. <38> service: OPES service identifier and optional service parameters. <39> am-id: Application message identifier. Uniquely identifies an application message within an OCP transaction. <40> data: Application message data. OCP agents may interpret data, but OCP itself treats data as an opaque sequence of bytes. Usually, data contains fragments of application message headers and/or payload. <41> meta-data: Application message meta-data. OCP agents may interpret meta-data, but OCP itself treats meta-data as an opaque sequence of bytes. Usually, meta-data will contain information about application protocol (name, version), application message kind (request or response), as well as message source and/or destination addresses. <42> size: Attached data size in octets. The value is the size of the "data" parameter value. The "data" parameter MUST be present = when "size" parameter is used and vice-versa. The value of "size" = would be equal to the transfer-length of the entire application message only if the entire application message is transmitted in one "data" parameter. Rousskov Expires September 29, 2003 [Page = 10] Internet-Draft OPES Callout Protocol (OCP) March = 2003 <43> size-request Requested data size in octets. The value is the size of application data requested by the sender. <44> offset: Application data offset. The offset of the first application byte has a value of zero. The offset is never negative. The value applies to the data attached to an OCP message. <45> modified: A boolean parameter. When used together with the "data" parameter, the value indicates that the attached data fragment = has been modified by the callout server, compared to its original value received from the OPES processor; says nothing about other fragments. When used with the 'app-message-start' message, indicates that the corresponding application message has been modified or will be modified (i.e., one or more of the corresponding messages with "data" parameter will probably have a "modified" parameter set). Only the callout server may send this flag. This parameter can be used with any OCP message that has an "am-id" parameter. <46> copied: A flag indicating that a copy of the attached application data is being kept at the OPES processor. Only the OPES processor may send this flag. This parameter can be used with any OCP message that may carry application message data. (XXX: it is yet unclear when OPES processor commitment to preserve the data may end.) <47> sizep: Remaining application data size prediction in octets. The value excludes data in the current OCP message, if any. The prediction applies to a single application message. This = parameter can be used with any OCP message that has am-id parameter. <48> modp: Future data modification prediction in percents. A modp value of 0 (zero) means the sender predicts that there will be no data modifications. A value of 100 means the sender is predicts that there will be data modifications. The value excludes data in the current OCP message, if any. The prediction applies to a single application message. This parameter can be used with any OCP message that has am-id parameter. <49> result: OCP processing result. May include integer status code and textual information. <50> error: A flag indicating abnormal conditions at the sender that cannot be expressed via result parameter. It is RECOMMENDED that the recipient deletes all state associated with the corresponding OCP message. Rousskov Expires September 29, 2003 [Page = 11] Internet-Draft OPES Callout Protocol (OCP) March = 2003 <51> feature: A OCP feature identifier with optional feature parameters. Used to declare support and negotiate use of OCP optional = features (e.g., copying of data chunks at the OPES processor). Rousskov Expires September 29, 2003 [Page = 12] Internet-Draft OPES Callout Protocol (OCP) March = 2003 6. Message Definitions <52> [Abbie: General remarks as in section 5] Senders MUST use message format specified in this section. (XXX note that at this time, the only "format" specified is the set of message parameters, but this will change as we add transport bindings and encodings). <53> Recipients MUST be able to parse messages in the specified format. If a malformed message is received, the recipient MUST terminate processing of the corresponding OCP connection using = 'connection-end' message with an error flag. If an unknown message or message parameter is received, the recipient MUST ignore it, but MAY report (e.g., log) it. <54> Except for messages that introduce new identifiers, all sent identifiers MUST be known (i.e., introduced and not ended by = previous messages). Except for messages that introduce new identifiers, the recipient MUST ignore any message with an unknown identifier. For example, recipient must ignore a data-have message if the xid parameter refers to an unknown transaction. Message definitions = below clearly state rare exceptions to the above rules. <55> (XXX can we define "ignore"?) (XXX move these rules elsewhere?) <56> (XXX Message parameters in [square brackets] are OPTIONAL. Other parameters are REQUIRED.) 6.1 connection-start <57> <58> Indicates the start of an OCP connection from the OPES processor. A callout server MUST NOT send this message. Upon receiving of this message, the callout server MUST either start maintaining connection state or refuse further processing by responding with a 'connection-end' message. A callout server MUST maintain the state until it receives a message indicating the end of the connection or until it terminates the connection itself. <59> The 'connection-start' message MUST be the first message on an OCP connection. If OCP transport connection delivers a message outside = of the ('connection-start', 'connection-end') boundaries, such a = message MUST be ignored, and the recipient MUST close the corresponding transport connection. <60> There are no OCP connection identifiers because connections are not multiplexed on a logical level. OCP transport protocol binding MUST distinguish OCP connections on a transport level. For example, a Rousskov Expires September 29, 2003 [Page = 13] Internet-Draft OPES Callout Protocol (OCP) March = 2003 single BEEP [RFC3080] channel may be designated to an OCP = connection. 6.2 connection-end <61> <62> Indicates an end of an OCP connection. The recipient MUST free associated state. The destruction of the state ensures that messages outside of OCP connection are ignored. <63> A 'connection-end' message implies 'xaction-end' messages for all transactions opened on this connection. 6.3 connection-priority <64> <65> Sets connection priority, overwriting the previous value. A callout server MUST NOT send this message. This message MUST be ignored if received by an OPES processor. 6.4 connection-service <66> <67> Sets default service for the connection, overwriting the previous value. A callout server MUST NOT send this message. This message = MUST be ignored if received by an OPES processor. 6.5 xaction-start <68> <69> Indicates the start of an OCP transaction. A callout server MUST NOT send this message. Upon receiving of this message, the callout = server MUST either start maintaining transaction state or refuse further processing by responding with a 'xaction-end' message. A callout server MUST maintain the state until it receives a message = indicating the end of the transaction or until it terminates the transaction itself. <70> The OPTIONAL "service" parameter applies to the original application message processed within this OCP transaction boundaries. If "service" is not specified, the "service" parameter from the connection state MUST be used. If the latter is not specified = either, the transaction is invalid and MUST be aborted by the recipient. <71> This message introduces transaction identifier (xid). Rousskov Expires September 29, 2003 [Page = 14] Internet-Draft OPES Callout Protocol (OCP) March = 2003 6.6 xaction-end <72> <73> Indicates the end of the OCP transaction. The recipient MUST free associated state. The destruction of the state ensures that future messages referring to the same transaction, if any, will be ignored. <74> This message terminates the life of the transaction identifier = (xid). <75> A 'xaction-end' message implies 'app-message-end' messages for all associated application messages (XXX: rephrase this and similar into a MUST?). 6.7 app-message-start <76> <77> Indicates the start of processing of an application message. The recipient MUST either start processing the application message (and maintain its state) or refuse further processing with an 'app-message-end' message. The recipient MUST maintain the state until it receives a message indicating the end of application = message processing or until it terminates the processing itself. <78> When 'app-message-start' message is sent to the callout server, the callout server usually sends an app-message-start message back, announcing the creation of an adapted version of the original application message. Such response may be delayed. For example, the callout server may wait for more information to come from the OPES processor. <79> This message introduces application message identifier (am-id). 6.8 app-message-end <80> <81> Indicates the end of application message processing. The recipient MUST free associated state. The destruction of the state ensures = that future messages referring to the same application message, if any, will be ignored. <82> This message terminates the life of the application message identifier (am-id). <83> A 'app-message-end' message implies 'data-end' message for the associated application message. Rousskov Expires September 29, 2003 [Page = 15] Internet-Draft OPES Callout Protocol (OCP) March = 2003 6.9 data-have <84> <85> This is the only OCP message that may carry application data. There MUST NOT be any gaps in data supplied by data-have and data-as-is messages (i.e., the offset of the next data message must be equal to the offset+size of the previous data message) (XXX: we do not need offset then; should we keep it as a validation mechanism?) (XXX: document what to do when this MUST is violated). Zero size is permitted and is useful for communicating predictions without = sending data. <86> When an OPES processor sends a "copied" flag, the OPES processor = MUST keep a copy of the corresponding data (the preservation commitment starts). <87> When an "ack" flag is present, the recipient MUST respond with a 'data-ack' message. 6.10 data-as-is <88> <89> Tells the OPES processor to use "size" bytes of data at copy-am-offset of the copy-am-id application message, as if that = data came from the callout server in a 'data-have am-id offset size> message. The data chunk MUST be under the preservation commitment. = If the OPES processor receives a 'data-as-is> message for data not = under preservation commitment, the message is invalid. Both "am-id" and "copy-am-id" application message identifiers MUST belong to the same OCP transaction. If they do not, the message is invalid. <90> If the data-as-is message is invalid, the OPES processor MUST abort am-id message processing (XXX: document how processing should be aborted). 6.11 data-pause <91> <92> Sent by a callout server, the data-pause message informs the OPES processor that it must stop sending data to the callout server until the callout server explicitly asks for more data using a 'data-need' message. Upon receiving a 'data-pause' message, the OPES processor SHOULD stop sending application message data to the callout server. If the OPES processor stops sending, it SHOULD send a corresponding Rousskov Expires September 29, 2003 [Page = 16] Internet-Draft OPES Callout Protocol (OCP) March = 2003 'data-paused' message to the callout server. Until the OPES processor receives the message, it may continue sending data to the callout server, of course. Thus, when the callout server sends this message, it MUST NOT mark the application message as "paused". (XXX: should we use MUST or MAY instead of SHOULDs above?) <93> An OPES processor MUST NOT send this message. A callout server MUST ignore this message if it receives it. 6.12 data-paused <94> <95> Sent by an OPES processor, the 'data-paused' message informs the callout server that there will be no more data for the specified application message until the callout server explicitly asks for = data using a 'data-need' message. After sending a 'data-paused' message, the OPES processor MUST stop sending application message data to the callout server. At that time, there may be still unprocessed data in the callout server queue, of course. When the callout server = receives the message, it MAY mark the application message as "paused". If the callout server receives data for a paused message (a violation of = the above MUST), the callout server MAY abort application message processing. <96> A callout server MUST NOT send this message. An OPES processor MUST ignore this message if it receives it. 6.13 data-end <97> <98> Informs the recipient that there will be no more data for the corresponding application message. If the recipient receives more data after the data-end message, it MUST abort application message processing. <99> A data-end message ends any data preservation commitments associated with the corresponding application message. 6.14 data-need <100> <101> Informs the OPES processor that the callout server needs more application message data. The "offset" parameter indicates the = amount of data already received. <102> Rousskov Expires September 29, 2003 [Page = 17] Internet-Draft OPES Callout Protocol (OCP) March = 2003 If a "size" parameter is present, its value is the suggested data size, and it MAY be ignored by the OPES processor. An absent "size" parameter implies "any size". The callout server MUST clear the "paused" state of the application message processing just before sending this message. <103> The OPES processor MUST ignore a data-need message if the OPES processor already sent request data. <104> An OPES processor MUST NOT send data-need messages (XXX: should we give an OPES processor the same abilities to pause/resume message processing that a callout server has?) 6.15 data-ack <105> <106> Informs the OPES processor that the corresponding data chunk has = been received by the callout server. <107> An optional "wont-forward" flag terminates preservation commitment for the corresponding data, if any. The flag is defined for callout server 'data-ack' messages only. <108> Responding with 'data-ack' messages to 'data-have' messages with a "please-ack" flag is REQUIRED. Responding with 'data-ack' messages = to 'data-have' messages without an "ack" flag is OPTIONAL. Implementations SHOULD be able to support debugging mode where every 'data-have' message is acked. (XXX: should we require responses for 'data-as-is> messages as well?) <109> A 'data-ack' response SHOULD be sent as soon as possible. If the callout server does not know immediately whether it will forward the data, it MUST respond without a "wont-forward" flag. If, at any = time, the callout server decides that it will not forward the data, it SHOULD send a 'data-ack' message with a "wont-forward" flag. Thus, multiple 'data-ack' messages and unsolicited 'data-ack' messages are allowed. <110> Sending of a 'data-ack' message means that a complete 'data-have' message has been received, but does not imply that the data has been processed in any other way. <111> The 'data-ack' mechanism has several purposes: to allow OPES processor to gauge the speed at which the callout server is = receiving data (for optimization purposes); to send back "wont-forward" notifications; and to assist in debugging OCP communications. Rousskov Expires September 29, 2003 [Page = 18] Internet-Draft OPES Callout Protocol (OCP) March = 2003 6.16 i-am-here <112> <113> Parameterless form informs the recipient that the sender is still maintaining the OCP connection. If "xid" or "am-id" identifier(s) = are used, the message informs the recipient that the sender is still processing the corresponding transaction or an application message. <114> An 'i-am-here' message MAY be sent without solicitation. In such case, it MUST NOT have a "rid" parameter. <115> An 'i-am-here' message MUST be sent in response to an = 'are-you-there' request. The "rid" value in the response MUST be set to "rid" value of the request. The response MUST have the same set of "xid" and "am-id" parameters if those identifiers are still valid. The = response MUST NOT use invalid identifiers. 6.17 are-you-there <116> <117> Solicits an immediate 'i-am-here' response. If the response does not use the same set of "xid" and "am-id" parameters, the recipient MAY assume that missing identifier(s) correspond to OCP transaction or application message that was not maintained at the time the response was generated. <118> The recipient MUST handle an 'are-you-there' request even if transaction or application message identifiers are invalid from the recipient point of view. Normally, messages with invalid identifiers are ignored. 6.18 do-you-support <119> 6.19 i-do-support <120> 6.20 i-dont-support <121> 6.21 please-use <122> Rousskov Expires September 29, 2003 [Page = 19] Internet-Draft OPES Callout Protocol (OCP) March = 2003 6.22 i-will-use <123> 6.23 i-wont-use <124> Rousskov Expires September 29, 2003 [Page = 20] Internet-Draft OPES Callout Protocol (OCP) March = 2003 7. Application Protocol Requirements <125> Not all application protocols can be adapted with OCP. Compiling a complete list of known limitations is impossible since "application protocol" is not a well defined term. However, listing known limitations can help it determining OCP applicability. This section is not a normative part of the OCP specification. <126> <127> Application protocol messages must have byte boundaries. OCP can only handle application messages with the number of bits = divisible by 8. <128> XXX Rousskov Expires September 29, 2003 [Page = 21] Internet-Draft OPES Callout Protocol (OCP) March = 2003 8. IAB Concerns <129> Document how OCP addresses applicable IAB concerns. XXX. Rousskov Expires September 29, 2003 [Page = 22] Internet-Draft OPES Callout Protocol (OCP) March = 2003 9. Security Considerations <130> Document. XXX. Rousskov Expires September 29, 2003 [Page = 23] Internet-Draft OPES Callout Protocol (OCP) March = 2003 10. Compliance <131> Only normative parts of this specification affect implementation compliance. Normative parts are either explicitly marked as such using the word "normative" or are phrases containing capitalized keywords from [RFC2119]. Definitions of terms used by normative = parts are, of course, normative as well. <132> An implementation is not compliant if it fails to satisfy one or = more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or = REQUIRED level and all the SHOULD level requirements for its protocols is = said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant". Rousskov Expires September 29, 2003 [Page = 24] Internet-Draft OPES Callout Protocol (OCP) March = 2003 11. To-do <133> <134> compliance: Do we really need two levels of compliance (conditional and unconditional)? <135> timeouts: document what messages cause what timers to be [re]set. <136> modified: should this parameter be required? Is it possible that = the callout server does not know whether the data got modified (consider service outsourcing scenario or some complex = permutation of a large image that may or may not result in a different image while it would be prohibitively expensive to keep a copy of the original data and to compare adapted data with the original). = When the server does not know, should it say "yes" to be safe (if the parameter is required), or should it confess with "I do not know" (by omitting the parameter or using 3-way logic)? <137> meta-data format: How/when do OPES processor and callout server = agree on meta-data format and contents? Note that meta-data should usually describe actual data encoding. Data-encoding may, = however, be also negotiated. How? When? <138> meta-trailer: We assume that meta-data is known in advance and = cannot be updated after some data has been sent. That is, we assume that meta-data is known when the application message starts. That is not true in general because some protocols (including HTTP) have support for trailers (meta-information after the payload). Should we add support for passing meta-data with 'app-message-end' or a similar "end" message? <139> copied: When can an OPES processor destroy a copy? <140> asis: Can a callout server refer to parts of [copied] data messages from the OPES processor? If yes, do we need to worry about fragmentation if yes? If no, will this restriction kill the optimization for mid-size application messages (the common case?) that are likely to be passed to the callout server in just one or two chunks? <141> partial: Should we support partial application message exchange (exchange only a part of the application message)? Who decides what parts to exchange? Should the callout server be able to ask which part it wants? How will it describe the part if it has not seen the entire message? Rousskov Expires September 29, 2003 [Page = 25] Internet-Draft OPES Callout Protocol (OCP) March = 2003 <142> loss: Should OPES processor be able to signal loss of data to the callout server. The current wording assumes that offset is incremented using sizes of actually received data fragments; if the processor detects loss it cannot pass that information and = can only hope that the callout server will notice (by interpreting = the data) or will not care (the server may be application- and/or loss-agnostic; e.g., a logging or billing server) <143> break: allow a callout server to get out of the processing loop without losing the data. <144> fast track: Document messages that may be sent on alternative connections. Require other-connections messages to be duplicated on the primary connection. <145> modp: Min and max values (0 and 100) should be "commitments" rather than "probabilities". <146> transactions-end: Decide whether we need a 'transactions-end' = message to terminate multiple transactions efficiently. Is terminating a connection good enough? <147> error: Do we need this flag or should we use result codes to relay the same meaning? <148> abort negotiation: Should we let the other side affect the abort decision on OPES level? Perhaps the callout server is doing some logging or accounting and MUST see every byte received by the = OPES processor, even if the application message is aborted by the processor. Should we add some kind of 'xaction-need-all' message? Or should we assume that the dispatcher always knows callout server needs and vice versa? <149> proxying Can OCP be proxied above transport layer? Perhaps to implement parts of a given service, transparently to the OPES processor? <150> normative IDs: To be normative, OPES Internet-Drafts must be = replaced with corresponding RFCs when the latter are published. Rousskov Expires September 29, 2003 [Page = 26] Internet-Draft OPES Callout Protocol (OCP) March = 2003 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-opes-architecture] Barbir, A., "An Architecture for Open Pluggable Edge Services (OPES)", draft-ietf-opes-architecture-04 (work = in progress), December 2002. Rousskov Expires September 29, 2003 [Page = 27] Internet-Draft OPES Callout Protocol (OCP) March = 2003 Informative References [I-D.ietf-opes-protocol-reqs] Beck, A., "Requirements for OPES Callout Protocols", draft-ietf-opes-protocol-reqs-03 (work in progress), December 2002. [I-D.ietf-opes-scenarios] Barbir, A., "OPES Use Cases and Deployment Scenarios", draft-ietf-opes-scenarios-01 (work in progress), August 2002. [I-D.ietf-fax-esmtp-conneg] Toyoda, K. and D. Crocker, "SMTP Service Extension for = Fax Content Negotiation", draft-ietf-fax-esmtp-conneg-06 = (work in progress), February 2003. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. Author's Address Alex Rousskov The Measurement Factory 1200 Pearl Street, Suite 70 Boulder, CO US EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/ Rousskov Expires September 29, 2003 [Page = 28] Internet-Draft OPES Callout Protocol (OCP) March = 2003 Appendix A. Change Log <155> <156> o introduced a notion of meta-data to both simplify OCP and make = OCP agnostic to application meta-data; previous approach essentially assumed existence of a few common properties like protocol name = or application message source/destination while not allowing any other properties to be exchanged between OCP agents); specific meta-data format/contents is not important to OCP but OCP will help agents to negotiate that format/contents <157> o removed wording implying that OCP adapts application messages; = OCP only used to exchange data and meta-data (which facilitates adaptation) <158> o changed most of the definitions; added definitions for meta-data, original/adapted flows, and others <159> o split 'data-pause' message into 'data-pause' request by the callout server and 'data-paused' notification by the OPES processor; fixed "paused" state management <160> o added motivation for data acking mechanism <161> o replaced "am-proto", "am-kind", "am-source", and "am-destination" parameters with "meta-data" <162> o replaced SERVER and CLIENT placeholders with "callout server" and "OPES processor" <163> o added editing marks Rousskov Expires September 29, 2003 [Page = 29] Internet-Draft OPES Callout Protocol (OCP) March = 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rousskov Expires September 29, 2003 [Page = 30] Internet-Draft OPES Callout Protocol (OCP) March = 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rousskov Expires September 29, 2003 [Page = 31] ------_=_NextPart_000_01C2FC7E.0D7D0090-- From owner-ietf-openproxy@mail.imc.org Sun Apr 6 17:15:43 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06388 for ; Sun, 6 Apr 2003 17:15:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36L4lJM022604 for ; Sun, 6 Apr 2003 14:04:47 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36L4lre022603 for ietf-openproxy-bks; Sun, 6 Apr 2003 14:04:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h36L4kJM022597 for ; Sun, 6 Apr 2003 14:04:46 -0700 (PDT) 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 h36L4a225480; Sun, 6 Apr 2003 17:04:37 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 17:04:37 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754055BD6F4@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES Group Subject: RE: feedback: OCP version head_sid2 thread: Try 2 Date: Sun, 6 Apr 2003 17:04:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FC80.2178142A" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FC80.2178142A Content-Type: text/plain Hi, See remarks inline Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Sunday, April 06, 2003 4:15 PM > To: OPES Group > Subject: Re: feedback: OCP version head_sid2 thread: Try 2 > > > On Sun, 6 Apr 2003, Abbie Barbir wrote: > > > application message: A sequence of octets that OPES processor > > designates for callout service processing or a > sequence of octets > > that callout server sends back to the OPES processor. > Usually, an > > application message is the basic unit of application protocol > > communication, as defined by that application protocol (e.g., > > HTTP/1.1 message). (XXX: This definition is bad because OCP > > messages themselves are also sequence of octets that > OCP agents > > send to each other. How to distinguish "OCP" from > "application" > > if we do not have an application data definition? > What we want to > > say is that application message is whatever an OCP agent has > > marked as such. How to say that?) > > > > I still do not like this defintion at all. > > > > An application message is still an application message whether OPES > > processor will send it to the callout server or not. We need to > > remember that in some cases the OPES processor will do all the work > > and if a trigger happens such as CPU watermark, the > processor will use > > the callout server as an additional helper. > > It is even worth than the above. We should try really hard to > keep OCP independent from the application (and, hence, > application messages). It is very important to do that to > make OCP more "agnostic". > Abbie: Agreed > As somebody said on this list before, OCP should not care > what the application message is. The difficult part is that > OCP has to identify application messages without carrying > what they are. That is what I meant in the above XXX > comments. OPES processor decides what an "application message > is". OPES processor may decide to forward true application > message "as is". It may decide to extract the payload and > forward just that. Or it can apply 100 transformations, > change the application protocol and encoding, and only then > subject the "application message" to OCP processing. The > callout server can do exactly the same, regardless of what > the OPES processor did! Abbie: Yes, that what I was trying to stay by seperating the OCP message from the Application message for a given protocol. The way I see it is that if a session is opened between the OPES processor and the callout server, that session is related to the supported application protcol. The indication of what the application protocol should be is done at setup!!!!! > > How do define that? The current definition defines it, but it > makes no distinction between "data octets" (which are > application message > data) and "OCP octets" (which are OCP message structures). > That is what needs to be fixed. > > > Furthermore, The OCP should be application agnostic, here I > think we > > should differentiate between the following: > > > > Application +---------------+ OCP Message +----------------+ > > Protocol --->| OPES Processor| ---------------> | Callout Server | > > Message <--- | | <--------------- | | > > +---------------+ +----------------+ > > > > In this regard, it is possible to have only one OCP binding > to TCP/IP > > regardless of the Application layer Protocol > > Sure, that's understood and is not the problem. Note that, > from OCP point of view, your leftmost part (Application > Protocol Message) does not exist. Agreed. That is used for illustration purposes. > > > The same thing can happen for data > > > > Application +---------------+ OCP Data +----------------+ > > Protocol --->| OPES Processor| ---------------> | Callout Server | > > Data <--- | | <--------------- | | > > +---------------+ +----------------+ > > There is no "OCP data", really. There is only application > data (original or preprocessed or adapted). > NOP. This is data that is associated with an OCP message, regardless of where the data was originated from (at the higher level). > > So I think that in the general case an OCP message can be one of the > > following: > > 1. Identical Application message (just forwarded) > > No, that cannot be an OCP message, only OCP message payload. > OCP is a protocol, it cannot forward application messages > without wrapping them in OCP headers/structures. > Abbie: That is a given, Sorry if I did not spill it in detail. Same applies for next remarks. > > 2. Partial Application message with some modification > > Probably same problem as above unless adding OCP headers is > "some modification". Application message can only be OCP payload. > > > 3. A message that is infered from an Application message. > > > > Thus, we should make distinction about an OCP message and an > > application message. > > We should, but that it easy. Nobody is going to confuse OCP > messages from application messages. OCP defines OCP > messages. The problem is to define application message so > that implementors know what they can pass across OCP and what > can they identify using am-id. That is very important. > > > So here is my proposal: > > > > 1. Application message: > > A sequence of octets that OPES processor accept for further > processing > > by itself or with the additional help from a callout > server. Usually, > > an application message is the basic unit of application protocol > > communication, as defined by that application protocol > (e.g.,HTTP/1.1 > > message). > > Not good. The application message definition cannot involve > "additional help from a callout server" because that implies > using OCP to get that "help" and one cannot use OCP until the > application message is defined (OCP does not exist yet). > > > Need to introduce the following > > > > 3. OCP Message: > > A sequence of octets that OPES processor use to communicate actions > > required on Application level messages to callout server. > The callout > > server also uses OCP messages to communicate results back > to the OPES > > processor. In some cases, the OCP message may be identical to the > > Application level message. However, in some other cases the OCP > > message can be a partial Application level message or generated > > entirely by an OPES processor. > > This does not work for the above reasons, but the standard > definition in the current draft should be OK (it could be > moved to the definitions section). Again, the problem is with > defining what application message is without just saying > "anything that OCP agent sends" because the latter includes > "OCP messages". See what I am getting at? I know I am not > explaining it well enough. Abbie: Kind off, It is not clear. I still disagree, it does not cover case 3. Abbie ------_=_NextPart_001_01C2FC80.2178142A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: feedback: OCP version head_sid2 thread: Try 2

Hi,

See remarks inline

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Sunday, April 06, 2003 4:15 PM
> To: OPES Group
> Subject: Re: feedback: OCP version head_sid2 = thread: Try 2
>
>
> On Sun, 6 Apr 2003, Abbie Barbir wrote:
>
> > application message: A sequence of octets = that OPES processor
> >       = designates for callout service processing or a
> sequence of octets
> >       that = callout server sends back to the OPES processor.
>  Usually, an
> >       = application message is the basic unit of application protocol
> >       = communication, as defined by that application protocol (e.g.,
> >       = HTTP/1.1 message). (XXX: This definition is bad because OCP
> >       = messages themselves are also sequence of octets that
> OCP agents
> >       send = to each other.  How to distinguish "OCP" from
> "application"
> >       if we = do not have an application data definition? 
> What we want to
> >       say is = that application message is whatever an OCP agent has
> >       marked = as such. How to say that?)
> >
> > I still do not like this defintion at = all.
> >
> > An application message is still an = application message whether OPES
> > processor will send it to the callout = server or not. We need to
> > remember that in some cases the OPES = processor will do all the work
> > and if a trigger happens such as CPU = watermark, the
> processor will use
> > the callout server as an additional = helper.
>
> It is even worth than the above. We should try = really hard to
> keep OCP independent from the application (and, = hence,
> application messages). It is very important to = do that to
> make OCP more "agnostic".
>
Abbie: Agreed

> As somebody said on this list before, OCP should = not care
> what the application message is. The difficult = part is that
> OCP has to identify application messages = without carrying
> what they are. That is what I meant in the = above XXX
> comments. OPES processor decides what an = "application message
> is". OPES processor may decide to forward = true application
> message "as is". It may decide to = extract the payload and
> forward just that. Or it can apply 100 = transformations,
> change the application protocol and encoding, = and only then
> subject the "application message" to = OCP processing. The
> callout server can do exactly the same, = regardless of what
> the OPES processor did!

Abbie: Yes, that what I was trying to stay by = seperating the OCP message from the Application message for a given = protocol. The way I see it is that if a session is opened between the = OPES processor and the callout server, that session is related to the = supported application protcol. The indication of what the application = protocol should be is done at setup!!!!!

>
> How do define that? The current definition = defines it, but it
> makes no distinction between "data = octets" (which are
> application message
> data) and "OCP octets" (which are OCP = message structures).
> That is what needs to be fixed.
>
> > Furthermore, The OCP should be application = agnostic, here I
> think we
> > should differentiate between the = following:
> >
> >  Application  = +---------------+   OCP Message    = +----------------+
> >  Protocol --->| OPES Processor| = ---------------> | Callout Server |
> >  Message <--- = |            = ;   | <--------------- = |            = ;    |
> = >           &n= bsp;   = +---------------+         &= nbsp;        = +----------------+
> >
> > In this regard, it is possible to have = only one OCP binding
> to TCP/IP
> > regardless of the Application layer = Protocol
>
> Sure, that's understood and is not the problem. = Note that,
> from OCP point of view, your leftmost part = (Application
> Protocol Message) does not exist.

Agreed. That is used for illustration = purposes.


>
> > The same thing can happen for data
> >
> >  Application  = +---------------+   OCP = Data       +----------------+
> >  Protocol --->| OPES Processor| = ---------------> | Callout Server |
> >  Data    <--- = |            = ;   | <--------------- = |            = ;    |
> = >           &n= bsp;   = +---------------+         &= nbsp;        = +----------------+
>
> There is no "OCP data", really. There = is only application
> data (original or preprocessed or = adapted).
>
NOP. This is data that is associated with an OCP = message, regardless of where the data was originated from (at the = higher level).

> > So I think that in the general case an OCP = message can be one of the
> > following:
> > 1. Identical Application message (just = forwarded)
>
> No, that cannot be an OCP message, only OCP = message payload.
> OCP is a protocol, it cannot forward = application messages
> without wrapping them in OCP = headers/structures.
>

Abbie: That is a given, Sorry if I did not spill it = in detail.
Same applies for next remarks.

> > 2. Partial Application message with some = modification
>
> Probably same problem as above unless adding = OCP headers is
> "some modification". Application = message can only be OCP payload.
>
> > 3. A message that is infered from an = Application message.
> >
> > Thus, we should make distinction about an = OCP message and an
> > application message.
>
> We should, but that it easy. Nobody is going to = confuse OCP
> messages from application messages.  OCP = defines OCP
> messages. The problem is to define application = message so
> that implementors know what they can pass = across OCP and what
> can they identify using am-id. That is very = important.
>
> > So here is my proposal:
> >
> > 1. Application message:
> > A sequence of octets that OPES processor = accept for further
> processing
> > by itself or with the additional help from = a callout
> server. Usually,
> > an application message is the basic unit = of application protocol
> > communication, as defined by that = application protocol
> (e.g.,HTTP/1.1
> > message).
>
> Not good. The application message definition = cannot involve
> "additional help from a callout = server" because that implies
> using OCP to get that "help" and one = cannot use OCP until the
> application message is defined (OCP does not = exist yet).
>
> > Need to introduce the following
> >
> > 3. OCP Message:
> > A sequence of octets that OPES processor = use to communicate actions
> > required on Application level messages to = callout server.
> The callout
> > server also uses OCP messages to = communicate results back
> to the OPES
> > processor. In some cases, the OCP message = may be identical to the
> > Application level message. However, in = some other cases the OCP
> > message can be a partial Application level = message or generated
> > entirely by an OPES processor.
>
> This does not work for the above reasons, but = the standard
> definition in the current draft should be OK = (it could be
> moved to the definitions section). Again, the = problem is with
> defining what application message is without = just saying
> "anything that OCP agent sends" = because the latter includes
> "OCP messages". See what I am getting = at? I know I am not
> explaining it well enough.

Abbie: Kind off, It is not clear. I still disagree, = it does not cover case 3.


Abbie



------_=_NextPart_001_01C2FC80.2178142A-- From owner-ietf-openproxy@mail.imc.org Sun Apr 6 19:50:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09692 for ; Sun, 6 Apr 2003 19:50:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36NZPJM026548 for ; Sun, 6 Apr 2003 16:35:25 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36NZPG5026547 for ietf-openproxy-bks; Sun, 6 Apr 2003 16:35:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36NZOJM026543 for ; Sun, 6 Apr 2003 16:35:24 -0700 (PDT) Received: from localhost.localdomain (pl109438.fiber.net [216.83.152.26] (may be forged)) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h36NaZKq001178 for ; Sun, 6 Apr 2003 17:36:35 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h36NZ6e25318; Sun, 6 Apr 2003 17:35:06 -0600 Date: Sun, 6 Apr 2003 17:35:06 -0600 Message-Id: <200304062335.h36NZ6e25318@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org Subject: Rules language Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does anyone have Doug Comer's book, "Network Systems and Design Using Network Processors" and would care to comment on the Network Classification Language (NCL) as a possible rule language prototype for OPES? I just heard about the book and NCL - I haven't seen any of it yet. Hilarie From owner-ietf-openproxy@mail.imc.org Sun Apr 6 20:13:23 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10102 for ; Sun, 6 Apr 2003 20:13:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3701KJM027185 for ; Sun, 6 Apr 2003 17:01:20 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3701KHa027184 for ietf-openproxy-bks; Sun, 6 Apr 2003 17:01:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3701IJM027179 for ; Sun, 6 Apr 2003 17:01:18 -0700 (PDT) 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 h3701F200659 for ; Sun, 6 Apr 2003 20:01:15 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 20:01:16 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: OPES Group Subject: FW: feedback: OCP version head_sid2 thread: Try 2 Date: Sun, 6 Apr 2003 20:01:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FC98.CE893122" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FC98.CE893122 Content-Type: text/plain > > -----Original Message----- > > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > > Sent: Sunday, April 06, 2003 5:41 PM > > To: Barbir, Abbie [CAR:1A00:EXCH] > > Subject: Re: feedback: OCP version head_sid2 thread: Try 2 > > > > > > I agree that the definition needs reworking, but I didn't > > understand your comment about "one OCP binding to TCP/IP > > regardless of the Appplication layer Protocol." > > > > Here are my suggestions for rewarding the opening ... I think > > this addresses some of the concerns. Note the questions at the end. > > > > Hilarie > > > > ========================================================= > > > > The normal processing OPES processing is a loop in which the > > OPES processor sends application messages to the callout > > server using OCP and the callout server returns those > > messages, possibly modified, using OCP. This is sometimes > > called a "bump in the wire" architecture. The application > > messages are augmented with metadata, some required by OCP, > > and some encoded by private convention between the two > > processors. OCP is not required to use application message > > framing boundaries when forwarding messages, though the > > original framing boundaries can be indicated by the OCP > > metadata. OCP may also use messages without any application > > message data. OCP has no requirements about application > > message reframing, re-ordering, or reconstructing the > > original application messages. > > > > An OPES processor is at liberty to choose which application > > messages or data about them to send over OCP. All data on > > all connections, or everything on some connections, or > > selected parts, or nothing might be sent over OCP. > > > > OCP communications are primarily about analyzing and/or > > modifying application messages, including the application > > message headers and the application message payloads. > > However, it is possible for OCP to carry only metadata about > > an application message. OPES metadata can also contain > > information about the connection between an application > > endpoint and the OPES processor. > > > > The two processors may exchange data related to their > > configuration, state, and connections (to each other and to > > applications). These messages are OPES messages and are > > specified by this protocol (OCP). > > > > A single OPES processor can communicate with many callout > > servers and vice versa. The OPES architecture [OPES-ARCH] > > describes the configuration possibilities. > > > > OCP is application agnostic but it is not suitable for all > > applications. The OPES metadata can carry application > > specific information. > > > > Question: MUST all the messages forwarded from an application > > connection be on the same OCP connection? I can't determine > > this from the requirements doc. > > > > Question: Should we be more careful about the notion of an > > application message (header and payload), applicaton message > > transmittal unit ("chunk"), and application/OPES connection? > > For my own part, I'd find it helpful if people would use > > standard terms for these, because it's so easy to become > > confused about which part is meant. Usually it doesn't > > matter for "messages", so I think we also need a term meaning > > "anything sent on the application connection". > > > > > > > ------_=_NextPart_001_01C2FC98.CE893122 Content-Type: text/html FW: feedback: OCP version head_sid2 thread: Try 2

> > -----Original Message-----
> > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> > Sent: Sunday, April 06, 2003 5:41 PM
> > To: Barbir, Abbie [CAR:1A00:EXCH]
> > Subject: Re: feedback: OCP version head_sid2 thread: Try 2
> >
> >
> > I agree that the definition needs reworking, but I didn't
> > understand your comment about "one OCP binding to TCP/IP
> > regardless of the Appplication layer Protocol."
> >
> > Here are my suggestions for rewarding the opening ... I think
> > this addresses some of the concerns.  Note the questions at the end.
> >
> > Hilarie
> >
> > =========================================================
> >
> > The normal processing OPES processing is a loop in which the
> > OPES processor sends application messages to the callout
> > server using OCP and the callout server returns those
> > messages, possibly modified, using OCP.  This is sometimes
> > called a "bump in the wire" architecture.  The application
> > messages are augmented with metadata, some required by OCP,
> > and some encoded by private convention between the two
> > processors.  OCP is not required to use application message
> > framing boundaries when forwarding messages, though the
> > original framing boundaries can be indicated by the OCP
> > metadata.  OCP may also use messages without any application
> > message data.  OCP has no requirements about application
> > message reframing, re-ordering, or reconstructing the
> > original application messages. 
> >
> > An OPES processor is at liberty to choose which application
> > messages or data about them to send over OCP.  All data on
> > all connections, or everything on some connections, or
> > selected parts, or nothing might be sent over OCP.
> >
> > OCP communications are primarily about analyzing and/or
> > modifying application messages, including the application
> > message headers and the application message payloads. 
> > However, it is possible for OCP to carry only metadata about
> > an application message. OPES metadata can also contain
> > information about the connection between an application
> > endpoint and the OPES processor.
> >
> > The two processors may exchange data related to their
> > configuration, state, and connections (to each other and to
> > applications).  These messages are OPES messages and are
> > specified by this protocol (OCP).
> >
> > A single OPES processor can communicate with many callout
> > servers and vice versa.  The OPES architecture [OPES-ARCH]
> > describes the configuration possibilities.
> >
> > OCP is application agnostic but it is not suitable for all
> > applications.  The OPES metadata can carry application
> > specific information.
> >
> > Question: MUST all the messages forwarded from an application
> > connection be on the same OCP connection?  I can't determine
> > this from the requirements doc.
> >
> > Question: Should we be more careful about the notion of an
> > application message (header and payload), applicaton message
> > transmittal unit ("chunk"), and application/OPES connection? 
> > For my own part, I'd find it helpful if people would use
> > standard terms for these, because it's so easy to become
> > confused about which part is meant.  Usually it doesn't
> > matter for "messages", so I think we also need a term meaning
> > "anything sent on the application connection".
> >
> >
> >
>

------_=_NextPart_001_01C2FC98.CE893122-- From owner-ietf-openproxy@mail.imc.org Sun Apr 6 20:13:39 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10126 for ; Sun, 6 Apr 2003 20:13:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3700TJM027148 for ; Sun, 6 Apr 2003 17:00:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3700Th2027147 for ietf-openproxy-bks; Sun, 6 Apr 2003 17:00:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3700RJM027141 for ; Sun, 6 Apr 2003 17:00:27 -0700 (PDT) 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 h3700O200542 for ; Sun, 6 Apr 2003 20:00:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 20:00:25 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754055BD712@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: OPES Group Subject: FW: feedback: OCP version head_sid2 thread: Try 2 Date: Sun, 6 Apr 2003 20:00:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FC98.AFB0C4C2" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FC98.AFB0C4C2 Content-Type: text/plain > -----Original Message----- > From: Barbir, Abbie [CAR:1A00:EXCH] > Sent: Sunday, April 06, 2003 5:46 PM > To: 'The Purple Streak, Hilarie Orman' > Subject: RE: feedback: OCP version head_sid2 thread: Try 2 > > > Hilarie, > > Thanks, sounds much better now (I will respond once I digest it more). > > Regarding, > > Question: MUST all the messages forwarded from an application > connection be on the same OCP connection? I can't determine > this from the requirements doc. > > You are right, it is not clear, even the definition of a > connection is not clear, since it sounds like a session to me. > > For the sake of simplicity ( I am trying to be careful here > with the choice of words) I think we should state the same > connection. I am sure though that others will disgaree, which > means more state keeping (keeping track of message id/fragments etc..) > > Abbie > > > > -----Original Message----- > > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > > Sent: Sunday, April 06, 2003 5:41 PM > > To: Barbir, Abbie [CAR:1A00:EXCH] > > Subject: Re: feedback: OCP version head_sid2 thread: Try 2 > > > > > > I agree that the definition needs reworking, but I didn't > > understand your comment about "one OCP binding to TCP/IP > > regardless of the Appplication layer Protocol." > > > > Here are my suggestions for rewarding the opening ... I think > > this addresses some of the concerns. Note the questions at the end. > > > > Hilarie > > > > ========================================================= > > > > The normal processing OPES processing is a loop in which the > > OPES processor sends application messages to the callout > > server using OCP and the callout server returns those > > messages, possibly modified, using OCP. This is sometimes > > called a "bump in the wire" architecture. The application > > messages are augmented with metadata, some required by OCP, > > and some encoded by private convention between the two > > processors. OCP is not required to use application message > > framing boundaries when forwarding messages, though the > > original framing boundaries can be indicated by the OCP > > metadata. OCP may also use messages without any application > > message data. OCP has no requirements about application > > message reframing, re-ordering, or reconstructing the > > original application messages. > > > > An OPES processor is at liberty to choose which application > > messages or data about them to send over OCP. All data on > > all connections, or everything on some connections, or > > selected parts, or nothing might be sent over OCP. > > > > OCP communications are primarily about analyzing and/or > > modifying application messages, including the application > > message headers and the application message payloads. > > However, it is possible for OCP to carry only metadata about > > an application message. OPES metadata can also contain > > information about the connection between an application > > endpoint and the OPES processor. > > > > The two processors may exchange data related to their > > configuration, state, and connections (to each other and to > > applications). These messages are OPES messages and are > > specified by this protocol (OCP). > > > > A single OPES processor can communicate with many callout > > servers and vice versa. The OPES architecture [OPES-ARCH] > > describes the configuration possibilities. > > > > OCP is application agnostic but it is not suitable for all > > applications. The OPES metadata can carry application > > specific information. > > > > Question: MUST all the messages forwarded from an application > > connection be on the same OCP connection? I can't determine > > this from the requirements doc. > > > > Question: Should we be more careful about the notion of an > > application message (header and payload), applicaton message > > transmittal unit ("chunk"), and application/OPES connection? > > For my own part, I'd find it helpful if people would use > > standard terms for these, because it's so easy to become > > confused about which part is meant. Usually it doesn't > > matter for "messages", so I think we also need a term meaning > > "anything sent on the application connection". > > > > > > > ------_=_NextPart_001_01C2FC98.AFB0C4C2 Content-Type: text/html FW: feedback: OCP version head_sid2 thread: Try 2

> -----Original Message-----
> From: Barbir, Abbie [CAR:1A00:EXCH]
> Sent: Sunday, April 06, 2003 5:46 PM
> To: 'The Purple Streak, Hilarie Orman'
> Subject: RE: feedback: OCP version head_sid2 thread: Try 2
>
>
> Hilarie,
>
> Thanks, sounds much better now (I will respond once I digest it more).
>
> Regarding,
>
> Question: MUST all the messages forwarded from an application
> connection be on the same OCP connection?  I can't determine
> this from the requirements doc.
>
> You are right, it is not clear, even the definition of a
> connection is not clear, since it sounds like a session to me.
>
> For the sake of simplicity ( I am trying to be careful here
> with the choice of words) I think we should state the same
> connection. I am sure though that others will disgaree, which
> means more state keeping (keeping track of message id/fragments etc..)
>
> Abbie
>
>
> > -----Original Message-----
> > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> > Sent: Sunday, April 06, 2003 5:41 PM
> > To: Barbir, Abbie [CAR:1A00:EXCH]
> > Subject: Re: feedback: OCP version head_sid2 thread: Try 2
> >
> >
> > I agree that the definition needs reworking, but I didn't
> > understand your comment about "one OCP binding to TCP/IP
> > regardless of the Appplication layer Protocol."
> >
> > Here are my suggestions for rewarding the opening ... I think
> > this addresses some of the concerns.  Note the questions at the end.
> >
> > Hilarie
> >
> > =========================================================
> >
> > The normal processing OPES processing is a loop in which the
> > OPES processor sends application messages to the callout
> > server using OCP and the callout server returns those
> > messages, possibly modified, using OCP.  This is sometimes
> > called a "bump in the wire" architecture.  The application
> > messages are augmented with metadata, some required by OCP,
> > and some encoded by private convention between the two
> > processors.  OCP is not required to use application message
> > framing boundaries when forwarding messages, though the
> > original framing boundaries can be indicated by the OCP
> > metadata.  OCP may also use messages without any application
> > message data.  OCP has no requirements about application
> > message reframing, re-ordering, or reconstructing the
> > original application messages. 
> >
> > An OPES processor is at liberty to choose which application
> > messages or data about them to send over OCP.  All data on
> > all connections, or everything on some connections, or
> > selected parts, or nothing might be sent over OCP.
> >
> > OCP communications are primarily about analyzing and/or
> > modifying application messages, including the application
> > message headers and the application message payloads. 
> > However, it is possible for OCP to carry only metadata about
> > an application message. OPES metadata can also contain
> > information about the connection between an application
> > endpoint and the OPES processor.
> >
> > The two processors may exchange data related to their
> > configuration, state, and connections (to each other and to
> > applications).  These messages are OPES messages and are
> > specified by this protocol (OCP).
> >
> > A single OPES processor can communicate with many callout
> > servers and vice versa.  The OPES architecture [OPES-ARCH]
> > describes the configuration possibilities.
> >
> > OCP is application agnostic but it is not suitable for all
> > applications.  The OPES metadata can carry application
> > specific information.
> >
> > Question: MUST all the messages forwarded from an application
> > connection be on the same OCP connection?  I can't determine
> > this from the requirements doc.
> >
> > Question: Should we be more careful about the notion of an
> > application message (header and payload), applicaton message
> > transmittal unit ("chunk"), and application/OPES connection? 
> > For my own part, I'd find it helpful if people would use
> > standard terms for these, because it's so easy to become
> > confused about which part is meant.  Usually it doesn't
> > matter for "messages", so I think we also need a term meaning
> > "anything sent on the application connection".
> >
> >
> >
>

------_=_NextPart_001_01C2FC98.AFB0C4C2-- From owner-ietf-openproxy@mail.imc.org Sun Apr 6 20:29:44 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10340 for ; Sun, 6 Apr 2003 20:29:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h370JXJM027660 for ; Sun, 6 Apr 2003 17:19:33 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h370JXYN027659 for ietf-openproxy-bks; Sun, 6 Apr 2003 17:19:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h370JWJM027655 for ; Sun, 6 Apr 2003 17:19:32 -0700 (PDT) Received: from localhost.localdomain (pl109438.fiber.net [216.83.152.26] (may be forged)) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h370KiKq002322; Sun, 6 Apr 2003 18:20:44 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h370JFl27678; Sun, 6 Apr 2003 18:19:15 -0600 Date: Sun, 6 Apr 2003 18:19:15 -0600 Message-Id: <200304070019.h370JFl27678@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: RE: Need to look at tracing and debuggig Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stepping back for a moment, it seems to me that you need to identify four essential things relevant to a "traceable entity" (Oskar called these "reference points", I believe): 1. The privacy policy at the time it dealt with the message. 2. Identification of the party responsible for setting and enforcing that policy. 3. Information pointing to a technical contact 4. Information that identifies, to the technical contact, the OPES processors involved in processing the message Item 4 can be opaque, i.e., only has meaning to the technical contact. I don't know if we want to standardize the representation of any of this, other than the tracing header names. From a protocol standpoint, it is certainly easiest to just say that every OPES processor is a traceable entity and that callout servers MAY be traceable entities. There has not been any discussion of what triggers tracing. I suppose it must originate from an endpoint (consumer or provider). Is it "per request" or "per connection" or "per something-else" (application-specific)? Or required all the time? There's also the question of "who's asking?" Items 1-3 might be considered sensitive information, relevant to competitors, or even security and privacy relevant. So a consumer might intend a trace request to mean "tell me what is applied by my network service provider and entities he contracts with, and anything else you can find out from the provider, but don't tell the content provider anything." And a caching OPES processor might send requests to content providers with a tracing request that meant "one or more of my consumers has requested tracing" and would cache the response with tracing headers. So, maybe tracing responses should be optional, and there should be a header that means "tracing request received and denied." Of course, that's weird - who received it, who denied it? Some unidentified OPES processor somewhere? I seem to have run into a conundrum here --- should we define tracing for all systems that do not trace themselves? :-) Hilarie From owner-ietf-openproxy@mail.imc.org Sun Apr 6 22:18:01 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12015 for ; Sun, 6 Apr 2003 22:18:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3725tJM001084 for ; Sun, 6 Apr 2003 19:05:55 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3725tFb001083 for ietf-openproxy-bks; Sun, 6 Apr 2003 19:05:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3725sJM001075 for ; Sun, 6 Apr 2003 19:05:54 -0700 (PDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3725cL09340; Sun, 6 Apr 2003 19:05:39 -0700 (PDT) Received: from zsc3c026.us.nortel.com ([47.81.138.26]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2J0VQ5V1; Sun, 6 Apr 2003 19:05:23 -0700 Received: from private2xsth6c (artpt5ns.us.nortel.com [47.140.52.77]) by zsc3c026.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2GHBK7HX; Sun, 6 Apr 2003 19:05:23 -0700 Message-ID: <002101c2fcaa$282ec9b0$4d348c2f@private2xsth6c> X-Sybari-Space: 00000000 00000000 00000000 From: "Reinaldo Penno" To: "The Purple Streak, Hilarie Orman" , References: <200304062335.h36NZ6e25318@localhost.localdomain> Subject: Re: Rules language Date: Sun, 6 Apr 2003 22:05:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Have you looked at RFC2723? ----- Original Message ----- From: "The Purple Streak, Hilarie Orman" To: Sent: Sunday, April 06, 2003 7:35 PM Subject: Rules language > > Does anyone have Doug Comer's book, "Network Systems and Design Using > Network Processors" and would care to comment on the Network Classification > Language (NCL) as a possible rule language prototype for OPES? I just > heard about the book and NCL - I haven't seen any of it yet. > > Hilarie > > From owner-ietf-openproxy@mail.imc.org Mon Apr 7 00:19:49 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13691 for ; Mon, 7 Apr 2003 00:19:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3748mJM004924 for ; Sun, 6 Apr 2003 21:08:48 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3748msO004923 for ietf-openproxy-bks; Sun, 6 Apr 2003 21:08:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3748kJM004919 for ; Sun, 6 Apr 2003 21:08:47 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3748dvj055153; Sun, 6 Apr 2003 22:08:39 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3748dhe055152; Sun, 6 Apr 2003 22:08:39 -0600 (MDT) (envelope-from rousskov) Date: Sun, 6 Apr 2003 22:08:39 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Need to look at tracing and debuggig In-Reply-To: <200304070019.h370JFl27678@localhost.localdomain> Message-ID: References: <200304070019.h370JFl27678@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: On Sun, 6 Apr 2003, The Purple Streak, Hilarie Orman wrote: > Stepping back for a moment, it seems to me that you need to identify > four essential things relevant to a "traceable entity" (Oskar called > these "reference points", I believe): > > 1. The privacy policy at the time it dealt with the message. Maybe, though #2 is probably sufficient. If we include #1, we would have to define what a "privacy policy" is, which is not going to be fun. Moreover, we would have to define what an _acceptable_ (OPES compliant?!) privacy policy is. See my earlier e-mail about that. For starters, are "we have no privacy policy" and "our privacy policy is only available through a court order or for $1,000" acceptable privacy policies? As long as the "responsible party" is identified, OPES responsibility ends. If a user does not like (or cannot find!) that "party" policies, the user can bypass. > 2. Identification of the party responsible for setting and > enforcing that policy. Yes. > 3. Information pointing to a technical contact Should be optional. Info in #2 is the only "point of contact" that outsiders should be able to see. > 4. Information that identifies, to the technical contact, the > OPES processors involved in processing the message > Item 4 can be opaque, i.e., only has meaning to the technical contact. Yes, but also optional, of course. > I don't know if we want to standardize the representation of any of > this, other than the tracing header names. The only reason to standardize representation is to expect some automated processing of this information. I would not spend too much time on this. I would suggest something very basic like: [comment] for every identifier (required URI or empty string, followed by an optional free-flow comment, encoded appropriately depending on the application protocol). This should be good enough for log analyses and similar automated tools but flexible enough to accommodate virtually all human needs. > There has not been any discussion of what triggers tracing. I > suppose it must originate from an endpoint (consumer or provider). > Is it "per request" or "per connection" or "per something-else" > (application-specific)? Or required all the time? I would start by requiring it at all times because: - you cannot, in general, re-trace an old message; network paths and intermediary decisions are not constants; if you do not get a trace with the message, you cannot be sure the bug you saw was caused by the same intermediaries you are now tracing one second later - some messages are impossible, dangerous, and/or costly to repeat The only objection to always-on tracing is the performance and bandwidth overhead. Our design limits the amount of information to the necessary minimum, so we should be safe given we are adapting application protocols and not transport-level things that have to count every bit. > There's also the question of "who's asking?" Items 1-3 might be > considered sensitive information, relevant to competitors, or even > security and privacy relevant. So a consumer might intend a trace > request to mean "tell me what is applied by my network service > provider and entities he contracts with, and anything else you can > find out from the provider, but don't tell the content provider > anything." And a caching OPES processor might send requests to > content providers with a tracing request that meant "one or more of > my consumers has requested tracing" and would cache the response > with tracing headers. I do not think traces reveal anything sensitive other than identities of "systems" that touched our message. Moreover, the latter can be obscured if really needed! I would start with a simple always-on scheme and make it more complex only if there are very specific reasons for that added complexity. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 00:37:14 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14595 for ; Mon, 7 Apr 2003 00:37:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h374RCJM005587 for ; Sun, 6 Apr 2003 21:27:12 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h374RBPw005586 for ietf-openproxy-bks; Sun, 6 Apr 2003 21:27:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h374RAJM005582 for ; Sun, 6 Apr 2003 21:27:10 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h374RDvj055636; Sun, 6 Apr 2003 22:27:13 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h374RDT9055635; Sun, 6 Apr 2003 22:27:13 -0600 (MDT) (envelope-from rousskov) Date: Sun, 6 Apr 2003 22:27:13 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.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: On Sun, 6 Apr 2003, Abbie Barbir wrote: > > > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > > > > > > Here are my suggestions for rewarding the opening ... I think > > > this addresses some of the concerns. Note the questions at the end. Good stuff, thank you! I would just polish the parts that imply that OCP deals with application message modification (it does not, the protocol just shovels data and metadata between the two agents, essentially). You should expect this text in the next draft version (tomorrow?). > > > Question: MUST all the messages forwarded from an application > > > connection be on the same OCP connection? I can't determine > > > this from the requirements doc. You cannot determine this because there is no such rule/implication. There is no required relationship between OCP connections and application connections. The latter may not even exist! We cannot document all non-existing rules, of course, but I will add a note to avoid any confusion. > > > Question: Should we be more careful about the notion of an > > > application message (header and payload), applicaton message > > > transmittal unit ("chunk"), and application/OPES connection? Yes, this is what this thread is about! How to define what an application message is given that the definition is really up to the OPES processor _and_ the callout server. I will try to polish some more to say just that. > > > For my own part, I'd find it helpful if people would use > > > standard terms for these, because it's so easy to become > > > confused about which part is meant. Usually it doesn't > > > matter for "messages", so I think we also need a term meaning > > > "anything sent on the application connection". Application connections are out of OCP scope. In some environments, they might be referred to in metadata, but metadata is opaque to OCP. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 00:46:02 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15057 for ; Mon, 7 Apr 2003 00:46:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h374bHJM005880 for ; Sun, 6 Apr 2003 21:37:17 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h374bG54005879 for ietf-openproxy-bks; Sun, 6 Apr 2003 21:37:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h374bFJM005875 for ; Sun, 6 Apr 2003 21:37:15 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h374bJvj055873; Sun, 6 Apr 2003 22:37:19 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h374bJvg055872; Sun, 6 Apr 2003 22:37:19 -0600 (MDT) (envelope-from rousskov) Date: Sun, 6 Apr 2003 22:37:19 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754055BD712@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754055BD712@zcard0k6.ca.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: On Sun, 6 Apr 2003, Abbie Barbir wrote: > > Question: MUST all the messages forwarded from an application > > connection be on the same OCP connection? I can't determine > > this from the requirements doc. > > > > You are right, it is not clear, even the definition of a > > connection is not clear, since it sounds like a session to me. What is not clear about the OCP connection definition? We should fix whatever is broken. We can change "OCP connection" to "OCP session"; the only reason the draft says "connection" is because that is what OCP requirements draft uses. Should we ignore this minor discrepancy if "session" is more appropriate? > > For the sake of simplicity ( I am trying to be careful here > > with the choice of words) I think we should state the same > > connection. I am sure though that others will disgaree, which > > means more state keeping (keeping track of message id/fragments etc..) Actually, for the sake of simplicity, we should not explicitly try to adapt application connections. Adapting application connections would be the only reason to talk about them in the OCP context. Then we should talk about adapting other application-specific things like sessions, caching, etc. The current intent is for OCP to facilitate adaptation of application message data and metadata. The metadata hides all application-specific things like source IP, session ID, or "connection". That's the beauty of the design, we just need to document/explain it better. Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 00:56:59 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15631 for ; Mon, 7 Apr 2003 00:56:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h374kuJM006111 for ; Sun, 6 Apr 2003 21:46:56 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h374kubK006110 for ietf-openproxy-bks; Sun, 6 Apr 2003 21:46:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h374ksJM006100 for ; Sun, 6 Apr 2003 21:46:55 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h374kwvj056098; Sun, 6 Apr 2003 22:46:58 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h374kwcW056097; Sun, 6 Apr 2003 22:46:58 -0600 (MDT) (envelope-from rousskov) Date: Sun, 6 Apr 2003 22:46:58 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: RE: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754055BD6F4@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754055BD6F4@zcard0k6.ca.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: On Sun, 6 Apr 2003, Abbie Barbir wrote: > Abbie: Yes, that what I was trying to stay by seperating the OCP > message from the Application message for a given protocol. The way I > see it is that if a session is opened between the OPES processor and > the callout server, that session is related to the supported > application protcol. The indication of what the application protocol > should be is done at setup!!!!! Yes, that is what Reinaldo Penno is working on right now. > > How do define that? The current definition defines it, but it > > makes no distinction between "data octets" (which are > > application message data) and "OCP octets" (which are > > OCP message structures). > > That is what needs to be fixed. Yes. > > > The same thing can happen for data > > > > > > Application +---------------+ OCP Data +----------------+ > > > Protocol --->| OPES Processor| ---------------> | Callout Server | > > > Data <--- | | <--------------- | | > > > +---------------+ +----------------+ > > > > There is no "OCP data", really. There is only application > > data (original or preprocessed or adapted). > > > NOP. This is data that is associated with an OCP message, regardless of > where the data was originated from (at the higher level). Well, yes, but this is only a question of a definition. We can have "application data" and "OCP data" and then define a relationship between the two. Alternatively, we can have "application data" only since any "data that is associated with an OCP message" is (by definition) "application data". The latter is the current, perhaps inferior, approach. Once we have a good definition for "application message", it should become less messy. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 11:57:36 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24438 for ; Mon, 7 Apr 2003 11:57:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37FiVJM012676 for ; Mon, 7 Apr 2003 08:44:31 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37FiVE0012675 for ietf-openproxy-bks; Mon, 7 Apr 2003 08:44:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37FiTJM012670 for ; Mon, 7 Apr 2003 08:44:29 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37FiVvj071668; Mon, 7 Apr 2003 09:44:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37FiV6B071667; Mon, 7 Apr 2003 09:44:31 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 09:44:31 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: RE: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.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: On Sun, 6 Apr 2003, Abbie Barbir wrote: > my feed back on the draft attached Thank you! I am incorporating the changes for the next release. Below are questions/clarifications about the questionable items. > +---------+ [Abbie:or partially adapted] +-------+ > | OPES | == (original data flow) ==> |callout| > |processor| <== (adapted data flow) === |server | > +---------+ +-------+ "Or partially adapted" is not necessary; the "original" term definition already covers the "preprocessing" case: original: Referring to application data or meta-data flowing from the OPES processor to an OPES callout server. adapted: Referring to application data or meta-data flowing from an OPES callout server to the OPES processor. That is, whatever OPES processor is sending is considered "original" from OCP point of view. When working on OCP, we need to try really hard to look at things from OCP point of view and not from the application "ends" point of view. Whatever the OPES preprocessor does before or after using OCP is out of OCP scope. If we start bringing preprocessing and other OCP-unrelated actions into the picture, we will make the protocol more complex and will inevitably limit its application by restricting things outside of its competence. This is not "The OPES" protocol. This is just an OCP protocol. It has very specific goal and scope. OPES processors do not have to use OCP to adapt application messages. > <20> > OPES processor establishes OPES connections with callout servers > for the purpose of exchanging [Abbie: OCP messages] application > messages and meta-data with the callout server(s). The purpose is to exchange application messages. OCP messages are just "means" of doing that. > The OPES processor then builds meta-data and forwards meta-data > and complete or partial application message data to the callout > server (original [Abbie: can also be partially adapted, example > translate English to German and then use callout server to do > text to audio] data flow). Translation at the OPES processor is out of OCP scope. Please see my rant above. > For the purpose of OCP, the result of OPES processor's > preprocessing is still an application message > > [[Abbie: not needed here if we just clarify what OCP messages are > from the > start]. This is not about OCP messages, this is about application messages (the definition of which does need an improvement). I will add "original" before "application message" to clarify/emphasize the intent. > Naturally, OPES processor and associated callout services must > agree on what application messages are acceptable (see section > XXX for information on OCP negotiations) [Abbie:Need to specify > negotiation here]. We probably should wait for negotiation details to become available: There may be too much stuff to insert here and a dedicated section may be more appropriate. > <21> > The callout server receives data and meta-data sent by the OPES > processor ([Abbie: Not really in the genral case]original data > flow). Not sure what you mean, but probably the same thing as above -- preprocessing is out of OCP scope; "original" from OCP point of view, not from application point of view. Suggestions for better terms than "original" and "adapted" are very welcome! > The callout server analyses meta-data and adapts data as it comes > in. The server usually builds its version of meta-data and sends > adapted data back to the OPES processor as soon as possible > (adapted data flow). [Abbie: Are we ruling out the possibility > that the OPEs processor will send HTTP redirect to the client and > asks the callout server to adapt the connection, for example an > adapted stream for low bandwidth] I do not see why we are ruling out any possibilities at this point. Can you clarify, including the "adapt the connection" part? > [Abbie: How about if we classify messages as control and data > related] I did that at some early stage, but deleted the results because: - many messages cannot be clearly labeled as "control" or "data related". For example, a 'data-pause' message is both control and data related (it controls data flow). - it is not clear how such classification will help anybody > <30> > A OCP transaction starts with a explicit 'xaction-start' message > sent by the OPES processor. A transaction ends with the first > 'xaction-end' message, explicit or implied, which can be sent by > either side. Zero or more OCP messages associated with the > transaction can be exchanged in between. > > [Abbie: We need a flow diagram here with may be a table that shows > the interaction, I also suggest the use of a message structure (a > figure) that shows the overall general format of a message] I will add a figure showing the nesting of messages. However, we cannot document any message structure now because we did not decide on transport/encoding issues yet. There is no message structure yet, except for the required message name and a list of optional/required parameters. > 4. Connections <31> > OCP connection is a logical abstraction representing a stream of > possibly interleaved OCP transactions and transaction-independent > messages. Connections allow for efficient handling of state > common to several OCP transactions, including processing > prioritization. > <32> > (XXX: OCP transport binding(s) will determine how callout > connections are mapped to transport connections. For example, if > raw TCP is the transport, than a TCP connection will correspond > to a callout connection. If BEEP over TCP is used, than a BEEP > channel will correspond to a callout connection, allowing callout > connection multiplexing over a single TCP connection.) > > [Abbie: How does this relate to a session? I think we should use a > session as opposed to a connection, since a session can have > multiple connections???] What is a session? Please use terminology from the architecture/requirements drafts or define a new term. I do not see any references to "sessions" in the architecture or requirements draft. Is it defined elsewhere? > 5. Message Parameter Definitions > > [Abbie: General remark on the whole section: It is still look weak > and not easy to read at all, we really need to have a figure or a > atble that shows how a message look like and the various parameters, > we need better description of why things are needed and how it is > used, I could see that the reader that was not involved in OPES list > will find this section very confusing] This section does not show how a message looks like because it documents message parts. I will add illustrations to the "2. Messages" section. Note that "6. Message Definitions" subsections already have illustrations for every message. See above regarding message format unavailability. I agree that this (and all other) sections need a lot of polishing, of course. Specific improvements are welcome :). > client: An OPES processor description. The description MAY be > used by callout server for logging and similar informational > purposes. > [Abbie: do u mean an OPES processor ID] Possibly, but I do not know yet. We need to discuss this. Is passing an ID enough? Is it possible that the callout server may need more information about the OPES processor? Negotiation work may clarify some of this. > 6. Message Definitions > <52> > [Abbie: General remarks as in section 5] Yes, same response. Again, I will incorporate all other fixes shortly. The above mentioned ones need more clarifications/discussion. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 13:20:05 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28049 for ; Mon, 7 Apr 2003 13:20:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37H9JJM016307 for ; Mon, 7 Apr 2003 10:09:19 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37H9Jeu016305 for ietf-openproxy-bks; Mon, 7 Apr 2003 10:09:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37H9HJM016301 for ; Mon, 7 Apr 2003 10:09:17 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37H9Ivj073677; Mon, 7 Apr 2003 11:09:18 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37H9I9Y073676; Mon, 7 Apr 2003 11:09:18 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 11:09:18 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.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: > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > > Question: Should we be more careful about the notion of > an application message (header and payload), OCP does not distinguish between application message header and application message payload. OCP treats the entire message as an opaque sequence of octets. Should we explicitly state that "header" and "payload" are not visible to OCP? > applicaton message transmittal unit ("chunk"), I think WG drafts use the term "fragment" instead of "chunk". Fragment may be preferred to avoid collision with HTTP chunked encoding (OCP fragment may spawn HTTP chunk boundaries, of course). Comments? Note that OCP does not use "fragment" much. OCP mostly uses "data" which stands for both a "application message fragment" and a "complete application message". Suggestions for a better term to describe both complete and partial application messages are very welcome. > and application/OPES connection? Application connections are out of OCP scope. Should we state that explicitly? There are no OPES connections, but Hilarie is probably talking about OCP connections. Abbie suggests to rename OCP connections to "sessions". Which term would you prefer? > For my own part, I'd find it helpful if people would use standard > terms for these, because it's so easy to become confused about which > part is meant. Yes, we just need to agree on the "standard". Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 14:18:28 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29698 for ; Mon, 7 Apr 2003 14:18:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37I99JM026653 for ; Mon, 7 Apr 2003 11:09:09 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37I99Pp026652 for ietf-openproxy-bks; Mon, 7 Apr 2003 11:09:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37I97JM026627 for ; Mon, 7 Apr 2003 11:09:07 -0700 (PDT) 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.9/8.12.9) with ESMTP id h37I99Ha086122 for ; Mon, 7 Apr 2003 14:09:09 -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 h37I92c6028092 for ; Mon, 7 Apr 2003 14:09:02 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h37I90Q4010763 for ; Mon, 7 Apr 2003 14:09:02 -0400 (EDT) Message-ID: <3E91BEEC.7040603@mhof.com> Date: Mon, 07 Apr 2003 14:09:48 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 References: <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > There are no OPES connections, but Hilarie is probably talking about > OCP connections. Abbie suggests to rename OCP connections to > "sessions". Which term would you prefer? The protocol requirements draft only talks about "connections", and not about "sessions". Unless something different is refered to, I would suggest to stick with the terminology we've in the existing drafts. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Apr 7 14:32:46 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00093 for ; Mon, 7 Apr 2003 14:32:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37IMUJM029618 for ; Mon, 7 Apr 2003 11:22:30 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37IMUPu029617 for ietf-openproxy-bks; Mon, 7 Apr 2003 11:22:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37IMSJM029607 for ; Mon, 7 Apr 2003 11:22:28 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37IMTvj076496; Mon, 7 Apr 2003 12:22:29 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37IMT1b076495; Mon, 7 Apr 2003 12:22:29 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 12:22:29 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: fixing "application message" mess Message-ID: 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: I may have found a simple and even elegant solution to the current mess with the "application message" definition and related issues. The clue was already in the draft but was disguised by poor presentation. Your comments and questions helped to factor it out. I will be making specific changes to the draft, but I want to share the outline with the list, to give early comments/objections a chance to be reflected in the next draft release. Here is the outline. 0. The core of the problem is in overloading of the term "application". The solution is in specifying exactly which "application" we are talking about and specifying the relationships between different "application" terms. 1. The are three applications in OPES/OCP environment (see diagram at the bottom of this message): - "input application" is specified by the application protocol that OPES processor is using to communicate with the previous application hop ("processor input") - "output application" is specified by the application protocol that OPES processor is using to communicate with the next application hop ("processor output") - "OCP application" is specified by the application protocol that is negotiated between OPES processor and the callout server (they may support several protocols and will have to pick one to use). Usually, input application is the same as output application. Often, input application is the same as OCP application. 2. OCP is concerned with OCP application messages only. OCP agents MUST obey OCP application requirements when exchanging OCP application messages (embedded in OCP messages). OCP places no restrictions on processor input or output and has no requirements concerning the relationship between OCP application messages and processor input or output. Such restrictions and requirements may exist for OPES processors, but are outside of OCP scope. 3. Meta-data may be used by OCP agents to relay information about input and output applications, including information about connections and message boundaries. In other words, let OPES processor worry about its application input and output. OPES processor negotiates with the callout server what OCP application they should use and then handles necessary conversions, if any. Naturally, the processor should not negotiate OCP applications that it cannot convert input application to or output application from. OCP application could be HTTP. Or it could be something like "transfer-encoded HTTP message body with content-type and transfer-encoding passed via meta-data". Etc... Comments? Thanks, Alex. previous application hop ------------------------ | (processor input) | V +---------+ +-------+ | OPES | <== (OCP application) ==> |callout| |processor| |server | +---------+ +-------+ | (processor output) | V -------------------- next application hop legend: === communications using OCP --- communications using other application protocols From subs-reminder@imc.org Mon Apr 7 15:17:21 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02632 for ; Mon, 7 Apr 2003 15:17:19 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JJmJM014450 for ; Mon, 7 Apr 2003 12:19:48 -0700 (PDT) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37JJm1t014449; Mon, 7 Apr 2003 12:19:48 -0700 (PDT) Date: Mon, 7 Apr 2003 12:19:48 -0700 (PDT) Message-Id: <200304071919.h37JJm1t014449@above.proper.com> To: opes-archive@ietf.org Subject: [[659661650]] Subscription to ietf-openproxy for opes-archive@ietf.org 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 Mon Apr 7 15:23:39 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02914 for ; Mon, 7 Apr 2003 15:23:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JE6JM012887 for ; Mon, 7 Apr 2003 12:14:06 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37JE6TJ012885 for ietf-openproxy-bks; Mon, 7 Apr 2003 12:14:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JE5JM012881 for ; Mon, 7 Apr 2003 12:14:05 -0700 (PDT) Received: from f05a-9-246.d1.club-internet.fr ([212.194.104.246] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 192c42-0006Ux-00; Mon, 07 Apr 2003 12:13:55 -0700 Message-Id: <5.2.0.9.0.20030407203158.040af990@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Apr 2003 20:39:24 +0200 To: Alex Rousskov , OPES Group From: jfcm Subject: RE: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: References: <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.nortel.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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 17:44 07/04/03, Alex Rousskov wrote: >That is, whatever OPES processor is sending is considered "original" >from OCP point of view. >When working on OCP, we need to try really hard to look at things from >OCP point of view and not from the application "ends" point of view. I understand that, everyone in here understand that, but think of the reader. He will consider that "orginal" means "as initially entered in the OPES Processor" (I definitly hate that OPES Processor word for the dispatcher here, I do understand the other way around :-). Could we not use someting as "out-bound" and "in-bound" IRT the used "call-out" protocol. It would be consistent. Also nothing prevents the returning in-bound message to be identical to the original if no change was performed. jfc From owner-ietf-openproxy@mail.imc.org Mon Apr 7 15:24:24 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02950 for ; Mon, 7 Apr 2003 15:24:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JEBJM012913 for ; Mon, 7 Apr 2003 12:14:11 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37JEB6O012912 for ietf-openproxy-bks; Mon, 7 Apr 2003 12:14:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JEAJM012903 for ; Mon, 7 Apr 2003 12:14:10 -0700 (PDT) Received: from f05a-9-246.d1.club-internet.fr ([212.194.104.246] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 192c47-0006Ux-00; Mon, 07 Apr 2003 12:14:00 -0700 Message-Id: <5.2.0.9.0.20030407204056.040cd140@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Apr 2003 21:16:05 +0200 To: Alex Rousskov From: jfcm Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 Cc: ietf-openproxy@imc.org In-Reply-To: References: <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 19:09 07/04/03, Alex Rousskov said: > > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > > Question: Should we be more careful about the notion of > > an application message (header and payload), > >OCP does not distinguish between application message header and >application message payload. OCP treats the entire message as an >opaque sequence of octets. Should we explicitly state that "header" >and "payload" are not visible to OCP? YES. Everything which clarfy what we talk about is an absolute need. > > applicaton message transmittal unit ("chunk"), > >I think WG drafts use the term "fragment" instead of "chunk". Fragment >may be preferred to avoid collision with HTTP chunked encoding (OCP >fragment may spawn HTTP chunk boundaries, of course). Comments? > >Note that OCP does not use "fragment" much. OCP mostly uses "data" >which stands for both a "application message fragment" and a "complete >application message". Suggestions for a better term to describe both >complete and partial application messages are very welcome. Data seems appropriate. However this remark seems of interest to quote. In the Minitel X.25 system for example I am investigating, the size of the Message may be of interest if it is smaller than the X.15 window size. It may make the transfer extremely fast. > > and application/OPES connection? > >Application connections are out of OCP scope. Should we state that >explicitly? ABSOLUTELY. For the same reasons. >There are no OPES connections, but Hilarie is probably talking about >OCP connections. Abbie suggests to rename OCP connections to >"sessions". Which term would you prefer? Would these sessions represent the whole message transiting through OCP towards as many services as required ? If yes I would accept the concepts. Interaction otherwise? A session would be all the OCP interactions that a message may perform from the dispatcher to services until sent to the user. So you could talk of the OPES session. Makes sense in French, but I do not know if it is the same in English. > > For my own part, I'd find it helpful if people would use standard > > terms for these, because it's so easy to become confused about which > > part is meant. > >Yes, we just need to agree on the "standard". You sure you want to use OPES Processor the way you do? For me it is opposed to every standard thinking I know. jfc From owner-ietf-openproxy@mail.imc.org Mon Apr 7 15:49:54 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04252 for ; Mon, 7 Apr 2003 15:49:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JenJM017844 for ; Mon, 7 Apr 2003 12:40:49 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37JennS017843 for ietf-openproxy-bks; Mon, 7 Apr 2003 12:40:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37JelJM017839 for ; Mon, 7 Apr 2003 12:40:47 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37Jenvj078377; Mon, 7 Apr 2003 13:40:49 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37JenSM078376; Mon, 7 Apr 2003 13:40:49 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 13:40:49 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: RE: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <5.2.0.9.0.20030407203158.040af990@mail.utel.net> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030407203158.040af990@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: On Mon, 7 Apr 2003, jfcm wrote: > At 17:44 07/04/03, Alex Rousskov wrote: > >That is, whatever OPES processor is sending is considered "original" > >from OCP point of view. > >When working on OCP, we need to try really hard to look at things from > >OCP point of view and not from the application "ends" point of view. > > I understand that, everyone in here understand that, but think of > the reader. > > He will consider that "orginal" means "as initially entered in the > OPES Processor" (I definitly hate that OPES Processor word for the > dispatcher here, I do understand the other way around :-). > > Could we not use someting as "out-bound" and "in-bound" IRT the used > "call-out" protocol. It would be consistent. OK, it is a "choice of a word" question. I think it is very important to use "right" words. Fortunately, it is easy to change the words in the draft so we have time to find good ones. (I am more concerned about the actual definitions and protocol specifics now.) Anyway, since the communication is between two entities (OPES processor and callout server), it is difficult for me to guess which one is "out-bound". "Out" depends on whether you are looking from OPES processor or callout server point of view. We already have output/input for OPES processor, where there is no confusion since we are talking about a single entity (the processor) in the middle of a pipe. Protocols often use request/response terms in these situations. Perhaps we can use "request data" and "response data" instead of "original" and "adapted"? I kind of like "adapted" though. It is the "original" that's confusing. More suggestions? > Also nothing prevents the returning in-bound message to be identical > to the original if no change was performed. True, except, perhaps, for tracing requirements. Recall that "seeing the application data" is a form of adaptation (by definition) because if I can see it, then I can log it; and if I log it, then the user may want to know my privacy policy. If we ignore tracing issues, is there some wording that makes a reader think that "something prevents returning identical messages"? Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 16:06:08 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04610 for ; Mon, 7 Apr 2003 16:06:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JrUJM021737 for ; Mon, 7 Apr 2003 12:53:30 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37JrUbO021735 for ietf-openproxy-bks; Mon, 7 Apr 2003 12:53:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37JrTJM021721 for ; Mon, 7 Apr 2003 12:53:29 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37JrVvj078739; Mon, 7 Apr 2003 13:53:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37JrVBI078738; Mon, 7 Apr 2003 13:53:31 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 13:53:31 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <5.2.0.9.0.20030407204056.040cd140@mail.utel.net> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030407204056.040cd140@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: On Mon, 7 Apr 2003, jfcm wrote: > On 19:09 07/04/03, Alex Rousskov said: > > >OCP does not distinguish between application message header and > >application message payload. OCP treats the entire message as an > >opaque sequence of octets. Should we explicitly state that "header" > >and "payload" are not visible to OCP? > > YES. Everything which clarfy what we talk about is an absolute need. Will do. > Data seems appropriate. However this remark seems of interest to quote. > In the Minitel X.25 system for example I am investigating, the size of the > Message may be of interest if it is smaller than the X.15 window size. It > may make the transfer extremely fast. OCP can relay OCP application message size via size parameter and input/output application message size via meta-data. I am not sure how your remark relates to OCP though. Please clarify. > >Application connections are out of OCP scope. Should we state that > >explicitly? > > ABSOLUTELY. For the same reasons. Will do. > >There are no OPES connections, but Hilarie is probably talking about > >OCP connections. Abbie suggests to rename OCP connections to > >"sessions". Which term would you prefer? > > Would these sessions represent the whole message transiting through > OCP towards as many services as required ? If yes I would accept the > concepts. Interaction otherwise? A session would be all the OCP > interactions that a message may perform from the dispatcher to > services until sent to the user. So you could talk of the OPES > session. Makes sense in French, but I do not know if it is the same > in English. If "many services" are on different callout servers, then your definition of "session" makes sense, but seems to be out of OCP scope since OCP is concerned with single processor - single server communication. If the services are on the same callout server, then your "session" would be in OCP scope. It would be something that may cross OCP connections even. I am not sure why we would need it though. To be able to abort easier? > You sure you want to use OPES Processor the way you do? > For me it is opposed to every standard thinking I know. Not sure what you mean. OPES processor is just an application proxy that outsources processing of some messages. Sounds pretty "standard" to me. Is it not? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 16:38:56 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05346 for ; Mon, 7 Apr 2003 16:38:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37KRWJM002368 for ; Mon, 7 Apr 2003 13:27:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37KRWDn002365 for ietf-openproxy-bks; Mon, 7 Apr 2003 13:27:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37KRUJM002349 for ; Mon, 7 Apr 2003 13:27:30 -0700 (PDT) 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.9/8.12.9) with ESMTP id h37KRWHa087364 for ; Mon, 7 Apr 2003 16:27:32 -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 h37KRQc6038825 for ; Mon, 7 Apr 2003 16:27:26 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h37KROQ4016639 for ; Mon, 7 Apr 2003 16:27:25 -0400 (EDT) Message-ID: <3E91DF5B.7020603@mhof.com> Date: Mon, 07 Apr 2003 16:28:11 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: fixing "application message" mess References: 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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > In other words, let OPES processor worry about its application input > and output. OPES processor negotiates with the callout server what OCP > application they should use and then handles necessary conversions, if > any. Naturally, the processor should not negotiate OCP applications > that it cannot convert input application to or output application from. > > OCP application could be HTTP. Or it could be something like > "transfer-encoded HTTP message body with content-type and > transfer-encoding passed via meta-data". Etc... Provides quite some flexibility, but complicates the negotiation process... Who would specify/standardize possible OCP applications to be used? E.g., who would specify something like "transfer-encoded HTTP message body with content-type and transfer-encoding passed via meta-data". How do we ensure interoperability? By requesting some mandatory OCP applications (e.g. HTTP)? -Markus From owner-ietf-openproxy@mail.imc.org Mon Apr 7 17:50:25 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06951 for ; Mon, 7 Apr 2003 17:50:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37LdeJM016062 for ; Mon, 7 Apr 2003 14:39:40 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37Ldes5016060 for ietf-openproxy-bks; Mon, 7 Apr 2003 14:39:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37LdcJM016051 for ; Mon, 7 Apr 2003 14:39:39 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37Ldfvj081296; Mon, 7 Apr 2003 15:39:41 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37LdfgS081295; Mon, 7 Apr 2003 15:39:41 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 15:39:41 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: fixing "application message" mess In-Reply-To: <3E91DF5B.7020603@mhof.com> Message-ID: References: <3E91DF5B.7020603@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: On Mon, 7 Apr 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > In other words, let OPES processor worry about its application input > > and output. OPES processor negotiates with the callout server what OCP > > application they should use and then handles necessary conversions, if > > any. Naturally, the processor should not negotiate OCP applications > > that it cannot convert input application to or output application from. > > > > OCP application could be HTTP. Or it could be something like > > "transfer-encoded HTTP message body with content-type and > > transfer-encoding passed via meta-data". Etc... > > Provides quite some flexibility, but complicates the negotiation > process... Who would specify/standardize possible OCP applications > to be used? E.g., who would specify something like "transfer-encoded > HTTP message body with content-type and transfer-encoding passed via > meta-data". How do we ensure interoperability? By requesting some > mandatory OCP applications (e.g. HTTP)? The above negotiations (automated or via configuration files) are unavoidable anyway! The only way to eliminate negotiations is to support all pre-defined input/output/OCP application protocols in every implementation, honor their message boundaries, _and_ transfer complete application messages. If we want to make support for an application protocol optional (e.g., some callout servers may not support SMTP but may support HTTP), then OCP agents must negotiate because the agents are no longer 100% compatible "by default". If we want to support partial message exchange (e.g., OPES processor extracts HTTP/SMTP message body and forwards that body along with some MIME headers as meta-information), then OCP agents must negotiate because the callout server needs to know whether it is getting a complete message or just the body. And so on. The proposed solution does not make negotiation more complex. In fact, it actually clarifies negotiation purpose. OCP negotiation must result in an agreement regarding OCP application protocol, which includes the usual things like name, version, message framing, meta-data (headers), etc. If you look at it, it all boils down to how to encode/interpret "meta-data" and how to interpret "data" (what is it I am getting?), something we have to negotiate anyway if we want to remain application agnostic. We can probably agree on the same meta-data encoding/format for all applications. Then, OCP application protocol == required meta-data fields + "data" meaning OPES WG may then publish an "HTTP as an OCP application protocol" draft where the above things will be specified for HTTP. Other working groups and individuals may publish their own application protocol bindings. OCP implementations will have to support at least one binding and able to negotiate it. OPES processors will have to support mapping of their input/output protocols to/from OCP application protocol they support (usually it will be a no-op mapping with exception of tracing). Again, this is no different from what we were going to have; the proposed terminology/approach is meant as a clarification, not an extension! Does the above sound convincing enough? Or do you still think I am opening a pandora box (that was closed before)? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 18:47:30 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09717 for ; Mon, 7 Apr 2003 18:47:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37MaIJM029083 for ; Mon, 7 Apr 2003 15:36:18 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37MaIqM029080 for ietf-openproxy-bks; Mon, 7 Apr 2003 15:36:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37MaGJM029068 for ; Mon, 7 Apr 2003 15:36:16 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37MaJvj082751 for ; Mon, 7 Apr 2003 16:36:19 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37MaJnf082750; Mon, 7 Apr 2003 16:36:19 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 16:36:19 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: OCP version head_sid3 available Message-ID: 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: To the best of my knowledge, all new specific OCP comments that caused no further objections/questions are now applied to the draft. That includes a large blob of text from Hilarie Orman (posted by Abbie Barbir). I also made a few additions/improvements. The [major] change log is quoted below. The latest snapshot, including XML sources for those doing hands-on modifications, is available at http://www.measurement-factory.com/tmp/opes/ Please continue to comment and work on the to-do list. I am especially interested in feedback regarding the new "OCP application" approach, outlined on this list earlier. Thank you, Alex. -------------- change log ---------------- Appendix A. Change Log <168> <169> o clarified application message definition and OCP boundaries by introducing three kinds of "applications": processor input, processor output, and OCP application <170> o made "Overall Operation" a top-level section since it got long and has its own subsections now; lots of editorial changes in this sections, new figures <171> o added illustrations of OCP messages, transactions, and connections From owner-ietf-openproxy@mail.imc.org Mon Apr 7 18:48:16 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09751 for ; Mon, 7 Apr 2003 18:48:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37McTJM029657 for ; Mon, 7 Apr 2003 15:38:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37McSGm029656 for ietf-openproxy-bks; Mon, 7 Apr 2003 15:38:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37McMJM029607 for ; Mon, 7 Apr 2003 15:38:23 -0700 (PDT) Received: from mhof.com ([135.104.20.82]) by mtaout08.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HCZ008SGW4H6U@mtaout08.icomcast.net> for ietf-openproxy@imc.org; Mon, 07 Apr 2003 18:36:18 -0400 (EDT) Date: Mon, 07 Apr 2003 18:36:17 -0400 From: Markus Hofmann Subject: Re: fixing "application message" mess In-reply-to: To: OPES Group Message-id: <3E91FD61.5080505@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <3E91DF5B.7020603@mhof.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Alex Rousskov wrote: > The above negotiations (automated or via configuration files) are > unavoidable anyway! A valid question still is whether such negotiations should be built into OCP or not. I'm not taking either side (yet :), just saying that pros and cons should be looked at before we start adding more and more to OCP itself. For example, one might also imagine that the OCP application to be used is (implicitely) indicated by the service to be called (and its description). Meaning, if an OPES processor decides to do a callout in order to execute Service A, one might assume that the description of Service A also tells the OPES processor what OCP application to use (likewise for the callout server). Note, that there might be multiple 'services' with different OCP application bindings defined for one and the same callout application (e.g. a virus scanner accepting files via HTTP, SMTP, and plain). > The proposed solution does not make negotiation more complex. Some kind of negotiation or agreement is required, sure. The question is whether this mechanism should be build into OCP or if it would be beneficial to assume this to happen "out-of-band". Just asking for the pros and cons. > it actually clarifies negotiation purpose. OCP negotiation must result > in an agreement regarding OCP application protocol, which includes the > usual things like name, version, message framing, meta-data (headers), > etc. If you look at it, it all boils down to how to encode/interpret > "meta-data" and how to interpret "data" (what is it I am getting?), > something we have to negotiate anyway if we want to remain application > agnostic. We can probably agree on the same meta-data encoding/format > for all applications. Then, > > OCP application protocol == required meta-data fields + > "data" meaning > > OPES WG may then publish an "HTTP as an OCP application protocol" > draft where the above things will be specified for HTTP. Other working > groups and individuals may publish their own application protocol > bindings. Sounds reasonable. > Does the above sound convincing enough? Or do you still think I am > opening a pandora box (that was closed before)? Not yet sure about the "pandora box" :) It's fine if we're convinced that this should be built into OCP, and if we keep the mechanisms in OCP as simple as possible and stay within our scope. -Markus From owner-ietf-openproxy@mail.imc.org Mon Apr 7 19:03:56 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10097 for ; Mon, 7 Apr 2003 19:03:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37MrTJM002533 for ; Mon, 7 Apr 2003 15:53:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37MrT1w002532 for ietf-openproxy-bks; Mon, 7 Apr 2003 15:53:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37MrSJM002513 for ; Mon, 7 Apr 2003 15:53:28 -0700 (PDT) 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 h37MrOV24405 for ; Mon, 7 Apr 2003 18:53:25 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Apr 2003 18:53:25 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540561F075@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: ietf-openproxy@imc.org Subject: Notification Date: Mon, 7 Apr 2003 18:53:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FD58.7F5D98E8" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FD58.7F5D98E8 Content-Type: text/plain With all the discussions on tracing, I discovered late today during my attempt to summarize the discussion in a draft format that we have not yet discussed Notification. So, to start, 1. What really triggers notification - End Application/user 2. Is the process automated - Rules triggers action, then error occurs OPES processor notify content provider - Callout server dicovers errors and inform whom, OPES processor and it then notify content provider? 3. How does this relate to Trust domains and Deployment 4. In the simplest case, can we say - Agent (consumer/provider application) does not like the OPES actions, invoke tracing (assuming that we have agreed on how) as a mechanism for notification (this is indirectly addressing notification) 5. Can we assume that notification is done on error only? - What is an error - Inavlid URL - Malformed Image etc.. 6. How about Content Provider induced erros ( bad links or bad programming practices)are they part of OPES Notification. 7. Can Notification be done offline (Poll OPES Servers at the end of business day and check an error log file ?) These are just thoughs for now Abbie ------_=_NextPart_001_01C2FD58.7F5D98E8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Notification

With all the discussions on tracing, I discovered = late today during my attempt to summarize the discussion in a draft = format that we have not yet discussed Notification.

So, to start,
1. What really triggers notification
   - End Application/user
2. Is the process automated
   - Rules triggers action, then error = occurs OPES processor notify content provider
   - Callout server dicovers errors and = inform whom, OPES processor and it
     then notify content = provider?
3. How does this relate to Trust domains and = Deployment
4. In the simplest case, can we say
   - Agent (consumer/provider = application)  does not like the OPES actions, invoke tracing = (assuming that we have agreed on how) as a mechanism for = notification

(this is indirectly addressing notification)

5. Can we assume that notification is done on error = only?
  - What is an error
    - Inavlid URL
    - Malformed Image etc..
   
6. How about Content Provider induced erros ( bad = links or bad programming practices)are they part of OPES = Notification.

7. Can Notification be done offline (Poll OPES = Servers at the end of business day and check an error log file = ?)

These are just thoughs for now

Abbie




------_=_NextPart_001_01C2FD58.7F5D98E8-- From owner-ietf-openproxy@mail.imc.org Mon Apr 7 19:49:37 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11122 for ; Mon, 7 Apr 2003 19:49:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37Nc1JM004847 for ; Mon, 7 Apr 2003 16:38:01 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37Nc1xK004846 for ietf-openproxy-bks; Mon, 7 Apr 2003 16:38:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37NbxJM004841 for ; Mon, 7 Apr 2003 16:37:59 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37Nc2vj084266; Mon, 7 Apr 2003 17:38:02 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37Nc2pX084265; Mon, 7 Apr 2003 17:38:02 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 17:38:02 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Notification In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540561F075@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540561F075@zcard0k6.ca.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: Abbie, What is the difference between tracing and notification _if_ tracing is always-on (i.e., trace info is attached to every message)? Both architecture and OCP requirements drafts do not define "notification" (AFAIK), so I am not sure what the difference is. Please clarify. Thank you, Alex. On Mon, 7 Apr 2003, Abbie Barbir wrote: > > With all the discussions on tracing, I discovered late today during my > attempt to summarize the discussion in a draft format that we have not yet > discussed Notification. > > So, to start, > 1. What really triggers notification > - End Application/user > 2. Is the process automated > - Rules triggers action, then error occurs OPES processor notify content > provider > - Callout server dicovers errors and inform whom, OPES processor and it > then notify content provider? > 3. How does this relate to Trust domains and Deployment > 4. In the simplest case, can we say > - Agent (consumer/provider application) does not like the OPES actions, > invoke tracing (assuming that we have agreed on how) as a mechanism for > notification > (this is indirectly addressing notification) > > 5. Can we assume that notification is done on error only? > - What is an error > - Inavlid URL > - Malformed Image etc.. > > 6. How about Content Provider induced erros ( bad links or bad programming > practices)are they part of OPES Notification. > > 7. Can Notification be done offline (Poll OPES Servers at the end of > business day and check an error log file ?) > > These are just thoughs for now > > Abbie > > > > > From owner-ietf-openproxy@mail.imc.org Mon Apr 7 19:56:28 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11220 for ; Mon, 7 Apr 2003 19:56:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37NkmJM005081 for ; Mon, 7 Apr 2003 16:46:48 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37Nkm2K005080 for ietf-openproxy-bks; Mon, 7 Apr 2003 16:46:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37NklJM005076 for ; Mon, 7 Apr 2003 16:46:47 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h37Nkovj084499; Mon, 7 Apr 2003 17:46:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h37NkoEX084498; Mon, 7 Apr 2003 17:46:50 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 17:46:50 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: fixing "application message" mess In-Reply-To: <3E91FD61.5080505@mhof.com> Message-ID: References: <3E91DF5B.7020603@mhof.com> <3E91FD61.5080505@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: On Mon, 7 Apr 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > The above negotiations (automated or via configuration files) are > > unavoidable anyway! > > A valid question still is whether such negotiations should be built > into OCP or not. I'm not taking either side (yet :), just saying > that pros and cons should be looked at before we start adding more > and more to OCP itself. Absolutely. That is why I explicitly said "or via configuration files". The scope of OCP negotiations is yet to be determined. I hope we can make that determination after Reinaldo Penno suggests the first negotiation mechanisms. > For example, one might also imagine that the OCP application to be > used is (implicitely) indicated by the service to be called (and its > description). Meaning, if an OPES processor decides to do a callout > in order to execute Service A, one might assume that the description > of Service A also tells the OPES processor what OCP application to > use (likewise for the callout server). Yes, a very reasonable setup. > Note, that there might be multiple 'services' with different OCP > application bindings defined for one and the same callout > application (e.g. a virus scanner accepting files via HTTP, SMTP, > and plain). Yes. > It's fine if we're convinced that this should be built into OCP, and > if we keep the mechanisms in OCP as simple as possible and stay > within our scope. We are not convinced yet :-). Reinaldo made some good points why auto-negation is needed, and I think we need to wait for his specification so that we can discuss specific trade-offs. Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 7 20:06:35 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11483 for ; Mon, 7 Apr 2003 20:06:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37NttJM005425 for ; Mon, 7 Apr 2003 16:55:55 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37Nttds005424 for ietf-openproxy-bks; Mon, 7 Apr 2003 16:55:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37NtsJM005412 for ; Mon, 7 Apr 2003 16:55:54 -0700 (PDT) Received: from mhof.com ([135.104.20.82]) by mtaout08.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HCZ008NFZO6W9@mtaout08.icomcast.net> for ietf-openproxy@imc.org; Mon, 07 Apr 2003 19:53:03 -0400 (EDT) Date: Mon, 07 Apr 2003 19:52:54 -0400 From: Markus Hofmann Subject: Re: OCP version head_sid3 available In-reply-to: To: OPES Group Message-id: <3E920F56.4030500@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Alex Rousskov wrote: > o clarified application message definition and OCP boundaries by > introducing three kinds of "applications": processor input, > processor output, and OCP application Apology if this has been addressed before, but it seems the term "OCP application" might be a little bit confusing in this context. Isn't it the case that it describes that payload type pf the OCP message, so that we could use "OCP payload type" rather than OCP application? -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 8 00:58:59 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17050 for ; Tue, 8 Apr 2003 00:58:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h384kTJM018278 for ; Mon, 7 Apr 2003 21:46:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h384kTVH018277 for ietf-openproxy-bks; Mon, 7 Apr 2003 21:46:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h384kRJM018272 for ; Mon, 7 Apr 2003 21:46:28 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h384kWvj091796; Mon, 7 Apr 2003 22:46:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h384kSrT091795; Mon, 7 Apr 2003 22:46:28 -0600 (MDT) (envelope-from rousskov) Date: Mon, 7 Apr 2003 22:46:28 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: OCP version head_sid3 available In-Reply-To: <3E920F56.4030500@mhof.com> Message-ID: References: <3E920F56.4030500@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: On Mon, 7 Apr 2003, Markus Hofmann wrote: > > Alex Rousskov wrote: > > > o clarified application message definition and OCP boundaries by > > introducing three kinds of "applications": processor input, > > processor output, and OCP application > > Apology if this has been addressed before, but it seems the term > "OCP application" might be a little bit confusing in this context. > Isn't it the case that it describes that payload type pf the OCP > message, so that we could use "OCP payload type" rather than OCP > application? I agree that "OCP application" is awkward. However, we are not talking just about OCP message payload. The term refers to the set of agreements (a protocol) covering things like: - meta-data encoding - required meta-data fields and their meaning - data encoding - data meaning The exact combination is unknown a priory. For example, in some cases, it may make sense to agree on meta-data and let meta-data describe data encoding and meaning. The "other side" of OCP communication does not know what it is getting in meta-data and data fields. It needs to be told about encoding and meanings, just like, say, HTTP defines HTTP message encoding and meaning. Again, a better term than "OCP application" would be great, but it has to cover all of the above things. It is the result of OCP agents negotiations about data and meta-data. Another important thing is that it should be easy to show that there is no documented/required relationship among processor input application, OCP application (or whatever we call it), and processor output application. When all three are "applications", the explanations are easy. Suggestions? Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 8 06:28:43 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04881 for ; Tue, 8 Apr 2003 06:28:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38AHCJM001597 for ; Tue, 8 Apr 2003 03:17:12 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38AHCT5001596 for ietf-openproxy-bks; Tue, 8 Apr 2003 03:17:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38AHAJM001585 for ; Tue, 8 Apr 2003 03:17:11 -0700 (PDT) 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 h38AGxf12645; Tue, 8 Apr 2003 06:16:59 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 06:16:59 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540561F0FF@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Notification Date: Tue, 8 Apr 2003 06:16:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FDB7.FCEC612C" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FDB7.FCEC612C Content-Type: text/plain Alex, The difference is that notification occur first and then tracing can occur. Basically, the assumption is that the default is that tracing if off. For example, contnet provider gets to be aware of a problem thru notification. Then tracing is invoked to help solve the issues. Just my $000002 cents. Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Monday, April 07, 2003 7:38 PM > To: ietf-openproxy@imc.org > Subject: Re: Notification > > > Abbie, > > What is the difference between tracing and notification > _if_ tracing is always-on (i.e., trace info is attached to > every message)? Both architecture and OCP requirements drafts > do not define "notification" (AFAIK), so I am not sure what > the difference is. Please clarify. > > Thank you, > > Alex. > > On Mon, 7 Apr 2003, Abbie Barbir wrote: > > > > > With all the discussions on tracing, I discovered late > today during my > > attempt to summarize the discussion in a draft format that > we have not > > yet discussed Notification. > > > > So, to start, > > 1. What really triggers notification > > - End Application/user > > 2. Is the process automated > > - Rules triggers action, then error occurs OPES processor notify > > content provider > > - Callout server dicovers errors and inform whom, OPES > processor and it > > then notify content provider? > > 3. How does this relate to Trust domains and Deployment > > 4. In the simplest case, can we say > > - Agent (consumer/provider application) does not like the OPES > > actions, invoke tracing (assuming that we have agreed on how) as a > > mechanism for notification (this is indirectly addressing > > notification) > > > > 5. Can we assume that notification is done on error only? > > - What is an error > > - Inavlid URL > > - Malformed Image etc.. > > > > 6. How about Content Provider induced erros ( bad links or bad > > programming practices)are they part of OPES Notification. > > > > 7. Can Notification be done offline (Poll OPES Servers at > the end of > > business day and check an error log file ?) > > > > These are just thoughs for now > > > > Abbie > > > > > > > > > > > ------_=_NextPart_001_01C2FDB7.FCEC612C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Notification

Alex,

The difference is that notification occur first and = then tracing can occur.
Basically, the assumption is that the default is = that tracing if off.

For example, contnet provider gets to be aware of a = problem thru notification. Then tracing is invoked to help solve the = issues.

Just my $000002 cents.

Abbie



> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Monday, April 07, 2003 7:38 PM
> To: ietf-openproxy@imc.org
> Subject: Re: Notification
>
>
> Abbie,
>
>       What is the = difference between tracing and notification
> _if_ tracing is always-on (i.e., trace info is = attached to
> every message)? Both architecture and OCP = requirements drafts
> do not define "notification" (AFAIK), = so I am not sure what
> the difference is. Please clarify.
>
> Thank you,
>
> Alex.
>
> On Mon, 7 Apr 2003, Abbie Barbir wrote:
>
> >
> > With all the discussions on tracing, I = discovered late
> today during my
> > attempt to summarize the discussion in a = draft format that
> we have not
> > yet discussed Notification.
> >
> > So, to start,
> > 1. What really triggers = notification
> >    - End = Application/user
> > 2. Is the process automated
> >    - Rules triggers action, = then error occurs OPES processor notify
> > content provider
> >    - Callout server = dicovers errors and inform whom, OPES
> processor and it
> >      then notify = content provider?
> > 3. How does this relate to Trust domains = and Deployment
> > 4. In the simplest case, can we say
> >    - Agent = (consumer/provider application)  does not like the OPES
> > actions, invoke tracing (assuming that we = have agreed on how) as a
> > mechanism for notification (this is = indirectly addressing
> > notification)
> >
> > 5. Can we assume that notification is done = on error only?
> >   - What is an error
> >     - Inavlid = URL
> >     - Malformed Image = etc..
> >
> > 6. How about Content Provider induced = erros ( bad links or bad
> > programming practices)are they part of = OPES Notification.
> >
> > 7. Can Notification be done offline (Poll = OPES Servers at
> the end of
> > business day and check an error log file = ?)
> >
> > These are just thoughs for now
> >
> > Abbie
> >
> >
> >
> >
> >
>

------_=_NextPart_001_01C2FDB7.FCEC612C-- From owner-ietf-openproxy@mail.imc.org Tue Apr 8 06:32:51 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05096 for ; Tue, 8 Apr 2003 06:32:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38AOqJM001910 for ; Tue, 8 Apr 2003 03:24:52 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38AOq3r001909 for ietf-openproxy-bks; Tue, 8 Apr 2003 03:24:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38AOpJM001904 for ; Tue, 8 Apr 2003 03:24:51 -0700 (PDT) Received: from f07a-9-5.d1.club-internet.fr ([212.194.152.5] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 192qHZ-0001zn-00; Tue, 08 Apr 2003 03:24:50 -0700 Message-Id: <5.2.0.9.0.20030408112857.0280b180@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 08 Apr 2003 11:38:23 +0200 To: Alex Rousskov , ietf-openproxy@imc.org From: jfcm Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: References: <5.2.0.9.0.20030407204056.040cd140@mail.utel.net> <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030407204056.040cd140@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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 21:53 07/04/03, Alex Rousskov wrote: >On Mon, 7 Apr 2003, jfcm wrote: > > Would these sessions represent the whole message transiting through > > OCP towards as many services as required ? If yes I would accept the > > concepts. Interaction otherwise? A session would be all the OCP > > interactions that a message may perform from the dispatcher to > > services until sent to the user. So you could talk of the OPES > > session. Makes sense in French, but I do not know if it is the same > > in English. > >If "many services" are on different callout servers, I did not say "many services" but "as many services as required". - if there is one or there are ten this makes no difference - there must be no asumption of where a service process is located. >then your definition of "session" makes sense, but seems to be out of OCP >scope since OCP is concerned with single processor - single server >communication. Tracing should keep track of previous OPES applied to the message. To prevent loops. This builds the concept of a session (exit the session in case of loop). >If the services are on the same callout server, then >your "session" would be in OCP scope. It would be something that may >cross OCP connections even. I am not sure why we would need it though. >To be able to abort easier? The question was about using the word session to another end. I explained what "session" meant to me, and I think it makes sense and can be used. Abort is one reason I quoted, yes. There may be others like to understand the order of the previously applied services, etc. > > You sure you want to use OPES Processor the way you do? > > For me it is opposed to every standard thinking I know. > >Not sure what you mean. OPES processor is just an application proxy >that outsources processing of some messages. Sounds pretty "standard" >to me. Is it not? Documented that already. To me a a processor is where an process occurs. An OPES is a service. So to me OPES Processor is where the service process occus, ie on what you call the call-out server. On what you currently call the OPES Processor only happen the dispatch of the call-outs. An addition confusion is if I use another archtecture than the dispatcher/call-out to implement OPES. I will use daysy chained OPES Porcessors where the servies will be provided if some conditions apply. jfc From owner-ietf-openproxy@mail.imc.org Tue Apr 8 06:34:14 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05160 for ; Tue, 8 Apr 2003 06:34:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38AOsJM001919 for ; Tue, 8 Apr 2003 03:24:54 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38AOsNc001918 for ietf-openproxy-bks; Tue, 8 Apr 2003 03:24:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38AOrJM001911 for ; Tue, 8 Apr 2003 03:24:53 -0700 (PDT) Received: from f07a-9-5.d1.club-internet.fr ([212.194.152.5] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 192qHb-0001zn-00; Tue, 08 Apr 2003 03:24:52 -0700 Message-Id: <5.2.0.9.0.20030408113923.0280cec0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 08 Apr 2003 11:45:36 +0200 To: Alex Rousskov , OPES Group From: jfcm Subject: RE: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: References: <5.2.0.9.0.20030407203158.040af990@mail.utel.net> <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754055BD6EE@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030407203158.040af990@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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 21:40 07/04/03, Alex Rousskov wrote: > > Could we not use someting as "out-bound" and "in-bound" IRT the used > > "call-out" protocol. It would be consistent. > >OK, it is a "choice of a word" question. I think it is very important >to use "right" words. Fortunately, it is easy to change the words in >the draft so we have time to find good ones. (I am more concerned >about the actual definitions and protocol specifics now.) True. However I feel some wordings may have lead to some orientations. I was refering to out-bound in the same direction and call-out. What ever word is right and clear is good for me. But just think that we will probably have many OPES acting in a daisy chain way (to start with two your way OPES on the same flow : one on the caller and one one the server side). >Anyway, since the communication is between two entities (OPES >processor and callout server), it is difficult for me to guess which >one is "out-bound". "Out" depends on whether you are looking from OPES >processor or callout server point of view. We already have >output/input for OPES processor, where there is no confusion since we >are talking about a single entity (the processor) in the middle of a >pipe. In my own intuitive wording (sorry, I cannot keep thinking otherwise) there is a dispatcher calling out on service processors. >Protocols often use request/response terms in these situations. >Perhaps we can use "request data" and "response data" instead of >"original" and "adapted"? I kind of like "adapted" though. It is the >"original" that's confusing. > >More suggestions? > > > Also nothing prevents the returning in-bound message to be identical > > to the original if no change was performed. > >True, except, perhaps, for tracing requirements. Recall that "seeing >the application data" is a form of adaptation (by definition) because >if I can see it, then I can log it; and if I log it, then the user may >want to know my privacy policy. > >If we ignore tracing issues, is there some wording that makes a reader >think that "something prevents returning identical messages"? I do not think so, except a possible wording of "out-boud, in-bound" chosen terms. Hence my remark. jfc From owner-ietf-openproxy@mail.imc.org Tue Apr 8 08:37:41 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08362 for ; Tue, 8 Apr 2003 08:37:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38CTHJM014207 for ; Tue, 8 Apr 2003 05:29:17 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38CTHf7014204 for ietf-openproxy-bks; Tue, 8 Apr 2003 05:29:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38CTFJM014194 for ; Tue, 8 Apr 2003 05:29:15 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h38CTGvj003170; Tue, 8 Apr 2003 06:29:16 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h38CTGIk003169; Tue, 8 Apr 2003 06:29:16 -0600 (MDT) (envelope-from rousskov) Date: Tue, 8 Apr 2003 06:29:16 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Notification In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540561F0FF@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540561F0FF@zcard0k6.ca.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: On Tue, 8 Apr 2003, Abbie Barbir wrote: > The difference is that notification occur first and then tracing can occur. > Basically, the assumption is that the default is that tracing if off. > > For example, contnet provider gets to be aware of a problem thru > notification. Then tracing is invoked to help solve the issues. If that is the case, I suggest that tracing should be always-on, just like HTTP Via headers now. This eliminates notification as a separate problem! I expected you to say that notification goes in opposite direction of tracing and does not (cannot) be attached to application messages that it notifies about. For example, if OPES is processing an HTTP request, the trace is attached to that request and optional notifications are sent to the client as the request passes through OPES intermediaries. If OPES is processing an HTTP response, the trace is attached to that response, and an optional notification is sent to provider(s?) as the response passes through OPES intermediaries. Note that since some of the application protocols we want to support use "store and forward" model and not "request/response" (e.g., SMTP), we cannot use responses to attach request notifications. In any case, that trick will not help a provider because notification information about the response is not available at the time of the request. This opposite-direction, outside-of-message scheme is much more difficult to support and, frankly, I think it would be a waste of time developing it. However, it is probably very close to what IAB would prefer (based on what the Considerations RFC they wrote). Comments? Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 8 08:57:51 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08923 for ; Tue, 8 Apr 2003 08:57:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38CoLJM015578 for ; Tue, 8 Apr 2003 05:50:21 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38CoL1d015577 for ietf-openproxy-bks; Tue, 8 Apr 2003 05:50:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38CoJJM015573 for ; Tue, 8 Apr 2003 05:50:19 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h38CoKvj003664; Tue, 8 Apr 2003 06:50:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h38CoK8J003663; Tue, 8 Apr 2003 06:50:20 -0600 (MDT) (envelope-from rousskov) Date: Tue, 8 Apr 2003 06:50:20 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 In-Reply-To: <5.2.0.9.0.20030408112857.0280b180@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030407204056.040cd140@mail.utel.net> <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754055BD713@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030407204056.040cd140@mail.utel.net> <5.2.0.9.0.20030408112857.0280b180@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: On Tue, 8 Apr 2003, jfcm wrote: > > At 21:53 07/04/03, Alex Rousskov wrote: > >On Mon, 7 Apr 2003, jfcm wrote: > > > Would these sessions represent the whole message transiting through > > > OCP towards as many services as required ? If yes I would accept the > > > concepts. Interaction otherwise? A session would be all the OCP > > > interactions that a message may perform from the dispatcher to > > > services until sent to the user. So you could talk of the OPES > > > session. Makes sense in French, but I do not know if it is the same > > > in English. > > > >If "many services" are on different callout servers, > > I did not say "many services" but "as many services as required". > - if there is one or there are ten this makes no difference > - there must be no asumption of where a service process is located. > > >then your definition of "session" makes sense, but seems to be out of OCP > >scope since OCP is concerned with single processor - single server > >communication. Please reread what I wrote. I am simply saying that if multiple servers may be involved, then your definition of a session becomes out of OCP scope. It is no longer an OCP session but something else. There is nothing wrong with that, but it needs to be stated explicitly so that we would know that OCP has nothing to do with it (this is an OCP draft discussion thread!). > Tracing should keep track of previous OPES applied to the message. > To prevent loops. This builds the concept of a session (exit the > session in case of loop). That's fine. You are, essentially, talking about tracing mechanisms. Tracing discussion has its own thread. > >If the services are on the same callout server, then > >your "session" would be in OCP scope. It would be something that may > >cross OCP connections even. I am not sure why we would need it though. > >To be able to abort easier? > > The question was about using the word session to another end. The question was about naming communication between OCP agents. We are talking about logical connections "to another _OCP_ end". Your session is not about OCP, but OPES in general, I guess. > I explained what "session" meant to me, and I think it makes sense > and can be used. Abort is one reason I quoted, yes. There may be > others like to understand the order of the previously applied > services, etc. Sure, that is what tracing is for. For example, HTTP Via headers are used by proxies to detect loops. It looks to me that your session is nothing else but a collection of all trace records added to the application message so far. Is it not? > > > You sure you want to use OPES Processor the way you do? > > > For me it is opposed to every standard thinking I know. > > > >Not sure what you mean. OPES processor is just an application proxy > >that outsources processing of some messages. Sounds pretty "standard" > >to me. Is it not? > > Documented that already. To me a a processor is where an process occurs. An > OPES is a service. So to me OPES Processor is where the service process > occus, ie on what you call the call-out server. On what you currently call > the OPES Processor only happen the dispatch of the call-outs. OPES processor can do adaptation internally. It can also do adaptation externally but without the use of callout servers and OCP. I think that is why it was called Processor, with a Dispatcher element. I agree that the name/concept is unfortunate because it focuses on physical placement (same box versus external server) rather than logical role. I tried to use OPES dispatcher as an OCP client, but folks objected, citing the architecture draft. I do not have the energy to fight this well-established terminology. Perhaps you can drive the change? Does anybody else care about "OPES processor" terminology imperfections? Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 8 09:32:16 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09621 for ; Tue, 8 Apr 2003 09:32:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38DKFJM016752 for ; Tue, 8 Apr 2003 06:20:15 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38DKFte016751 for ietf-openproxy-bks; Tue, 8 Apr 2003 06:20:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38DKEJM016746 for ; Tue, 8 Apr 2003 06:20:14 -0700 (PDT) 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 h38DK0m15376; Tue, 8 Apr 2003 09:20:00 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 09:20:01 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540561F22A@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Notification Date: Tue, 8 Apr 2003 09:20:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FDD1.8ED396BE" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FDD1.8ED396BE Content-Type: text/plain see inline, Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, April 08, 2003 8:29 AM > To: ietf-openproxy@imc.org > Subject: RE: Notification > > > > On Tue, 8 Apr 2003, Abbie Barbir wrote: > > > The difference is that notification occur first and then > tracing can > > occur. Basically, the assumption is that the default is > that tracing > > if off. > > > > For example, contnet provider gets to be aware of a problem thru > > notification. Then tracing is invoked to help solve the issues. > > If that is the case, I suggest that tracing should be > always-on, just like HTTP Via headers now. This eliminates > notification as a separate problem! > > I expected you to say that notification goes in opposite > direction of tracing and does not (cannot) be attached to > application messages that it notifies about. For example, if > OPES is processing an HTTP request, the trace is attached to > that request and optional notifications are sent to the > client as the request passes through OPES intermediaries. If > OPES is processing an HTTP response, the trace is attached to > that response, and an optional notification is sent to > provider(s?) as the response passes through OPES intermediaries. Yes, this should be the case. In this case, is Notification application Protocol dependent? Or is it done out of band, (this also addresses next paragraph too). I agree with u that this will not be easy. The point here is to define what we will support for notification, since it can be argued that tracing by itself is a tool and notification is the mechanism for using tracing/debugging. > > Note that since some of the application protocols we want to > support use "store and forward" model and not > "request/response" (e.g., SMTP), we cannot use responses to > attach request notifications. In any case, that trick will > not help a provider because notification information about > the response is not available at the time of the request. > > This opposite-direction, outside-of-message scheme is much > more difficult to support and, frankly, I think it would be a > waste of time developing it. However, it is probably very > close to what IAB would prefer (based on what the > Considerations RFC they wrote). > > Comments? > > Alex. Here are the IAB requirements: (3.1) Notification: The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider. (3.2) Notification: The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries. abbie ------_=_NextPart_001_01C2FDD1.8ED396BE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Notification

see inline,

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, April 08, 2003 8:29 AM
> To: ietf-openproxy@imc.org
> Subject: RE: Notification
>
>
>
> On Tue, 8 Apr 2003, Abbie Barbir wrote:
>
> > The difference is that notification occur = first and then
> tracing can
> > occur. Basically, the assumption is that = the default is
> that tracing
> > if off.
> >
> > For example, contnet provider gets to be = aware of a problem thru
> > notification. Then tracing is invoked to = help solve the issues.
>
> If that is the case, I suggest that tracing = should be
> always-on, just like HTTP Via headers now. This = eliminates
> notification as a separate problem!
>

> I expected you to say that notification goes in = opposite
> direction of tracing and does not (cannot) be = attached to
> application messages that it notifies about. = For example, if
> OPES is processing an HTTP request, the trace = is attached to
> that request and optional notifications are = sent to the
> client as the request passes through OPES = intermediaries. If
> OPES is processing an HTTP response, the trace = is attached to
> that response, and an optional notification is = sent to
> provider(s?) as the response passes through = OPES intermediaries.

Yes, this should be the case. In this case, is = Notification application Protocol dependent?
Or is it done out of band, (this also addresses next = paragraph too). I agree with u that this will not be easy. The point = here is to define what we will support for notification, since it can = be argued that tracing by itself is a tool and notification is the = mechanism for using tracing/debugging.

>
> Note that since some of the application = protocols we want to
> support use "store and forward"  = model and not
> "request/response" (e.g., SMTP), we = cannot use responses to
> attach request notifications. In any case, that = trick will
> not help a provider because notification = information about
> the response is not available at the time of = the request.
>
> This opposite-direction, outside-of-message = scheme is much
> more difficult to support and, frankly, I think = it would be a
> waste of time developing it. However, it is = probably very
> close to what IAB would prefer (based on what = the
> Considerations RFC they wrote).
>
> Comments?
>
> Alex.

Here are the IAB requirements:
  (3.1) Notification: The overall OPES = framework needs to assist
   content providers in detecting and = responding to client-centric
   actions by OPES intermediaries that are = deemed inappropriate by the
   content provider.

   (3.2) Notification: The overall OPES = framework should assist end
   users in detecting the behavior of OPES = intermediaries, potentially
   allowing them to identify imperfect or = compromised intermediaries.


abbie

------_=_NextPart_001_01C2FDD1.8ED396BE-- From owner-ietf-openproxy@mail.imc.org Tue Apr 8 11:04:16 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16934 for ; Tue, 8 Apr 2003 11:04:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38EvTJM026105 for ; Tue, 8 Apr 2003 07:57:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38EvTm2026104 for ietf-openproxy-bks; Tue, 8 Apr 2003 07:57:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38EvRJM026099 for ; Tue, 8 Apr 2003 07:57:27 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h38EvTvj006783; Tue, 8 Apr 2003 08:57:29 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h38EvTqg006782; Tue, 8 Apr 2003 08:57:29 -0600 (MDT) (envelope-from rousskov) Date: Tue, 8 Apr 2003 08:57:29 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Notification In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540561F22A@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540561F22A@zcard0k6.ca.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: On Tue, 8 Apr 2003, Abbie Barbir wrote: > Yes, this should be the case. In this case, is Notification > application Protocol dependent? Or is it done out of band, (this > also addresses next paragraph too). Does not matter at this point. Application dependency is a secondary problem, IMO. First, we need to decide whether we should support notification (on a protocol level) at all. > Here are the IAB requirements: > (3.1) Notification: The overall OPES framework needs to assist > content providers in detecting and responding to client-centric > actions by OPES intermediaries that are deemed inappropriate by the > content provider. > > (3.2) Notification: The overall OPES framework should assist end > users in detecting the behavior of OPES intermediaries, potentially > allowing them to identify imperfect or compromised intermediaries. I believe tracing satisfies 3.2. The only problem is with 3.1 because most client-centric actions happen _after_ the application message left the content provider(s) and, thus, notifications cannot be piggy-backed to application messages and have to travel in the opposite direction of traces. Let's concentrate on satisfying 3.1 as the subject of this thread. The 3.1 requirement is quite vague and it is not clear how normative are the comments that accompany/justify it. My vote is to interpret "assist" above as "assistance on non-protocol level". That is, we provide always-on tracing and claim that traces are sufficient to satisfy 3.1 above as long as both ends cooperate. We can also assert that if the ends do not cooperate, then no protocol-level solution will work either. Specifically, we suggest that content providers that suspect or experience difficulties do the following: 1. Check whether requests they receive pass through OPES intermediaries. Presence of OPES tracing info will determine that. This check is only possible for request/response protocols. For other protocols (e.g., broadcast or push), the provider would have to assume that OPES intermediaries are involved until proven otherwise. 2. If OPES intermediaries are suspected, request OPES traces from potentially affected user(s). The trace will be a part of the application message received by the user software. If users cooperate, the provider(s) have all the information they need. If users do not cooperate, the provider(s) cannot do much about it (they might be able to deny service to uncooperative users in some cases). 3. Some traces may indicate that more information is available by accessing certain resources on the specified OPES intermediary or elsewhere. Content providers may query for more information in that case. 4. If everything else fails, providers can enforce no-adaptation policy using appropriate OPES bypass mechanisms and/or end-to-end mechanisms. Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 8 11:04:52 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16985 for ; Tue, 8 Apr 2003 11:04:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38EsFJM026018 for ; Tue, 8 Apr 2003 07:54:15 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38EsFhW026017 for ietf-openproxy-bks; Tue, 8 Apr 2003 07:54:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38EsDJM026011 for ; Tue, 8 Apr 2003 07:54:14 -0700 (PDT) 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.9/8.12.9) with ESMTP id h38EsE9Y048781; Tue, 8 Apr 2003 10:54:14 -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 h38Es7c6013932; Tue, 8 Apr 2003 10:54:07 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h38Es7Q4017137; Tue, 8 Apr 2003 10:54:07 -0400 (EDT) Message-ID: <3E92E2BE.8070000@mhof.com> Date: Tue, 08 Apr 2003 10:54:54 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: Notification References: <87609AFB433BD5118D5E0002A52CD7540561F0FF@zcard0k6.ca.nortel.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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > I expected you to say that notification goes in opposite direction of > tracing and does not (cannot) be attached to application messages that > it notifies about. Yup, that's my interpretation of "tracing" and "notification". I would further assume that "tracing" is always-on, just as "tracing" mail servers via headers is always-on. A major concern with notification is scalability. A content provider certainly is not interested in receiving a notification for every HTTP response sent out. As such, a mechanism for explicit request of notification is required. Now, when exactly would a content provider issue such request? How would such mechanism be used? Randomly, or on a statistical basis? Or manually? Is such a scheme of practical relevance? Privacy is another concern. Maybe a user doesn't want to reveal to any content provider all the OPES services that have been applied on her behalf. For example, why should every content provider know what exact virus scanner I'm using? Wouldn't that help hackers, for example? > This opposite-direction, outside-of-message scheme is much more > difficult to support and, frankly, I think it would be a waste of time > developing it. However, it is probably very close to what IAB would > prefer (based on what the Considerations RFC they wrote). I tend to agree with you that the kind of "opposite-direction, outside-of-message scheme" is quite tricky, and IMHO not very practical. Scalability and also privacy are a big concern here. However, IAB consideration (3.1) suggests a kind of notification along thos lines: (3.1) Notification: The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider. Section 3.1 of RFC3238 provides the motivation for this consideration, and there are certainly some very valid arguments. However, maybe there're other means to address these concerns? Probably best if we check-in with our ADs and the IAB at some point, but I'd first like to discuss this a little bit further and solicit input on this very topic from other folks as well. So, please post your comments on this one! -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 8 11:34:57 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19189 for ; Tue, 8 Apr 2003 11:34:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38FN7JM027785 for ; Tue, 8 Apr 2003 08:23:07 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38FN7tE027784 for ietf-openproxy-bks; Tue, 8 Apr 2003 08:23:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38FN6JM027780 for ; Tue, 8 Apr 2003 08:23:06 -0700 (PDT) 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 h38FMtm19844; Tue, 8 Apr 2003 11:22:55 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 11:22:56 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540561F481@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Notification Date: Tue, 8 Apr 2003 11:22:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FDE2.B9577CF0" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FDE2.B9577CF0 Content-Type: text/plain Alex, In general I have no problem(s) with your remarks. We need to have good justification on what "assiatance means" and how at least one end "content provider" can detect malfunction (inappropriate behaior) Can we say that we expect them to do periodic sanity check? This is a quick responce for now Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, April 08, 2003 10:57 AM > To: ietf-openproxy@imc.org > Subject: RE: Notification > > > > On Tue, 8 Apr 2003, Abbie Barbir wrote: > > > Yes, this should be the case. In this case, is Notification > > application Protocol dependent? Or is it done out of band, > (this also > > addresses next paragraph too). > > Does not matter at this point. Application dependency is a > secondary problem, IMO. First, we need to decide whether we > should support notification (on a protocol level) at all. > > > Here are the IAB requirements: > > (3.1) Notification: The overall OPES framework needs to assist > > content providers in detecting and responding to client-centric > > actions by OPES intermediaries that are deemed > inappropriate by the > > content provider. > > > > (3.2) Notification: The overall OPES framework should assist end > > users in detecting the behavior of OPES intermediaries, > potentially > > allowing them to identify imperfect or compromised > intermediaries. > > I believe tracing satisfies 3.2. The only problem is with 3.1 > because most client-centric actions happen _after_ the > application message left the content provider(s) and, thus, > notifications cannot be piggy-backed to application messages > and have to travel in the opposite direction of traces. Let's > concentrate on satisfying 3.1 as the subject of this thread. > > The 3.1 requirement is quite vague and it is not clear how > normative are the comments that accompany/justify it. My vote > is to interpret "assist" above as "assistance on non-protocol > level". That is, we provide always-on tracing and claim that > traces are sufficient to satisfy 3.1 above as long as both > ends cooperate. We can also assert that if the ends do not > cooperate, then no protocol-level solution will work either. > Specifically, we suggest that content providers that suspect > or experience difficulties do the following: > > 1. Check whether requests they receive pass through > OPES intermediaries. Presence of OPES tracing info > will determine that. This check is only possible for > request/response protocols. For other protocols (e.g., > broadcast or push), the provider would have to assume > that OPES intermediaries are involved until proven > otherwise. > > 2. If OPES intermediaries are suspected, > request OPES traces from potentially affected user(s). > The trace will be a part of the application message > received by the user software. If users cooperate, > the provider(s) have all the information they need. > If users do not cooperate, the provider(s) cannot > do much about it (they might be able to deny service > to uncooperative users in some cases). > > 3. Some traces may indicate that more information > is available by accessing certain resources on the > specified OPES intermediary or elsewhere. Content > providers may query for more information in that > case. > > 4. If everything else fails, providers can enforce > no-adaptation policy using appropriate OPES > bypass mechanisms and/or end-to-end mechanisms. > > Alex. > ------_=_NextPart_001_01C2FDE2.B9577CF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Notification

Alex,

In general I have no problem(s) with your = remarks.

We need to have good justification on what = "assiatance means" and how at least one end "content = provider" can detect malfunction (inappropriate = behaior)

Can we say that we expect them to do periodic sanity = check?

This is a quick responce for now

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, April 08, 2003 10:57 AM
> To: ietf-openproxy@imc.org
> Subject: RE: Notification
>
>
>
> On Tue, 8 Apr 2003, Abbie Barbir wrote:
>
> > Yes, this should be the case. In this = case, is Notification
> > application Protocol dependent? Or is it = done out of band,
> (this also
> > addresses next paragraph too).
>
> Does not matter at this point. Application = dependency is a
> secondary problem, IMO. First, we need to = decide whether we
> should support notification (on a protocol = level) at all.
>
> > Here are the IAB requirements:
> >   (3.1) Notification: The = overall OPES framework needs to assist
> >    content providers in = detecting and responding to client-centric
> >    actions by OPES = intermediaries that are deemed
> inappropriate by the
> >    content provider.
> >
> >    (3.2) Notification: The = overall OPES framework should assist end
> >    users in detecting the = behavior of OPES intermediaries,
> potentially
> >    allowing them to = identify imperfect or compromised
> intermediaries.
>
> I believe tracing satisfies 3.2. The only = problem is with 3.1
> because most client-centric actions happen = _after_ the
> application message left the content = provider(s) and, thus,
> notifications cannot be piggy-backed to = application messages
> and have to travel in the opposite direction of = traces. Let's
> concentrate on satisfying 3.1 as the subject of = this thread.
>
> The 3.1 requirement is quite vague and it is = not clear how
> normative are the comments that = accompany/justify it. My vote
> is to interpret "assist" above as = "assistance on non-protocol
> level". That is, we provide always-on = tracing and claim that
> traces are sufficient to satisfy 3.1 above as = long as both
> ends cooperate. We can also assert that if the = ends do not
> cooperate, then no protocol-level solution will = work either.
> Specifically, we suggest that content providers = that suspect
> or experience difficulties do the = following:
>
>       1. Check whether = requests they receive pass through
>         OPES = intermediaries. Presence of OPES tracing info
>         will = determine that. This check is only possible for
>         = request/response protocols. For other protocols (e.g.,
>         broadcast = or push), the provider would have to assume
>         that OPES = intermediaries are involved until proven
>         = otherwise.
>
>       2. If OPES = intermediaries are suspected,
>         request = OPES traces from potentially affected user(s).
>         The trace = will be a part of the application message
>         received = by the user software. If users cooperate,
>         the = provider(s) have all the information they need.
>         If users = do not cooperate, the provider(s) cannot
>         do much = about it (they might be able to deny service
>         to = uncooperative users in some cases).
>
>       3. Some traces = may indicate that more information
>         is = available by accessing certain resources on the
>         specified = OPES intermediary or elsewhere. Content
>         providers = may query for more information in that
>         = case.
>
>       4. If everything = else fails, providers can enforce
>          = no-adaptation policy using appropriate OPES
>          = bypass mechanisms and/or end-to-end mechanisms.
>
> Alex.
>

------_=_NextPart_001_01C2FDE2.B9577CF0-- From owner-ietf-openproxy@mail.imc.org Tue Apr 8 13:04:20 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22281 for ; Tue, 8 Apr 2003 13:04:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38GtlJM001586 for ; Tue, 8 Apr 2003 09:55:47 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38Gtlps001585 for ietf-openproxy-bks; Tue, 8 Apr 2003 09:55:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38GtjJM001579 for ; Tue, 8 Apr 2003 09:55:45 -0700 (PDT) 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.9/8.12.9) with ESMTP id h38Gtl9Y049977 for ; Tue, 8 Apr 2003 12:55:47 -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 h38GtfUf022368 for ; Tue, 8 Apr 2003 12:55:41 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h38GteQ4024506 for ; Tue, 8 Apr 2003 12:55:40 -0400 (EDT) Message-ID: <3E92FF3B.8020100@mhof.com> Date: Tue, 08 Apr 2003 12:56:27 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: OCP version head_sid3 available References: <3E920F56.4030500@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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > I agree that "OCP application" is awkward. However, we are not talking > just about OCP message payload. The term refers to the set of > agreements (a protocol) covering things like: > - meta-data encoding > - required meta-data fields and their meaning > - data encoding > - data meaning > The exact combination is unknown a priory. For example, in some cases, > it may make sense to agree on meta-data and let meta-data describe > data encoding and meaning. > > The "other side" of OCP communication does not know what it is getting > in meta-data and data fields. It needs to be told about encoding and > meanings, just like, say, HTTP defines HTTP message encoding and > meaning. > > Again, a better term than "OCP application" would be great, but it has > to cover all of the above things. It is the result of OCP agents > negotiations about data and meta-data. What you describe above (i.e. meta-data encoding, data encoding, etc.), isn't that is some sense a profile for the data to be exchanged via OCP, basically an "OCP profile"? The actual data to be exchanged and described by the profile would be "OCP data"... -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 8 13:59:40 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24031 for ; Tue, 8 Apr 2003 13:59:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HoVJM003899 for ; Tue, 8 Apr 2003 10:50:31 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38HoVpb003898 for ietf-openproxy-bks; Tue, 8 Apr 2003 10:50:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38HoUJM003893 for ; Tue, 8 Apr 2003 10:50:30 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h38HoWvj010896; Tue, 8 Apr 2003 11:50:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h38HoWs9010895; Tue, 8 Apr 2003 11:50:32 -0600 (MDT) (envelope-from rousskov) Date: Tue, 8 Apr 2003 11:50:32 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: OCP version head_sid3 available In-Reply-To: <3E92FF3B.8020100@mhof.com> Message-ID: References: <3E920F56.4030500@mhof.com> <3E92FF3B.8020100@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: On Tue, 8 Apr 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > I agree that "OCP application" is awkward. However, we are not talking > > just about OCP message payload. The term refers to the set of > > agreements (a protocol) covering things like: > > - meta-data encoding > > - required meta-data fields and their meaning > > - data encoding > > - data meaning > > The exact combination is unknown a priory. For example, in some cases, > > it may make sense to agree on meta-data and let meta-data describe > > data encoding and meaning. > > > > The "other side" of OCP communication does not know what it is getting > > in meta-data and data fields. It needs to be told about encoding and > > meanings, just like, say, HTTP defines HTTP message encoding and > > meaning. > > > > Again, a better term than "OCP application" would be great, but it has > > to cover all of the above things. It is the result of OCP agents > > negotiations about data and meta-data. > > What you describe above (i.e. meta-data encoding, data encoding, > etc.), isn't that is some sense a profile for the data to be exchanged > via OCP, basically an "OCP profile"? I guess you can call the above an "OCP profile", though an "OCP payload profile" would be more accurate: data and metadata are OCP payload, the profile does not describe OCP but only its payload. A profile describing data and metadata. > The actual data to be exchanged and described by the profile would > be "OCP data"... THE question is "what is am-id referring to?" A complete data+metadata blob with no name? In the current model the thing referred to by am-id is called "OCP application message". Hopefully, we can find a better name for that entity. Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 8 14:19:11 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24761 for ; Tue, 8 Apr 2003 14:19:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38I7nJM005817 for ; Tue, 8 Apr 2003 11:07:49 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38I7nf6005816 for ietf-openproxy-bks; Tue, 8 Apr 2003 11:07:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38I7mJM005809 for ; Tue, 8 Apr 2003 11:07:48 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h38I7ovj012356; Tue, 8 Apr 2003 12:07:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h38I7oc5012355; Tue, 8 Apr 2003 12:07:50 -0600 (MDT) (envelope-from rousskov) Date: Tue, 8 Apr 2003 12:07:50 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Notification In-Reply-To: <3E92E2BE.8070000@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540561F0FF@zcard0k6.ca.nortel.com> <3E92E2BE.8070000@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: On Tue, 8 Apr 2003, Markus Hofmann wrote: > I tend to agree with you that the kind of "opposite-direction, > outside-of-message scheme" is quite tricky, and IMHO not very > practical. Scalability and also privacy are a big concern here. Yes. I would also add "the level of detail that providers would want to see in those notifications" as a problem. IMO, these concerns together make any general-purpose notification scheme impractical. If the group decides to proceed anyway, we should talk to Hit Metering (RFC 2227) folks for an advice how to avoid their protocol fate. Hit Metering for caching is exactly what Notifications are for OPES. Hit Metering is dead, AFAIK. > Probably best if we check-in with our ADs and the IAB at some point, > but I'd first like to discuss this a little bit further and solicit > input on this very topic from other folks as well. So, please post > your comments on this one! Just to summarize for the record: IMO, we should satisfy 3.1 consideration by saying that "always-on tracing assists content providers" and giving a few specific examples. We should not go beyond that and we should seek ADs and the IAB opinion ASAP. In other words, we would be saying that the IAB choice of "Notification" label should be interpreted as "Notification assistance" (making notifications meaningful) and should not be interpreted as "Notification protocol". We go by the actual consideration wording, ignore the label, and consider any IAB motivation text as informative (not normative). Again, once we decide what to do, we should contact ADs/IAB ASAP. Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 8 19:36:19 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08340 for ; Tue, 8 Apr 2003 19:36:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NODJM023882 for ; Tue, 8 Apr 2003 16:24:13 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38NODk8023880 for ietf-openproxy-bks; Tue, 8 Apr 2003 16:24:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38NOBJM023860 for ; Tue, 8 Apr 2003 16:24:12 -0700 (PDT) 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 h38NO8m26323 for ; Tue, 8 Apr 2003 19:24:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 19:24:08 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: ietf-openproxy@imc.org Cc: "Abbie Barbir" Subject: Tracing Draft version-0004082003 Date: Tue, 8 Apr 2003 19:24:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2FE25.F2688E7E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_000_01C2FE25.F2688E7E Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FE25.F2688E7E" ------_=_NextPart_001_01C2FE25.F2688E7E Content-Type: text/plain Hi, Attached is the -00 version of the tracing draft. Please keep in mind it is work in progress. Feedback is required. Abbie ------_=_NextPart_001_01C2FE25.F2688E7E Content-Type: text/html Tracing Draft version-0004082003

Hi,

Attached is the -00 version of the tracing draft.
Please keep in mind it is work in progress.

Feedback is required.

Abbie

  ------_=_NextPart_001_01C2FE25.F2688E7E-- ------_=_NextPart_000_01C2FE25.F2688E7E Content-Type: text/plain; name="draft-barbir-opes-tracing-00-04082003.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-barbir-opes-tracing-00-04082003.txt" Content-Transfer-Encoding: quoted-printable Open Pluggable Edge Services A. Barbir (Editor) Internet-Draft Nortel Networks Expires: September 29, 2003 March 31, 2003 OPES tracing facility draft-ietf-opes-tracing 1. Introduction The Open Pluggable Edge Services (OPES) architecture enables = cooperative application services (OPES services) between a data = provider, a data consumer, and zero or more OPES processors. The = application services under consideration analyze and possibly transform = application-level messages exchanged between the data provider and the = data consumer. The execution of such services is governed by a set of rules installed = on the OPES processor. The rules enforcement can trigger the execution = of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of = service execution by communicating and collaborating with one or more = remote callout servers. As described in [], an OPES processor = communicates with and invokes services on a callout server by using a = callout protocol. In [], the IAB has required the OPES working group to support tracing = and notification. This document addresses these IAB requirements. The = document examines the effect of tracing and notification requirements = on OPES architecture and callout protocol []. In particular, the work = identifies traceable entities in an OPES flow and how this information = is relayed to end points. As per the architecture document [], there is a requirement of relaying = tracing information in-band. The document investigate this possibility = and discusses possible methods that could be used to detect faulty OPES = processors by end points on an OPES flow.=20 The document is organized as follows: Section 2 considers ? Section 3? = etc.=20 2. Basic Definitions - REFERENCE POINT - a reference that may be used out-of-band to=20 perform a specific function.=20 An example may be URI for the privacy policy, center of authority=20 URI, server address, etc. Usually no protocol is provided to access=20 the reference point. =20 - INFORMATION POINT - implies presence of the protocol to access=20 detailed information at this point. Example may be URI to get=20 a certificate for virus checker or content filter, examine=20 and set profile setting and active preferences. - IDENTIFIER - provides a unique binding to detailed persistent=20 information. For example "transformation-applied : fe123" gives=20 a participant ability to enquire (and maybe cache) details of=20 the transformation fe123. Use of such (opaque) identifiers=20 does not require prior knowledge and does not create a burden=20 of storing additional information - this is just a tag for=20 persistent information (not message-specific). 3. Requirements for Notification in an OPES Flow This section takes a look at the IAB requirements (3.1) and (3.2) and = how they relate to notification 3.1 Notification Requirements There are requirements on the architecture [] to assist content = provider applications in detecting and responding to data consumer = applications actions by OPES intermediaries that are deemed = inappropriate by the content provider. This is referred to as = notification. In general, notification goes in opposite direction of tracing and = cannot be attached to application messages that it notifies about. This = can be done out-band and may require the development of a new protocol. = In general, this opposite-direction, outside-of-message scheme is = difficult to support.=20 NOTE: When would a content provider issue such request?=20 How would such mechanism be used?=20 Randomly, or on a statistical basis?=20 Or manually? Is such a scheme of practical relevance? 3.1.1 Notification Concerns A major concern with notification is scalability. For example, it is = not practical to assume that a content provider is interested in = receiving a notification for every HTTP response sent out. As such, a = mechanism for explicit request of notification May be required.=20 Privacy is another concern. Maybe a user doesn't want to reveal to any = content provider all the OPES services that have been applied on her = behalf. For example, why should every content provider know what exact = virus scanner a user is using? 3.2 How to Fulfill Notifications Requirements IAB consideration (3.1) [] suggests that the overall OPES framework = needs to assist content providers in detecting and responding to = client-centric actions by OPES intermediaries that are deemed = inappropriate by the content provider. This requirement is hard to implement since most client-centric actions = happen _after_ the application message left the content provider(s) = and, thus, notifications cannot be piggy-backed to application messages = and have to travel in the opposite direction of traces. Note: Need to explain more here. IAB consideration (3.2) [] can be satisfied by the development of a = tracing facility. In this regard, it is recommended that tracing SHOULD = be always-on, just like HTTP Via headers now. This should eliminate = notification as a separate requirement. If the OPES end points cooperate then notification can be supported by = tracing. It is recommended that content providers that suspect or = experience difficulties do the following: 1. Check whether requests they receive pass through OPES intermediaries. Presence of OPES tracing info will determine that. This check is only possible for request/response protocols. For other protocols (e.g., broadcast or push), the provider would have to assume that OPES intermediaries are involved until proven otherwise. 2. If OPES intermediaries are suspected, request OPES traces from potentially affected user(s). The trace will be a part of the application message received by the user software. If users cooperate, the provider(s) have all the information they need. If users do not cooperate, the provider(s) cannot do much about it (they might be able to deny service to uncooperative users in some cases). 3. Some traces may indicate that more information is available by accessing certain resources on the specified OPES intermediary or elsewhere. Content providers may query for more information in that case. 4. If everything else fails, providers can enforce no-adaptation policy using appropriate OPES bypass mechanisms and/or end-to-end mechanisms. 4. Requirements for Tracing in an OPES Flow In [], the IAB has required that the OPES architecture provide tracing = and debugging facilities. From [], the OPES architecture SHOULD assist = consumer application in detecting the behavior of OPES processors and = callout servers to potentially allow them to identify imperfect or = compromised operations.=20 =20 The OPES architecture document [] has addressed these concerns at a = higher level. The architecture requires that tracing be feasible on the = OPES flow per OPES processor using in-band annotation. This requirement = provides a participant with the ability to detect OPES intermediaries = in the course of normal interaction.=20 4.1 What is traceable? End OPES points must be able to trace the following: 1. OPES processors that are involved. 2. OPES services (including callout services) that were performed on a = request or response.=20 3. TBD 4.2 Tracing and Trust Domains Tracing is limited to trust domain. Entities outside of that domain may = or may not see any traces, depending on domain policies or = configuration. Therefore, there is no need for mandatory end-to-end = tracing facility. For example, if an OPES system is on the content = provider "side", end-users are not guaranteed any traces. If an OPES = system is working inside end-user domain, the origin server is not = guaranteed any traces related to user requests. There are two distinct uses of traces. First, is to SHOULD enable the = "end (content producer or consumer) to detect OPES processor presence = within end's trust domain. Such "end" should be able to see a trace = entry, but does not need to be able to interpret it beyond = identification of the trust domain(s).=20 Second, the domain administrator SHOULD be able to take a trace entry = (possibly supplied by an "end? as an opaque string) and interpret it. = The administrator must be able to identify OPES processor(s) involved = and may be able to identify applied adaptation services along with = other message-specific information. That information SHOULD help to = explain what OPES agent(s) were involved and what they did. It may be = impractical to provide all the required information in all cases. This = document view a trace record as a hint, as opposed to an exhaustive = audit. Since the administrators of various trust domains can have various ways = of looking into tracing, they MAY require the choice of freedom in what = to put in trace records and how to format them. Trace records should be = easy to extend beyond basic OPES requirements. Trace management = algorithms should treat trace records as opaque data to the extent = possible. It is not expected that entities in one trust domain to be able to get = all OPES-related feedback from entities in other trust domains. For = example, if an end-user suspects that a served is corrupted by a = callout service, there is no guarantee that the use will be able to = identify that service, contact its owner, or debug it _unless_ the = service is within my trust domain. This is no different from the = current situation where it is impossible, in general, to know the = contact person for an application on an origin server that generates = corrupted HTML; and even if the person is known, one should not expect = that person to respond to end-user queries. 4.3 In-Band Tracing The architecture [] states that races must be in-band. This requirement = limits the number of application protocols that OPES can adapt and the = amount of details a trace record can convey. The set of protocols that can support tracing for OPES Flow must be = clearly documented. The architecture does not prevent implementers of = developing out-of-band protocols and techniques to address the above = limitation.=20 4.3.1 Tracing information granularity and persistence levels The information may be: - message-related, e.g. "virus checking done - passed", "content = filtering applied", "translated from quibbish to danqush". Such = information should be supplied with each message and indicate that = specific action was taken. All data that describes specific actions = performed for the message should be provided with that message, as = there is no other way to find message level details later. OPES = application (including OPES processor and all application modules and = callout servers involved) is not supposed to keep volatile information = after request processing is done.=20 - session related.=20 TBD Session level data must be preserved for the duration of the session. = OPES processor is responsible for inserting notifications if = session-level information changes.=20 Examples of session-related information is "virus checker=20 abcd build 123 enabled", "OPES server id=3Dxyz present".=20 - log information id. This may be used e.g. for accounting and = non-repudiation purposes. Detailed information referenced by this id = may be not available online but can be retrieved later by some off-line = procedure. - server related persistent information, e.g. "OPES center of authority = ", "privacy policy ". It may be also presented once per = session and it does not change between sessions. - end-point related data: what profile is activated (profile ID), where = to get profile details, where to set preferences. I'm not sure how far = we should go in this direction.=20 4.4 OCP Support for Tracing It is the task of an OPES processor to add trace records to application = messages. In this case, OCP protocol is not affected by tracing = requirements for the following reasons: a) Exclusive assignment simplifies the protocol. b) There are use cases where callout services adapt payload regardless = of the application protocol in use and leave header adjustment to OPES = processor or other services. For example, think of a generic text = translation or image modification service; such services require = payload encoding knowledge but can be application-independent if OPES = processor can supply them with just the payload. c) OPES processor is always _able_ to trace its own invocation and = service(s) execution because OPES processor must understand the = application protocol. Assigning these tracing tasks to callout servers = is just an optimization in cases where callout servers manipulate = application message headers. d) May not be able to trace all services that are done at the callout = server. e) It makes OPES compliance checks easier when remote third party = callout servers are used. f) Servers or services MAY add their own OPES trace records, of course. 4.5 Protocol Binding to Tracing How tracing is added is application protocol-specific and will be = documented in separate drafts. This work documents what tracing = information is required and some common tracing elements. 5. Security Considerations ------_=_NextPart_000_01C2FE25.F2688E7E-- From owner-ietf-openproxy@mail.imc.org Tue Apr 8 19:53:47 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08585 for ; Tue, 8 Apr 2003 19:53:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NkPJM025896 for ; Tue, 8 Apr 2003 16:46:25 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38NkOnP025895 for ietf-openproxy-bks; Tue, 8 Apr 2003 16:46:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NkNJM025889 for ; Tue, 8 Apr 2003 16:46:24 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h38NmAKq027697; Tue, 8 Apr 2003 17:48:11 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h38NjtZ02420; Tue, 8 Apr 2003 17:45:55 -0600 Date: Tue, 8 Apr 2003 17:45:55 -0600 Message-Id: <200304082345.h38NjtZ02420@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: info@utel.net Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <5.2.0.9.0.20030408112857.0280b180@mail.utel.net> Subject: Re: FW: feedback: OCP version head_sid2 thread: Try 2 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think we need to stick with the terms "OPES processor" and "callout servers". If it helps, think that the terms are abbreviations for "OPES-enabled proxy processor" and "a server performing OPES services in response to requests from an OPES-enabled proxy processor". It seems like a good idea to me to have OCP headers that mean "The OPES processor A expects OPES service X to be applied to this data" (these might even be ordered) and "callout server B applied OPES service X to this data". That doesn't mean that the headers MUST be copied to the tracing data on the messages that are part of the proxied data (but they COULD be). I'm skeptical about using these headers to avoid loop detection, though. That's a local implementation matter. Sometimes it will work, sometimes the services might actually have loops (apply unbase64, translate gif to jpg, apply base64, apply unbase64, translate color to bw, apply base64). Still, the headers would be useful for workflow organization, even if loops are OK. Hilarie From owner-ietf-openproxy@mail.imc.org Wed Apr 9 02:38:16 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16061 for ; Wed, 9 Apr 2003 02:38:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h396H6JM012502 for ; Tue, 8 Apr 2003 23:17:06 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h396H6W7012501 for ietf-openproxy-bks; Tue, 8 Apr 2003 23:17:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h396H5JM012490 for ; Tue, 8 Apr 2003 23:17:05 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h396H9vj030107; Wed, 9 Apr 2003 00:17:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h396H9UC030106; Wed, 9 Apr 2003 00:17:09 -0600 (MDT) (envelope-from rousskov) Date: Wed, 9 Apr 2003 00:17:09 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Tracing Draft version-0004082003 In-Reply-To: <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.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: On Tue, 8 Apr 2003, Abbie Barbir wrote: > Attached is the -00 version of the tracing draft. > Please keep in mind it is work in progress. > Feedback is required. Abbie, This is a great start, especially given a very short time you had to write this first version of the draft! Specific comments are inlined. I did not review the overall structure of the draft because I think it is premature to do that (need more "meat" and it is not yet clear whether some of the current sections are going to stay). N.B. Pease format using 72 character line length if possible -- it makes it easier (for some of us) to quote and comment. Thank you. > OPES tracing facility How about just "OPES Tracing"? Does "Facility" mean something specific? Will there be other (non "facility") OPES tracing drafts? > draft-ietf-opes-tracing > > 1. Introduction > > The Open Pluggable Edge Services (OPES) architecture enables cooperative > application services (OPES services) between a data provider, a data consumer, > and zero or more OPES processors. The application services under > consideration analyze and possibly transform application-level messages > exchanged between the data provider and the data consumer. > > The execution of such services is governed by a set of rules installed on the > OPES processor. The rules enforcement can trigger the execution of service > applications local to the OPES processor. > > Alternatively, the OPES processor can distribute the responsibility of service > execution by communicating and collaborating with one or more remote callout > servers. As described in [], an OPES processor communicates with and invokes > services on a callout server by using a callout protocol. > > In [], the IAB has required the OPES working group to support tracing and > notification. This document addresses these IAB requirements. IAB (RFC 3238) does not require support of anything. It lists considerations that the WG should _address_: "The purpose of this document is not to recommend specific solutions for OPES, or even to mandate specific functional requirements.... Instead, these are recommendations on issues that any OPES solutions standardized in the IETF should be required to address, similar to the "Security Considerations" currently required in IETF documents [RFC2316]. As an example, one way to address security issues is to show that appropriate security mechanisms have been provided in the protocol, and another way to address security issues is to demonstrate that no security issues apply to this particular protocol. There is a huge difference between "requiring support" and enumerating "issues that OPES solutions should be required to address". Let's not shoot ourselves in the foot. :-) Also, RFC 3238 does not contain the word "trace" or "tracing", just "notification". I would suggest saying something like this: IAB has required OPES solutions to address end user and content provider notification concerns. This document specifies tracing mechanisms that address those concerns. It would be nice to explain somewhere why we are not calling this document OPES Notification [Facility]. > The document examines the effect of tracing and notification > requirements on OPES architecture and callout protocol []. In > particular, the work identifies traceable entities in an OPES flow > and how this information is relayed to end points. what information? > As per the architecture document [], there is a requirement of > relaying tracing information in-band. The document investigate this > possibility and discusses possible methods that could be used to > detect faulty OPES processors by end points on an OPES flow. What about faulty callout servers? Do we have a term that describes OPES system (processor + callout servers + whatever else is out there that is OPES-related)? > The document is organized as follows: Section 2 considers ? Section > 3? etc. > > > 2. Basic Definitions > > - REFERENCE POINT - a reference that may be used out-of-band to > perform a specific function. > > An example may be URI for the privacy policy, center of authority > URI, server address, etc. Usually no protocol is provided to > access the reference point. > > - INFORMATION POINT - implies presence of the protocol to access > detailed information at this point. Example may be URI to get > a certificate for virus checker or content filter, examine > and set profile setting and active preferences. > > - IDENTIFIER - provides a unique binding to detailed persistent > information. For example "transformation-applied : fe123" gives a > participant ability to enquire (and maybe cache) details of the > transformation fe123. Use of such (opaque) identifiers does not > require prior knowledge and does not create a burden of storing > additional information - this is just a tag for persistent > information (not message-specific). The above classification seems like a result of protocol over-engineering to me. Would it be possible to avoid introducing any classifications/terms until the draft starts actually _using_ them for a specific purpose? This will save us a lot of time -- there is no reason (and it is very difficult) to discuss something that is not used (yet). > 3. Requirements for Notification in an OPES Flow > > > This section takes a look at the IAB requirements (3.1) and (3.2) and how they > relate to notification > > 3.1 Notification Requirements > > There are requirements on the architecture [] to assist content provider > applications in detecting and responding to data consumer applications actions > by OPES intermediaries that are deemed inappropriate by the content provider. > This is referred to as notification. > > In general, notification goes in opposite direction of tracing and cannot be > attached to application messages that it notifies about. If we compare notification with tracing like that, we should talk about/define tracing first and only then provide a comparison. An "opposite direction" illustration (figure) would be nice here! > This can be done "This has to be done" ? > out-band and may require the development of a new protocol. In general, this > opposite-direction, outside-of-message scheme is difficult to support. What does it mean "difficult to support"? Consider removing that sentence. (it's OK in a conversation, but not in a spec) This text is of great importance because we are, essentially, saying that the "ideal" scheme that IAB folks envisioned is not practical. We need to be as specific as possible here. > NOTE: When would a content provider issue such request? What request? > How would such > mechanism be used? Randomly, or on a statistical basis? Or manually? Is such > a scheme of practical relevance? In the above, there is no definition of the "mechanism" detailed enough to answer these questions. > 3.1.1 Notification Concerns > > A major concern with notification is scalability. For example, it is not > practical to assume that a content provider is interested in receiving a > notification for every HTTP response sent out. As such, a mechanism for > explicit request of notification May be required. Why is it not practical?! Some content providers would love to know exactly what their clients are doing with their content. They would be willing to double server capacity to handle the load. "Not scalable" usually implies non-linear (hopefully exponential) growth with the number of messages or notification-generation points. You need to show such growth (or something similar) if you want to play the scalability card. What does not scale and when? > Privacy is another concern. Maybe a user doesn't want to reveal to any content > provider all the OPES services that have been applied on her behalf. For > example, why should every content provider know what exact virus scanner a > user is using? Consider rephrasing to something like this: End point privacy is a concern. An end user may consider information about OPES services applied on her behalf as private. For example, if translation for braille device has been applied, it can be concluded that the user is having eyesight problems; such information may be misused if the user is applying for a job online. Similarly, a content provider may consider information about its OPES services private. For example, use of a specific OPES intermediary by a high traffic volume site may indicate business alliances that have not been publicly announced yet. Also consider adding something like this: Security is a concern. An attacker may benefit from knowledge of internal OPES services layout, execution order, software versions and other information likely to be present in automated notifications. Also consider adding something like this: The level of available details in notifications versus content provider interest in supporting notification is a concern. Experience shows that content providers often require very detailed information about user actions to be interested in notifications at all. For example, Hit Metering protocol (RFC XXX) has been designed to supply content providers with proxy cache hit counts, in an effort to reduce cache busting behavior which was cause by content providers desire to get accurate site "access counts". The Hit Metering protocol is not widely deployed today because it turns out that content providers are not interested enough in "just hit counts"; only knowing things like each client IP addresses, browser versions, or cookies would make providers interested enough to support cache hit notifications. Hit Metering experience is very relevant because Hit Metering protocol was designed to do for HTTP caching intermediaries what OPES notifications are meant to do for OPES intermediaries. (We would need to verify the above info with Hit Metering authors, but to the best of my knowledge it is correct) > 3.2 How to Fulfill Notifications Requirements > > IAB consideration (3.1) [] suggests that the overall OPES framework needs to > assist content providers in detecting and responding to client-centric actions > by OPES intermediaries that are deemed inappropriate by the content provider. > > This requirement is hard to implement since most client-centric actions happen What do we mean by "implement"? Write a spec? Code it up? Deploy? Other? Consider rephrasing to something like: To address this requirement directly, one would have to ... and then finish with a statement that we are addressing it indirectly by providing tracing mechanisms that assist interested providers in detecting and responding to inappropriate OPES actions. Say how they assist (you already do the latter now, below). > _after_ the application message left the content provider(s) and, thus, > notifications cannot be piggy-backed to application messages and have to > travel in the opposite direction of traces. > > Note: Need to explain more here. > IAB consideration (3.2) [] can be satisfied by the development of a tracing > facility. In this regard, it is recommended that tracing SHOULD be always-on, > just like HTTP Via headers now. This should eliminate notification as a > separate requirement. Why not MUST be always-on? We are talking about interoperability here (a broken intermediary that does not use Via-OPES headers is an interoperability problem because it cannot be bypassed). > If the OPES end points cooperate then notification can be supported by > tracing. It is recommended that content providers that suspect or experience > difficulties do the following: Recommended is too strong, IMO. "For example, ..." or "providers could ...", would be more appropriate. > 1. Check whether requests they receive pass through > OPES intermediaries. Presence of OPES tracing info > will determine that. This check is only possible for > request/response protocols. For other protocols (e.g., > broadcast or push), the provider would have to assume > that OPES intermediaries are involved until proven > otherwise. > > 2. If OPES intermediaries are suspected, > request OPES traces from potentially affected user(s). > The trace will be a part of the application message > received by the user software. If users cooperate, > the provider(s) have all the information they need. > If users do not cooperate, the provider(s) cannot > do much about it (they might be able to deny service > to uncooperative users in some cases). > > 3. Some traces may indicate that more information > is available by accessing certain resources on the > specified OPES intermediary or elsewhere. Content > providers may query for more information in that > case. > > 4. If everything else fails, providers can enforce > no-adaptation policy using appropriate OPES > bypass mechanisms and/or end-to-end mechanisms. > > > > > 4. Requirements for Tracing in an OPES Flow > > > In [], the IAB has required that the OPES architecture provide tracing and > debugging facilities. From [], the OPES architecture SHOULD assist consumer > application in detecting the behavior of OPES processors and callout servers > to potentially allow them to identify imperfect or compromised operations. > > The OPES architecture document [] has addressed these concerns at a higher > level. The architecture requires that tracing be feasible on the OPES flow per > OPES processor using in-band annotation. This requirement provides a > participant with the ability to detect OPES intermediaries in the course of > normal interaction. > > 4.1 What is traceable? > > End OPES points must be able to trace the following: Consider more accurate "The following entities can be identified in a trace" > 1. OPES processors that are involved. > 2. OPES services (including callout services) that were performed on a request > or response. "... performed on an application message" > 3. TBD Also, we need to add MUST/SHOULD/MAY to each traceable entity, I guess. > > 4.2 Tracing and Trust Domains > > Tracing is limited to trust domain. Entities outside of that domain may or may > not see any traces, depending on domain policies or configuration. Therefore, > there is no need for mandatory end-to-end tracing facility. For example, if an > OPES system is on the content provider "side", end-users are not guaranteed > any traces. If an OPES system is working inside end-user domain, the origin > server is not guaranteed any traces related to user requests. I am not sure about the above. It contradicts our statement that we are addressing IAB concerns. If there is no trace, we are not. I think it is reasonable to say that there MUST be at least one trace entry per "system". (A trust domain may include several such systems/entities, see the trust domain definition). > There are two distinct uses of traces. First, is to SHOULD enable the "end > (content producer or consumer) to detect OPES processor presence within end's > trust domain. Such "end" should be able to see a trace entry, but does not > need to be able to interpret it beyond identification of the trust domain(s). > Second, the domain administrator SHOULD be able to take a trace entry > (possibly supplied by an "end? as an opaque string) and interpret it. The > administrator must be able to identify OPES processor(s) involved and may be > able to identify applied adaptation services along with other message-specific > information. That information SHOULD help to explain what OPES agent(s) were > involved and what they did. It may be impractical to provide all the required > information in all cases. This document view a trace record as a hint, as > opposed to an exhaustive audit. > > Since the administrators of various trust domains can have various ways of > looking into tracing, they MAY require the choice of freedom in what to put in > trace records and how to format them. Trace records should be easy to extend > beyond basic OPES requirements. Trace management algorithms should treat trace > records as opaque data to the extent possible. > It is not expected that entities in one trust domain to be able to get all > OPES-related feedback from entities in other trust domains. For example, if an > end-user suspects that a served is corrupted by a callout service, there is no > guarantee that the use will be able to identify that service, contact its > owner, or debug it _unless_ the service is within my trust domain. This is no > different from the current situation where it is impossible, in general, to > know the contact person for an application on an origin server that generates > corrupted HTML; and even if the person is known, one should not expect that > person to respond to end-user queries. The above should have "system" granularity, not "domain" granularity because there can be different privacy policies within one trust domain. > 4.3 In-Band Tracing > > The architecture [] states that races must be in-band. This requirement limits > the number of application protocols that OPES can adapt and the amount of > details a trace record can convey. > > The set of protocols that can support tracing for OPES Flow must be clearly > documented. The architecture does not prevent implementers of developing > out-of-band protocols and techniques to address the above limitation. We should not (cannot) document the set of supported protocols directly, IMO. We should document _requirements_ for application protocols that want to support OPES traces. This is similar to OCP application bindings. > 4.3.1 Tracing information granularity and persistence levels > > The information may be: > > - message-related, e.g. "virus checking done - passed", "content filtering > applied", "translated from quibbish to danqush". Such information should be > supplied with each message and indicate that specific action was taken. All > data that describes specific actions performed for the message should be > provided with that message, as there is no other way to find message level > details later. OPES application (including OPES processor and all application > modules and callout servers involved) is not supposed to keep volatile > information after request processing is done. > > - session related. > TBD > > Session level data must be preserved for the duration of the session. OPES > processor is responsible for inserting notifications if session-level > information changes. > > Examples of session-related information is "virus checker abcd build 123 > enabled", "OPES server id=xyz present". > > - log information id. This may be used e.g. for accounting and non-repudiation > purposes. Detailed information referenced by this id may be not available > online but can be retrieved later by some off-line procedure. > > - server related persistent information, e.g. "OPES center of authority > ", "privacy policy ". It may be also presented once per session and > it does not change between sessions. > > - end-point related data: what profile is activated (profile ID), where to get > profile details, where to set preferences. I'm not sure how far we should go > in this direction. The above classification seems like a result of protocol over-engineering to me. Would it be possible to avoid introducing any classifications/terms until the draft starts actually _using_ them for a specific purpose? This will save us a lot of time -- there is no reason (and it is very difficult) to discuss something that is not used (yet). > 4.4 OCP Support for Tracing > > It is the task of an OPES processor to add trace records to application > messages. In this case, OCP protocol is not affected by tracing requirements > for the following reasons: Either say "If it is the task..." or remove "In this case, " :-) > a) Exclusive assignment simplifies the protocol. > > b) There are use cases where callout services adapt payload regardless of the > application protocol in use and leave header adjustment to OPES processor or > other services. For example, think of a generic text translation or image > modification service; such services require payload encoding knowledge but can > be application-independent if OPES processor can supply them with just the > payload. > > c) OPES processor is always _able_ to trace its own invocation and service(s) > execution because OPES processor must understand the application protocol. > Assigning these tracing tasks to callout servers is just an optimization in > cases where callout servers manipulate application message headers. > > d) May not be able to trace all services that are done at the callout server. > > e) It makes OPES compliance checks easier when remote third party callout > servers are used. > > f) Servers or services MAY add their own OPES trace records, of course. I wonder if it is appropriate for the draft to explain the motivation behind a decision, at such lengths? Should we just state requirements instead? > > 4.5 Protocol Binding to Tracing > > How tracing is added is application protocol-specific and will be documented > in separate drafts. This work documents what tracing information is required > and some common tracing elements. > > 5. Security Considerations I would suggest adding rules from the message below (or something similar). They are very specific things we can discuss/fix/polish, and they actually shape the conventions/intent of many tracing draft sections. The draft should be mostly about specific requirements, not our motivation or reasoning about what we might do and what design alternatives we have available. http://www.imc.org/ietf-openproxy/mail-archive/msg01875.html Please note that I am not saying the above rules are perfect! I am just saying we need more specific "bones" to grow the draft "meat" around, or we will never exit the jelly state. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 9 05:17:44 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19014 for ; Wed, 9 Apr 2003 05:17:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3993FJM007251 for ; Wed, 9 Apr 2003 02:03:15 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3993Fqn007250 for ietf-openproxy-bks; Wed, 9 Apr 2003 02:03:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3993EJM007243 for ; Wed, 9 Apr 2003 02:03:14 -0700 (PDT) Received: from f05a-5-135.d1.club-internet.fr ([212.194.100.135] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 193BU1-0006Ev-00 for ietf-openproxy@imc.org; Wed, 09 Apr 2003 02:03:06 -0700 Message-Id: <5.2.0.9.0.20030409104748.027546f0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Apr 2003 11:08:13 +0200 To: ietf-openproxy@imc.org From: jfcm Subject: Re: Tracing Draft version-0004082003 In-Reply-To: References: <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 08:17 09/04/03, Alex Rousskov wrote: >On Tue, 8 Apr 2003, Abbie Barbir wrote: >Abbie, > This is a great start, especially given a very short time you >had to write this first version of the draft! Specific comments are >inlined. Agree. > I did not review the overall structure of the draft because >I think it is premature to do that (need more "meat" and it is not >yet clear whether some of the current sections are going to stay). This is the problem with your way of thinking from the leaf to the trunc. Quite confusing to me sometimes. > > OPES tracing facility > >How about just "OPES Tracing"? Does "Facility" mean something specific? >Will there be other (non "facility") OPES tracing drafts? You talk about notification as specific and sometime separate from a blocked tacing. Also IAB expects a paper on tracing. > > draft-ietf-opes-tracing > > > > 1. Introduction > > > > The Open Pluggable Edge Services (OPES) architecture enables cooperative > > application services (OPES services) between a data provider, a data > consumer, > > and zero or more OPES processors. The application services under > > consideration analyze and possibly transform application-level messages > > exchanged between the data provider and the data consumer. > > > > The execution of such services is governed by a set of rules installed > on the > > OPES processor. The rules enforcement can trigger the execution of service > > applications local to the OPES processor. > > > > Alternatively, the OPES processor can distribute the responsibility of > service > > execution by communicating and collaborating with one or more remote > callout > > servers. As described in [], an OPES processor communicates with and > invokes > > services on a callout server by using a callout protocol. > > > > In [], the IAB has required the OPES working group to support tracing and > > notification. This document addresses these IAB requirements. > >IAB (RFC 3238) does not require support of anything. It lists considerations >that the WG should _address_: > > "The purpose of this document is not to recommend specific solutions > for OPES, or even to mandate specific functional requirements.... > Instead, these are recommendations on issues > that any OPES solutions standardized in the IETF should be required > to address, similar to the "Security Considerations" currently > required in IETF documents [RFC2316]. As an example, one way to > address security issues is to show that appropriate security > mechanisms have been provided in the protocol, and another way to > address security issues is to demonstrate that no security issues > apply to this particular protocol. > >There is a huge difference between "requiring support" and enumerating "issues >that OPES solutions should be required to address". Let's not shoot ourselves >in the foot. :-) > >Also, RFC 3238 does not contain the word "trace" or "tracing", just >"notification". > >I would suggest saying something like this: > > IAB has required OPES solutions to address end user and > content provider notification concerns. This document > specifies tracing mechanisms that address those concerns. > >It would be nice to explain somewhere why we are not calling this >document OPES Notification [Facility]. > > > The document examines the effect of tracing and notification > > requirements on OPES architecture and callout protocol []. In > > particular, the work identifies traceable entities in an OPES flow > > and how this information is relayed to end points. > >what information? > > > As per the architecture document [], there is a requirement of > > relaying tracing information in-band. The document investigate this > > possibility and discusses possible methods that could be used to > > detect faulty OPES processors by end points on an OPES flow. > >What about faulty callout servers? Do we have a term that describes >OPES system (processor + callout servers + whatever else is out there >that is OPES-related)? In this Abbie's context, with "OPES Processor" being actually used as a word for the whole system manager, I fully accept the wording. OPES Processor can be a process in a box or the supervisor of a large buch of callout/non-call out servers. > > The document is organized as follows: Section 2 considers ? Section > > 3? etc. > > > > > > 2. Basic Definitions > > > > - REFERENCE POINT - a reference that may be used out-of-band to > > perform a specific function. > > > > An example may be URI for the privacy policy, center of authority > > URI, server address, etc. Usually no protocol is provided to > > access the reference point. > > > > - INFORMATION POINT - implies presence of the protocol to access > > detailed information at this point. Example may be URI to get > > a certificate for virus checker or content filter, examine > > and set profile setting and active preferences. > > > > - IDENTIFIER - provides a unique binding to detailed persistent > > information. For example "transformation-applied : fe123" gives a > > participant ability to enquire (and maybe cache) details of the > > transformation fe123. Use of such (opaque) identifiers does not > > require prior knowledge and does not create a burden of storing > > additional information - this is just a tag for persistent > > information (not message-specific). > >The above classification seems like a result of protocol >over-engineering to me. Would it be possible to avoid introducing any >classifications/terms until the draft starts actually _using_ them for >a specific purpose? This will save us a lot of time -- there is no >reason (and it is very difficult) to discuss something that is not >used (yet). Leaf to trunc (Basica vs C) approach. I do support that initial lexical referencing. Skip the reading if you dislike it and refere to it further on. Reading has not to be linear. Keep the info of where is the definition, so you dont have to master it first shot. Makes life easier, reading simpler and debates quicker. Our main problem here is word definition, and where they fit in a commonly accepted model. > > 3. Requirements for Notification in an OPES Flow > > > > This section takes a look at the IAB requirements (3.1) and (3.2) and > how they > > relate to notification > > > > 3.1 Notification Requirements > > > > There are requirements on the architecture [] to assist content provider > > applications in detecting and responding to data consumer applications > actions > > by OPES intermediaries that are deemed inappropriate by the content > provider. > > This is referred to as notification. > > > > In general, notification goes in opposite direction of tracing and > cannot be > > attached to application messages that it notifies about. > >If we compare notification with tracing like that, we should talk >about/define tracing first and only then provide a comparison. > >An "opposite direction" illustration (figure) would be nice here! > > > This can be done > >"This has to be done" ? > > > out-band and may require the development of a new protocol. In general, > this > > opposite-direction, outside-of-message scheme is difficult to support. > >What does it mean "difficult to support"? Consider removing that >sentence. (it's OK in a conversation, but not in a spec) This text is >of great importance because we are, essentially, saying that the >"ideal" scheme that IAB folks envisioned is not practical. We need to >be as specific as possible here. > > > NOTE: When would a content provider issue such request? > >What request? > > > How would such > > mechanism be used? Randomly, or on a statistical basis? Or manually? > Is such > > a scheme of practical relevance? > >In the above, there is no definition of the "mechanism" detailed enough to >answer these questions. > > > 3.1.1 Notification Concerns > > > > A major concern with notification is scalability. For example, it is not > > practical to assume that a content provider is interested in receiving a > > notification for every HTTP response sent out. As such, a mechanism for > > explicit request of notification May be required. > >Why is it not practical?! Some content providers would love to know exactly >what their clients are doing with their content. They would be willing to >double server capacity to handle the load. > >"Not scalable" usually implies non-linear (hopefully exponential) growth with >the number of messages or notification-generation points. You need to show >such growth (or something similar) if you want to play the scalability card. >What does not scale and when? > > > Privacy is another concern. Maybe a user doesn't want to reveal to any > content > > provider all the OPES services that have been applied on her behalf. For > > example, why should every content provider know what exact virus scanner a > > user is using? > >Consider rephrasing to something like this: > > End point privacy is a concern. An end user may consider information > about OPES services applied on her behalf as private. For example, if > translation for braille device has been applied, it can be concluded > that the user is having eyesight problems; such information may be > misused if the user is applying for a job online. Similarly, a content > provider may consider information about its OPES services private. > For example, use of a specific OPES intermediary by a high traffic > volume site may indicate business alliances that have not been publicly > announced yet. > >Also consider adding something like this: > > Security is a concern. An attacker may benefit from knowledge > of internal OPES services layout, execution order, software > versions and other information likely to be present in > automated notifications. > >Also consider adding something like this: > > The level of available details in notifications versus content > provider interest in supporting notification is a concern. Experience > shows that content providers often require very detailed information > about user actions to be interested in notifications at all. For > example, Hit Metering protocol (RFC XXX) has been designed to supply > content providers with proxy cache hit counts, in an effort to reduce > cache busting behavior which was cause by content providers desire to > get accurate site "access counts". The Hit Metering protocol is not > widely deployed today because it turns out that content providers are > not interested enough in "just hit counts"; only knowing things like > each client IP addresses, browser versions, or cookies would make > providers interested enough to support cache hit notifications. Hit > Metering experience is very relevant because Hit Metering protocol was > designed to do for HTTP caching intermediaries what OPES notifications > are meant to do for OPES intermediaries. > > (We would need to verify the above info with Hit Metering > authors, but to the best of my knowledge it is correct) Is it necessary to so exnesively motivate a decision. It would be helpfull in foot notes. Should notes be permited? > > 3.2 How to Fulfill Notifications Requirements > > > > IAB consideration (3.1) [] suggests that the overall OPES framework > needs to > > assist content providers in detecting and responding to client-centric > actions > > by OPES intermediaries that are deemed inappropriate by the content > provider. > > > > This requirement is hard to implement since most client-centric actions > happen > >What do we mean by "implement"? Write a spec? Code it up? Deploy? Other? >Consider rephrasing to something like: > > To address this requirement directly, one would have to ... > >and then finish with a statement that we are addressing it indirectly by >providing tracing mechanisms that assist interested providers in detecting and >responding to inappropriate OPES actions. Say how they assist (you already do >the latter now, below). > > > _after_ the application message left the content provider(s) and, thus, > > notifications cannot be piggy-backed to application messages and have to > > travel in the opposite direction of traces. > > > > Note: Need to explain more here. > > > IAB consideration (3.2) [] can be satisfied by the development of a tracing > > facility. In this regard, it is recommended that tracing SHOULD be > always-on, > > just like HTTP Via headers now. This should eliminate notification as a > > separate requirement. > >Why not MUST be always-on? We are talking about interoperability here (a >broken intermediary that does not use Via-OPES headers is an interoperability >problem because it cannot be bypassed). If HTTP Via is SHOULD it can only be SHOULD. > > If the OPES end points cooperate then notification can be supported by > > tracing. It is recommended that content providers that suspect or > experience > > difficulties do the following: > >Recommended is too strong, IMO. "For example, ..." or "providers could ...", >would be more appropriate. > > > 1. Check whether requests they receive pass through > > OPES intermediaries. Presence of OPES tracing info > > will determine that. This check is only possible for > > request/response protocols. For other protocols (e.g., > > broadcast or push), the provider would have to assume > > that OPES intermediaries are involved until proven > > otherwise. > > > > 2. If OPES intermediaries are suspected, > > request OPES traces from potentially affected user(s). > > The trace will be a part of the application message > > received by the user software. If users cooperate, > > the provider(s) have all the information they need. > > If users do not cooperate, the provider(s) cannot > > do much about it (they might be able to deny service > > to uncooperative users in some cases). > > > > 3. Some traces may indicate that more information > > is available by accessing certain resources on the > > specified OPES intermediary or elsewhere. Content > > providers may query for more information in that > > case. > > > > 4. If everything else fails, providers can enforce > > no-adaptation policy using appropriate OPES > > bypass mechanisms and/or end-to-end mechanisms. > > > > 4. Requirements for Tracing in an OPES Flow > > > > > > In [], the IAB has required that the OPES architecture provide tracing and > > debugging facilities. From [], the OPES architecture SHOULD assist consumer > > application in detecting the behavior of OPES processors and callout > servers > > to potentially allow them to identify imperfect or compromised operations. > > > > The OPES architecture document [] has addressed these concerns at a higher > > level. The architecture requires that tracing be feasible on the OPES > flow per > > OPES processor using in-band annotation. This requirement provides a > > participant with the ability to detect OPES intermediaries in the course of > > normal interaction. > > > > 4.1 What is traceable? > > > > End OPES points must be able to trace the following: > >Consider more accurate "The following entities can be identified in a trace" > > > 1. OPES processors that are involved. > > 2. OPES services (including callout services) that were performed on a > request > > or response. > >"... performed on an application message" > > > 3. TBD > >Also, we need to add MUST/SHOULD/MAY to each traceable entity, I guess. MAY. to be consitent with your wording. > > 4.2 Tracing and Trust Domains > > > > Tracing is limited to trust domain. Entities outside of that domain may > or may > > not see any traces, depending on domain policies or configuration. > Therefore, > > there is no need for mandatory end-to-end tracing facility. For > example, if an > > OPES system is on the content provider "side", end-users are not guaranteed > > any traces. If an OPES system is working inside end-user domain, the origin > > server is not guaranteed any traces related to user requests. > >I am not sure about the above. It contradicts our statement that we are >addressing IAB concerns. If there is no trace, we are not. I think it is >reasonable to say that there MUST be at least one trace entry per "system". >(A trust domain may include several such systems/entities, see the trust >domain definition). I think we are with option to turn it out. Privacy must be permitted. > > There are two distinct uses of traces. First, is to SHOULD enable the "end > > (content producer or consumer) to detect OPES processor presence within > end's > > trust domain. Such "end" should be able to see a trace entry, but does not > > need to be able to interpret it beyond identification of the trust > domain(s). > > > Second, the domain administrator SHOULD be able to take a trace entry > > (possibly supplied by an "end? as an opaque string) and interpret it. The > > administrator must be able to identify OPES processor(s) involved and > may be > > able to identify applied adaptation services along with other > message-specific > > information. That information SHOULD help to explain what OPES agent(s) > were > > involved and what they did. It may be impractical to provide all the > required > > information in all cases. This document view a trace record as a hint, as > > opposed to an exhaustive audit. > > > > Since the administrators of various trust domains can have various ways of > > looking into tracing, they MAY require the choice of freedom in what to > put in > > trace records and how to format them. Trace records should be easy to > extend > > beyond basic OPES requirements. Trace management algorithms should > treat trace > > records as opaque data to the extent possible. > > > It is not expected that entities in one trust domain to be able to get all > > OPES-related feedback from entities in other trust domains. For > example, if an > > end-user suspects that a served is corrupted by a callout service, > there is no > > guarantee that the use will be able to identify that service, contact its > > owner, or debug it _unless_ the service is within my trust domain. This > is no > > different from the current situation where it is impossible, in general, to > > know the contact person for an application on an origin server that > generates > > corrupted HTML; and even if the person is known, one should not expect that > > person to respond to end-user queries. > >The above should have "system" granularity, not "domain" granularity because >there can be different privacy policies within one trust domain. > > > 4.3 In-Band Tracing > > > > The architecture [] states that races must be in-band. This requirement > limits > > the number of application protocols that OPES can adapt and the amount of > > details a trace record can convey. > > > > The set of protocols that can support tracing for OPES Flow must be clearly > > documented. The architecture does not prevent implementers of developing > > out-of-band protocols and techniques to address the above limitation. > >We should not (cannot) document the set of supported protocols directly, IMO. >We should document _requirements_ for application protocols that want to >support OPES traces. This is similar to OCP application bindings. > > > 4.3.1 Tracing information granularity and persistence levels > > > > The information may be: > > > > - message-related, e.g. "virus checking done - passed", "content filtering > > applied", "translated from quibbish to danqush". Such information should be > > supplied with each message and indicate that specific action was taken. All > > data that describes specific actions performed for the message should be > > provided with that message, as there is no other way to find message level > > details later. OPES application (including OPES processor and all > application > > modules and callout servers involved) is not supposed to keep volatile > > information after request processing is done. > > > > - session related. > > TBD > > > > Session level data must be preserved for the duration of the session. OPES > > processor is responsible for inserting notifications if session-level > > information changes. > > > > Examples of session-related information is "virus checker abcd build 123 > > enabled", "OPES server id=xyz present". > > > > - log information id. This may be used e.g. for accounting and > non-repudiation > > purposes. Detailed information referenced by this id may be not available > > online but can be retrieved later by some off-line procedure. > > > > - server related persistent information, e.g. "OPES center of authority > > ", "privacy policy ". It may be also presented once per > session and > > it does not change between sessions. > > > > - end-point related data: what profile is activated (profile ID), where > to get > > profile details, where to set preferences. I'm not sure how far we > should go > > in this direction. > >The above classification seems like a result of protocol >over-engineering to me. Would it be possible to avoid introducing any >classifications/terms until the draft starts actually _using_ them for >a specific purpose? This will save us a lot of time -- there is no >reason (and it is very difficult) to discuss something that is not >used (yet). Pasted remark. Same comment. > > 4.4 OCP Support for Tracing > > > > It is the task of an OPES processor to add trace records to application > > messages. In this case, OCP protocol is not affected by tracing > requirements > > for the following reasons: > >Either say "If it is the task..." or remove "In this case, " :-) > > > a) Exclusive assignment simplifies the protocol. > > > > b) There are use cases where callout services adapt payload regardless > of the > > application protocol in use and leave header adjustment to OPES > processor or > > other services. For example, think of a generic text translation or image > > modification service; such services require payload encoding knowledge > but can > > be application-independent if OPES processor can supply them with just the > > payload. > > > > c) OPES processor is always _able_ to trace its own invocation and > service(s) > > execution because OPES processor must understand the application protocol. > > Assigning these tracing tasks to callout servers is just an optimization in > > cases where callout servers manipulate application message headers. > > > > d) May not be able to trace all services that are done at the callout > server. > > > > e) It makes OPES compliance checks easier when remote third party callout > > servers are used. > > > > f) Servers or services MAY add their own OPES trace records, of course. > >I wonder if it is appropriate for the draft to explain the motivation >behind a decision, at such lengths? Should we just state requirements >instead? Foot notes? > > 4.5 Protocol Binding to Tracing > > > > How tracing is added is application protocol-specific and will be > documented > > in separate drafts. This work documents what tracing information is > required > > and some common tracing elements. > > > > 5. Security Considerations > >I would suggest adding rules from the message below (or something >similar). They are very specific things we can discuss/fix/polish, and >they actually shape the conventions/intent of many tracing draft sections. >The draft should be mostly about specific requirements, not our motivation >or reasoning about what we might do and what design alternatives we have >available. > http://www.imc.org/ietf-openproxy/mail-archive/msg01875.html >Please note that I am not saying the above rules are perfect! I am just saying >we need more specific "bones" to grow the draft "meat" around, or we will >never exit the jelly state. Thank you both for the work achieved. jfc From owner-ietf-openproxy@mail.imc.org Wed Apr 9 09:14:12 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26758 for ; Wed, 9 Apr 2003 09:14:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39D3aJM025035 for ; Wed, 9 Apr 2003 06:03:36 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39D3ZxS025034 for ietf-openproxy-bks; Wed, 9 Apr 2003 06:03:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h39D3YJM025030 for ; Wed, 9 Apr 2003 06:03:34 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h39D3Zvj040306; Wed, 9 Apr 2003 07:03:35 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h39D3ZKe040305; Wed, 9 Apr 2003 07:03:35 -0600 (MDT) (envelope-from rousskov) Date: Wed, 9 Apr 2003 07:03:35 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Tracing Draft version-0004082003 In-Reply-To: <5.2.0.9.0.20030409104748.027546f0@mail.utel.net> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030409104748.027546f0@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: On Wed, 9 Apr 2003, jfcm wrote: > > > OPES tracing facility > > > >How about just "OPES Tracing"? Does "Facility" mean something specific? > >Will there be other (non "facility") OPES tracing drafts? > > You talk about notification as specific and sometime separate from a blocked > tacing. What is block tracing? What do you mean by "notification as specific ... blocked tracing"? > Also IAB expects a paper on tracing. What makes you think that? RFC 3238 does not contain the word "trace" or "tracing", just "notification". Did I miss it? > >What about faulty callout servers? Do we have a term that describes > >OPES system (processor + callout servers + whatever else is out there > >that is OPES-related)? > > In this Abbie's context, with "OPES Processor" being actually used > as a word for the whole system manager, I fully accept the wording. > OPES Processor can be a process in a box or the supervisor of a > large buch of callout/non-call out servers. OPES processor is defined in the architecture draft. The definition is not context dependent. Figure 1 in that draft clearly shows callout servers outside of the processor box. We can change the definition and/or the figure (and I would support a discussion about it), but until we do, we have to use the old concept whether we like it or not. > >The above classification seems like a result of protocol > >over-engineering to me. Would it be possible to avoid introducing any > >classifications/terms until the draft starts actually _using_ them for > >a specific purpose? This will save us a lot of time -- there is no > >reason (and it is very difficult) to discuss something that is not > >used (yet). > > Leaf to trunc (Basica vs C) approach. I do support that initial lexical > referencing. Skip the reading if you dislike it and refere to it further > on. Reading has not to be linear. Keep the info of where is the > definition, so you dont have to master it first shot. Makes life easier, > reading simpler and debates quicker. Our main problem here is word > definition, and where they fit in a commonly accepted model. You misinterpreted my comment. I am objecting not to forward-looking definitions (they are perfectly fine), but definition that are not _used_ anywhere. It does not make sense, IMO, to include debate-causing definitions (there is no consensus about the above definitions) when those definitions are not used! We can include them once we actually start using them. > Is it necessary to so exnesively motivate a decision. If a decision may contradict IAB expectations, then yes. > It would be helpfull in foot notes. Should notes be permited? As an Appendix, yes. I am fine with moving the above rant into an Appendix. > >Why not MUST be always-on? We are talking about interoperability here (a > >broken intermediary that does not use Via-OPES headers is an interoperability > >problem because it cannot be bypassed). > > If HTTP Via is SHOULD it can only be SHOULD. Why? HTTP does (did) not have IAB considerations to address. We have a much higher bar to jump over. > >Also, we need to add MUST/SHOULD/MAY to each traceable entity, I guess. > > MAY. to be consitent with your wording. Which wording? > >I am not sure about the above. It contradicts our statement that we are > >addressing IAB concerns. If there is no trace, we are not. I think it is > >reasonable to say that there MUST be at least one trace entry per "system". > >(A trust domain may include several such systems/entities, see the trust > >domain definition). > > I think we are with option to turn it out. Privacy must be permitted. If a provider has an option to turn _all_ tracing off, then we are not supporting notification in any shape or form. Privacy can be permitted by making trace entries contain no private information. Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 9 10:26:21 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00515 for ; Wed, 9 Apr 2003 10:26:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39EHhJM029365 for ; Wed, 9 Apr 2003 07:17:43 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39EHhuf029364 for ietf-openproxy-bks; Wed, 9 Apr 2003 07:17:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39EHfJM029356 for ; Wed, 9 Apr 2003 07:17:41 -0700 (PDT) Received: from f04a-8-15.d1.club-internet.fr ([212.194.79.15] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 193GOR-0001XA-00; Wed, 09 Apr 2003 07:17:39 -0700 Message-Id: <5.2.0.9.0.20030409161137.03265840@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Apr 2003 16:25:03 +0200 To: Alex Rousskov , ietf-openproxy@imc.org From: jfcm Subject: Re: Tracing Draft version-0004082003 In-Reply-To: References: <5.2.0.9.0.20030409104748.027546f0@mail.utel.net> <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030409104748.027546f0@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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 15:03 09/04/03, Alex Rousskov wrote: >On Wed, 9 Apr 2003, jfcm wrote: > > > > > OPES tracing facility > > > > > >How about just "OPES Tracing"? Does "Facility" mean something specific? > > >Will there be other (non "facility") OPES tracing drafts? > > > > You talk about notification as specific and sometime separate from a > blocked > > tacing. > >What is block tracing? What do you mean by "notification as specific >... blocked tracing"? I mean that if he permits to block the tracing facility (what you object) he documents case were there is no tracing and notification. So notification should be in the title. > > Also IAB expects a paper on tracing. >What makes you think that? RFC 3238 does not contain the word "trace" >or "tracing", just "notification". Did I miss it? lapsus calami. I meant IAB expects a paper on notification. Adding tracingis OK but notification must also be quoted in the title. > > >What about faulty callout servers? Do we have a term that describes > > >OPES system (processor + callout servers + whatever else is out there > > >that is OPES-related)? > > > > In this Abbie's context, with "OPES Processor" being actually used > > as a word for the whole system manager, I fully accept the wording. > > OPES Processor can be a process in a box or the supervisor of a > > large buch of callout/non-call out servers. > >OPES processor is defined in the architecture draft. The definition is >not context dependent. Figure 1 in that draft clearly shows callout >servers outside of the processor box. We can change the definition >and/or the figure (and I would support a discussion about it), but >until we do, we have to use the old concept whether we like it or not. I do dislike it. I say it. And I just say that Abbie's paper is acceptable even for a person outside of this WG knowing the reason of this language. > > >The above classification seems like a result of protocol > > >over-engineering to me. Would it be possible to avoid introducing any > > >classifications/terms until the draft starts actually _using_ them for > > >a specific purpose? This will save us a lot of time -- there is no > > >reason (and it is very difficult) to discuss something that is not > > >used (yet). > > > > Leaf to trunc (Basica vs C) approach. I do support that initial lexical > > referencing. Skip the reading if you dislike it and refere to it further > > on. Reading has not to be linear. Keep the info of where is the > > definition, so you dont have to master it first shot. Makes life easier, > > reading simpler and debates quicker. Our main problem here is word > > definition, and where they fit in a commonly accepted model. > >You misinterpreted my comment. I am objecting not to forward-looking >definitions (they are perfectly fine), but definition that are not >_used_ anywhere. It does not make sense, IMO, to include >debate-causing definitions (there is no consensus about the above >definitions) when those definitions are not used! We can include them >once we actually start using them. OK. You said you would not discuss that tevel in your mail. So I assumed the above. However I not fully dig into the definitions but I felt they brought some light on what he wanted to say and be of use in the futher debale. Will not fight for them if the text is clear without them. > > Is it necessary to so exnesively motivate a decision. > >If a decision may contradict IAB expectations, then yes. Is there not a way to document a position without entering them into the text? This makes the text to be part of a debate rather than a reference. This may give the feeling the examples are very important to the text, while they are only current examples. > > It would be helpfull in foot notes. Should notes be permited? > >As an Appendix, yes. I am fine with moving the above rant into an >Appendix. great. > > >Why not MUST be always-on? We are talking about interoperability here (a > > >broken intermediary that does not use Via-OPES headers is an > interoperability > > >problem because it cannot be bypassed). > > > > If HTTP Via is SHOULD it can only be SHOULD. > >Why? HTTP does (did) not have IAB considerations to address. We have a >much higher bar to jump over. IAB is not the reference for me. The reference is the consistency of what is considered. OPES are over HTTP. There should not be obliged more than the supporting HTTP protocol. Seems layer violation to me. > > >Also, we need to add MUST/SHOULD/MAY to each traceable entity, I guess. > > > > MAY. to be consitent with your wording. > >Which wording? Just above you used the word "can ". > > >I am not sure about the above. It contradicts our statement that we are > > >addressing IAB concerns. If there is no trace, we are not. I think it is > > >reasonable to say that there MUST be at least one trace entry per > "system". > > >(A trust domain may include several such systems/entities, see the trust > > >domain definition). > > > > I think we are with option to turn it out. Privacy must be permitted. > >If a provider has an option to turn _all_ tracing off, then we are not >supporting notification in any shape or form. Privacy can be permitted >by making trace entries contain no private information. If you accept to waste bandwidth and nanoseconds, yes. jfc From owner-ietf-openproxy@mail.imc.org Wed Apr 9 11:22:04 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02612 for ; Wed, 9 Apr 2003 11:22:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39FBNJM006342 for ; Wed, 9 Apr 2003 08:11:23 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39FBNX6006341 for ietf-openproxy-bks; Wed, 9 Apr 2003 08:11:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h39FBKJM006331 for ; Wed, 9 Apr 2003 08:11:21 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h39FBLvj043543; Wed, 9 Apr 2003 09:11:21 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h39FBLYi043542; Wed, 9 Apr 2003 09:11:21 -0600 (MDT) (envelope-from rousskov) Date: Wed, 9 Apr 2003 09:11:21 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Tracing Draft version-0004082003 In-Reply-To: <5.2.0.9.0.20030409161137.03265840@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030409104748.027546f0@mail.utel.net> <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75405670A3C@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030409104748.027546f0@mail.utel.net> <5.2.0.9.0.20030409161137.03265840@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: On Wed, 9 Apr 2003, jfcm wrote: > I mean that if he permits to block the tracing facility (what you > object) he documents case were there is no tracing and notification. > So notification should be in the title. I do not see where the current tracing draft documents notification support/assistance without tracing. Did I miss it? In fact, that is the primary reason I objected to giving one side an ability to disable all tracing -- without tracing we have no notification assistance! (and the latter is required) > > > Also IAB expects a paper on tracing. > >What makes you think that? RFC 3238 does not contain the word "trace" > >or "tracing", just "notification". Did I miss it? > > lapsus calami. I meant IAB expects a paper on notification. Adding > tracingis OK but notification must also be quoted in the title. Since the draft is actually about tracing (because we do not provide any direct support for notification) it is wrong to put notification in the title. Unless, of course, we want to say something like "OPES Tracing and lack of Notification" :-). > > > If HTTP Via is SHOULD it can only be SHOULD. > > > >Why? HTTP does (did) not have IAB considerations to address. We have a > >much higher bar to jump over. > > IAB is not the reference for me. The reference is the consistency of what > is considered. OPES are over HTTP. There should not be obliged more than > the supporting HTTP protocol. Seems layer violation to me. I see no layer violation whatsoever. It is like saying that SSL/TLS encryption over HTTP is a layer violation because HTTP layer is not secure. We are not affecting any compliant HTTP implementation by making OPES tracing mandatory. Also, OPES is over many things, not just HTTP. > >If a provider has an option to turn _all_ tracing off, then we are not > >supporting notification in any shape or form. Privacy can be permitted > >by making trace entries contain no private information. > > If you accept to waste bandwidth and nanoseconds, yes. It is not a waste, it is a trade-off. We trade additional information (like OPES system identification) for fewer bytes on the wire. Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 9 12:59:54 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06263 for ; Wed, 9 Apr 2003 12:59:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39GhRJM009246 for ; Wed, 9 Apr 2003 09:43:27 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39GhRQO009245 for ietf-openproxy-bks; Wed, 9 Apr 2003 09:43:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h39GhQJM009241 for ; Wed, 9 Apr 2003 09:43:26 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h39GhRvj045771 for ; Wed, 9 Apr 2003 10:43:27 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h39GhRwe045770; Wed, 9 Apr 2003 10:43:27 -0600 (MDT) (envelope-from rousskov) Date: Wed, 9 Apr 2003 10:43:27 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: set of OPES documents In-Reply-To: <5.2.0.9.0.20030406192433.03477ec0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030406192433.03477ec0@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: OCP Core and Tracing drafts need to talk about application-independent mechanisms. "Something(s)" need to talk about application-specific aspects of OCP and tracing. For example, OCP Core documents OCP messages that can be used to communicate HTTP messages and HTTP metadata (as opaque sequences of octets) between OPES processor and callout servers. Some other document has to explain what HTTP metadata really means to OPES processor and callout server when it is sent over OCP (and document metadata format if we decide that the format itself is application-specific). Similarly, Tracing draft documents general rules (e.g., OPES processors MUST/SHOULD/MAY add their IDs to the trace). Some other document has to explain how trace entries can be added to SMTP messages (MIME header field names and such). It would help authors to know the set of final OPES documents so that appropriate cross-references can be made before all documents are written. The set can change at any time, of course. I would like to suggest the following set. It is based on a principle that it is better to have one application-specific document per application. An alternative is to have one application-specific document per application, per application-independent draft. The former places all, say, HTTP-related things in one draft, yielding (#Facilities + #Applications) documents (convenient for those who implement/deploy/debug OPES _systems_ for HTTP). The latter allows for more fine-grained, facility-specific application drafts, yielding (#Facilities * #Applications) documents (convenient for those who implement/debug specific OPES facilities for HTTP). The set is incomplete, I only mention some documents we care about at this time: Application-independent documents: OPES Architecture draft-ietf-opes-architecture OPES Callout Protocol Core draft-ietf-opes-ocp OPES Tracing draft-ietf-opes-trace OPES Bypass draft-ietf-opes-bypass ... Application-specific documents: OPES adaptation of HTTP draft-ietf-opes-http OPES adaptation of SMTP draft-ietf-opes-smtp OPES adaptation of FooBarP draft-ietf-opes-foobarp ... Does the above make sense? Would you prefer the alternative (more of more specific drafts)? Other options like combining all application-independent drafts into one document? Also, given a relatively large number of related drafts, would it make any sense to have one short "OPES Requirements" draft that lists all available drafts and describes the relationship between them? Or do we want to repeat pretty much the same explanations in every draft instead? Are there similar cases in other WG? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 9 16:11:32 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12639 for ; Wed, 9 Apr 2003 16:11:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39JqiJM020144 for ; Wed, 9 Apr 2003 12:52:44 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39Jqilo020143 for ietf-openproxy-bks; Wed, 9 Apr 2003 12:52:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39JqeJM020137 for ; Wed, 9 Apr 2003 12:52:40 -0700 (PDT) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003040919523605100ndbfde>; Wed, 9 Apr 2003 19:52:37 +0000 From: "Oskar Batuner" To: "Alex Rousskov" , Subject: RE: set of OPES documents Date: Wed, 9 Apr 2003 15:52:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Wednesday, April 09, 2003 12:43 PM > To: ietf-openproxy@imc.org > Subject: set of OPES documents > > [...] > > The set is incomplete, I only mention some documents we care about at > this time: > > Application-independent documents: > > OPES Architecture > draft-ietf-opes-architecture > > OPES Callout Protocol Core > draft-ietf-opes-ocp > > OPES Tracing > draft-ietf-opes-trace > > OPES Bypass > draft-ietf-opes-bypass If I understand correctly the last one is about - very limited - set of directives. I'd suggest having a single document "OPES tracing, notification and directives" draft-ietf-opes-dirs-trace The rationale: subjects are tightly connected. There will be requests that are tracing directives (e.g. Set-tracing-level), there will be responses to directives that are very close to tracing/notification info ( - - ...). "Bypass" looks like low-granularity instruction about the desired level of transformation. ------------- And again - no, OPES is not evil! It is MAY be very useful for both content producers and content consumers. Let's not focus just on ways how to reduce possible harm, let's also look at the ways to maximize benefits. Why the first thing that comes in mind is "bypass"? Why not "activate", "translate", "enable-transformation"? ------------- If there will be OCP-related tracing features we need another document: draft-ietf-opes-ocp-trace Rationale: OCP is just one recommended callout protocol. We do not exclude usage of other callout protocols conforming to the OPES requirements (e.g. icap-based). Inserting OCP-related things into the document describing OPES flow will make OCP an integral part of the OPES spec. IMHO OCP should be positioned as a replaceable building block. > > ... > > Application-specific documents: > > OPES adaptation of HTTP > draft-ietf-opes-http > > OPES adaptation of SMTP > draft-ietf-opes-smtp > > OPES adaptation of FooBarP > draft-ietf-opes-foobarp For the reasons described above I'd suggest a separate set of docs: draft-ietf-opes-opcp-http draft-ietf-opes-opcp-smtp draft-ietf-opes-opcp-... > > ... > > Does the above make sense? Would you prefer the alternative (more of > more specific drafts)? Other options like combining all > application-independent drafts into one document? > > Also, given a relatively large number of related drafts, would it make > any sense to have one short "OPES Requirements" draft that lists all > available drafts and describes the relationship between them? Or do we > want to repeat pretty much the same explanations in every draft > instead? Are there similar cases in other WG? I agree - this is an important problem. There already is certain interrelated information scattered through different drafts. For example at some moment Hilarie referred to the figure 2 in the policy draft to explain some architectural elements. I am not sure that a person studying OPES architecture will easily find this connection. Adding a big group of documents without proper systematization may create even more confusion. Oskar From owner-ietf-openproxy@mail.imc.org Wed Apr 9 16:32:51 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13457 for ; Wed, 9 Apr 2003 16:32:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39KIYJM021488 for ; Wed, 9 Apr 2003 13:18:34 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39KIYlh021487 for ietf-openproxy-bks; Wed, 9 Apr 2003 13:18:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h39KIXJM021480 for ; Wed, 9 Apr 2003 13:18:33 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h39KIYvj052109; Wed, 9 Apr 2003 14:18:34 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h39KIY7K052108; Wed, 9 Apr 2003 14:18:34 -0600 (MDT) (envelope-from rousskov) Date: Wed, 9 Apr 2003 14:18:34 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: set of OPES documents In-Reply-To: Message-ID: References: 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: On Wed, 9 Apr 2003, Oskar Batuner wrote: > > Application-independent documents: > > > > OPES Architecture > > draft-ietf-opes-architecture > > > > OPES Callout Protocol Core > > draft-ietf-opes-ocp > > > > OPES Tracing > > draft-ietf-opes-trace > > > > OPES Bypass > > draft-ietf-opes-bypass > > If I understand correctly the last one is about - very limited - set > of directives. I'd suggest having a single document "OPES tracing, > notification and directives" > > draft-ietf-opes-dirs-trace > > The rationale: subjects are tightly connected. There will be > requests that are tracing directives (e.g. Set-tracing-level), there > will be responses to directives that are very close to > tracing/notification info ( - - ...). > "Bypass" looks like low-granularity instruction about the desired > level of transformation. Good point! I agree that it may make sense to have one draft that covers all communications between end points and OPES processors (tracing, bypass, etc.) If we go down that path, we need a more appropriate name though. How about: "Processor-to-end communications in OPES" draft-ietf-opes-end or "OPES processor and end points communications" draft-ietf-opes-end or something like that? Does that cover all uses we know of right now? > Why the first thing that comes in mind is "bypass"? Why not > "activate", "translate", "enable-transformation"? "Bypass" is shorter and easier to grasp with little context. :-) > If there will be OCP-related tracing features we need another document: > > draft-ietf-opes-ocp-trace > > Rationale: OCP is just one recommended callout protocol. We do not > exclude usage of other callout protocols conforming to the OPES > requirements (e.g. icap-based). Inserting OCP-related things into > the document describing OPES flow will make OCP an integral part of > the OPES spec. I agree with you rationale, but not with your conclusion/suggestion. IMO, If there will be OCP-related tracing features, they can go into OCP document (draft-ietf-opes-ocp) or (draft-ietf-opes-ocp-core). > IMHO OCP should be positioned as a replaceable building block. I agree. However, a "replaceable building block" assumes some common interface. The presence of such (undocumented) interface has an effect on what you propose below. > > Application-specific documents: > > > > OPES adaptation of HTTP > > draft-ietf-opes-http > > > > OPES adaptation of SMTP > > draft-ietf-opes-smtp > > > > OPES adaptation of FooBarP > > draft-ietf-opes-foobarp > > For the reasons described above I'd suggest a separate set of docs: > > draft-ietf-opes-opcp-http > draft-ietf-opes-opcp-smtp > draft-ietf-opes-opcp-... I assume you meant "-ocp-". I see your reasons, but have to say that if we go down that path, we would _also_ need application bindings for draft-ietf-opes-end: draft-ietf-opes-end-http draft-ietf-opes-end-smtp draft-ietf-opes-end-... Instead, we could try to keep OCP as a replaceable block, but assume (keep in mind) that whatever interface is needed for *-app-protocol drafts would be common among all "OCPs". For example, metadata meaning and service IDs would be common among all OCPs. This approach limits our theoretical abilities/flexibility, but, since chances of two OCPs long-term survival are pretty slim, we may be OK. Comments? Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 9 20:31:51 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21339 for ; Wed, 9 Apr 2003 20:31:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A0LpJM003916 for ; Wed, 9 Apr 2003 17:21:51 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A0Lpl4003915 for ietf-openproxy-bks; Wed, 9 Apr 2003 17:21:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A0LnJM003909 for ; Wed, 9 Apr 2003 17:21:50 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3A0NtKq008626; Wed, 9 Apr 2003 18:23:55 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3A0LF303918; Wed, 9 Apr 2003 18:21:15 -0600 Date: Wed, 9 Apr 2003 18:21:15 -0600 Message-Id: <200304100021.h3A0LF303918@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: set of OPES documents Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some WG's produce a "roadmap" document that does this. However, experience shows that a large number of related drafts is a situation to be avoided wherever possible. It seems like a good idea at first, but if they need to cross-reference each other it becomes a nightmare to keep them all in sync. Years later backlash sets in. On Wed, 9 Apr 2003 at 10:43:27 -0600 (MDT) Alex Rousskov asked: > Also, given a relatively large number of related drafts, would it make > any sense to have one short "OPES Requirements" draft that lists all > available drafts and describes the relationship between them? Or do we > want to repeat pretty much the same explanations in every draft > instead? Are there similar cases in other WG? Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 10 02:55:00 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09768 for ; Thu, 10 Apr 2003 02:54:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A6emJM027692 for ; Wed, 9 Apr 2003 23:40:48 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A6emhc027691 for ietf-openproxy-bks; Wed, 9 Apr 2003 23:40:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A6elJM027682 for ; Wed, 9 Apr 2003 23:40:47 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3A6gsKq019991 for ; Thu, 10 Apr 2003 00:42:55 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3A6e9w22682; Thu, 10 Apr 2003 00:40:09 -0600 Date: Thu, 10 Apr 2003 00:40:09 -0600 Message-Id: <200304100640.h3A6e9w22682@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org Subject: Some attempts at clarification Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Recently several of us spent a couple of hours in a phone call trying to clarify some issues that have come up on the mailing list. We'd like to share our "findings", such as there are, with the hope that they will help the WG reach consensus. In some cases we were only able to clarify question or summarize what has already been discussed on the mailing list. In all cases, the final resolution will come from the discussion on this mailing list. Feel free to discuss, dispute, rebutt, defend, or embrace anything presented here. All resolutions will be by consensus of the WG on the mailing list. Hilarie ================================= Message definitions and relating messages to connections OCP has no particular requirements about how messages from the flow proxied by an OPES processor is carried or represented in OCP messages. The messages in a proxied flow can be messages from or to a data consumer and messages from or to a data provider; Alex suggested that messages from the OPES processor to either endpoint be called "application output messages" and messages from either endpoint to the OPES processor be called "application input messages". The Policy Requirements draft has four processing points identifying these message sending/receiving points (figure 2) as 1, 2, 3, and 4 (input from consumer, output to provider, input from provider, output to consumer). Would rewording to refer to these processing points, rather than naming messages, be helpful? OCP has a message type called "application message"; its purpose is to allow the callout server to send several modified messages (e.g. different versions of the same content) as its part of one callout transaction. Hilarie objected to this on the grounds of complexity, suggesting that if it is needed it could be done with application-specific metadata. The ensuing discussion yielded the assertion that OCP could not be implemented without a binding to an application protocol. One solution is for OCP be specified as a core protocol and that separate documents could be produced with the OCP-HTTP, OCP-SMTP, OCP-FTP, etc. bindings. The current draft would be called the "OCP core" protocol, with no application-specific information. The OCP-HTTP document would need attention as soon as the protocol elements are firm. There might be protocol independent services, such as mime part transformation, because mime parts can occur in several different application protocols. One solution would define a new application protocol binding for OCP, such as OCP-MIMEPARTS. Are there other solutions? OCP can be described with a layering model, and the draft might describe it as: OCP-Application-Messages OCP-Transactions OCP-Connections OCP-Transport Binding Layer 4 Transport IP Loop Shortcuts Abbie said that he wanted to allow the callout server to shortcut the loop used by OCP and send modified content directly to the intended recipient on the proxied dataflow. If proxied application protocol allows redirection, then the OPES processor can send it a redirection message that results in it communicating directly with the machine running callout services, but the callout server must then run application server code. Should these kinds of shortcuts be documented in OCP or any of our other documents, or can we just let it stand as "obvious to those versed in the state of the art"? Negotiation Capability negotiation is needed on a per transaction basis, not just on a per connection basis. Transactions with similar capability requirements can be grouped usefully onto a single connection. We need to make sure this is compatible with privacy and security requirements; we have to revisit this wrt to the requirements and what can be done with IPSec and TLS. Tracing There has been a lot of discussion of notification vis-a-vis tracing. Tracing can probably be best regarded as the proposed mechanism on which to base notification. The major objection to defining out-of-band protocols for tracing or notification is that the chance of adoption is low. However, it remains to be seen if we can develop mappings onto application protocols that satisfy all the requirements. Tracing is a requirement on an OPES processor, not the OCP protocol. An important question is whether or not the OPES processor must be aware of all the OPES services performed by a callout server. It might be, if the requirement is that the callout server perform ONLY services explicitly requested by OPES processor, or it might not. If not, it should be able to ask the callout server to include such a list as metadata on OCP Application Messages. Oskar noted that the callout server MIGHT want to include additional information that would be useful, such as parameter settings used during execution of a service. Should this additional information be specified as application-independent metadata in OCP Application Messages? Should there be a way to request that the response to a proxied message include tracing information identifying ALL OPES services applied to it (to both the response and the reply)? Given that it would be impossible to require complete disclosure of services from an entity with which you had no contractual agreement, this cannot be fully enforced, but it would be OK for cases with such an agreement. Is this sufficient to satisfy the notification requirement of the IAB? Alex notes that an advantage of having tracing data added to all messages going through an OPES processor is avoidance of any need to signal which connections or transactions or messages were subject to tracing. This is a major simplification. "Clarifiers" Alex Rousskov Abbie Barbir Oskar Batuner Reinaldo Penno Martin Stecher Hilarie Orman Markus Hofmann Marshall Rose From owner-ietf-openproxy@mail.imc.org Thu Apr 10 07:42:24 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15583 for ; Thu, 10 Apr 2003 07:42:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ABUxJM004555 for ; Thu, 10 Apr 2003 04:30:59 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3ABUxNF004554 for ietf-openproxy-bks; Thu, 10 Apr 2003 04:30:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.9/8.11.6) with SMTP id h3ABUuJM004548 for ; Thu, 10 Apr 2003 04:30:57 -0700 (PDT) Received: from hermes.webwasher.com [192.168.1.3] id UVFEVYOA; 10 Apr 2003 13:30:53 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Some attempts at clarification X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 10 Apr 2003 13:27:30 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02EF54CC1@hermes.webwasher.com> Thread-Topic: Some attempts at clarification Thread-Index: AcL/MQTtKCDrRH7ARY2XKLBsDkcFnwAIBh1g From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h3ABUwJM004551 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Message definitions and relating messages to connections > > [...] > > The ensuing discussion yielded the assertion that OCP could not be > implemented without a binding to an application protocol. One > solution is for OCP be specified as a core protocol and that separate > documents could be produced with the OCP-HTTP, OCP-SMTP, OCP-FTP, > etc. bindings. The current draft would be called the "OCP core" > protocol, with no application-specific information. The OCP-HTTP > document would need attention as soon as the protocol elements are > firm. > > There might be protocol independent services, such as mime part > transformation, because mime parts can occur in several different > application protocols. One solution would define a new application > protocol binding for OCP, such as OCP-MIMEPARTS. Are there other > solutions? > Such as OCP-MIMEPARTS I think we need something like OCP-FILE or OCP-GENERIC that is able to vector out something like a file with- out anything application protocol specific. I even think that it makes sense to define this together with the OCP core instead of a separate pseudo-application-binding. That should be able to produce maximum interoperability. As an example look at a virus scanner: While it may do a better job by understanding application protocols, the basic functionality is to find viruses in any file. Let's say the virus scanning OPES service is developped for perfect handling of HTTP and SMTP and therefore supports OCP-HTTP and OCP-SMTP. Next you get an OPES processor for FTP. The OPES service does not support OCP-FTP; still a chance that the FTP up- and downloads get checked for viruses? If every OPES processor and OPES service is encouraged to support OCP-FILE if possible at all, this could be a fallback solution if compatibility on OCP application protocol binding cannot be achieved. I believe that although there are services that cannot support OCP-GENERIC (because they filter HTTP header fields for example), most and the most interesting OPES services can support this. So, definition on a promiment place (as in the core) could be a good idea. Support cannot be made a MUST but a "SHOULD if possible". > > Negotiation > > Capability negotiation is needed on a per transaction basis, not just > on a per connection basis. Transactions with similar capability > requirements can be grouped usefully onto a single connection. We > need to make sure this is compatible with privacy and security > requirements; we have to revisit this wrt to the requirements and what > can be done with IPSec and TLS. > I agree that different transactions could require different capability negotiations. What I am missing is a good example why these kind of different trans- actions still need to be grouped within one connection and so make it necessary for OCP to renew capability negotiations in between some transactions. Couldn't the protocol be defined lighter by requireing that a new connection needs to be established if capability renegotiations needs to take place? Could somebody give an example why this is not sufficient? Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Apr 10 11:18:57 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23593 for ; Thu, 10 Apr 2003 11:18:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AF3QJM019868 for ; Thu, 10 Apr 2003 08:03:26 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AF3QoV019867 for ietf-openproxy-bks; Thu, 10 Apr 2003 08:03:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3AF3PJM019860 for ; Thu, 10 Apr 2003 08:03:25 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3AF3Qvj080119; Thu, 10 Apr 2003 09:03:26 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3AF3QAG080118; Thu, 10 Apr 2003 09:03:26 -0600 (MDT) (envelope-from rousskov) Date: Thu, 10 Apr 2003 09:03:26 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: Some attempts at clarification In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CC1@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CC1@hermes.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: On Thu, 10 Apr 2003, Martin Stecher wrote: > > There might be protocol independent services, such as mime part > > transformation, because mime parts can occur in several different > > application protocols. Protocol-independent services may be viable not just because some protocols share similar message structure and encoding (e.g., MIME) but because it is often trivial for an OPES processor to do message conversion to/from a protocol-independent form while writing one "generic" service instead of one for each application protocol is obviously attractive. > > One solution would define a new application > > protocol binding for OCP, such as OCP-MIMEPARTS. Are there other > > solutions? > > Such as OCP-MIMEPARTS I think we need something like OCP-FILE or > OCP-GENERIC that is able to vector out something like a file with- > out anything application protocol specific. Yes, this is what Hilarie calls OCP-MIMEPARTS, essentially. You get a blob of data with MIME-like encoding (and other general details) specified in the metadata. It is very generic. You cannot avoid metadata completely because you have to specify encoding/content-type (with real files, the latter can be assumed by application or guessed based on the file name extension or even file content). We should be careful with using MIME "as is" though because it implies certain payload transformations (new lines and such); HTTP had to solve this problem (HTTP payload is not strictly MIME compliant). OCP-Generic might be a better name. > I even think that it makes sense to define this together with the > OCP core instead of a separate pseudo-application-binding. That > should be able to produce maximum interoperability. I believe this is a separate question that we can answer once OCP-MIMEPARTS/Generic is documented. We can, for example, keep it as a separate document, but add a "OCP-Generic SHOULD be supported" to OCP-Core. We have to integrate only if many OCP core parts become affected. For example, HTTP caching features are a MAY; in theory, they could have been documented as a separate document, but there were too many interactions with HTTP "Core". HTTP Authentication (also a MAY), on the other hand, is a separate document because there is very little interaction. > As an example look at a virus scanner: While it may do a better job > by understanding application protocols, the basic functionality is > to find viruses in any file. Let's say the virus scanning OPES > service is developped for perfect handling of HTTP and SMTP and > therefore supports OCP-HTTP and OCP-SMTP. Next you get an OPES > processor for FTP. The OPES service does not support OCP-FTP; still > a chance that the FTP up- and downloads get checked for viruses? If > every OPES processor and OPES service is encouraged to support > OCP-FILE if possible at all, this could be a fallback solution if > compatibility on OCP application protocol binding cannot be > achieved. Agreed. > I believe that although there are services that cannot support > OCP-GENERIC (because they filter HTTP header fields for example), > most and the most interesting OPES services can support this. > So, definition on a promiment place (as in the core) could be > a good idea. Support cannot be made a MUST but a "SHOULD if > possible". Actually, virtually _any_ service can support OCP-Generic. It is all a question of the amount/kind of pre- and post-processing work done at the OPES processor. In your example (HTTP headers adaptation), OPES processor may pass just the headers as application data and then re-assemble the message once the adapted headers come back from the callout server. There are two primary settings that need to be negotiated (auto/dynamically or statically via configuration files) between an OPES processor and a callout service: - how the data is encoded (raw/unknown, chunked, UTF-8, ...) - what that data represents (SMTP payload, HTTP headers, ...) The OCP-Generic specification should be flexible enough to "support" a variety of common combinations without hindering interoperability between and specific pair of OCP agents. One agent (processor or server) would most likely have to do the legwork of converting "anything" to "generic". OPES processor is probably the best candidate to do that. Finding an elegant scheme to support the above is one of the biggest challenges ahead of us. > > Negotiation > > > > Capability negotiation is needed on a per transaction basis, not just > > on a per connection basis. Transactions with similar capability > > requirements can be grouped usefully onto a single connection. We > > need to make sure this is compatible with privacy and security > > requirements; we have to revisit this wrt to the requirements and what > > can be done with IPSec and TLS. > > I agree that different transactions could require different > capability negotiations. What I am missing is a good example why > these kind of different trans- actions still need to be grouped > within one connection and so make it necessary for OCP to renew > capability negotiations in between some transactions. Couldn't the > protocol be defined lighter by requireing that a new connection > needs to be established if capability renegotiations needs to take > place? Could somebody give an example why this is not sufficient? Right now the OCP core is light enough to open/close OCP connections (not transport connections!) without much overhead. However, the OCP Core specification lacks any details regarding transport-level negotiations such as transport encryption. What I suspect may happen is that the "OCP connection" entity from the OCP requirements draft will be split into two entities: - OCP connection (responsible for expensive, mostly transport-level negotiations and state) - OCP session (responsible for light-weight, mostly service-level negotiations and state) It is also possible that OCP sessions could be nested so that you do not have to renegotiate from scratch. Some may argue that OCP transactions should be used to override OCP session state and that sessions must not be nested. I think we should discuss this issue once people review the next OCP Core version (to be posted shortly). It may be time to bring transport binding into the picture. The above will depend, in part, on OCP transport binding(s?). Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 10 12:04:47 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25041 for ; Thu, 10 Apr 2003 12:04:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AFc3JM022809 for ; Thu, 10 Apr 2003 08:38:03 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AFc2UO022808 for ietf-openproxy-bks; Thu, 10 Apr 2003 08:38:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3AFc1JM022804 for ; Thu, 10 Apr 2003 08:38:01 -0700 (PDT) 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 h3AFbn519371; Thu, 10 Apr 2003 11:37:50 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Apr 2003 11:37:50 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754056BE63F@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Tracing Draft version-0004082003 Date: Thu, 10 Apr 2003 11:37:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF77.24300796" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FF77.24300796 Content-Type: text/plain ALex, thanks We will fix and resubmit abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, April 09, 2003 2:17 AM > To: ietf-openproxy@imc.org > Subject: Re: Tracing Draft version-0004082003 > > > > On Tue, 8 Apr 2003, Abbie Barbir wrote: > > > Attached is the -00 version of the tracing draft. > > Please keep in mind it is work in progress. > > Feedback is required. > > Abbie, > > This is a great start, especially given a very short > time you had to write this first version of the draft! > Specific comments are inlined. I did not review the overall > structure of the draft because I think it is premature to do > that (need more "meat" and it is not yet clear whether some > of the current sections are going to stay). > > > N.B. Pease format using 72 character line length if possible -- it > makes it easier (for some of us) to quote and comment. > Thank you. > > > > OPES tracing facility > > How about just "OPES Tracing"? Does "Facility" mean something > specific? Will there be other (non "facility") OPES tracing drafts? > > > draft-ietf-opes-tracing > > > > 1. Introduction > > > > The Open Pluggable Edge Services (OPES) architecture enables > > cooperative application services (OPES services) between a data > > provider, a data consumer, and zero or more OPES processors. The > > application services under consideration analyze and possibly > > transform application-level messages exchanged between the data > > provider and the data consumer. > > > > The execution of such services is governed by a set of > rules installed > > on the OPES processor. The rules enforcement can trigger the > > execution of service applications local to the OPES processor. > > > > Alternatively, the OPES processor can distribute the > responsibility of > > service execution by communicating and collaborating with > one or more > > remote callout servers. As described in [], an OPES processor > > communicates with and invokes services on a callout server > by using a > > callout protocol. > > > > In [], the IAB has required the OPES working group to > support tracing > > and notification. This document addresses these IAB requirements. > > IAB (RFC 3238) does not require support of anything. It lists > considerations that the WG should _address_: > > "The purpose of this document is not to recommend specific > solutions > for OPES, or even to mandate specific functional requirements.... > Instead, these are recommendations on issues > that any OPES solutions standardized in the IETF should be required > to address, similar to the "Security Considerations" currently > required in IETF documents [RFC2316]. As an example, one way to > address security issues is to show that appropriate security > mechanisms have been provided in the protocol, and another way to > address security issues is to demonstrate that no security issues > apply to this particular protocol. > > There is a huge difference between "requiring support" and > enumerating "issues that OPES solutions should be required to > address". Let's not shoot ourselves in the foot. :-) > > Also, RFC 3238 does not contain the word "trace" or > "tracing", just "notification". > > I would suggest saying something like this: > > IAB has required OPES solutions to address end user and > content provider notification concerns. This document > specifies tracing mechanisms that address those concerns. > > It would be nice to explain somewhere why we are not calling > this document OPES Notification [Facility]. > > > The document examines the effect of tracing and notification > > requirements on OPES architecture and callout protocol []. In > > particular, the work identifies traceable entities in an > OPES flow and > > how this information is relayed to end points. > > what information? > > > As per the architecture document [], there is a requirement of > > relaying tracing information in-band. The document investigate this > > possibility and discusses possible methods that could be used to > > detect faulty OPES processors by end points on an OPES flow. > > What about faulty callout servers? Do we have a term that > describes OPES system (processor + callout servers + whatever > else is out there that is OPES-related)? > > > The document is organized as follows: Section 2 considers ? > Section 3? > > etc. > > > > > > 2. Basic Definitions > > > > - REFERENCE POINT - a reference that may be used out-of-band to > > perform a specific function. > > > > An example may be URI for the privacy policy, center of authority > > URI, server address, etc. Usually no protocol is provided to > > access the reference point. > > > > - INFORMATION POINT - implies presence of the protocol to access > > detailed information at this point. Example may be URI to get > > a certificate for virus checker or content filter, examine > > and set profile setting and active preferences. > > > > - IDENTIFIER - provides a unique binding to detailed persistent > > information. For example "transformation-applied : fe123" gives a > > participant ability to enquire (and maybe cache) details of the > > transformation fe123. Use of such (opaque) identifiers does not > > require prior knowledge and does not create a burden of storing > > additional information - this is just a tag for persistent > > information (not message-specific). > > The above classification seems like a result of protocol > over-engineering to me. Would it be possible to avoid > introducing any classifications/terms until the draft starts > actually _using_ them for a specific purpose? This will save > us a lot of time -- there is no reason (and it is very > difficult) to discuss something that is not used (yet). > > > > 3. Requirements for Notification in an OPES Flow > > > > > > This section takes a look at the IAB requirements (3.1) and > (3.2) and > > how they relate to notification > > > > 3.1 Notification Requirements > > > > There are requirements on the architecture [] to assist content > > provider applications in detecting and responding to data consumer > > applications actions by OPES intermediaries that are deemed > > inappropriate by the content provider. This is referred to as > > notification. > > > > In general, notification goes in opposite direction of tracing and > > cannot be attached to application messages that it notifies about. > > If we compare notification with tracing like that, we should > talk about/define tracing first and only then provide a comparison. > > An "opposite direction" illustration (figure) would be nice here! > > > This can be done > > "This has to be done" ? > > > out-band and may require the development of a new protocol. In > > general, this opposite-direction, outside-of-message scheme is > > difficult to support. > > What does it mean "difficult to support"? Consider removing > that sentence. (it's OK in a conversation, but not in a spec) > This text is of great importance because we are, essentially, > saying that the "ideal" scheme that IAB folks envisioned is > not practical. We need to be as specific as possible here. > > > NOTE: When would a content provider issue such request? > > What request? > > > How would such > > mechanism be used? Randomly, or on a statistical basis? > Or manually? > > Is such a scheme of practical relevance? > > In the above, there is no definition of the "mechanism" > detailed enough to answer these questions. > > > > 3.1.1 Notification Concerns > > > > A major concern with notification is scalability. For > example, it is > > not practical to assume that a content provider is interested in > > receiving a notification for every HTTP response sent out. > As such, a > > mechanism for explicit request of notification May be required. > > Why is it not practical?! Some content providers would love > to know exactly what their clients are doing with their > content. They would be willing to double server capacity to > handle the load. > > "Not scalable" usually implies non-linear (hopefully > exponential) growth with the number of messages or > notification-generation points. You need to show such growth > (or something similar) if you want to play the scalability > card. What does not scale and when? > > > Privacy is another concern. Maybe a user doesn't want to > reveal to any > > content provider all the OPES services that have been > applied on her > > behalf. For example, why should every content provider know > what exact > > virus scanner a user is using? > > Consider rephrasing to something like this: > > End point privacy is a concern. An end user may consider > information > about OPES services applied on her behalf as private. > For example, if > translation for braille device has been applied, it can > be concluded > that the user is having eyesight problems; such information may be > misused if the user is applying for a job online. > Similarly, a content > provider may consider information about its OPES services private. > For example, use of a specific OPES intermediary by a high traffic > volume site may indicate business alliances that have not > been publicly > announced yet. > > Also consider adding something like this: > > Security is a concern. An attacker may benefit from knowledge > of internal OPES services layout, execution order, software > versions and other information likely to be present in > automated notifications. > > Also consider adding something like this: > > The level of available details in notifications versus content > provider interest in supporting notification is a > concern. Experience > shows that content providers often require very detailed > information > about user actions to be interested in notifications at all. For > example, Hit Metering protocol (RFC XXX) has been > designed to supply > content providers with proxy cache hit counts, in an > effort to reduce > cache busting behavior which was cause by content > providers desire to > get accurate site "access counts". The Hit Metering > protocol is not > widely deployed today because it turns out that content > providers are > not interested enough in "just hit counts"; only knowing > things like > each client IP addresses, browser versions, or cookies would make > providers interested enough to support cache hit > notifications. Hit > Metering experience is very relevant because Hit Metering > protocol was > designed to do for HTTP caching intermediaries what OPES > notifications > are meant to do for OPES intermediaries. > > (We would need to verify the above info with Hit Metering > authors, but to the best of my knowledge it is correct) > > > 3.2 How to Fulfill Notifications Requirements > > > > IAB consideration (3.1) [] suggests that the overall OPES framework > > needs to assist content providers in detecting and responding to > > client-centric actions by OPES intermediaries that are deemed > > inappropriate by the content provider. > > > > This requirement is hard to implement since most client-centric > > actions happen > > What do we mean by "implement"? Write a spec? Code it up? > Deploy? Other? Consider rephrasing to something like: > > To address this requirement directly, one would have to ... > > and then finish with a statement that we are addressing it > indirectly by providing tracing mechanisms that assist > interested providers in detecting and responding to > inappropriate OPES actions. Say how they assist (you already > do the latter now, below). > > > _after_ the application message left the content provider(s) and, > > thus, notifications cannot be piggy-backed to application > messages and > > have to travel in the opposite direction of traces. > > > > Note: Need to explain more here. > > > IAB consideration (3.2) [] can be satisfied by the development of a > > tracing facility. In this regard, it is recommended that tracing > > SHOULD be always-on, just like HTTP Via headers now. This should > > eliminate notification as a separate requirement. > > Why not MUST be always-on? We are talking about > interoperability here (a broken intermediary that does not > use Via-OPES headers is an interoperability problem because > it cannot be bypassed). > > > If the OPES end points cooperate then notification can be > supported by > > tracing. It is recommended that content providers that suspect or > > experience difficulties do the following: > > Recommended is too strong, IMO. "For example, ..." or > "providers could ...", would be more appropriate. > > > 1. Check whether requests they receive pass through > > OPES intermediaries. Presence of OPES tracing info > > will determine that. This check is only possible for > > request/response protocols. For other protocols (e.g., > > broadcast or push), the provider would have to assume > > that OPES intermediaries are involved until proven > > otherwise. > > > > 2. If OPES intermediaries are suspected, > > request OPES traces from potentially affected user(s). > > The trace will be a part of the application message > > received by the user software. If users cooperate, > > the provider(s) have all the information they need. > > If users do not cooperate, the provider(s) cannot > > do much about it (they might be able to deny service > > to uncooperative users in some cases). > > > > 3. Some traces may indicate that more information > > is available by accessing certain resources on the > > specified OPES intermediary or elsewhere. Content > > providers may query for more information in that > > case. > > > > 4. If everything else fails, providers can enforce > > no-adaptation policy using appropriate OPES > > bypass mechanisms and/or end-to-end mechanisms. > > > > > > > > > > 4. Requirements for Tracing in an OPES Flow > > > > > > In [], the IAB has required that the OPES architecture > provide tracing > > and debugging facilities. From [], the OPES architecture > SHOULD assist > > consumer application in detecting the behavior of OPES > processors and > > callout servers to potentially allow them to identify imperfect or > > compromised operations. > > > > The OPES architecture document [] has addressed these concerns at a > > higher level. The architecture requires that tracing be feasible on > > the OPES flow per OPES processor using in-band annotation. This > > requirement provides a participant with the ability to detect OPES > > intermediaries in the course of normal interaction. > > > > 4.1 What is traceable? > > > > End OPES points must be able to trace the following: > > Consider more accurate "The following entities can be > identified in a trace" > > > 1. OPES processors that are involved. > > 2. OPES services (including callout services) that were > performed on a > > request or response. > > "... performed on an application message" > > > 3. TBD > > Also, we need to add MUST/SHOULD/MAY to each traceable > entity, I guess. > > > > > 4.2 Tracing and Trust Domains > > > > Tracing is limited to trust domain. Entities outside of that domain > > may or may not see any traces, depending on domain policies or > > configuration. Therefore, there is no need for mandatory end-to-end > > tracing facility. For example, if an OPES system is on the content > > provider "side", end-users are not guaranteed any traces. > If an OPES > > system is working inside end-user domain, the origin server is not > > guaranteed any traces related to user requests. > > I am not sure about the above. It contradicts our statement > that we are addressing IAB concerns. If there is no trace, we > are not. I think it is reasonable to say that there MUST be > at least one trace entry per "system". (A trust domain may > include several such systems/entities, see the trust domain > definition). > > > There are two distinct uses of traces. First, is to SHOULD > enable the > > "end (content producer or consumer) to detect OPES > processor presence > > within end's trust domain. Such "end" should be able to see a trace > > entry, but does not need to be able to interpret it beyond > > identification of the trust domain(s). > > > Second, the domain administrator SHOULD be able to take a > trace entry > > (possibly supplied by an "end? as an opaque string) and > interpret it. > > The administrator must be able to identify OPES > processor(s) involved > > and may be able to identify applied adaptation services along with > > other message-specific information. That information SHOULD help to > > explain what OPES agent(s) were involved and what they did. > It may be > > impractical to provide all the required information in all > cases. This > > document view a trace record as a hint, as opposed to an exhaustive > > audit. > > > > Since the administrators of various trust domains can have various > > ways of looking into tracing, they MAY require the choice > of freedom > > in what to put in trace records and how to format them. > Trace records > > should be easy to extend beyond basic OPES requirements. Trace > > management algorithms should treat trace records as opaque > data to the > > extent possible. > > > It is not expected that entities in one trust domain to be > able to get > > all OPES-related feedback from entities in other trust domains. For > > example, if an end-user suspects that a served is corrupted by a > > callout service, there is no guarantee that the use will be able to > > identify that service, contact its owner, or debug it _unless_ the > > service is within my trust domain. This is no different from the > > current situation where it is impossible, in general, to know the > > contact person for an application on an origin server that > generates > > corrupted HTML; and even if the person is known, one should > not expect > > that person to respond to end-user queries. > > The above should have "system" granularity, not "domain" > granularity because there can be different privacy policies > within one trust domain. > > > 4.3 In-Band Tracing > > > > The architecture [] states that races must be in-band. This > > requirement limits the number of application protocols that > OPES can > > adapt and the amount of details a trace record can convey. > > > > The set of protocols that can support tracing for OPES Flow must be > > clearly documented. The architecture does not prevent > implementers of > > developing out-of-band protocols and techniques to address > the above > > limitation. > > We should not (cannot) document the set of supported > protocols directly, IMO. We should document _requirements_ > for application protocols that want to support OPES traces. > This is similar to OCP application bindings. > > > 4.3.1 Tracing information granularity and persistence levels > > > > The information may be: > > > > - message-related, e.g. "virus checking done - passed", "content > > filtering applied", "translated from quibbish to danqush". Such > > information should be supplied with each message and indicate that > > specific action was taken. All data that describes specific actions > > performed for the message should be provided with that message, as > > there is no other way to find message level details later. OPES > > application (including OPES processor and all application > modules and > > callout servers involved) is not supposed to keep volatile > information > > after request processing is done. > > > > - session related. > > TBD > > > > Session level data must be preserved for the duration of > the session. > > OPES processor is responsible for inserting notifications if > > session-level information changes. > > > > Examples of session-related information is "virus checker > abcd build > > 123 enabled", "OPES server id=xyz present". > > > > - log information id. This may be used e.g. for accounting and > > non-repudiation purposes. Detailed information referenced > by this id > > may be not available online but can be retrieved later by some > > off-line procedure. > > > > - server related persistent information, e.g. "OPES center of > > authority ", "privacy policy ". It may be also presented > > once per session and it does not change between sessions. > > > > - end-point related data: what profile is activated (profile ID), > > where to get profile details, where to set preferences. I'm > not sure > > how far we should go in this direction. > > The above classification seems like a result of protocol > over-engineering to me. Would it be possible to avoid > introducing any classifications/terms until the draft starts > actually _using_ them for a specific purpose? This will save > us a lot of time -- there is no reason (and it is very > difficult) to discuss something that is not used (yet). > > > 4.4 OCP Support for Tracing > > > > It is the task of an OPES processor to add trace records to > > application messages. In this case, OCP protocol is not affected by > > tracing requirements for the following reasons: > > Either say "If it is the task..." or remove "In this case, " :-) > > > a) Exclusive assignment simplifies the protocol. > > > > b) There are use cases where callout services adapt payload > regardless > > of the application protocol in use and leave header > adjustment to OPES > > processor or other services. For example, think of a generic text > > translation or image modification service; such services require > > payload encoding knowledge but can be > application-independent if OPES > > processor can supply them with just the payload. > > > > c) OPES processor is always _able_ to trace its own invocation and > > service(s) execution because OPES processor must understand the > > application protocol. Assigning these tracing tasks to > callout servers > > is just an optimization in cases where callout servers manipulate > > application message headers. > > > > d) May not be able to trace all services that are done at > the callout > > server. > > > > e) It makes OPES compliance checks easier when remote third party > > callout servers are used. > > > > f) Servers or services MAY add their own OPES trace records, of > > course. > > I wonder if it is appropriate for the draft to explain the > motivation behind a decision, at such lengths? Should we just > state requirements instead? > > > > > 4.5 Protocol Binding to Tracing > > > > How tracing is added is application protocol-specific and will be > > documented in separate drafts. This work documents what tracing > > information is required and some common tracing elements. > > > > 5. Security Considerations > > > > I would suggest adding rules from the message below (or > something similar). They are very specific things we can > discuss/fix/polish, and they actually shape the > conventions/intent of many tracing draft sections. The draft > should be mostly about specific requirements, not our > motivation or reasoning about what we might do and what > design alternatives we have available. > http://www.imc.org/ietf-openproxy/mail-archive/msg01875.html > Please note that I am not saying the above rules are perfect! > I am just saying we need more specific "bones" to grow the > draft "meat" around, or we will never exit the jelly state. > > Thank you, > > Alex. > > ------_=_NextPart_001_01C2FF77.24300796 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Tracing Draft version-0004082003

ALex,

thanks
We will fix and resubmit

abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Wednesday, April 09, 2003 2:17 AM
> To: ietf-openproxy@imc.org
> Subject: Re: Tracing Draft = version-0004082003
>
>
>
> On Tue, 8 Apr 2003, Abbie Barbir wrote:
>
> > Attached is the -00 version of the tracing = draft.
> > Please keep in mind it is work in = progress.
> > Feedback is required.
>
> Abbie,
>
>       This is a great = start, especially given a very short
> time you had to write this first version of the = draft!
> Specific comments are inlined. I did not review = the overall
> structure of the draft because I think it is = premature to do
> that (need more "meat" and it is not = yet clear whether some
> of the current sections are going to = stay).
>
>
>   N.B. Pease format using 72 = character line length if possible -- it
>        makes = it easier (for some of us) to quote and comment.
> Thank you.
>
>
> = >           &n= bsp;           OPES = tracing facility
>
> How about just "OPES Tracing"? Does = "Facility" mean something
> specific? Will there be other (non = "facility") OPES tracing drafts?
>
> = >           &n= bsp;           = draft-ietf-opes-tracing
> >
> > 1. Introduction
> >
> > The Open Pluggable Edge Services (OPES) = architecture enables
> > cooperative application services (OPES = services) between a data
> > provider, a data consumer, and zero or = more OPES processors.  The
> > application services under consideration = analyze and possibly
> > transform application-level messages = exchanged between the data
> > provider and the data consumer.
> >
> > The execution of such services is governed = by a set of
> rules installed
> > on the OPES processor.  The rules = enforcement can trigger the
> > execution of service applications local to = the OPES processor.
> >
> > Alternatively, the OPES processor can = distribute the
> responsibility of
> > service execution by communicating and = collaborating with
> one or more
> > remote callout servers. As described in = [], an OPES processor
> > communicates with and invokes services on = a callout server
> by using a
> > callout protocol.
> >
> > In [], the IAB has required the OPES = working group to
> support tracing
> > and notification. This document addresses = these IAB requirements.
>
> IAB (RFC 3238) does not require support of = anything. It lists
> considerations that the WG should = _address_:
>
>    "The purpose of this = document is not to recommend specific
> solutions
>    for OPES, or even to mandate = specific functional requirements....
>    Instead, these are = recommendations on issues
>    that any OPES solutions = standardized in the IETF should be required
>    to address, similar to the = "Security Considerations" currently
>    required in IETF documents = [RFC2316].  As an example, one way to
>    address security issues is to = show that appropriate security
>    mechanisms have been provided = in the protocol, and another way to
>    address security issues is to = demonstrate that no security issues
>    apply to this particular = protocol.
>
> There is a huge difference between = "requiring support" and
> enumerating "issues that OPES solutions = should be required to
> address". Let's not shoot ourselves in the = foot. :-)
>
> Also, RFC 3238 does not contain the word = "trace" or
> "tracing", just = "notification".
>
> I would suggest saying something like = this:
>
>     IAB has required OPES = solutions to address end user and
>     content provider = notification concerns. This document
>     specifies tracing = mechanisms that address those concerns.
>
> It would be nice to explain somewhere why we = are not calling
> this document OPES Notification = [Facility].
>
> > The document examines the effect of = tracing and notification
> > requirements on OPES architecture and = callout protocol []. In
> > particular, the work identifies traceable = entities in an
> OPES flow and
> > how this information is relayed to end = points.
>
> what information?
>
> > As per the architecture document [], there = is a requirement of
> > relaying tracing information in-band. The = document investigate this
> > possibility and discusses possible methods = that could be used to
> > detect faulty OPES processors by end = points on an OPES flow.
>
> What about faulty callout servers? Do we have a = term that
> describes OPES system (processor + callout = servers + whatever
> else is out there that is OPES-related)?
>
> > The document is organized as follows: = Section 2 considers ?
> Section 3?
> > etc.
> >
> >
> > 2. Basic Definitions
> >
> > - REFERENCE POINT - a reference that may = be used out-of-band to
> >   perform a specific = function.
> >
> >   An example may be URI for the = privacy policy, center of authority
> >   URI, server address, etc. = Usually no protocol is provided to
> >   access the reference = point.
> >
> > - INFORMATION POINT - implies presence of = the protocol to access
> >   detailed information at this = point. Example may be URI to get
> >   a certificate for virus = checker or content filter, examine
> >   and set profile setting and = active preferences.
> >
> > - IDENTIFIER - provides a unique binding = to detailed persistent
> >   information. For example = "transformation-applied : fe123" gives a
> >   participant ability to enquire = (and maybe cache) details of the
> >   transformation fe123. Use of = such (opaque) identifiers does not
> >   require prior knowledge and = does not create a burden of storing
> >   additional information - this = is just a tag for persistent
> >   information (not = message-specific).
>
> The above classification seems like a result of = protocol
> over-engineering to me. Would it be possible to = avoid
> introducing any classifications/terms until the = draft starts
> actually _using_ them for a specific = purpose?  This will save
> us a lot of time -- there is no reason (and it = is very
> difficult) to discuss something that is not = used (yet).
>
>
> > 3. Requirements for Notification in an = OPES Flow
> >
> >
> > This section takes a look at the IAB = requirements (3.1) and
> (3.2) and
> > how they relate to notification
> >
> > 3.1 Notification Requirements
> >
> > There are requirements on the architecture = [] to assist content
> > provider applications in detecting and = responding to data consumer
> > applications actions by OPES = intermediaries that are deemed
> > inappropriate by the content provider. = This is referred to as
> > notification.
> >
> > In general, notification goes in opposite = direction of tracing and
> > cannot be attached to application messages = that it notifies about.
>
> If we compare notification with tracing like = that, we should
> talk about/define tracing first and only then = provide a comparison.
>
> An "opposite direction" illustration = (figure) would be nice here!
>
> > This can be done
>
> "This has to be done" ?
>
> > out-band and may require the development = of a new protocol. In
> > general, this opposite-direction, = outside-of-message scheme is
> > difficult to support.
>
> What does it mean "difficult to = support"? Consider removing
> that sentence. (it's OK in a conversation, but = not in a spec)
> This text is of great importance because we = are, essentially,
> saying that the "ideal" scheme that = IAB folks envisioned is
> not practical. We need to be as specific as = possible here.
>
> > NOTE: When would a content provider issue = such request?
>
> What request?
>
> > How would such
> > mechanism be used?  Randomly, or on a = statistical basis? 
> Or manually?
> > Is such a scheme of practical = relevance?
>
> In the above, there is no definition of the = "mechanism"
> detailed enough to answer these = questions.
>
>
> > 3.1.1 Notification Concerns
> >
> > A major concern with notification is = scalability. For
> example, it is
> > not practical to assume that a content = provider is interested in
> > receiving a notification for every HTTP = response sent out.
> As such, a
> > mechanism for explicit request of = notification May be required.
>
> Why is it not practical?! Some content = providers would love
> to know exactly what their clients are doing = with their
> content. They would be willing to double server = capacity to
> handle the load.
>
> "Not scalable" usually implies = non-linear (hopefully
> exponential) growth with the number of messages = or
> notification-generation points. You need to = show such growth
> (or something similar) if you want to play the = scalability
> card. What does not scale and when?
>
> > Privacy is another concern. Maybe a user = doesn't want to
> reveal to any
> > content provider all the OPES services = that have been
> applied on her
> > behalf. For example, why should every = content provider know
> what exact
> > virus scanner a user is using?
>
> Consider rephrasing to something like = this:
>
>     End point privacy is a = concern. An end user may consider
> information
>     about OPES services = applied on her behalf as private. 
> For example, if
>     translation for braille = device has been applied, it can
> be concluded
>     that the user is having = eyesight problems; such information may be
>     misused if the user is = applying for a job online.
> Similarly, a content
>     provider may consider = information about its OPES services private.
>     For example, use of a = specific OPES intermediary by a high traffic
>     volume site may = indicate business alliances that have not
> been publicly
>     announced yet.
>
> Also consider adding something like = this:
>
>     Security is a concern. = An attacker may benefit from knowledge
>     of internal OPES = services layout, execution order, software
>     versions and other = information likely to be present in
>     automated = notifications.
>
> Also consider adding something like = this:
>
>     The level of available = details in notifications versus content
>     provider interest in = supporting notification is a
> concern.  Experience
>     shows that content = providers often require very detailed
> information
>     about user actions to = be interested in notifications at all. For
>     example, Hit Metering = protocol (RFC XXX) has been
> designed to supply
>     content providers with = proxy cache hit counts, in an
> effort to reduce
>     cache busting behavior = which was cause by content
> providers desire to
>     get accurate site = "access counts". The Hit Metering
> protocol is not
>     widely deployed today = because it turns out that content
> providers are
>     not interested enough = in "just hit counts"; only knowing
> things like
>     each client IP = addresses, browser versions, or cookies would make
>     providers interested = enough to support cache hit
> notifications.  Hit
>     Metering experience is = very relevant because Hit Metering
> protocol was
>     designed to do for HTTP = caching intermediaries what OPES
> notifications
>     are meant to do for = OPES intermediaries.
>
>     (We would need to = verify the above info with Hit Metering
>     authors, but to the = best of my knowledge it is correct)
>
> > 3.2 How to Fulfill Notifications = Requirements
> >
> > IAB consideration (3.1) [] suggests that = the overall OPES framework
> > needs to assist content providers in = detecting and responding to
> > client-centric actions by OPES = intermediaries that are deemed
> > inappropriate by the content = provider.
> >
> > This requirement is hard to implement = since most client-centric
> > actions happen
>
> What do we mean by "implement"? Write = a spec? Code it up?
> Deploy? Other? Consider rephrasing to something = like:
>
>     To address this = requirement directly, one would have to ...
>
> and then finish with a statement that we are = addressing it
> indirectly by providing tracing mechanisms that = assist
> interested providers in detecting and = responding to
> inappropriate OPES actions. Say how they assist = (you already
> do the latter now, below).
>
> > _after_ the application message left the = content provider(s) and,
> > thus, notifications cannot be piggy-backed = to application
> messages and
> > have to travel in the opposite direction = of traces.
> >
> > Note: Need to explain more here.
>
> > IAB consideration (3.2) [] can be = satisfied by the development of a
> > tracing facility. In this regard, it is = recommended that tracing
> > SHOULD be always-on, just like HTTP Via = headers now. This should
> > eliminate notification as a separate = requirement.
>
> Why not MUST be always-on? We are talking about =
> interoperability here (a broken intermediary = that does not
> use Via-OPES headers is an interoperability = problem because
> it cannot be bypassed).
>
> > If the OPES end points cooperate then = notification can be
> supported by
> > tracing. It is recommended that content = providers that suspect or
> > experience difficulties do the = following:
>
> Recommended is too strong, IMO. "For = example, ..." or
> "providers could ...", would be more = appropriate.
>
> >     1. Check whether = requests they receive pass through
> >       OPES = intermediaries. Presence of OPES tracing info
> >       will determine = that. This check is only possible for
> >       request/response = protocols. For other protocols (e.g.,
> >       broadcast or = push), the provider would have to assume
> >       that OPES = intermediaries are involved until proven
> >       = otherwise.
> >
> >     2. If OPES = intermediaries are suspected,
> >       request OPES = traces from potentially affected user(s).
> >       The trace will = be a part of the application message
> >       received by the = user software. If users cooperate,
> >       the provider(s) = have all the information they need.
> >       If users do not = cooperate, the provider(s) cannot
> >       do much about it = (they might be able to deny service
> >       to uncooperative = users in some cases).
> >
> >     3. Some traces may = indicate that more information
> >       is available by = accessing certain resources on the
> >       specified OPES = intermediary or elsewhere. Content
> >       providers may = query for more information in that
> >       case.
> >
> >     4. If everything else = fails, providers can enforce
> >        = no-adaptation policy using appropriate OPES
> >        bypass = mechanisms and/or end-to-end mechanisms.
> >
> >
> >
> >
> > 4. Requirements for Tracing in an OPES = Flow
> >
> >
> > In [], the IAB has required that the OPES = architecture
> provide tracing
> > and debugging facilities. From [], the = OPES architecture
> SHOULD assist
> > consumer application in detecting the = behavior of OPES
> processors and
> > callout servers to potentially allow them = to identify imperfect or
> > compromised operations.
> >
> > The OPES architecture document [] has = addressed these concerns at a
> > higher level. The architecture requires = that tracing be feasible on
> > the OPES flow per OPES processor using = in-band annotation. This
> > requirement provides a participant with = the ability to detect OPES
> > intermediaries in the course of normal = interaction.
> >
> > 4.1 What is traceable?
> >
> > End OPES points must be able to trace the = following:
>
> Consider more accurate "The following = entities can be
> identified in a trace"
>
> > 1. OPES processors that are = involved.
> > 2. OPES services (including callout = services) that were
> performed on a
> > request or response.
>
> "... performed on an application = message"
>
> > 3. TBD
>
> Also, we need to add MUST/SHOULD/MAY to each = traceable
> entity, I guess.
>
> >
> > 4.2 Tracing and Trust Domains
> >
> > Tracing is limited to trust domain. = Entities outside of that domain
> > may or may not see any traces, depending = on domain policies or
> > configuration. Therefore, there is no need = for mandatory end-to-end
> > tracing facility. For example, if an OPES = system is on the content
> > provider "side", end-users are = not guaranteed any traces.
> If an OPES
> > system is working inside end-user domain, = the origin server is not
> > guaranteed any traces related to user = requests.
>
> I am not sure about the above. It contradicts = our statement
> that we are addressing IAB concerns. If there = is no trace, we
> are not.  I think it is reasonable to say = that there MUST be
> at least one trace entry per = "system". (A trust domain may
> include several such systems/entities, see the = trust domain
> definition).
>
> > There are two distinct uses of traces. = First, is to SHOULD
> enable the
> > "end (content producer or consumer) = to detect OPES
> processor presence
> > within end's trust domain. Such = "end" should be able to see a trace
> > entry, but does not need to be able to = interpret it beyond
> > identification of the trust = domain(s).
>
> > Second, the domain administrator SHOULD be = able to take a
> trace entry
> > (possibly supplied by an "end? as an = opaque string) and
> interpret it.
> > The administrator must be able to identify = OPES
> processor(s) involved
> > and may be able to identify applied = adaptation services along with
> > other message-specific information. That = information SHOULD help to
> > explain what OPES agent(s) were involved = and what they did.
> It may be
> > impractical to provide all the required = information in all
> cases. This
> > document view a trace record as a hint, as = opposed to an exhaustive
> > audit.
> >
> > Since the administrators of various trust = domains can have various
> > ways of looking into tracing, they MAY = require the choice
> of freedom
> > in what to put in trace records and how to = format them.
> Trace records
> > should be easy to extend beyond basic OPES = requirements. Trace
> > management algorithms should treat trace = records as opaque
> data to the
> > extent possible.
>
> > It is not expected that entities in one = trust domain to be
> able to get
> > all OPES-related feedback from entities in = other trust domains. For
> > example, if an end-user suspects that a = served is corrupted by a
> > callout service, there is no guarantee = that the use will be able to
> > identify that service, contact its owner, = or debug it _unless_ the
> > service is within my trust domain. This is = no different from the
> > current situation where it is impossible, = in general, to know the
> > contact person for an application on an = origin server that
> generates
> > corrupted HTML; and even if the person is = known, one should
> not expect
> > that person to respond to end-user = queries.
>
> The above should have "system" = granularity, not "domain"
> granularity because there can be different = privacy policies
> within one trust domain.
>
> > 4.3 In-Band Tracing
> >
> > The architecture [] states that races must = be in-band. This
> > requirement limits the number of = application protocols that
> OPES can
> > adapt and the amount of details a trace = record can convey.
> >
> > The set of protocols that can support = tracing for OPES Flow must be
> > clearly documented. The architecture does = not prevent
> implementers of
> > developing out-of-band protocols and = techniques to address
> the above
> > limitation.
>
> We should not (cannot) document the set of = supported
> protocols directly, IMO. We should document = _requirements_
> for application protocols that want to support = OPES traces.
> This is similar to OCP application = bindings.
>
> > 4.3.1 Tracing information granularity and = persistence levels
> >
> > The information may be:
> >
> > - message-related, e.g. "virus checkin= g done - passed", "content
> > filtering applied", "translated = from quibbish to danqush". Such
> > information should be supplied with each = message and indicate that
> > specific action was taken. All data that = describes specific actions
> > performed for the message should be = provided with that message, as
> > there is no other way to find message = level details later. OPES
> > application (including OPES processor and = all application
> modules and
> > callout servers involved) is not supposed = to keep volatile
> information
> > after request processing is done.
> >
> > - session related.
> > TBD
> >
> > Session level data must be preserved for = the duration of
> the session.
> > OPES processor is responsible for = inserting notifications if
> > session-level information changes.
> >
> > Examples of session-related information is = "virus checker
> abcd build
> > 123 enabled", "OPES server = id=3Dxyz present".
> >
> > - log information id. This may be used = e.g. for accounting and
> > non-repudiation purposes. Detailed = information referenced
> by this id
> > may be not available online but can be = retrieved later by some
> > off-line procedure.
> >
> > - server related persistent information, = e.g. "OPES center of
> > authority <URI>", "privacy = policy <URI>". It may be also presented
> > once per session and it does not change = between sessions.
> >
> > - end-point related data: what profile is = activated (profile ID),
> > where to get profile details, where to set = preferences. I'm
> not sure
> > how far we should go in this = direction.
>
> The above classification seems like a result of = protocol
> over-engineering to me. Would it be possible to = avoid
> introducing any classifications/terms until the = draft starts
> actually _using_ them for a specific = purpose?  This will save
> us a lot of time -- there is no reason (and it = is very
> difficult) to discuss something that is not = used (yet).
>
> > 4.4 OCP Support for Tracing
> >
> > It is the task of an OPES processor to add = trace records to
> > application messages. In this case, OCP = protocol is not affected by
> > tracing requirements for the following = reasons:
>
> Either say "If it is the task..." or = remove "In this case, " :-)
>
> > a) Exclusive assignment simplifies the = protocol.
> >
> > b) There are use cases where callout = services adapt payload
> regardless
> > of the application protocol in use and = leave header
> adjustment to OPES
> > processor or other services. For example, = think of a generic text
> > translation or image modification service; = such services require
> > payload encoding knowledge but can be =
> application-independent if OPES
> > processor can supply them with just the = payload.
> >
> > c) OPES processor is always _able_ to = trace its own invocation and
> > service(s) execution because OPES = processor must understand the
> > application protocol. Assigning these = tracing tasks to
> callout servers
> > is just an optimization in cases where = callout servers manipulate
> > application message headers.
> >
> > d) May not be able to trace all services = that are done at
> the callout
> > server.
> >
> > e) It makes OPES compliance checks easier = when remote third party
> > callout servers are used.
> >
> > f) Servers or services MAY add their own = OPES trace records, of
> > course.
>
> I wonder if it is appropriate for the draft to = explain the
> motivation behind a decision, at such lengths? = Should we just
> state requirements instead?
>
> >
> > 4.5 Protocol Binding to Tracing
> >
> > How tracing is added is application = protocol-specific and will be
> > documented in separate drafts. This work = documents what tracing
> > information is required and some common = tracing elements.
> >
> > 5. Security Considerations
>
>
>
> I would suggest adding rules from the message = below (or
> something similar). They are very specific = things we can
> discuss/fix/polish, and they actually shape the =
> conventions/intent of many tracing draft = sections. The draft
> should be mostly about specific requirements, = not our
> motivation or reasoning about what we might do = and what
> design alternatives we have available.
>       http://www.imc.org/ietf-openproxy/mail-archive/msg0187= 5.html
> Please note that I am not saying the above = rules are perfect!
> I am just saying we need more specific = "bones" to grow the
> draft "meat" around, or we will never = exit the jelly state.
>
> Thank you,
>
> Alex.
>
>

------_=_NextPart_001_01C2FF77.24300796-- From owner-ietf-openproxy@mail.imc.org Thu Apr 10 12:06:34 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25133 for ; Thu, 10 Apr 2003 12:06:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AFfXJM022868 for ; Thu, 10 Apr 2003 08:41:33 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AFfXfA022867 for ietf-openproxy-bks; Thu, 10 Apr 2003 08:41:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3AFfWJM022863 for ; Thu, 10 Apr 2003 08:41:33 -0700 (PDT) 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 h3AFfHl02033; Thu, 10 Apr 2003 11:41:18 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Apr 2003 11:41:18 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754056BE64B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: jfcm , Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Tracing Draft version-0004082003 Date: Thu, 10 Apr 2003 11:41:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF77.9F6DF5D0" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C2FF77.9F6DF5D0 Content-Type: text/plain Hi, I will sort through and then make a decision on how to address the issues here. So, please wait untill the next update. Abbie > -----Original Message----- > From: jfcm [mailto:info@utel.net] > Sent: Wednesday, April 09, 2003 10:25 AM > To: Alex Rousskov; ietf-openproxy@imc.org > Subject: Re: Tracing Draft version-0004082003 > > > > At 15:03 09/04/03, Alex Rousskov wrote: > >On Wed, 9 Apr 2003, jfcm wrote: > > > > > > > OPES tracing facility > > > > > > > >How about just "OPES Tracing"? Does "Facility" mean something > > > >specific? Will there be other (non "facility") OPES > tracing drafts? > > > > > > You talk about notification as specific and sometime > separate from a > > blocked > > > tacing. > > > >What is block tracing? What do you mean by "notification as specific > >... blocked tracing"? > > I mean that if he permits to block the tracing facility (what > you object) he documents case were there is no tracing and > notification. So notification should be in the title. > > > > Also IAB expects a paper on tracing. > >What makes you think that? RFC 3238 does not contain the > word "trace" > >or "tracing", just "notification". Did I miss it? > > lapsus calami. I meant IAB expects a paper on notification. > Adding tracingis OK but notification must also be quoted in the title. > > > > >What about faulty callout servers? Do we have a term > that describes > > > >OPES system (processor + callout servers + whatever else is out > > > >there that is OPES-related)? > > > > > > In this Abbie's context, with "OPES Processor" being > actually used > > > as a word for the whole system manager, I fully accept > the wording. > > > OPES Processor can be a process in a box or the supervisor of a > > > large buch of callout/non-call out servers. > > > >OPES processor is defined in the architecture draft. The > definition is > >not context dependent. Figure 1 in that draft clearly shows callout > >servers outside of the processor box. We can change the definition > >and/or the figure (and I would support a discussion about it), but > >until we do, we have to use the old concept whether we like > it or not. > > I do dislike it. I say it. And I just say that Abbie's paper > is acceptable even for a person outside of this WG knowing > the reason of this language. > > > > >The above classification seems like a result of protocol > > > >over-engineering to me. Would it be possible to avoid > introducing > > > >any classifications/terms until the draft starts > actually _using_ > > > >them for a specific purpose? This will save us a lot of time -- > > > >there is no reason (and it is very difficult) to discuss > something > > > >that is not used (yet). > > > > > > Leaf to trunc (Basica vs C) approach. I do support that initial > > > lexical referencing. Skip the reading if you dislike it > and refere > > > to it further on. Reading has not to be linear. Keep the info of > > > where is the definition, so you dont have to master it > first shot. > > > Makes life easier, reading simpler and debates quicker. Our main > > > problem here is word definition, and where they fit in a commonly > > > accepted model. > > > >You misinterpreted my comment. I am objecting not to forward-looking > >definitions (they are perfectly fine), but definition that are not > >_used_ anywhere. It does not make sense, IMO, to include > debate-causing > >definitions (there is no consensus about the above > >definitions) when those definitions are not used! We can > include them > >once we actually start using them. > > OK. You said you would not discuss that tevel in your mail. > So I assumed the above. However I not fully dig into the > definitions but I felt they brought some light on what he > wanted to say and be of use in the futher debale. Will not > fight for them if the text is clear without them. > > > > Is it necessary to so exnesively motivate a decision. > > > >If a decision may contradict IAB expectations, then yes. > > Is there not a way to document a position without entering > them into the text? This makes the text to be part of a > debate rather than a reference. This may give the feeling the > examples are very important to the text, while they are only > current examples. > > > > It would be helpfull in foot notes. Should notes be permited? > > > >As an Appendix, yes. I am fine with moving the above rant into an > >Appendix. > > great. > > > > >Why not MUST be always-on? We are talking about interoperability > > > >here (a broken intermediary that does not use Via-OPES > headers is > > > >an > > interoperability > > > >problem because it cannot be bypassed). > > > > > > If HTTP Via is SHOULD it can only be SHOULD. > > > >Why? HTTP does (did) not have IAB considerations to address. > We have a > >much higher bar to jump over. > > IAB is not the reference for me. The reference is the > consistency of what > is considered. OPES are over HTTP. There should not be > obliged more than > the supporting HTTP protocol. Seems layer violation to me. > > > > >Also, we need to add MUST/SHOULD/MAY to each traceable entity, I > > > >guess. > > > > > > MAY. to be consitent with your wording. > > > >Which wording? > > Just above you used the word "can ". > > > > >I am not sure about the above. It contradicts our > statement that we > > > >are addressing IAB concerns. If there is no trace, we > are not. I > > > >think it is reasonable to say that there MUST be at > least one trace > > > >entry per > > "system". > > > >(A trust domain may include several such > systems/entities, see the > > > >trust domain definition). > > > > > > I think we are with option to turn it out. Privacy must be > > > permitted. > > > >If a provider has an option to turn _all_ tracing off, then > we are not > >supporting notification in any shape or form. Privacy can be > permitted > >by making trace entries contain no private information. > > If you accept to waste bandwidth and nanoseconds, yes. > jfc > > > ------_=_NextPart_001_01C2FF77.9F6DF5D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Tracing Draft version-0004082003

Hi,

I will sort through and then make a decision on how = to address the issues here.
So, please wait untill the next update.

Abbie


> -----Original Message-----
> From: jfcm [mailto:info@utel.net]
> Sent: Wednesday, April 09, 2003 10:25 AM
> To: Alex Rousskov; = ietf-openproxy@imc.org
> Subject: Re: Tracing Draft = version-0004082003
>
>
>
> At 15:03 09/04/03, Alex Rousskov wrote:
> >On Wed, 9 Apr 2003, jfcm wrote:
> >
> > > > = >           &n= bsp;           OPES = tracing facility
> > > >
> > > >How about just "OPES = Tracing"? Does "Facility" mean something
> > > >specific? Will there be other = (non "facility") OPES
> tracing drafts?
> > >
> > > You talk about notification as = specific and sometime
> separate from a
> > blocked
> > > tacing.
> >
> >What is block tracing? What do you mean by = "notification as specific
> >... blocked tracing"?
>
> I mean that if he permits to block the tracing = facility (what
> you object) he documents case were there is no = tracing and
> notification. So notification should be in the = title.
>
> > > Also IAB expects a paper on = tracing.
> >What makes you think that? RFC 3238 does = not contain the
> word "trace"
> >or "tracing", just = "notification". Did I miss it?
>
> lapsus calami. I meant IAB expects a paper on = notification.
> Adding tracingis OK but notification must also = be quoted in the title.
>
> > > >What about faulty callout = servers? Do we have a term
> that describes
> > > >OPES system (processor + callout = servers + whatever else is out
> > > >there that is = OPES-related)?
> > >
> > > In this Abbie's context, with = "OPES Processor" being
> actually used
> > > as a word for the whole system = manager, I fully accept
> the wording.
> > > OPES Processor can be a process in a = box or the supervisor of a
> > > large buch of callout/non-call out = servers.
> >
> >OPES processor is defined in the = architecture draft. The
> definition is
> >not context dependent. Figure 1 in that = draft clearly shows callout
> >servers outside of the processor box. We = can change the definition
> >and/or the figure (and I would support a = discussion about it), but
> >until we do, we have to use the old concept = whether we like
> it or not.
>
> I do dislike it. I say it. And I just say that = Abbie's paper
> is acceptable even for a person outside of this = WG knowing
> the reason of this language.
>
> > > >The above classification seems = like a result of protocol
> > > >over-engineering to me. Would it = be possible to avoid
> introducing
> > > >any classifications/terms until = the draft starts
> actually _using_
> > > >them for a specific = purpose?  This will save us a lot of time --
> > > >there is no reason (and it is = very difficult) to discuss
> something
> > > >that is not used (yet).
> > >
> > > Leaf to trunc (Basica vs C) approach. = I do support that initial
> > > lexical referencing. Skip the reading = if you dislike it
> and refere
> > > to it further on. Reading has not to = be linear. Keep the info of
> > > where is the definition, so you dont = have to master it
> first shot.
> > > Makes life easier, reading simpler = and debates quicker. Our main
> > > problem here is word definition, and = where they fit in a commonly
> > > accepted model.
> >
> >You misinterpreted my comment. I am = objecting not to forward-looking
> >definitions (they are perfectly fine), but = definition that are not
> >_used_ anywhere. It does not make sense, = IMO, to include
> debate-causing
> >definitions (there is no consensus about = the above
> >definitions) when those definitions are not = used! We can
> include them
> >once we actually start using them.
>
> OK. You said you would not discuss that tevel = in your mail.
> So I assumed the above. However I not fully dig = into the
> definitions but I felt they brought some light = on what he
> wanted to say and be of use in the futher = debale. Will not
> fight for them if the text is clear without = them.
>
> > > Is it necessary to so exnesively = motivate a decision.
> >
> >If a decision may contradict IAB = expectations, then yes.
>
> Is there not a way to document a position = without entering
> them into the text? This makes the text to be = part of a
> debate rather than a reference. This may give = the feeling the
> examples are very important to the text, while = they are only
> current examples.
>
> > > It would be helpfull in foot notes. = Should notes be permited?
> >
> >As an Appendix, yes. I am fine with moving = the above rant into an
> >Appendix.
>
> great.
>
> > > >Why not MUST be always-on? We are = talking about interoperability
> > > >here (a broken intermediary that = does not use Via-OPES
> headers is
> > > >an
> > interoperability
> > > >problem because it cannot be = bypassed).
> > >
> > > If HTTP Via is SHOULD it can only be = SHOULD.
> >
> >Why? HTTP does (did) not have IAB = considerations to address.
> We have a
> >much higher bar to jump over.
>
> IAB is not the reference for me. The reference = is the
> consistency of what
> is considered. OPES are over HTTP. There should = not be
> obliged more than
> the supporting HTTP protocol. Seems layer = violation to me.
>
> > > >Also, we need to add = MUST/SHOULD/MAY to each traceable entity, I
> > > >guess.
> > >
> > > MAY. to be consitent with your = wording.
> >
> >Which wording?
>
> Just above you used the word "can = ".
>
> > > >I am not sure about the above. It = contradicts our
> statement that we
> > > >are addressing IAB concerns. If = there is no trace, we
> are not.  I
> > > >think it is reasonable to say = that there MUST be at
> least one trace
> > > >entry per
> > "system".
> > > >(A trust domain may include = several such
> systems/entities, see the
> > > >trust domain definition).
> > >
> > > I think we are with option to turn it = out. Privacy must be
> > > permitted.
> >
> >If a provider has an option to turn _all_ = tracing off, then
> we are not
> >supporting notification in any shape or = form. Privacy can be
> permitted
> >by making trace entries contain no private = information.
>
> If you accept to waste bandwidth and = nanoseconds, yes.
> jfc
>
>
>

------_=_NextPart_001_01C2FF77.9F6DF5D0-- From owner-ietf-openproxy@mail.imc.org Thu Apr 10 13:04:25 2003 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26589 for ; Thu, 10 Apr 2003 13:04:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AGqUJM025820 for ; Thu, 10 Apr 2003 09:52:30 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AGqUmp025819 for ietf-openproxy-bks; Thu, 10 Apr 2003 09:52:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3AGqTJM025814 for ; Thu, 10 Apr 2003 09:52:29 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3AGqVvj082828 for ; Thu, 10 Apr 2003 10:52:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3AGqVJE082827; Thu, 10 Apr 2003 10:52:31 -0600 (MDT) (envelope-from rousskov) Date: Thu, 10 Apr 2003 10:52:30 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: OCP Core version head_sid4 available Message-ID: 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: To the best of my knowledge, all new specific OCP comments that caused no further objections/questions are now applied to the draft. The "application message" definition and related text has been changed (improved?) again. I think we are getting close to a stable definition though. If you have any additions or corrections for the [new] misspelled Acknowledgments section, please let me know. The authors list is not frozen either, of course. The [major] change log is quoted below. The latest snapshot, including XML sources for those doing hands-on modifications, is available at http://www.measurement-factory.com/tmp/opes/ Please continue to comment and work on the to-do list. Thank you, Alex. -------------- change log ---------------- Appendix B. Change Log <217> <218> o Changed document labels to reflect future "WG draft" status. <219> o Added Acknowledgments section. <220> o Added "Core" to the title since we expect application specific drafts to follow and because this document, even when complete, cannot specify a "working" protocol without application-specific parts. This change is still debatable. <221> o Added reference to required future application-specific specs in the Introduction. <222> o Moved all rant about irrelevance of application protocols proxied by an OPES processor to the "Application proxies and OCP scope" section. Removed "processor input" and "processor output" terms. No reason to define a new term when its only purpose is to document irrelevance? <223> o Moved "OCP message" definition to the terminology section. <224> o Clarified "application message" definition based on recent WG discussions and suggestions. There seems to be consensus that "application message" is whatever OPES processor and callout server define or agree on, but OCP needs some minimal structure (content + metadata) <225> o Synced data and metadata definitions with the new "application message" definition. <226> o Simplified "Overall Operation" section since it no longer need to talk about irrelevance of application protocols proxied by an OPES processor. <227> o Illustrated nesting/relationship of key OCP concepts (application message, OCP message, transaction, connection, transport connection, etc.). The figure needs more work. <228> o Listed all from-processor and from-server OCP messages in one place, with references to message definitions. <229> o Added "services" message parameter, assuming that more than one service may be requested/executed with one transaction. <230> o Gave callout server ability to report what services were actually applied (see "services" parameter definition). From owner-ietf-openproxy@mail.imc.org Thu Apr 10 13:49:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27844 for ; Thu, 10 Apr 2003 13:49:24 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193fuo-00032q-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 13:32:46 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193fuo-00032n-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 13:32:46 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AHc6JM027665 for ; Thu, 10 Apr 2003 10:38:06 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AHc65D027664 for ietf-openproxy-bks; Thu, 10 Apr 2003 10:38:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3AHc4JM027660 for ; Thu, 10 Apr 2003 10:38:05 -0700 (PDT) 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.9/8.12.9) with ESMTP id h3AHc69Y073049 for ; Thu, 10 Apr 2003 13:38:06 -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 h3AHc0c6038644 for ; Thu, 10 Apr 2003 13:38:00 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3AHbwQ4027467 for ; Thu, 10 Apr 2003 13:37:59 -0400 (EDT) Message-ID: <3E95AC27.7060609@mhof.com> Date: Thu, 10 Apr 2003 13:38:47 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: set of OPES documents References: <5.2.0.9.0.20030406192433.03477ec0@mail.utel.net> 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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > It would help authors to know the set of final OPES documents so > that appropriate cross-references can be made before all documents > are written. The set can change at any time, of course. Yup. In general, however, let me second Hilarie''s advise (in a later email) that we should try to avoid a *large* number of related drafts. This does *not* preclude having separate, focused drafts as you propose, but if there are multiple choices on how to split them, a general guideline would be to keep the number of separate documents low (as feasible). > I would like to suggest the following set. It is based on a principle > that it is better to have one application-specific document per > application. An alternative is to have one application-specific > document per application, per application-independent draft. Following above guideline, I would be tempted to lean towards the former approach, namely having one application-specific document per application. > The set is incomplete, I only mention some documents we care about at > this time: > > Application-independent documents: > > OPES Architecture > draft-ietf-opes-architecture > > OPES Callout Protocol Core > draft-ietf-opes-ocp > > OPES Tracing > draft-ietf-opes-trace > > OPES Bypass > draft-ietf-opes-bypass As suggested later, I like the idea of combining the later two, since both are concerned about conveying information towards the end-user(s). > Application-specific documents: > > OPES adaptation of HTTP > draft-ietf-opes-http > > OPES adaptation of SMTP > draft-ietf-opes-smtp > > OPES adaptation of FooBarP > draft-ietf-opes-foobarp Yes, but only the first one (on HTTP) would be within the current charter of the WG. -Markus From owner-ietf-openproxy@mail.imc.org Thu Apr 10 18:30:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10508 for ; Thu, 10 Apr 2003 18:30:22 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193kIh-0004zc-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 18:13:43 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193kIh-0004zZ-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 18:13:43 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AMAIJM013477 for ; Thu, 10 Apr 2003 15:10:18 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AMAIOG013476 for ietf-openproxy-bks; Thu, 10 Apr 2003 15:10:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AMAGJM013469 for ; Thu, 10 Apr 2003 15:10:17 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3AMCbKq016057; Thu, 10 Apr 2003 16:12:38 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3AM9Wo03702; Thu, 10 Apr 2003 16:09:32 -0600 Date: Thu, 10 Apr 2003 16:09:32 -0600 Message-Id: <200304102209.h3AM9Wo03702@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: OCP Core version head_sid4 available Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Maybe I misunderstood the purpose of app-messages, but I don't see how to use the app-message-* directives to allow more than one "response" from the callout server. The OPES processor does app-message-start for am-id, X, then some data, then app-message-end am-id=X, and the callout server will respond with app-message-start am-id=X and sometime later app-message-end am-id=X. At that point all state about am-id=X on both machines must be destroyed. How can the callout server send another version of the data it received from the OPES processor and relate it to am-id=X? Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 10 18:32:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10572 for ; Thu, 10 Apr 2003 18:32:36 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193kKs-0004zw-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 18:15:58 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193kKr-0004zt-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 18:15:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AMLpJM014046 for ; Thu, 10 Apr 2003 15:21:51 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AMLph2014045 for ietf-openproxy-bks; Thu, 10 Apr 2003 15:21:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AMLoJM014040 for ; Thu, 10 Apr 2003 15:21:50 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3AMOCKq016403 for ; Thu, 10 Apr 2003 16:24:12 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3AMLCU04276; Thu, 10 Apr 2003 16:21:12 -0600 Date: Thu, 10 Apr 2003 16:21:12 -0600 Message-Id: <200304102221.h3AMLCU04276@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org Subject: Charter issues Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Are we defining standards that apply to any content transforming proxy, even those which do not use a callout protocol? Such an entity might be known as an "IETF standard OPES processor"? From our charter, I would guess that this is true, and that the callout protocol is a minor part of the work. However, I'd never really thought of it that way - we've done so little on authorization, reversibility, "end-to-end" encryption, policy specification, control by endpoints, tracking, traceability, etc. that it would be difficult for someone to tell whether or not a particular content-transforming proxy was "IETF compliant" or not. Should we be working on this? My impression was that we would have guidelines, but the only thing that would really be standardized would be a callout protocol and tracing support. What's the group opinion? Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 10 19:25:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11671 for ; Thu, 10 Apr 2003 19:25:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193lAO-0005Dz-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:09:12 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193lAN-0005Dw-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:09:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AN6NJM015104 for ; Thu, 10 Apr 2003 16:06:23 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AN6NVc015103 for ietf-openproxy-bks; Thu, 10 Apr 2003 16:06:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3AN6LJM015099 for ; Thu, 10 Apr 2003 16:06:22 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3AN6Nvj092495; Thu, 10 Apr 2003 17:06:23 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3AN6NDH092494; Thu, 10 Apr 2003 17:06:23 -0600 (MDT) (envelope-from rousskov) Date: Thu, 10 Apr 2003 17:06:23 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP Core version head_sid4 available In-Reply-To: <200304102209.h3AM9Wo03702@localhost.localdomain> Message-ID: References: <200304102209.h3AM9Wo03702@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: On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > Maybe I misunderstood the purpose of app-messages, but I don't see > how to use the app-message-* directives to allow more than one > "response" from the callout server. This is achieved by responding with several all-message-start messages, all with distinct am-ids. > The OPES processor does app-message-start > for am-id, X, then some data, then app-message-end am-id=X, yes > and the callout server will respond with app-message-start am-id=X no, am-id=y1 > and sometime later app-message-end am-id=X. no, app-message-end xid am-id=y1 In addition to that, it can respond with more (at _any_ time after receiving app-message-start am-id=x): app-message-start xid am-id=y2 app-message-start xid am-id=y3 ... app-message-start xid am-id=y4 ... app-message-end xid am-id=y3 app-message-end xid am-id=y2 ... app-message-end xid am-id=y4 or whatever (interleaved in any way). It is important that there is no [documented] relation between original and adapted flows. Usually, the original application message is adapted according to requested services, but other things might happen as well (errors, service ID expansion, or whatever). > How can the callout server send another version of the data it > received from the OPES processor and relate it to am-id=X? It does not need to relate to am-id=x because that is what transaction ID (xid) is for. By definition, OCP transactions encapsulate processing of the original application message (am-id=x). Technically, we do not even need am-id parameter for original data flow. Does this clarify? Also, look at the new "adapted flow" figure in the draft (and related figures). It also shows how multiple adapted application messages within one transaction are possible. Can the figure be improved to make the above more apparent? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 10 19:27:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11839 for ; Thu, 10 Apr 2003 19:27:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193lCD-0005Gs-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:11:05 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193lCD-0005Gp-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:11:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANIQJM015558 for ; Thu, 10 Apr 2003 16:18:26 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3ANIQoM015557 for ietf-openproxy-bks; Thu, 10 Apr 2003 16:18:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANIOJM015551 for ; Thu, 10 Apr 2003 16:18:25 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3ANKlKq018399; Thu, 10 Apr 2003 17:20:47 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3ANHkF06946; Thu, 10 Apr 2003 17:17:46 -0600 Date: Thu, 10 Apr 2003 17:17:46 -0600 Message-Id: <200304102317.h3ANHkF06946@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: OCP Core version head_sid4 available Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for am-id clarification. In general, the OPES processor won't know how many am's might be sent by the callout server or what kinds they might be. This makes it difficult to know what to start carrying on the proxied flow. Should the OPES processor wait until transaction-close? That seems inefficient. How do people envision using this multiple return message feature? Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 10 19:32:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11955 for ; Thu, 10 Apr 2003 19:32:03 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193lGP-0005Iq-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:15:25 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193lGP-0005Il-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:15:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANLYJM015715 for ; Thu, 10 Apr 2003 16:21:34 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3ANLYku015714 for ietf-openproxy-bks; Thu, 10 Apr 2003 16:21:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANLXJM015708 for ; Thu, 10 Apr 2003 16:21:33 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3ANNuKq018459 for ; Thu, 10 Apr 2003 17:23:56 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3ANKse07094; Thu, 10 Apr 2003 17:20:54 -0600 Date: Thu, 10 Apr 2003 17:20:54 -0600 Message-Id: <200304102320.h3ANKse07094@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org Subject: Shortcuts Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I had a returned thought on the issue of whether or not data had to complete the loop between the OPES processor and the callout server. If the proxied protocol is a store-and-forward type, like SMTP, then it seems that the callout server might, quite properly, send transformed messages directly to an application endpoint (SMTP server) without going back through the OPES processor. If this is proper, should we document it. If it is improper, can we say why? Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 10 19:35:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12061 for ; Thu, 10 Apr 2003 19:35:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193lK3-0005KZ-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:19:11 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193lK2-0005KW-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:19:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANPJJM016270 for ; Thu, 10 Apr 2003 16:25:19 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3ANPJSM016269 for ietf-openproxy-bks; Thu, 10 Apr 2003 16:25:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3ANPHJM016262 for ; Thu, 10 Apr 2003 16:25:18 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3ANPIvj092872; Thu, 10 Apr 2003 17:25:18 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3ANPInW092871; Thu, 10 Apr 2003 17:25:18 -0600 (MDT) (envelope-from rousskov) Date: Thu, 10 Apr 2003 17:25:18 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Charter issues In-Reply-To: <200304102221.h3AMLCU04276@localhost.localdomain> Message-ID: References: <200304102221.h3AMLCU04276@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: On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > Are we defining standards that apply to any content transforming > proxy, even those which do not use a callout protocol? Some of our standards will apply to content transforming proxies (OPES processors) that do not use OCP. > Such an entity > might be known as an "IETF standard OPES processor"? Something like that. Just "OPES processor" is probably sufficient. > From our charter, I would guess that this is true, and that the > callout protocol is a minor part of the work. The same conclusion can be derived from already published drafts. > we've done so little on authorization, reversibility, "end-to-end" > encryption, policy specification, control by endpoints, tracking, > traceability, etc. that it would be difficult for someone to tell whether > or not a particular content-transforming proxy was "IETF compliant" or not. "OPES compliant". IETF may have other standards related to content-transforming proxies. It is impossible to tell right now whether something is OPES compliant, of course. - tracing: We have made very good progress on tracing (IMO, most major decisions either have been made or have known options to chose from). Abbie is already working on the second revision of the draft that will cover tracing (at least). - We talked about authorization a little bit (its bypass form) - I am not sure what reversibility is. - "end-to-end" encryption seems to be out of scope - policy specification is out of scope if you mean "privacy policy specification" - control by endpoints: same as authorization? > Should we be working on this? Yes, and we are. > My impression was that we would have guidelines, but the only thing > that would really be standardized would be a callout protocol and > tracing support. What's the group opinion? and bypass (or other form(s) of authorization) Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 10 19:47:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12442 for ; Thu, 10 Apr 2003 19:47:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193lVi-0005Pd-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:31:14 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193lVh-0005Pa-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 19:31:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANbVJM016895 for ; Thu, 10 Apr 2003 16:37:31 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3ANbUUT016894 for ietf-openproxy-bks; Thu, 10 Apr 2003 16:37:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3ANbTJM016890 for ; Thu, 10 Apr 2003 16:37:29 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3ANbUvj093218; Thu, 10 Apr 2003 17:37:30 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3ANbUDa093217; Thu, 10 Apr 2003 17:37:30 -0600 (MDT) (envelope-from rousskov) Date: Thu, 10 Apr 2003 17:37:30 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP Core version head_sid4 available In-Reply-To: <200304102317.h3ANHkF06946@localhost.localdomain> Message-ID: References: <200304102317.h3ANHkF06946@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: On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > Thanks for am-id clarification. In general, the OPES processor > won't know how many am's might be sent by the callout server or what > kinds they might be. If this knowledge is needed, it can be relayed via metadata or explicitly added to the protocol as an "expect more" flag/parameter. My expectation is that the possibility of multiple adapted application messages is application-dependent. Those OPES processors that support applications like SMTP would wait for the callout server to close the transaction. > This makes it difficult to know what to start carrying > on the proxied flow. Not sure what you mean. The number of adapted application messages does not really affect proxied flow. Usually, OPES processor would start post-processing and sending out every application message it receives immediately after it gets app-message-start message (whether it is the first such message or 10th). Multiple adapted application messages are only allowed for protocols like SMTP where that is not a problem, of course. Did I misunderstood your statement? > Should the OPES processor wait until transaction-close? > That seems inefficient. Why should it? It got an adapted application message it can proceed with. OCP supports very efficient pipeline where there is no waiting as long as the application protocol supports such behavior. See http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-06.txt for example. There were other SMTP-related examples posted on the list. Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 10 21:23:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14446 for ; Thu, 10 Apr 2003 21:23:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193n0J-0005sV-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 21:06:55 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193n0I-0005s4-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 21:06:54 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B11PJM021558 for ; Thu, 10 Apr 2003 18:01:25 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B11PoH021557 for ietf-openproxy-bks; Thu, 10 Apr 2003 18:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B11OJM021550 for ; Thu, 10 Apr 2003 18:01:24 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3B13nKq021685; Thu, 10 Apr 2003 19:03:49 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3B10fe12544; Thu, 10 Apr 2003 19:00:41 -0600 Date: Thu, 10 Apr 2003 19:00:41 -0600 Message-Id: <200304110100.h3B10fe12544@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: OCP Core version head_sid4 available Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm thinking of image conversion as an example, but anything with the HTTP "vary" header more generally. If the requested OPES service is something general, like "decrease image size", one could imagine the service returning several responses, like "black and white", "300x400 depth 3", etc. Or the service "translate to local language" might return "french", "german", and "italian" in some places. The OPES processor will look at the headers on the returned am's, looking for something that matches the preferences of the user who caused the content to be converted. Although more than one might be acceptable, one might be best. Without knowing whether or not it's going to be part of the transaction, the OPES processor would have to wait until transaction close to send the result. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 10 22:19:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15547 for ; Thu, 10 Apr 2003 22:19:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193ns2-00067c-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 22:02:26 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193ns2-00067Y-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 22:02:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B1xCJM023409 for ; Thu, 10 Apr 2003 18:59:12 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B1xCaO023408 for ietf-openproxy-bks; Thu, 10 Apr 2003 18:59:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.109]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B1xAJM023403 for ; Thu, 10 Apr 2003 18:59:11 -0700 (PDT) Received: from mhof.com ([135.104.20.77]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HD5000REPFQ11@mtaout11.icomcast.net> for ietf-openproxy@imc.org; Thu, 10 Apr 2003 21:57:27 -0400 (EDT) Date: Thu, 10 Apr 2003 21:57:26 -0400 From: Markus Hofmann Subject: Re: Shortcuts In-reply-to: <200304102320.h3ANKse07094@localhost.localdomain> Cc: ietf-openproxy@imc.org Message-id: <3E962106.6080608@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <200304102320.h3ANKse07094@localhost.localdomain> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT The Purple Streak, Hilarie Orman wrote: > I had a returned thought on the issue of whether or not data had to > complete the loop between the OPES processor and the callout server. > If the proxied protocol is a store-and-forward type, like SMTP, then > it seems that the callout server might, quite properly, send > transformed messages directly to an application endpoint (SMTP server) > without going back through the OPES processor. If that is the case, why would you need a callout protocol in the first place? Why wouldn't "OPES processor" and "callout server" talk SMTP between each other? "OPES processor" and "callout server" would just be two mail servers talking SMTP... -Markus From owner-ietf-openproxy@mail.imc.org Thu Apr 10 22:35:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15794 for ; Thu, 10 Apr 2003 22:35:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193o7s-0006BN-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 22:18:48 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193o7r-0006BK-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 22:18:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B2P3JM024678 for ; Thu, 10 Apr 2003 19:25:03 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B2P3nV024677 for ietf-openproxy-bks; Thu, 10 Apr 2003 19:25:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B2P2JM024670 for ; Thu, 10 Apr 2003 19:25:02 -0700 (PDT) Received: from mhof.com ([135.104.20.77]) by mtaout08.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HD50064AQI53P@mtaout08.icomcast.net> for ietf-openproxy@imc.org; Thu, 10 Apr 2003 22:20:30 -0400 (EDT) Date: Thu, 10 Apr 2003 22:20:29 -0400 From: Markus Hofmann Subject: Re: Charter issues In-reply-to: <200304102221.h3AMLCU04276@localhost.localdomain> To: ietf-openproxy@imc.org Message-id: <3E96266D.1020406@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <200304102221.h3AMLCU04276@localhost.localdomain> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT The Purple Streak, Hilarie Orman wrote: > Are we defining standards that apply to any content transforming > proxy, even those which do not use a callout protocol? We're chartered to define two things: a "callout protocol" and a "rules specification method". Obviously, the former applies only to services using a callout, the later also applies to services that don't use a callout. We're further chartered to "draft [a] high-level, overall example OPES architecture", which is different from "defining a standard". > Such an entity > might be known as an "IETF standard OPES processor"? From our charter, > I would guess that this is true, and that the callout protocol is a > minor part of the work. The "high-level, overall example OPES architecture" we're chartered to *draft* certainly includes this possibility, but I don't see us chartered to *standardize* it. The draft architecture is expected to only set the stage for the callout protocol and the rules specification method. > However, I'd never really thought of it that > way - we've done so little on authorization, reversibility, "end-to-end" > encryption, policy specification, control by endpoints, tracking, > traceability, etc. that it would be difficult for someone to tell whether > or not a particular content-transforming proxy was "IETF compliant" or not. > Should we be working on this? I'd say we need to work on this to the extend that we must understand the implications coming from that for (a) the callout protocol and (b) the rules specification method. > My impression was that we would have guidelines, but the only thing that > would really be standardized would be a callout protocol and tracing > support. What's the group opinion? I agree with you, but in addition we're also chartered to standardize the rules specification method. -Markus From owner-ietf-openproxy@mail.imc.org Fri Apr 11 00:14:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17268 for ; Fri, 11 Apr 2003 00:14:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193pfZ-0006Vi-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 23:57:41 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193pfY-0006Vf-00 for opes-archive@ietf.org; Thu, 10 Apr 2003 23:57:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B43AJM028058 for ; Thu, 10 Apr 2003 21:03:10 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B43ALj028057 for ietf-openproxy-bks; Thu, 10 Apr 2003 21:03:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3B439JM028053 for ; Thu, 10 Apr 2003 21:03:09 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3B42Vvj099371; Thu, 10 Apr 2003 22:02:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3B42VQZ099370; Thu, 10 Apr 2003 22:02:31 -0600 (MDT) (envelope-from rousskov) Date: Thu, 10 Apr 2003 22:02:31 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Shortcuts In-Reply-To: <200304102320.h3ANKse07094@localhost.localdomain> Message-ID: References: <200304102320.h3ANKse07094@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: On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > I had a returned thought on the issue of whether or not data had to > complete the loop between the OPES processor and the callout server. > If the proxied protocol is a store-and-forward type, like SMTP, then > it seems that the callout server might, quite properly, send > transformed messages directly to an application endpoint (SMTP server) > without going back through the OPES processor. > > If this is proper, should we document it. If it is improper, can > we say why? Excellent question! If a callout server accepts application message and then just forwards an adapted version elsewhere, it is not (should not be) a callout server. It is an OPES processor! Thus, it is absolutely proper to do that as long as the entity in question does not pretend to be a callout server and obeys all processor requirements. Here is what you get in that case: -- (SMTP) --> OPES --> (SMTP) --> OPES --> (SMTP) processor 1 processor 2 Which is perfectly fine and is obviously beyond OCP scope (OCP is not involved here). If, for some unnatural reason, the same thing is implemented using OCP, it may still be OPES-legal as long as both OPES agents know what they are doing: callout server -- (SMTP) --> OPES --> (OCP) --> _and_ OPES --> (SMTP) processor 1 processor 2 Essentially, "adaptation service" here means "I took care of it, forget it". This is OK as long as processors cooperate. Note that the callout server would be required to respond with that "I took care of it" application message to its OPES processor 1 (that application message/response will probably have no payload though, just metadata). No need to documented this convoluted case, IMO. A somewhat similar but more realistic example with an "I took care of it" response would be a "black hole" service (e.g., a SPAM filter): -- (SMTP) --> OPES --> (OCP) --> callout processor 1 server The latter might be worth documenting in an "SMTP adaptation using OPES" draft. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Fri Apr 11 00:32:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17742 for ; Fri, 11 Apr 2003 00:32:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193pww-0006ZR-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 00:15:38 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193pww-0006ZO-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 00:15:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B4D4JM028230 for ; Thu, 10 Apr 2003 21:13:04 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B4D4Vh028229 for ietf-openproxy-bks; Thu, 10 Apr 2003 21:13:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3B4D2JM028225 for ; Thu, 10 Apr 2003 21:13:02 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3B4D6vj099607; Thu, 10 Apr 2003 22:13:06 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3B4D52W099606; Thu, 10 Apr 2003 22:13:05 -0600 (MDT) (envelope-from rousskov) Date: Thu, 10 Apr 2003 22:13:05 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP Core version head_sid4 available In-Reply-To: <200304110100.h3B10fe12544@localhost.localdomain> Message-ID: References: <200304110100.h3B10fe12544@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: On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > I'm thinking of image conversion as an example, but anything with the > HTTP "vary" header more generally. If the requested OPES service is > something general, like "decrease image size", one could imagine the > service returning several responses, like "black and white", "300x400 > depth 3", etc. Or the service "translate to local language" might > return "french", "german", and "italian" in some places. The OPES > processor will look at the headers on the returned am's, looking for > something that matches the preferences of the user who caused the > content to be converted. Although more than one might be acceptable, > one might be best. Without knowing whether or not it's going to be > part of the transaction, the OPES processor would have to wait until > transaction close to send the result. That is fine/unavoidable, I think. There are examples where pipeline model does not (cannot) work all the way through. Any example where the OPES processor does post-processing, and that post-processing needs to know all adapted response(s) before starting, will break pipeline at the OPES processor. Note that (a) it does not break the protocol, just prevents certain optimizations (b) I cannot think of any optimization that is not supported by OCP but will work better that OCP here (c) OPES processor may relay user preferences to the callout server so that the serve can produce a single best response (if the server is smart enough to do that). This can be done via metadata, of course. Alex. From owner-ietf-openproxy@mail.imc.org Fri Apr 11 02:06:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25526 for ; Fri, 11 Apr 2003 02:06:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193rPy-0006sW-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 01:49:43 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193rPy-0006sT-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 01:49:42 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B5v6JM001029 for ; Thu, 10 Apr 2003 22:57:06 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B5v6QT001028 for ietf-openproxy-bks; Thu, 10 Apr 2003 22:57:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B5v5JM001024 for ; Thu, 10 Apr 2003 22:57:05 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3B5xYKq030352; Thu, 10 Apr 2003 23:59:34 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3B5uRB26076; Thu, 10 Apr 2003 23:56:27 -0600 Date: Thu, 10 Apr 2003 23:56:27 -0600 Message-Id: <200304110556.h3B5uRB26076@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: OCP Core version head_sid4 available Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's not that the OPES processor wants only one response, it's that it needs to know, in advance, which reponses are coming. In fact, it may need to cause early termination of some responses in order to manage cache space. Hilarie On Thu, 10 Apr 2003 at 22:13:05 -0600 (MDT) Alex Rousskov contended: > On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > I'm thinking of image conversion as an example, but anything with the > > HTTP "vary" header more generally. If the requested OPES service is > > something general, like "decrease image size", one could imagine the > > service returning several responses, like "black and white", "300x400 > > depth 3", etc. Or the service "translate to local language" might > > return "french", "german", and "italian" in some places. The OPES > > processor will look at the headers on the returned am's, looking for > > something that matches the preferences of the user who caused the > > content to be converted. Although more than one might be acceptable, > > one might be best. Without knowing whether or not it's going to be > > part of the transaction, the OPES processor would have to wait until > > transaction close to send the result. > That is fine/unavoidable, I think. There are examples where pipeline > model does not (cannot) work all the way through. Any example where > the OPES processor does post-processing, and that post-processing > needs to know all adapted response(s) before starting, will break > pipeline at the OPES processor. Note that > (a) it does not break the protocol, just prevents > certain optimizations > (b) I cannot think of any optimization that is > not supported by OCP but will work better that OCP > here > (c) OPES processor may relay user preferences to > the callout server so that the serve can produce > a single best response (if the server is smart > enough to do that). This can be done via metadata, > of course. From owner-ietf-openproxy@mail.imc.org Fri Apr 11 02:11:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29813 for ; Fri, 11 Apr 2003 02:11:05 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193rUZ-0006t1-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 01:54:27 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193rUY-0006sy-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 01:54:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B5qIJM000609 for ; Thu, 10 Apr 2003 22:52:18 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B5qIoU000608 for ietf-openproxy-bks; Thu, 10 Apr 2003 22:52:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B5qHJM000604 for ; Thu, 10 Apr 2003 22:52:17 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3B5sjKq030213; Thu, 10 Apr 2003 23:54:46 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3B5pct25850; Thu, 10 Apr 2003 23:51:38 -0600 Date: Thu, 10 Apr 2003 23:51:38 -0600 Message-Id: <200304110551.h3B5pct25850@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: markus@mhof.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <3E962106.6080608@mhof.com> Subject: Re: Shortcuts Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As has been mentioned before, because friends of OPES would like to deal with OPES and its callout protocol for all content transformation tasks. Just makes life easier. Hilarie On Thu, 10 Apr 2003 at 21:57:26 -0400 Markus Hofmann mused: > The Purple Streak, Hilarie Orman wrote: > > I had a returned thought on the issue of whether or not data had to > > complete the loop between the OPES processor and the callout server. > > If the proxied protocol is a store-and-forward type, like SMTP, then > > it seems that the callout server might, quite properly, send > > transformed messages directly to an application endpoint (SMTP server) > > without going back through the OPES processor. > If that is the case, why would you need a callout protocol in the > first place? Why wouldn't "OPES processor" and "callout server" talk > SMTP between each other? "OPES processor" and "callout server" would > just be two mail servers talking SMTP... > -Markus From owner-ietf-openproxy@mail.imc.org Fri Apr 11 06:48:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06490 for ; Fri, 11 Apr 2003 06:48:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193vp8-0000u2-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 06:31:58 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193vp7-0000tz-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 06:31:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BAZxJM010633 for ; Fri, 11 Apr 2003 03:35:59 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BAZxGm010632 for ietf-openproxy-bks; Fri, 11 Apr 2003 03:35:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BAZwJM010627 for ; Fri, 11 Apr 2003 03:35:58 -0700 (PDT) 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 h3BAZjj10422; Fri, 11 Apr 2003 06:35:46 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Apr 2003 06:35:45 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754056BEC1E@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Shortcuts Date: Fri, 11 Apr 2003 06:35:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30016.1BDA9EFE" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30016.1BDA9EFE Content-Type: text/plain Alex, yes I agree with your assement. This case is beyond OCP.(although in theory u can still use OCP but the question is why?) Should we call it distributed OPES processor (where performance does not count) abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, April 11, 2003 12:03 AM > To: ietf-openproxy@imc.org > Subject: Re: Shortcuts > > > > On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > > I had a returned thought on the issue of whether or not data had to > > complete the loop between the OPES processor and the > callout server. > > If the proxied protocol is a store-and-forward type, like > SMTP, then > > it seems that the callout server might, quite properly, send > > transformed messages directly to an application endpoint > (SMTP server) > > without going back through the OPES processor. > > > > If this is proper, should we document it. If it is > improper, can we > > say why? > > Excellent question! > > If a callout server accepts application message and then just > forwards an adapted version elsewhere, it is not (should not > be) a callout server. It is an OPES processor! Thus, it is > absolutely proper to do that as long as the entity in > question does not pretend to be a callout server and obeys > all processor requirements. > > Here is what you get in that case: > > -- (SMTP) --> OPES --> (SMTP) --> OPES --> (SMTP) > processor 1 processor 2 > > Which is perfectly fine and is obviously beyond OCP scope > (OCP is not involved here). > > If, for some unnatural reason, the same thing is implemented > using OCP, it may still be OPES-legal as long as both OPES > agents know what they are doing: > > callout server > -- (SMTP) --> OPES --> (OCP) --> _and_ OPES --> (SMTP) > processor 1 processor 2 > > Essentially, "adaptation service" here means "I took care of > it, forget it". This is OK as long as processors cooperate. > Note that the callout server would be required to respond > with that "I took care of it" application message to its OPES > processor 1 (that application message/response will probably > have no payload though, just metadata). No need to documented > this convoluted case, IMO. > > A somewhat similar but more realistic example with an "I took > care of it" response would be a "black hole" service (e.g., a > SPAM filter): > > -- (SMTP) --> OPES --> (OCP) --> callout > processor 1 server > > The latter might be worth documenting in an "SMTP adaptation > using OPES" draft. > > HTH, > > Alex. > > > ------_=_NextPart_001_01C30016.1BDA9EFE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Shortcuts

Alex,

yes I agree with your assement.
This case is beyond OCP.(although in theory u can = still use OCP but the question is why?)

Should we call it distributed OPES processor (where = performance does not count)

abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Friday, April 11, 2003 12:03 AM
> To: ietf-openproxy@imc.org
> Subject: Re: Shortcuts
>
>
>
> On Thu, 10 Apr 2003, The Purple Streak, Hilarie = Orman wrote:
>
> > I had a returned thought on the issue of = whether or not data had to
> > complete the loop between the OPES = processor and the
> callout server.
> > If the proxied protocol is a = store-and-forward type, like
> SMTP, then
> > it seems that the callout server might, = quite properly, send
> > transformed messages directly to an = application endpoint
> (SMTP server)
> > without going back through the OPES = processor.
> >
> > If this is proper, should we document = it.  If it is
> improper, can we
> > say why?
>
> Excellent question!
>
> If a callout server accepts application message = and then just
> forwards an adapted version elsewhere, it is = not (should not
> be) a callout server. It is an OPES processor! = Thus, it is
> absolutely proper to do that as long as the = entity in
> question does not pretend to be a callout = server and obeys
> all processor requirements.
>
> Here is what you get in that case:
>
>  -- (SMTP) --> = OPES         --> (SMTP) = --> OPES        --> = (SMTP)
>          = ;      processor = 1            = ;     processor 2
>
> Which is perfectly fine and is obviously beyond = OCP scope
> (OCP is not involved here).
>
> If, for some unnatural reason, the same thing = is implemented
> using OCP, it may still be OPES-legal as long = as both OPES
> agents know what they are doing:
>
>          = ;            = ;            = ;         callout server
>  -- (SMTP) --> = OPES         --> (OCP) = --> _and_ OPES     --> (SMTP)
>          = ;      processor = 1            = ;    processor 2
>
> Essentially, "adaptation service" = here means "I took care of
> it, forget it". This is OK as long as = processors cooperate.
> Note that the callout server would be required = to respond
> with that "I took care of it" = application message to its OPES
> processor 1 (that application message/response = will probably
> have no payload though, just metadata). No need = to documented
> this convoluted case, IMO.
>
> A somewhat similar but more realistic example = with an "I took
> care of it" response would be a = "black hole" service (e.g., a
> SPAM filter):
>
>  -- (SMTP) --> = OPES         --> (OCP) = --> callout
>          = ;      processor = 1            = ;    server
>
> The latter might be worth documenting in an = "SMTP adaptation
> using OPES" draft.
>
> HTH,
>
> Alex.
>
>
>

------_=_NextPart_001_01C30016.1BDA9EFE-- From owner-ietf-openproxy@mail.imc.org Fri Apr 11 06:50:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06515 for ; Fri, 11 Apr 2003 06:50:56 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193vrN-0000uF-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 06:34:17 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193vrN-0000uB-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 06:34:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BAfSJM010762 for ; Fri, 11 Apr 2003 03:41:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BAfSj9010760 for ietf-openproxy-bks; Fri, 11 Apr 2003 03:41:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BAfRJM010754 for ; Fri, 11 Apr 2003 03:41:27 -0700 (PDT) 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 h3BAfFk05508; Fri, 11 Apr 2003 06:41:16 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Apr 2003 06:41:15 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754056BEC27@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: OCP Core version head_sid4 available Date: Fri, 11 Apr 2003 06:41:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30016.E02D41EE" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30016.E02D41EE Content-Type: text/plain see in line, abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, April 11, 2003 12:13 AM > To: ietf-openproxy@imc.org > Subject: Re: OCP Core version head_sid4 available SNIP > That is fine/unavoidable, I think. There are examples where > pipeline model does not (cannot) work all the way through. > Any example where the OPES processor does post-processing, > and that post-processing needs to know all adapted > response(s) before starting, will break pipeline at the OPES > processor. Note that > right on, we call this in the personalization drafts that we submitted before to OPES quality of delivery. Yes, it might break the pipeline. Abbie SNIP ------_=_NextPart_001_01C30016.E02D41EE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: OCP Core version head_sid4 available

see in line,
abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Friday, April 11, 2003 12:13 AM
> To: ietf-openproxy@imc.org
> Subject: Re: OCP Core version head_sid4 = available

SNIP

> That is fine/unavoidable, I think. There are = examples where
> pipeline model does not (cannot) work all the = way through.
> Any example where the OPES processor does = post-processing,
> and that post-processing needs to know all = adapted
> response(s) before starting, will break = pipeline at the OPES
> processor. Note that
>

right on, we call this in the personalization drafts = that we submitted before to OPES quality of delivery. Yes, it might = break the pipeline.

Abbie


SNIP

------_=_NextPart_001_01C30016.E02D41EE-- From owner-ietf-openproxy@mail.imc.org Fri Apr 11 09:05:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11078 for ; Fri, 11 Apr 2003 09:05:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193xxP-00022X-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 08:48:39 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193xxN-00022U-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 08:48:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BCuEJM020597 for ; Fri, 11 Apr 2003 05:56:14 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BCuDKU020596 for ietf-openproxy-bks; Fri, 11 Apr 2003 05:56:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BCuCJM020590 for ; Fri, 11 Apr 2003 05:56:12 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3BCu7vj012330; Fri, 11 Apr 2003 06:56:07 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3BCu7H4012329; Fri, 11 Apr 2003 06:56:07 -0600 (MDT) (envelope-from rousskov) Date: Fri, 11 Apr 2003 06:56:07 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP Core version head_sid4 available In-Reply-To: <200304110556.h3B5uRB26076@localhost.localdomain> Message-ID: References: <200304110556.h3B5uRB26076@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: On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > It's not that the OPES processor wants only one response, it's that it > needs to know, in advance, which reponses are coming. In fact, it may > need to cause early termination of some responses in order to manage > cache space. Same answer, I believe. You are constructing an example where it is impossible to avoid overheads if you assume no example-specific negotiation of some kind. Note, however, that it is possible to trade what you call "cache space" for reponse time and local bandwidth: assuming reproduceable responses, the OPES processor can send the same application message for adaptation twice; during the first attempt, it will terminate every adapted response after noting its metadata; during the second attempt, it will terminate all responses but the one(s) it preselected after the first attempt. Alex. > On Thu, 10 Apr 2003 at 22:13:05 -0600 (MDT) Alex Rousskov contended: > > > On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > > > I'm thinking of image conversion as an example, but anything with the > > > HTTP "vary" header more generally. If the requested OPES service is > > > something general, like "decrease image size", one could imagine the > > > service returning several responses, like "black and white", "300x400 > > > depth 3", etc. Or the service "translate to local language" might > > > return "french", "german", and "italian" in some places. The OPES > > > processor will look at the headers on the returned am's, looking for > > > something that matches the preferences of the user who caused the > > > content to be converted. Although more than one might be acceptable, > > > one might be best. Without knowing whether or not it's going to be > > > part of the transaction, the OPES processor would have to wait until > > > transaction close to send the result. > > > That is fine/unavoidable, I think. There are examples where pipeline > > model does not (cannot) work all the way through. Any example where > > the OPES processor does post-processing, and that post-processing > > needs to know all adapted response(s) before starting, will break > > pipeline at the OPES processor. Note that > > > (a) it does not break the protocol, just prevents > > certain optimizations > > (b) I cannot think of any optimization that is > > not supported by OCP but will work better that OCP > > here > > (c) OPES processor may relay user preferences to > > the callout server so that the serve can produce > > a single best response (if the server is smart > > enough to do that). This can be done via metadata, > > of course. From owner-ietf-openproxy@mail.imc.org Fri Apr 11 09:10:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11337 for ; Fri, 11 Apr 2003 09:10:59 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193y2u-00026N-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 08:54:20 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193y2u-00026K-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 08:54:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BD2dJM020842 for ; Fri, 11 Apr 2003 06:02:39 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BD2dWh020841 for ietf-openproxy-bks; Fri, 11 Apr 2003 06:02:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BD2bJM020837 for ; Fri, 11 Apr 2003 06:02:38 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3BD2Nvj012463; Fri, 11 Apr 2003 07:02:23 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3BD2NrQ012462; Fri, 11 Apr 2003 07:02:23 -0600 (MDT) (envelope-from rousskov) Date: Fri, 11 Apr 2003 07:02:23 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Shortcuts In-Reply-To: <200304110551.h3B5pct25850@localhost.localdomain> Message-ID: References: <200304110551.h3B5pct25850@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: On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > As has been mentioned before, because friends of OPES would like to > deal with OPES and its callout protocol for all content > transformation tasks. Just makes life easier. You have to provide a better (more detailed) motivation than that. In your specific example, sending the message to the next SMTP hop is actually "easier" than handling OCP. Moreover, any OPES processor that supports rule language would already have the functionality to send application messages to their next hop as opposed to a callout server -- it is a common case in real-world rule sets or ACLs, and we are not adding anything "new" here. Alex. > On Thu, 10 Apr 2003 at 21:57:26 -0400 Markus Hofmann mused: > > The Purple Streak, Hilarie Orman wrote: > > > > I had a returned thought on the issue of whether or not data had to > > > complete the loop between the OPES processor and the callout server. > > > If the proxied protocol is a store-and-forward type, like SMTP, then > > > it seems that the callout server might, quite properly, send > > > transformed messages directly to an application endpoint (SMTP server) > > > without going back through the OPES processor. > > > If that is the case, why would you need a callout protocol in the > > first place? Why wouldn't "OPES processor" and "callout server" talk > > SMTP between each other? "OPES processor" and "callout server" would > > just be two mail servers talking SMTP... > > > -Markus > From owner-ietf-openproxy@mail.imc.org Fri Apr 11 09:13:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11404 for ; Fri, 11 Apr 2003 09:13:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193y5T-000278-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 08:56:59 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 193y5S-000275-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 08:56:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BD6LJM020951 for ; Fri, 11 Apr 2003 06:06:21 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BD6LKS020950 for ietf-openproxy-bks; Fri, 11 Apr 2003 06:06:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BD6JJM020945 for ; Fri, 11 Apr 2003 06:06:20 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3BD6Kvj012569; Fri, 11 Apr 2003 07:06:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3BD6K6x012568; Fri, 11 Apr 2003 07:06:20 -0600 (MDT) (envelope-from rousskov) Date: Fri, 11 Apr 2003 07:06:20 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Shortcuts In-Reply-To: <87609AFB433BD5118D5E0002A52CD754056BEC1E@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754056BEC1E@zcard0k6.ca.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: On Fri, 11 Apr 2003, Abbie Barbir wrote: > Should we call it distributed OPES processor (where performance does > not count) I do not think there is anything special here that deserves a new name. It is simple a case of forwarding an application message to the next application protocol hop (possibly determined by processor rules). The first OPES processor would not even know that the second hop is an OPES processor. I do not see any performance penalty here either. The "black hole" case I described at the very end may be worth documenting somewhere though. Alex. > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Friday, April 11, 2003 12:03 AM > > To: ietf-openproxy@imc.org > > Subject: Re: Shortcuts > > > > > > > > On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > > > > I had a returned thought on the issue of whether or not data had to > > > complete the loop between the OPES processor and the > > callout server. > > > If the proxied protocol is a store-and-forward type, like > > SMTP, then > > > it seems that the callout server might, quite properly, send > > > transformed messages directly to an application endpoint > > (SMTP server) > > > without going back through the OPES processor. > > > > > > If this is proper, should we document it. If it is > > improper, can we > > > say why? > > > > Excellent question! > > > > If a callout server accepts application message and then just > > forwards an adapted version elsewhere, it is not (should not > > be) a callout server. It is an OPES processor! Thus, it is > > absolutely proper to do that as long as the entity in > > question does not pretend to be a callout server and obeys > > all processor requirements. > > > > Here is what you get in that case: > > > > -- (SMTP) --> OPES --> (SMTP) --> OPES --> (SMTP) > > processor 1 processor 2 > > > > Which is perfectly fine and is obviously beyond OCP scope > > (OCP is not involved here). > > > > If, for some unnatural reason, the same thing is implemented > > using OCP, it may still be OPES-legal as long as both OPES > > agents know what they are doing: > > > > callout server > > -- (SMTP) --> OPES --> (OCP) --> _and_ OPES --> (SMTP) > > processor 1 processor 2 > > > > Essentially, "adaptation service" here means "I took care of > > it, forget it". This is OK as long as processors cooperate. > > Note that the callout server would be required to respond > > with that "I took care of it" application message to its OPES > > processor 1 (that application message/response will probably > > have no payload though, just metadata). No need to documented > > this convoluted case, IMO. > > > > A somewhat similar but more realistic example with an "I took > > care of it" response would be a "black hole" service (e.g., a > > SPAM filter): > > > > -- (SMTP) --> OPES --> (OCP) --> callout > > processor 1 server > > > > The latter might be worth documenting in an "SMTP adaptation > > using OPES" draft. > > > > HTH, > > > > Alex. > > > > > > > From owner-ietf-openproxy@mail.imc.org Fri Apr 11 13:19:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21989 for ; Fri, 11 Apr 2003 13:19:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1942E2-0004P4-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 13:22:06 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1942E1-0004P1-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 13:22:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BH9OJM005522 for ; Fri, 11 Apr 2003 10:09:25 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BH9Oun005521 for ietf-openproxy-bks; Fri, 11 Apr 2003 10:09:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BH9NJM005517 for ; Fri, 11 Apr 2003 10:09:24 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3BHBwKq017162; Fri, 11 Apr 2003 11:11:59 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3BH8fu27008; Fri, 11 Apr 2003 11:08:41 -0600 Date: Fri, 11 Apr 2003 11:08:41 -0600 Message-Id: <200304111708.h3BH8fu27008@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: Shortcuts Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's desirable to avoid the round-trip latency whenever possible. It seems eminently possible and sensible to do this for SMTP. That lets one have an architecture with a centralized content-driven dispatcher (OPES processor) but without round-trip latency between the OPES processor and the callout server. Hilarie On Fri, 11 Apr 2003 at 07:02:23 -0600 (MDT) Alex Rousskov murmured: > On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > As has been mentioned before, because friends of OPES would like to > > deal with OPES and its callout protocol for all content > > transformation tasks. Just makes life easier. > You have to provide a better (more detailed) motivation than that. In > your specific example, sending the message to the next SMTP hop is > actually "easier" than handling OCP. Moreover, any OPES processor that > supports rule language would already have the functionality to send > application messages to their next hop as opposed to a callout server > -- it is a common case in real-world rule sets or ACLs, and we are not > adding anything "new" here. > Alex. > > On Thu, 10 Apr 2003 at 21:57:26 -0400 Markus Hofmann mused: > > > The Purple Streak, Hilarie Orman wrote: > > > > > > I had a returned thought on the issue of whether or not data had to > > > > complete the loop between the OPES processor and the callout server. > > > > If the proxied protocol is a store-and-forward type, like SMTP, then > > > > it seems that the callout server might, quite properly, send > > > > transformed messages directly to an application endpoint (SMTP server) > > > > without going back through the OPES processor. > > > > > If that is the case, why would you need a callout protocol in the > > > first place? Why wouldn't "OPES processor" and "callout server" talk > > > SMTP between each other? "OPES processor" and "callout server" would > > > just be two mail servers talking SMTP... > > > > > -Markus > > From owner-ietf-openproxy@mail.imc.org Fri Apr 11 13:36:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22403 for ; Fri, 11 Apr 2003 13:36:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1942UD-0004VS-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 13:38:49 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1942UC-0004VP-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 13:38:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHPnJM006044 for ; Fri, 11 Apr 2003 10:25:49 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BHPngt006043 for ietf-openproxy-bks; Fri, 11 Apr 2003 10:25:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BHPlJM006034 for ; Fri, 11 Apr 2003 10:25:47 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3BHPmvj018613; Fri, 11 Apr 2003 11:25:48 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3BHPmN9018612; Fri, 11 Apr 2003 11:25:48 -0600 (MDT) (envelope-from rousskov) Date: Fri, 11 Apr 2003 11:25:48 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Shortcuts In-Reply-To: <200304111708.h3BH8fu27008@localhost.localdomain> Message-ID: References: <200304111708.h3BH8fu27008@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: On Fri, 11 Apr 2003, The Purple Streak, Hilarie Orman wrote: > It's desirable to avoid the round-trip latency whenever possible. It > seems eminently possible and sensible to do this for SMTP. That lets > one have an architecture with a centralized content-driven dispatcher > (OPES processor) but without round-trip latency between the OPES > processor and the callout server. There is no round-trip latency in a simple implementation of your example: There is no callout server and OCP. There is no "bump on the wire" to introduce that latency. There are just two sequential hops (two OPES processors) on the wire, pipelining as fast as they can. If you insist on using OCP and a callout server, then there is still no extra round-trip latency as long as both OPES processor and the callout server can handle "I took care of it, forget it" mode of operation that I described earlier. No modifications to OCP core are required to support that mode on per-application basis. That mode may be useful to implement black holes, for example (but I am repeating myself). Do you think we should add explicit "I took care of it, forget it" support to OCP Core? Even though some connection-oriented application protocols like HTTP cannot "forget" a message on a protocol level? Thanks, Alex. > On Fri, 11 Apr 2003 at 07:02:23 -0600 (MDT) Alex Rousskov murmured: > > On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > > > As has been mentioned before, because friends of OPES would like to > > > deal with OPES and its callout protocol for all content > > > transformation tasks. Just makes life easier. > > > You have to provide a better (more detailed) motivation than that. In > > your specific example, sending the message to the next SMTP hop is > > actually "easier" than handling OCP. Moreover, any OPES processor that > > supports rule language would already have the functionality to send > > application messages to their next hop as opposed to a callout server > > -- it is a common case in real-world rule sets or ACLs, and we are not > > adding anything "new" here. > > > Alex. > > > > On Thu, 10 Apr 2003 at 21:57:26 -0400 Markus Hofmann mused: > > > > The Purple Streak, Hilarie Orman wrote: > > > > > > > > I had a returned thought on the issue of whether or not data had to > > > > > complete the loop between the OPES processor and the callout server. > > > > > If the proxied protocol is a store-and-forward type, like SMTP, then > > > > > it seems that the callout server might, quite properly, send > > > > > transformed messages directly to an application endpoint (SMTP server) > > > > > without going back through the OPES processor. > > > > > > > If that is the case, why would you need a callout protocol in the > > > > first place? Why wouldn't "OPES processor" and "callout server" talk > > > > SMTP between each other? "OPES processor" and "callout server" would > > > > just be two mail servers talking SMTP... > > > > > > > -Markus > > > > From owner-ietf-openproxy@mail.imc.org Fri Apr 11 15:00:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24698 for ; Fri, 11 Apr 2003 15:00:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1943o1-0004x0-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 15:03:21 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1943o1-0004wx-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 15:03:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BInGJM010182 for ; Fri, 11 Apr 2003 11:49:16 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BInG1I010181 for ietf-openproxy-bks; Fri, 11 Apr 2003 11:49:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BInFJM010176 for ; Fri, 11 Apr 2003 11:49:15 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3BIppKq020374; Fri, 11 Apr 2003 12:51:51 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3BImQR31975; Fri, 11 Apr 2003 12:48:26 -0600 Date: Fri, 11 Apr 2003 12:48:26 -0600 Message-Id: <200304111848.h3BImQR31975@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: Shortcuts Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I don't think any changes are necessary for OCP. Not even "I took care of it". The only question is whether or not we need to document shortcuts somewhere - ideally it would have been in the architecture document, I suppose. There are at least two cases for shortcuts, redirects and cut-throughs; are there more? Can we get agreement on wording about when a shortcut is OK and when not, where should we put the wording? I think shortcuts are generally very difficult for streaming protocols, by the way. I'd like to hear differently, if there are streaming experts out there. Hilarie From owner-ietf-openproxy@mail.imc.org Fri Apr 11 15:46:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27327 for ; Fri, 11 Apr 2003 15:46:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1944WP-0005Dt-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 15:49:13 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1944WO-0005Dp-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 15:49:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJawJM012577 for ; Fri, 11 Apr 2003 12:36:58 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BJawV5012576 for ietf-openproxy-bks; Fri, 11 Apr 2003 12:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BJauJM012567 for ; Fri, 11 Apr 2003 12:36:56 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3BJavvj022715; Fri, 11 Apr 2003 13:36:57 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3BJavaf022714; Fri, 11 Apr 2003 13:36:57 -0600 (MDT) (envelope-from rousskov) Date: Fri, 11 Apr 2003 13:36:57 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Shortcuts In-Reply-To: <200304111848.h3BImQR31975@localhost.localdomain> Message-ID: References: <200304111848.h3BImQR31975@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: On Fri, 11 Apr 2003, The Purple Streak, Hilarie Orman wrote: > I don't think any changes are necessary for OCP. Not even "I took > care of it". The only question is whether or not we need to > document shortcuts somewhere - ideally it would have been in the > architecture document, I suppose. There are at least two cases for > shortcuts, redirects and cut-throughs; are there more? Can we get > agreement on wording about when a shortcut is OK and when not, where > should we put the wording? What would be the purpose of documenting a shortcut if no protocol changes are required to support it? The purpose would determine whether documentation is needed and where it should be placed, IMO. If you want to document shortcuts (on high level) to illustrate OPES architecture power, the architecture draft or use cases draft is the place. If you want to document (in detail) a nice trick that may come in handy for some, a separate document would be more appropriate, IMO. Other reasons? OCP Core does not seem like the right place since OCP may not be involved in some of these shortcuts and since they might be application-specific. Alex. From owner-ietf-openproxy@mail.imc.org Fri Apr 11 17:06:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00510 for ; Fri, 11 Apr 2003 17:06:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1945lj-0005vk-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 17:09:07 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1945li-0005vh-00 for opes-archive@ietf.org; Fri, 11 Apr 2003 17:09:07 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKwKJM018054 for ; Fri, 11 Apr 2003 13:58:20 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BKwKfo018053 for ietf-openproxy-bks; Fri, 11 Apr 2003 13:58:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BKwJJM018049 for ; Fri, 11 Apr 2003 13:58:19 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3BKwLvj024628; Fri, 11 Apr 2003 14:58:21 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3BKwL8e024627; Fri, 11 Apr 2003 14:58:21 -0600 (MDT) (envelope-from rousskov) Date: Fri, 11 Apr 2003 14:58:21 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: a question ONES again? In-Reply-To: <5.2.0.9.0.20030406192433.03477ec0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030406192433.03477ec0@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: On Sun, 6 Apr 2003, jfcm wrote: > But the real point is that it shows a totally different logical > model and a different philiosophy of protocol. We have a fast pipe > with bypasses and loops. And no callout protocol. An OPES system does not require the use of OCP. OPES processor can use other means to adapt content, including adapting content using processor's internal resources/code. OCP is just something generally (but not universally) useful that we want to standardize, besides other things that are OCP-independent (like tracing and bypass). Thus, I do not see any "totally different" logical model or philosophy in your example. What is the difference between a chain/mesh of OPES processors and the model you describe? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Sat Apr 12 04:43:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24076 for ; Sat, 12 Apr 2003 04:43:56 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Gee-0000iJ-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 04:46:32 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 194Gee-0000iG-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 04:46:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C8aAJM009873 for ; Sat, 12 Apr 2003 01:36:10 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C8aAZE009872 for ietf-openproxy-bks; Sat, 12 Apr 2003 01:36:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.9/8.11.6) with SMTP id h3C8a8JM009850 for ; Sat, 12 Apr 2003 01:36:09 -0700 (PDT) Received: from hermes.webwasher.com [192.168.1.3] id 6E0BBKMZ; 12 Apr 2003 10:36:04 +0200 Received: from jb2xg0j ([80.187.13.178]) by hermes.webwasher.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 12 Apr 2003 10:32:40 +0200 Reply-To: From: "Frank Berzau" To: , Subject: ICAP RFC available Date: Sat, 12 Apr 2003 10:35:42 +0200 Organization: webwasher.com Message-ID: <000301c300ce$8aea4de0$0000fea9@jb2xg0j> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 12 Apr 2003 08:32:41.0828 (UTC) FILETIME=[155E7240:01C300CE] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Finally, the ICAP RFC has been published. See http://www.ietf.org/rfc/rfc3507.txt. Thanks, Frank From owner-ietf-openproxy@mail.imc.org Sat Apr 12 08:08:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26044 for ; Sat, 12 Apr 2003 08:08:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Jqx-00016l-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 08:11:27 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 194Jqw-00016i-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 08:11:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CBxJJM026833 for ; Sat, 12 Apr 2003 04:59:19 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CBxJAL026831 for ietf-openproxy-bks; Sat, 12 Apr 2003 04:59:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2] (may be forged)) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CBxHJM026817 for ; Sat, 12 Apr 2003 04:59:17 -0700 (PDT) Received: from f08v-8-153.d1.club-internet.fr ([212.194.163.153] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 194Jex-0002PR-00; Sat, 12 Apr 2003 04:59:04 -0700 Message-Id: <5.2.0.9.0.20030412121806.04794ec0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 12 Apr 2003 12:19:30 +0200 To: Markus Hofmann From: jfcm Subject: Re: Shortcuts Cc: ietf-openproxy@imc.org In-Reply-To: <3E962106.6080608@mhof.com> References: <200304102320.h3ANKse07094@localhost.localdomain> <200304102320.h3ANKse07094@localhost.localdomain> 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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 03:57 11/04/03, Markus Hofmann wrote: >The Purple Streak, Hilarie Orman wrote: > >>I had a returned thought on the issue of whether or not data had to >>complete the loop between the OPES processor and the callout server. >>If the proxied protocol is a store-and-forward type, like SMTP, then >>it seems that the callout server might, quite properly, send >>transformed messages directly to an application endpoint (SMTP server) >>without going back through the OPES processor. > >If that is the case, why would you need a callout protocol in the first >place? Why wouldn't "OPES processor" and "callout server" talk SMTP >between each other? "OPES processor" and "callout server" would just be >two mail servers talking SMTP... Absolutely true. This is a daisy chaining model. This is not excluding any other model. This is not exlusing callout protocol additions in metadata. jfc From owner-ietf-openproxy@mail.imc.org Sat Apr 12 08:08:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26059 for ; Sat, 12 Apr 2003 08:08:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Jqz-00016s-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 08:11:29 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 194Jqy-00016o-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 08:11:28 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CBxoJM026930 for ; Sat, 12 Apr 2003 04:59:50 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CBxoEF026929 for ietf-openproxy-bks; Sat, 12 Apr 2003 04:59:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2] (may be forged)) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CBxnJM026918 for ; Sat, 12 Apr 2003 04:59:49 -0700 (PDT) Received: from f08v-8-153.d1.club-internet.fr ([212.194.163.153] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 194Jf2-0002PR-00; Sat, 12 Apr 2003 04:59:08 -0700 Message-Id: <5.2.0.9.0.20030412122928.047c4cc0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 12 Apr 2003 12:33:05 +0200 To: Alex Rousskov , ietf-openproxy@imc.org From: jfcm Subject: Re: a question ONES again? In-Reply-To: References: <5.2.0.9.0.20030406192433.03477ec0@mail.utel.net> <5.2.0.9.0.20030406192433.03477ec0@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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 22:58 11/04/03, Alex Rousskov wrote: >On Sun, 6 Apr 2003, jfcm wrote: > > But the real point is that it shows a totally different logical > > model and a different philiosophy of protocol. We have a fast pipe > > with bypasses and loops. And no callout protocol. > >An OPES system does not require the use of OCP. OPES processor can use >other means to adapt content, including adapting content using >processor's internal resources/code. OCP is just something generally >(but not universally) useful that we want to standardize, besides >other things that are OCP-independent (like tracing and bypass). > >Thus, I do not see any "totally different" logical model or >philosophy in your example. What is the difference between a >chain/mesh of OPES processors and the model you describe? Totally different is may be too big a word. However in my present OPES model understanding it is, but I may be wrong. This is due to the lack of proper layer modelization. Why would two chained OPES have necessarily to fall down to http level and not to chose to stay at callout protocol level? jfc From owner-ietf-openproxy@mail.imc.org Sat Apr 12 08:08:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26070 for ; Sat, 12 Apr 2003 08:08:55 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Jqz-00016x-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 08:11:29 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 194Jqy-00016p-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 08:11:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CBxxJM026955 for ; Sat, 12 Apr 2003 04:59:59 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CBxx5S026954 for ietf-openproxy-bks; Sat, 12 Apr 2003 04:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2] (may be forged)) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CBxnJM026917 for ; Sat, 12 Apr 2003 04:59:49 -0700 (PDT) Received: from f08v-8-153.d1.club-internet.fr ([212.194.163.153] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 194Jf0-0002PR-00; Sat, 12 Apr 2003 04:59:07 -0700 Message-Id: <5.2.0.9.0.20030412122449.04794b00@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 12 Apr 2003 12:27:20 +0200 To: "The Purple Streak, Hilarie Orman" , rousskov@measurement-factory.com From: jfcm Subject: Re: Shortcuts Cc: ietf-openproxy@imc.org In-Reply-To: <200304111848.h3BImQR31975@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 20:48 11/04/03, The Purple Streak, Hilarie Orman wrote: >There are at least two cases for shortcuts, redirects and cut-throughs; >are there more? Stops. Let imagine an anti-spam system based unpon origin verification (calls the origin to checj an ID key is consistent). 1. the key is positive: I can short-cut to the pop server. 2. the key is not answered because there is no checking service, I redirect to another filtering system 3. the key is negative I kill the mail. jfc From owner-ietf-openproxy@mail.imc.org Sat Apr 12 08:08:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26089 for ; Sat, 12 Apr 2003 08:08:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Jr3-000173-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 08:11:33 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 194Jr2-000170-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 08:11:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CBxJJM026832 for ; Sat, 12 Apr 2003 04:59:19 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CBxJHv026830 for ietf-openproxy-bks; Sat, 12 Apr 2003 04:59:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2] (may be forged)) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CBxHJM026818 for ; Sat, 12 Apr 2003 04:59:18 -0700 (PDT) Received: from f08v-8-153.d1.club-internet.fr ([212.194.163.153] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 194Jev-0002PR-00; Sat, 12 Apr 2003 04:59:01 -0700 Message-Id: <5.2.0.9.0.20030412115938.047c0380@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 12 Apr 2003 12:13:09 +0200 To: "The Purple Streak, Hilarie Orman" From: jfcm Subject: Re: Charter issues Cc: ietf-openproxy@imc.org In-Reply-To: <200304102221.h3AMLCU04276@localhost.localdomain> 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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 00:21 11/04/03, The Purple Streak, Hilarie Orman said: >My impression was that we would have guidelines, but the only thing that >would really be standardized would be a callout protocol and tracing >support. What's the group opinion? As indicated several times I consider that the callout protocol is NO part of the OPES concept. It is a convenient way for Service providers to operate WITHIN the common processing of an OPES. If the callout protocol is above transportation layers it can be a framework for inter service applications. If there are transport layers proposing faster, more secure and more efficient solutions than TCP/IP this will be of interest to create "network black hole" provinding a faster, more secure and more efficient service than TCP/IP. All the issues you point out are far more important as far as service operations and provisions are concerned. And, again, their organization depend very much on an OPES/ONES modelization first. As pointed out still recently the model we use (dispatcher/call-out protocol/call-out servers) can only be a part of the OPES chain, even when this architecture is used, because both ends can use it. This would create already a daisy chaining and the temptation of a direct call-out relation between these two, without getting down at http; smtp etc. protocol. I feel this results from the "proxy" image whch made the proxy server to be considered as a front-end dispatcher, ie performing an OPES level of tasks (hence the OPES Procesor wording as a machine in front of the Content Server). A true architecture is dasy chaining along the transport or querry/response path. With all the points you rise. IMHO at least. jfc From owner-ietf-openproxy@mail.imc.org Sat Apr 12 10:22:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28789 for ; Sat, 12 Apr 2003 10:22:51 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Lwc-0001TR-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 10:25:27 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 194Lwc-0001TO-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 10:25:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CEFVJM004878 for ; Sat, 12 Apr 2003 07:15:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CEFVuZ004877 for ietf-openproxy-bks; Sat, 12 Apr 2003 07:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3CEFUJM004873 for ; Sat, 12 Apr 2003 07:15:30 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h3CEFVvj051707; Sat, 12 Apr 2003 08:15:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3CEFVDx051706; Sat, 12 Apr 2003 08:15:31 -0600 (MDT) (envelope-from rousskov) Date: Sat, 12 Apr 2003 08:15:31 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: a question ONES again? In-Reply-To: <5.2.0.9.0.20030412122928.047c4cc0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030406192433.03477ec0@mail.utel.net> <5.2.0.9.0.20030406192433.03477ec0@mail.utel.net> <5.2.0.9.0.20030412122928.047c4cc0@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: On Sat, 12 Apr 2003, jfcm wrote: > At 22:58 11/04/03, Alex Rousskov wrote: > >On Sun, 6 Apr 2003, jfcm wrote: > > > But the real point is that it shows a totally different logical > > > model and a different philiosophy of protocol. We have a fast pipe > > > with bypasses and loops. And no callout protocol. > > > >An OPES system does not require the use of OCP. OPES processor can use > >other means to adapt content, including adapting content using > >processor's internal resources/code. OCP is just something generally > >(but not universally) useful that we want to standardize, besides > >other things that are OCP-independent (like tracing and bypass). > > > >Thus, I do not see any "totally different" logical model or > >philosophy in your example. What is the difference between a > >chain/mesh of OPES processors and the model you describe? > > Totally different is may be too big a word. However in my present > OPES model understanding it is, but I may be wrong. This is due > to the lack of proper layer modelization. Why would two chained > OPES have necessarily to fall down to http level and not to chose > to stay at callout protocol level? The answer is very simple: an OPES processor will proxy application protocol (e.g., HTTP) instead of "branching out" using the callout protocol (e.g., OCP) when the processor is not interested in the result of the adaptation that the next hop (the chained OPES processor) will perform. These kinds of decisions are usually done when interpreting the rules at the first processor. Thus, the decision is really done by whoever writes the processing rules. Alex. From owner-ietf-openproxy@mail.imc.org Sat Apr 12 14:16:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01572 for ; Sat, 12 Apr 2003 14:16:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Paw-00024b-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 14:19:18 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 194Paw-00024Y-00 for opes-archive@ietf.org; Sat, 12 Apr 2003 14:19:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CI82JM018850 for ; Sat, 12 Apr 2003 11:08:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CI829o018849 for ietf-openproxy-bks; Sat, 12 Apr 2003 11:08:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CI80JM018845 for ; Sat, 12 Apr 2003 11:08:00 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3CIAqKq026897; Sat, 12 Apr 2003 12:10:53 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3CI7A721643; Sat, 12 Apr 2003 12:07:10 -0600 Date: Sat, 12 Apr 2003 12:07:10 -0600 Message-Id: <200304121807.h3CI7A721643@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: frank@webwasher.com Cc: icap-discussions@yahoogroups.com, ietf-openproxy@imc.org In-reply-to: Yourmessage <000301c300ce$8aea4de0$0000fea9@jb2xg0j> Subject: Re: ICAP RFC available Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It would have been polite of the editor to check the contact info before publishing. Hilarie From owner-ietf-openproxy@mail.imc.org Mon Apr 14 03:48:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27215 for ; Mon, 14 Apr 2003 03:48:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194ykK-0000X9-00 for opes-archive@ietf.org; Mon, 14 Apr 2003 03:51:20 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 194ykK-0000X5-00 for opes-archive@ietf.org; Mon, 14 Apr 2003 03:51:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E7bK1r025150 for ; Mon, 14 Apr 2003 00:37:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E7bKXN025149 for ietf-openproxy-bks; Mon, 14 Apr 2003 00:37:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from cirse.saclay.cea.fr (cirse.saclay.cea.fr [132.166.192.127]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E7bI1r025137 for ; Mon, 14 Apr 2003 00:37:19 -0700 (PDT) (envelope-from basile.starynkevitch@cea.fr) Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.saclay.cea.fr (8.12.9/CEAnet-Internet.1.0) with ESMTP id h3E7b53B008994 for ; Mon, 14 Apr 2003 09:37:05 +0200 (MEST) Received: from muguet.saclay.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Mon, 14 Apr 2003 09:36:49 +0200 Received: from aigle.saclay.cea.fr (aigle.saclay.cea.fr [132.166.132.1]) by muguet.saclay.cea.fr (8.12.9/CEAnet-Interne.1.0) with ESMTP id h3E7b4lO016068; Mon, 14 Apr 2003 09:37:04 +0200 (MEST) Received: from is002258.saclay.cea.fr by aigle.saclay.cea.fr (8.8.8+Sun/CEANET.2.0.1) id JAA20923; Mon, 14 Apr 2003 09:35:09 +0200 (MET DST) Received: from basile by is002258.saclay.cea.fr with local (Exim 4.12) id 194yWV-0003AD-00; Mon, 14 Apr 2003 09:37:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16026.25887.781075.164881@is002258.saclay.cea.fr> Date: Mon, 14 Apr 2003 09:37:03 +0200 To: ICAP-Discussions@yahoogroups.com Cc: Subject: [ICAP-Discussions] ICAP RFC available In-Reply-To: <000301c300ce$8aea4de0$0000fea9@jb2xg0j> References: <000301c300ce$8aea4de0$0000fea9@jb2xg0j> X-Mailer: VM 7.14 under Emacs 21.2.2 From: Basile STARYNKEVITCH Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h3E7bK1r025150 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA27215 >>>>> "Frank" == Frank Berzau writes: Frank> Finally, the ICAP RFC has been published. See Frank> http://www.ietf.org/rfc/rfc3507.txt. Thanks. Is there any significant differences with http://www.i-cap.org/spec/icap_specification.txt? Apparently, there is no major difference (except of course in the text formatting). -- N.B. Any opinions expressed here are only mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. --------------------------------------------------------------------- Basile STARYNKEVITCH ---- Commissariat à l Energie Atomique * France DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359 work email: Basile point Starynkevitch at cea point fr home email: Basile at Starynkevitch point net From owner-ietf-openproxy@mail.imc.org Mon Apr 14 06:04:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29586 for ; Mon, 14 Apr 2003 06:04:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1950rc-00016H-00 for opes-archive@ietf.org; Mon, 14 Apr 2003 06:07:00 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1950rc-00016E-00 for opes-archive@ietf.org; Mon, 14 Apr 2003 06:07:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E9hJ1r039778 for ; Mon, 14 Apr 2003 02:43:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E9hJ8A039777 for ietf-openproxy-bks; Mon, 14 Apr 2003 02:43:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3E9gh1r039767 for ; Mon, 14 Apr 2003 02:43:16 -0700 (PDT) (envelope-from frank@webwasher.com) Received: from hermes.webwasher.com [192.168.1.3] id MBEBWJQI; 14 Apr 2003 11:42:28 +0200 Received: from jb2xg0j ([80.152.6.130]) by hermes.webwasher.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Apr 2003 11:39:05 +0200 Reply-To: From: "Frank Berzau" To: Cc: Subject: RE: [ICAP-Discussions] ICAP RFC available Date: Mon, 14 Apr 2003 11:42:21 +0200 Organization: webwasher.com Message-ID: <001b01c3026a$26e7f2f0$0140a8c0@jb2xg0j> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <16026.25887.781075.164881@is002258.saclay.cea.fr> X-OriginalArrivalTime: 14 Apr 2003 09:39:05.0359 (UTC) FILETIME=[B09089F0:01C30269] X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h3E9hH1r039772 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h3E9hJ1r039778 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA29586 No, there aren't any. The RFC that has now been published is simply documenting current practice, and the old draft has been published as is (with minor changes in format and I think some very few changes in wording. but no changes to the specs itself). What has changed is that some vendors have added support for additional features by adding x-headers. These are documented for the first time in Martin's draft (The draft should be available within the next days as draft-stecher-icap-subid-00 from http://www.ietf.org/internet-drafts/draft-stecher-icap-subid-00.txt. If you cannot wait you can download a copy here too: http://www.martin-stecher.de/draft-stecher-icap-subid-00.txt). These are not changing the standard in any way, so there was no need to add this to the paper before publishing the RFC. Martin's paper is simply an attempt to document current practice and allow implementors to add support so they can work with some of the additions that are available in implemtations today. Thanks, Frank > -----Original Message----- > From: Basile STARYNKEVITCH [mailto:basile.starynkevitch@cea.fr] > Sent: Monday, April 14, 2003 9:37 AM > To: ICAP-Discussions@yahoogroups.com > Cc: ietf-openproxy@imc.org > Subject: [ICAP-Discussions] ICAP RFC available > > > >>>>> "Frank" == Frank Berzau writes: > > Frank> Finally, the ICAP RFC has been published. See > Frank> http://www.ietf.org/rfc/rfc3507.txt. > > Thanks. > > Is there any significant differences with > http://www.i-> cap.org/spec/icap_specification.txt? > > > Apparently, there is > no major difference (except of course in the text formatting). > > > -- > > N.B. Any opinions expressed here are only mine, and not of my > organization. N.B. Les opinions exprimees ici me sont > personnelles et n engagent pas le CEA. > > --------------------------------------------------------------------- > Basile STARYNKEVITCH ---- Commissariat à l Energie > Atomique * France > DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX > phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; > mobile: 6,8501.2359 work email: Basile point Starynkevitch at > cea point fr > home email: Basile at Starynkevitch point net > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> Get 128 Bit SSL Encryption! > http://us.click.yahoo.com/W7NydA/hdqFAA/VygGAA> /h6uqlB/TM > > > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > ICAP-Discussions-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > From owner-ietf-openproxy@mail.imc.org Tue Apr 15 18:28:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14970 for ; Tue, 15 Apr 2003 18:28:25 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Yx6-00056N-00 for opes-archive@ietf.org; Tue, 15 Apr 2003 18:30:56 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195Yx5-00056J-00 for opes-archive@ietf.org; Tue, 15 Apr 2003 18:30:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FMHrt2095554 for ; Tue, 15 Apr 2003 15:17:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FMHr0w095553 for ietf-openproxy-bks; Tue, 15 Apr 2003 15:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FMHqt2095548 for ; Tue, 15 Apr 2003 15:17:52 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3FMLgKq012778; Tue, 15 Apr 2003 16:21:43 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3FMJQj25493; Tue, 15 Apr 2003 16:19:26 -0600 Date: Tue, 15 Apr 2003 16:19:26 -0600 Message-Id: <200304152219.h3FMJQj25493@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org Subject: OCP questions Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've been going over the callout protocol requirements and OCP, and find them in generally good agreement. I don't fully understand the requirements, though and have a couple of questions about them and OCP. First, I know I asked about whether or not a transaction was supposed to be kept on a single connection, but I cannot find my question or the answer in any archive, so, annoyingly to everyone, including myself, I need to ask again. If I am reading things correctly, the requirements allow several "connections" over one transport connection, but OCP forbids it. Is there disagreement? If not, which notion is correct? The requirements mention "keep-alives" and "heartbeats". Was there any intent to require heartbeat support? OCP does not use them, which is fine with me. Reviewing the messages on this list, I find myself deeply uncertain about what would be in "OCP/HTTP bindings". Would it be an encoding of the OCP protocol elements (transaction start, transaction id, etc.) as HTTP-style headers? In order to allow someone to write an Apache module for OCP and make use of the HTTP header parsing libraries, for example? And bring in all the baggage about chunking? If so, we need to state this somewhere, and say why we are doing this, rather than defining protocol-independent bindings. The "application agnostic" stuff seems to lead one to expect protocol-independent metadata. This is why I am deeply confused. Further, if there is a truly application independent encoding, say, for mime parts, then why not just use this as the single encoding? At one time it was very important to use HTTP bindings for this code reuse purpose, but I'm not sure that is still the case. Can we document a decision on this point? OCP's negotiation section hints at a rich set of operations; do we need more than the usual "here's my menu" and "here's my selection from your menu" ? I confess to not understanding the big diagram in OCP; it may be an elegant way to convey information, if I only understood it. Where are the "data have" messages? Are those "OCP messages" in the last box? What are "connection C" and "connection G" ? I cannot keep myself from stumbling over "application message" time and again. And again. The stuff between the OPES processor and callout server that might be encapsulated data coming from or going to the proxied transaction ... can that have an unambiguous name, like "zinc", if there's nothing better? Hilarie From owner-ietf-openproxy@mail.imc.org Tue Apr 15 19:08:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15949 for ; Tue, 15 Apr 2003 19:08:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195ZaF-0005HU-00 for opes-archive@ietf.org; Tue, 15 Apr 2003 19:11:23 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195ZaE-0005HR-00 for opes-archive@ietf.org; Tue, 15 Apr 2003 19:11:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FMv9t2097685 for ; Tue, 15 Apr 2003 15:57:09 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FMv97W097684 for ietf-openproxy-bks; Tue, 15 Apr 2003 15:57:09 -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.8p1/8.12.8) with ESMTP id h3FMv8t2097679 for ; Tue, 15 Apr 2003 15:57:08 -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 h3FMv4vj074291; Tue, 15 Apr 2003 16:57:04 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3FMv4Z9074290; Tue, 15 Apr 2003 16:57:04 -0600 (MDT) (envelope-from rousskov) Date: Tue, 15 Apr 2003 16:57:04 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP questions In-Reply-To: <200304152219.h3FMJQj25493@localhost.localdomain> Message-ID: References: <200304152219.h3FMJQj25493@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: On Tue, 15 Apr 2003, The Purple Streak, Hilarie Orman wrote: > First, I know I asked about whether or not a transaction was > supposed to be kept on a single connection, but I cannot find my > question or the answer in any archive, so, annoyingly to everyone, > including myself, I need to ask again. IMO, the requirements draft semi-implies that a single transaction cannot cross connection boundaries. OCP Core follows the same principle though we need to explicitly document this fact (added to the todo list). OCP Core will allow certain OCP messages with xid to be sent on several connections to support fast-abort and similar optimizations (you may recall a thread about it on this list). The latter feature is the "fast track" item on the todo list. > If I am reading things correctly, the requirements allow several > "connections" over one transport connection, but OCP forbids it. > Is there disagreement? If not, which notion is correct? OCP Core does not forbid several OCP connection over one transport connection (bugs notwithstanding). OCP Core says, in part ("Connections" section, blob 87): If BEEP over TCP is used, than a BEEP channel will correspond to a callout connection, allowing callout connection multiplexing over a single TCP connection. What made you think that "OCP forbids it"? > The requirements mention "keep-alives" and "heartbeats". Was there > any intent to require heartbeat support? OCP does not use them, > which is fine with me. OCP Core supports heartbeats via and messages. Those are actually very useful because OCP Core relies on timeouts to resolve possible problems with overloaded or malfunctioning agents and timeouts without heartbeats do not work well for "slow" adaptations. > Reviewing the messages on this list, I find myself deeply uncertain > about what would be in "OCP/HTTP bindings". Would it be an encoding > of the OCP protocol elements (transaction start, transaction id, > etc.) as HTTP-style headers? You may be confusing/mixing OCP transport binding and application-specific drafts. We have not decided on OCP transport binding. In theory, it can be HTTP like in ICAP. If that is the case, then either OCP Core (if there is only one transport binding) or HTTP Transport Binding for OCP (if there are multiple transport bindings) drafts will indeed document how to convert OCP protocol elements to HTTP elements. On the other hand, if OCP transport binding is, say, BEEP, then there is no need to convert OCP protocol elements to HTTP elements. There is a need to document how OCP protocol elements are encoded within BEEP channels, of course. > In order to allow someone to write an Apache module for OCP and make > use of the HTTP header parsing libraries, for example? And bring in > all the baggage about chunking? If so, we need to state this > somewhere, and say why we are doing this, rather than defining > protocol-independent bindings. The "application agnostic" stuff > seems to lead one to expect protocol-independent metadata. This is > why I am deeply confused. Further, if there is a truly application > independent encoding, say, for mime parts, then why not just use > this as the single encoding? At one time it was very important to > use HTTP bindings for this code reuse purpose, but I'm not sure that > is still the case. Can we document a decision on this point? I may have mentioned that before, but I think we need to decide on OCP transport binding(s?) first. Once we know the transport, we would be able to decide how to document OCP encodings. Or, at least, the two decisions (transport and encoding) should be done simultaneously because some high-level transports (e.g., HTTP) have strong influence on encodings. Answering this question will make OCP much more clear for people who need message syntax before they can understand a protocol (the majority of practitioners, I guess). > OCP's negotiation section hints at a rich set of operations; do we > need more than the usual "here's my menu" and "here's my selection > from your menu" ? We are waiting for Reinaldo Penno to give us an answer. You can ignore negotiation messages until then. > I confess to not understanding the big diagram in OCP; it may be an > elegant way to convey information, if I only understood it. It simply shows incapsulation of protocol elements (boxes within boxes). As I said in release notes, I am not particularly happy about it either. Better rendering ideas or examples are more than welcome! > Where are the "data have" messages? Are those "OCP messages" in the > last box? Yes, data-have message is an OCP message. > What are "connection C" and "connection G" ? Two [partially concurrent] OCP connections. > I cannot keep myself from stumbling over "application message" time > and again. And again. The stuff between the OPES processor and > callout server that might be encapsulated data coming from or going > to the proxied transaction ... can that have an unambiguous name, > like "zinc", if there's nothing better? Except for section 1.1, there should be no mentioning of "proxied" anything. The fact that OPES processor is a proxy is out of OCP scope, and section 1.1 attempts to document that. "Application message" is whatever OPES processor and callout server what it to be, essentially. I would not like "zinc", but would very welcome better alternatives to describe an undefined (content, metadata) pair. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 16 09:12:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29956 for ; Wed, 16 Apr 2003 09:12:47 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195mkv-0001QN-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 09:15:17 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195mku-0001QK-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 09:15:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GD09t2055629 for ; Wed, 16 Apr 2003 06:00:09 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GD09jq055627 for ietf-openproxy-bks; Wed, 16 Apr 2003 06:00:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GD08t2055618 for ; Wed, 16 Apr 2003 06:00:08 -0700 (PDT) (envelope-from info@utel.net) Received: from f05v-9-204.d1.club-internet.fr ([212.194.92.204] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 195mVu-00016o-00; Wed, 16 Apr 2003 05:59:47 -0700 Message-Id: <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 16 Apr 2003 12:18:45 +0200 To: Alex Rousskov From: jfcm Subject: Re: OCP questions Cc: ietf-openproxy@imc.org In-Reply-To: References: <200304152219.h3FMJQj25493@localhost.localdomain> <200304152219.h3FMJQj25493@localhost.localdomain> 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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 00:57 16/04/03, Alex Rousskov said: >Answering this question will make OCP much more clear for people who >need message syntax before they can understand a protocol (the >majority of practitioners, I guess). I happen to be one of the few needing a model first. Just to know what we are talking about: it may help. Most of the points risen here would get a clear response with a simple diagrams such as : http | data input | dispatcher | call-out protocol | server | call-out protocol | data-output | http <------ OPES ? <------ OPES ? jfc PS. What about protocol conversion, is that OPES? From owner-ietf-openproxy@mail.imc.org Wed Apr 16 09:32:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00653 for ; Wed, 16 Apr 2003 09:32:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195n3y-0001YJ-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 09:34:58 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195n3y-0001YG-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 09:34:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GDMit2058373 for ; Wed, 16 Apr 2003 06:22:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GDMiDu058371 for ietf-openproxy-bks; Wed, 16 Apr 2003 06:22: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.8p1/8.12.8) with ESMTP id h3GDMgt2058359 for ; Wed, 16 Apr 2003 06:22: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 h3GDMhvj094880; Wed, 16 Apr 2003 07:22:43 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3GDMhPI094879; Wed, 16 Apr 2003 07:22:43 -0600 (MDT) (envelope-from rousskov) Date: Wed, 16 Apr 2003 07:22:43 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP questions In-Reply-To: <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> Message-ID: References: <200304152219.h3FMJQj25493@localhost.localdomain> <200304152219.h3FMJQj25493@localhost.localdomain> <5.2.0.9.0.20030416121232.029f5430@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: On Wed, 16 Apr 2003, jfcm wrote: > Most of the points risen here would get a clear response with a > simple diagrams such as : > > http | data input | dispatcher | call-out protocol | server | call-out > protocol | data-output | http > <------ OPES ? > <------ OPES ? We already have/had such diagrams. Obviously, they did not provide enough "clear responses". Note that OCP has nothing to do with "http | data input |" and "data-output | http" parts. OCP Core has specific wording about that. That wording replaced some of the figures that had those parts in earlier OCP Core versions. > PS. What about protocol conversion, is that OPES? It can be. An application proxy that does protocol conversion may support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy today has to convert between HTTP and FTP (or even Gopher, WAIS, etc.). I do not see why OPES proxies should be more limited than existing HTTP proxies. If OCP is involved in protocol conversion, OCP agents would have to negotiate/agree on how to specify original/adapted protocols via application message metadata. Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 16 10:30:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03529 for ; Wed, 16 Apr 2003 10:30:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195nyG-0001qX-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 10:33:08 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195nyF-0001qU-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 10:33:07 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GEK4t2061291 for ; Wed, 16 Apr 2003 07:20:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GEK4p5061290 for ietf-openproxy-bks; Wed, 16 Apr 2003 07:20:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GEK3t2061285 for ; Wed, 16 Apr 2003 07:20:03 -0700 (PDT) (envelope-from info@utel.net) Received: from f05v-9-204.d1.club-internet.fr ([212.194.92.204] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 195nlX-0005gH-00; Wed, 16 Apr 2003 07:20:00 -0700 Message-Id: <5.2.0.9.0.20030416155353.03966980@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 16 Apr 2003 16:10:34 +0200 To: Alex Rousskov , ietf-openproxy@imc.org From: jfcm Subject: Re: OCP questions In-Reply-To: References: <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> <200304152219.h3FMJQj25493@localhost.localdomain> <200304152219.h3FMJQj25493@localhost.localdomain> <5.2.0.9.0.20030416121232.029f5430@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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 15:22 16/04/03, Alex Rousskov wrote: >On Wed, 16 Apr 2003, jfcm wrote: > > Most of the points risen here would get a clear response with a > > simple diagrams such as : > > > > http | data input | dispatcher | call-out protocol | server | call-out > > protocol | data-output | http > > <------ OPES ? > > <------ OPES ? > <--- OPES ? >We already have/had such diagrams. Obviously, they did not provide >enough "clear responses". hmmm... This is your opinion which translates into some's difficulty to understand where we are. If OPES is defined as the first possbility, http is part of it and call-out may take it into account. If it is defined the second way, external protocols are no part of OPES but OCP can consider knowing it. If it is the third definition (that I thought you would add by yourself in your response to illustrate the difficulty), then the call-out protocol has NO relation with the entry protocol. >Note that OCP has nothing to do with "http | >data input |" and "data-output | http" parts. OCP Core has specific >wording about that. That wording replaced some of the figures that had >those parts in earlier OCP Core versions. Seems that this wording does not prevent questions. May be both could be kept? We could check they fit the different understandings. > > PS. What about protocol conversion, is that OPES? > >It can be. An application proxy that does protocol conversion may >support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy >today has to convert between HTTP and FTP (or even Gopher, WAIS, >etc.). I do not see why OPES proxies should be more limited than >existing HTTP proxies. If OCP is involved in protocol conversion, OCP >agents would have to negotiate/agree on how to specify >original/adapted protocols via application message metadata. At a given stage one must start saying what an OPES is and is not. And stop saying "it can be". IMHO it CANNOT be a protocol converter if it is not related to the entry protocol (but the use of different I/O protocol will [affirmative mode] make it a part of a protocol conversion system). This will have an impact on OCP. The protocol sequence is then: http > call-out > smtp. jfc >Alex. > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03 From owner-ietf-openproxy@mail.imc.org Wed Apr 16 12:02:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06921 for ; Wed, 16 Apr 2003 12:02:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195pP6-0002On-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 12:04:56 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195pP6-0002Ok-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 12:04:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GFpat2065713 for ; Wed, 16 Apr 2003 08:51:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GFpaVM065711 for ietf-openproxy-bks; Wed, 16 Apr 2003 08:51: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.8p1/8.12.8) with ESMTP id h3GFpYt2065705 for ; Wed, 16 Apr 2003 08:51:34 -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 h3GFpZvj098313; Wed, 16 Apr 2003 09:51:35 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3GFpZGp098312; Wed, 16 Apr 2003 09:51:35 -0600 (MDT) (envelope-from rousskov) Date: Wed, 16 Apr 2003 09:51:35 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: OPES definition/scope In-Reply-To: <5.2.0.9.0.20030416155353.03966980@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> <200304152219.h3FMJQj25493@localhost.localdomain> <200304152219.h3FMJQj25493@localhost.localdomain> <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> <5.2.0.9.0.20030416155353.03966980@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: -- was "Subject: OCP questions" jfc, You keep mixing OCP and OPES which makes it very awkward (for me) to respond. The "OCP questions" thread you responded to was about OCP. OCP Core is application-agnostic and, hence does not care much about proxied protocols, their conversions, etc. I took the liberty of renaming your Subject line. If you want to polish or completely change OPES definition, PLEASE stay on this new thread and make specific suggestions here. If you want to discuss OCP Core draft instead, please use existing OPES architecture and the old thread (or start a new one). I understand that OCP depends on OPES architecture, but OCP thread is not about OPES in general, it is about OCP. This new thread can be about what OPES is or should be. Specific OPES-related comments are inlined. On Wed, 16 Apr 2003, jfcm wrote: > At 15:22 16/04/03, Alex Rousskov wrote: > >On Wed, 16 Apr 2003, jfcm wrote: > > > Most of the points risen here would get a clear response with a > > > simple diagrams such as : > > > > > > http | data input | dispatcher | call-out protocol | server | call-out > > > protocol | data-output | http > > > <------ OPES ? > > > <------ OPES ? > > > <--- OPES ? > > >We already have/had such diagrams. Obviously, they did not provide > >enough "clear responses". > > hmmm... This is your opinion which translates into some's difficulty > to understand where we are. What I said is not an opinion. It is a fact. We had very similar diagrams in OCP Core (e.g., see section 2.1 "2.1 OCP environment" in version head_sid3 of the OCP Core draft [1]) and, since people keep asking questions, they did not get us "clear responses" you promise. [1] http://www.measurement-factory.com/tmp/opes/snapshots/head_sid3/ocp-spec.html#section_ops-environment > If OPES is defined as the first possbility, http is part of it and > call-out may take it into account. If it is defined the second way, > external protocols are no part of OPES but OCP can consider knowing > it. If it is the third definition (that I thought you would add by > yourself in your response to illustrate the difficulty), then the > call-out protocol has NO relation with the entry protocol. I do not know what "possibilities" you are talking about. Are they related to the arrows on your diagram? Care to define them explicitly? > >Note that OCP has nothing to do with "http | > >data input |" and "data-output | http" parts. OCP Core has specific > >wording about that. That wording replaced some of the figures that had > >those parts in earlier OCP Core versions. > > Seems that this wording does not prevent questions. May be both > could be kept? We could check they fit the different understandings. By "both", do you mean the old figure and the new wording? > > > PS. What about protocol conversion, is that OPES? > > > >It can be. An application proxy that does protocol conversion may > >support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy > >today has to convert between HTTP and FTP (or even Gopher, WAIS, > >etc.). I do not see why OPES proxies should be more limited than > >existing HTTP proxies. If OCP is involved in protocol conversion, OCP > >agents would have to negotiate/agree on how to specify > >original/adapted protocols via application message metadata. > > At a given stage one must start saying what an OPES is and is not. OPES is about many specific things. If you keep asking specific questions ("Is OPES about Foo"), you will keep getting specific answers ("OPES can be about Foo", but it can also be about "Bar"). > And stop saying "it can be". I was just answering your question! OPES, regardless of the definition, can be many things. It is OK to say "OPES is about protocol conversion", but since OPES is also about other things, it is more accurate to say (IMO) that "OPES can be about protocol conversion". That is, "protocol conversion" is within OPES scope. The latter is the best wording, I guess. > IMHO it CANNOT be a protocol converter if it is not related to the > entry protocol OPES _is_ related to the input/entry protocol. We even plan input/output protocol-specific drafts, possibly one per proxied protocol! > (but the use of different I/O protocol will > [affirmative mode] make it a part of a protocol conversion system). Do not know what you mean by "I/O protocol". > This will have an impact on OCP. The protocol sequence is then: > http > call-out > smtp. The above is not how callout protocol is now defined. Callout is something that comes back: (http) <--> OPES processor <--> (ftp) ^ | V (callout) Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 16 16:37:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15947 for ; Wed, 16 Apr 2003 16:37:51 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195the-0003ae-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 16:40:22 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195thd-0003ab-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 16:40:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GKR6t2074814 for ; Wed, 16 Apr 2003 13:27:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GKR66F074813 for ietf-openproxy-bks; Wed, 16 Apr 2003 13:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GKR5t2074808 for ; Wed, 16 Apr 2003 13:27:05 -0700 (PDT) (envelope-from info@utel.net) Received: from f18m-2-113.d1.club-internet.fr ([212.195.137.113] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 195tUh-0001Kh-00; Wed, 16 Apr 2003 13:27:00 -0700 Message-Id: <5.2.0.9.0.20030416184406.02a74170@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 16 Apr 2003 19:27:23 +0200 To: Alex Rousskov , ietf-openproxy@imc.org From: jfcm Subject: Re: OPES definition/scope In-Reply-To: References: <5.2.0.9.0.20030416155353.03966980@mail.utel.net> <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> <200304152219.h3FMJQj25493@localhost.localdomain> <200304152219.h3FMJQj25493@localhost.localdomain> <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> <5.2.0.9.0.20030416155353.03966980@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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just think in simple ways: - Yes/No. - layers by layer implications - logical models - what has not been approved by consensus is not accepted *At 17:51 16/04/03, Alex Rousskov wrote: >-- was "Subject: OCP questions" >jfc, > You keep mixing OCP and OPES which makes it very awkward (for >me) to respond. The "OCP questions" thread you responded to was about >OCP. OCP Core is application-agnostic and, hence does not care much >about proxied protocols, their conversions, etc. The thread I followed was questions on that. > I took the liberty of renaming your Subject line. If you want >to polish or completely change OPES definition, PLEASE stay on this >new thread and make specific suggestions here. If you want to discuss >OCP Core draft instead, please use existing OPES architecture and the >old thread (or start a new one). I understand that OCP depends on OPES >architecture, but OCP thread is not about OPES in general, it is about >OCP. This new thread can be about what OPES is or should be. The OPES is NOT defined enough for the OPC Core not to be affected. At this stage I saw no concensus call on anything yet. Or did I miss something? > Specific OPES-related comments are inlined. > >On Wed, 16 Apr 2003, jfcm wrote: > > > At 15:22 16/04/03, Alex Rousskov wrote: > > >On Wed, 16 Apr 2003, jfcm wrote: > > > > Most of the points risen here would get a clear response with a > > > > simple diagrams such as : > > > > > > > > http | data input | dispatcher | call-out protocol | server | call-out > > > > protocol | data-output | http > > > > <------ OPES ? possiblity 1 > > > > <------ OPES ? possiblity 2 > > > <--- OPES ? possibility 3 > > > > >We already have/had such diagrams. Obviously, they did not provide > > >enough "clear responses". > > > > hmmm... This is your opinion which translates into some's difficulty > > to understand where we are. > >What I said is not an opinion. It is a fact. We had very similar >diagrams in OCP Core (e.g., see section 2.1 "2.1 OCP environment" in >version head_sid3 of the OCP Core draft [1]) and, since people keep >asking questions, they did not get us "clear responses" you promise. > >[1] >http://www.measurement-factory.com/tmp/opes/snapshots/head_sid3/ocp-spec.html#section_ops-environment Since people still keep asking questions I suggest that you keep both the diagram and the explaination. This may help to understand. So we may also see if the diagrams are good enough and if the explanations match the diagram. Modelization is the first step, but it is also an iterative process. > > If OPES is defined as the first possbility, http is part of it and > > call-out may take it into account. If it is defined the second way, > > external protocols are no part of OPES but OCP can consider knowing > > it. If it is the third definition (that I thought you would add by > > yourself in your response to illustrate the difficulty), then the > > call-out protocol has NO relation with the entry protocol. > >I do not know what "possibilities" you are talking about. Are they >related to the arrows on your diagram? Care to define them explicitly? I am discussing a diagram where three possibitilities are shown with a question mark. For your convenience I added the wording "possiblity #". > > >Note that OCP has nothing to do with "http | > > >data input |" and "data-output | http" parts. OCP Core has specific > > >wording about that. That wording replaced some of the figures that had > > >those parts in earlier OCP Core versions. > > > > Seems that this wording does not prevent questions. May be both > > could be kept? We could check they fit the different understandings. > >By "both", do you mean the old figure and the new wording? Yes. As discussed above. Even is things are the same in your mind, either they will present the same thing and they will help understanding, or they may present different things and will help indifying misunderstandings. > > > > PS. What about protocol conversion, is that OPES? > > > > > >It can be. An application proxy that does protocol conversion may > > >support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy > > >today has to convert between HTTP and FTP (or even Gopher, WAIS, > > >etc.). I do not see why OPES proxies should be more limited than > > >existing HTTP proxies. If OCP is involved in protocol conversion, OCP > > >agents would have to negotiate/agree on how to specify > > >original/adapted protocols via application message metadata. > > > > At a given stage one must start saying what an OPES is and is not. > >OPES is about many specific things. If you keep asking specific >questions ("Is OPES about Foo"), you will keep getting specific >answers ("OPES can be about Foo", but it can also be about "Bar"). This should not be the case. If you work out a, OPES diagram; you will have I/Os and you will phrase OPES in a mathematical way as a function (or group of functions). That function(s) will be clearly understood if it is clearly and afirmatively described in a generic way. If the I/O of the OPES black-box are data flows under protocols, then OPES may relate to protocols, if not they will not. This is what a diagram will permit/help you to see easily. > > And stop saying "it can be". > >I was just answering your question! OPES, regardless of the >definition, can be many things. It is OK to say "OPES is about >protocol conversion", but since OPES is also about other things, it is >more accurate to say (IMO) that "OPES can be about protocol >conversion". That is, "protocol conversion" is within OPES scope. >The latter is the best wording, I guess. No. As everything generic OPES can only carry what they have beend defined to carry. Some implementations could do more, they could also participate into some other process. But generic OPES will do all what they are expected to do if they are well designed, and no more (otherwise they would have been ill defined or would cost too much to develop for the expected return). > > IMHO it CANNOT be a protocol converter if it is not related to the > > entry protocol > >OPES _is_ related to the input/entry protocol. We even plan >input/output protocol-specific drafts, possibly one per proxied >protocol! You "plan". This is "possibly". IAB said it is related to http. To be realted to more you have two options: - to draft as many OPES systems with impact on OPC - to make them independent from the I/O protocol (possiblity 2 or better 3 aboe), leaving that aspect to a protocol interface able to relate with such OPES systems. I do prefer that last approach in one architecture (dispatcher centric). I do not in the other architecture (daisy chaining). When you say that OPES "can be both" you do not help me deciding. We are here talking specifcally of the OPC Core. And in a dispatcher centric architecture I think the callout protocol is the center of the whole OPES system; while in the daisy chain architecture If feel it is quite of no interest. > > (but the use of different I/O protocol will > > [affirmative mode] make it a part of a protocol conversion system). > >Do not know what you mean by "I/O protocol". Protocol used to input or output the data. The same wording as you, just above. > > This will have an impact on OCP. The protocol sequence is then: > > http > call-out > smtp. > >The above is not how callout protocol is now defined. Callout is >something that comes back: > > (http) <--> OPES processor <--> (ftp) > ^ > | > V > (callout) Thnak you for the draft/ So you can see that that the sequence of the data path is http > (dispatcher) call-out (server) call-out > (dispatcher) > ftp. So if you only keep protocol, the protocol sequence is what I indicated. It permits to see that - unless protocols conversion or continuity relies on stored information every meta info in the input protcol must be transported in the call-out protcol. So the OPC is I/O protocol dependent and new versions can be specified on I/O protocols basis. Or OCP supports enough information to be mapped into many protocols. Then all the protocols one can interface are OPES acceptable. This makes two totally different architectures and ways to consider OPES. jfc From owner-ietf-openproxy@mail.imc.org Wed Apr 16 17:14:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17135 for ; Wed, 16 Apr 2003 17:14:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195uHL-0003pB-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 17:17:15 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195uHK-0003p8-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 17:17:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GL4Mt2076158 for ; Wed, 16 Apr 2003 14:04:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GL4M9T076157 for ietf-openproxy-bks; Wed, 16 Apr 2003 14:04:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GL4Lt2076151 for ; Wed, 16 Apr 2003 14:04:21 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3GL8TKq023265; Wed, 16 Apr 2003 15:08:29 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3GL5pZ26836; Wed, 16 Apr 2003 15:05:51 -0600 Date: Wed, 16 Apr 2003 15:05:51 -0600 Message-Id: <200304162105.h3GL5pZ26836@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: info@utel.net Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <5.2.0.9.0.20030416184406.02a74170@mail.utel.net> Subject: Re: OPES definition/scope Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OPES is not going to do protocol conversion. An OPES-like architecture could, at some point, define the processing points and control messages for this kind of functionality, and I hope that someday we'll get there, but I doubt that it will be in a WG called OPES. You make a good point in observing that if OPES did protocol conversion, then the notion that the callout protocol is the encoded in the proxied protocol becomes confused - callout transactions would logically use protocol X in one direction and protocol Y in the other. And further, we'd have to think through several issues about matching names, authentication methods, connection initiation to endpoints, etc. that just didn't come up when we did the architecture. Of course, someone might be able to do some protocol conversions using OPES and a single protocol encoding for the callout protocol. That's fine and good, I'm sure the framework we are developing will support more uses than we directly address. Hilarie On Wed, 16 Apr 2003 at 19:27:23 +0200 jfcm stated: > I just think in simple ways: > - Yes/No. > - layers by layer implications > - logical models > - what has not been approved by consensus is not accepted > *At 17:51 16/04/03, Alex Rousskov wrote: > >-- was "Subject: OCP questions" > >jfc, > > You keep mixing OCP and OPES which makes it very awkward (for > >me) to respond. The "OCP questions" thread you responded to was about > >OCP. OCP Core is application-agnostic and, hence does not care much > >about proxied protocols, their conversions, etc. > The thread I followed was questions on that. > > I took the liberty of renaming your Subject line. If you want > >to polish or completely change OPES definition, PLEASE stay on this > >new thread and make specific suggestions here. If you want to discuss > >OCP Core draft instead, please use existing OPES architecture and the > >old thread (or start a new one). I understand that OCP depends on OPES > >architecture, but OCP thread is not about OPES in general, it is about > >OCP. This new thread can be about what OPES is or should be. > The OPES is NOT defined enough for the OPC Core not to be affected. > At this stage I saw no concensus call on anything yet. Or did I > miss something? > > Specific OPES-related comments are inlined. > > > >On Wed, 16 Apr 2003, jfcm wrote: > > > > > At 15:22 16/04/03, Alex Rousskov wrote: > > > >On Wed, 16 Apr 2003, jfcm wrote: > > > > > Most of the points risen here would get a clear response with a > > > > > simple diagrams such as : > > > > > > > > > > http | data input | dispatcher | call-out protocol | server | call-out > > > > > protocol | data-output | http > > > > > <------ OPES ? possiblity 1 > > > > > <------ OPES ? possiblity 2 > > > > <--- OPES ? possibility 3 > > > > > > >We already have/had such diagrams. Obviously, they did not provide > > > >enough "clear responses". > > > > > > hmmm... This is your opinion which translates into some's difficulty > > > to understand where we are. > > > >What I said is not an opinion. It is a fact. We had very similar > >diagrams in OCP Core (e.g., see section 2.1 "2.1 OCP environment" in > >version head_sid3 of the OCP Core draft [1]) and, since people keep > >asking questions, they did not get us "clear responses" you promise. > > > >[1] > >http://www.measurement-factory.com/tmp/opes/snapshots/head_sid3/ocp-spec.html#section_ops-environment > Since people still keep asking questions I suggest that you keep both the > diagram and the explaination. This may help to understand. So we may also > see if the diagrams are good enough and if the explanations match the > diagram. Modelization is the first step, but it is also an iterative process. > > > If OPES is defined as the first possbility, http is part of it and > > > call-out may take it into account. If it is defined the second way, > > > external protocols are no part of OPES but OCP can consider knowing > > > it. If it is the third definition (that I thought you would add by > > > yourself in your response to illustrate the difficulty), then the > > > call-out protocol has NO relation with the entry protocol. > > > >I do not know what "possibilities" you are talking about. Are they > >related to the arrows on your diagram? Care to define them explicitly? > I am discussing a diagram where three possibitilities are shown > with a question mark. For your convenience I added the wording > "possiblity #". > > > >Note that OCP has nothing to do with "http | > > > >data input |" and "data-output | http" parts. OCP Core has specific > > > >wording about that. That wording replaced some of the figures that had > > > >those parts in earlier OCP Core versions. > > > > > > Seems that this wording does not prevent questions. May be both > > > could be kept? We could check they fit the different understandings. > > > >By "both", do you mean the old figure and the new wording? > Yes. As discussed above. Even is things are the same in your mind, either > they will present the same thing and they will help understanding, or they > may present different things and will help indifying misunderstandings. > > > > > PS. What about protocol conversion, is that OPES? > > > > > > > >It can be. An application proxy that does protocol conversion may > > > >support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy > > > >today has to convert between HTTP and FTP (or even Gopher, WAIS, > > > >etc.). I do not see why OPES proxies should be more limited than > > > >existing HTTP proxies. If OCP is involved in protocol conversion, OCP > > > >agents would have to negotiate/agree on how to specify > > > >original/adapted protocols via application message metadata. > > > > > > At a given stage one must start saying what an OPES is and is not. > > > >OPES is about many specific things. If you keep asking specific > >questions ("Is OPES about Foo"), you will keep getting specific > >answers ("OPES can be about Foo", but it can also be about "Bar"). > This should not be the case. If you work out a, OPES diagram; you > will have I/Os and you will phrase OPES in a mathematical way as > a function (or group of functions). That function(s) will be clearly > understood if it is clearly and afirmatively described in a generic way. > If the I/O of the OPES black-box are data flows under protocols, then > OPES may relate to protocols, if not they will not. This is what a > diagram will permit/help you to see easily. > > > And stop saying "it can be". > > > >I was just answering your question! OPES, regardless of the > >definition, can be many things. It is OK to say "OPES is about > >protocol conversion", but since OPES is also about other things, it is > >more accurate to say (IMO) that "OPES can be about protocol > >conversion". That is, "protocol conversion" is within OPES scope. > >The latter is the best wording, I guess. > No. As everything generic OPES can only carry what they have > beend defined to carry. Some implementations could do more, > they could also participate into some other process. But generic > OPES will do all what they are expected to do if they are well > designed, and no more (otherwise they would have been ill defined > or would cost too much to develop for the expected return). > > > IMHO it CANNOT be a protocol converter if it is not related to the > > > entry protocol > > > >OPES _is_ related to the input/entry protocol. We even plan > >input/output protocol-specific drafts, possibly one per proxied > >protocol! > You "plan". This is "possibly". IAB said it is related to http. > To be realted to more you have two options: > - to draft as many OPES systems with impact on OPC > - to make them independent from the I/O protocol (possiblity > 2 or better 3 aboe), leaving that aspect to a protocol interface > able to relate with such OPES systems. > I do prefer that last approach in one architecture (dispatcher centric). > I do not in the other architecture (daisy chaining). When you say > that OPES "can be both" you do not help me deciding. > We are here talking specifcally of the OPC Core. And in a > dispatcher centric architecture I think the callout protocol is the > center of the whole OPES system; while in the daisy chain > architecture If feel it is quite of no interest. > > > (but the use of different I/O protocol will > > > [affirmative mode] make it a part of a protocol conversion system). > > > >Do not know what you mean by "I/O protocol". > Protocol used to input or output the data. The same > wording as you, just above. > > > This will have an impact on OCP. The protocol sequence is then: > > > http > call-out > smtp. > > > >The above is not how callout protocol is now defined. Callout is > >something that comes back: > > > > (http) <--> OPES processor <--> (ftp) > > ^ > > | > > V > > (callout) > Thnak you for the draft/ So you can see that that the sequence > of the data path is http > (dispatcher) call-out (server) call-out > > (dispatcher) > ftp. > So if you only keep protocol, the protocol sequence is what > I indicated. It permits to see that - unless protocols conversion > or continuity relies on stored information every meta info in > the input protcol must be transported in the call-out protcol. > So the OPC is I/O protocol dependent and new versions can > be specified on I/O protocols basis. > Or OCP supports enough information to be mapped into many > protocols. Then all the protocols one can interface are OPES > acceptable. > This makes two totally different architectures and ways to > consider OPES. > jfc From owner-ietf-openproxy@mail.imc.org Wed Apr 16 17:51:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18096 for ; Wed, 16 Apr 2003 17:51:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195ur6-0003zF-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 17:54:12 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195ur5-0003zC-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 17:54:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLhAt2077700 for ; Wed, 16 Apr 2003 14:43:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GLhAIA077699 for ietf-openproxy-bks; Wed, 16 Apr 2003 14:43:10 -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.8p1/8.12.8) with ESMTP id h3GLh8t2077694 for ; Wed, 16 Apr 2003 14:43:09 -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 h3GLhBvj007692; Wed, 16 Apr 2003 15:43:11 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3GLhBVJ007691; Wed, 16 Apr 2003 15:43:11 -0600 (MDT) (envelope-from rousskov) Date: Wed, 16 Apr 2003 15:43:11 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OPES definition/scope In-Reply-To: <5.2.0.9.0.20030416184406.02a74170@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030416155353.03966980@mail.utel.net> <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> <200304152219.h3FMJQj25493@localhost.localdomain> <200304152219.h3FMJQj25493@localhost.localdomain> <5.2.0.9.0.20030416121232.029f5430@mail.utel.net> <5.2.0.9.0.20030416155353.03966980@mail.utel.net> <5.2.0.9.0.20030416184406.02a74170@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: Short summary/conclusion for those that do not want to read the whole thing: jfc, I am still not sure what exactly you are objecting to (if anything). Would it be possible for you to summarize your position in a stand-alone statement _and_ propose specific changes to any of the existing drafts? This will ensure that we, eventually, have consensus. If you are not objecting to or suggesting anything specific but are rather asking questions, you may want to re-post a set of specific questions that are still not answered (but it is impossible to guarantee that every question can be answered to one's satisfaction, of course). Detailed responses are inlined below. On Wed, 16 Apr 2003, jfcm wrote: > *At 17:51 16/04/03, Alex Rousskov wrote: > > > I took the liberty of renaming your Subject line. If you want > >to polish or completely change OPES definition, PLEASE stay on this > >new thread and make specific suggestions here. If you want to discuss > >OCP Core draft instead, please use existing OPES architecture and the > >old thread (or start a new one). I understand that OCP depends on OPES > >architecture, but OCP thread is not about OPES in general, it is about > >OCP. This new thread can be about what OPES is or should be. > > The OPES is NOT defined enough for the OPC Core not to be affected. Maybe, but that does not prevent me working on OCP Core. If OPES definition changes, I can adjust OCP Core as needed. I do not anticipate significant OCP changes, regardless of what this discussion does to OPES definition. Thus, I do not think I am wasting my time. IMO, those who think the changes will be significant should concentrate on OPES definition/scope first (and leave OCP alone, for now). > At this stage I saw no concensus call on anything yet. Or did I miss > something? I consider published WG drafts (most important ones are already approved as RFCs) as consensus. This does not imply that no changes to those drafts are allowed, of course. It just raises the bar for making those changes. There is currently a consensus call for the OCP Core draft to become a WG draft. So far, there has been no specific objections I am aware of. We have discussed a few changes that have already been implemented. > Since people still keep asking questions I suggest that you keep > both the diagram and the explaination. This may help to understand. > So we may also see if the diagrams are good enough and if the > explanations match the diagram. Modelization is the first step, but > it is also an iterative process. OK. I will try to resurrect the diagram while trying to avoid now-undefined terms such as "input and output protocol". The problem is that this kind of diagram/text does not really belong to OCP. OPES Architecture or another document should address the scope of OPES components and their interaction. It is wrong to spend so much effort on documenting what OCP is NOT, especially in the OCP Core draft. > > > If OPES is defined as the first possbility, http is part of it and > > > call-out may take it into account. If it is defined the second way, > > > external protocols are no part of OPES but OCP can consider knowing > > > it. If it is the third definition (that I thought you would add by > > > yourself in your response to illustrate the difficulty), then the > > > call-out protocol has NO relation with the entry protocol. > > > >I do not know what "possibilities" you are talking about. Are they > >related to the arrows on your diagram? Care to define them explicitly? > > I am discussing a diagram where three possibitilities are shown > with a question mark. For your convenience I added the wording > "possiblity #". Please provide textual definitions. It is virtually impossible (for me) to discuss definitions that have no textual representations. [ If you want to use a formal model, that's fine with me to, but the current diagram is not a formal model because its elements and symbols are undefined. ] > > > > > PS. What about protocol conversion, is that OPES? > > > > > > > >It can be. An application proxy that does protocol conversion may > > > >support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy > > > >today has to convert between HTTP and FTP (or even Gopher, WAIS, > > > >etc.). I do not see why OPES proxies should be more limited than > > > >existing HTTP proxies. If OCP is involved in protocol conversion, OCP > > > >agents would have to negotiate/agree on how to specify > > > >original/adapted protocols via application message metadata. > > > > > > At a given stage one must start saying what an OPES is and is not. > > > >OPES is about many specific things. If you keep asking specific > >questions ("Is OPES about Foo"), you will keep getting specific > >answers ("OPES can be about Foo", but it can also be about "Bar"). > > This should not be the case. If you work out a, OPES diagram; you > will have I/Os and you will phrase OPES in a mathematical way as a > function (or group of functions). That function(s) will be clearly > understood if it is clearly and afirmatively described in a generic > way. I cannot make such a diagram or a set of mathematical functions that would completely define OPES and raise no further questions. If you can, you should do that and we will discuss the result. For me, OPES system is simply an intermediary that obeys certain rules (e.g., tracing and bypass), that adapts proxied traffic, and that may use OCP to facilitate adaptations via callout servers. > If the I/O of the OPES black-box are data flows under protocols, then > OPES may relate to protocols, if not they will not. This is what a > diagram will permit/help you to see easily. OPES relates to protocols being proxied. Do you think otherwise? If not, I do not think anybody else does, so we still have consensus, which is already documented in the architecture draft. > > > And stop saying "it can be". > > > >I was just answering your question! OPES, regardless of the > >definition, can be many things. It is OK to say "OPES is about > >protocol conversion", but since OPES is also about other things, it is > >more accurate to say (IMO) that "OPES can be about protocol > >conversion". That is, "protocol conversion" is within OPES scope. > >The latter is the best wording, I guess. > > No. As everything generic OPES can only carry what they have > beend defined to carry. Some implementations could do more, > they could also participate into some other process. But generic > OPES will do all what they are expected to do if they are well > designed, and no more (otherwise they would have been ill defined > or would cost too much to develop for the expected return). And why this is a "No"? I see no contradiction between the above two paragraphs. Some OPES systems can do protocol adaptation. Some cannot. Both kinds of systems are OPES as long as they (intend to) obey OPES rules. > > > IMHO it CANNOT be a protocol converter if it is not related to the > > > entry protocol It is related. I have heard no opinions suggesting otherwise. > >OPES _is_ related to the input/entry protocol. We even plan > >input/output protocol-specific drafts, possibly one per proxied > >protocol! > IAB said it is related to http. Correction: IAB (RFC 3238) does not refer to HTTP in any normative context. > You "plan". This is "possibly". > To be realted to more you have two options: > > - to draft as many OPES systems with impact on OPC > - to make them independent from the I/O protocol (possiblity > 2 or better 3 aboe), leaving that aspect to a protocol interface > able to relate with such OPES systems. These are not the only two options. The approach I am advocating is to have one generic (application agnostic, independent from the I/O protocol) OPES Core and several application-specific bindings or mappings of that core. OCP Core is a part of OPES Core. So are OPES tracing and OPES bypass drafts (or whatever they end up being called when/if merged). We will have different tracing mapping/support in HTTP and, say, RTSP, because those protocols are so different. > I do prefer that last approach in one architecture (dispatcher centric). > I do not in the other architecture (daisy chaining). When you say > that OPES "can be both" you do not help me deciding. IMO, OPES can be used in both architectures. I am not sure what you are deciding about, but I am sorry if I cannot help you. > We are here talking specifcally of the OPC Core. And in a > dispatcher centric architecture I think the callout protocol is the > center of the whole OPES system; while in the daisy chain > architecture If feel it is quite of no interest. Fine(*). Is that a problem? I do not see anything wrong with a particular OPES component being useful in some environments and not in other environments. OCP is a MAY for OPES. Like caching is a MAY for HTTP. (*) though it is impossible to verify your "no interest" assertion without having definitons of "dispatcher centric" and "daisy chain" architectures > > > This will have an impact on OCP. The protocol sequence is then: > > > http > call-out > smtp. > > > >The above is not how callout protocol is now defined. Callout is > >something that comes back: > > > > (http) <--> OPES processor <--> (ftp) > > ^ > > | > > V > > (callout) > > Thnak you for the draft/ So you can see that that the sequence of > the data path is http > (dispatcher) call-out (server) call-out > > (dispatcher) > ftp. > > So if you only keep protocol, the protocol sequence is what > I indicated. It permits to see that - unless protocols conversion > or continuity relies on stored information every meta info in > the input protcol must be transported in the call-out protcol. _Every_ metainfo? I do not see how is that implied. The exact protocol conversion/mapping functions are undefined by OPES; it is perfectly fine, in general, to alter meta information (adapt it), including a case where all information is deleted (SMTP black hole for SPAM). > So the OPC is I/O protocol dependent and new versions can > be specified on I/O protocols basis. OCP Core is independent of proxied protocols. There will be specific application bindings for specific "application messages". > Or OCP supports enough information to be mapped into many protocols. > Then all the protocols one can interface are OPES acceptable. > > This makes two totally different architectures and ways to consider > OPES. And I want to support both by separating application-independent Core from application-dependent bindings. Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 16 18:29:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20024 for ; Wed, 16 Apr 2003 18:29:55 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195vS4-000453-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 18:32:24 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195vS3-00044z-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 18:32:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GMJ4t2078823 for ; Wed, 16 Apr 2003 15:19:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GMJ4iA078822 for ietf-openproxy-bks; Wed, 16 Apr 2003 15:19:04 -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.8p1/8.12.8) with ESMTP id h3GMJ2t2078817 for ; Wed, 16 Apr 2003 15:19:03 -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 h3GMIsvj008520; Wed, 16 Apr 2003 16:18:54 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3GMIs74008519; Wed, 16 Apr 2003 16:18:54 -0600 (MDT) (envelope-from rousskov) Date: Wed, 16 Apr 2003 16:18:54 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OPES definition/scope In-Reply-To: <200304162105.h3GL5pZ26836@localhost.localdomain> Message-ID: References: <200304162105.h3GL5pZ26836@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: On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote: > OPES is not going to do protocol conversion. An OPES-like > architecture could, at some point, define the processing points and > control messages for this kind of functionality, and I hope that > someday we'll get there, but I doubt that it will be in a WG called > OPES. I think you gave a premature answer. If OPES is to support HTTP, then OPES processors will have to participate in protocol conversion (HTTP -> FTP) because an HTTP proxy has to do that. In fact, any existing HTTP proxy that supports ftp:// URLs is, essentially, an OPES processor. It adapts application messages that it proxies! Have you ever thought about what happens when your browser sends GET ftp://ftp.example.com/pub HTTP/1.0 through an HTTP proxy? ftp.example.com does not talk HTTP on port 21 and does not know about HTML. Yet, your browser gets an HTTP response with a nicely formated directory listing in HTML. Magic? Note that I am not saying that OCP has to be involved. > You make a good point in observing that if OPES did protocol > conversion, then the notion that the callout protocol is the encoded > in the proxied protocol becomes confused - callout transactions > would logically use protocol X in one direction and protocol Y in > the other. And further, we'd have to think through several issues > about matching names, authentication methods, connection initiation > to endpoints, etc. that just didn't come up when we did the > architecture. I think you are finding complications when none exist. At least not at the OCP Core level. Look at the way application message is currently defined in OCP Core. There is no place for [additional] confusion, even if protocol conversion is done via callout servers. The [proxied protocol (or protocols) do not exist at the OCP Core level! > Of course, someone might be able to do some protocol conversions > using OPES and a single protocol encoding for the callout protocol. > That's fine and good, I'm sure the framework we are developing will > support more uses than we directly address. True. Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 16 19:56:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21658 for ; Wed, 16 Apr 2003 19:56:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195wnV-0004N6-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 19:58:37 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195wnV-0004N3-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 19:58:37 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GNh0t2081536 for ; Wed, 16 Apr 2003 16:43:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GNh0oc081535 for ietf-openproxy-bks; Wed, 16 Apr 2003 16:43:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GNgwt2081530 for ; Wed, 16 Apr 2003 16:42:58 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3GNl7Kq028645; Wed, 16 Apr 2003 17:47:07 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3GNiIF01777; Wed, 16 Apr 2003 17:44:18 -0600 Date: Wed, 16 Apr 2003 17:44:18 -0600 Message-Id: <200304162344.h3GNiIF01777@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: OPES definition/scope Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Proxies do lots of things that OPES will not specify. Some are so heinous that I'll not even mention them. And no, I don't believe they use magic, but your question shows an admirably open mind. Hilarie From owner-ietf-openproxy@mail.imc.org Wed Apr 16 21:29:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23360 for ; Wed, 16 Apr 2003 21:29:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195yFV-0004eH-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 21:31:37 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 195yFU-0004eE-00 for opes-archive@ietf.org; Wed, 16 Apr 2003 21:31:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1G0t2083687 for ; Wed, 16 Apr 2003 18:16:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H1G0Mr083686 for ietf-openproxy-bks; Wed, 16 Apr 2003 18:16:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1Fxt2083678 for ; Wed, 16 Apr 2003 18:15:59 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3H1K9Kq031536; Wed, 16 Apr 2003 19:20:09 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3H1HRQ06771; Wed, 16 Apr 2003 19:17:27 -0600 Date: Wed, 16 Apr 2003 19:17:27 -0600 Message-Id: <200304170117.h3H1HRQ06771@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: OCP questions Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 15 Apr 2003 at 16:57:04 -0600 (MDT) Alex Rousskov announced: > > If I am reading things correctly, the requirements allow several > > "connections" over one transport connection, but OCP forbids it. > > Is there disagreement? If not, which notion is correct? > OCP Core does not forbid several OCP connection over one transport > connection (bugs notwithstanding). OCP Core says, in part > ("Connections" section, blob 87): > If BEEP over TCP is used, than a BEEP channel will correspond > to a callout connection, allowing callout connection > multiplexing over a single TCP connection. > What made you think that "OCP forbids it"? These words: For example, if raw TCP is the transport, than a TCP connection will correspond to a callout connection. > > The requirements mention "keep-alives" and "heartbeats". Was there > > any intent to require heartbeat support? OCP does not use them, > > which is fine with me. > OCP Core supports heartbeats via and > messages. Those are actually very useful because OCP Core relies on > timeouts to resolve possible problems with overloaded or > malfunctioning agents and timeouts without heartbeats do not work well > for "slow" adaptations. I think "heartbeat" generally means that a message every n time units is required - there's no "are you there". > > Reviewing the messages on this list, I find myself deeply uncertain > > about what would be in "OCP/HTTP bindings". Would it be an encoding > > of the OCP protocol elements (transaction start, transaction id, > > etc.) as HTTP-style headers? > You may be confusing/mixing OCP transport binding and > application-specific drafts. We have not decided on OCP transport > binding. In theory, it can be HTTP like in ICAP. If that is the case, > then either OCP Core (if there is only one transport binding) or HTTP > Transport Binding for OCP (if there are multiple transport bindings) > drafts will indeed document how to convert OCP protocol elements to > HTTP elements. Then there are two distinct options being considered, as you say: 1. A single transport for OCP. 2. Multiple transports for OCP. If there is a single transport, then there will be a single document showing how to encode the OCP protocol elements into bitstrings carried over that transport. If there are multiple transports, then there will be a document for each transport showing how to encode the OCP protocol elements into bitstrings carried over that transport. Those would be OCP/HTTP, OCP/RTP, OCP/TCP, OCP/BEEP, perhaps. With other possibilties, such as OCP/SNMP. OCP/FTP, OCP/WEP, .... Lurking in the wings is the idea of a new transport, call it OCPTRAN for the moment (or "copper" :-) see later), running over one or more of TCP, UDP, IP, BEEP?, ... The OCP document as it stands now is a data model and state machine. It is awaiting WG decision on the issue of transport. OK so far? One thing that might help with clarity is to note that we have been talking about using a Layer 4 transport as OCP transport sometime, but other times we are talking about using a Layer 5 protocols as an OCP transport. What bothers me is the issue of the nature of the proxied protocols and whether or not each one needs its own OCP binding. We know that HTTP, with only minor modifications, can be the OCP transport for a proxied HTTP connection. Can/should it be the OCP transport for FTP? For SNMP? For telnet? That possibility is what led to the awkward architecture for protocol conversion, using OCP transport X for requests and getting the reply back on transport Y! There are pros and cons here. Using a "native" callout protocol (HTTP over HTTP, SNMP over SNMP, RTP over RTP, etc.) is a quick way to get going - the person who knows the protocol can probably figure out a quick way to get the callout protocol implemented, the framing and other issues are simpler if you aren't changing protocols, libraries can be reused, etc. The con is that the OPES processor may become bogged down with too many pieces of client-side code. There must be other issues. If there is only one transport protocol, then it may become complicated with too many features as it tries to encompass all the different framing methods, reliability issues, etc. My opinion is that if we decide on only one transport, that it *not* be tied to HTTP, that it be as lightweight as possible. (By the way, I'm in touch with someone who says he's got documented timings of the overhead involved in parsing a null XML message with standard commercial software - 30 times the effort of a simple TCP connection sending one byte back and forth; I'm trying to get his tech report). Personally, I think the best choice is a new transport named OCPTRAN that can run over TCP for data that needs reliable service and can also run over UDP or just IP if need be. I'm not sure where BEEP fits in this taxonomy - it seems to be orthogonal (in the sense of "not a branch point" rather than "useless"). > > I cannot keep myself from stumbling over "application message" time > > and again. And again. The stuff between the OPES processor and > > callout server that might be encapsulated data coming from or going > > to the proxied transaction ... can that have an unambiguous name, > > like "zinc", if there's nothing better? > Except for section 1.1, there should be no mentioning of "proxied" > anything. The fact that OPES processor is a proxy is out of OCP scope, > and section 1.1 attempts to document that. "Application message" is > whatever OPES processor and callout server what it to be, essentially. > I would not like "zinc", but would very welcome better alternatives to > describe an undefined (content, metadata) pair. Even if the draft doesn't refer to proxied data, the concept is still there, and "application message" will continue to seem ambiguous, to me, anyway. How can you not like "zinc"? OSERVICE-BLOB? OUTBOARD-SERVICE-DATA? Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 17 01:44:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28143 for ; Thu, 17 Apr 2003 01:44:12 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1962EL-0005OO-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 01:46:41 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1962EK-0005OL-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 01:46:41 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H5Vht2091872 for ; Wed, 16 Apr 2003 22:31:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H5Vhpx091871 for ietf-openproxy-bks; Wed, 16 Apr 2003 22:31:43 -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.8p1/8.12.8) with ESMTP id h3H5Vft2091866 for ; Wed, 16 Apr 2003 22:31:42 -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 h3H5VLvj018653; Wed, 16 Apr 2003 23:31:21 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3H5VLeZ018652; Wed, 16 Apr 2003 23:31:21 -0600 (MDT) (envelope-from rousskov) Date: Wed, 16 Apr 2003 23:31:21 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP questions In-Reply-To: <200304170117.h3H1HRQ06771@localhost.localdomain> Message-ID: References: <200304170117.h3H1HRQ06771@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: On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote: > On Tue, 15 Apr 2003 at 16:57:04 -0600 (MDT) Alex Rousskov announced: > > > OCP Core does not forbid several OCP connection over one transport > > connection (bugs notwithstanding). OCP Core says, in part > > ("Connections" section, blob 87): > > > If BEEP over TCP is used, than a BEEP channel will correspond > > to a callout connection, allowing callout connection > > multiplexing over a single TCP connection. > > > What made you think that "OCP forbids it"? > > These words: > For example, if raw TCP is the transport, than a TCP connection > will correspond to a callout connection. which is true unless we want to add connection IDs to OCP. Without explicit connection IDS it is not possible to have multiple OCP connection over a transport connection that does not support embedded "channels" or "sessions". I would be happy to add connection IDs if needed, but it may be a good idea to decide on the transport binding(s) first in case we decide on a single binding that makes connection IDs unnecessary. > > OCP Core supports heartbeats via and > > messages. Those are actually very useful because OCP Core relies on > > timeouts to resolve possible problems with overloaded or > > malfunctioning agents and timeouts without heartbeats do not work well > > for "slow" adaptations. > > I think "heartbeat" generally means that a message every n time units is > required - there's no "are you there". Yes. OCP agents can implement heartbeat by sending messages at regular time intervals if desired. I do not see a need to make that a default/required behavior though. Do you? > > > Reviewing the messages on this list, I find myself deeply uncertain > > > about what would be in "OCP/HTTP bindings". Would it be an encoding > > > of the OCP protocol elements (transaction start, transaction id, > > > etc.) as HTTP-style headers? > > > You may be confusing/mixing OCP transport binding and > > application-specific drafts. We have not decided on OCP transport > > binding. In theory, it can be HTTP like in ICAP. If that is the case, > > then either OCP Core (if there is only one transport binding) or HTTP > > Transport Binding for OCP (if there are multiple transport bindings) > > drafts will indeed document how to convert OCP protocol elements to > > HTTP elements. > > Then there are two distinct options being considered, as you say: > > 1. A single transport for OCP. > 2. Multiple transports for OCP. > > If there is a single transport, then there will be a single document > showing how to encode the OCP protocol elements into bitstrings carried over > that transport. > > If there are multiple transports, then there will be a document for each > transport showing how to encode the OCP protocol elements into bitstrings > carried over that transport. Those would be OCP/HTTP, OCP/RTP, OCP/TCP, > OCP/BEEP, perhaps. With other possibilties, such as OCP/SNMP. OCP/FTP, > OCP/WEP, .... Yes, that is exactly what I was trying to say. In case of a single binding, there is probably no need for a separate "transport" document -- everything transport-related can be integrated into OCP Core. > Lurking in the wings is the idea of a new transport, call it OCPTRAN for > the moment (or "copper" :-) see later), running over one or more of > TCP, UDP, IP, BEEP?, ... Exactly :-) > The OCP document as it stands now is a data model and state machine. It is > awaiting WG decision on the issue of transport. > > OK so far? Yes, we are in agreement. > One thing that might help with clarity is to note that we have been > talking about using a Layer 4 transport as OCP transport sometime, > but other times we are talking about using a Layer 5 protocols as an > OCP transport. I will add such a note to the Core draft. > What bothers me is the issue of the nature of the proxied protocols > and whether or not each one needs its own OCP binding. We know that > HTTP, with only minor modifications, can be the OCP transport for a > proxied HTTP connection. Can/should it be the OCP transport for > FTP? For SNMP? For telnet? That possibility is what led to the > awkward architecture for protocol conversion, using OCP transport X > for requests and getting the reply back on transport Y! I agree that proxied protocols may benefit from a particular OCP transport. That would be the primary argument to support multiple transports. However, IMO, HTTP makes a very poor OCP transport regardless of the proxied protocol. HTTP is simply not designed for that. I can provide specific arguments if anybody cares to listen. I think ICAP suffers a lot in clarity (and, perhaps even features/performance) due to an unfortunate choice of transport. Martin will probably disagree. I think BEEP is a much better fit. I do not have a strong opinion about this though (yet?). > There are pros and cons here. Using a "native" callout protocol > (HTTP over HTTP, SNMP over SNMP, RTP over RTP, etc.) is a quick way > to get going - the person who knows the protocol can probably figure > out a quick way to get the callout protocol implemented, the framing > and other issues are simpler if you aren't changing protocols, > libraries can be reused, etc. The con is that the OPES processor > may become bogged down with too many pieces of client-side code. > There must be other issues. I disagree that framing is simpler. I agree that learning curve is less steep and that [good] libraries can be reused. I would address the learning curve issue by selecting a very simple transport/encoding model. I would address the code reuse issue by selecting a well-supported (existing) or very simple (new) encoding. > If there is only one transport protocol, then it may become > complicated with too many features as it tries to encompass all the > different framing methods, reliability issues, etc. Or, it might be too simple to support some esoteric corner cases efficiently. I would strive for the latter rather than designing a transport "behemoth". > My opinion is that if we decide on only one transport, that it *not* > be tied to HTTP, that it be as lightweight as possible. I agree. That is what makes raw TCP or perhaps BEEP attractive to me. > (By the way, I'm in touch with someone who says he's got documented > timings of the overhead involved in parsing a null XML message with > standard commercial software - 30 times the effort of a simple TCP > connection sending one byte back and forth; I'm trying to get his > tech report). I would be very interested to see this report because I am surprised by the conclusion. Perhaps "standard commercial software" means "unoptimized commercial software" (in which case I would not care much -- general-purpose parsers can be slow and I bet the TCP stack they used had been optimized many times). > Personally, I think the best choice is a new transport named OCPTRAN > that can run over TCP for data that needs reliable service and can > also run over UDP or just IP if need be. I'm not sure where BEEP > fits in this taxonomy - it seems to be orthogonal (in the sense of > "not a branch point" rather than "useless"). I hear you, but when I read http://www.clipcode.com/peer/beep_technical_whitepaper.htm I feel guilty for not using BEEP and inventing yet another *TRANP. I have not finished reading or digesting the paper though. If by "not a branch point" you mean "we would still need to decide on BEEP transport (BEEP over what)", then I agree. > > > I cannot keep myself from stumbling over "application message" time > > > and again. And again. The stuff between the OPES processor and > > > callout server that might be encapsulated data coming from or going > > > to the proxied transaction ... can that have an unambiguous name, > > > like "zinc", if there's nothing better? > > > Except for section 1.1, there should be no mentioning of "proxied" > > anything. The fact that OPES processor is a proxy is out of OCP scope, > > and section 1.1 attempts to document that. "Application message" is > > whatever OPES processor and callout server what it to be, essentially. > > I would not like "zinc", but would very welcome better alternatives to > > describe an undefined (content, metadata) pair. > > Even if the draft doesn't refer to proxied data, the concept is still > there, and "application message" will continue to seem ambiguous, to > me, anyway. Yes. > How can you not like "zinc"? OSERVICE-BLOB? OUTBOARD-SERVICE-DATA? "Blob" is close. What do you call a blob tuple (metadata + data)? Blot? Blop (for blob pair)? Plob (for pair of blobs?) Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 06:02:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14103 for ; Thu, 17 Apr 2003 06:02:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1966G5-0006PZ-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 06:04:45 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1966G4-0006PW-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 06:04:44 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H9k1t2027323 for ; Thu, 17 Apr 2003 02:46:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H9k1cM027322 for ietf-openproxy-bks; Thu, 17 Apr 2003 02:46:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H9k0t2027313 for ; Thu, 17 Apr 2003 02:46:00 -0700 (PDT) (envelope-from info@utel.net) Received: from f06a-9-110.d1.club-internet.fr ([212.194.128.110] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 1965xt-000217-00 for ietf-openproxy@imc.org; Thu, 17 Apr 2003 02:45:58 -0700 Message-Id: <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 17 Apr 2003 11:53:46 +0200 To: ietf-openproxy@imc.org From: jfcm Subject: Re: OCP questions In-Reply-To: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> 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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think I agree with most of this and accept most of the pending points. I only feel that simplicity/complexity will depend on the modelization defining where OPES boarders are. If you include all the possible plugs it may have to use in the design of a device, you will get a more complex device. And you will not be sure it can be used worldwide. If you get it a transformer and make it frequency indepedant you have probably more chances. But you need to get local converters. At 07:31 17/04/03, Alex Rousskov wrote: >On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > Personally, I think the best choice is a new transport named OCPTRAN > > that can run over TCP for data that needs reliable service and can > > also run over UDP or just IP if need be. I'm not sure where BEEP > > fits in this taxonomy - it seems to be orthogonal (in the sense of > > "not a branch point" rather than "useless"). > >I hear you, but when I read > http://www.clipcode.com/peer/beep_technical_whitepaper.htm >I feel guilty for not using BEEP and inventing yet another *TRANP. I >have not finished reading or digesting the paper though. If by "not a >branch point" you mean "we would still need to decide on BEEP >transport (BEEP over what)", then I agree. Would you be so kind to give us a brief on your finding/feeling when you are finished. I think it might help (me/us?) a lot. Thank you. jfc From owner-ietf-openproxy@mail.imc.org Thu Apr 17 13:02:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28557 for ; Thu, 17 Apr 2003 13:02:12 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196CoQ-0001Kn-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 13:04:38 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196CoP-0001Kk-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 13:04:37 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGmct2052764 for ; Thu, 17 Apr 2003 09:48:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HGmcvJ052763 for ietf-openproxy-bks; Thu, 17 Apr 2003 09:48: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.8p1/8.12.8) with ESMTP id h3HGmat2052758 for ; Thu, 17 Apr 2003 09:48:36 -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 h3HGmbvj034494 for ; Thu, 17 Apr 2003 10:48:37 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HGmbX7034493; Thu, 17 Apr 2003 10:48:37 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 10:48:37 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: BEEP as OCP transport In-Reply-To: <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@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: BEEP is a good candidate for OCP transport. Here are a few major arguments for/against using BEEP as OCP transport. I hope that Marshall Rose can review this and offer his insight both as BEEP author and as a co-author of a syslog protocol build on top of BEEP. 1. BEEP exists but is new BEEP Core specification is a stable "Standards Track" RFC. However, only few protocols over BEEP have been documented and, as far as I can tell, none are super popular yet. This means that we do not need to reinvent the wheel, but we may also find yet-unknown problems with the existing wheel design. 2. BEEP uses XML If we choose BEEP, any compliant implementation would have to parse XML elements. BEEP documentation asserts that many great XML libraries exist, some optimized for performance. While I agree, I also assert that most (if not all) of the existing libraries are usually not suitable "as is" for a given decent-size project that is concerned with efficiency, portability and/or licensing restrictions. I do not see much MIME code reuse in HTTP implementations and I expect the same to be true about similar XML-based protocols. Using BEEP for OCP essentially implies that every OPES processor or callout server will have to include an XML library. Unless we think that this is already the case for 90% of implementations that will support OCP, we should think twice about this new burden. On the other hand, we could try to make OCP/BEEP less extensible but also less XML-dependent by mandating or recommending semi-fixed structure of required XML elements. Parsing or generating such elements would be simple and possible without any XML library. This kind of violates protocol boundaries (though BEEP appears to do similar things when it limits XML to exclude entity references). 3. BEEP is connection oriented Some suggested that there should be OCP transport that can run on top of UDP or even raw IP. Selecting BEEP would then imply that we need two transport protocols because BEEP cannot run on top of UDP. However, lossy protocols such as UDP or raw IP are prohibited by OCP requirements draft. Moreover, no arguments have been made (yet) to justify the need for a lossy transport. Moreover (Marshall, please do not read this sentence), it is probably technically possible to implement BEEP on top of UDP to preserve the same high-level semantics. One would essentially have to define what to do when a UDP or IP packet is lost and implement congestion avoidance. I hope we do not have to do this ugly hack though. 4. BEEP exchange styles are close fit, but not perfect BEEP requires replies to every BEEP MSG. OCP does not. We can add "null" replies, of course, but the protocol does not need them (it would be a waste from technical point of view). Some might argue that mandatory replies will actually make OCP easier to understand. I wonder why BEEP assumes that replies must be required (being so flexible in other aspects), but it is probably too late to change that assumption. Can BEEP exchange styles be extended? Probably not without losing compatibility with existing BEEP libraries. 5. BEEP Core does not determine transport We would still have to decide whether OCP runs on top of BEEP/TCP only or allow other BEEP transport bindings. 6. BEEP Core does not determine encoding We would still have to decide how to encode OCP messages. BEEP defaults to application/beep+xml, but other MIME types can be used. 7. BEEP channels allow simple low-overhead OCP connections From owner-ietf-openproxy@mail.imc.org Thu Apr 17 13:16:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29136 for ; Thu, 17 Apr 2003 13:16:10 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196D1w-0001Sp-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 13:18:36 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196D1v-0001Sm-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 13:18:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HH66t2053354 for ; Thu, 17 Apr 2003 10:06:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HH66gO053353 for ietf-openproxy-bks; Thu, 17 Apr 2003 10:06: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.8p1/8.12.8) with ESMTP id h3HH64t2053348 for ; Thu, 17 Apr 2003 10:06: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 h3HH5xvj034859; Thu, 17 Apr 2003 11:05:59 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HH5xl2034858; Thu, 17 Apr 2003 11:05:59 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 11:05:59 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: OCPTRAN as OCP transport In-Reply-To: Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@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: On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote: > Personally, I think the best choice is a new transport named OCPTRAN > that can run over TCP for data that needs reliable service and can > also run over UDP or just IP if need be. If the group is convinced that designing a new transport is a good idea, one way to proceed is to take BEEP, remove its XML dependency (unless we choose to use XML for OCP messages) and remove mandatory responses. Doing just that will allow us to reuse a lot of existing documentation (and even code). Hilarie, could you please try to convince us that new transport is needed assuming no UDP support is required? Hmm... The above can be rephrased in a more direct way, I guess: Hilarie, what is wrong with BEEP, assuming no UDP support is required? Once we know what is wrong, we can see what it would take to fix it. If the group is further convinced that unreliable transport support is needed, I would suggest that we add lossy transport support to the above. Hilarie, could you please try to convince us that unreliable transport support is required? More specifically, what kind of application protocols cannot be adapted with OCP/TCP using a reasonable set of OCP transaction timeouts to accomodate slow callout servers or bad connectivity to them? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 13:37:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29723 for ; Thu, 17 Apr 2003 13:37:47 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196DMr-0001ZQ-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 13:40:13 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196DMr-0001ZN-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 13:40:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHSct2054158 for ; Thu, 17 Apr 2003 10:28:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HHSc1i054157 for ietf-openproxy-bks; Thu, 17 Apr 2003 10:28:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHSbt2054150 for ; Thu, 17 Apr 2003 10:28:37 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3HHSL1w000754; Thu, 17 Apr 2003 10:28:21 -0700 (PDT) Date: Thu, 17 Apr 2003 10:28:20 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport Message-Id: <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> In-Reply-To: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit as requested by alex, i'll reply. speaking as the beep guy, instead of the co-chair: > 1. BEEP exists but is new > > BEEP Core specification is a stable "Standards Track" RFC. > However, only few protocols over BEEP have been documented > and, as far as I can tell, none are super popular yet. > This means that we do not need to reinvent the wheel, but > we may also find yet-unknown problems with the existing > wheel design. i think your greater risk in terms of whether you can find a library you like or whether you have to role your own. experience with reliable syslog shows that the libraries out there are "too general" for what syslog implementors want. unfortunately, those implementors found that out the hard way, i.e., they invested a lot if using a library instead of just rolling their own implementation. further, some of the non-commercial libraries out there are GPL'd, which many open-source and commercial implementors reject because of the down-stream constraints it places on their code. (it was a bit of an eye-opener to hear that even the open-source guys think this way.) the choice of whether you use a library or roll-your-own all comes down to "cost", which includes things like price (free or not), but also includes things like the integration cost (e.g., same language, same threading model, required libraries, etc.) certainly many of the reliable syslog implementors i've talked to feel they would have been better served by rolling their own... > 2. BEEP uses XML xml is mandatory in beep for channel management, that's it. the subset that of xml that beep uses means that you can take something like expat and easily integrate it. for an ocp channel, you can use any format you want. beep doesn't care. it gives you an 8-bit clean container. after that, it's up to you. > 3. BEEP is connection oriented the only protocol i've ever seen that had a reason for being both CO and CL is the DNS, and even then, the kind of transactions being used by the DNS for CO and CL vary dramatically. if it makes sense to use ocp in a CL mode, don't consider beep. do something else. > 4. BEEP exchange styles are close fit, but not perfect > > BEEP requires replies to every BEEP MSG. OCP does not. > We can add "null" replies, of course, but the > protocol does not need them (it would be a waste from > technical point of view). > Some might argue that mandatory replies will actually > make OCP easier to understand. the reason why MSG's get a response is because until you see the response, you never know if the the MSG actually got to the other side and got worked on. ultimately, it's the application, and not the transport, that's responsible for things like that (cf., Clark, etc.). if you want to do some kind of streaming thing in OCP, you can look at the way syslog reliable does it. darren came up with that and it's fairly elegant. > I wonder why BEEP assumes that replies must be required > (being so flexible in other aspects), but it is > probably too late to change that assumption. Can BEEP > exchange styles be extended? Probably not without > losing compatibility with existing BEEP libraries. you'd need to define a beep feature negotiation to do that. > 5. BEEP Core does not determine transport > > We would still have to decide whether OCP runs > on top of BEEP/TCP only or allow other BEEP > transport bindings. realistically, does something besides TCP have any significant presence? > 6. BEEP Core does not determine encoding > > We would still have to decide how to encode OCP > messages. BEEP defaults to application/beep+xml, > but other MIME types can be used. true. see my answer to (2) above. > 7. BEEP channels allow simple low-overhead OCP connections i'm not sure what this means. if you take a look at the xmlconf stuff, they have a specialized application which requires multiple parallel running in the same authentication context. they use beep for that. even if you don't have the multiplicity requirement, using beep means you never have to screw around defining authentication/privacy stuff, because beep comes with sasl and/or tls. if you find yourself defining a protocol that has a lot of administrative overhead (e.g., negotiation, security, etc.), then odds are you should have looked at beep before specifying all that stuff. however, you should always use the best tool for the job. if beep is overkill, don't use it. /mtr From owner-ietf-openproxy@mail.imc.org Thu Apr 17 14:22:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01010 for ; Thu, 17 Apr 2003 14:22:02 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196E3h-0001lC-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 14:24:29 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196E3g-0001l9-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 14:24:28 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIAAt2055812 for ; Thu, 17 Apr 2003 11:10:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIAAds055811 for ietf-openproxy-bks; Thu, 17 Apr 2003 11:10:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIA9t2055803 for ; Thu, 17 Apr 2003 11:10:09 -0700 (PDT) (envelope-from rpenno@nortelnetworks.com) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HI9uV29880; Thu, 17 Apr 2003 11:09:56 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2R1BXYJ9>; Thu, 17 Apr 2003 11:09:41 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18EB0@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , ietf-openproxy@imc.org Subject: Capability Negotiation for OCP Date: Thu, 17 Apr 2003 11:09:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3050C.8054A726" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C3050C.8054A726 Content-Type: text/plain These are my ideas on capability negotiation. They are a mix of SDP's offer/answer, BGP and PPP. I wait for comments before I expand the sections. ----------- * The requirements for the capability negotiation are: - Small number of RTTs - Simple but extensible - Able to negotiate different capabilities for transaction, connection, channel and device level. (did I miss any layer?) - Able to negotiate capabilities for a different processing layer (for example, inside a channel you can alter the capabilities for the device level, or inside a transaction you can alter the capabilities for the channel). * Capabilities Capabilities are expressed with a identifier and a value. Depending on the OCP protocol the WG chooses, this can be achieved by a TLV field or a text based notation The same capability can be included in a packet more than once if they are on different scopes (e.g., device vs. transaction). * Packet Format The capability negotiation packet is divided in several scopes (device, transaction, channel, etc). In each scope any number of capabilities and their respective values can be included. The capability negotiation packets also includes a identifier so that the peers can match packets belonging to the same negotiation. There are 4 different types of capability negotiation packets: , , and * Capability Negotiation The capability negotiation starts with a packet in which the initiator (OPES processor or Callout server) lists the desired capabilities and their respectrive values in each scope. To every sent by the initiator, the non-initiator (OCP peer) sends an packet listing the capabilities it would prefer a different value and the ones it does not understand at all. Based on the answer of its peer, the initiator of the capability negotiation can send a packet and raise an event or try again with the changes proposed by its peer. When the OCP peers have reached an agreement the non-initiator will send an packet which indicate the end of the capability negotiation process. It is expected that no more than 4 messages will be required for the peers to reach a agreement: , with a different proposal, final , . If one of the peers does not want to carry the capability negotiation any further, it can send a packet. The packet should contain the reason for the failure. More specifically, the message must contain for each offending capability the offered value and the value proposed by the peer. It is important to notice the capability negotiation process can occur anytime during the life of a OCP transport connection (for the lack of a better term), not necessarily when a connection/channel/transaction is established. ---------- ------_=_NextPart_001_01C3050C.8054A726 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Capability Negotiation for OCP

These are my ideas on capability negotiation. They = are a mix of SDP's offer/answer, BGP and PPP. I wait for comments = before I expand the sections.

-----------

* The requirements for the capability negotiation = are:

- Small number of RTTs
- Simple but extensible
- Able to negotiate different capabilities for = transaction, connection, channel and device level. (did I miss any = layer?)

- Able to negotiate capabilities for a different = processing layer (for example, inside a channel you can alter the = capabilities for the device level, or inside a transaction you can = alter the capabilities for the channel).

* Capabilities

Capabilities are expressed with a identifier and a = value. Depending on the OCP protocol the WG chooses, this can be = achieved by a TLV field or a text based <name:value> = notation

The same capability can be included in a packet more = than once if they are on different scopes (e.g., device vs. = transaction).

* Packet Format

The capability negotiation packet is divided in = several scopes (device, transaction, channel, etc). In each scope any = number of capabilities and their respective values can be = included.

The capability negotiation packets also includes a = identifier so that the peers can match packets belonging to the same = negotiation.

There are 4 different types of capability negotiation = packets: <offer>, <answer>, <success> and = <failure>

* Capability Negotiation

The capability negotiation starts with a = <offer> packet in which the initiator (OPES processor or Callout = server) lists the desired capabilities and their respectrive values in = each scope.

To every <offer> sent by the initiator, the = non-initiator (OCP peer) sends an <answer> packet listing the = capabilities it would prefer a different value and the ones it does not = understand at all.

Based on the answer of its peer, the initiator of the = capability negotiation can send a <failure> packet and raise an = event or try again with the changes proposed by its peer. When the OCP = peers have reached an agreement the non-initiator will send an = <success> packet which indicate the end of the capability = negotiation process.

It is expected that no more than 4 messages will be = required for the peers to reach a agreement: <offer>, = <answer> with a different proposal, final <offer>, = <success>.

If one of the peers does not want to carry the = capability negotiation any further, it can send a <failure> = packet. The <failure> packet should contain the reason for the = failure. More specifically, the message must contain for each offending = capability the offered value and the value proposed by the peer. =

It is important to notice the capability negotiation = process can occur anytime during the life of a OCP transport connection = (for the lack of a better term), not necessarily when a = connection/channel/transaction is established.

----------

------_=_NextPart_001_01C3050C.8054A726-- From owner-ietf-openproxy@mail.imc.org Thu Apr 17 14:34:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01427 for ; Thu, 17 Apr 2003 14:34:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196EFG-0001os-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 14:36:26 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196EFF-0001op-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 14:36:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIMLt2056069 for ; Thu, 17 Apr 2003 11:22:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIMLj0056068 for ietf-openproxy-bks; Thu, 17 Apr 2003 11:22:21 -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.8p1/8.12.8) with ESMTP id h3HIMJt2056063 for ; Thu, 17 Apr 2003 11:22: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 h3HIM9vj037754; Thu, 17 Apr 2003 12:22:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HIM9RV037753; Thu, 17 Apr 2003 12:22:09 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 12:22:09 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport In-Reply-To: <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> 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: On Thu, 17 Apr 2003, Marshall Rose wrote: > > 1. BEEP exists but is new > > i think your greater risk in terms of whether you can find a > library you like or whether you have to role your own. > > experience with reliable syslog shows that the libraries out > there are "too general" for what syslog implementors want. > unfortunately, those implementors found that out the hard way, i.e., > they invested a lot if using a library instead of just rolling their > own implementation. > > further, some of the non-commercial libraries out there are > GPL'd, which many open-source and commercial implementors reject > because of the down-stream constraints it places on their code. (it > was a bit of an eye-opener to hear that even the open-source guys > think this way.) > > the choice of whether you use a library or roll-your-own all > comes down to "cost", which includes things like price (free or > not), but also includes things like the integration cost (e.g., same > language, same threading model, required libraries, etc.) > > certainly many of the reliable syslog implementors i've talked to > feel they would have been better served by rolling their own... I share this experience in other protocols/areas. There are just to many variables to find a good fit between a general-purpose protocol library and a decent-size project. This is why I am also concerned with XML! > > 2. BEEP uses XML > > xml is mandatory in beep for channel management, that's it. the > subset that of xml that beep uses means that you can take something > like expat and easily integrate it. ... if you already use C language, do not have performance or memory management problems with expat ways of doing things, and are OK with MIT license. This is actually what surprises me about the XML choice for BEEP Core -- its use is so limited that it is hard to justify! If somebody takes a shortcut in supporting the XML part of BEEP, it would be trivial to prove that their implementation is not OCP compliant by sending an "interesting" (difficult to parse but valid) XML element as a part of a channel management routine. Thus, we would either have to close our eyes on this problem and test with simple XML elements only, or we would have to acknowledge that many (most?) OCP implementations are not really compliant. Not a nice choice. The same can be said about MIME, I guess. Most HTTP implementations fail to parse at least some "interesting" MIME-like headers (quotations, escapes, multiple lines via LWS, etc.). This is really unfortunate and does lead to compatibility problems long-term. What do you think about documenting an even simpler XML subset and recommending (requiring?!) its use within OCP/BEEP? Would that help at all? Did you consider that option when designing BEEP? > for an ocp channel, you can use any format you want. beep doesn't > care. it gives you an 8-bit clean container. after that, it's up to > you. Yes; I should have stated that in the original summary. > > 3. BEEP is connection oriented > > the only protocol i've ever seen that had a reason for being both CO > and CL is the DNS, and even then, the kind of transactions being > used by the DNS for CO and CL vary dramatically. > > if it makes sense to use ocp in a CL mode, don't consider beep. > do something else. I should have said "BEEP is a lossless protocol". However, your DNS comment is important. Let's wait for Hilarie to drive that lossy transport argument. > > 4. BEEP exchange styles are close fit, but not perfect > > > > BEEP requires replies to every BEEP MSG. OCP does not. > > We can add "null" replies, of course, but the > > protocol does not need them (it would be a waste from > > technical point of view). > > Some might argue that mandatory replies will actually > > make OCP easier to understand. > > the reason why MSG's get a response is because until you see the > response, you never know if the the MSG actually got to the other side > and got worked on. ultimately, it's the application, and not the > transport, that's responsible for things like that (cf., Clark, etc.). Yes, that is why the always-respond restriction in BEEP seems out of place. Some applications (like OCP) do not care whether certain OCP messages are already being worked on (a pipeline model). > if you want to do some kind of streaming thing in OCP, you can look > at the way syslog reliable does it. darren came up with that and > it's fairly elegant. Do you mean a stream of ANS frames, with optional in-frame aggregation of syslog messages? Aggregation aside, that seems like the only sane way to do "streaming" or "pipeline" with BEEP. I kept the same approach in mind when considering OCP over BEEP. Or are you talking about something else? I would not recommend using aggregation trick with OCP though. > > Can BEEP > > exchange styles be extended? Probably not without > > losing compatibility with existing BEEP libraries. > > you'd need to define a beep feature negotiation to do that. Interesting point! > > 5. BEEP Core does not determine transport > > > > We would still have to decide whether OCP runs > > on top of BEEP/TCP only or allow other BEEP > > transport bindings. > > realistically, does something besides TCP have any significant presence? No, unless Hilarie manages to convince the group that lossy transports such as UDP must be supported (which would create its own problems because BEEP cannot run on top of UDP as-is). > > 6. BEEP Core does not determine encoding > > > > We would still have to decide how to encode OCP > > messages. BEEP defaults to application/beep+xml, > > but other MIME types can be used. > > true. see my answer to (2) above. > > > > 7. BEEP channels allow simple low-overhead OCP connections > > i'm not sure what this means. if you take a look at the xmlconf > stuff, they have a specialized application which requires multiple > parallel running in the same authentication context. they use beep > for that. > even if you don't have the multiplicity requirement, using beep > means you never have to screw around defining authentication/privacy > stuff, because beep comes with sasl and/or tls. > if you find yourself defining a protocol that has a lot of > administrative overhead (e.g., negotiation, security, etc.), then > odds are you should have looked at beep before specifying all that > stuff. I agree. #7 is a "for BEEP" argument. BEEP channels are a perfect match for what OCP connections are. OCP connections are not really "connections" from transport point of view; more like sessions. Most OCP negotiations can be done on BEEP session basis (TCP connection), allowing for low-overhead OCP connections (BEEP channels). > however, you should always use the best tool for the job. if beep is > overkill, don't use it. Thanks for a detailed response! Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 15:00:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02452 for ; Thu, 17 Apr 2003 15:00:12 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Eec-00020d-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 15:02:38 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196Eec-00020a-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 15:02:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIqXt2057279 for ; Thu, 17 Apr 2003 11:52:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIqXfq057278 for ietf-openproxy-bks; Thu, 17 Apr 2003 11:52:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIqVt2057273 for ; Thu, 17 Apr 2003 11:52:32 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3HIqU1w000966; Thu, 17 Apr 2003 11:52:30 -0700 (PDT) Date: Thu, 17 Apr 2003 11:52:30 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport Message-Id: <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> In-Reply-To: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit again, speaking as the beep guy, not the co-chair: > I share this experience in other protocols/areas. There are just to > many variables to find a good fit between a general-purpose protocol > library and a decent-size project. This is why I am also concerned > with XML! all i can say is that your perception about xml appears to be at variance with my impression of a lot of other people's perceptions. > ... if you already use C language, do not have performance or memory > management problems with expat ways of doing things, and are OK with > MIT license. This is actually what surprises me about the XML choice > for BEEP Core -- its use is so limited that it is hard to justify! see above. > If somebody takes a shortcut in supporting the XML part of BEEP, it > would be trivial to prove that their implementation is not OCP > compliant by sending an "interesting" (difficult to parse but valid) > XML element as a part of a channel management routine. the xml subset used by beep makes that rather difficult. > Thus, we would > either have to close our eyes on this problem and test with simple XML > elements only, or we would have to acknowledge that many (most?) OCP > implementations are not really compliant. Not a nice choice. i think it's a false choice. anyone who can wade through and understand the opes specifications, will have no difficulty dealing with xml. let's keep our perspective here. > The same can be said about MIME, I guess. Most HTTP implementations > fail to parse at least some "interesting" MIME-like headers > (quotations, escapes, multiple lines via LWS, etc.). This is really > unfortunate and does lead to compatibility problems long-term. > > What do you think about documenting an even simpler XML subset and > recommending (requiring?!) its use within OCP/BEEP? Would that help at > all? Did you consider that option when designing BEEP? no, because then you move out of the realm of widely-deployed tools. that's why canonical xml is a bad thing: it requires the use of special-purpose libraries. > > > 4. BEEP exchange styles are close fit, but not perfect > > > > > > BEEP requires replies to every BEEP MSG. OCP does not. > > > We can add "null" replies, of course, but the > > > protocol does not need them (it would be a waste from > > > technical point of view). > > > Some might argue that mandatory replies will actually > > > make OCP easier to understand. > > > > the reason why MSG's get a response is because until you see the > > response, you never know if the the MSG actually got to the other side > > and got worked on. ultimately, it's the application, and not the > > transport, that's responsible for things like that (cf., Clark, etc.). > > Yes, that is why the always-respond restriction in BEEP seems out of > place. Some applications (like OCP) do not care whether certain OCP > messages are already being worked on (a pipeline model). ok, do you care that they actually got there or not? > > if you want to do some kind of streaming thing in OCP, you can look > > at the way syslog reliable does it. darren came up with that and > > it's fairly elegant. > > Do you mean a stream of ANS frames, with optional in-frame aggregation > of syslog messages? Aggregation aside, that seems like the only sane > way to do "streaming" or "pipeline" with BEEP. I kept the same > approach in mind when considering OCP over BEEP. Or are you talking > about something else? if you don't need an acknowledgement for each MSG, you can do what reliable syslog does, wherein the server sends a MSG when the channel opens, and the client sends back zero or more ANS in response. /mtr From owner-ietf-openproxy@mail.imc.org Thu Apr 17 15:05:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02827 for ; Thu, 17 Apr 2003 15:05:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Ejl-00022Q-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 15:07:57 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196Ejk-00022N-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 15:07:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIvWt2057433 for ; Thu, 17 Apr 2003 11:57:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIvWPZ057432 for ietf-openproxy-bks; Thu, 17 Apr 2003 11:57:32 -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.8p1/8.12.8) with ESMTP id h3HIvVt2057425 for ; Thu, 17 Apr 2003 11:57:31 -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 h3HIvWvj038656; Thu, 17 Apr 2003 12:57:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HIvWdW038655; Thu, 17 Apr 2003 12:57:32 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 12:57:32 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Capability Negotiation for OCP In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18EB0@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18EB0@zsc3c026.us.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: On Thu, 17 Apr 2003, Reinaldo Penno wrote: > These are my ideas on capability negotiation. They are a mix of > SDP's offer/answer, BGP and PPP. Sounds like a great start to me. I am sure we will run into arguments once the wording becomes more specific. One high-level thing to consider now is scope (level) definition: Do we want to have a fixed number of levels associated with OCP entities like connection and transaction? Or do we want to allow unlimited nesting? For example, is it possible that something needs to be re-negotiated in the middle of a transaction? Another issue: are negotiations always limited in scope to a single transport connection? Are we worried that two connections to the same IP may not end up at the same callout server? In other words, if an OPES processor wants to open 10 connections to a callout server, does it need to negotiate each from scratch OR can it refer to earlier ("cached") negotiations? Semantically, does describe sender characteristics "I can use Foo" or can it describe sender desires (recipient characteristics) "Please use Foo" as well? For example, how can a callout server change OPES processor copying state from "yes" to "no" in the middle of an OCP connection? Using "Processor-uses-copying" property? How is the order of negotiations determined -- what if both OPES processor and callout server send messages "at once"? Finally, can we define a complete set of parameters that MUST be negotiated for OCP Core? Let's not spent too much effort on what you call "packet format" now. The choice of transport protocol and encoding will have a major impact on that, I think. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 15:38:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04763 for ; Thu, 17 Apr 2003 15:38:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196FFU-000297-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 15:40:44 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196FFT-000294-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 15:40:43 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJQYt2058490 for ; Thu, 17 Apr 2003 12:26:34 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJQYGb058489 for ietf-openproxy-bks; Thu, 17 Apr 2003 12:26:34 -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.8p1/8.12.8) with ESMTP id h3HJQWt2058484 for ; Thu, 17 Apr 2003 12:26:32 -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 h3HJQXvj039355; Thu, 17 Apr 2003 13:26:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HJQXL2039354; Thu, 17 Apr 2003 13:26:33 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 13:26:33 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport In-Reply-To: <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> 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: On Thu, 17 Apr 2003, Marshall Rose wrote: > all i can say is that your perception about xml appears to be at > variance with my impression of a lot of other people's perceptions. Good! Since my view is rather pessimistic, I would rather be proven wrong. :) > > If somebody takes a shortcut in supporting the XML part of BEEP, it > > would be trivial to prove that their implementation is not OCP > > compliant by sending an "interesting" (difficult to parse but valid) > > XML element as a part of a channel management routine. > > the xml subset used by beep makes that rather difficult. > > > Thus, we would either have to close our eyes on this problem and > > test with simple XML elements only, or we would have to > > acknowledge that many (most?) OCP implementations are not really > > compliant. Not a nice choice. > > i think it's a false choice. anyone who can wade through and understand > the opes specifications, will have no difficulty dealing with xml. let's > keep our perspective here. It is not a question of misinterpreting the specs. The shortcut I am talking about is a deliberate action. For example: "For simplicity, we will assume that CDATA will never be sent to our server as a part of BEEP channel management; let's not handle CDATA!". And then some OPES processor decides to send its copyright statement in CDATA... > > What do you think about documenting an even simpler XML subset and > > recommending (requiring?!) its use within OCP/BEEP? Would that > > help at all? Did you consider that option when designing BEEP? > > no, because then you move out of the realm of widely-deployed tools. > that's why canonical xml is a bad thing: it requires the use of > special-purpose libraries. Right. Since I assume that most decent implementations will have to use special-purpose libraries anyway, it is not a problem for me. So it all boils down to whether appropriate XML libraries are available for the majority of real-world implementations we care about. I am skeptical; you say the majority think that they are indeed available. > > > the reason why MSG's get a response is because until you see the > > > response, you never know if the the MSG actually got to the other side > > > and got worked on. ultimately, it's the application, and not the > > > transport, that's responsible for things like that (cf., Clark, etc.). > > > > Yes, that is why the always-respond restriction in BEEP seems out of > > place. Some applications (like OCP) do not care whether certain OCP > > messages are already being worked on (a pipeline model). > > ok, do you care that they actually got there or not? I know they would get there because I use lossless transport (I would be notified if something goes wrong). I do not care about the timing though (because it is a pipeline/stream). I am only interested in the adapted data sent back; that adapted data may come at any time, even before [some of] my original data reaches the other end(!)... > if you don't need an acknowledgement for each MSG, you can do what > reliable syslog does, wherein the server sends a MSG when the > channel opens, and the client sends back zero or more ANS in > response. Yes, of course. The problem is that the server does not "want" to send any MSG until it gets data from the processor. I understand how to hack what I need using BEEP mechanisms, but they seem to go against the logic/semantics of what is going on. What I need is: Processor(client): start, data-have, data-have, data-have, ... end Server: start, data-have, data-have, ... end without much of a relationship between the two lines/flows. What I would have to do with BEEP is: Processor(client): server-can-start(MSG) Server: processor-can-start(MSG) Processor(client): start(ANS), data-have(ANS), data-have(ANS)... Server: start(ANS), data-have(ANS), data-have(ANS)... or some variation of the above. The first two messages are not needed from OCP point of view, but are required by BEEP because it supports multiple responses for one request but not multiple requests with one response (essentially). We may be able to hide server-can-start and processor-can-start MSGs behind some other OCP messages that must be sent anyway, but that may increase the confusion. Is there a better way? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 17:02:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07915 for ; Thu, 17 Apr 2003 17:02:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GZN-0002fb-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 17:05:21 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196GZN-0002fY-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 17:05:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKpMt2060850 for ; Thu, 17 Apr 2003 13:51:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HKpMqF060849 for ietf-openproxy-bks; Thu, 17 Apr 2003 13:51:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKpLt2060843 for ; Thu, 17 Apr 2003 13:51:21 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3HKtkKq000488; Thu, 17 Apr 2003 14:55:47 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3HKqjK29413; Thu, 17 Apr 2003 14:52:45 -0600 Date: Thu, 17 Apr 2003 14:52:45 -0600 Message-Id: <200304172052.h3HKqjK29413@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rpenno@nortelnetworks.com Cc: ietf-openproxy@imc.org, rousskov@measurement-factory.com In-reply-to: Yourmessage <0A11633F61BD9F40B43ABCC694004F93F18EB0@zsc3c026.us.nortel.com> Subject: Re: Capability Negotiation for OCP Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Channel" and "device" are not terms of reference that I've seen for OPES before. What are they, how do they relate to the architecture? Why aren't two messages ("menu offer" and "menu selection") sufficient? Many IETF protocols use this method and live happy lives. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 17 17:08:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08001 for ; Thu, 17 Apr 2003 17:08:55 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GfC-0002gb-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 17:11:22 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196GfC-0002gY-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 17:11:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKwBt2061216 for ; Thu, 17 Apr 2003 13:58:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HKwB9r061215 for ietf-openproxy-bks; Thu, 17 Apr 2003 13:58: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.8p1/8.12.8) with ESMTP id h3HKwAt2061209 for ; Thu, 17 Apr 2003 13:58: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 h3HKwCvj041500; Thu, 17 Apr 2003 14:58:12 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HKwCV6041499; Thu, 17 Apr 2003 14:58:12 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 14:58:12 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: SOAP and OCP In-Reply-To: Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> 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: Abbie Barbir argued that OPES processors should support SOAP as a foundation of OCP. Abbie, I think it is time to resume that discussion in the OCP transport light/scope. I have three basic questions: 1. SOAP is not a transport protocol. Would you require a specific transport protocol to be used if OCP is implemented using SOAP? For example, would you require that BEEP/TCP and only BEEP/TCP is used under SOAP? 2. My understanding is that using SOAP pretty much requires XML message format/encoding for OCP messages. How do you suggest we implement OCP data pipeline with SOAP? More specifically, what is the best way to transfer, say, a 900KB "binary" stream from OPES processor to callout server? Single large SOAP message? Multiple small messages? How to encode binary data? 3. Does SOAP allow for SOAP "connections" that are mapped to transport connections of some kind? If we do not have access to transport connections, how do we keep state and avoid constant renegotiations? How do we guarantee that two messages to the same callout server IP address end up at the same server (as opposed to being NATed or load-balanced to different servers)? Do we care about IP not being sufficient to identify a real server? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 17:19:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08299 for ; Thu, 17 Apr 2003 17:19:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Gpl-0002kw-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 17:22:17 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196Gpl-0002kt-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 17:22:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLBTt2062137 for ; Thu, 17 Apr 2003 14:11:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLBTZf062136 for ietf-openproxy-bks; Thu, 17 Apr 2003 14:11:29 -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.8p1/8.12.8) with ESMTP id h3HLBRt2062129 for ; Thu, 17 Apr 2003 14:11: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 h3HLBSvj041842; Thu, 17 Apr 2003 15:11:28 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HLBRdA041841; Thu, 17 Apr 2003 15:11:27 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 15:11:27 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Capability Negotiation for OCP In-Reply-To: <200304172052.h3HKqjK29413@localhost.localdomain> Message-ID: References: <200304172052.h3HKqjK29413@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: On Thu, 17 Apr 2003, The Purple Streak, Hilarie Orman wrote: > Why aren't two messages ("menu offer" and "menu selection") > sufficient? Many IETF protocols use this method and live happy > lives. How do you indicate success/failure with only offer/selection message available? For example, how can an OPES processor tell callout server that server's particular selection (combination of available options) from the offered menu is not acceptable/available? Just because the processor offers paramA: valueA1 or valueA2 paramB: valueB1 or valueB2 does not, in general, imply that any (valueA*, valueB*) combination/pair selected by the server is acceptable to the OPES processor, right? Can you give an example of an offer/selection protocol that negotiates more than one parameter at once but lacks success/failure acknowledgments? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 17:51:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09690 for ; Thu, 17 Apr 2003 17:51:11 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HK7-00032i-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 17:53:39 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196HK6-00032f-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 17:53:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLgxt2063544 for ; Thu, 17 Apr 2003 14:42:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLgxlC063543 for ietf-openproxy-bks; Thu, 17 Apr 2003 14:42:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLgvt2063534 for ; Thu, 17 Apr 2003 14:42:57 -0700 (PDT) (envelope-from rpenno@nortelnetworks.com) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HLgiK26520; Thu, 17 Apr 2003 16:42:45 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2R1BY23L>; Thu, 17 Apr 2003 14:42:45 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18EB2@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'The Purple Streak, Hilarie Orman'" Cc: ietf-openproxy@imc.org, rousskov@measurement-factory.com Subject: RE: Capability Negotiation for OCP Date: Thu, 17 Apr 2003 14:42:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3052A.45CCB5F8" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C3052A.45CCB5F8 Content-Type: text/plain Hilarie That's how SDP's offer/answer work and its one of its disadvantages. The authors themselves indicate that in RFC3264. " Since SDP has no way to indicate that the message is for the purpose of capability indication, this is determined from the context of the higher layer protocol. The ability of baseline SDP to indicate capabilities is very limited. It cannot express allowed parameter ranges or values, and can not be done in parallel with an offer/answer itself. Extensions might address such limitations in the future." That's why I extended a little bit by adapting some ideas from PPP. Regards, Reinaldo > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Thursday, April 17, 2003 4:53 PM > To: Penno, Reinaldo [BL60:0430:EXCH] > Cc: ietf-openproxy@imc.org; rousskov@measurement-factory.com > Subject: Re: Capability Negotiation for OCP > > > "Channel" and "device" are not terms of reference that I've > seen for OPES before. What are they, how do they relate to > the architecture? > > Why aren't two messages ("menu offer" and "menu selection") > sufficient? Many IETF protocols use this method and live happy lives. > > Hilarie > ------_=_NextPart_001_01C3052A.45CCB5F8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Capability Negotiation for OCP

Hilarie

That's how SDP's offer/answer work and its one of its = disadvantages. The authors themselves indicate that in RFC3264.

"
Since SDP has no way to indicate that the message is = for
   the purpose of capability indication, = this is determined from the
   context of the higher layer = protocol.  The ability of baseline SDP to
   indicate capabilities is very = limited.  It cannot express allowed
   parameter ranges or values, and can not = be done in parallel with an
   offer/answer itself.  Extensions = might address such limitations in
   the future."

That's why I extended a little bit by adapting some = ideas from PPP.

Regards,

Reinaldo

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> Sent: Thursday, April 17, 2003 4:53 PM
> To: Penno, Reinaldo [BL60:0430:EXCH]
> Cc: ietf-openproxy@imc.org; = rousskov@measurement-factory.com
> Subject: Re: Capability Negotiation for = OCP
>
>
> "Channel" and "device" are = not terms of reference that I've
> seen for OPES before.  What are they, how = do they relate to
> the architecture?
>
> Why aren't two messages ("menu offer" = and "menu selection")
> sufficient? Many IETF protocols use this method = and live happy lives.
>
> Hilarie
>

------_=_NextPart_001_01C3052A.45CCB5F8-- From owner-ietf-openproxy@mail.imc.org Thu Apr 17 18:01:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10103 for ; Thu, 17 Apr 2003 18:01:59 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HUY-00036q-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 18:04:26 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196HUY-00036n-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 18:04:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLqZt2063967 for ; Thu, 17 Apr 2003 14:52:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLqZaT063965 for ietf-openproxy-bks; Thu, 17 Apr 2003 14:52:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLqYt2063955 for ; Thu, 17 Apr 2003 14:52:34 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3HLqX1w001226; Thu, 17 Apr 2003 14:52:33 -0700 (PDT) Date: Thu, 17 Apr 2003 14:52:33 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport Message-Id: <20030417145233.1357cbb9.mrose@dbc.mtview.ca.us> In-Reply-To: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit > > ok, do you care that they actually got there or not? > > I know they would get there because I use lossless transport (I would > be notified if something goes wrong). I do not care about the timing > though (because it is a pipeline/stream). I am only interested in the > adapted data sent back; that adapted data may come at any time, even > before [some of] my original data reaches the other end(!)... not true. when TCP fails, a really good API will tell you the last octet that got acknowledged. most APIs just tell you the connection was broken. what this means is that the *only* way that an application protocol knows what application data was successfully received is for it to make those determinations based on the application data it receives. for example, that's a reason why an SMTP sender waits to get an acknowledgement to the final "." of a DATA command. > ... What I > would have to do with BEEP is: > > Processor(client): server-can-start(MSG) > Server: processor-can-start(MSG) > Processor(client): start(ANS), data-have(ANS), data-have(ANS)... > Server: start(ANS), data-have(ANS), data-have(ANS)... > > or some variation of the above. why not use beep's segmentation capability? beep's MSG, RPY, ERR, and ANS messages each contain a single MIME entity, e.g., an application/octet-stream or whatever. beep segments a MIME entity into multiple frames. each frame, except the last one, has an indicator saying "more to come". in many cases the entire message fits into one frame, e.g., C: MSG with some data & no more-bit S: RPY with some data & no more-bit if it doesn't fit into one frame,then: in most applications, the server waits until it receives a frame without the more-to-come indicator before processing the data, e.g., timeline 1 ---------- C: MSG with some data & more-bit C: some data & more-bit C: some data & more-bit C: some data & more-bit C: some data & no more-bit S: RPY with some data & more-bit S: some data & no more-bit however, the server can start processing the MSG as soon as it receives the first frame, even if the more-to-come indicator is present: timeline 1 timeline 2 ---------- ---------- C: MSG with some data & more-bit timeline 2 starts S: RPY with some data & more-bit C: some data & more-bit S: some data & more-bit C: some data & more-bit S: some data & more-bit C: some data & more-bit S: some data & more-bit C: some data & no more-bit S: some data & no more-bit the only "tricky" part is that if the server replies with an ERR instead of a RPY, then the client must send a frame without the more-to-come indicator and the sender must start ignoring frames that refer to the errored MSG (cf., section 2.6.3). /mtr From owner-ietf-openproxy@mail.imc.org Thu Apr 17 18:22:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12100 for ; Thu, 17 Apr 2003 18:22:38 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HoY-0003Gg-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 18:25:06 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196HoX-0003Ga-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 18:25:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HME3t2064416 for ; Thu, 17 Apr 2003 15:14:03 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HME3jk064415 for ietf-openproxy-bks; Thu, 17 Apr 2003 15:14:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HME2t2064410 for ; Thu, 17 Apr 2003 15:14:02 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3HMIRKq003282; Thu, 17 Apr 2003 16:18:28 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3HMFFY01277; Thu, 17 Apr 2003 16:15:15 -0600 Date: Thu, 17 Apr 2003 16:15:15 -0600 Message-Id: <200304172215.h3HMFFY01277@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: Capability Negotiation for OCP Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: PPP, IPSec and IKE use "offer, select". The trick is to spell out the complete set of selections at offer time. Don't say (A1 or A2) and (B1 or B2) if (A1 and B2) is not permitted - say instead { A2 and (B1 or B2) } or { A1 and B1} Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 17 18:56:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13372 for ; Thu, 17 Apr 2003 18:56:56 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196ILh-0003U2-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 18:59:21 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196ILh-0003Tx-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 18:59:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HMl8t2064980 for ; Thu, 17 Apr 2003 15:47:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HMl72W064979 for ietf-openproxy-bks; Thu, 17 Apr 2003 15:47:07 -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.8p1/8.12.8) with ESMTP id h3HMl6t2064974 for ; Thu, 17 Apr 2003 15:47:06 -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 h3HMl7vj044068; Thu, 17 Apr 2003 16:47:07 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HMl7WK044067; Thu, 17 Apr 2003 16:47:07 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 16:47:07 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport In-Reply-To: <20030417145233.1357cbb9.mrose@dbc.mtview.ca.us> Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> <20030417145233.1357cbb9.mrose@dbc.mtview.ca.us> 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: On Thu, 17 Apr 2003, Marshall Rose wrote: > > > ok, do you care that they actually got there or not? > > > > I know they would get there because I use lossless transport (I would > > be notified if something goes wrong). I do not care about the timing > > though (because it is a pipeline/stream). I am only interested in the > > adapted data sent back; that adapted data may come at any time, even > > before [some of] my original data reaches the other end(!)... > > not true. when TCP fails, a really good API will tell you the last > octet that got acknowledged. most APIs just tell you the connection > was broken. ... and the latter is all OCP agent needs to know. > what this means is that the *only* way that an application protocol > knows what application data was successfully received is for it to make > those determinations based on the application data it receives. An OPES processor does not care whether the original data was received (in general). It only cares about the adapted data it receives back. Thus, if connection is terminated abnormally, the adapted flow is incomplete and that is all that matters. A callout server cares even less because it cannot influence what OPES processor does with the adapted data. If a connection is terminated prematurely, the callout server simply forgets about corresponding transactions. > for example, that's a reason why an SMTP sender waits to get an > acknowledgement to the final "." of a DATA command. True, but such an acknowledgement is not needed in the OCP data pipeline case, I think. > > What I would have to do with BEEP is: > > > > Processor(client): server-can-start(MSG) > > Server: processor-can-start(MSG) > > Processor(client): start(ANS), data-have(ANS), data-have(ANS)... > > Server: start(ANS), data-have(ANS), data-have(ANS)... > > > > or some variation of the above. > > why not use beep's segmentation capability? > > beep's MSG, RPY, ERR, and ANS messages each contain a single MIME entity, > e.g., an application/octet-stream or whatever. beep segments a MIME > entity into multiple frames. each frame, except the last one, has an > indicator saying "more to come". > ... > the only "tricky" part is that if the server replies with an ERR > instead of a RPY, then the client must send a frame without the > more-to-come indicator and the sender must start ignoring frames > that refer to the errored MSG (cf., section 2.6.3). This would be a very good solution but BEEP core says (emphasis mine): When a message is segmented and sent as several frames, those frames must be sent sequentially, WITHOUT ANY INTERVENING FRAMES FROM OTHER MESSAGES ON THE SAME CHANNEL. However, there are two exceptions: first, no restriction is made with respect to the interleaving of frames for other channels; and, second, in a one-to-many exchange, multiple answers may be simultaneously in progress. This means that OPES agent cannot interleave data-have messages with other messages without incurring the penalty of an extra three BEEP messages. If OPES agent want to send a non-data-have message immediately, on the same channel, in the middle of a data-have stream, it would have to Extra 1. "Close" the current data-have "stream" with "MSG ." 2. send the non-data-have message Extra 3. "Reopen" the data-have "stream" with "MSG *" Extra 4. receive "NUL" response for "Extra 1". The extras can be avoided if non-data-have message is sent on a different channel, but then we have synchronization problems to worry about. Hmm... A combination of the more-bit and other-end-can-send approaches may be an attractive hack though (but still a hack, unfortunately). Once again, we seem to be beaten by a strange asymmetry in BEEP: interleaving ANS "responses" is allowed, but interleaving MSG "requests" is not. Did I miss anything? Thank you for helping with the OCP/BEEP transport mapping. Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 19:05:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13625 for ; Thu, 17 Apr 2003 19:05:22 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196ITr-0003WO-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 19:07:47 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196ITr-0003WL-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 19:07:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HMvAt2065680 for ; Thu, 17 Apr 2003 15:57:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HMvA5M065679 for ietf-openproxy-bks; Thu, 17 Apr 2003 15:57:10 -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.8p1/8.12.8) with ESMTP id h3HMv8t2065674 for ; Thu, 17 Apr 2003 15:57:08 -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 h3HMv9vj044359; Thu, 17 Apr 2003 16:57:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HMv9JP044358; Thu, 17 Apr 2003 16:57:09 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 16:57:09 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: Capability Negotiation for OCP In-Reply-To: <200304172215.h3HMFFY01277@localhost.localdomain> Message-ID: References: <200304172215.h3HMFFY01277@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: On Thu, 17 Apr 2003, The Purple Streak, Hilarie Orman wrote: > PPP, IPSec and IKE use "offer, select". The trick is to spell out > the complete set of selections at offer time. Don't say (A1 or A2) > and (B1 or B2) if (A1 and B2) is not permitted - say instead > > { A2 and (B1 or B2) } or { A1 and B1} I see. The problem is solved by enumerating all possibilities _before_ negotiation begins. Kind of defeats the whole idea behind "negotiation" -- "multiple choice" is not how I would define negotiation. Perhaps that's the best we can do with computers though, not sure. Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 19:58:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14612 for ; Thu, 17 Apr 2003 19:58:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196JJU-0003iJ-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 20:01:08 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196JJT-0003iG-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 20:01:08 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HNnYt2067237 for ; Thu, 17 Apr 2003 16:49:34 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HNnYSR067236 for ietf-openproxy-bks; Thu, 17 Apr 2003 16:49:34 -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.8p1/8.12.8) with ESMTP id h3HNnXt2067231 for ; Thu, 17 Apr 2003 16:49:33 -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 h3HNnYvj045521; Thu, 17 Apr 2003 17:49:34 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3HNnYZ9045520; Thu, 17 Apr 2003 17:49:34 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 17:49:34 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport In-Reply-To: Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> <20030417145233.1357cbb9.mrose@dbc.mtview.ca.us> 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: On Thu, 17 Apr 2003, Alex Rousskov wrote: > A combination of the more-bit and other-end-can-send approaches may > be an attractive hack though Here is how it might look (C == OPES processor, S == callout server) // Processor allows the server to start a BEEP ANS stream C: MSG 1 1 . C: ; perhaps no payload at all C: END // Server allows the processor to start a BEEP ANS stream S: MSG 1 2 . S: ; perhaps no payload at all S: END // normal OCP flow starts for the processor // (when it receives "MSG 1 2 .") and then ends C: ANS 1 3 . C: ... C: END ... // some of the ANSes may use multiple frames C: ANS 1 1234 . C: ... C: END C: NUL // normal OCP flow starts for the server // (when it receives "MSG 1 1 .") and then ends S: ANS 1 4 . S: ... S: END ... // some of the ANSes may use multiple frames S: ANS 1 1235 . S: ... S: END S: NUL The last two group of messages do not depend on each other from BEEP point of view. This is still not perfect because it prevents OCP from using BEEP MSG number/concept for anything useful. However, this allows to package OCP messages inside BEEP ANS messages, with virtually no overhead. This is clearly an abuse of BEEP, to get around its assumptions about message exchange styles. However, this allows (hopefully) to reuse other BEEP mechanisms such as channels, profile negotiation, and session encryption. I would not be surprised if the above can be polished further to allow for more tight OCP:BEEP integration. Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 17 20:30:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15040 for ; Thu, 17 Apr 2003 20:30:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Joh-0003lu-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 20:33:23 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196Joh-0003lq-00 for opes-archive@ietf.org; Thu, 17 Apr 2003 20:33:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I0Mjt2067836 for ; Thu, 17 Apr 2003 17:22:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3I0MjnR067835 for ietf-openproxy-bks; Thu, 17 Apr 2003 17:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I0Mit2067830 for ; Thu, 17 Apr 2003 17:22:44 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3I0Mh1w001449; Thu, 17 Apr 2003 17:22:43 -0700 (PDT) Date: Thu, 17 Apr 2003 17:22:43 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport Message-Id: <20030417172243.33b8198f.mrose@dbc.mtview.ca.us> In-Reply-To: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> <20030417145233.1357cbb9.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit > Did I miss anything? i can't figure out half of what you're saying, because i gave you an example with MSG and RPY, and you replied talking about MSG, ANS, and NUL. so, when i say: timeline 1 timeline 2 ---------- ---------- C: MSG with some data & more-bit timeline 2 starts S: RPY with some data & more-bit C: some data & more-bit S: some data & more-bit C: some data & more-bit S: some data & more-bit C: some data & more-bit S: some data & more-bit C: some data & no more-bit S: some data & no more-bit you seem to be replying that this won't work because you can't have more than one message in flight on a single channel. correct. so if the requirements is: - asynchronous request/response where the response can start coming back before the request is fully sent. use the approach i explained above. if there is an additional requirement that: - more than one simultaneous asynchronous request/response on a single beep session then do each parallel exchange on its own channel. if there are other requirements, or these requirements are wrong, let me know. /mtr From owner-ietf-openproxy@mail.imc.org Fri Apr 18 01:16:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20345 for ; Fri, 18 Apr 2003 01:16:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196OHA-0004p1-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 01:19:04 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196OHA-0004oy-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 01:19:04 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I50rt2073692 for ; Thu, 17 Apr 2003 22:00:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3I50rCb073691 for ietf-openproxy-bks; Thu, 17 Apr 2003 22:00: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.8p1/8.12.8) with ESMTP id h3I50pt2073686 for ; Thu, 17 Apr 2003 22:00: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 h3I50rvj052812; Thu, 17 Apr 2003 23:00:53 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3I50rKs052811; Thu, 17 Apr 2003 23:00:53 -0600 (MDT) (envelope-from rousskov) Date: Thu, 17 Apr 2003 23:00:53 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport In-Reply-To: <20030417172243.33b8198f.mrose@dbc.mtview.ca.us> Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> <20030417145233.1357cbb9.mrose@dbc.mtview.ca.us> <20030417172243.33b8198f.mrose@dbc.mtview.ca.us> 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: On Thu, 17 Apr 2003, Marshall Rose wrote: > so, when i say: > > timeline 1 timeline 2 > ---------- ---------- > C: MSG with some data & more-bit > timeline 2 starts > S: RPY with some data & more-bit > C: some data & more-bit S: some data & more-bit > C: some data & more-bit S: some data & more-bit > C: some data & more-bit S: some data & more-bit > C: some data & no more-bit S: some data & no more-bit > > you seem to be replying that this won't work because you can't have more > than one message in flight on a single channel. yes. > correct. so if the requirements is: > > - asynchronous request/response where the response can start coming > back before the request is fully sent. > > use the approach i explained above. if there is an additional > requirement that: > > - more than one simultaneous asynchronous request/response on a > single beep session > > then do each parallel exchange on its own channel. > > if there are other requirements, or these requirements are wrong, let me > know. Simplified transport requirements of the current OCP core, in each flow direction (processor to server and server to processor), are: - efficiently send possibly large application messages and metadata (blobs), with possibly more than one blob being sent at a time; parts of each blob should be delivered in sent order - send usually small OCP "control" messages related to the dataflow above, at any time; control messages should be delivered in sent order We agree that the first approach (one channel per OCP connection) does not work without hacks because it does not support the "at any time" part. Using multiple channels per OCP connection (one for control and one or more for data/metadata) would work, but, as I said, I am worried about synchronization problems between data and control channels. My understanding is that BEEP does not guarantee that two messages sent on two channels will arrive in the order they were sent. Please correct me if I am wrong. This FTP-like approach adds more state than is strictly necessary for OCP, but I cannot think of any specific OCP task that would _require_ synchronization between data and control channels. So, yes, I think it can work. Moreover, adding extra control channels to support fast aborts is on the todo list and the FTP approach would make that optimization a little easier to describe. I think we are on the same page now. It would be great to hear from others as well. Is anybody able to follow my lame attempts at explaining the problem? Does anybody have horror stories to tell about FTP (other than firewall problems)? Is there a reason we should not use multiple BEEP channels per OCP connection _if_ BEEP is selected as a transport protocol? Marshall, is it correct to say that opening a new BEEP channel can be "cheap", even if we want to use encryption and such? Multi-channel solution appears to be more elegant than my hack, but I am worried about the cost on performance. If an OCP connection (all BEEP channels) needs to be encrypted using, say TLS, does it mean that an OCP agent would have to re-negotiate encryption parameters for every channel it needs to open? This is not a show-stopper (because we could keep channels persistent), but we need to understand the costs. It would be nice if we could say "and for this new channel, use the same parameters we negotiated for that old channel", but we cannot do that in general, can we? Thanks, Alex. P.S. Apologies for skipping a few steps in the previous e-mail. I put too many new details in one example. From owner-ietf-openproxy@mail.imc.org Fri Apr 18 11:19:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16980 for ; Fri, 18 Apr 2003 11:19:29 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196XgZ-0000Av-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 11:21:55 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196XgY-0000As-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 11:21:55 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IF7Rt2026347 for ; Fri, 18 Apr 2003 08:07:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IF7RrC026346 for ietf-openproxy-bks; Fri, 18 Apr 2003 08:07:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IF7Nt2026337 for ; Fri, 18 Apr 2003 08:07:26 -0700 (PDT) (envelope-from rpenno@nortelnetworks.com) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IExdt06592; Fri, 18 Apr 2003 09:59:40 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2R1BZCA8>; Fri, 18 Apr 2003 07:59:40 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18EB4@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'The Purple Streak, Hilarie Orman'" , rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP Date: Fri, 18 Apr 2003 07:59:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C305BB.214B6BC0" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C305BB.214B6BC0 Content-Type: text/plain Hilarie, I do not follow you. PPP has configure-request, configure-response, configure-nak and configure-rej to indicate that some capabilities are not-acceptable and others the peer proposes a differente value. Anyway, I understand your proposal, but is awkard to put every single acceptable value/range/strings for every capability. There might be excessive overhead. On another point, how would you express preference of A1 over A2? I guess ((A1) or A2)? Alex, In order to leverage cached negotiations, we can ask every negotiation to bear a identification number that is unique. Other negotiations can refer to it. Regards, Reinaldo > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Thursday, April 17, 2003 6:15 PM > To: rousskov@measurement-factory.com > Cc: ietf-openproxy@imc.org > Subject: Re: Capability Negotiation for OCP > > > > PPP, IPSec and IKE use "offer, select". The trick is to > spell out the complete set of selections at offer time. > Don't say (A1 or A2) and (B1 or B2) if (A1 and B2) is not > permitted - say instead > > { A2 and (B1 or B2) } or { A1 and B1} > > Hilarie > ------_=_NextPart_001_01C305BB.214B6BC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Capability Negotiation for OCP

Hilarie,

I do not follow you. PPP has configure-request, = configure-response, configure-nak and configure-rej to indicate that = some capabilities are not-acceptable and others the peer proposes a = differente value.

Anyway, I understand your proposal, but is awkard to = put every single acceptable value/range/strings for every capability. = There might be excessive overhead. On another point, how would you = express preference of A1 over A2? I guess ((A1) or A2)?

Alex,

In order to leverage cached negotiations, we can ask = every negotiation to bear a identification number that is unique. Other = negotiations can refer to it.

Regards,

Reinaldo

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> Sent: Thursday, April 17, 2003 6:15 PM
> To: rousskov@measurement-factory.com
> Cc: ietf-openproxy@imc.org
> Subject: Re: Capability Negotiation for = OCP
>
>
>
> PPP, IPSec and IKE use "offer, = select".  The trick is to
> spell out the complete set of selections at = offer time. 
> Don't say (A1 or A2) and (B1 or B2) if (A1 and = B2) is not
> permitted - say instead
>
>       { A2 and (B1 or = B2) } or { A1 and B1}
>
> Hilarie
>

------_=_NextPart_001_01C305BB.214B6BC0-- From owner-ietf-openproxy@mail.imc.org Fri Apr 18 12:54:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19539 for ; Fri, 18 Apr 2003 12:54:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196ZAB-0000Xx-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 12:56:35 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196ZAA-0000Xu-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 12:56:34 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IGkAt2029275 for ; Fri, 18 Apr 2003 09:46:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IGkA1N029274 for ietf-openproxy-bks; Fri, 18 Apr 2003 09:46:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IGk8t2029269 for ; Fri, 18 Apr 2003 09:46:09 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3IGk8dh000553; Fri, 18 Apr 2003 09:46:08 -0700 (PDT) Date: Fri, 18 Apr 2003 09:46:08 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport Message-Id: <20030418094608.0c435714.mrose@dbc.mtview.ca.us> In-Reply-To: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> <20030417145233.1357cbb9.mrose@dbc.mtview.ca.us> <20030417172243.33b8198f.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit thanks for the clarification. > Simplified transport requirements of the current OCP core, in each > flow direction (processor to server and server to processor), are: > > - efficiently send possibly large application messages and > metadata (blobs), with possibly more than one blob being > sent at a time; parts of each blob should be > delivered in sent order > > - send usually small OCP "control" messages related > to the dataflow above, at any time; control messages should > be delivered in sent order > > We agree that the first approach (one channel per OCP connection) does > not work without hacks because it does not support the "at any time" > part. > > Using multiple channels per OCP connection (one for control and one or > more for data/metadata) would work, but, as I said, I am worried about > synchronization problems between data and control channels. My > understanding is that BEEP does not guarantee that two messages sent > on two channels will arrive in the order they were sent. Please > correct me if I am wrong. that is correct, channels on the same session, are effectively parallel. if you need to synchronize them, you can, you have to define messages to do so for your protocol. > I think we are on the same page now. It would be great to hear from > others as well. Is anybody able to follow my lame attempts at > explaining the problem? Does anybody have horror stories to tell about > FTP (other than firewall problems)? Is there a reason we should not > use multiple BEEP channels per OCP connection _if_ BEEP is selected as > a transport protocol? if the answer is "FTP", then the wrong question has been asked. > Marshall, is it correct to say that opening a new BEEP channel can be > "cheap", even if we want to use encryption and such? Multi-channel > solution appears to be more elegant than my hack, but I am worried > about the cost on performance. If an OCP connection (all BEEP > channels) needs to be encrypted using, say TLS, does it mean that an > OCP agent would have to re-negotiate encryption parameters for every > channel it needs to open? This is not a show-stopper (because we could > keep channels persistent), but we need to understand the costs. It > would be nice if we could say "and for this new channel, use the same > parameters we negotiated for that old channel", but we cannot do that > in general, can we? each beep session has a single encryption/authentication context. you negotiate it at the start of the session, and it applies to every channel thereafter, e.g., beep channels beep frames tls packets tcp segments all traffic on all channels goes over the same tls session. /mtr From owner-ietf-openproxy@mail.imc.org Fri Apr 18 12:57:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19590 for ; Fri, 18 Apr 2003 12:57:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196ZDP-0000Y8-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 12:59:55 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196ZDO-0000Y5-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 12:59:54 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IGiht2029250 for ; Fri, 18 Apr 2003 09:44:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IGihYK029249 for ietf-openproxy-bks; Fri, 18 Apr 2003 09:44:43 -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.8p1/8.12.8) with ESMTP id h3IGift2029242 for ; Fri, 18 Apr 2003 09:44:42 -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 h3IGihvj069066; Fri, 18 Apr 2003 10:44:43 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3IGihoK069065; Fri, 18 Apr 2003 10:44:43 -0600 (MDT) (envelope-from rousskov) Date: Fri, 18 Apr 2003 10:44:43 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18EB4@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18EB4@zsc3c026.us.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: On Fri, 18 Apr 2003, Reinaldo Penno wrote: > In order to leverage cached negotiations, we can ask every > negotiation to bear a identification number that is unique. Other > negotiations can refer to it. Yes, of course, but I am worried about potential security-related attacks on such cached IDs as well as stale information. For example, "Yeah, I am the same guy who just talked to you and gave you negotiation ID 12313". I would like, ideally, to reuse an existing scheme that allows that sort of optimization rather than invent our own negotiation caching scheme. Are there other protocols that are concerned with the cost of renegotiation across independent transport connections? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Apr 18 14:24:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21570 for ; Fri, 18 Apr 2003 14:24:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196aZm-0000q5-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 14:27:06 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196aZm-0000q2-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 14:27:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIIXt2033800 for ; Fri, 18 Apr 2003 11:18:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIIXCQ033799 for ietf-openproxy-bks; Fri, 18 Apr 2003 11:18:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIIWt2033793 for ; Fri, 18 Apr 2003 11:18:32 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3IINCKq005794; Fri, 18 Apr 2003 12:23:12 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3IIHli03361; Fri, 18 Apr 2003 12:17:47 -0600 Date: Fri, 18 Apr 2003 12:17:47 -0600 Message-Id: <200304181817.h3IIHli03361@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rpenno@nortelnetworks.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <0A11633F61BD9F40B43ABCC694004F93F18EB4@zsc3c026.us.nortel.com> Subject: RE: Capability Negotiation for OCP Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the PPP authors told me several years ago that PPP only used two messages; perhaps it has changed. IKE does use just the two messages. Preference of A1 over A2 is expressed as (A1 or A2); preference of A2 over A1 is expressed as (A2 or A1), just like compilers do it. OPES will have a rule compiler, it can certainly have a preference compiler. Hilarie > I do not follow you. PPP has configure-request, configure-response, > configure-nak and configure-rej to indicate that some capabilities are > not-acceptable and others the peer proposes a differente value. > Anyway, I understand your proposal, but is awkard to put every single > acceptable value/range/strings for every capability. There might be > excessive overhead. On another point, how would you express preference of A1 > over A2? I guess ((A1) or A2)? > Alex, > In order to leverage cached negotiations, we can ask every negotiation to > bear a identification number that is unique. Other negotiations can refer to > it. > Regards, > Reinaldo > > -----Original Message----- > > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > > Sent: Thursday, April 17, 2003 6:15 PM > > To: rousskov@measurement-factory.com > > Cc: ietf-openproxy@imc.org > > Subject: Re: Capability Negotiation for OCP > > > > > > > > PPP, IPSec and IKE use "offer, select". The trick is to > > spell out the complete set of selections at offer time. > > Don't say (A1 or A2) and (B1 or B2) if (A1 and B2) is not > > permitted - say instead > > > > { A2 and (B1 or B2) } or { A1 and B1} > > > > Hilarie > > From owner-ietf-openproxy@mail.imc.org Fri Apr 18 14:27:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21648 for ; Fri, 18 Apr 2003 14:27:19 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196acK-0000qz-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 14:29:44 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196acK-0000qw-00 for opes-archive@ietf.org; Fri, 18 Apr 2003 14:29:44 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IICit2033091 for ; Fri, 18 Apr 2003 11:12:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IICiuI033090 for ietf-openproxy-bks; Fri, 18 Apr 2003 11:12: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.8p1/8.12.8) with ESMTP id h3IICgt2033085 for ; Fri, 18 Apr 2003 11:12:42 -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 h3IICgvj072126; Fri, 18 Apr 2003 12:12:42 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3IICfKb072125; Fri, 18 Apr 2003 12:12:42 -0600 (MDT) (envelope-from rousskov) Date: Fri, 18 Apr 2003 12:12:41 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport In-Reply-To: <20030418094608.0c435714.mrose@dbc.mtview.ca.us> Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@mail.utel.net> <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> <20030417115230.69375b3c.mrose@dbc.mtview.ca.us> <20030417145233.1357cbb9.mrose@dbc.mtview.ca.us> <20030417172243.33b8198f.mrose@dbc.mtview.ca.us> <20030418094608.0c435714.mrose@dbc.mtview.ca.us> 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: On Fri, 18 Apr 2003, Marshall Rose wrote: > > I think we are on the same page now. It would be great to hear from > > others as well. Is anybody able to follow my lame attempts at > > explaining the problem? Does anybody have horror stories to tell about > > FTP (other than firewall problems)? Is there a reason we should not > > use multiple BEEP channels per OCP connection _if_ BEEP is selected as > > a transport protocol? > > if the answer is "FTP", then the wrong question has been asked. Shoot. I deleted a sentence explaining that the multi-channel approach is probably similar to what FTP uses (data channel + control channel). I did not mean to suggest that we use FTP for anything; that would not even be funny. Still, some FTP lessons might be useful. > each beep session has a single encryption/authentication context. > you negotiate it at the start of the session, and it applies to > every channel thereafter, e.g., > > beep channels > beep frames > tls packets > tcp segments > > all traffic on all channels goes over the same tls session. Great, that helps to keep per-channel overheads low. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Sat Apr 19 16:04:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02071 for ; Sat, 19 Apr 2003 16:04:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196ycA-0005YX-00 for opes-archive@ietf.org; Sat, 19 Apr 2003 16:07:10 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 196ycA-0005YT-00 for opes-archive@ietf.org; Sat, 19 Apr 2003 16:07:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JJpSt2020337 for ; Sat, 19 Apr 2003 12:51:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JJpSjb020336 for ietf-openproxy-bks; Sat, 19 Apr 2003 12:51:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JJpQt2020331 for ; Sat, 19 Apr 2003 12:51:26 -0700 (PDT) (envelope-from rpenno@nortelnetworks.com) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3JJp8515890; Sat, 19 Apr 2003 14:51:08 -0500 (CDT) Received: from zsc3c026.us.nortel.com ([47.81.138.26]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2R1B5JK1; Sat, 19 Apr 2003 12:51:08 -0700 Received: from private2xsth6c (artpt5qr.us.nortel.com [47.140.52.142]) by zsc3c026.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2GHBLAPX; Sat, 19 Apr 2003 12:51:08 -0700 Message-ID: <000701c306ad$0b6652f0$8e348c2f@private2xsth6c> X-Sybari-Space: 00000000 00000000 00000000 From: "Reinaldo Penno" To: "The Purple Streak, Hilarie Orman" , "Reinaldo Penno" Cc: References: <200304181817.h3IIHli03361@localhost.localdomain> Subject: Re: Capability Negotiation for OCP Date: Sat, 19 Apr 2003 15:51:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I do not like the fact that suddenly the order of the elements in the OR statement is important. Yes, compilers can optimize based onjthe order, but the final result is indepdendent of the ordering. We need to think about something different. We still need a way for the peer to say that it does not understand a capability and/or does not agree with any value proposed (and actually conveys which value it would have agreed). It can be on the naswr message, but we need a special notation for that. regards, Reinaldo ----- Original Message ----- From: "The Purple Streak, Hilarie Orman" To: "Penno, Reinaldo [BL60:0430:EXCH]" Cc: Sent: Friday, April 18, 2003 2:17 PM Subject: RE: Capability Negotiation for OCP > One of the PPP authors told me several years ago that PPP only used two > messages; perhaps it has changed. IKE does use just the two messages. > > Preference of A1 over A2 is expressed as (A1 or A2); preference of A2 > over > A1 is expressed as (A2 or A1), just like compilers do it. > > OPES will have a rule compiler, it can certainly have a preference > compiler. > > Hilarie > > > I do not follow you. PPP has configure-request, configure-response, > > configure-nak and configure-rej to indicate that some capabilities > are > > not-acceptable and others the peer proposes a differente value. > > > Anyway, I understand your proposal, but is awkard to put every single > > acceptable value/range/strings for every capability. There might be > > excessive overhead. On another point, how would you express > preference of A1 > > over A2? I guess ((A1) or A2)? > > > Alex, > > > In order to leverage cached negotiations, we can ask every > negotiation to > > bear a identification number that is unique. Other negotiations can > refer to > > it. > > > Regards, > > > Reinaldo > > > > -----Original Message----- > > > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > > > Sent: Thursday, April 17, 2003 6:15 PM > > > To: rousskov@measurement-factory.com > > > Cc: ietf-openproxy@imc.org > > > Subject: Re: Capability Negotiation for OCP > > > > > > > > > > > > PPP, IPSec and IKE use "offer, select". The trick is to > > > spell out the complete set of selections at offer time. > > > Don't say (A1 or A2) and (B1 or B2) if (A1 and B2) is not > > > permitted - say instead > > > > > > { A2 and (B1 or B2) } or { A1 and B1} > > > > > > Hilarie > > > > From owner-ietf-openproxy@mail.imc.org Mon Apr 21 09:06:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14216 for ; Mon, 21 Apr 2003 09:06:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197b28-0000CM-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:08:32 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197b27-0000CI-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:08:31 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LCs8t2041704 for ; Mon, 21 Apr 2003 05:54:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LCs8KR041703 for ietf-openproxy-bks; Mon, 21 Apr 2003 05:54:08 -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.8p1/8.12.8) with ESMTP id h3LCs7t2041696 for ; Mon, 21 Apr 2003 05:54:07 -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 h3LCrm408104; Mon, 21 Apr 2003 08:53:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Apr 2003 08:53:48 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754057C7FF9@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "The Purple Streak, Hilarie Orman" , info@utel.net Cc: ietf-openproxy@imc.org Subject: RE: OPES definition/scope Date: Mon, 21 Apr 2003 08:53:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30805.09D80D9E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30805.09D80D9E Content-Type: text/plain Hilaries, I second your opinion. Abbie > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Wednesday, April 16, 2003 5:06 PM > To: info@utel.net > Cc: ietf-openproxy@imc.org > Subject: Re: OPES definition/scope > > > > OPES is not going to do protocol conversion. An OPES-like > architecture could, at some point, define the processing > points and control messages for this kind of functionality, > and I hope that someday we'll get there, but I doubt that it > will be in a WG called OPES. > > You make a good point in observing that if OPES did protocol > conversion, then the notion that the callout protocol is the > encoded in the proxied protocol becomes confused - callout > transactions would logically use protocol X in one direction > and protocol Y in the other. And further, we'd have to think > through several issues about matching names, authentication > methods, connection initiation to endpoints, etc. that just > didn't come up when we did the architecture. > > Of course, someone might be able to do some protocol > conversions using OPES and a single protocol encoding for the > callout protocol. That's fine and good, I'm sure the > framework we are developing will support more uses than we > directly address. > > Hilarie > > On Wed, 16 Apr 2003 at 19:27:23 +0200 jfcm stated: > > I just think in simple ways: > > - Yes/No. > > - layers by layer implications > > - logical models > > - what has not been approved by consensus is not accepted > > > *At 17:51 16/04/03, Alex Rousskov wrote: > > >-- was "Subject: OCP questions" > > >jfc, > > > You keep mixing OCP and OPES which makes it very > awkward (for > > >me) to respond. The "OCP questions" thread you responded to was > > about >OCP. OCP Core is application-agnostic and, hence > does not care > > much >about proxied protocols, their conversions, etc. > > > The thread I followed was questions on that. > > > > I took the liberty of renaming your Subject > line. If you want > > >to polish or completely change OPES definition, PLEASE > stay on this > > >new thread and make specific suggestions here. If you want > to discuss > > >OCP Core draft instead, please use existing OPES > architecture and the > > >old thread (or start a new one). I understand that OCP depends on > > OPES >architecture, but OCP thread is not about OPES in > general, it > > is about >OCP. This new thread can be about what OPES is or should > > be. > > > The OPES is NOT defined enough for the OPC Core not to be > affected. > > At this stage I saw no concensus call on anything yet. Or > did I miss > > something? > > > > Specific OPES-related comments are inlined. > > > > > >On Wed, 16 Apr 2003, jfcm wrote: > > > > > > > At 15:22 16/04/03, Alex Rousskov wrote: > > > > >On Wed, 16 Apr 2003, jfcm wrote: > > > > > > Most of the points risen here would get a clear > response with > > a > > > > simple diagrams such as : > > > > > > > > > > http | data input | dispatcher | call-out > protocol | server | call-out > > > > > > protocol | data-output | http > > > > > > <------ OPES ? possiblity 1 > > > > > > <------ OPES ? possiblity 2 > > > > > <--- OPES ? possibility 3 > > > > > > > > >We already have/had such diagrams. Obviously, they > did not provide > > > > >enough "clear responses". > > > > > > > > hmmm... This is your opinion which translates into > some's difficulty > > > > to understand where we are. > > > > > >What I said is not an opinion. It is a fact. We had very similar > > >diagrams in OCP Core (e.g., see section 2.1 "2.1 OCP > environment" in > > >version head_sid3 of the OCP Core draft [1]) and, since > people keep > > >asking questions, they did not get us "clear responses" > you promise. > > > > > >[1] > > > >http://www.measurement-factory.com/tmp/opes/snapshots/head_si > d3/ocp-spec.html#section_ops-environment > > > Since people still keep asking questions I suggest that > you keep both > > the > > diagram and the explaination. This may help to understand. > So we may also > > see if the diagrams are good enough and if the > explanations match the > > diagram. Modelization is the first step, but it is also an > iterative process. > > > > > If OPES is defined as the first possbility, http is part of it > > and > > call-out may take it into account. If it is defined the > > second way, > > external protocols are no part of OPES but OCP can > > consider knowing > > it. If it is the third definition (that I > > thought you would add by > > yourself in your response to > illustrate > > the difficulty), then the > > call-out protocol has NO > relation with > > the entry protocol. > >I do not know what "possibilities" you are > > talking about. Are they >related to the arrows on your > diagram? Care > > to define them explicitly? > > > I am discussing a diagram where three possibitilities are > shown with > > a question mark. For your convenience I added the wording > "possiblity > > #". > > > > > >Note that OCP has nothing to do with "http | > > > > >data input |" and "data-output | http" parts. OCP Core has > > specific > > >wording about that. That wording replaced > some of the > > figures that had > > >those parts in earlier OCP Core > versions. > > > > > > Seems that this wording does not prevent questions. May be both > > > > could be kept? We could check they fit the different > understandings. > > > > > >By "both", do you mean the old figure and the new wording? > > > Yes. As discussed above. Even is things are the same in your mind, > > either > > they will present the same thing and they will help > understanding, or they > > may present different things and will help indifying > misunderstandings. > > > > > > > PS. What about protocol conversion, is that OPES? > > > > > > > > > >It can be. An application proxy that does protocol conversion > > may > > >support OPES mechanisms and may be > OPES-compliant. A decent > > HTTP proxy > > >today has to convert between HTTP and FTP (or even > > Gopher, WAIS, > > >etc.). I do not see why OPES proxies should be > > more limited than > > >existing HTTP proxies. If OCP is > involved in > > protocol conversion, OCP > > >agents would have to > negotiate/agree on > > how to specify > > >original/adapted protocols via application > > message metadata. > > > > At a given stage one must start saying > > what an OPES is and is not. > > > >OPES is about many specific things. If you keep asking specific > > >questions ("Is OPES about Foo"), you will keep getting specific > > >answers ("OPES can be about Foo", but it can also be about "Bar"). > > > This should not be the case. If you work out a, OPES diagram; you > > will have I/Os and you will phrase OPES in a mathematical way as a > > function (or group of functions). That function(s) will be clearly > > understood if it is clearly and afirmatively described in a generic > > way. > > > If the I/O of the OPES black-box are data flows under > protocols, then > > OPES may relate to protocols, if not they will not. This is what a > > diagram will permit/help you to see easily. > > > > > And stop saying "it can be". > > > > > >I was just answering your question! OPES, regardless of the > > >definition, can be many things. It is OK to say "OPES is about > > >protocol conversion", but since OPES is also about other > things, it > > is >more accurate to say (IMO) that "OPES can be about protocol > > >conversion". That is, "protocol conversion" is within OPES scope. > > >The latter is the best wording, I guess. > > > No. As everything generic OPES can only carry what they > have beend > > defined to carry. Some implementations could do more, they > could also > > participate into some other process. But generic OPES will do all > > what they are expected to do if they are well designed, > and no more > > (otherwise they would have been ill defined or would cost > too much to > > develop for the expected return). > > > > > IMHO it CANNOT be a protocol converter if it is not related to > > the > > entry protocol > > > >OPES _is_ related to the input/entry protocol. We even plan > > >input/output protocol-specific drafts, possibly one per proxied > > >protocol! > > > You "plan". This is "possibly". IAB said it is related to > http. To > > be realted to more you have two options: > > > - to draft as many OPES systems with impact on OPC > > - to make them independent from the I/O protocol (possiblity > > 2 or better 3 aboe), leaving that aspect to a protocol interface > > able to relate with such OPES systems. > > > I do prefer that last approach in one architecture (dispatcher > > centric). I do not in the other architecture (daisy > chaining). When > > you say that OPES "can be both" you do not help me deciding. > > > We are here talking specifcally of the OPC Core. And in a > dispatcher > > centric architecture I think the callout protocol is the center of > > the whole OPES system; while in the daisy chain > architecture If feel > > it is quite of no interest. > > > > > (but the use of different I/O protocol will > > > > [affirmative mode] make it a part of a protocol conversion > > system). > >Do not know what you mean by "I/O protocol". > > > Protocol used to input or output the data. The same > > wording as you, just above. > > > > > This will have an impact on OCP. The protocol sequence > is then: > > > > http > call-out > smtp. > > > >The above is not how callout protocol is now defined. Callout is > > >something that comes back: > > > > > > (http) <--> OPES processor <--> (ftp) > > > ^ > > > | > > > V > > > (callout) > > > Thnak you for the draft/ So you can see that that the sequence of > > the data path is http > (dispatcher) call-out (server) call-out > > > (dispatcher) > ftp. > > > So if you only keep protocol, the protocol sequence is what I > > indicated. It permits to see that - unless protocols conversion or > > continuity relies on stored information every meta info in > the input > > protcol must be transported in the call-out protcol. So the OPC is > > I/O protocol dependent and new versions can be specified on I/O > > protocols basis. > > > Or OCP supports enough information to be mapped into many > protocols. > > Then all the protocols one can interface are OPES acceptable. > > > This makes two totally different architectures and ways to > consider > > OPES. jfc > ------_=_NextPart_001_01C30805.09D80D9E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: OPES definition/scope

Hilaries,

I second your opinion.

Abbie


> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> Sent: Wednesday, April 16, 2003 5:06 PM
> To: info@utel.net
> Cc: ietf-openproxy@imc.org
> Subject: Re: OPES definition/scope
>
>
>
> OPES is not going to do protocol = conversion.  An OPES-like
> architecture could, at some point, define the = processing
> points and control messages for this kind of = functionality,
> and I hope that someday we'll get there, but I = doubt that it
> will be in a WG called OPES.
>
> You make a good point in observing that if OPES = did protocol
> conversion, then the notion that the callout = protocol is the
> encoded in the proxied protocol becomes = confused - callout
> transactions would logically use protocol X in = one direction
> and protocol Y in the other. And further, we'd = have to think
> through several issues about matching names, = authentication
> methods, connection initiation to endpoints, = etc. that just
> didn't come up when we did the = architecture.
>
> Of course, someone might be able to do some = protocol
> conversions using OPES and a single protocol = encoding for the
> callout protocol.  That's fine and good, = I'm sure the
> framework we are developing will support more = uses than we
> directly address.
>
> Hilarie
>
> On Wed, 16 Apr 2003 at 19:27:23 +0200 jfcm = stated:
> >  I just think in simple ways:
> >  - Yes/No.
> >  - layers by layer = implications
> >  - logical models
> >  - what has not been approved by = consensus is not accepted
>
> >  *At 17:51 16/04/03, Alex Rousskov = wrote:
> >  >-- was "Subject: OCP = questions"
> >  >jfc,
> >  = >         You keep mixing = OCP and OPES which makes it very
> awkward (for
> >  >me) to respond. The "OCP = questions" thread you responded to was
> > about  >OCP. OCP Core is = application-agnostic and, hence
> does not care
> > much  >about proxied protocols, = their conversions, etc.
>
> >  The thread I followed was questions = on that.
>
> >  = >         I took the liberty = of renaming your Subject
> line. If you want
> >  >to polish or completely change = OPES definition, PLEASE
> stay on this 
> > >new thread and make specific = suggestions here. If you want
> to discuss 
> > >OCP Core draft instead, please use = existing OPES
> architecture and the 
> > >old thread (or start a new one). I = understand that OCP depends on
> > OPES  >architecture, but OCP = thread is not about OPES in
> general, it
> > is about  >OCP. This new thread = can be about what OPES is or should
> > be.
>
> >  The OPES is NOT defined enough for = the OPC Core not to be
> affected. 
> > At this stage I saw no concensus call on = anything yet. Or
> did I  miss
> > something?
>
> >  = >         Specific = OPES-related comments are inlined.
> >  >
> >  >On Wed, 16 Apr 2003, jfcm = wrote:
> >  >
> >  > > At 15:22 16/04/03, Alex = Rousskov wrote:
> >  > > >On Wed, 16 Apr 2003, = jfcm wrote:
> >  > > > > Most of the = points risen here would get a clear
> response with
> > a  > > > > simple = diagrams such as :  > > > >
> >  > > > > http  | = data input | dispatcher | call-out
> protocol | server | call-out
> >  > > > > protocol | = data-output | http
> >  > > > > <------ OPES = ? possiblity 1
> >  > > > = >          <------ = OPES ? possiblity 2
> >  > >  = >           &n= bsp;           &n= bsp;    <--- OPES ? possibility 3
> >  > >
> >  > > >We already have/had = such diagrams. Obviously, they
> did not provide
> >  > > >enough "clear = responses".
> >  > >
> >  > > hmmm... This is your = opinion which translates into
> some's difficulty
> >  > > to understand where we = are.
> >  >
> >  >What I said is not an opinion. = It is a fact. We had very similar
> >  >diagrams in OCP Core (e.g., see = section 2.1 "2.1 OCP
> environment" in
> >  >version head_sid3 of the OCP Core= draft [1]) and, since
> people keep
> >  >asking questions, they did not = get us "clear responses"
> you promise.
> >  >
> >  >[1]
> > 
> >http://www.measurement-factory.com/tmp/opes/snapshots/= head_si
> d3/ocp-spec.html#section_ops-environment
>
> >  Since people still keep asking = questions I suggest that
> you keep both
> > the
> >  diagram and the explaination. This = may help to understand.
> So we may also
> >  see if the diagrams are good enough = and if the
> explanations match the
> >  diagram. Modelization is the first = step, but it is also an
> iterative process.
>
> >  > > If OPES is defined as the = first possbility, http is part of it
> > and  > > call-out may take it = into account. If it is defined the
> > second way,  > > external = protocols are no part of OPES but OCP can
> > consider knowing  > > it. If it = is the third definition (that I
> > thought you would add by  > > = yourself in your response to
> illustrate
> > the difficulty), then the  > > = call-out protocol has NO
> relation with
> > the entry protocol.  >  >I = do not know what "possibilities" you are
> > talking about. Are they  >related = to the arrows on your
> diagram? Care
> > to define them explicitly?
>
> >  I am discussing a diagram where = three possibitilities are
> shown  with
> > a question mark. For your convenience I = added the wording 
> "possiblity
> > #".
>
> >  > > >Note that OCP has = nothing to do with "http |
> >  > > >data input |" and = "data-output | http" parts. OCP Core has
> > specific  > > >wording about = that. That wording replaced
> some of the
> > figures that had  > > >those = parts in earlier OCP Core
> versions.  > >
> >  > > Seems that this wording = does not prevent questions. May be both
> >  > > could be kept? We could = check they fit the different
> understandings.
> >  >
> >  >By "both", do you mean = the old figure and the new wording?
>
> >  Yes. As discussed above. Even is = things are the same in your mind,
> > either
> >  they will present the same thing and = they will help
> understanding, or they
> >  may present different things and = will help indifying
> misunderstandings.
>
> >  > > > > PS. What about = protocol conversion, is that OPES?
> >  > > >
> >  > > >It can be. An = application proxy that does protocol conversion
> > may  > > >support OPES = mechanisms and may be
> OPES-compliant. A decent
> > HTTP proxy  > > >today has = to convert between HTTP and FTP (or even
> > Gopher, WAIS,  > > >etc.). I = do not see why OPES proxies should be
> > more limited than  > > = >existing HTTP proxies. If OCP is
> involved in
> > protocol conversion, OCP  > > = >agents would have to
> negotiate/agree on
> > how to specify  > > = >original/adapted protocols via application
> > message metadata.  > >  = > > At a given stage one must start saying
> > what an OPES is and is not.  = >
> >  >OPES is about many specific = things. If you keep asking specific
> >  >questions ("Is OPES about = Foo"), you will keep getting specific
> >  >answers ("OPES can be about = Foo", but it can also be about "Bar").
>
> >  This should not be the case. If you = work out a, OPES diagram; you 
> > will have I/Os and you will phrase OPES in = a mathematical way as  a
> > function (or group of functions). That = function(s) will be clearly 
> > understood if it is clearly and = afirmatively described in a generic
> > way.
>
> >  If the I/O of the OPES black-box are = data flows under
> protocols, then 
> > OPES may relate to protocols, if not they = will not. This is what a 
> > diagram will permit/help you to see = easily.
>
> >  > > And stop saying "it = can be".
> >  >
> >  >I was just answering your = question! OPES, regardless of the 
> > >definition, can be many things. It is = OK to say "OPES is about 
> > >protocol conversion", but since = OPES is also about other
> things, it
> > is  >more accurate to say (IMO) = that "OPES can be about protocol 
> > >conversion". That is, = "protocol conversion" is within OPES scope. 
> > >The latter is the best wording, I = guess.
>
> >  No. As everything generic OPES can = only carry what they
> have  beend
> > defined to carry. Some implementations = could do more,  they
> could also
> > participate into some other process. But = generic  OPES will do all
> > what they are expected to do if they are = well  designed,
> and no more
> > (otherwise they would have been ill = defined  or would cost
> too much to
> > develop for the expected return).
>
> >  > > IMHO it CANNOT be a = protocol converter if it is not related to
> > the  > > entry protocol  = >
> >  >OPES _is_ related to the = input/entry protocol. We even plan
> >  >input/output protocol-specific = drafts, possibly one per proxied
> >  >protocol!
>
> >  You "plan". This is = "possibly". IAB said it is related to
> http.  To
> > be realted to more you have two = options:
>
> >  - to draft as many OPES systems with = impact on OPC
> >  - to make them independent from the = I/O protocol (possiblity
> >     2 or better 3 = aboe), leaving that aspect to a protocol interface
> >     able to relate = with such OPES systems.
>
> >  I do prefer that last approach in = one architecture (dispatcher
> > centric).  I do not in the other = architecture (daisy
> chaining). When
> > you say  that OPES "can be = both" you do not help me deciding.
>
> >  We are here talking specifcally of = the OPC Core. And in a 
> dispatcher
> > centric architecture I think the callout = protocol is the  center of
> > the whole OPES system; while in the daisy = chain 
> architecture If feel
> > it is quite of no interest.
>
> >  > > (but the use of different = I/O protocol will
> >  > > [affirmative mode] make it = a part of a protocol conversion
> > system).  >  >Do not know = what you mean by "I/O protocol".
>
> >  Protocol used to input or output the = data. The same
> >  wording as you, just above.
>
> >  > > This will have an impact = on OCP. The protocol sequence
> is then: 
> > > > http > call-out > = smtp.  >
> >  >The above is not how callout = protocol is now defined. Callout is
> >  >something that comes = back:
> >  >
> >  = >         (http) <--> = OPES processor <--> (ftp)
> >  = >           &n= bsp;          ^
> >  = >           &n= bsp;          |
> >  >     &nb= sp;           &nb= sp;    V
> >  = >           &n= bsp;       (callout)
>
> >  Thnak you for the draft/ So you can = see that that the sequence  of
> > the data path is http > (dispatcher) = call-out (server) call-out >
> >  (dispatcher) > ftp.
>
> >  So if you only keep protocol, the = protocol sequence is what  I
> > indicated. It permits to see that - unless = protocols conversion  or
> > continuity relies on stored information = every meta info in 
> the input
> > protcol must be transported in the = call-out protcol.  So the OPC is
> > I/O protocol dependent and new versions = can  be specified on I/O
> > protocols basis.
>
> >  Or OCP supports enough information = to be mapped into many 
> protocols.
> > Then all the protocols one can interface = are OPES  acceptable.
>
> >  This makes two totally different = architectures and ways to
>  consider
> > OPES.  jfc
>

------_=_NextPart_001_01C30805.09D80D9E-- From owner-ietf-openproxy@mail.imc.org Mon Apr 21 09:16:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14426 for ; Mon, 21 Apr 2003 09:16:47 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197bCQ-0000F4-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:19:10 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197bCQ-0000F1-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:19:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LD6dt2041974 for ; Mon, 21 Apr 2003 06:06:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LD6d5D041973 for ietf-openproxy-bks; Mon, 21 Apr 2003 06:06:39 -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.8p1/8.12.8) with ESMTP id h3LD6ct2041968 for ; Mon, 21 Apr 2003 06:06:38 -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 h3LD6Lk23376; Mon, 21 Apr 2003 09:06:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Apr 2003 09:06:21 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754057C803E@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP Date: Mon, 21 Apr 2003 09:06:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30806.CCAB55B4" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30806.CCAB55B4 Content-Type: text/plain hi, how about Authentication/Authorization/encrytption. how/when these will be negotiated/supported etc. Are we talking about another encapsulation (like HTTPS or SASL) here or what? Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, April 17, 2003 2:58 PM > To: ietf-openproxy@imc.org > Subject: Re: Capability Negotiation for OCP > > > > > On Thu, 17 Apr 2003, Reinaldo Penno wrote: > > > These are my ideas on capability negotiation. They are a > mix of SDP's > > offer/answer, BGP and PPP. > > Sounds like a great start to me. I am sure we will run into > arguments once the wording becomes more specific. > > One high-level thing to consider now is scope (level) > definition: Do we want to have a fixed number of levels > associated with OCP entities like connection and transaction? > Or do we want to allow unlimited nesting? For example, is it > possible that something needs to be re-negotiated in the > middle of a transaction? > > Another issue: are negotiations always limited in scope to a > single transport connection? Are we worried that two > connections to the same IP may not end up at the same callout > server? In other words, if an OPES processor wants to open 10 > connections to a callout server, does it need to negotiate > each from scratch OR can it refer to earlier > ("cached") negotiations? > > Semantically, does describe sender characteristics "I > can use Foo" or can it describe sender desires (recipient > characteristics) "Please use Foo" as well? For example, how > can a callout server change OPES processor copying state from > "yes" to "no" in the middle of an OCP connection? Using > "Processor-uses-copying" property? > > How is the order of negotiations determined -- what if both > OPES processor and callout server send messages "at once"? > > Finally, can we define a complete set of parameters that MUST > be negotiated for OCP Core? > > Let's not spent too much effort on what you call "packet > format" now. The choice of transport protocol and encoding > will have a major impact on that, I think. > > Thank you, > > Alex. > ------_=_NextPart_001_01C30806.CCAB55B4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Capability Negotiation for OCP

hi,
how about = Authentication/Authorization/encrytption.

how/when these will be negotiated/supported = etc.
Are we talking about another encapsulation (like = HTTPS or SASL) here or what?


Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Thursday, April 17, 2003 2:58 PM
> To: ietf-openproxy@imc.org
> Subject: Re: Capability Negotiation for = OCP
>
>
>
>
> On Thu, 17 Apr 2003, Reinaldo Penno = wrote:
>
> > These are my ideas on capability = negotiation. They are a
> mix of SDP's
> > offer/answer, BGP and PPP.
>
> Sounds like a great start to me. I am sure we = will run into
> arguments once the wording becomes more = specific.
>
> One high-level thing to consider now is scope = (level)
> definition: Do we want to have a fixed number = of levels
> associated with OCP entities like connection = and transaction?
> Or do we want to allow unlimited nesting? For = example, is it
> possible that something needs to be = re-negotiated in the
> middle of a transaction?
>
> Another issue: are negotiations always limited = in scope to a
> single transport connection? Are we worried = that two
> connections to the same IP may not end up at = the same callout
> server? In other words, if an OPES processor = wants to open 10
> connections to a callout server, does it need = to negotiate
> each from scratch OR can it refer to = earlier
> ("cached") negotiations?
>
> Semantically, does <offer> describe = sender characteristics "I
> can use Foo" or can it describe sender = desires (recipient
> characteristics) "Please use Foo" as = well? For example, how
> can a callout server change OPES processor = copying state from
> "yes" to "no" in the middle = of an OCP connection? Using
> "Processor-uses-copying" = property?
>
> How is the order of negotiations determined -- = what if both
> OPES processor and callout server send = <offer> messages "at once"?
>
> Finally, can we define a complete set of = parameters that MUST
> be negotiated for OCP Core?
>
> Let's not spent too much effort on what you = call "packet
> format" now. The choice of transport = protocol and encoding
> will have a major impact on that, I = think.
>
> Thank you,
>
> Alex.
>

------_=_NextPart_001_01C30806.CCAB55B4-- From owner-ietf-openproxy@mail.imc.org Mon Apr 21 09:42:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15025 for ; Mon, 21 Apr 2003 09:42:59 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197bbk-0000Nk-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:45:20 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197bbj-0000Nh-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:45:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LDZet2043299 for ; Mon, 21 Apr 2003 06:35:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LDZesI043298 for ietf-openproxy-bks; Mon, 21 Apr 2003 06:35:40 -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.8p1/8.12.8) with ESMTP id h3LDZdt2043292 for ; Mon, 21 Apr 2003 06:35: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 h3LDZS415597; Mon, 21 Apr 2003 09:35:28 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Apr 2003 09:35:28 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754057C80B5@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Mon, 21 Apr 2003 09:35:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3080A.DE0BD65E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C3080A.DE0BD65E Content-Type: text/plain Hi, sorry for the dealy see inline Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, April 17, 2003 4:58 PM > To: ietf-openproxy@imc.org > Subject: SOAP and OCP > > > > Abbie Barbir argued that OPES processors should support SOAP > as a foundation of OCP. Abbie, I think it is time to resume > that discussion in the OCP transport light/scope. I have > three basic questions: > > 1. SOAP is not a transport protocol. Would you > require a specific transport protocol to > be used if OCP is implemented using SOAP? > For example, would you require that BEEP/TCP and > only BEEP/TCP is used under SOAP? > Yes, but there are bindings defined for SOAP (like HTTP, BEEP ?). No we will not require specific bindings. We have agreed that this OCP draft basically define metadata/state machine for OCP and that bindings will be defined later. IF we use SOAP, then SOAP can have its own bindings. This way we define SOAP/OCP and then SOAP over ... can be defined by anyone else. > 2. My understanding is that using SOAP pretty > much requires XML message format/encoding for > OCP messages. How do you suggest we implement > OCP data pipeline with SOAP? More specifically, > what is the best way to transfer, say, a 900KB > "binary" stream from OPES processor to callout server? > Single large SOAP message? Multiple small messages? > How to encode binary data? > SOAP can have various ways of encoding binary data and in general it is not efficient. However, SOAP 1.2 support attachements. Mesasges can be frammed/fragemented etc.. by the SOAP over xxx protocol. XML must be used, but we can have a core XML set that can be parsed quickly. Yes there will be overhead and Yes we can try to minimize it. > 3. Does SOAP allow for SOAP "connections" that are > mapped to transport connections of some kind? > If we do not have access to transport connections, > how do we keep state and avoid constant > renegotiations? How do we guarantee that two > messages to the same callout server IP address > end up at the same server (as opposed to being > NATed or load-balanced to different servers)? Do > we care about IP not being sufficient to identify > a real server? > SOAP will run over another protocol. So the answere here is a function of the underlying protocol. IF we ignore SOAP for now, you still need to answere the same questions if you are using HTTP over HTTP (something like ICAP). So basically, there is no reason for not be able to do with over SOAP/.... I think SOAP can be a very good match, since, we can define SOAP over any of the transport (I am using it here in general terms like HTTP, BEEP, SIP, SMTP, FTP, etc..). Using SOAP can really make our job much easier, since the underlying protocol can be defined by anyone. Abbie ------_=_NextPart_001_01C3080A.DE0BD65E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: SOAP and OCP

Hi,
sorry for the dealy
see inline

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Thursday, April 17, 2003 4:58 PM
> To: ietf-openproxy@imc.org
> Subject: SOAP and OCP
>
>
>
> Abbie Barbir argued that OPES processors should = support SOAP
> as a foundation of OCP. Abbie, I think it is = time to resume
> that discussion in the OCP transport = light/scope. I have
> three basic questions:
>
>       1. SOAP is not a = transport protocol. Would you
>          = require a specific transport protocol to
>          be = used if OCP is implemented using SOAP?
>          For = example, would you require that BEEP/TCP and
>          = only BEEP/TCP is used under SOAP?
>

Yes, but there are bindings defined for SOAP (like = HTTP, BEEP ?).
No we will not require specific bindings. We have = agreed that this OCP draft basically define
metadata/state machine for OCP and that bindings = will be defined later. IF we use SOAP, then SOAP can have its own = bindings. This way we define SOAP/OCP and then SOAP over ... can be = defined by anyone else.


>       2. My = understanding is that using SOAP pretty
>          = much requires XML message format/encoding for
>          OCP = messages. How do you suggest we implement
>          OCP = data pipeline with SOAP? More specifically,
>          = what is the best way to transfer, say, a 900KB
>          = "binary" stream from OPES processor to callout server?
>          = Single large SOAP message? Multiple small messages?
>          How = to encode binary data?
>

SOAP can have various ways of encoding binary data = and in general it is not efficient. However, SOAP 1.2 support = attachements. Mesasges can be frammed/fragemented etc.. by the SOAP = over xxx protocol.

XML must be used, but we can have a core XML set that = can be parsed quickly. Yes there will be overhead and Yes we can try to = minimize it.

>       3. Does SOAP = allow for SOAP "connections" that are
>          = mapped to transport connections of some kind?
>          If = we do not have access to transport connections,
>          how = do we keep state and avoid constant
>          = renegotiations? How do we guarantee that two
>          = messages to the same callout server IP address
>          end = up at the same server (as opposed to being
>          = NATed or load-balanced to different servers)? Do
>          we = care about IP not being sufficient to identify
>          a = real server?
>

SOAP will run over another protocol. So the answere = here is a function of the underlying protocol. IF we ignore SOAP for = now, you still need to answere the same questions if you are using HTTP = over HTTP (something like ICAP). So basically, there is no reason for = not be able to do with over SOAP/....

I think SOAP can be a very good match, since, we can = define SOAP over any of the transport (I am using it here in general = terms like HTTP, BEEP, SIP, SMTP, FTP, etc..).

Using SOAP can really make our job much easier, since = the underlying protocol can be defined by anyone.



Abbie

------_=_NextPart_001_01C3080A.DE0BD65E-- From owner-ietf-openproxy@mail.imc.org Mon Apr 21 09:43:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15053 for ; Mon, 21 Apr 2003 09:43:59 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197bci-0000O4-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:46:20 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197bch-0000O1-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:46:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LDYwt2043263 for ; Mon, 21 Apr 2003 06:34:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LDYwJE043260 for ietf-openproxy-bks; Mon, 21 Apr 2003 06:34:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LDYvt2043235 for ; Mon, 21 Apr 2003 06:34:57 -0700 (PDT) (envelope-from batuner@attbi.com) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <20030421133446051004rv2pe>; Mon, 21 Apr 2003 13:34:47 +0000 From: "Oskar Batuner" To: "Abbie Barbir" , "Alex Rousskov" , Subject: RE: Capability Negotiation for OCP Date: Mon, 21 Apr 2003 09:34:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C307E9.40DA0430" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <87609AFB433BD5118D5E0002A52CD754057C803E@zcard0k6.ca.nortel.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C307E9.40DA0430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Capability Negotiation for OCPDid we have made a decision on BEEP? The BEEP discussion had no conclusive end, in fact for me it looks more like a pause. There were pros and cons discussed, more pros than cons, but no conclusion. If we are going to adopt BEEP many things will be shaped by that. Alex, what do you think? Oskar -----Original Message----- From: owner-ietf-openproxy@mail.imc.org [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Abbie Barbir Sent: Monday, April 21, 2003 9:06 AM To: Alex Rousskov; ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP hi, how about Authentication/Authorization/encrytption. how/when these will be negotiated/supported etc. Are we talking about another encapsulation (like HTTPS or SASL) here or what? Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, April 17, 2003 2:58 PM > To: ietf-openproxy@imc.org > Subject: Re: Capability Negotiation for OCP > > > > > On Thu, 17 Apr 2003, Reinaldo Penno wrote: > > > These are my ideas on capability negotiation. They are a > mix of SDP's > > offer/answer, BGP and PPP. > > Sounds like a great start to me. I am sure we will run into > arguments once the wording becomes more specific. > > One high-level thing to consider now is scope (level) > definition: Do we want to have a fixed number of levels > associated with OCP entities like connection and transaction? > Or do we want to allow unlimited nesting? For example, is it > possible that something needs to be re-negotiated in the > middle of a transaction? > > Another issue: are negotiations always limited in scope to a > single transport connection? Are we worried that two > connections to the same IP may not end up at the same callout > server? In other words, if an OPES processor wants to open 10 > connections to a callout server, does it need to negotiate > each from scratch OR can it refer to earlier > ("cached") negotiations? > > Semantically, does describe sender characteristics "I > can use Foo" or can it describe sender desires (recipient > characteristics) "Please use Foo" as well? For example, how > can a callout server change OPES processor copying state from > "yes" to "no" in the middle of an OCP connection? Using > "Processor-uses-copying" property? > > How is the order of negotiations determined -- what if both > OPES processor and callout server send messages "at once"? > > Finally, can we define a complete set of parameters that MUST > be negotiated for OCP Core? > > Let's not spent too much effort on what you call "packet > format" now. The choice of transport protocol and encoding > will have a major impact on that, I think. > > Thank you, > > Alex. > ------=_NextPart_000_004D_01C307E9.40DA0430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Capability Negotiation for OCP
Did we=20 have made a decision on BEEP? The BEEP discussion had no =
conclusive end, in fact for me it looks more like a pause. = There were=20
pros=20 and cons discussed, more pros than cons, but no conclusion. =
 
If we=20 are going to adopt BEEP many things will be shaped by that. =
 
Alex,=20 what do you think?
 
Oskar
-----Original Message-----
From:=20 owner-ietf-openproxy@mail.imc.org=20 [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Abbie=20 Barbir
Sent: Monday, April 21, 2003 9:06 AM
To: = Alex=20 Rousskov; ietf-openproxy@imc.org
Subject: RE: Capability = Negotiation=20 for OCP

hi,
how about=20 Authentication/Authorization/encrytption.

how/when these will be negotiated/supported = etc.=20
Are we talking about another encapsulation (like = HTTPS or=20 SASL) here or what?


Abbie


> -----Original Message-----
>=20 From: Alex Rousskov [mailto:rousskov@measurem= ent-factory.com]=20
> Sent: Thursday, April 17, 2003 2:58 = PM=20
> To: ietf-openproxy@imc.org
>=20 Subject: Re: Capability Negotiation for OCP
>=20
>
> =
>
> On Thu, 17 Apr 2003, = Reinaldo Penno=20 wrote:
>
> = > These=20 are my ideas on capability negotiation. They are a
> mix of SDP's
> > = offer/answer, BGP=20 and PPP.
>
> = Sounds like=20 a great start to me. I am sure we will run into
>=20 arguments once the wording becomes more specific.
>=20
> One high-level thing to consider now is = scope=20 (level)
> definition: Do we want to have = a fixed=20 number of levels
> associated with OCP = entities=20 like connection and transaction?
> Or do = we want to=20 allow unlimited nesting? For example, is it
>=20 possible that something needs to be re-negotiated in the =
> middle of a transaction?
>=20
> Another issue: are negotiations always = limited in=20 scope to a
> single transport connection? = Are we=20 worried that two
> connections to the = same IP may=20 not end up at the same callout
> server? = In other=20 words, if an OPES processor wants to open 10
>=20 connections to a callout server, does it need to negotiate =
> each from scratch OR can it refer to earlier =
> ("cached") negotiations?
>=20
> Semantically, does <offer> = describe sender=20 characteristics "I
> can use Foo" or can = it=20 describe sender desires (recipient
>=20 characteristics) "Please use Foo" as well? For example, how =
> can a callout server change OPES processor copying state = from=20
> "yes" to "no" in the middle of an OCP = connection?=20 Using
> "Processor-uses-copying" = property?=20
>
> How is the = order of=20 negotiations determined -- what if both
> = OPES=20 processor and callout server send <offer> messages "at = once"?=20
>
> Finally, can we = define a=20 complete set of parameters that MUST
> be = negotiated for OCP Core?
> =
> Let's not spent too much effort on what you call "packet =
> format" now. The choice of transport = protocol and=20 encoding
> will have a major impact on = that, I=20 think.
>
> = Thank=20 you,
>
> = Alex.=20
>

------=_NextPart_000_004D_01C307E9.40DA0430-- From owner-ietf-openproxy@mail.imc.org Mon Apr 21 09:48:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15307 for ; Mon, 21 Apr 2003 09:48:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197bhP-0000QV-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:51:11 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197bhO-0000QS-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 09:51:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LDcat2043443 for ; Mon, 21 Apr 2003 06:38:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LDcap0043442 for ietf-openproxy-bks; Mon, 21 Apr 2003 06:38: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.8p1/8.12.8) with ESMTP id h3LDcZt2043430 for ; Mon, 21 Apr 2003 06:38:35 -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 h3LDcN415870; Mon, 21 Apr 2003 09:38:23 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Apr 2003 09:38:23 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754057C80C2@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Oskar Batuner , Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP Date: Mon, 21 Apr 2003 09:38:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3080B.46E29DE8" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C3080B.46E29DE8 Content-Type: text/plain Oskar, We can not decide on BEEP now. We have to eliminate other candidates like SOAP first. Basically, u r right, this is only a Pause. Abbie -----Original Message----- From: Oskar Batuner [mailto:batuner@attbi.com] Sent: Monday, April 21, 2003 9:35 AM To: Barbir, Abbie [CAR:1A00:EXCH]; Alex Rousskov; ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP Did we have made a decision on BEEP? The BEEP discussion had no conclusive end, in fact for me it looks more like a pause. There were pros and cons discussed, more pros than cons, but no conclusion. If we are going to adopt BEEP many things will be shaped by that. Alex, what do you think? Oskar -----Original Message----- From: owner-ietf-openproxy@mail.imc.org [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Abbie Barbir Sent: Monday, April 21, 2003 9:06 AM To: Alex Rousskov; ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP hi, how about Authentication/Authorization/encrytption. how/when these will be negotiated/supported etc. Are we talking about another encapsulation (like HTTPS or SASL) here or what? Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com ] > Sent: Thursday, April 17, 2003 2:58 PM > To: ietf-openproxy@imc.org > Subject: Re: Capability Negotiation for OCP > > > > > On Thu, 17 Apr 2003, Reinaldo Penno wrote: > > > These are my ideas on capability negotiation. They are a > mix of SDP's > > offer/answer, BGP and PPP. > > Sounds like a great start to me. I am sure we will run into > arguments once the wording becomes more specific. > > One high-level thing to consider now is scope (level) > definition: Do we want to have a fixed number of levels > associated with OCP entities like connection and transaction? > Or do we want to allow unlimited nesting? For example, is it > possible that something needs to be re-negotiated in the > middle of a transaction? > > Another issue: are negotiations always limited in scope to a > single transport connection? Are we worried that two > connections to the same IP may not end up at the same callout > server? In other words, if an OPES processor wants to open 10 > connections to a callout server, does it need to negotiate > each from scratch OR can it refer to earlier > ("cached") negotiations? > > Semantically, does describe sender characteristics "I > can use Foo" or can it describe sender desires (recipient > characteristics) "Please use Foo" as well? For example, how > can a callout server change OPES processor copying state from > "yes" to "no" in the middle of an OCP connection? Using > "Processor-uses-copying" property? > > How is the order of negotiations determined -- what if both > OPES processor and callout server send messages "at once"? > > Finally, can we define a complete set of parameters that MUST > be negotiated for OCP Core? > > Let's not spent too much effort on what you call "packet > format" now. The choice of transport protocol and encoding > will have a major impact on that, I think. > > Thank you, > > Alex. > ------_=_NextPart_001_01C3080B.46E29DE8 Content-Type: text/html Message
Oskar,
 
We can not decide on BEEP now.
We have to eliminate other candidates like SOAP first.
Basically, u r right, this is only a Pause.
 
 
Abbie
 
-----Original Message-----
From: Oskar Batuner [mailto:batuner@attbi.com]
Sent: Monday, April 21, 2003 9:35 AM
To: Barbir, Abbie [CAR:1A00:EXCH]; Alex Rousskov; ietf-openproxy@imc.org
Subject: RE: Capability Negotiation for OCP

Did we have made a decision on BEEP? The BEEP discussion had no
conclusive end, in fact for me it looks more like a pause. There were
pros and cons discussed, more pros than cons, but no conclusion.
 
If we are going to adopt BEEP many things will be shaped by that.
 
Alex, what do you think?
 
Oskar
-----Original Message-----
From: owner-ietf-openproxy@mail.imc.org [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Abbie Barbir
Sent: Monday, April 21, 2003 9:06 AM
To: Alex Rousskov; ietf-openproxy@imc.org
Subject: RE: Capability Negotiation for OCP

hi,
how about Authentication/Authorization/encrytption.

how/when these will be negotiated/supported etc.
Are we talking about another encapsulation (like HTTPS or SASL) here or what?


Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measurement-factory.com]
> Sent: Thursday, April 17, 2003 2:58 PM
> To: ietf-openproxy@imc.org
> Subject: Re: Capability Negotiation for OCP
>
>
>
>
> On Thu, 17 Apr 2003, Reinaldo Penno wrote:
>
> > These are my ideas on capability negotiation. They are a
> mix of SDP's
> > offer/answer, BGP and PPP.
>
> Sounds like a great start to me. I am sure we will run into
> arguments once the wording becomes more specific.
>
> One high-level thing to consider now is scope (level)
> definition: Do we want to have a fixed number of levels
> associated with OCP entities like connection and transaction?
> Or do we want to allow unlimited nesting? For example, is it
> possible that something needs to be re-negotiated in the
> middle of a transaction?
>
> Another issue: are negotiations always limited in scope to a
> single transport connection? Are we worried that two
> connections to the same IP may not end up at the same callout
> server? In other words, if an OPES processor wants to open 10
> connections to a callout server, does it need to negotiate
> each from scratch OR can it refer to earlier
> ("cached") negotiations?
>
> Semantically, does <offer> describe sender characteristics "I
> can use Foo" or can it describe sender desires (recipient
> characteristics) "Please use Foo" as well? For example, how
> can a callout server change OPES processor copying state from
> "yes" to "no" in the middle of an OCP connection? Using
> "Processor-uses-copying" property?
>
> How is the order of negotiations determined -- what if both
> OPES processor and callout server send <offer> messages "at once"?
>
> Finally, can we define a complete set of parameters that MUST
> be negotiated for OCP Core?
>
> Let's not spent too much effort on what you call "packet
> format" now. The choice of transport protocol and encoding
> will have a major impact on that, I think.
>
> Thank you,
>
> Alex.
>

------_=_NextPart_001_01C3080B.46E29DE8-- From owner-ietf-openproxy@mail.imc.org Mon Apr 21 11:04:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18995 for ; Mon, 21 Apr 2003 11:04:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197csJ-0000q9-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 11:06:31 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197csI-0000pl-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 11:06:30 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LErZt2048965 for ; Mon, 21 Apr 2003 07:53:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LErZEB048964 for ietf-openproxy-bks; Mon, 21 Apr 2003 07:53:35 -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.8p1/8.12.8) with ESMTP id h3LErXt2048953 for ; Mon, 21 Apr 2003 07:53:34 -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 h3LErXvj072636; Mon, 21 Apr 2003 08:53:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3LErXIr072635; Mon, 21 Apr 2003 08:53:33 -0600 (MDT) (envelope-from rousskov) Date: Mon, 21 Apr 2003 08:53:33 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: SOAP and OCP In-Reply-To: <87609AFB433BD5118D5E0002A52CD754057C80B5@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754057C80B5@zcard0k6.ca.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: Abbie, Can you point me to specific specs describing "binary" (opaque, really) data transfer capability of SOAP (or XML)? Also, you mentioned previously that we should consider SOAP because web services use SOAP. I would like to make that statement more precise so that we can evaluate this advantage. If OCP is built on top of SOAP, do you expect any existing web services to be able to act as callout servers "as is", without _any_ modifications? Or do you expect modification of existing services to support OCP-over-SOAP to be "easier" than similar modification to support OCP-over-notSOAP? Thank you for the other two clarifications. It looks like BEEP provides similar features with respect to the transport protocol selection and even better (more direct) features for connection state management. Alex. On Mon, 21 Apr 2003, Abbie Barbir wrote: > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Thursday, April 17, 2003 4:58 PM > > To: ietf-openproxy@imc.org > > Subject: SOAP and OCP > > > > Abbie Barbir argued that OPES processors should support SOAP > > as a foundation of OCP. Abbie, I think it is time to resume > > that discussion in the OCP transport light/scope. I have > > three basic questions: > > > > 1. SOAP is not a transport protocol. Would you > > require a specific transport protocol to > > be used if OCP is implemented using SOAP? > > For example, would you require that BEEP/TCP and > > only BEEP/TCP is used under SOAP? > > > > Yes, but there are bindings defined for SOAP (like HTTP, BEEP ?). No > we will not require specific bindings. We have agreed that this OCP > draft basically define metadata/state machine for OCP and that > bindings will be defined later. IF we use SOAP, then SOAP can have > its own bindings. This way we define SOAP/OCP and then SOAP over ... > can be defined by anyone else. > > > > 2. My understanding is that using SOAP pretty > > much requires XML message format/encoding for > > OCP messages. How do you suggest we implement > > OCP data pipeline with SOAP? More specifically, > > what is the best way to transfer, say, a 900KB > > "binary" stream from OPES processor to callout server? > > Single large SOAP message? Multiple small messages? > > How to encode binary data? > > > > SOAP can have various ways of encoding binary data and in general it > is not efficient. However, SOAP 1.2 support attachements. Mesasges > can be frammed/fragemented etc.. by the SOAP over xxx protocol. > > XML must be used, but we can have a core XML set that can be parsed > quickly. Yes there will be overhead and Yes we can try to minimize > it. > > > 3. Does SOAP allow for SOAP "connections" that are > > mapped to transport connections of some kind? > > If we do not have access to transport connections, > > how do we keep state and avoid constant > > renegotiations? How do we guarantee that two > > messages to the same callout server IP address > > end up at the same server (as opposed to being > > NATed or load-balanced to different servers)? Do > > we care about IP not being sufficient to identify > > a real server? > > > > SOAP will run over another protocol. So the answere here is a > function of the underlying protocol. IF we ignore SOAP for now, you > still need to answere the same questions if you are using HTTP over > HTTP (something like ICAP). So basically, there is no reason for not > be able to do with over SOAP/.... > > I think SOAP can be a very good match, since, we can define SOAP > over any of the transport (I am using it here in general terms like > HTTP, BEEP, SIP, SMTP, FTP, etc..). > > Using SOAP can really make our job much easier, since the underlying > protocol can be defined by anyone. > > > > Abbie > From owner-ietf-openproxy@mail.imc.org Mon Apr 21 11:25:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19569 for ; Mon, 21 Apr 2003 11:25:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197dCj-0000xe-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 11:27:37 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197dCi-0000xb-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 11:27:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LF1at2049639 for ; Mon, 21 Apr 2003 08:01:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LF1ac4049638 for ietf-openproxy-bks; Mon, 21 Apr 2003 08:01: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.8p1/8.12.8) with ESMTP id h3LF1Zt2049628 for ; Mon, 21 Apr 2003 08:01:35 -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 h3LF1O418365; Mon, 21 Apr 2003 11:01:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Apr 2003 11:01:24 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754057C822B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP Date: Mon, 21 Apr 2003 11:01:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30816.DCF3B92E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30816.DCF3B92E Content-Type: text/plain Alex, agreed, abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Monday, April 21, 2003 11:00 AM > To: ietf-openproxy@imc.org > Subject: RE: Capability Negotiation for OCP > > > On Mon, 21 Apr 2003, Abbie Barbir wrote: > > > how about Authentication/Authorization/encrytption. > > > > how/when these will be negotiated/supported etc. Are we > talking about > > another encapsulation (like HTTPS or SASL) here or what? > > It would depend on the transport protocol selection, I think. > If the transport protocol already has mechanisms to support > Authentication/Authorization/encrytption, then those > mechanisms should be reused. IMO, possibility of this kind of > reuse would be the primary advantage of selecting an existing > application transport (e.g., BEEP) compared to new low-level OCPTRAN. > > Since so many things depend on the transport now, we need to select > transport(s) as soon as possible. > > Alex. > ------_=_NextPart_001_01C30816.DCF3B92E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Capability Negotiation for OCP

Alex,
agreed,

abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Monday, April 21, 2003 11:00 AM
> To: ietf-openproxy@imc.org
> Subject: RE: Capability Negotiation for = OCP
>
>
> On Mon, 21 Apr 2003, Abbie Barbir wrote:
>
> > how about = Authentication/Authorization/encrytption.
> >
> > how/when these will be = negotiated/supported etc. Are we
> talking about
> > another encapsulation (like HTTPS or SASL) = here or what?
>
> It would depend on the transport protocol = selection, I think.
> If the transport protocol already has = mechanisms to support
> Authentication/Authorization/encrytption, then = those
> mechanisms should be reused. IMO, possibility = of this kind of
> reuse would be the primary advantage of = selecting an existing
> application transport (e.g., BEEP) compared to = new low-level OCPTRAN.
>
> Since so many things depend on the transport = now, we need to select
> transport(s) as soon as possible.
>
> Alex.
>

------_=_NextPart_001_01C30816.DCF3B92E-- From owner-ietf-openproxy@mail.imc.org Mon Apr 21 11:26:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19603 for ; Mon, 21 Apr 2003 11:26:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197dDY-0000y9-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 11:28:28 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197dDX-0000y6-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 11:28:28 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LFHEt2050169 for ; Mon, 21 Apr 2003 08:17:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LFHD4a050168 for ietf-openproxy-bks; Mon, 21 Apr 2003 08:17:14 -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.8p1/8.12.8) with ESMTP id h3LFHCt2050163 for ; Mon, 21 Apr 2003 08:17:12 -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 h3LFHCvj073242; Mon, 21 Apr 2003 09:17:12 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3LFHC3j073241; Mon, 21 Apr 2003 09:17:12 -0600 (MDT) (envelope-from rousskov) Date: Mon, 21 Apr 2003 09:17:12 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP In-Reply-To: Message-ID: References: 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: On Mon, 21 Apr 2003, Oskar Batuner wrote: > Did we have made a decision on BEEP? No. > The BEEP discussion had no conclusive end, in fact for me it looks > more like a pause. There were pros and cons discussed, more pros > than cons, but no conclusion. The discussion is not over. We now know at least two ways to map OCP to BEEP. We still need to compare BEEP with other candidates. > If we are going to adopt BEEP many things will be shaped by that. Yes, as with any other existing transport protocol. At this time, I have a more-or-less clear picture of how to map OCP to BEEP. I would like proponents of other approaches (Abbie for SOAP and Hilarie for OCPTRAN) to argue their positions, either "in general" or "relative to BEEP", whatever format they prefer. I tried to ask a few questions about SOAP and OCPTRAN to facilitate this discussion. I would also like to hear Martin Stecher's opinion on transport selection. As ICAP fan, Martin may want to push for HTTP as the transport to make OCP look like ICAP/2.0. I did say that HTTP is not ideal transport for OCP, but we have to keep many factors in mind when selecting the protocol. If we consider SOAP because Web Services use SOAP, we must consider HTTP because ICAP servers use HTTP. Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 21 11:28:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19711 for ; Mon, 21 Apr 2003 11:28:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197dFW-000104-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 11:30:30 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197dFV-000101-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 11:30:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LExot2049538 for ; Mon, 21 Apr 2003 07:59:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LExooe049537 for ietf-openproxy-bks; Mon, 21 Apr 2003 07:59:50 -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.8p1/8.12.8) with ESMTP id h3LExnt2049531 for ; Mon, 21 Apr 2003 07:59: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 h3LExovj072760; Mon, 21 Apr 2003 08:59:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3LExoUr072759; Mon, 21 Apr 2003 08:59:50 -0600 (MDT) (envelope-from rousskov) Date: Mon, 21 Apr 2003 08:59:50 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP In-Reply-To: <87609AFB433BD5118D5E0002A52CD754057C803E@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754057C803E@zcard0k6.ca.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: On Mon, 21 Apr 2003, Abbie Barbir wrote: > how about Authentication/Authorization/encrytption. > > how/when these will be negotiated/supported etc. Are we talking > about another encapsulation (like HTTPS or SASL) here or what? It would depend on the transport protocol selection, I think. If the transport protocol already has mechanisms to support Authentication/Authorization/encrytption, then those mechanisms should be reused. IMO, possibility of this kind of reuse would be the primary advantage of selecting an existing application transport (e.g., BEEP) compared to new low-level OCPTRAN. Since so many things depend on the transport now, we need to select transport(s) as soon as possible. Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 21 12:41:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21848 for ; Mon, 21 Apr 2003 12:41:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197eOj-0001S3-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 12:44:05 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197eOi-0001Rz-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 12:44:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LGXNt2052618 for ; Mon, 21 Apr 2003 09:33:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LGXNUM052617 for ietf-openproxy-bks; Mon, 21 Apr 2003 09:33:23 -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.8p1/8.12.8) with ESMTP id h3LGXMt2052611 for ; Mon, 21 Apr 2003 09:33:22 -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 h3LGXA404315; Mon, 21 Apr 2003 12:33:11 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Apr 2003 12:33:11 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754057C8356@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Mon, 21 Apr 2003 12:33:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30823.B14E09E8" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30823.B14E09E8 Content-Type: text/plain Alex, Try w3c (SOAP 1.2) http://www.xml.org http://www.xml.com/pub/a/2003/02/26/binaryxml.html http://www.w3.org/TR/soap12-af/ see inline Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Monday, April 21, 2003 10:54 AM > To: ietf-openproxy@imc.org > Subject: RE: SOAP and OCP > > > Abbie, > > Can you point me to specific specs describing "binary" > (opaque, really) data transfer capability of SOAP (or XML)? > > Also, you mentioned previously that we should consider > SOAP because web services use SOAP. I would like to make that > statement more precise so that we can evaluate this > advantage. If OCP is built on top of SOAP, do you expect any > existing web services to be able to act as callout servers > "as is", without _any_ modifications? Or do you expect > modification of existing services to support OCP-over-SOAP to > be "easier" than similar modification to support OCP-over-notSOAP? > Yes, web services uses SOAP and this will allow OPES to be plugged into that area (as opposed to be a competitor). The short answere to your question about modifications is Yes. By definition a web services once discovered and its description is obatianed is immediatly interoperable. On the otherhand, a schema of OCP can be written that could be used by the web services server that he will use to become an OPES Callout server. > Thank you for the other two clarifications. It looks > like BEEP provides similar features with respect to the > transport protocol selection and even better (more direct) > features for connection state management. > > Alex. SNIP Abbie ------_=_NextPart_001_01C30823.B14E09E8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: SOAP and OCP

Alex,

Try w3c (SOAP 1.2)
http://www.xml.org
http://www.xml.com/pub/a/2003/02/26/binaryxml.html=
http://www.w3.org/TR/soap12-af/


see inline
Abbie
 

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Monday, April 21, 2003 10:54 AM
> To: ietf-openproxy@imc.org
> Subject: RE: SOAP and OCP
>
>
> Abbie,
>
>       Can you point me = to specific specs describing "binary"
> (opaque, really) data transfer capability of = SOAP (or XML)?
>
>       Also, you = mentioned previously that we should consider
> SOAP because web services use SOAP. I would = like to make that
> statement more precise so that we can evaluate = this
> advantage. If OCP is built on top of SOAP, do = you expect any
> existing web services to be able to act as = callout servers
> "as is", without _any_ modifications? = Or do you expect
> modification of existing services to support = OCP-over-SOAP to
> be "easier" than similar modification = to support OCP-over-notSOAP?
>

Yes, web services uses SOAP and this will allow OPES = to be plugged into that area (as opposed to be a competitor).
The short answere to your question about = modifications is Yes. By definition a web services once discovered and = its description is obatianed is immediatly interoperable.

On the otherhand, a schema of OCP can be written that = could be used by the web services server that he will use to become an = OPES Callout server.


>       Thank you for the = other two clarifications. It looks
> like BEEP provides similar features with = respect to the
> transport protocol selection and even better = (more direct)
> features for connection state = management.
>
> Alex.
 SNIP

Abbie

------_=_NextPart_001_01C30823.B14E09E8-- From owner-ietf-openproxy@mail.imc.org Mon Apr 21 13:45:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23892 for ; Mon, 21 Apr 2003 13:45:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197fOi-0001tx-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 13:48:08 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197fOg-0001ta-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 13:48:07 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LHYAt2056327 for ; Mon, 21 Apr 2003 10:34:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LHYAtJ056326 for ietf-openproxy-bks; Mon, 21 Apr 2003 10:34:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LHY8t2056318 for ; Mon, 21 Apr 2003 10:34:08 -0700 (PDT) (envelope-from rpenno@nortelnetworks.com) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3LHXuo03356; Mon, 21 Apr 2003 10:33:56 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2R1B6TWV>; Mon, 21 Apr 2003 10:33:41 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18EB8@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP Date: Mon, 21 Apr 2003 10:33:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3082B.E04E223E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C3082B.E04E223E Content-Type: text/plain We are having discussions on capability negotiation in the PANA WG also. I thought on copying their required functionality here to see if we need this in OCP. PAA and PAC are the peers. > A) > > Pac <-- Paa: i support x,y and z > Pac --> Paa: i would like to use y > > B) > Pac --> Paa: enable x > Pac <-- Paa: status (ok, failed) > > C) > Pac <-- Paa: you must use y > Pac --> Paa: status (ok, failed) > > D) > Pac --> Paa: what do you support? > Pac <-- Paa: i support x,y and z Regards, Reinaldo > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Monday, April 21, 2003 11:00 AM > To: ietf-openproxy@imc.org > Subject: RE: Capability Negotiation for OCP > > > > On Mon, 21 Apr 2003, Abbie Barbir wrote: > > > how about Authentication/Authorization/encrytption. > > > > how/when these will be negotiated/supported etc. Are we > talking about > > another encapsulation (like HTTPS or SASL) here or what? > > It would depend on the transport protocol selection, I think. > If the transport protocol already has mechanisms to support > Authentication/Authorization/encrytption, then those > mechanisms should be reused. IMO, possibility of this kind of > reuse would be the primary advantage of selecting an existing > application transport (e.g., BEEP) compared to new low-level OCPTRAN. > > Since so many things depend on the transport now, we need to select > transport(s) as soon as possible. > > Alex. > ------_=_NextPart_001_01C3082B.E04E223E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Capability Negotiation for OCP

We are having discussions on capability negotiation = in the PANA WG also. I thought on copying their required functionality = here to see if we need this in OCP. PAA and PAC are the = peers.

> A)
>
> Pac <-- Paa: i support x,y and z
> Pac --> Paa: i would like to use y
>
> B)
> Pac --> Paa: enable x
> Pac <-- Paa: status (ok, failed)
>
> C)
> Pac <-- Paa: you must use y
> Pac --> Paa: status (ok, failed)
>
> D)
> Pac --> Paa: what do you support?
> Pac <-- Paa: i support x,y and z

Regards,

Reinaldo

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Monday, April 21, 2003 11:00 AM
> To: ietf-openproxy@imc.org
> Subject: RE: Capability Negotiation for = OCP
>
>
>
> On Mon, 21 Apr 2003, Abbie Barbir wrote:
>
> > how about = Authentication/Authorization/encrytption.
> >
> > how/when these will be = negotiated/supported etc. Are we
> talking about
> > another encapsulation (like HTTPS or SASL) = here or what?
>
> It would depend on the transport protocol = selection, I think.
> If the transport protocol already has = mechanisms to support
> Authentication/Authorization/encrytption, then = those
> mechanisms should be reused. IMO, possibility = of this kind of
> reuse would be the primary advantage of = selecting an existing
> application transport (e.g., BEEP) compared to = new low-level OCPTRAN.
>
> Since so many things depend on the transport = now, we need to select
> transport(s) as soon as possible.
>
> Alex.
>

------_=_NextPart_001_01C3082B.E04E223E-- From owner-ietf-openproxy@mail.imc.org Mon Apr 21 13:53:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24167 for ; Mon, 21 Apr 2003 13:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197fWE-0001yy-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 13:55:54 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197fWD-0001yv-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 13:55:54 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LHirt2056517 for ; Mon, 21 Apr 2003 10:44:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LHirN7056516 for ietf-openproxy-bks; Mon, 21 Apr 2003 10:44: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.8p1/8.12.8) with ESMTP id h3LHiqt2056511 for ; Mon, 21 Apr 2003 10:44: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 h3LHirvj076783; Mon, 21 Apr 2003 11:44:53 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3LHirMn076782; Mon, 21 Apr 2003 11:44:53 -0600 (MDT) (envelope-from rousskov) Date: Mon, 21 Apr 2003 11:44:53 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: SOAP and OCP In-Reply-To: <87609AFB433BD5118D5E0002A52CD754057C8356@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754057C8356@zcard0k6.ca.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: On Mon, 21 Apr 2003, Abbie Barbir wrote: > Try w3c (SOAP 1.2) > http://www.xml.org > http://www.xml.com/pub/a/2003/02/26/binaryxml.html > http://www.w3.org/TR/soap12-af/ OK. So it looks like we have at least two choices when it comes to transmitting opaque data over SOAP. First, we can base64-encode it. The "binaryxml.html" document argues that encoding is the right way to go because it lets us stay within XML boundaries. On the other hand, encoding is expensive (CPU and bandwidth wise). The second option is to use MIME-like "attachments". The worst part is that there is no "standard" way to transmit opaque data over SOAP yet. Implementations use different approaches and may not be compatible. Please correct me if I am wrong. OCP is about exchanging opaque data and metadata. XML does not support opaque data well. That is why SOAP does not support opaque data well. From this point of view, SOAP is the wrong protocol to base OCP on -- the primary OCP function is not well supported. Other factors may be more important though. > > If OCP is built on top of SOAP, do you expect any > > existing web services to be able to act as callout servers > > "as is", without _any_ modifications? Or do you expect > > modification of existing services to support OCP-over-SOAP to > > be "easier" than similar modification to support OCP-over-notSOAP? > > > > Yes, web services uses SOAP and this will allow OPES to be plugged > into that area (as opposed to be a competitor). The short answere to > your question about modifications is Yes. By definition a web > services once discovered and its description is obatianed is > immediatly interoperable. On the otherhand, a schema of OCP can be > written that could be used by the web services server that he will > use to become an OPES Callout server. I am not sure I understand the answer. What does it mean to be "immediatly interoperable by definition"? My understanding is that any existing web service can already participate in an OPES system "as is" as long as the OPES processor using the service supports SOAP. However, such participation is outside of OCP scope because OCP is not SOAP; OCP is a stand-alone protocol that has features not described in SOAP specs. To support OCP, a web service must be modified. In other words, SOAP may be used as an OPES callout protocol (from architectural point of view). However, the protocol we are working on (OCP), is not identical to SOAP (but can be implemented on top of SOAP). Modifications would be required for existing web services to support OCP. Is my understanding correct? If it is, we may have a good compromise available: treat both OCP and SOAP as possible callout protocols and make sure that OPES framework is not OCP- or SOAP-specific. OPES implementations will use the most appropriate protocol for their needs. Comments? Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 21 14:23:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25255 for ; Mon, 21 Apr 2003 14:23:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197fzZ-0002CM-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 14:26:13 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197fzZ-0002CJ-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 14:26:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LIDPt2057123 for ; Mon, 21 Apr 2003 11:13:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LIDPIE057122 for ietf-openproxy-bks; Mon, 21 Apr 2003 11:13: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.8p1/8.12.8) with ESMTP id h3LIDLt2057112 for ; Mon, 21 Apr 2003 11:13: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 h3LIDNvj078539; Mon, 21 Apr 2003 12:13:23 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3LIDNZm078538; Mon, 21 Apr 2003 12:13:23 -0600 (MDT) (envelope-from rousskov) Date: Mon, 21 Apr 2003 12:13:23 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Capability Negotiation for OCP In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18EB8@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18EB8@zsc3c026.us.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: On Mon, 21 Apr 2003, Reinaldo Penno wrote: > We are having discussions on capability negotiation in the PANA WG also. I > thought on copying their required functionality here to see if we need this > in OCP. PAA and PAC are the peers. > > > A) > > > > Pac <-- Paa: i support x,y and z > > Pac --> Paa: i would like to use y > > > > B) > > Pac --> Paa: enable x > > Pac <-- Paa: status (ok, failed) > > > > C) > > Pac <-- Paa: you must use y > > Pac --> Paa: status (ok, failed) > > > > D) > > Pac --> Paa: what do you support? > > Pac <-- Paa: i support x,y and z These are very similar to what the current OCP draft has. These kind of questions/answers come from the general "negotiation" definition/meaning. What you posted on the list a few days ago is, essentially, a _mechanism_ to implement some (or all) of the above: --> let's use x, y, or z <-- let's use x OR failure Specifically, there is virtually no difference between B and C because "enable" and "use" are pretty much the same verbs in this context. There is also little difference between A and B because if the "I support" list is limited to "x", than that option is likely to be selected/used/enabled. I already asked you a "design" question related to this little difference: are we negotiating options used by one side or communication parameters (sued by both sides)? Item D is just a question of how the dialog is structured. In short, once you add more specifics to your scheme and answer already pending questions, we should be able to see wither A-D are already supported by the mechanism you are working on. Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 21 21:21:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11206 for ; Mon, 21 Apr 2003 21:21:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197mVV-0005PQ-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 21:23:37 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197mVU-0005PN-00 for opes-archive@ietf.org; Mon, 21 Apr 2003 21:23:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M1Art2067726 for ; Mon, 21 Apr 2003 18:10:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3M1Ark1067725 for ietf-openproxy-bks; Mon, 21 Apr 2003 18:10:53 -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.8p1/8.12.8) with ESMTP id h3M1Aqt2067717 for ; Mon, 21 Apr 2003 18:10:53 -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 h3M1Ag427468; Mon, 21 Apr 2003 21:10:42 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Apr 2003 21:10:43 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582A397@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Mon, 21 Apr 2003 21:10:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3086B.FA6E86FA" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C3086B.FA6E86FA Content-Type: text/plain ALex, See inline Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Monday, April 21, 2003 1:45 PM > To: ietf-openproxy@imc.org > Subject: RE: SOAP and OCP > > > > On Mon, 21 Apr 2003, Abbie Barbir wrote: > > > Try w3c (SOAP 1.2) > > http://www.xml.org > http://www.xml.com/pub/a/2003/02/26/binaryxml.html > > http://www.w3.org/TR/soap12-af/ > > OK. So it looks like we have at least two choices when it > comes to transmitting opaque data over SOAP. First, we can > base64-encode it. The "binaryxml.html" document argues that > encoding is the right way to go because it lets us stay > within XML boundaries. On the other hand, encoding is > expensive (CPU and bandwidth wise). The second option is to > use MIME-like "attachments". > Yes, true, this is why I said that there are ways of doing it. SO Agree. > The worst part is that there is no "standard" way to transmit > opaque data over SOAP yet. Implementations use different > approaches and may not be compatible. Please correct me if I am wrong. > Agree > OCP is about exchanging opaque data and metadata. XML does > not support opaque data well. That is why SOAP does not > support opaque data well. From this point of view, SOAP is > the wrong protocol to base OCP on -- the primary OCP function > is not well supported. Other factors may be more important though. > > > > If OCP is built on top of SOAP, do you expect any > > > existing web services to be able to act as callout > servers "as is", > > > without _any_ modifications? Or do you expect modification of > > > existing services to support OCP-over-SOAP to be "easier" than > > > similar modification to support OCP-over-notSOAP? > > > > > > > Yes, web services uses SOAP and this will allow OPES to be plugged > > into that area (as opposed to be a competitor). The short > answere to > > your question about modifications is Yes. By definition a > web services > > once discovered and its description is obatianed is immediatly > > interoperable. On the otherhand, a schema of OCP can be > written that > > could be used by the web services server that he will use > to become an > > OPES Callout server. > > I am not sure I understand the answer. What does it mean to > be "immediatly interoperable by definition"? My understanding > is that any existing web service can already participate in > an OPES system "as is" as long as the OPES processor using > the service supports SOAP. However, such participation is > outside of OCP scope because OCP is not SOAP; OCP is a > stand-alone protocol that has features not described in SOAP > specs. To support OCP, a web service must be modified. > True, that is what I mean. > In other words, SOAP may be used as an OPES callout protocol > (from architectural point of view). However, the protocol we > are working on (OCP), is not identical to SOAP (but can be > implemented on top of SOAP). Modifications would be required > for existing web services to support OCP. > very true > Is my understanding correct? If it is, we may have a good compromise > available: treat both OCP and SOAP as possible callout > protocols and make sure that OPES framework is not OCP- or > SOAP-specific. OPES implementations will use the most > appropriate protocol for their needs. > > Comments? > > Alex. I would love that. abbie ------_=_NextPart_001_01C3086B.FA6E86FA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: SOAP and OCP

ALex,
See inline
Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Monday, April 21, 2003 1:45 PM
> To: ietf-openproxy@imc.org
> Subject: RE: SOAP and OCP
>
>
>
> On Mon, 21 Apr 2003, Abbie Barbir wrote:
>
> > Try w3c (SOAP 1.2)
> > http://www.xml.org
> http://www.xml.com/pub/a/2003/02/26/binaryxml.html=
> > http://www.w3.org/TR/soap12-af/
>
> OK. So it looks like we have at least two = choices when it
> comes to transmitting opaque data over SOAP. = First, we can
> base64-encode it. The = "binaryxml.html" document argues that
> encoding is the right way to go because it lets = us stay
> within XML boundaries. On the other hand, = encoding is
> expensive (CPU and bandwidth wise). The second = option is to
> use MIME-like "attachments".
>

Yes, true, this is why I said that there are ways of = doing it.
SO Agree.

> The worst part is that there is no = "standard" way to transmit
> opaque data over SOAP yet. Implementations use = different
> approaches and may not be compatible. Please = correct me if I am wrong.
>

Agree

> OCP is about exchanging opaque data and = metadata. XML does
> not support opaque data well. That is why SOAP = does not
> support opaque data well. From this point of = view, SOAP is
> the wrong protocol to base OCP on -- the = primary OCP function
> is not well supported.  Other factors may = be more important though.
>
> > > If OCP is built on top of SOAP, do = you expect any
> > > existing web services to be able to = act as callout
> servers "as is",
> > > without _any_ modifications? Or do = you expect modification of
> > > existing services to support = OCP-over-SOAP to be "easier" than
> > > similar modification to support = OCP-over-notSOAP?
> > >
> >
> > Yes, web services uses SOAP and this will = allow OPES to be plugged
> > into that area (as opposed to be a = competitor). The short
> answere to
> > your question about modifications is Yes. = By definition a
> web services
> > once discovered and its description is = obatianed is immediatly
> > interoperable. On the otherhand, a schema = of OCP can be
> written that
> > could be used by the web services server = that he will use
> to become an
> > OPES Callout server.
>
> I am not sure I understand the answer. What = does it mean to
> be "immediatly interoperable by = definition"? My understanding
> is that any existing web service can already = participate in
> an OPES system "as is" as long as the = OPES processor using
> the service supports SOAP. However, such = participation is
> outside of OCP scope because OCP is not SOAP; = OCP is a
> stand-alone protocol that has features not = described in SOAP
> specs. To support OCP, a web service must be = modified.
>

True, that is what I mean.

> In other words, SOAP may be used as an OPES = callout protocol
> (from architectural point of view). However, = the protocol we
> are working on (OCP), is not identical to SOAP = (but can be
> implemented on top of SOAP). Modifications = would be required
> for existing web services to support = OCP.
>

very true

> Is my understanding correct? If it is, we may = have a good compromise
> available: treat both OCP and SOAP as possible = callout
> protocols and make sure that OPES framework is = not OCP- or
> SOAP-specific.  OPES implementations will = use the most
> appropriate protocol for their needs.
>
> Comments?
>
> Alex.

I would love that.

abbie

------_=_NextPart_001_01C3086B.FA6E86FA-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 00:25:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14358 for ; Tue, 22 Apr 2003 00:25:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197pNy-0006Ar-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 00:28:02 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197pNy-0006Ao-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 00:28:02 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M4I4t2071970 for ; Mon, 21 Apr 2003 21:18:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3M4I4YF071969 for ietf-openproxy-bks; Mon, 21 Apr 2003 21:18:04 -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.8p1/8.12.8) with ESMTP id h3M4I2t2071964 for ; Mon, 21 Apr 2003 21:18:03 -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 h3M4I5vj093107; Mon, 21 Apr 2003 22:18:06 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3M4I5hi093106; Mon, 21 Apr 2003 22:18:05 -0600 (MDT) (envelope-from rousskov) Date: Mon, 21 Apr 2003 22:18:05 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: SOAP and OCP In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540582A397@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540582A397@zcard0k6.ca.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: On Mon, 21 Apr 2003, Abbie Barbir wrote: > On Mon, 21 Apr 2003, Alex Rousskov wrote: > > > My understanding is that any existing web service can already > > participate in an OPES system "as is" as long as the OPES > > processor using the service supports SOAP. However, such > > participation is outside of OCP scope because OCP is not SOAP; OCP > > is a stand-alone protocol that has features not described in SOAP > > specs. To support OCP, a web service must be modified. > > True, that is what I mean. > > > In other words, SOAP may be used as an OPES callout protocol (from > > architectural point of view). However, the protocol we are working > > on (OCP), is not identical to SOAP (but can be implemented on top > > of SOAP). Modifications would be required for existing web > > services to support OCP. > > very true > > > Is my understanding correct? If it is, we may have a good > > compromise available: treat both OCP and SOAP as possible callout > > protocols and make sure that OPES framework is not OCP- or > > SOAP-specific. OPES implementations will use the most appropriate > > protocol for their needs. > > I would love that. Great! Given the above agreement, I would suggest that OCP we work on right now is _not_ implemented on top of SOAP because: 1a. SOAP does not deal well with opaque data exchange 1b. efficient opaque data exchange is the primary goal of our OCP 2. SOAP strength (current deployment) can still be used whenever appropriate by OPES processors that support SOAP and either adapt SOAP-friendly data only or do not care about performance on binary data Instead, I would suggest that the WG encourages Abbie to write a "how to use SOAP as an OPES callout protocol" draft, supplying OPES implementors with an explicit OCP alternative. All WG documents (including those documenting tracing and bypass mechanisms) will have to make sure that no specific callout protocol is assumed in a general OPES context. Any objections or further comments? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 09:53:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09305 for ; Tue, 22 Apr 2003 09:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197yF3-0001rO-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 09:55:25 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197yF2-0001rL-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 09:55:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MDdLt2022176 for ; Tue, 22 Apr 2003 06:39:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MDdLIZ022175 for ietf-openproxy-bks; Tue, 22 Apr 2003 06:39:21 -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.8p1/8.12.8) with ESMTP id h3MDdKt2022170 for ; Tue, 22 Apr 2003 06:39:20 -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 h3MDd7g26758; Tue, 22 Apr 2003 09:39:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 09:39:08 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582A58E@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Tue, 22 Apr 2003 09:38:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C308D4.8772DB6A" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C308D4.8772DB6A Content-Type: text/plain see inline abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, April 22, 2003 12:18 AM > To: ietf-openproxy@imc.org > Subject: RE: SOAP and OCP > > SNIP > Great! Given the above agreement, I would suggest that OCP we > work on right now is _not_ implemented on top of SOAP because: > > 1a. SOAP does not deal well with opaque data exchange > 1b. efficient opaque data exchange is the primary goal of our OCP > > 2. SOAP strength (current deployment) can still be used whenever > appropriate by OPES processors that support SOAP and either > adapt SOAP-friendly data only or do not care about performance > on binary data > agree > Instead, I would suggest that the WG encourages Abbie to > write a "how to use SOAP as an OPES callout protocol" draft, > supplying OPES implementors with an explicit OCP alternative. > All WG documents (including those documenting tracing and > bypass mechanisms) will have to make sure that no specific > callout protocol is assumed in a general OPES context. > > Any objections or further comments? > > Thank you, > > Alex. > I am ok with that. I hope that it could become a working item for the WG and I will move on it once OCP/tracing drafts matures. Abbie ------_=_NextPart_001_01C308D4.8772DB6A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: SOAP and OCP

see inline
abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, April 22, 2003 12:18 AM
> To: ietf-openproxy@imc.org
> Subject: RE: SOAP and OCP
>
>

SNIP

> Great! Given the above agreement, I would = suggest that OCP we
> work on right now is _not_ implemented on top = of SOAP because:
>
>   1a. SOAP does not deal well with = opaque data exchange
>   1b. efficient opaque data exchange = is the primary goal of our OCP
>
>   2.  SOAP strength (current = deployment) can still be used whenever
>     appropriate by OPES = processors that support SOAP and either
>     adapt SOAP-friendly = data only or do not care about performance
>     on binary data
>

agree

> Instead, I would suggest that the WG encourages = Abbie to
> write a "how to use SOAP as an OPES = callout protocol" draft,
> supplying OPES implementors with an explicit = OCP alternative.
> All WG documents (including those documenting = tracing and
> bypass mechanisms) will have to make sure that = no specific
> callout protocol is assumed in a general OPES = context.
>
> Any objections or further comments?
>
> Thank you,
>
> Alex.
>

I am ok with that. I hope that it could become a = working item for the WG and I will move on it once OCP/tracing drafts = matures.

Abbie



------_=_NextPart_001_01C308D4.8772DB6A-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 10:28:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11616 for ; Tue, 22 Apr 2003 10:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197ynm-00027q-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 10:31:18 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197ynm-00027n-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 10:31:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MEKRt2023949 for ; Tue, 22 Apr 2003 07:20:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MEKR6O023948 for ietf-openproxy-bks; Tue, 22 Apr 2003 07:20:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MEKRt2023940 for ; Tue, 22 Apr 2003 07:20:27 -0700 (PDT) (envelope-from batuner@attbi.com) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003042214202005100fv1gfe>; Tue, 22 Apr 2003 14:20:21 +0000 From: "Oskar Batuner" To: Subject: RE: SOAP and OCP Date: Tue, 22 Apr 2003 10:20:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Another place for SOAP in OPES is access to all reference and information points. While there is a trend to postpone (preferably indefinitely :) any specs that go beyond the definition of the reference - still without such specs OPES achitsture is incomplete. All references with undefined information structure look more like a "fine print" - one that is not supposed to be read. If we move some programmatically accessible information to references without providing access specs - all implementers are forced to create proprietary access formats and interoperability becomes a problem. Should we look at this now? Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Tuesday, April 22, 2003 12:18 AM > To: ietf-openproxy@imc.org > Subject: RE: SOAP and OCP > > > > > On Mon, 21 Apr 2003, Abbie Barbir wrote: > > > On Mon, 21 Apr 2003, Alex Rousskov wrote: > > > > > My understanding is that any existing web service can already > > > participate in an OPES system "as is" as long as the OPES > > > processor using the service supports SOAP. However, such > > > participation is outside of OCP scope because OCP is not SOAP; OCP > > > is a stand-alone protocol that has features not described in SOAP > > > specs. To support OCP, a web service must be modified. > > > > True, that is what I mean. > > > > > In other words, SOAP may be used as an OPES callout protocol (from > > > architectural point of view). However, the protocol we are working > > > on (OCP), is not identical to SOAP (but can be implemented on top > > > of SOAP). Modifications would be required for existing web > > > services to support OCP. > > > > very true > > > > > Is my understanding correct? If it is, we may have a good > > > compromise available: treat both OCP and SOAP as possible callout > > > protocols and make sure that OPES framework is not OCP- or > > > SOAP-specific. OPES implementations will use the most appropriate > > > protocol for their needs. > > > > I would love that. > > Great! Given the above agreement, I would suggest that OCP we work on > right now is _not_ implemented on top of SOAP because: > > 1a. SOAP does not deal well with opaque data exchange > 1b. efficient opaque data exchange is the primary goal of our OCP > > 2. SOAP strength (current deployment) can still be used whenever > appropriate by OPES processors that support SOAP and either > adapt SOAP-friendly data only or do not care about performance > on binary data > > Instead, I would suggest that the WG encourages Abbie to write a "how > to use SOAP as an OPES callout protocol" draft, supplying OPES > implementors with an explicit OCP alternative. All WG documents > (including those documenting tracing and bypass mechanisms) will have > to make sure that no specific callout protocol is assumed in a general > OPES context. > > Any objections or further comments? > > Thank you, > > Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 11:10:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13093 for ; Tue, 22 Apr 2003 11:10:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197zRW-0002Qv-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 11:12:22 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197zRV-0002Qs-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 11:12:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MExFt2028627 for ; Tue, 22 Apr 2003 07:59:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MExFeB028626 for ietf-openproxy-bks; Tue, 22 Apr 2003 07:59:15 -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.8p1/8.12.8) with ESMTP id h3MExEt2028616 for ; Tue, 22 Apr 2003 07:59:14 -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 h3MEx7f10204; Tue, 22 Apr 2003 10:59:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 10:59:08 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582A710@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Oskar Batuner , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Tue, 22 Apr 2003 10:59:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C308DF.B5F89604" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C308DF.B5F89604 Content-Type: text/plain Oskar, Agreed. Although, I am sure that some will argue otherwise. We can address this now or may be address later with the SOAP draft. ABbie > -----Original Message----- > From: Oskar Batuner [mailto:batuner@attbi.com] > Sent: Tuesday, April 22, 2003 10:20 AM > To: ietf-openproxy@imc.org > Subject: RE: SOAP and OCP > > > > Another place for SOAP in OPES is access to > all reference and information points. > > While there is a trend to postpone (preferably indefinitely > :) any specs that go beyond the definition of the reference - > still without such specs OPES achitsture is incomplete. > All references with undefined information structure look > more like a "fine print" - one that is not supposed to be read. > > If we move some programmatically accessible information to > references without providing access specs - all > implementers are forced to create proprietary access > formats and interoperability becomes a problem. > > Should we look at this now? > > Oskar > > > -----Original Message----- > > From: owner-ietf-openproxy@mail.imc.org > > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > > Sent: Tuesday, April 22, 2003 12:18 AM > > To: ietf-openproxy@imc.org > > Subject: RE: SOAP and OCP > > > > > > > > > > On Mon, 21 Apr 2003, Abbie Barbir wrote: > > > > > On Mon, 21 Apr 2003, Alex Rousskov wrote: > > > > > > > My understanding is that any existing web service can already > > > > participate in an OPES system "as is" as long as the OPES > > > > processor using the service supports SOAP. However, such > > > > participation is outside of OCP scope because OCP is > not SOAP; OCP > > > > is a stand-alone protocol that has features not > described in SOAP > > > > specs. To support OCP, a web service must be modified. > > > > > > True, that is what I mean. > > > > > > > In other words, SOAP may be used as an OPES callout > protocol (from > > > > architectural point of view). However, the protocol we > are working > > > > on (OCP), is not identical to SOAP (but can be > implemented on top > > > > of SOAP). Modifications would be required for existing web > > > > services to support OCP. > > > > > > very true > > > > > > > Is my understanding correct? If it is, we may have a good > > > > compromise available: treat both OCP and SOAP as > possible callout > > > > protocols and make sure that OPES framework is not OCP- or > > > > SOAP-specific. OPES implementations will use the most > appropriate > > > > protocol for their needs. > > > > > > I would love that. > > > > Great! Given the above agreement, I would suggest that OCP > we work on > > right now is _not_ implemented on top of SOAP because: > > > > 1a. SOAP does not deal well with opaque data exchange > > 1b. efficient opaque data exchange is the primary goal of our OCP > > > > 2. SOAP strength (current deployment) can still be used whenever > > appropriate by OPES processors that support SOAP and either > > adapt SOAP-friendly data only or do not care about performance > > on binary data > > > > Instead, I would suggest that the WG encourages Abbie to > write a "how > > to use SOAP as an OPES callout protocol" draft, supplying OPES > > implementors with an explicit OCP alternative. All WG documents > > (including those documenting tracing and bypass mechanisms) > will have > > to make sure that no specific callout protocol is assumed > in a general > > OPES context. > > > > Any objections or further comments? > > > > Thank you, > > > > Alex. > ------_=_NextPart_001_01C308DF.B5F89604 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: SOAP and OCP

Oskar,

Agreed.
Although, I am sure that some will argue = otherwise.
 We can address this now or may be address = later with the SOAP draft.

ABbie


> -----Original Message-----
> From: Oskar Batuner [mailto:batuner@attbi.com]
> Sent: Tuesday, April 22, 2003 10:20 AM
> To: ietf-openproxy@imc.org
> Subject: RE: SOAP and OCP
>
>
>
> Another place for SOAP in OPES is access to =
> all reference and information points.
>
> While there is a trend to postpone (preferably = indefinitely
> :) any specs that go beyond the definition of = the reference -
> still without such specs OPES achitsture is = incomplete.
> All references with undefined information = structure look
> more like a "fine print" - one that = is not supposed to be read.
>
> If we move some programmatically accessible = information to
> references without providing access specs - all =
> implementers are forced to create = proprietary  access
> formats and interoperability becomes a = problem.
>
> Should we look at this now?
>
> Oskar
>
> > -----Original Message-----
> > From: owner-ietf-openproxy@mail.imc.org =
> > [mailto:owner-ietf-open= proxy@mail.imc.org]On Behalf Of Alex Rousskov
> > Sent: Tuesday, April 22, 2003 12:18 = AM
> > To: ietf-openproxy@imc.org
> > Subject: RE: SOAP and OCP
> >
> >
> >
> >
> > On Mon, 21 Apr 2003, Abbie Barbir = wrote:
> >
> > > On Mon, 21 Apr 2003, Alex Rousskov = wrote:
> > >
> > > > My understanding is that any = existing web service can already
> > > > participate in an OPES system = "as is" as long as the OPES
> > > > processor using the service = supports SOAP. However, such
> > > > participation is outside of OCP = scope because OCP is
> not SOAP; OCP
> > > > is a stand-alone protocol that = has features not
> described in SOAP
> > > > specs. To support OCP, a web = service must be modified.
> > >
> > > True, that is what I mean.
> > >
> > > > In other words, SOAP may be used = as an OPES callout
> protocol (from
> > > > architectural point of view). = However, the protocol we
> are working
> > > > on (OCP), is not identical to = SOAP (but can be
> implemented on top
> > > > of SOAP). Modifications would be = required for existing web
> > > > services to support OCP.
> > >
> > > very true
> > >
> > > > Is my understanding correct? If = it is, we may have a good
> > > > compromise available: treat both = OCP and SOAP as
> possible callout
> > > > protocols and make sure that = OPES framework is not OCP- or
> > > > SOAP-specific.  OPES = implementations will use the most
> appropriate
> > > > protocol for their needs.
> > >
> > > I would love that.
> >
> > Great! Given the above agreement, I would = suggest that OCP
> we work on
> > right now is _not_ implemented on top of = SOAP because:
> >
> >   1a. SOAP does not deal well = with opaque data exchange
> >   1b. efficient opaque data = exchange is the primary goal of our OCP
> >
> >   2.  SOAP strength = (current deployment) can still be used whenever
> >     appropriate by = OPES processors that support SOAP and either
> >     adapt = SOAP-friendly data only or do not care about performance
> >     on binary = data
> >
> > Instead, I would suggest that the WG = encourages Abbie to
> write a "how
> > to use SOAP as an OPES callout = protocol" draft, supplying OPES
> > implementors with an explicit OCP = alternative. All WG documents
> > (including those documenting tracing and = bypass mechanisms)
> will have
> > to make sure that no specific callout = protocol is assumed
> in a general
> > OPES context.
> >
> > Any objections or further comments?
> >
> > Thank you,
> >
> > Alex.
>

------_=_NextPart_001_01C308DF.B5F89604-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 11:21:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13506 for ; Tue, 22 Apr 2003 11:21:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197zcN-0002WB-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 11:23:36 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 197zcN-0002W8-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 11:23:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MFBct2029052 for ; Tue, 22 Apr 2003 08:11:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MFBbn7029051 for ietf-openproxy-bks; Tue, 22 Apr 2003 08:11:37 -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.8p1/8.12.8) with ESMTP id h3MFBZt2029046 for ; Tue, 22 Apr 2003 08:11: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 h3MFBavj008882; Tue, 22 Apr 2003 09:11:36 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3MFBa65008881; Tue, 22 Apr 2003 09:11:36 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 09:11:36 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: SOAP and OCP In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540582A58E@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540582A58E@zcard0k6.ca.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: I am trying to find a rational explanation for SOAP inability to handle opaque data efficiently. Is it accurate to say that SOAP (and XML) cannot handle opaque data because their designers assume that every data format in the world will eventually become XML-based? Images will no longer use JPEG but SVG, movies will not use MPEG but SMILE, and so on? Is that the assumption? If it is not the assumption, I do not understand how rational people can develop a protocol for data exchange that does not support binary data natively/well -- you either phase binary data out or you support it from the start. Am I missing something? I am happy that we seem to reach an agreement regarding SOAP and OCP, but I am surprised that SOAP is not good enough, given its definition: SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. Without the "structured" requirement (which has to be interpreted in W3C context or it would make little sense), this is exactly what we need for OCP! When designing OCP, are we, in fact, trying to develop a better SOAP? Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 11:59:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14597 for ; Tue, 22 Apr 2003 11:59:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1980Cv-0002ja-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 12:01:21 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1980Cu-0002jX-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 12:01:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MFpZt2030732 for ; Tue, 22 Apr 2003 08:51:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MFpZao030731 for ietf-openproxy-bks; Tue, 22 Apr 2003 08:51: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 (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MFpYt2030724 for ; Tue, 22 Apr 2003 08:51:34 -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.9/8.12.9) with ESMTP id h3MFpZHa051681 for ; Tue, 22 Apr 2003 11:51:35 -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 h3MFpSc6054281 for ; Tue, 22 Apr 2003 11:51:28 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3MFpSQ4021367 for ; Tue, 22 Apr 2003 11:51:28 -0400 (EDT) Message-ID: <3EA56533.1030406@mhof.com> Date: Tue, 22 Apr 2003 11:52:19 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: SOAP and OCP References: <87609AFB433BD5118D5E0002A52CD754057C80B5@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754057C80B5@zcard0k6.ca.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: Content-Transfer-Encoding: 7bit Abbie Barbir wrote: >> 1. SOAP is not a transport protocol. Would you >> require a specific transport protocol to >> be used if OCP is implemented using SOAP? >> For example, would you require that BEEP/TCP and >> only BEEP/TCP is used under SOAP? > > Yes, but there are bindings defined for SOAP (like HTTP, BEEP ?). > No we will not require specific bindings. We have agreed that this OCP draft > basically define > metadata/state machine for OCP and that bindings will be defined later. IF > we use SOAP, then SOAP can have its own bindings. This way we define > SOAP/OCP and then SOAP over ... can be defined by anyone else. I'm not convinced that this would be an attractive option, since it opens up again the issue of interoperability. I bet we'll see vendors implementing "OCP over SOAP over A" and other vendors implementing "OCP over SOAP over B", thus not being able to interoperate. We already see this happening in the SIP area, where some vendors only implement SIP over TCP, and others only SIP over SCTP - whether this is "allowed" by the standards or not... -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 22 12:10:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14883 for ; Tue, 22 Apr 2003 12:10:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1980Nb-0002o9-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 12:12:23 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1980Na-0002o6-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 12:12:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MG1gt2031133 for ; Tue, 22 Apr 2003 09:01:42 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MG1gxg031132 for ietf-openproxy-bks; Tue, 22 Apr 2003 09:01:42 -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.8p1/8.12.8) with ESMTP id h3MG1et2031126 for ; Tue, 22 Apr 2003 09:01: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 h3MG1dvj010122; Tue, 22 Apr 2003 10:01:39 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3MG1dk5010121; Tue, 22 Apr 2003 10:01:39 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 10:01:39 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: SOAP and OCP In-Reply-To: Message-ID: References: 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: On Tue, 22 Apr 2003, Oskar Batuner wrote: > Another place for SOAP in OPES is access to all reference and > information points. > > While there is a trend to postpone (preferably indefinitely :) any > specs that go beyond the definition of the reference - still without > such specs OPES achitsture is incomplete. All references with > undefined information structure look more like a "fine print" - one > that is not supposed to be read. > > If we move some programmatically accessible information to > references without providing access specs - all implementers are > forced to create proprietary access formats and interoperability > becomes a problem. What do you mean by "providing access specs"? Would providing a protocol name such as "http:" in a URI identifier be sufficient? You are not talking about specifying how the referenced content is to be composed or interpreted, are you? Can you give a couple of specific examples where implementations would access referenced content and auto-interpret it? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 12:22:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15238 for ; Tue, 22 Apr 2003 12:22:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1980Zl-0002th-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 12:24:57 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1980Zk-0002tL-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 12:24:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MGFTt2031685 for ; Tue, 22 Apr 2003 09:15:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MGFTUZ031684 for ietf-openproxy-bks; Tue, 22 Apr 2003 09:15:29 -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.8p1/8.12.8) with ESMTP id h3MGFSt2031679 for ; Tue, 22 Apr 2003 09:15: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 h3MGFTvj010392; Tue, 22 Apr 2003 10:15:29 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3MGFTan010391; Tue, 22 Apr 2003 10:15:29 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 10:15:29 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: SOAP and OCP In-Reply-To: <3EA56533.1030406@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754057C80B5@zcard0k6.ca.nortel.com> <3EA56533.1030406@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: On Tue, 22 Apr 2003, Markus Hofmann wrote: > I'm not convinced that this would be an attractive option, since it > opens up again the issue of interoperability. I bet we'll see > vendors implementing "OCP over SOAP over A" and other vendors > implementing "OCP over SOAP over B", thus not being able to > interoperate. > > We already see this happening in the SIP area, where some vendors > only implement SIP over TCP, and others only SIP over SCTP - whether > this is "allowed" by the standards or not... Whether the above is truly an interoperability problem depends on whether a "TCP vendor" actually wants to interoperate with the "SCTP vendor". I do not know whether OCP really needs multiple transport protocols, but I can imagine a situation where a certain callout server supports only one transport (out of several available) and causes no interoperability problems because it supports the only transport that makes sense for its kind of services. Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 12:55:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16104 for ; Tue, 22 Apr 2003 12:55:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19815M-000354-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 12:57:36 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19815L-000350-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 12:57:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MGkdt2032649 for ; Tue, 22 Apr 2003 09:46:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MGkdGb032648 for ietf-openproxy-bks; Tue, 22 Apr 2003 09:46: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.8p1/8.12.8) with ESMTP id h3MGkct2032639 for ; Tue, 22 Apr 2003 09:46:38 -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 h3MGkVf14905; Tue, 22 Apr 2003 12:46:31 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 12:46:32 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582A8D7@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Tue, 22 Apr 2003 12:46:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C308EE.B802B16E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C308EE.B802B16E Content-Type: text/plain Markus, u have to deal with this option anyway. Once u define generic OCP you will end having OCP over XXX over yyy over zzz etc... Abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, April 22, 2003 11:52 AM > To: ietf-openproxy@imc.org > Subject: Re: SOAP and OCP > > > > Abbie Barbir wrote: > > >> 1. SOAP is not a transport protocol. Would you > >> require a specific transport protocol to > >> be used if OCP is implemented using SOAP? > >> For example, would you require that BEEP/TCP and > >> only BEEP/TCP is used under SOAP? > > > > Yes, but there are bindings defined for SOAP (like HTTP, > BEEP ?). No > > we will not require specific bindings. We have agreed that this OCP > > draft basically define metadata/state machine for OCP and that > > bindings will be defined later. IF we use SOAP, then SOAP > can have its > > own bindings. This way we define SOAP/OCP and then SOAP > over ... can > > be defined by anyone else. > > I'm not convinced that this would be an attractive option, since it > opens up again the issue of interoperability. I bet we'll see vendors > implementing "OCP over SOAP over A" and other vendors implementing > "OCP over SOAP over B", thus not being able to interoperate. > > We already see this happening in the SIP area, where some > vendors only > implement SIP over TCP, and others only SIP over SCTP - whether this > is "allowed" by the standards or not... > > -Markus > > ------_=_NextPart_001_01C308EE.B802B16E Content-Type: text/html RE: SOAP and OCP

Markus,

u have to deal with this option anyway.
Once u define generic OCP you will end having OCP over XXX over yyy over zzz etc...


Abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, April 22, 2003 11:52 AM
> To: ietf-openproxy@imc.org
> Subject: Re: SOAP and OCP
>
>
>
> Abbie Barbir wrote:
>
> >>    1. SOAP is not a transport protocol. Would you
> >>       require a specific transport protocol to
> >>       be used if OCP is implemented using SOAP?
> >>       For example, would you require that BEEP/TCP and
> >>       only BEEP/TCP is used under SOAP?
> >
> > Yes, but there are bindings defined for SOAP (like HTTP,
> BEEP ?). No
> > we will not require specific bindings. We have agreed that this OCP
> > draft basically define metadata/state machine for OCP and that
> > bindings will be defined later. IF we use SOAP, then SOAP
> can have its
> > own bindings. This way we define SOAP/OCP and then SOAP
> over ... can
> > be defined by anyone else.
>
> I'm not convinced that this would be an attractive option, since it
> opens up again the issue of interoperability. I bet we'll see vendors
> implementing "OCP over SOAP over A" and other vendors implementing
> "OCP over SOAP over B", thus not being able to interoperate.
>
> We already see this happening in the SIP area, where some
> vendors only
> implement SIP over TCP, and others only SIP over SCTP - whether this
> is "allowed" by the standards or not...
>
> -Markus
>
>

------_=_NextPart_001_01C308EE.B802B16E-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 13:31:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17339 for ; Tue, 22 Apr 2003 13:31:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981es-0003NJ-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 13:34:18 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1981es-0003NG-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 13:34:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MHIwt2034731 for ; Tue, 22 Apr 2003 10:18:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MHIwY4034730 for ietf-openproxy-bks; Tue, 22 Apr 2003 10:18: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.8p1/8.12.8) with ESMTP id h3MHIut2034723 for ; Tue, 22 Apr 2003 10:18: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 h3MHIwvj011993; Tue, 22 Apr 2003 11:18:58 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3MHIwGc011992; Tue, 22 Apr 2003 11:18:58 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 11:18:58 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: SOAP and OCP In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540582A8D7@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540582A8D7@zcard0k6.ca.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: On Tue, 22 Apr 2003, Abbie Barbir wrote: > u have to deal with this option anyway. Once u define generic OCP > you will end having OCP over XXX over yyy over zzz etc... We could decide on one transport protocol for OCP Core and have no other transport alternatives (this still allows for SOAP to be used as another callout protocol, of course; by "OCP" I mean the protocol we are working on right now, I wish it had a specific name to distinguish it from other callout protocols). Alex. > > -----Original Message----- > > From: Markus Hofmann [mailto:markus@mhof.com] > > Sent: Tuesday, April 22, 2003 11:52 AM > > To: ietf-openproxy@imc.org > > Subject: Re: SOAP and OCP > > > > > > > > Abbie Barbir wrote: > > > > >> 1. SOAP is not a transport protocol. Would you > > >> require a specific transport protocol to > > >> be used if OCP is implemented using SOAP? > > >> For example, would you require that BEEP/TCP and > > >> only BEEP/TCP is used under SOAP? > > > > > > Yes, but there are bindings defined for SOAP (like HTTP, > > BEEP ?). No > > > we will not require specific bindings. We have agreed that this OCP > > > draft basically define metadata/state machine for OCP and that > > > bindings will be defined later. IF we use SOAP, then SOAP > > can have its > > > own bindings. This way we define SOAP/OCP and then SOAP > > over ... can > > > be defined by anyone else. > > > > I'm not convinced that this would be an attractive option, since it > > opens up again the issue of interoperability. I bet we'll see vendors > > implementing "OCP over SOAP over A" and other vendors implementing > > "OCP over SOAP over B", thus not being able to interoperate. > > > > We already see this happening in the SIP area, where some > > vendors only > > implement SIP over TCP, and others only SIP over SCTP - whether this > > is "allowed" by the standards or not... > > > > -Markus > > > > > From owner-ietf-openproxy@mail.imc.org Tue Apr 22 13:35:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17435 for ; Tue, 22 Apr 2003 13:35:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981iZ-0003OV-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 13:38:07 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1981iZ-0003OS-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 13:38:07 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MHSdt2034966 for ; Tue, 22 Apr 2003 10:28:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MHSdLj034965 for ietf-openproxy-bks; Tue, 22 Apr 2003 10:28: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 (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MHSbt2034958 for ; Tue, 22 Apr 2003 10:28:38 -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.9/8.12.9) with ESMTP id h3MHSdHa052597 for ; Tue, 22 Apr 2003 13:28:39 -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 h3MHSWc6063757 for ; Tue, 22 Apr 2003 13:28:33 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3MHSWQ4024760 for ; Tue, 22 Apr 2003 13:28:32 -0400 (EDT) Message-ID: <3EA57BF4.8060001@mhof.com> Date: Tue, 22 Apr 2003 13:29:24 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: SOAP and OCP References: <87609AFB433BD5118D5E0002A52CD7540582A8D7@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540582A8D7@zcard0k6.ca.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: Content-Transfer-Encoding: 7bit Abbie Barbir wrote: > u have to deal with this option anyway. > Once u define generic OCP you will end having OCP over XXX over yyy over zzz > etc... No, not if we only define *one* "OCP over XXX", i.e. only one transport protocol binding. Sure, it *might* turn out that there's be a need to have multiple transport bindings, in which case this option should be discussed. But I've not yet seen a convincing, *specific and practial relevant* case that would required multiple such bindings. We can probably come back to this question once we've decided on a (first) OCP transport binding, and then we can really answer whether this is sufficient. I just want to caution that we should *not* assume to have multliple OCP transport bindings per default. I'd rather suggest we try to have a single such binding, and only if it turns out to be absolutely necessary, we might consider others. -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 22 13:45:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17931 for ; Tue, 22 Apr 2003 13:45:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981rt-0003Wh-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 13:47:45 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1981rs-0003We-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 13:47:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MHbIt2035599 for ; Tue, 22 Apr 2003 10:37:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MHbIIi035597 for ietf-openproxy-bks; Tue, 22 Apr 2003 10:37:18 -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.8p1/8.12.8) with ESMTP id h3MHbGt2035589 for ; Tue, 22 Apr 2003 10:37:16 -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.9/8.12.9) with ESMTP id h3MHbH9Y003535 for ; Tue, 22 Apr 2003 13:37: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 h3MHbBc6064489 for ; Tue, 22 Apr 2003 13:37:11 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3MHbAQ4025005 for ; Tue, 22 Apr 2003 13:37:10 -0400 (EDT) Message-ID: <3EA57DF9.5060803@mhof.com> Date: Tue, 22 Apr 2003 13:38:01 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: SOAP and OCP References: <87609AFB433BD5118D5E0002A52CD754057C80B5@zcard0k6.ca.nortel.com> <3EA56533.1030406@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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Whether the above is truly an interoperability problem depends on > whether a "TCP vendor" actually wants to interoperate with the "SCTP > vendor". I do not know whether OCP really needs multiple transport > protocols, but I can imagine a situation where a certain callout > server supports only one transport (out of several available) and > causes no interoperability problems because it supports the only > transport that makes sense for its kind of services. I agree in theory, but fact is that this complicates interworking in real life. Some services won't clearly dicted a specific transport, i.e. some services can potentially be run on top of different transports. If you now have vendors with different preferences, only supporting their prefered transport (for whatever reason), these vendors simply won't be able to interwork with each other - that's an interoprtability problem. I agree - I also don't yet know whether OCP needs multiple transport protocols. But this should *not* make us conlcude that there definitely will be multiple such bindings and design the system/protocol accordingly. Maybe on transport binding is sufficient, and we would end up with a clearer picture? -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 22 15:20:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22504 for ; Tue, 22 Apr 2003 15:20:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1983MI-0004Mf-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 15:23:14 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1983MH-0004Mc-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 15:23:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MJ8ut2039678 for ; Tue, 22 Apr 2003 12:08:56 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MJ8un2039677 for ietf-openproxy-bks; Tue, 22 Apr 2003 12:08:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MJ8tt2039672 for ; Tue, 22 Apr 2003 12:08:55 -0700 (PDT) (envelope-from info@utel.net) Received: from f11v-7-89.d1.club-internet.fr ([213.44.166.89] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 1982zU-0000C6-00; Tue, 22 Apr 2003 11:59:40 -0700 Message-Id: <5.2.0.9.0.20030422210019.0339bd60@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 22 Apr 2003 21:07:46 +0200 To: "Abbie Barbir" , Markus Hofmann , ietf-openproxy@imc.org From: jfcm Subject: RE: SOAP and OCP In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540582A8D7@zcard0k6.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_29603501==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=====================_29603501==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed If other protocols than http are supported my "filter" is "can the DNS be supported". The application being the missing IDNA solution for Internationalized TLDs. I am sure that SOAP is quite heavy/slow to support that. The architecture yet is simple: The OPES processor receives a querry with an unkown TLD. It OCP it to a DNS.2 server which responds both the meaning of the TLD and the IP addresses of its zone server for the calling OPES Processor. The Path leaves the calling party to decide to use the proposed IP address (lcoal TLD) or not. jfc At 18:46 22/04/03, Abbie Barbir wrote: >Markus, > >u have to deal with this option anyway. >Once u define generic OCP you will end having OCP over XXX over yyy over >zzz etc... > >Abbie > > > -----Original Message----- > > From: Markus Hofmann [mailto:markus@mhof.com] > > Sent: Tuesday, April 22, 2003 11:52 AM > > To: ietf-openproxy@imc.org > > Subject: Re: SOAP and OCP > > > > > > > > Abbie Barbir wrote: > > > > >> 1. SOAP is not a transport protocol. Would you > > >> require a specific transport protocol to > > >> be used if OCP is implemented using SOAP? > > >> For example, would you require that BEEP/TCP and > > >> only BEEP/TCP is used under SOAP? > > > > > > Yes, but there are bindings defined for SOAP (like HTTP, > > BEEP ?). No > > > we will not require specific bindings. We have agreed that this OCP > > > draft basically define metadata/state machine for OCP and that > > > bindings will be defined later. IF we use SOAP, then SOAP > > can have its > > > own bindings. This way we define SOAP/OCP and then SOAP > > over ... can > > > be defined by anyone else. > > > > I'm not convinced that this would be an attractive option, since it > > opens up again the issue of interoperability. I bet we'll see vendors > > implementing "OCP over SOAP over A" and other vendors implementing > > "OCP over SOAP over B", thus not being able to interoperate. > > > > We already see this happening in the SIP area, where some > > vendors only > > implement SIP over TCP, and others only SIP over SCTP - whether this > > is "allowed" by the standards or not... > > > > -Markus > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03 --=====================_29603501==.ALT Content-Type: text/html; charset="us-ascii" If other protocols than http are supported my "filter" is "can the DNS be supported". The application being the missing IDNA solution for Internationalized TLDs.

I am sure that SOAP is quite heavy/slow to support that. The architecture yet is simple: The OPES processor receives a querry with an unkown TLD. It OCP it to a DNS.2 server which responds both the meaning of the TLD and the IP addresses of its zone server for the calling OPES Processor. The Path leaves the calling party to decide to use the proposed IP address (lcoal TLD) or not.
jfc

At 18:46 22/04/03, Abbie Barbir wrote:

Markus,

u have to deal with this option anyway.
Once u define generic OCP you will end having OCP over XXX over yyy over zzz etc...

Abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, April 22, 2003 11:52 AM
> To: ietf-openproxy@imc.org
> Subject: Re: SOAP and OCP
>
>
>
> Abbie Barbir wrote:
>
> >>    1. SOAP is not a transport protocol. Would you
> >>       require a specific transport protocol to
> >>       be used if OCP is implemented using SOAP?
> >>       For example, would you require that BEEP/TCP and
> >>       only BEEP/TCP is used under SOAP?
> >
> > Yes, but there are bindings defined for SOAP (like HTTP,
> BEEP ?). No
> > we will not require specific bindings. We have agreed that this OCP
> > draft basically define metadata/state machine for OCP and that
> > bindings will be defined later. IF we use SOAP, then SOAP
> can have its
> > own bindings. This way we define SOAP/OCP and then SOAP
> over ... can
> > be defined by anyone else.
>
> I'm not convinced that this would be an attractive option, since it
> opens up again the issue of interoperability. I bet we'll see vendors
> implementing "OCP over SOAP over A" and other vendors implementing
> "OCP over SOAP over B", thus not being able to interoperate.
>
> We already see this happening in the SIP area, where some
> vendors only
> implement SIP over TCP, and others only SIP over SCTP - whether this
> is "allowed" by the standards or not...
>
> -Markus
>
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03
--=====================_29603501==.ALT-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 16:13:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24219 for ; Tue, 22 Apr 2003 16:13:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1984BO-0004pr-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 16:16:02 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1984BN-0004pn-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 16:16:01 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MK3lt2043769 for ; Tue, 22 Apr 2003 13:03:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MK3lLF043768 for ietf-openproxy-bks; Tue, 22 Apr 2003 13:03: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.8p1/8.12.8) with ESMTP id h3MK3kt2043762 for ; Tue, 22 Apr 2003 13:03: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 h3MK3lvj017082; Tue, 22 Apr 2003 14:03:47 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3MK3lNu017081; Tue, 22 Apr 2003 14:03:47 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 14:03:47 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Adapting DNS In-Reply-To: <5.2.0.9.0.20030422210019.0339bd60@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030422210019.0339bd60@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: -- subject was "OCP and OPES" On Tue, 22 Apr 2003, jfcm wrote: > If other protocols than http are supported my "filter" is "can the > DNS be supported". The application being the missing IDNA solution > for Internationalized TLDs. I see no architectural reason to exclude DNS from the set of adaptable protocols a priory. However, I have to note that DNS is different from, say, SMTP (not to mention HTTP) because it is not really "store and forward" or "proxy" protocol. AFAIK, there is no real "final destination" in a typical DNS query; a DNS server may be configured to send authoritative responses (it becomes the final destination then) or may forward the query elsewhere (it becomes a DNS "hop" then, essentially). Thus, a DNS server doing OPES transformations may not be a real "intermediary" as prescribed by OPES architecture. The distinction should not cause any significant problems though, IMO. Some OPES features such as tracing would not be fully available for DNS/UDP exchanges due to packet size limitations, I guess. Zone exchanges over TCP should not suffer from these limitations. The two DNS applications (query resolution and zone transfer) have to be considered separately because they are, essentially, separate protocols. > I am sure that SOAP is quite heavy/slow to support that. Probably, at least in a typical SOAP environment. > The architecture yet is simple: The OPES processor receives a querry > with an unkown TLD. It OCP it to a DNS.2 server which responds both > the meaning of the TLD and the IP addresses of its zone server for > the calling OPES Processor. The Path leaves the calling party to > decide to use the proposed IP address (lcoal TLD) or not. If a query destination (DNS.2 server) generates a response, then this is not an adaptation/OPES, IMO. I would adjust the above description to better fit current OPES architecture: - DNS server D receives a query for iTLD - D, acting as an OPES processor, adapts the query so that the internationalized domain is encoded to avoid compatibility problems with other (old) DNS servers; this step may use OCP and callout servers - D forwards adapted query to another DNS server (possibly self) - D receives a reply - D, acting as an OPES processor, adapts the reply to match internationalized encoding rules; this step may use OCP and callout servers - D forwards adapted (iTLD) reply to the calling party Notice how essentially the same processing is now described from the OPES point of view, properly isolating OCP and making it optional. Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 17:31:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27608 for ; Tue, 22 Apr 2003 17:31:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1985Oi-0005dw-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 17:33:53 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1985Oi-0005ds-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 17:33:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MLM4t2046478 for ; Tue, 22 Apr 2003 14:22:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MLM4Jg046477 for ietf-openproxy-bks; Tue, 22 Apr 2003 14:22:04 -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.8p1/8.12.8) with ESMTP id h3MLM2t2046472 for ; Tue, 22 Apr 2003 14:22:03 -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 h3MLM5vj019024; Tue, 22 Apr 2003 15:22:05 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3MLM41q019023; Tue, 22 Apr 2003 15:22:04 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 15:22:04 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org cc: Martin Stecher Subject: HTTP as OCP transport, ICAP/2.0 Message-ID: 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: Here are the reasons to use HTTP as OCP transport: + ICAP uses HTTP as transport; we can make OCP look like ICAP/2.0, which may significantly improve OCP survival/adoption chances + HTTP applications are our primary target; it would be easier to add OCP support to HTTP intermediaries (OPES processors) if OCP transport is also HTTP + it is likely that many existing web services already support HTTP (e.g., as a part of SOAP over HTTP); it would be easier to add OCP support to such services (OPES callout servers) if OCP transport is also HTTP + HTTP is fairly well-understood protocol as far as basic transport functionality is concerned Here are the reasons to avoid HTTP as OCP transport: - HTTP makes it difficult to support a pipeline of OCP messages without converting every message into a request/response pair; this limits OCP flexibility and/or performance - ICAP uses HTTP as transport; if we try to make OCP to look like ICAP/2.0, we may have to sacrifice some (many?) OCP properties and clean design to retain some form of backward compatibility; for example, OCP metadata should be distinct from HTTP metadata, which may be difficult to achieve while preserving compatibility with ICAP/1.1. - HTTP lacks appropriate connection management primitives because persistent connections were added on top of an existing protocol (HTTP/1.0) and are just a performance optimization; HTTP is not really design for long-lived connections many OCP agents would enjoy - HTTP lacks appropriate native support for security and authentication; compared to SOAP and BEEP, little reuse of other protocols/mechanisms is possible in this context - HTTP specification (RFC 2616) is a big, complicated document; HTTP comes with many features that OCP probably does not need Did I miss anything important? ICAP/OPES issues are also discussed, in part, in the draft-stecher-opes-icap-eval-00 document: http://www.faqs.org/ftp/internet-drafts/draft-stecher-opes-icap-eval-00.txt IMO, the primary reason to use HTTP as OCP transport would be "compatibility" with ICAP. I wonder if ICAP proponents would consider it possible for ICAP/2.0 or ICAP-NG to use something other than HTTP as transport? Or will selection of other transports kill the opportunity to merge ICAP/2.0 and OCP? What do you think? I am especially interested in comments from Martin Stecher and anybody else with first-hand ICAP experience. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 19:19:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01195 for ; Tue, 22 Apr 2003 19:19:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19874r-0006H6-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 19:21:29 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19874k-0006H1-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 19:21:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MN9Nt2049531 for ; Tue, 22 Apr 2003 16:09:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MN9Nec049530 for ietf-openproxy-bks; Tue, 22 Apr 2003 16:09:23 -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.8p1/8.12.8) with ESMTP id h3MN9Lt2049524 for ; Tue, 22 Apr 2003 16:09:22 -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.9/8.12.9) with ESMTP id h3MN9NHa056117 for ; Tue, 22 Apr 2003 19:09:23 -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 h3MN9Hc6096121 for ; Tue, 22 Apr 2003 19:09:17 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3MN9GQ4008418 for ; Tue, 22 Apr 2003 19:09:17 -0400 (EDT) Message-ID: <3EA5CBD0.8020903@mhof.com> Date: Tue, 22 Apr 2003 19:10:08 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: SOAP and OCP References: <87609AFB433BD5118D5E0002A52CD7540582A397@zcard0k6.ca.nortel.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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Instead, I would suggest that the WG encourages Abbie to write a "how > to use SOAP as an OPES callout protocol" draft, supplying OPES > implementors with an explicit OCP alternative. All WG documents > (including those documenting tracing and bypass mechanisms) will have > to make sure that no specific callout protocol is assumed in a general > OPES context. > > Any objections or further comments? Having a document discussing the usage of SOAP as the OPES callout protocol is fine (indeed, I believe there was a now expired, individual ID about this a while ago). However, I'd like to hit the brake on going down the path of specifying multiple OPES callout protocols. Let's focus on getting "an" OCP - with the appropriate transport binding(s) and application binding(s) - done. We're chartered to specify a callout protocol, and not a suite of possible callout protocols. There might be multiple alternatives, and we'll have to decide which is the best one. If there's a real need for having multiple callout protocols, let's have a discussion and see whether there's WG consensus to do so. Otherwise, I'd suggest we focus on getting a single callout protocol done right, and base the companion documents around this protocol. Leaving too many options seems like a simple way to overcome controversy and to make everybody happy, but it might not always be the best choice in technical design. -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 22 19:25:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01327 for ; Tue, 22 Apr 2003 19:25:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1987BK-0006J1-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 19:28:11 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1987BK-0006Iy-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 19:28:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MNI0t2049850 for ; Tue, 22 Apr 2003 16:18:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MNI0hx049849 for ietf-openproxy-bks; Tue, 22 Apr 2003 16:18:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MNHxt2049843 for ; Tue, 22 Apr 2003 16:17:59 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3MNNs9o001368; Tue, 22 Apr 2003 17:23:54 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3MNGd220916; Tue, 22 Apr 2003 17:16:39 -0600 Date: Tue, 22 Apr 2003 17:16:39 -0600 Message-Id: <200304222316.h3MNGd220916@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org, martin.stecher@webwasher.com In-reply-to: Yourmessage Subject: Re: HTTP as OCP transport, ICAP/2.0 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I thought BEEP's security was the same as HTTP's: use TLS. Hilarie From owner-ietf-openproxy@mail.imc.org Tue Apr 22 19:42:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01561 for ; Tue, 22 Apr 2003 19:42:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1987Rb-0006Lu-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 19:44:59 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1987Ra-0006Lr-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 19:44:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MNYnt2050287 for ; Tue, 22 Apr 2003 16:34:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MNYn1B050286 for ietf-openproxy-bks; Tue, 22 Apr 2003 16:34: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.8p1/8.12.8) with ESMTP id h3MNYlt2050280 for ; Tue, 22 Apr 2003 16:34: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 h3MNYivj022207; Tue, 22 Apr 2003 17:34:44 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3MNYigq022206; Tue, 22 Apr 2003 17:34:44 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 17:34:44 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: HTTP as OCP transport, ICAP/2.0 In-Reply-To: <200304222316.h3MNGd220916@localhost.localdomain> Message-ID: References: <200304222316.h3MNGd220916@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: On Tue, 22 Apr 2003, The Purple Streak, Hilarie Orman wrote: > I thought BEEP's security was the same as HTTP's: use TLS. My understanding is that BEEP can _negotiate_ security profile for a BEEP session (so that we do not have to worry about that at all). Please correct me if I am wrong. I know that HTTP has no idea it is being (or can be) wrapped with TLS. Thus, we, as OCP writers, would have to worry about negotiating and then enabling TLS. Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 19:57:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02029 for ; Tue, 22 Apr 2003 19:57:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1987fg-0006TP-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 19:59:32 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1987fg-0006TM-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 19:59:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MNpNt2050694 for ; Tue, 22 Apr 2003 16:51:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MNpMbv050693 for ietf-openproxy-bks; Tue, 22 Apr 2003 16:51: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.8p1/8.12.8) with ESMTP id h3MNpLt2050688 for ; Tue, 22 Apr 2003 16:51: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 h3MNpKvj022670; Tue, 22 Apr 2003 17:51:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3MNpKj8022669; Tue, 22 Apr 2003 17:51:20 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 17:51:20 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: SOAP and OCP In-Reply-To: <3EA5CBD0.8020903@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540582A397@zcard0k6.ca.nortel.com> <3EA5CBD0.8020903@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: On Tue, 22 Apr 2003, Markus Hofmann wrote: > If there's a real need for having multiple callout protocols, let's > have a discussion and see whether there's WG consensus to do so. > Otherwise, I'd suggest we focus on getting a single callout protocol > done right, and base the companion documents around this protocol. > > Leaving too many options seems like a simple way to overcome > controversy and to make everybody happy, but it might not always be > the best choice in technical design. I agree; you may have misinterpreted what we are after: OPES architecture already assumes that adaptation can be done by means other than OCP. Thus, we are not increasing complexity or adding anything really new. We are simply making a statement that OPES framework (tracing, bypass, and such) should not depend on OCP because OCP is not the only allowed way to do adaptation! The fact that SOAP may be used as a callout protocol is just a side-effect of the above statement. We will not focus on SOAP. We will focus on "our" OCP. "How to use SOAP as an OPES callout protocol" draft may (should??) end up having a single normative sentence: use "as is" Does this approach work for you? Alex. From owner-ietf-openproxy@mail.imc.org Tue Apr 22 20:55:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02876 for ; Tue, 22 Apr 2003 20:55:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1988aQ-0006h3-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 20:58:10 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1988aP-0006h0-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 20:58:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N0m8t2056641 for ; Tue, 22 Apr 2003 17:48:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N0m8AH056640 for ietf-openproxy-bks; Tue, 22 Apr 2003 17:48:08 -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.8p1/8.12.8) with ESMTP id h3N0m6t2056630 for ; Tue, 22 Apr 2003 17:48:07 -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 h3N0lug26085; Tue, 22 Apr 2003 20:47:57 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 20:47:57 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582AD6A@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: HTTP as OCP transport, ICAP/2.0 Date: Tue, 22 Apr 2003 20:47:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30931.FAD9B026" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30931.FAD9B026 Content-Type: text/plain Hilarie, Based on my understanding. This is correct. Marshall, can we have your 2 cents. Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, April 22, 2003 7:35 PM > To: ietf-openproxy@imc.org > Subject: Re: HTTP as OCP transport, ICAP/2.0 > > > > > On Tue, 22 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > > I thought BEEP's security was the same as HTTP's: use TLS. > > My understanding is that BEEP can _negotiate_ security > profile for a BEEP session (so that we do not have to worry > about that at all). Please correct me if I am wrong. > > I know that HTTP has no idea it is being (or can be) wrapped > with TLS. Thus, we, as OCP writers, would have to worry about > negotiating and then enabling TLS. > > Alex. > > ------_=_NextPart_001_01C30931.FAD9B026 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: HTTP as OCP transport, ICAP/2.0

Hilarie,
Based on my understanding. This is correct.

Marshall, can we have your 2 cents.

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, April 22, 2003 7:35 PM
> To: ietf-openproxy@imc.org
> Subject: Re: HTTP as OCP transport, = ICAP/2.0
>
>
>
>
> On Tue, 22 Apr 2003, The Purple Streak, Hilarie = Orman wrote:
>
> > I thought BEEP's security was the same as = HTTP's: use TLS.
>
> My understanding is that BEEP can _negotiate_ = security
> profile for a BEEP session (so that we do not = have to worry
> about that at all). Please correct me if I am = wrong.
>
> I know that HTTP has no idea it is being (or = can be) wrapped
> with TLS. Thus, we, as OCP writers, would have = to worry about
> negotiating and then enabling TLS.
>
> Alex.
>
>

------_=_NextPart_001_01C30931.FAD9B026-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 20:55:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02891 for ; Tue, 22 Apr 2003 20:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1988aU-0006hA-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 20:58:14 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1988aU-0006h7-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 20:58:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N0mkt2056673 for ; Tue, 22 Apr 2003 17:48:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N0mkBU056672 for ietf-openproxy-bks; Tue, 22 Apr 2003 17:48:46 -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.8p1/8.12.8) with ESMTP id h3N0mjt2056664 for ; Tue, 22 Apr 2003 17:48:45 -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 h3N0mZf02094; Tue, 22 Apr 2003 20:48:36 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 20:48:36 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582AD6B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Tue, 22 Apr 2003 20:48:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30932.1245EA54" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30932.1245EA54 Content-Type: text/plain Alex, Agree Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, April 22, 2003 7:51 PM > To: ietf-openproxy@imc.org > Subject: Re: SOAP and OCP > > > > On Tue, 22 Apr 2003, Markus Hofmann wrote: > > > If there's a real need for having multiple callout protocols, let's > > have a discussion and see whether there's WG consensus to do so. > > Otherwise, I'd suggest we focus on getting a single callout > protocol > > done right, and base the companion documents around this protocol. > > > > Leaving too many options seems like a simple way to overcome > > controversy and to make everybody happy, but it might not always be > > the best choice in technical design. > > I agree; you may have misinterpreted what we are after: > > OPES architecture already assumes that adaptation can be done > by means other than OCP. Thus, we are not increasing > complexity or adding anything really new. We are simply > making a statement that OPES framework (tracing, bypass, and > such) should not depend on OCP because OCP is not the only > allowed way to do adaptation! > > The fact that SOAP may be used as a callout protocol is just > a side-effect of the above statement. We will not focus on > SOAP. We will focus on "our" OCP. "How to use SOAP as an OPES > callout protocol" draft may (should??) end up having a single > normative sentence: > use "as is" > > Does this approach work for you? > > Alex. > ------_=_NextPart_001_01C30932.1245EA54 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: SOAP and OCP

Alex,

Agree

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, April 22, 2003 7:51 PM
> To: ietf-openproxy@imc.org
> Subject: Re: SOAP and OCP
>
>
>
> On Tue, 22 Apr 2003, Markus Hofmann = wrote:
>
> > If there's a real need for having multiple = callout protocols, let's
> > have a discussion and see whether there's = WG consensus to do so.
> > Otherwise, I'd suggest we focus on getting = a single callout
> protocol
> > done right, and base the companion = documents around this protocol.
> >
> > Leaving too many options seems like a = simple way to overcome
> > controversy and to make everybody happy, = but it might not always be
> > the best choice in technical = design.
>
> I agree; you may have misinterpreted what we = are after:
>
> OPES architecture already assumes that = adaptation can be done
> by means other than OCP. Thus, we are not = increasing
> complexity or adding anything really new. We = are simply
> making a statement that OPES framework = (tracing, bypass, and
> such) should not depend on OCP because OCP is = not the only
> allowed way to do adaptation!
>
> The fact that SOAP may be used as a callout = protocol is just
> a side-effect of the above statement. We will = not focus on
> SOAP. We will focus on "our" OCP. = "How to use SOAP as an OPES
> callout protocol" draft may (should??) end = up having a single
> normative sentence:
>       use "as = is"
>
> Does this approach work for you?
>
> Alex.
>

------_=_NextPart_001_01C30932.1245EA54-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 20:55:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02906 for ; Tue, 22 Apr 2003 20:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1988aV-0006hG-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 20:58:15 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1988aV-0006hB-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 20:58:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N0l1t2056603 for ; Tue, 22 Apr 2003 17:47:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N0l13K056602 for ietf-openproxy-bks; Tue, 22 Apr 2003 17:47:01 -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.8p1/8.12.8) with ESMTP id h3N0l0t2056544 for ; Tue, 22 Apr 2003 17:47:00 -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 h3N0krf00663; Tue, 22 Apr 2003 20:46:54 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 20:46:54 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582AD69@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Tue, 22 Apr 2003 20:46:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30931.D4B8D4DA" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30931.D4B8D4DA Content-Type: text/plain Markus, The plan for now is to go ahead and get a transport for OCP that best fits. SOAP addresses some issues and is good in some situations. We will readdress later. Abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, April 22, 2003 7:10 PM > To: ietf-openproxy@imc.org > Subject: Re: SOAP and OCP > > > > Alex Rousskov wrote: > > > Instead, I would suggest that the WG encourages Abbie to > write a "how > > to use SOAP as an OPES callout protocol" draft, supplying OPES > > implementors with an explicit OCP alternative. All WG documents > > (including those documenting tracing and bypass mechanisms) > will have > > to make sure that no specific callout protocol is assumed > in a general > > OPES context. > > > > Any objections or further comments? > > Having a document discussing the usage of SOAP as the OPES callout > protocol is fine (indeed, I believe there was a now expired, > individual ID about this a while ago). However, I'd like to hit the > brake on going down the path of specifying multiple OPES callout > protocols. > > Let's focus on getting "an" OCP - with the appropriate transport > binding(s) and application binding(s) - done. We're chartered to > specify a callout protocol, and not a suite of possible callout > protocols. There might be multiple alternatives, and we'll have to > decide which is the best one. > > If there's a real need for having multiple callout protocols, let's > have a discussion and see whether there's WG consensus to do so. > Otherwise, I'd suggest we focus on getting a single callout protocol > done right, and base the companion documents around this protocol. > > Leaving too many options seems like a simple way to overcome > controversy and to make everybody happy, but it might not always be > the best choice in technical design. > > -Markus > > ------_=_NextPart_001_01C30931.D4B8D4DA Content-Type: text/html RE: SOAP and OCP

Markus,

The plan for now is to go ahead and get a transport for OCP that best fits.
SOAP addresses some issues and is good in some situations.
We will readdress later.

Abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, April 22, 2003 7:10 PM
> To: ietf-openproxy@imc.org
> Subject: Re: SOAP and OCP
>
>
>
> Alex Rousskov wrote:
>
> > Instead, I would suggest that the WG encourages Abbie to
> write a "how
> > to use SOAP as an OPES callout protocol" draft, supplying OPES
> > implementors with an explicit OCP alternative. All WG documents
> > (including those documenting tracing and bypass mechanisms)
> will have
> > to make sure that no specific callout protocol is assumed
> in a general
> > OPES context.
> >
> > Any objections or further comments?
>
> Having a document discussing the usage of SOAP as the OPES callout
> protocol is fine (indeed, I believe there was a now expired,
> individual ID about this a while ago). However, I'd like to hit the
> brake on going down the path of specifying multiple OPES callout
> protocols.
>
> Let's focus on getting "an" OCP - with the appropriate transport
> binding(s) and application binding(s) - done. We're chartered to
> specify a callout protocol, and not a suite of possible callout
> protocols. There might be multiple alternatives, and we'll have to
> decide which is the best one.
>
> If there's a real need for having multiple callout protocols, let's
> have a discussion and see whether there's WG consensus to do so.
> Otherwise, I'd suggest we focus on getting a single callout protocol
> done right, and base the companion documents around this protocol.
>
> Leaving too many options seems like a simple way to overcome
> controversy and to make everybody happy, but it might not always be
> the best choice in technical design.
>
> -Markus
>
>

------_=_NextPart_001_01C30931.D4B8D4DA-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 21:23:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03392 for ; Tue, 22 Apr 2003 21:23:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19891I-0006nw-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 21:25:56 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19891H-0006nt-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 21:25:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N1Ett2057475 for ; Tue, 22 Apr 2003 18:14:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N1EtZj057474 for ietf-openproxy-bks; Tue, 22 Apr 2003 18:14:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N1Ert2057464 for ; Tue, 22 Apr 2003 18:14:53 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HDR006X8UZSOL@mtaout01.icomcast.net> for ietf-openproxy@imc.org; Tue, 22 Apr 2003 21:04:41 -0400 (EDT) Date: Tue, 22 Apr 2003 21:04:40 -0400 From: Markus Hofmann Subject: Re: SOAP and OCP In-reply-to: To: ietf-openproxy@imc.org Message-id: <3EA5E6A8.2000007@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <87609AFB433BD5118D5E0002A52CD7540582A397@zcard0k6.ca.nortel.com> <3EA5CBD0.8020903@mhof.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Alex Rousskov wrote: > OPES architecture already assumes that adaptation can be done by means > other than OCP. Only if this "other than OCP" fully complies with the requirements outlined in the WG documents (which might be obvious if "other than OCP" is a local procedure call on the OPES processor). If this "othern than OCP" would have to be modified/extended in oder to meet the requirements, or if the usage of "other than OCP" would imply additional complexity on the OPES framework, the WG shouldn't spend cycles on it. I believe we're basically in agreement here. > Thus, we are not increasing complexity or adding > anything really new. We are simply making a statement that OPES > framework (tracing, bypass, and such) should not depend on OCP because > OCP is not the only allowed way to do adaptation! See above. > The fact that SOAP may be used as a callout protocol is just a > side-effect of the above statement. We will not focus on SOAP. We will > focus on "our" OCP. "How to use SOAP as an OPES callout protocol" > draft may (should??) end up having a single normative sentence: > use "as is" > > Does this approach work for you? I hope the above provides an answer to that. If the WG decides that SOAP (or some modification of SOAP) should be the OCP, the WG will work on it. If the WG decides that something different than SOAP should become the OCP, the *WG* should not spend any cycles on SOAP (this includes possible modifications/extensions to SOAP, as well as requirements that might be imposed by SOAP on the OPES framework). Of course, this is *not* meant to prevent individual contributors to look at it, the WG just won't take this on as work item, and it should not distract the WG. And, obviously, if SOAP can be used without any modifications/extensions and without having any additional requirements on the OPES framework - hey, there's nothing to do and we also don't have a problem. If I understood you correctly, that's very much what you said. -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 22 21:43:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03800 for ; Tue, 22 Apr 2003 21:43:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1989Ko-0006t3-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 21:46:06 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1989Ko-0006t0-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 21:46:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N1YLt2059679 for ; Tue, 22 Apr 2003 18:34:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N1YLpv059678 for ietf-openproxy-bks; Tue, 22 Apr 2003 18:34:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.110]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N1YJt2059672 for ; Tue, 22 Apr 2003 18:34:20 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout10.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HDR00GGMVG2F5@mtaout10.icomcast.net> for ietf-openproxy@imc.org; Tue, 22 Apr 2003 21:14:27 -0400 (EDT) Date: Tue, 22 Apr 2003 21:14:26 -0400 From: Markus Hofmann Subject: Re: SOAP and OCP In-reply-to: <87609AFB433BD5118D5E0002A52CD7540582AD69@zcard0k6.ca.nortel.com> To: ietf-openproxy@imc.org Message-id: <3EA5E8F2.1080305@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: <87609AFB433BD5118D5E0002A52CD7540582AD69@zcard0k6.ca.nortel.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Abbie Barbir wrote: > The plan for now is to go ahead and get a transport for OCP that best fits. Absolutely, that's the goal! > SOAP addresses some issues and is good in some situations. > We will readdress later. Discussing the pros and cons of using SOAP (or other protocols) as the OCP transport is perfectly fine (and we already had some good discussions around that topic). The goal of these discussions is to decide on THE OCP transport - the result should be unambiguous, if possible. The WG will then move forward with the selected OCP transport and won't spend cycles on other alternatives. If this sounds OK, we're in agreement. -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 22 22:40:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04715 for ; Tue, 22 Apr 2003 22:40:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198ADd-00079k-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 22:42:45 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198ADd-00079h-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 22:42:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N2Vst2060982 for ; Tue, 22 Apr 2003 19:31:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N2VsBf060981 for ietf-openproxy-bks; Tue, 22 Apr 2003 19:31:54 -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.8p1/8.12.8) with ESMTP id h3N2Vrt2060976 for ; Tue, 22 Apr 2003 19:31:53 -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 h3N2Vmf08402; Tue, 22 Apr 2003 22:31:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 22:31:48 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582AD9C@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , ietf-openproxy@imc.org Subject: RE: SOAP and OCP Date: Tue, 22 Apr 2003 22:31:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30940.7D2447F4" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30940.7D2447F4 Content-Type: text/plain Markus, No problem Abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, April 22, 2003 9:14 PM > To: ietf-openproxy@imc.org > Subject: Re: SOAP and OCP > > > > Abbie Barbir wrote: > > > The plan for now is to go ahead and get a transport for OCP > that best > > fits. > > Absolutely, that's the goal! > > > SOAP addresses some issues and is good in some situations. > > We will readdress later. > > Discussing the pros and cons of using SOAP (or other > protocols) as the > OCP transport is perfectly fine (and we already had some good > discussions around that topic). The goal of these discussions is to > decide on THE OCP transport - the result should be unambiguous, if > possible. The WG will then move forward with the selected OCP > transport and won't spend cycles on other alternatives. > > If this sounds OK, we're in agreement. > > -Markus > > ------_=_NextPart_001_01C30940.7D2447F4 Content-Type: text/html RE: SOAP and OCP

Markus,

No problem

Abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Tuesday, April 22, 2003 9:14 PM
> To: ietf-openproxy@imc.org
> Subject: Re: SOAP and OCP
>
>
>
> Abbie Barbir wrote:
>
> > The plan for now is to go ahead and get a transport for OCP
> that best
> > fits.
>
> Absolutely, that's the goal!
>
> > SOAP addresses some issues and is good in some situations.
> > We will readdress later.
>
> Discussing the pros and cons of using SOAP (or other
> protocols) as the
> OCP transport is perfectly fine (and we already had some good
> discussions around that topic). The goal of these discussions is to
> decide on THE OCP transport - the result should be unambiguous, if
> possible. The WG will then move forward with the selected OCP
> transport and won't spend cycles on other alternatives.
>
> If this sounds OK, we're in agreement.
>
> -Markus
>
>

------_=_NextPart_001_01C30940.7D2447F4-- From owner-ietf-openproxy@mail.imc.org Tue Apr 22 22:43:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04761 for ; Tue, 22 Apr 2003 22:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198AGO-0007Ac-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 22:45:36 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198AGO-0007AZ-00 for opes-archive@ietf.org; Tue, 22 Apr 2003 22:45:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N2Zot2061037 for ; Tue, 22 Apr 2003 19:35:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N2ZohX061036 for ietf-openproxy-bks; Tue, 22 Apr 2003 19:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.110]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N2Zmt2061030 for ; Tue, 22 Apr 2003 19:35:49 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout10.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HDR00G2DYNYV7@mtaout10.icomcast.net> for ietf-openproxy@imc.org; Tue, 22 Apr 2003 22:23:58 -0400 (EDT) Date: Tue, 22 Apr 2003 22:23:57 -0400 From: Markus Hofmann Subject: Re: HTTP as OCP transport, ICAP/2.0 In-reply-to: To: ietf-openproxy@imc.org Message-id: <3EA5F93D.6040101@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 References: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Alex Rousskov wrote: > + ICAP uses HTTP as transport; we can make > OCP look like ICAP/2.0, which may > significantly improve OCP survival/adoption > chances Hm, does ICAP really use HTTP as transport, i.e. run on top of HTTP? I'd say ICAP is a protocol that looks very much like HTTP and uses TCP as the transport. Indeed, RFC 3507 states "ICAP uses TCP/IP as a transport protocol. The default port is 1344, but other ports may be used.". In the early stages of ICAP, it was supposed to run over HTTP, but this was dropped at some later point. > + HTTP applications are our primary target; > it would be easier to add OCP support to > HTTP intermediaries (OPES processors) if > OCP transport is also HTTP > > + it is likely that many existing web services already > support HTTP (e.g., as a part of SOAP over HTTP); > it would be easier to add OCP support to > such services (OPES callout servers) if > OCP transport is also HTTP > > + HTTP is fairly well-understood protocol as > far as basic transport functionality is > concerned An additional pro might be firewall traversal, although this might not be that big of an issue in deployment scenarios OCP will play a role (?). > Here are the reasons to avoid HTTP as OCP transport: > > - HTTP makes it difficult to support a pipeline of OCP > messages without converting every message into > a request/response pair; this limits OCP flexibility > and/or performance > > - ICAP uses HTTP as transport; if we try to make OCP > to look like ICAP/2.0, we may have to sacrifice > some (many?) OCP properties and clean design to > retain some form of backward compatibility; for example, > OCP metadata should be distinct from HTTP metadata, > which may be difficult to achieve while > preserving compatibility with ICAP/1.1. > > - HTTP lacks appropriate connection management > primitives because persistent connections were > added on top of an existing protocol (HTTP/1.0) > and are just a performance optimization; HTTP is > not really design for long-lived connections many > OCP agents would enjoy > > - HTTP lacks appropriate native support for security > and authentication; compared to SOAP and BEEP, > little reuse of other protocols/mechanisms is > possible in this context > > - HTTP specification (RFC 2616) is a big, complicated > document; HTTP comes with many features that OCP > probably does not need The kind of "streaming capabilities" of HTTP (i.e. chunking) is kind of limited. If running over HTTP, would we expect problems with HTTP intermediaries sitting in-between the OPES processor and the callout server (for example if OPES processor and callout server ane in different adminsitrative domains). -Markus From owner-ietf-openproxy@mail.imc.org Wed Apr 23 01:22:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08065 for ; Wed, 23 Apr 2003 01:22:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198CkY-00000H-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 01:24:54 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198CkX-00000E-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 01:24:53 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N5Cut2066846 for ; Tue, 22 Apr 2003 22:12:56 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N5CumX066845 for ietf-openproxy-bks; Tue, 22 Apr 2003 22:12: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.8p1/8.12.8) with ESMTP id h3N5Cst2066840 for ; Tue, 22 Apr 2003 22:12: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 h3N5Cvvj030410; Tue, 22 Apr 2003 23:12:57 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3N5CvcX030409; Tue, 22 Apr 2003 23:12:57 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 23:12:57 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: HTTP as OCP transport, ICAP/2.0 In-Reply-To: <3EA5F93D.6040101@mhof.com> Message-ID: References: <3EA5F93D.6040101@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: On Tue, 22 Apr 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > + ICAP uses HTTP as transport; we can make > > OCP look like ICAP/2.0, which may > > significantly improve OCP survival/adoption > > chances > > Hm, does ICAP really use HTTP as transport, i.e. run on top of HTTP? > I'd say ICAP is a protocol that looks very much like HTTP and uses > TCP as the transport. Indeed, RFC 3507 states "ICAP uses TCP/IP as a > transport protocol. The default port is 1344, but other ports may > be used.". Minor terminology conflict, I believe. When I said "HTTP transport", I meant what you mean above. Since HTTP is so extensible, it is difficult to say what is "transport" and what is "looks very much like". If we use HTTP as (the only) OCP transport we are likely to do what ICAP folks had to do or something similar to that. > An additional pro might be firewall traversal, although this might > not be that big of an issue in deployment scenarios OCP will play a > role (?). Yes, though it becomes even less of an issue with firewalls becoming smarter about the traffic they block (moving from L2-4 to L7). Moreover, OCP servers, like ICAP servers, are not likely to run on port 80 by default even if HTTP transport/model is used. > The kind of "streaming capabilities" of HTTP (i.e. chunking) is kind > of limited. Yes, we would not be able to use chunking "as is" without giving up current OCP flexibility to mix data chunks and control commands on the same TCP connection. > If running over HTTP, would we expect problems with HTTP > intermediaries sitting in-between the OPES processor and the callout > server (for example if OPES processor and callout server ane in > different adminsitrative domains). This question is on the to-do list: do we want OCP to be proxy-able? We can probably go either way, especially if OCP is based on HTTP. At this time, I see no reason to allow/document OCP proxies explicitly, but once the transport protocol is selected, we must revisit the issue. I've never heard of BEEP proxies. Do they exist? What about SOAP proxies? Are they similar to (or even the same as) XML switches? Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 23 01:41:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08540 for ; Wed, 23 Apr 2003 01:41:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198D2u-00008T-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 01:43:53 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198D2u-00008Q-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 01:43:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N5Y3t2067385 for ; Tue, 22 Apr 2003 22:34:03 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N5Y368067384 for ietf-openproxy-bks; Tue, 22 Apr 2003 22:34: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.8p1/8.12.8) with ESMTP id h3N5Y2t2067377 for ; Tue, 22 Apr 2003 22:34: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 h3N5Y5vj030900; Tue, 22 Apr 2003 23:34:05 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3N5Y5Fh030899; Tue, 22 Apr 2003 23:34:05 -0600 (MDT) (envelope-from rousskov) Date: Tue, 22 Apr 2003 23:34:05 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: SOAP and OCP In-Reply-To: <3EA5E6A8.2000007@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540582A397@zcard0k6.ca.nortel.com> <3EA5CBD0.8020903@mhof.com> <3EA5E6A8.2000007@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: On Tue, 22 Apr 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > OPES architecture already assumes that adaptation can be done by > > means other than OCP. > > Only if this "other than OCP" fully complies with the requirements > outlined in the WG documents Yes, of course, though the OCP requirements draft may not apply in this case because it defines many requirements that have nothing to do with OPES framework but simply outline what we think a _good_ OCP protocol can be. In other words, it is possible to build an OPES-compliant system using a non-OCP-compliant callout protocol. > (which might be obvious if "other than OCP" is a local procedure > call on the OPES processor). As I probably mentioned before, the architecture documents do not (cannot?) distinguish "local" from "remote" without severely limiting OPES processor definition. The processor "box" is not well defined, and even "local" adapters have to obey applicable OPES requirements (if any). > If this "othern than OCP" would have to be modified/extended in oder > to meet the requirements, or if the usage of "other than OCP" would > imply additional complexity on the OPES framework, the WG shouldn't > spend cycles on it. I agree. All I am saying is that OPES framework requirements such as tracing and bypassing draft(s) should not have any dependency on a particular form of the callout/adaptation mechanism. This is the primary reason to keep those drafts specific to OPES processor (or even dispatcher, something we would have to argue about later). > I believe we're basically in agreement here. Yes, I think so. We can proceed without violating each other preferences, at least for now :-). We may have to revisit the "local" versus "remote" and "processor" versus "dispatcher" issues later, when it is time to define OPES tracing/bypass scope. At that time, I will argue that, for example, it is impossible to bypass non-OCP adaptation "inside" the OPES processor as it is currently defined, and I would argue that the definition or usage of "processor" and "dispatcher" terms should be revised to allow for such bypass and to erase any distinction between OCP-based and other adaptors. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 23 02:34:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05387 for ; Wed, 23 Apr 2003 02:34:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Ds1-0000iK-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 02:36:41 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198Ds0-0000iE-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 02:36:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N6QIt2074855 for ; Tue, 22 Apr 2003 23:26:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N6QIMH074854 for ietf-openproxy-bks; Tue, 22 Apr 2003 23:26:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N6QHt2074842 for ; Tue, 22 Apr 2003 23:26:17 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3N6WH9o013963; Wed, 23 Apr 2003 00:32:17 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3N6PD509605; Wed, 23 Apr 2003 00:25:13 -0600 Date: Wed, 23 Apr 2003 00:25:13 -0600 Message-Id: <200304230625.h3N6PD509605@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: markus@mhof.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <3EA5F93D.6040101@mhof.com> Subject: Re: HTTP as OCP transport, ICAP/2.0 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Transport" in the classicial meaning is layer 4. However, it's possible for a protocol, like ICAP, to use a layer 5 protocol as its transport. That is, to fit entirely within the semantics of layer 5 and to introduce its own further semantics. I think that is the best way to view ICAP, from an architectural viewpoint. The deviations from HTTP semantics are trivial. The intent was to have something that ran on devices that already understood HTTP, so very little additional code would be writtent to support ICAP. Most multimedia streaming protocols run over HTTP fairly well. We've stated several times that the OPES processor and callout server have to be in the same administrative domain for security reasons. But, let's look at the case where they aren't, just for fun. Suppose someone put an HTTP intermediary in their path, as you suggest, and suppose it is an OPES process and it does HTTP content modification, wouldn't that be a mess? Even if the callout protocol is something else (SE), there might be an OPES box doing SE modification in the path. So, I'd think the callout protocol MUST carry a transport header with "no OPES" in order to control what could turn into an uncontrollable routing problem. Hilarie From owner-ietf-openproxy@mail.imc.org Wed Apr 23 09:47:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18281 for ; Wed, 23 Apr 2003 09:47:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Kdb-0003uc-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 09:50:15 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198Kda-0003uZ-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 09:50:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NDaRt2016427 for ; Wed, 23 Apr 2003 06:36:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NDaRJm016426 for ietf-openproxy-bks; Wed, 23 Apr 2003 06:36:27 -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.8p1/8.12.8) with ESMTP id h3NDaQt2016418 for ; Wed, 23 Apr 2003 06:36:26 -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 h3NDaC820029; Wed, 23 Apr 2003 09:36:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Apr 2003 09:36:12 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540582AF51@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "The Purple Streak, Hilarie Orman" , markus@mhof.com Cc: ietf-openproxy@imc.org Subject: RE: HTTP as OCP transport, ICAP/2.0 Date: Wed, 23 Apr 2003 09:36:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3099D.4D6AD6CE" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C3099D.4D6AD6CE Content-Type: text/plain Hilarie, yes I do concur with you. We have addressed the other issue before (not in the same administrative domain, the VPCN solution if you remember). Abbie > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Wednesday, April 23, 2003 2:25 AM > To: markus@mhof.com > Cc: ietf-openproxy@imc.org > Subject: Re: HTTP as OCP transport, ICAP/2.0 > > > > "Transport" in the classicial meaning is layer 4. However, > it's possible for a protocol, like ICAP, to use a layer 5 > protocol as its transport. That is, to fit entirely within > the semantics of layer 5 and to introduce its own further > semantics. I think that is the best way to view ICAP, from > an architectural viewpoint. The deviations from HTTP > semantics are trivial. The intent was to have something that > ran on devices that already understood HTTP, so very little > additional code would be writtent to support ICAP. > > Most multimedia streaming protocols run over HTTP fairly well. > > We've stated several times that the OPES processor and > callout server have to be in the same administrative domain > for security reasons. But, let's look at the case where they > aren't, just for fun. Suppose someone put an HTTP > intermediary in their path, as you suggest, and suppose it is > an OPES process and it does HTTP content modification, > wouldn't that be a mess? > > Even if the callout protocol is something else (SE), there > might be an OPES box doing SE modification in the path. > > So, I'd think the callout protocol MUST carry a transport > header with "no OPES" in order to control what could turn > into an uncontrollable routing problem. > > Hilarie > > > > ------_=_NextPart_001_01C3099D.4D6AD6CE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: HTTP as OCP transport, ICAP/2.0

Hilarie,

yes I do concur with you.

We have addressed the other issue before (not in the = same administrative domain, the VPCN solution if you remember).


Abbie


> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> Sent: Wednesday, April 23, 2003 2:25 AM
> To: markus@mhof.com
> Cc: ietf-openproxy@imc.org
> Subject: Re: HTTP as OCP transport, = ICAP/2.0
>
>
>
> "Transport" in the classicial meaning = is layer 4.  However,
> it's possible for a protocol, like ICAP, to use = a layer 5
> protocol as its transport.  That is, to = fit entirely within
> the semantics of layer 5 and to introduce its = own further
> semantics.  I think that is the best way = to view ICAP, from
> an architectural viewpoint.  The = deviations from HTTP
> semantics are trivial.  The intent was to = have something that
> ran on devices that already understood HTTP, so = very little
> additional code would be writtent to support = ICAP.
>
> Most multimedia streaming protocols run over = HTTP fairly well.
>
> We've stated several times that the OPES = processor and
> callout server have to be in the same = administrative domain
> for security reasons. But, let's look at the = case where they
> aren't, just for fun.  Suppose someone put = an HTTP
> intermediary in their path, as you suggest, and = suppose it is
> an OPES process and it does HTTP content = modification,
> wouldn't that be a mess?
>
> Even if the callout protocol is something else = (SE), there
> might be an OPES box doing SE modification in = the path.
>
> So, I'd think the callout protocol MUST carry a = transport
> header with "no OPES" in order to = control what could turn
> into an uncontrollable routing problem.
>
> Hilarie
>
>
>
>

------_=_NextPart_001_01C3099D.4D6AD6CE-- From owner-ietf-openproxy@mail.imc.org Wed Apr 23 10:25:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20714 for ; Wed, 23 Apr 2003 10:25:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198LDb-0004FN-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 10:27:27 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198LDa-0004FJ-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 10:27:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NEIQt2020294 for ; Wed, 23 Apr 2003 07:18:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NEIQmX020293 for ietf-openproxy-bks; Wed, 23 Apr 2003 07:18:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mx01.netapp.com (mx01.netapp.com [198.95.226.53]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NEIPt2020270 for ; Wed, 23 Apr 2003 07:18:25 -0700 (PDT) (envelope-from jmartin@netapp.com) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.9/8.12.9/NTAP-1.4) with ESMTP id h3NEIKFB024169 for ; Wed, 23 Apr 2003 07:18:21 -0700 (PDT) Received: from JMARTIN-LAP2.netapp.com ([10.58.48.234]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.4) with ESMTP id h3NEIJJd006038 for ; Wed, 23 Apr 2003 07:18:20 -0700 (PDT) Message-Id: <5.2.0.9.2.20030423100418.032732f0@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Apr 2003 10:15:04 -0400 To: ietf-openproxy@imc.org From: John Martin Subject: Re: HTTP as OCP transport, ICAP/2.0 In-Reply-To: <200304230625.h3N6PD509605@localhost.localdomain> References: 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: Hilarie is correct in that the aim was to make it friendly to HTTP developers and apps with existing HTTP interfaces rather than strict HTTP compliance. If I recall correctly, the main reason that ICAP diverged from HTTP was that ICAP required chunking. Leaving chunking as optional made icap-enabled applications that dealt with the transfer of large amounts of data slow and inefficient. In particular virus scanning apps wanted a way to ack a small piece of data and tell the icap client to send more or not. Originally, ICAP was defined as an HTTP vectoring protocol or "HTTP over HTTP" - a way of encapsulating one complete HTTP message within another HTTP message. It still looks and smells a lot like HTTP. John At 02:25 23/04/2003, The Purple Streak, Hilarie Orman wrote: >"Transport" in the classicial meaning is layer 4. However, it's >possible for a protocol, like ICAP, to use a layer 5 protocol as its >transport. That is, to fit entirely within the semantics of layer 5 >and to introduce its own further semantics. I think that is the best >way to view ICAP, from an architectural viewpoint. The deviations from >HTTP semantics are trivial. The intent was to have something that ran >on devices that already understood HTTP, so very little additional code >would be writtent to support ICAP. > >Most multimedia streaming protocols run over HTTP fairly well. > >We've stated several times that the OPES processor and callout server >have to be in the same administrative domain for security reasons. >But, let's look at the case where they aren't, just for fun. Suppose >someone put an HTTP intermediary in their path, as you suggest, and >suppose it is an OPES process and it does HTTP content modification, >wouldn't that be a mess? > >Even if the callout protocol is something else (SE), there might be an >OPES box doing SE modification in the path. > >So, I'd think the callout protocol MUST carry a transport header with >"no OPES" in order to control what could turn into an uncontrollable >routing problem. > >Hilarie --------------------------------------------------------------- Please note new phone number: +1 347 613 2259 --------------------------------------------------------------- From owner-ietf-openproxy@mail.imc.org Wed Apr 23 11:03:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22277 for ; Wed, 23 Apr 2003 11:03:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198LpA-0004ac-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 11:06:16 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198LpA-0004aZ-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 11:06:16 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NEt0t2023310 for ; Wed, 23 Apr 2003 07:55:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NEt0vC023309 for ietf-openproxy-bks; Wed, 23 Apr 2003 07:55:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NEsxt2023301 for ; Wed, 23 Apr 2003 07:54:59 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3NEstXk004784; Wed, 23 Apr 2003 07:54:55 -0700 (PDT) Date: Wed, 23 Apr 2003 07:54:55 -0700 From: Marshall Rose To: "The Purple Streak, Hilarie Orman" Cc: rousskov@measurement-factory.com, ietf-openproxy@imc.org, martin.stecher@webwasher.com Subject: Re: HTTP as OCP transport, ICAP/2.0 Message-Id: <20030423075455.0176622c.mrose@dbc.mtview.ca.us> In-Reply-To: <200304222316.h3MNGd220916@localhost.localdomain> References: <200304222316.h3MNGd220916@localhost.localdomain> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit [ again, not speaking as a co-chair... ] > I thought BEEP's security was the same as HTTP's: use TLS. no. you can negotiate the use of tls with beep. (in contrast, with most http implementations, it's not a negotiation, it's "just there" or not, depending on the port you open.) in addition, tls uses sasl which can complement, or replace tls' functionality. for example, want to authenticate/privatize using kerberos? no problem, negotiate the use of the kerberos mechanism in sasl. /mtr From owner-ietf-openproxy@mail.imc.org Wed Apr 23 11:33:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23544 for ; Wed, 23 Apr 2003 11:33:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198MI8-0004sL-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 11:36:12 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198MI7-0004sG-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 11:36:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NFOat2026221 for ; Wed, 23 Apr 2003 08:24:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NFOald026220 for ietf-openproxy-bks; Wed, 23 Apr 2003 08:24: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.8p1/8.12.8) with ESMTP id h3NFOZt2026215 for ; Wed, 23 Apr 2003 08:24: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 h3NFOYvj044815; Wed, 23 Apr 2003 09:24:34 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3NFOYwA044814; Wed, 23 Apr 2003 09:24:34 -0600 (MDT) (envelope-from rousskov) Date: Wed, 23 Apr 2003 09:24:34 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: HTTP as OCP transport, ICAP/2.0 In-Reply-To: <200304230625.h3N6PD509605@localhost.localdomain> Message-ID: References: <200304230625.h3N6PD509605@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: On Wed, 23 Apr 2003, The Purple Streak, Hilarie Orman wrote: > We've stated several times that the OPES processor and callout > server have to be in the same administrative domain for security > reasons. I hope the above is a typo. Perhaps you meant "same trust domain"? Requiring same administrative domain is totally unnecessary, even for security reasons. > But, let's look at the case where they aren't, just for fun. > Suppose someone put an HTTP intermediary in their path, as you > suggest, and suppose it is an OPES process and it does HTTP content > modification, wouldn't that be a mess? I am not sure what "as you suggest" refers to (you did not quote the message you are responding to). If my ISP or an ISP further upstream installed a TCP hijacking HTTP proxy and did not tell me about it (explicitly or via a smallprint in a signed contract), then there is a trust problem. If the installed HTTP proxy is OPES-compliant and my browser is OPES-aware, I may be able to notice/debug it. > Even if the callout protocol is something else (SE), there might be > an OPES box doing SE modification in the path. Yes, the specific callout mechanism is irrelevant here. > So, I'd think the callout protocol MUST carry a transport header > with "no OPES" in order to control what could turn into an > uncontrollable routing problem. I do not understand the above. Can you elaborate? IMO, the callout protocol MUST NOT be involved if an OPES processor was instructed to bypass OPES transformations (that instruction may come via the application protocol being proxied). If callout protocol is involved, we are not bypassing. If OPES processor cannot honor a bypass instruction, then it is either incompliant or has to talk to an OPES processor (and not just a callout server). Either case, is out of OCP scope. Alex. From owner-ietf-openproxy@mail.imc.org Wed Apr 23 11:54:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24267 for ; Wed, 23 Apr 2003 11:54:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198McM-000547-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 11:57:06 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198McL-000544-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 11:57:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NFhKt2026856 for ; Wed, 23 Apr 2003 08:43:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NFhKRs026855 for ietf-openproxy-bks; Wed, 23 Apr 2003 08:43: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.8p1/8.12.8) with ESMTP id h3NFhIt2026850 for ; Wed, 23 Apr 2003 08:43: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 h3NFhGvj045295 for ; Wed, 23 Apr 2003 09:43:16 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3NFhGiR045294; Wed, 23 Apr 2003 09:43:16 -0600 (MDT) (envelope-from rousskov) Date: Wed, 23 Apr 2003 09:43:16 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCPTRAN as OCP transport In-Reply-To: Message-ID: References: <200304170117.h3H1HRQ06771@localhost.localdomain> <200304170117.h3H1HRQ06771@localhost.localdomain> <5.2.0.9.0.20030417114605.02baa090@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: Hilarie, You mentioned that a new custom OCP transport is the best way to proceed, but did not follow up on that suggestion. As of now, we seem to have two existing transports to consider: BEEP and HTTP. Do you still think a new, custom transport would be better? If yes, can you elaborate? You can use my specific questions below to start with (they split the problem into two semi-independent parts: new versus old transport and reliable versus lossy transport). It would be great to have more information so that we can summarize the advantages/disadvantages of all transports and make the final selection. Thank you, Alex. On Thu, 17 Apr 2003, Alex Rousskov wrote: > > On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote: > > > Personally, I think the best choice is a new transport named OCPTRAN > > that can run over TCP for data that needs reliable service and can > > also run over UDP or just IP if need be. > > If the group is convinced that designing a new transport is a good > idea, one way to proceed is to take BEEP, remove its XML dependency > (unless we choose to use XML for OCP messages) and remove mandatory > responses. Doing just that will allow us to reuse a lot of existing > documentation (and even code). Hilarie, could you please try to > convince us that new transport is needed assuming no UDP support is > required? > > Hmm... The above can be rephrased in a more direct way, I guess: > Hilarie, what is wrong with BEEP, assuming no UDP support is required? > Once we know what is wrong, we can see what it would take to fix it. > > > If the group is further convinced that unreliable transport support is > needed, I would suggest that we add lossy transport support to the > above. Hilarie, could you please try to convince us that unreliable > transport support is required? More specifically, what kind of > application protocols cannot be adapted with OCP/TCP using a > reasonable set of OCP transaction timeouts to accomodate slow callout > servers or bad connectivity to them? > > Thank you, > > Alex. > From owner-ietf-openproxy@mail.imc.org Wed Apr 23 15:02:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00936 for ; Wed, 23 Apr 2003 15:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198PXc-0006Us-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 15:04:24 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198PXV-0006UK-00 for opes-archive@ietf.org; Wed, 23 Apr 2003 15:04:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NInkt2035410 for ; Wed, 23 Apr 2003 11:49:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NInk7e035409 for ietf-openproxy-bks; Wed, 23 Apr 2003 11:49:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NInjt2035404 for ; Wed, 23 Apr 2003 11:49:46 -0700 (PDT) (envelope-from batuner@attbi.com) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2003042318494200200o1crje>; Wed, 23 Apr 2003 18:49:42 +0000 From: "Oskar Batuner" To: "The Purple Streak, Hilarie Orman" Cc: Subject: RE: HTTP as OCP transport, ICAP/2.0 Date: Wed, 23 Apr 2003 14:49:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <200304230625.h3N6PD509605@localhost.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of The Purple > Streak, Hilarie Orman > Sent: Wednesday, April 23, 2003 2:25 AM > To: markus@mhof.com > Cc: ietf-openproxy@imc.org > Subject: Re: HTTP as OCP transport, ICAP/2.0 > > > We've stated several times that the OPES processor and callout server > have to be in the same administrative domain for security reasons. > But, let's look at the case where they aren't, just for fun. Suppose > someone put an HTTP intermediary in their path, as you suggest, and > suppose it is an OPES process and it does HTTP content modification, > wouldn't that be a mess? > > Even if the callout protocol is something else (SE), there might be an > OPES box doing SE modification in the path. > > So, I'd think the callout protocol MUST carry a transport header with > "no OPES" in order to control what could turn into an uncontrollable > routing problem. Hilarie, I do not quite understand your fears. An OPES box is (should be) a legitimate building block for network application architecture. If rules and protocols are designed correctly they should not require additional restrictions of this kind. Moreover, imposing such specific restrictions looks like introducing per-case patches. Unless there is a specific scenario that result in problem we should avoid patching. Oskar From owner-ietf-openproxy@mail.imc.org Thu Apr 24 09:07:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15528 for ; Thu, 24 Apr 2003 09:07:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198gUA-0005nb-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 09:09:58 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198gUA-0005nX-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 09:09:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OCjrt2002770 for ; Thu, 24 Apr 2003 05:45:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OCjrEH002769 for ietf-openproxy-bks; Thu, 24 Apr 2003 05:45:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3OCjot2002735 for ; Thu, 24 Apr 2003 05:45:51 -0700 (PDT) (envelope-from martin.stecher@webwasher.com) Received: from hermes.webwasher.com [192.168.1.3] id CF2J8RM6; 24 Apr 2003 14:45:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HTTP as OCP transport, ICAP/2.0 Date: Thu, 24 Apr 2003 14:42:16 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02EF54CC9@hermes.webwasher.com> Thread-Topic: HTTP as OCP transport, ICAP/2.0 Thread-Index: AcMJFMDdatHwarRASwCpnVT0csJqiABRmkVA From: "Martin Stecher" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h3OCjqt2002763 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, > IMO, the primary reason to use HTTP as OCP transport would be > "compatibility" with ICAP. I wonder if ICAP proponents would consider > it possible for ICAP/2.0 or ICAP-NG to use something other than HTTP > as transport? Or will selection of other transports kill the > opportunity to merge ICAP/2.0 and OCP? > > What do you think? I am especially interested in comments from Martin > Stecher and anybody else with first-hand ICAP experience. I am just returning from an easter holiday, sorry for the delay. I fully agree to what Hilarie and John explained regarding the ICAP history and the motivation to have it in a HTTP-like style. ICAP developers from the first hours that migrated from ICAP/0.9 and ICAP/0.95 to ICAP/1.0 already experienced the development from a pure HTTP implementation to a standalone protocol (which is still very much like HTTP though). It is definetly a plus that ICAP developers can benefit from their HTTP protocol experience and probably have already some source code around that can be reused when implementing ICAP. On the other hand ICAP/1.0 is different from HTTP and that may require changes to existing HTTP handling code which may introduce new problems as well, e.g. the existence of two zero-end-chunks within one message. If you look in the ICAP implementation within the Squid project you will also find that reusing the HTTP code for ICAP can make things hardly readable. Getting this together I believe that ICAP/2.0 can have a different transport than HTTP. Creating a new ICAP version without touching the transport layer seems nearly impossible to me. Picking a fully binary protocol would be a too big difference though. I think ICAP TNG should still have some text elements and some ICAP-known syntax elements like icap-URIs. Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Apr 24 11:40:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20295 for ; Thu, 24 Apr 2003 11:40:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198iri-0006iL-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 11:42:27 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198iri-0006iH-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 11:42:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OFSft2013911 for ; Thu, 24 Apr 2003 08:28:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OFSfjh013910 for ietf-openproxy-bks; Thu, 24 Apr 2003 08:28:41 -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.8p1/8.12.8) with ESMTP id h3OFSet2013904 for ; Thu, 24 Apr 2003 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 h3OFSevj081087; Thu, 24 Apr 2003 09:28:40 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3OFSebO081086; Thu, 24 Apr 2003 09:28:40 -0600 (MDT) (envelope-from rousskov) Date: Thu, 24 Apr 2003 09:28:40 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: HTTP as OCP transport, ICAP/2.0 In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CC9@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CC9@hermes.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: On Thu, 24 Apr 2003, Martin Stecher wrote: > Getting this together I believe that ICAP/2.0 can have a different > transport than HTTP. Creating a new ICAP version without touching > the transport layer seems nearly impossible to me. Picking a fully > binary protocol would be a too big difference though. I think ICAP > TNG should still have some text elements and some ICAP-known syntax > elements like icap-URIs. Thank you for detailed comments, Martin. Given your position (and absence of other HTTP-related comments/objections), I will nominate BEEP as the OCP transport (I will do that on a separate thread shortly). With BEEP, we can keep the OCP headers text-based while still allowing for fast, efficient parsing. Or we can have them XML-based (also text but not optimized for parsing). I also agree that we should reuse "good things" from ICAP, as much as possible. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 24 11:48:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20644 for ; Thu, 24 Apr 2003 11:48:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198ize-0006p7-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 11:50:39 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198ize-0006p1-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 11:50:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OFf6t2014428 for ; Thu, 24 Apr 2003 08:41:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OFf6pb014427 for ietf-openproxy-bks; Thu, 24 Apr 2003 08:41: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.8p1/8.12.8) with ESMTP id h3OFf5t2014421 for ; Thu, 24 Apr 2003 08:41: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 h3OFf6vj081432 for ; Thu, 24 Apr 2003 09:41:06 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3OFf6i3081431; Thu, 24 Apr 2003 09:41:06 -0600 (MDT) (envelope-from rousskov) Date: Thu, 24 Apr 2003 09:41:06 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: OCP transport nomination In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CC9@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CC9@hermes.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: I would like to nominate BEEP as the only OCP transport. My primary reasons for nominating BEEP are: - reuse of BEEP negotiation capabilities for transport encryption and such - availability of efficient transfer for opaque ("binary") data There are several issues that we would need to resolve if BEEP is selected by the group (e.g., selecting BEEP message exchange model and defining OCP message encoding), but I would like to hear other protocol nominations (Hilarie?) or any objections to BEEP before discussing BEEP-specific details. I hope I am not making a mistake by giving BEEP a preference over SOAP. I would really like to use SOAP because that is what web services world is using, and we are doing something very similar. Unfortunately, SOAP suffers from a legacy of being started as an RPC protocol and has no standard way of handling large opaque data [efficiently]. If BEEP is selected, we would essentially trade "efficient transfer" for "current deployment". I hope that is the right choice, especially since SOAP can still be used as another callout protocol in environments where efficient transfer is not important. If you think otherwise, please speak up now. We have talked about all known transport candidates except Hilarie's OCPTRAN. Let's move this discussion to a closure. OCP work cannot proceed much further without the transport selection. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 24 12:51:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23244 for ; Thu, 24 Apr 2003 12:51:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198jz7-0007FN-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 12:54:09 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198jz6-0007FD-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 12:54:08 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OGhTt2016819 for ; Thu, 24 Apr 2003 09:43:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OGhTYc016818 for ietf-openproxy-bks; Thu, 24 Apr 2003 09:43:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3OGhQt2016810 for ; Thu, 24 Apr 2003 09:43:27 -0700 (PDT) (envelope-from martin.stecher@webwasher.com) Received: from hermes.webwasher.com [192.168.1.3] id X02LKT4T; 24 Apr 2003 18:43:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCP transport nomination Date: Thu, 24 Apr 2003 18:39:57 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02EF54CCD@hermes.webwasher.com> Thread-Topic: OCP transport nomination Thread-Index: AcMKfEVUmjBipdAuQZO9sBdP3aKWVAAAZcyg From: "Martin Stecher" To: "Alex Rousskov" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h3OGhSt2016814 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Alex, could you already give some real life examples how OCP over BEEP will look like? I am not sure how much XML and Content-Type statements will be necessary to be BEEP compatible. While I like many of the BEEP concepts and agree that they are very useful for OCP, I am not sure that I will like the protocol's look and feel. This may change by seeing a real example, or it will encourage me to create an alternate proposal ;-) That's why I am also very interested how OCPTRAN could look like. Regards Martin > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, April 24, 2003 5:41 PM > To: ietf-openproxy@imc.org > Subject: OCP transport nomination > > > > > I would like to nominate BEEP as the only OCP transport. My primary > reasons for nominating BEEP are: > > - reuse of BEEP negotiation capabilities for > transport encryption and such > > - availability of efficient transfer for > opaque ("binary") data > > There are several issues that we would need to resolve if BEEP is > selected by the group (e.g., selecting BEEP message exchange model and > defining OCP message encoding), but I would like to hear other > protocol nominations (Hilarie?) or any objections to BEEP before > discussing BEEP-specific details. > > I hope I am not making a mistake by giving BEEP a preference over > SOAP. I would really like to use SOAP because that is what web > services world is using, and we are doing something very similar. > > Unfortunately, SOAP suffers from a legacy of being started as an RPC > protocol and has no standard way of handling large opaque data > [efficiently]. If BEEP is selected, we would essentially trade > "efficient transfer" for "current deployment". I hope that is the > right choice, especially since SOAP can still be used as another > callout protocol in environments where efficient transfer is not > important. If you think otherwise, please speak up now. > > > We have talked about all known transport candidates except Hilarie's > OCPTRAN. Let's move this discussion to a closure. OCP work cannot > proceed much further without the transport selection. > > Thank you, > > Alex. > From owner-ietf-openproxy@mail.imc.org Thu Apr 24 13:35:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24700 for ; Thu, 24 Apr 2003 13:35:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198kf8-0007ar-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 13:37:34 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198kf8-0007ao-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 13:37:34 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OHPQt2018241 for ; Thu, 24 Apr 2003 10:25:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OHPQIt018240 for ietf-openproxy-bks; Thu, 24 Apr 2003 10:25:26 -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.8p1/8.12.8) with ESMTP id h3OHPPt2018235 for ; Thu, 24 Apr 2003 10:25:25 -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 h3OHHjr09265; Thu, 24 Apr 2003 13:17:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Apr 2003 13:17:46 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540587C904@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Martin Stecher , Alex Rousskov , ietf-openproxy@imc.org Subject: RE: OCP transport nomination Date: Thu, 24 Apr 2003 13:17:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30A85.6971F530" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C30A85.6971F530 Content-Type: text/plain all, sounds like a fair proposal. Hilarie, can u give an example Alex, same toy you. ps: SOAP is out so no work for me Abbie > -----Original Message----- > From: Martin Stecher [mailto:martin.stecher@webwasher.com] > Sent: Thursday, April 24, 2003 12:40 PM > To: Alex Rousskov; ietf-openproxy@imc.org > Subject: RE: OCP transport nomination > > > > Alex, > > could you already give some real life examples how OCP over > BEEP will look like? > > I am not sure how much XML and Content-Type statements will > be necessary to be BEEP compatible. > > While I like many of the BEEP concepts and agree that they > are very useful for OCP, I am not sure that I will like the > protocol's look and feel. This may change by seeing a real > example, or it will encourage me to create an alternate proposal ;-) > > That's why I am also very interested how OCPTRAN could look like. > > Regards > Martin > > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Thursday, April 24, 2003 5:41 PM > > To: ietf-openproxy@imc.org > > Subject: OCP transport nomination > > > > > > > > > > I would like to nominate BEEP as the only OCP transport. My primary > > reasons for nominating BEEP are: > > > > - reuse of BEEP negotiation capabilities for > > transport encryption and such > > > > - availability of efficient transfer for > > opaque ("binary") data > > > > There are several issues that we would need to resolve if BEEP is > > selected by the group (e.g., selecting BEEP message > exchange model and > > defining OCP message encoding), but I would like to hear other > > protocol nominations (Hilarie?) or any objections to BEEP before > > discussing BEEP-specific details. > > > > I hope I am not making a mistake by giving BEEP a preference over > > SOAP. I would really like to use SOAP because that is what web > > services world is using, and we are doing something very similar. > > > > Unfortunately, SOAP suffers from a legacy of being started > as an RPC > > protocol and has no standard way of handling large opaque data > > [efficiently]. If BEEP is selected, we would essentially trade > > "efficient transfer" for "current deployment". I hope that is the > > right choice, especially since SOAP can still be used as another > > callout protocol in environments where efficient transfer is not > > important. If you think otherwise, please speak up now. > > > > > > We have talked about all known transport candidates except > Hilarie's > > OCPTRAN. Let's move this discussion to a closure. OCP work cannot > > proceed much further without the transport selection. > > > > Thank you, > > > > Alex. > > > > ------_=_NextPart_001_01C30A85.6971F530 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: OCP transport nomination

all,

sounds like a fair proposal.

Hilarie, can u give an example
Alex, same toy you.

ps: SOAP is out so no work for me

Abbie


> -----Original Message-----
> From: Martin Stecher [mailto:martin.stecher@webwa= sher.com]
> Sent: Thursday, April 24, 2003 12:40 PM
> To: Alex Rousskov; = ietf-openproxy@imc.org
> Subject: RE: OCP transport nomination
>
>
>
> Alex,
>
> could you already give some real life examples = how OCP over
> BEEP will look like?
>
> I am not sure how much XML and Content-Type = statements will
> be necessary to be BEEP compatible.
>
> While I like many of the BEEP concepts and = agree that they
> are very useful for OCP, I am not sure that I = will like the
> protocol's look and feel. This may change by = seeing a real
> example, or it will encourage me to create an = alternate proposal ;-)
>
> That's why I am also very interested how = OCPTRAN could look like.
>
> Regards
> Martin
>
> > -----Original Message-----
> > From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> > Sent: Thursday, April 24, 2003 5:41 = PM
> > To: ietf-openproxy@imc.org
> > Subject: OCP transport nomination
> >
> >
> >
> >
> > I would like to nominate BEEP as the only = OCP transport. My primary
> > reasons for nominating BEEP are:
> >
> >     - reuse of BEEP = negotiation capabilities for
> >       transport = encryption and such
> >
> >     - availability of = efficient transfer for
> >       opaque = ("binary") data
> >
> > There are several issues that we would = need to resolve if BEEP is
> > selected by the group (e.g., selecting = BEEP message
> exchange model and
> > defining OCP message encoding), but I = would like to hear other
> > protocol nominations (Hilarie?) or any = objections to BEEP before
> > discussing BEEP-specific details.
> >
> > I hope I am not making a mistake by giving = BEEP a preference over
> > SOAP. I would really like to use SOAP = because that is what web
> > services world is using, and we are doing = something very similar.
> >
> > Unfortunately, SOAP suffers from a legacy = of being started
> as an RPC
> > protocol and has no standard way of = handling large opaque data
> > [efficiently]. If BEEP is selected, we = would essentially trade
> > "efficient transfer" for = "current deployment". I hope that is the
> > right choice, especially since SOAP can = still be used as another
> > callout protocol in environments where = efficient transfer is not
> > important. If you think otherwise, please = speak up now.
> >
> >
> > We have talked about all known transport = candidates except
> Hilarie's
> > OCPTRAN.  Let's move this discussion = to a closure. OCP work cannot
> > proceed much further without the transport = selection.
> >
> > Thank you,
> >
> > Alex.
> >
>
>

------_=_NextPart_001_01C30A85.6971F530-- From owner-ietf-openproxy@mail.imc.org Thu Apr 24 14:49:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27285 for ; Thu, 24 Apr 2003 14:49:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198lpR-0000Fo-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 14:52:17 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198lpQ-0000FT-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 14:52:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OIe8t2022113 for ; Thu, 24 Apr 2003 11:40:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OIe8ck022112 for ietf-openproxy-bks; Thu, 24 Apr 2003 11:40: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.8p1/8.12.8) with ESMTP id h3OIe7t2022107 for ; Thu, 24 Apr 2003 11:40: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 h3OIe8vj086461; Thu, 24 Apr 2003 12:40:08 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3OHppHd084226; Thu, 24 Apr 2003 11:51:51 -0600 (MDT) (envelope-from rousskov) Date: Thu, 24 Apr 2003 11:49:10 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: OCP transport nomination In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CCD@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CCD@hermes.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: On Thu, 24 Apr 2003, Martin Stecher wrote: > could you already give some real life examples how OCP over BEEP > will look like? I am not sure how much XML and Content-Type > statements will be necessary to be BEEP compatible. Here is an example of what XML and MIME exposure is _required_ by BEEP. The actual exposure to XML and MIME headers (beyond this example) would depend on us. "C" is for OPES processor. "S" is for callout server. * OCP connection (BEEP session) and OCP transaction (BEEP channel) establishment; the transaction establishment part is missing OCP control messages (those are given in the next example): S: C: S: RPY 0 0 . 0 201 S: S: S: S: S: END C: RPY 0 0 . 0 52 C: C: C: END C: MSG 0 1 . 52 133 C: C: C: C: C: END S: RPY 0 1 . 201 100 S: S: S: END * Sending an OCP control message over a BEEP channel: C: MSG 1 0 . 0 50 C: Content-type: application/beep+ocp C: C: are-you-there xid ... C: END S: REP 1 0 . 0 61 S: Content-type: application/beep+ocp S: S: i-am-here xid ... S: END * Sending data message over a BEEP channel (note that we may want to establish a new channel for data, in addition to control channel for command messages; here, we are using channel #2, am-id=1234): C: MSG 2 1234 * 0 1634 C: Content-type: whatever-was-negotiated C: C: ... 1634 data octets, with more to come ... C: END C: MSG 2 1234 * 1634 65536 C: Content-type: whatever-was-negotiated C: C: ... 65536 data octets, with more to come ... C: END C: MSG 2 1234 . 67170 100 C: Content-type: whatever-was-negotiated C: C: ... last 100 octets of the data ... C: END Most numbers/parameters are wrong/random. I am just illustrating XML/MIME exposure here. You can notice that we must use XML for BEEP state management and we must use explicit Content-types for anything other than application/beep+xml. Note that if we define our own BEEP messages, we can avoid repetitions of "Content-type:" headers by defining our own defaults. BEEP defaults to application/beep+xml. We will lose compatibility with existing BEEP libraries/implementations though, so it may not be such a good idea. Disclaimer: The first example is actually based on draft-ietf-syslog-reliable-12 that uses BEEP as transport. I am not a BEEP expert yet, so the above may have conceptual bugs. Please correct them if they affect XML/MIME exposure issues. > While I like many of the BEEP concepts and agree that they are very > useful for OCP, I am not sure that I will like the protocol's look > and feel. This may change by seeing a real example, or it will > encourage me to create an alternate proposal ;-) > > That's why I am also very interested how OCPTRAN could look like. I too would be excited to work on a "better BEEP" or "better SOAP". I just think that existing protocols must be considered first (or in parallel). If we can convince ourselves that BEEP is good enough, we will save the working group a lot of work. Alex. > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Thursday, April 24, 2003 5:41 PM > > To: ietf-openproxy@imc.org > > Subject: OCP transport nomination > > > > > > > > > > I would like to nominate BEEP as the only OCP transport. My primary > > reasons for nominating BEEP are: > > > > - reuse of BEEP negotiation capabilities for > > transport encryption and such > > > > - availability of efficient transfer for > > opaque ("binary") data > > > > There are several issues that we would need to resolve if BEEP is > > selected by the group (e.g., selecting BEEP message exchange model and > > defining OCP message encoding), but I would like to hear other > > protocol nominations (Hilarie?) or any objections to BEEP before > > discussing BEEP-specific details. > > > > I hope I am not making a mistake by giving BEEP a preference over > > SOAP. I would really like to use SOAP because that is what web > > services world is using, and we are doing something very similar. > > > > Unfortunately, SOAP suffers from a legacy of being started as an RPC > > protocol and has no standard way of handling large opaque data > > [efficiently]. If BEEP is selected, we would essentially trade > > "efficient transfer" for "current deployment". I hope that is the > > right choice, especially since SOAP can still be used as another > > callout protocol in environments where efficient transfer is not > > important. If you think otherwise, please speak up now. > > > > > > We have talked about all known transport candidates except Hilarie's > > OCPTRAN. Let's move this discussion to a closure. OCP work cannot > > proceed much further without the transport selection. > > > > Thank you, > > > > Alex. > > > > From owner-ietf-openproxy@mail.imc.org Thu Apr 24 15:42:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00048 for ; Thu, 24 Apr 2003 15:42:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198mdw-0000bE-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 15:44:28 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198mdv-0000bB-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 15:44:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OJYVt2023568 for ; Thu, 24 Apr 2003 12:34:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OJYVaB023567 for ietf-openproxy-bks; Thu, 24 Apr 2003 12:34:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OJYTt2023561 for ; Thu, 24 Apr 2003 12:34:30 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.5) with ESMTP id h3OJeumh010092; Thu, 24 Apr 2003 13:40:58 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3OJXTN32356; Thu, 24 Apr 2003 13:33:29 -0600 Date: Thu, 24 Apr 2003 13:33:29 -0600 Message-Id: <200304241933.h3OJXTN32356@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: RE: OCP transport nomination Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This looks pretty good. The major performance issue is whether or not the content message headers can be easily parsed without calling any XML library. The second issue is the same question for transaction establishment. The examples make it look quite easy. It is imperative that we be able to avoid calling XML libraries for these operations. I'm not sure how much of an advantage BEEP's security mechanisms turn out to be. It doesn't seem to have any specific support for detailed security policy, just closes out existing sessions, starts a TLS connection, reopens the sessions on the new connection (might have terminology confused here). Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 24 17:20:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04230 for ; Thu, 24 Apr 2003 17:20:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198oAs-0001dC-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 17:22:34 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198oAr-0001d9-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 17:22:33 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLA7t2028071 for ; Thu, 24 Apr 2003 14:10:07 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLA7Ya028070 for ietf-openproxy-bks; Thu, 24 Apr 2003 14:10:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLA4t2028061 for ; Thu, 24 Apr 2003 14:10:05 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3OLA5Xk009961; Thu, 24 Apr 2003 14:10:06 -0700 (PDT) Date: Thu, 24 Apr 2003 14:10:05 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: OCP transport nomination Message-Id: <20030424141005.08b98973.mrose@dbc.mtview.ca.us> In-Reply-To: References: <72992B39BBD9294BB636A960E89AE02EF54CCD@hermes.webwasher.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit [ speaking as beep guy, and not co-chair... ] > I am just illustrating > XML/MIME exposure here. You can notice that we must use XML for BEEP > state management and we must use explicit Content-types for anything > other than application/beep+xml. alex - perhaps a better way of explaining it is that each beep interaction exchanges a mime object over an 8bit-clean path. mime objects are serialized as some headers, e.g., Content-Type:, a blank line, and then the body. the default content-type is application/octet-stream, which means that if the serialized object starts with a blank line, then Content-Type: application/octet-stream is assumed (not application/beep+xml). this is the "optimize for binary" hack that dave crocker detests so much (dave doesn't like defaults). the use of xml in beep can be limited to channel 0, which is used for channel management (e.g., open a channel for doing ocp). otherwise, beep really doesn't care how one structures the data it sends. /mtr From owner-ietf-openproxy@mail.imc.org Thu Apr 24 17:23:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04407 for ; Thu, 24 Apr 2003 17:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198oDd-0001en-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 17:25:25 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198oDc-0001ek-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 17:25:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLEUt2028413 for ; Thu, 24 Apr 2003 14:14:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLEUVx028412 for ietf-openproxy-bks; Thu, 24 Apr 2003 14:14:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLESt2028407 for ; Thu, 24 Apr 2003 14:14:29 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3OLEPXk009968; Thu, 24 Apr 2003 14:14:25 -0700 (PDT) Date: Thu, 24 Apr 2003 14:14:25 -0700 From: Marshall Rose To: "The Purple Streak, Hilarie Orman" Cc: rousskov@measurement-factory.com, ietf-openproxy@imc.org Subject: Re: OCP transport nomination Message-Id: <20030424141425.00d237fb.mrose@dbc.mtview.ca.us> In-Reply-To: <200304241933.h3OJXTN32356@localhost.localdomain> References: <200304241933.h3OJXTN32356@localhost.localdomain> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit [ speaking as the beep guy, and not the co-chair... ] > This looks pretty good. The major performance issue is whether or not > the content message headers can be easily parsed without calling any > XML library. The second issue is the same question for transaction > establishment. The examples make it look quite easy. It is imperative > that we be able to avoid calling XML libraries for these operations. technical, "content message" headers are "mime things", not "xml things". you can certainly write your own parser to handle the strict 1.0 version of xml that beep uses for channel management, etc., if you're so inclined. > I'm not sure how much of an advantage BEEP's security mechanisms turn > out to be. It doesn't seem to have any specific support for detailed > security policy, ... nor would you want it to, given that security policies are either domain-specific or are so general as to lack meaning. the advantage is that you don't have to re-invent the wheel (since someone already re-invented it for you). in other words, the wg doesn't have to argue about how to encode tls negotiations, or sasl negotiations, etc. the wg doesn't have to argue about the relationship between tls and sasl, etc. a second advantage, is that you get to use the current practices developed by the ietf's application area, without having to think about it. it is fair to say that a great deal of the motivation behind beep was to give wg's the ability to avoid thinking about the administrative aspects of protocol design. /mtr From owner-ietf-openproxy@mail.imc.org Thu Apr 24 17:30:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04729 for ; Thu, 24 Apr 2003 17:30:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198oKK-0001jE-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 17:32:20 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198oKJ-0001j6-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 17:32:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLNkt2028835 for ; Thu, 24 Apr 2003 14:23:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLNknx028834 for ietf-openproxy-bks; Thu, 24 Apr 2003 14:23:46 -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.8p1/8.12.8) with ESMTP id h3OLNit2028829 for ; Thu, 24 Apr 2003 14:23:45 -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 h3OLNW2R090459; Thu, 24 Apr 2003 15:23:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3OLNWMo090458; Thu, 24 Apr 2003 15:23:32 -0600 (MDT) (envelope-from rousskov) Date: Thu, 24 Apr 2003 15:23:32 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP transport nomination In-Reply-To: <20030424141005.08b98973.mrose@dbc.mtview.ca.us> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CCD@hermes.webwasher.com> <20030424141005.08b98973.mrose@dbc.mtview.ca.us> 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: On Thu, 24 Apr 2003, Marshall Rose wrote: > [ speaking as beep guy, and not co-chair... ] Since Dave Crocker is not around, we can assume the above is the default :-). > alex - perhaps a better way of explaining it is that each beep > interaction exchanges a mime object over an 8bit-clean path. > mime objects are serialized as some headers, e.g., Content-Type:, a > blank line, and then the body. the default content-type is > application/octet-stream, which means that if the serialized object > starts with a blank line, then > > Content-Type: application/octet-stream > > is assumed (not application/beep+xml). this is the "optimize for > binary" hack that dave crocker detests so much (dave doesn't like > defaults). > > the use of xml in beep can be limited to channel 0, which is used for > channel management (e.g., open a channel for doing ocp). otherwise, beep > really doesn't care how one structures the data it sends. Sorry I misread the default. This probably means even less overhead for data exchanges over BEEP if OCP agents agree with that default. My earlier examples lack Content-Type: application/beep+xml lines where XML is involved (because I incorrectly thought it was the default type). Thanks for clarifying this. Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 24 17:52:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05500 for ; Thu, 24 Apr 2003 17:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198ogT-0001ur-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 17:55:13 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198ogS-0001uo-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 17:55:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLitt2029858 for ; Thu, 24 Apr 2003 14:44:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLitqx029857 for ietf-openproxy-bks; Thu, 24 Apr 2003 14:44:55 -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.8p1/8.12.8) with ESMTP id h3OList2029851 for ; Thu, 24 Apr 2003 14:44: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 h3OLih2R090957; Thu, 24 Apr 2003 15:44:43 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3OLihhF090956; Thu, 24 Apr 2003 15:44:43 -0600 (MDT) (envelope-from rousskov) Date: Thu, 24 Apr 2003 15:44:43 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: ietf-openproxy@imc.org Subject: RE: OCP transport nomination In-Reply-To: <200304241933.h3OJXTN32356@localhost.localdomain> Message-ID: References: <200304241933.h3OJXTN32356@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: On Thu, 24 Apr 2003, The Purple Streak, Hilarie Orman wrote: > This looks pretty good. The major performance issue is whether or > not the content message headers can be easily parsed without calling > any XML library. The second issue is the same question for > transaction establishment. The examples make it look quite easy. > It is imperative that we be able to avoid calling XML libraries for > these operations. If we do not use XML for our own (OCP) purposes, then whether you need sophisticated XML parsing libraries/code depends on how compliant you want your implementation to be. For example, in most cases, one can just search (a simple strstr(3) in C) for the only profile ID that implementation supports without even understading XML! This will, of course, lead to compliance violations and interoperability problems. But you could have a configuration option (fast versus compliant parser). It is probably also possible to write a OCP/BEEP-optimized XML parser that remains compliant but fast and correctly ignores anything that OCP/BEEP does not care about. It is more work that strstr(), but it is not a lot of work. I suspect implementations concerned about XML and performance will do something like that unless they really do not care about compliance. Alex. From owner-ietf-openproxy@mail.imc.org Thu Apr 24 18:23:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08152 for ; Thu, 24 Apr 2003 18:23:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198pAM-0002LV-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 18:26:06 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198pAL-0002LM-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 18:26:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OMFSt2031219 for ; Thu, 24 Apr 2003 15:15:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OMFSru031218 for ietf-openproxy-bks; Thu, 24 Apr 2003 15:15:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OMFRt2031212 for ; Thu, 24 Apr 2003 15:15:27 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.5) with ESMTP id h3OMLmmh015593; Thu, 24 Apr 2003 16:21:48 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3OMEKh08023; Thu, 24 Apr 2003 16:14:20 -0600 Date: Thu, 24 Apr 2003 16:14:20 -0600 Message-Id: <200304242214.h3OMEKh08023@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: mrose@dbc.mtview.ca.us Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <20030424141425.00d237fb.mrose@dbc.mtview.ca.us> Subject: Re: OCP transport nomination Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 24 Apr 2003 at 14:14:25 -0700 Marshall Rose said: > [ speaking as the beep guy, and not the co-chair... ] > > I'm not sure how much of an advantage BEEP's security mechanisms turn > > out to be. It doesn't seem to have any specific support for detailed > > security policy, ... > nor would you want it to, given that security policies are > either domain-specific or are so general as to lack meaning. The expression of security policy in the TLS context comes down to a list of cryptographic preferences. I didn't see any way through BEEP to encode anything about TLS negotiations. Perhaps I'm not sufficiently adept at BEEP navigation to find the profile document - all I saw was a URI, and my assumption was that the single option was "do TLS". What document shows how to encode a request for mutual authentication, encryption algorithm, authentication mechanism? Hilarie From owner-ietf-openproxy@mail.imc.org Thu Apr 24 18:32:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08641 for ; Thu, 24 Apr 2003 18:32:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198pIn-0002Tr-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 18:34:49 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 198pIn-0002To-00 for opes-archive@ietf.org; Thu, 24 Apr 2003 18:34:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OMOrt2031506 for ; Thu, 24 Apr 2003 15:24:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OMOrVo031505 for ietf-openproxy-bks; Thu, 24 Apr 2003 15:24:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OMOqt2031500 for ; Thu, 24 Apr 2003 15:24:52 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h3OMOoXk010196; Thu, 24 Apr 2003 15:24:50 -0700 (PDT) Date: Thu, 24 Apr 2003 15:24:49 -0700 From: Marshall Rose To: "The Purple Streak, Hilarie Orman" Cc: ietf-openproxy@imc.org Subject: Re: OCP transport nomination Message-Id: <20030424152449.0494005c.mrose@dbc.mtview.ca.us> In-Reply-To: <200304242214.h3OMEKh08023@localhost.localdomain> References: <20030424141425.00d237fb.mrose@dbc.mtview.ca.us> <200304242214.h3OMEKh08023@localhost.localdomain> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 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: Content-Transfer-Encoding: 7bit [ speaking as the beep guy, and not the co-chair... ] > > > > I'm not sure how much of an advantage BEEP's security mechanisms turn > > > out to be. It doesn't seem to have any specific support for detailed > > > security policy, ... > > > nor would you want it to, given that security policies are > > either domain-specific or are so general as to lack meaning. > > The expression of security policy in the TLS context comes down to a > list of cryptographic preferences. I didn't see any way through BEEP > to encode anything about TLS negotiations. Perhaps I'm not > sufficiently adept at BEEP navigation to find the profile document - > all I saw was a URI, and my assumption was that the single option was > "do TLS". What document shows how to encode a request for mutual > authentication, encryption algorithm, authentication mechanism? well, where i come from we refer to that as a negotation issue not a matter of security policy. (although i suppose one could categorize the former as a subset of the latter). to me a security policy refers to things like authorization, access control, etc., which, by definition are domain-specific. if you look at the security considerations section of the various rfcs that use beep (e.g., 3195, 3288), you'll see that things like cryptographic preferences is dictated there. things like cryptographic preferences are already encoded in the tls negotiation... /mtr From owner-ietf-openproxy@mail.imc.org Fri Apr 25 11:02:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11810 for ; Fri, 25 Apr 2003 11:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1994kN-0001MV-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 11:04:19 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1994kM-0001MS-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 11:04:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PEp5t2011609 for ; Fri, 25 Apr 2003 07:51:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PEp5s0011608 for ietf-openproxy-bks; Fri, 25 Apr 2003 07:51:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PEp3t2011602 for ; Fri, 25 Apr 2003 07:51:04 -0700 (PDT) (envelope-from info@utel.net) Received: from f13m-3-114.d1.club-internet.fr ([212.195.78.114] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 1994X9-0002Ox-00; Fri, 25 Apr 2003 07:50:41 -0700 Message-Id: <5.2.0.9.0.20030425144740.02aa20d0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 25 Apr 2003 14:53:32 +0200 To: Alex Rousskov , "The Purple Streak, Hilarie Orman" From: jfcm Subject: RE: OCP transport nomination Cc: ietf-openproxy@imc.org In-Reply-To: References: <200304241933.h3OJXTN32356@localhost.localdomain> <200304241933.h3OJXTN32356@localhost.localdomain> 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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just want to recall my "DNS support filter" (I want the final solution to be operational to support DNS.2 - DNS new generation- and DNS+ - exended services). They may not call on TCP and work on UDP. There are many OPES services which my consist of short information being changed, upgrated, obtianed, collected, etc. that UDP could support faster? jfc From owner-ietf-openproxy@mail.imc.org Fri Apr 25 13:51:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16757 for ; Fri, 25 Apr 2003 13:51:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1997OB-0002UC-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 13:53:35 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 1997OB-0002U3-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 13:53:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PHeSt2019986 for ; Fri, 25 Apr 2003 10:40:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PHeSUJ019985 for ietf-openproxy-bks; Fri, 25 Apr 2003 10:40: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.8p1/8.12.8) with ESMTP id h3PHeQt2019977 for ; Fri, 25 Apr 2003 10:40: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 h3PHeS2R019639; Fri, 25 Apr 2003 11:40:28 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3PHeSdJ019638; Fri, 25 Apr 2003 11:40:28 -0600 (MDT) (envelope-from rousskov) Date: Fri, 25 Apr 2003 11:40:28 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: OCP transport nomination In-Reply-To: <5.2.0.9.0.20030425144740.02aa20d0@mail.utel.net> Message-ID: References: <200304241933.h3OJXTN32356@localhost.localdomain> <200304241933.h3OJXTN32356@localhost.localdomain> <5.2.0.9.0.20030425144740.02aa20d0@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: On Fri, 25 Apr 2003, jfcm wrote: > I just want to recall my "DNS support filter" (I want the final > solution to be operational to support DNS.2 - DNS new generation- > and DNS+ - exended services). They may not call on TCP and work on > UDP. > > There are many OPES services which my consist of short information > being changed, upgrated, obtianed, collected, etc. that UDP could > support faster? If my view of OPES/OCP is correct, then it makes almost no difference whether the proxied protocol is based on TCP, UDP, or something else. OCP is an efficient _callout_ (i.e., orthogonal to the proxied protocol path) protocol that can use a single TCP connection to process thousands of small application messages, with little per-message overhead as long as the set of callout servers used by the OPES processor is constant and of reasonable size. Do we expect the set of callout servers to change so rapidly that server connections cannot be reused at the OPES processor? If yes, we may have to support UDP-like OCP transport (and probably change a lot of OCP requirements related to "OCP connections"). If no, then transport connection setup time is not an issue and TCP-based OCP transport should work as well (or better) as UDP-based one. I think the latter is much closer to reality. Am I missing something important here? Alex. P.S. We have to design OCP so that it is possible to process a small application message with a single RTT delay (something sent to callout server once, something received back once, no additional exchanges on OCP level). From owner-ietf-openproxy@mail.imc.org Fri Apr 25 14:40:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18528 for ; Fri, 25 Apr 2003 14:40:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19989n-0002mn-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 14:42:47 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19989m-0002mk-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 14:42:46 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PIVnt2021860 for ; Fri, 25 Apr 2003 11:31:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PIVnPE021859 for ietf-openproxy-bks; Fri, 25 Apr 2003 11:31: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 (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PIVmt2021852 for ; Fri, 25 Apr 2003 11:31:48 -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.9/8.12.9) with ESMTP id h3PIVnHa093080 for ; Fri, 25 Apr 2003 14:31: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 h3PIVhc6005612 for ; Fri, 25 Apr 2003 14:31:43 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3PIVgQ4011954 for ; Fri, 25 Apr 2003 14:31:43 -0400 (EDT) Message-ID: <3EA97F43.3040306@mhof.com> Date: Fri, 25 Apr 2003 14:32:35 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: OCP transport nomination References: <200304241933.h3OJXTN32356@localhost.localdomain> <200304241933.h3OJXTN32356@localhost.localdomain> <5.2.0.9.0.20030425144740.02aa20d0@mail.utel.net> 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: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Do we expect the set of callout servers to change so rapidly that > server connections cannot be reused at the OPES processor? If yes, we > may have to support UDP-like OCP transport (and probably change a lot > of OCP requirements related to "OCP connections"). If no, then > transport connection setup time is not an issue and TCP-based OCP > transport should work as well (or better) as UDP-based one. I think > the latter is much closer to reality. Am I missing something important > here? No, I don't think you're missing anything. You summarized very nicely what my understanding has been for a while. Since we expect to "re-use" estbalished TCP connections between OPES processor and callout server, the TCP connection establishment overhead is probably not of big importance. -Markus From owner-ietf-openproxy@mail.imc.org Fri Apr 25 17:00:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23537 for ; Fri, 25 Apr 2003 17:00:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199AL6-0003g0-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 17:02:36 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 199AL5-0003fx-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 17:02:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PKoet2026217 for ; Fri, 25 Apr 2003 13:50:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PKoeXH026216 for ietf-openproxy-bks; Fri, 25 Apr 2003 13:50:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PKodt2026211 for ; Fri, 25 Apr 2003 13:50:40 -0700 (PDT) (envelope-from info@utel.net) Received: from f02m-5-174.d1.club-internet.fr ([212.194.16.174] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 199A9W-0003oX-00 for ietf-openproxy@imc.org; Fri, 25 Apr 2003 13:50:39 -0700 Message-Id: <5.2.0.9.0.20030425222345.03f19ec0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 25 Apr 2003 22:40:40 +0200 To: ietf-openproxy@imc.org From: jfcm Subject: Re: OCP transport nomination In-Reply-To: <3EA97F43.3040306@mhof.com> References: <200304241933.h3OJXTN32356@localhost.localdomain> <200304241933.h3OJXTN32356@localhost.localdomain> <5.2.0.9.0.20030425144740.02aa20d0@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 - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 20:32 25/04/03, Markus Hofmann said: >Alex Rousskov wrote: >>Do we expect the set of callout servers to change so rapidly that >>server connections cannot be reused at the OPES processor? If yes, we >>may have to support UDP-like OCP transport (and probably change a lot >>of OCP requirements related to "OCP connections"). If no, then >>transport connection setup time is not an issue and TCP-based OCP >>transport should work as well (or better) as UDP-based one. I think >>the latter is much closer to reality. Am I missing something important >>here? > >No, I don't think you're missing anything. You summarized very nicely what >my understanding has been for a while. Since we expect to "re-use" >estbalished TCP connections between OPES processor and callout server, the >TCP connection establishment overhead is probably not of big importance. As indicated before the first need I can see is for a pre-resolver. Draft not completed: I consider OPES for the job. 1. User enters a DN with a TLD 2. the OPES processor filters on the TLD 3. if unknown string ask call out server(s) if it is an internationalized scripting or an existing TLD 4. if yes, corrects and auto-generates the filter + possible change 5. if not, potentially caches the filer (memory size dependant) and may be denies the call Looks very similar to DNS current traffic to me. 1. if the OPES is in front of the ISP nameserver TCP support to one server seems OK. 2. if it is in front of the resolver I understand that OCP would not be a good choice (fast occasionial needs) Is that correct? I note that if several call out servers are to be polled, UDP seems a need (I am not good on TCP/UDP)? jfc From owner-ietf-openproxy@mail.imc.org Fri Apr 25 17:42:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24360 for ; Fri, 25 Apr 2003 17:42:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199B05-0003re-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 17:44:57 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 199B05-0003rb-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 17:44:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PLYEt2027914 for ; Fri, 25 Apr 2003 14:34:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PLYENG027913 for ietf-openproxy-bks; Fri, 25 Apr 2003 14:34:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PLYCt2027908 for ; Fri, 25 Apr 2003 14:34:13 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h3PLf24k026640; Fri, 25 Apr 2003 15:41:03 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3PLXBF11304; Fri, 25 Apr 2003 15:33:11 -0600 Date: Fri, 25 Apr 2003 15:33:11 -0600 Message-Id: <200304252133.h3PLXBF11304@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: markus@mhof.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <3EA97F43.3040306@mhof.com> Subject: Re: OCP transport nomination Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: While re-use is certainly expected, we shouldn't make the overhead so high that it becomes impractical to open many connections. Separate connections might be needed to keep sensitive user data encrypted under different keys, multiple connections might be desirable for scheduling streaming applications, etc. Hilarie On Fri, 25 Apr 2003 at 14:32:35 -0400 Markus Hofmann observed: > Alex Rousskov wrote: > > Do we expect the set of callout servers to change so rapidly that > > server connections cannot be reused at the OPES processor? If yes, we > > may have to support UDP-like OCP transport (and probably change a lot > > of OCP requirements related to "OCP connections"). If no, then > > transport connection setup time is not an issue and TCP-based OCP > > transport should work as well (or better) as UDP-based one. I think > > the latter is much closer to reality. Am I missing something important > > here? > No, I don't think you're missing anything. You summarized very nicely > what my understanding has been for a while. Since we expect to > "re-use" estbalished TCP connections between OPES processor and > callout server, the TCP connection establishment overhead is probably > not of big importance. From owner-ietf-openproxy@mail.imc.org Fri Apr 25 18:02:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24682 for ; Fri, 25 Apr 2003 18:02:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199BJj-0003w3-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 18:05:15 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 199BJj-0003w0-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 18:05:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PLt4t2028555 for ; Fri, 25 Apr 2003 14:55:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PLt4Q0028554 for ietf-openproxy-bks; Fri, 25 Apr 2003 14:55:04 -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.8p1/8.12.8) with ESMTP id h3PLt2t2028548 for ; Fri, 25 Apr 2003 14:55: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 h3PLt42R026514; Fri, 25 Apr 2003 15:55:04 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3PLt4g7026513; Fri, 25 Apr 2003 15:55:04 -0600 (MDT) (envelope-from rousskov) Date: Fri, 25 Apr 2003 15:55:04 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP transport nomination In-Reply-To: <5.2.0.9.0.20030425222345.03f19ec0@mail.utel.net> Message-ID: References: <200304241933.h3OJXTN32356@localhost.localdomain> <200304241933.h3OJXTN32356@localhost.localdomain> <5.2.0.9.0.20030425144740.02aa20d0@mail.utel.net> <5.2.0.9.0.20030425222345.03f19ec0@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: On Fri, 25 Apr 2003, jfcm wrote: > As indicated before the first need I can see is for a pre-resolver. > Draft not completed: I consider OPES for the job. > > 1. User enters a DN with a TLD > 2. the OPES processor filters on the TLD > 3. if unknown string ask call out server(s) if it is an internationalized > scripting or an existing TLD > 4. if yes, corrects and auto-generates the filter + possible change > 5. if not, potentially caches the filer (memory size dependant) and may be > denies the call Though I am not sure what you mean by "auto-generates the filter + possible change", the above does not seem to fit OPES model nicely. You are talking about a query/response or RPC interface with the callout server: "is it an internationalized scripting?" While everything can be viewed as a form of an RPC interface, OPES is specializing in _adapting proxied traffic_. It is possible to adjust the above so that it fits OPES better: ... 2. the OPES processor forwards the DNS query (with a questionable DN) to a callout server 3. the OPES processor receives a possibly adapted query from the callout server ... > Looks very similar to DNS current traffic to me. > 1. if the OPES is in front of the ISP nameserver TCP support to one server > seems OK. Yes, though I would rather describe OPES processor as a part of an [ISP] nameserver to fit OPES model better; recall that OPES processor is a proxy/hop on the application protocol path, a DNS server in this case. > 2. if it is in front of the resolver I understand that OCP would not be a > good choice (fast occasionial needs) Is that correct? What do you mean by "front of the resolver"? How is that different from "front of the ISP nameserver"? Fast occasional use is OK as long as both agents are able to keep TCP connection(s) between them open. If they cannot (for whatever reason), then "fast occasional use" would require UDP-like transport. > I note that if several call out servers are to be polled, UDP seems > a need (I am not good on TCP/UDP)? The number of servers is not relevant as long as it is reasonable compared to the capacity of the OPES processor. For example, one can serve thousands of concurrent TCP connections efficiently on a small server. If we think UDP-like transport is a must, we would probably have to give up (or make optional) OCP/OPES features like encryption and authentication. Most lossy transports have relatively small maximum payloads that may not allow for much overhead. In fact, it would be impossible, for example, to adapt many DNS responses because they are already close to the maximum packet size. To summarize, I agree that OCP over TCP (or any connection-oriented transport) is bad for "fast occasional use" in busy environments. We have to decide whether there is any application that requires "very fast occasional adaptation" and that deals with busy processors and/or services. Perhaps your "front of the resolver" is a good example, but please clarify what you mean by that. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Apr 25 18:11:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24885 for ; Fri, 25 Apr 2003 18:11:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199BRu-0003zK-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 18:13:42 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 199BRt-0003zH-00 for opes-archive@ietf.org; Fri, 25 Apr 2003 18:13:41 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PM4Gt2028863 for ; Fri, 25 Apr 2003 15:04:16 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PM4GGM028862 for ietf-openproxy-bks; Fri, 25 Apr 2003 15:04:16 -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.8p1/8.12.8) with ESMTP id h3PM4Ft2028857 for ; Fri, 25 Apr 2003 15:04:15 -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 h3PM4H2R026740; Fri, 25 Apr 2003 16:04:17 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h3PM4Hr2026739; Fri, 25 Apr 2003 16:04:17 -0600 (MDT) (envelope-from rousskov) Date: Fri, 25 Apr 2003 16:04:17 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP transport nomination In-Reply-To: <200304252133.h3PLXBF11304@localhost.localdomain> Message-ID: References: <200304252133.h3PLXBF11304@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: On Fri, 25 Apr 2003, The Purple Streak, Hilarie Orman wrote: > While re-use is certainly expected, we shouldn't make the overhead > so high that it becomes impractical to open many connections. > Separate connections might be needed to keep sensitive user data > encrypted under different keys, multiple connections might be > desirable for scheduling streaming applications, etc. Support for separate connections is a MUST, of course! The overhead we were talking about is in the connection _establishment_ phase. The overhead to keep a connection open is usually much smaller and is less important as far as response time or bandwidth is concerned. The reason to choose UDP over TCP is usually not the number of concurrent events (connections or queries) but the cost of creating an event (opening a connection or sending a packet). Alex. > On Fri, 25 Apr 2003 at 14:32:35 -0400 Markus Hofmann observed: > > > Alex Rousskov wrote: > > > > Do we expect the set of callout servers to change so rapidly that > > > server connections cannot be reused at the OPES processor? If yes, we > > > may have to support UDP-like OCP transport (and probably change a lot > > > of OCP requirements related to "OCP connections"). If no, then > > > transport connection setup time is not an issue and TCP-based OCP > > > transport should work as well (or better) as UDP-based one. I think > > > the latter is much closer to reality. Am I missing something important > > > here? > > > No, I don't think you're missing anything. You summarized very nicely > > what my understanding has been for a while. Since we expect to > > "re-use" estbalished TCP connections between OPES processor and > > callout server, the TCP connection establishment overhead is probably > > not of big importance. > > > From owner-ietf-openproxy@mail.imc.org Sat Apr 26 14:13:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24588 for ; Sat, 26 Apr 2003 14:13:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199UDL-0000he-00 for opes-archive@ietf.org; Sat, 26 Apr 2003 14:15:55 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 199UDK-0000ha-00 for opes-archive@ietf.org; Sat, 26 Apr 2003 14:15:55 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3QI5It2017232 for ; Sat, 26 Apr 2003 11:05:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3QI5IL4017231 for ietf-openproxy-bks; Sat, 26 Apr 2003 11:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3QI5Ht2017225 for ; Sat, 26 Apr 2003 11:05:17 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h3QICL4k029222; Sat, 26 Apr 2003 12:12:22 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3QI46M05576; Sat, 26 Apr 2003 12:04:06 -0600 Date: Sat, 26 Apr 2003 12:04:06 -0600 Message-Id: <200304261804.h3QI46M05576@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: info@utel.net Cc: rousskov@measurement-factory.com, ietf-openproxy@imc.org In-reply-to: Yourmessage <5.2.0.9.0.20030425144740.02aa20d0@mail.utel.net> Subject: RE: OCP transport nomination Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Small requests over TCP should be fine. The only reason I can see for supporting UDP is for RTP or some kinds of broadcast (if, for some reason, the OPES processor would broadcast or anycast to groups of callout servers). On Fri, 25 Apr 2003 at 14:53:32 +0200 jfcm penned: > I just want to recall my "DNS support filter" (I want the final solution to > be operational to support DNS.2 - DNS new generation- and DNS+ - exended > services). They may not call on TCP and work on UDP. > There are many OPES services which my consist of short information being > changed, upgrated, obtianed, collected, etc. that UDP could support faster? > jfc Hilarie